• Xin26x is an univeral video encoder framework, which can accommodate all video coding standard on this planet so far.
• It is optimized for real time video communication, live streaming application and offline video encoding.
• It currently supports HEVC, AV1(I frame), VVC video coding standards.
• It is a very high performance encoder.
• It is well-structured for understandability, maintainability and scalability.
• It is written from scratch and has a plain C API to enable a simple integration into other software.
• It is very small footprint encoder, it takes very small memory requirement under restricted mode.

Xin26x is organized into the following core modules:

• h26x_core: Provides common foundational components, including: pixel-level operations, MCTF low-level implementation, uinttree data structure, thread pool, and shared modules for HEVC and VVC (e.g., transform, inverse transform, SAO)
• h265_core: Shared components for the HEVC encoder and decoder
• h266_core: Shared components for the VVC encoder and decoder
• AV1_core (h265p_core): Shared components for the AV1 encoder and decoder
• h265_enc: HEVC encoder implementation
• h266_enc: VVC encoder implementation
• AV1_enc (h265p_enc): AV1 encoder implementation
• h26x-api: Public API interface layer for xin26x

The project is modular and can be configured based on your needs:

• If you only need HEVC encoding, link the following modules: h26x_core, h265_core, h265_enc, h26x-api. To add VVC support on top of HEVC, simply include: h266_core, h266_enc.

• All modules can be selectively enabled or disabled during the CMake build configuration, without modifying the codebase.

Additional Notes

• The dashed components in the architecture diagram indicate reserved structures that are not yet implemented.
• AV1 is internally referred to as: h265p (H.265 Plus).

xin26x_test.exe -i input.yuv -w 1280 -h 720 -f 30 -a 2 -p 1 -r 1 -b 2000000 -o test.bin
xin26x_test.exe -i input.yuv -w 1280 -h 720 -f 30 -a 2 -p 1 -r 0 -q 32 -o test.bin

• Our Windows build use CMake and Visual Studio. The workable version is CMake3.5 or above and Visual Studio 2022.
• Run make-solutions.bat under build folder, building projects will be generated under this folder.
• In addition, we put a pre-built win64 exe under folder testbin, you can run it on win64 without build.

Please refer to xin_app_enc.c.

Offline encoder parameters for xin26x and x265 are as follows:

x265 veryslow
x265.exe -o test.bin --input-res 1920x1080 --fps 30 --frames frames --bitrate kbitrate --tune psnr -p veryslow input.yuv

xin265 p1
xin26x_test.exe -o test.bin -i input.yuv -w 1920 -h 1080 -f 30 -n frames -r 6 -b bitrate -p 1 -a 0

xin265 p4
xin26x_test.exe -o test.bin -i input.yuv -w 1920 -h 1080 -f 30 -n frames -r 6 -b bitrate -p 4 -a 0

xin265 p6
xin26x_test.exe -o test.bin -i input.yuv -w 1920 -h 1080 -f 30 -n frames -r 6 -b bitrate -p 6 -a 0

xin266 p1
xin26x_test.exe -o test.bin -i input.yuv -w 1920 -h 1080 -f 30 -n frames -r 6 -b bitrate -p 1 -a 2

xin266 p4
xin26x_test.exe -o test.bin -i input.yuv -w 1920 -h 1080 -f 30 -n frames -r 6 -b bitrate -p 4 -a 2

xin266 p6
xin26x_test.exe -o test.bin -i input.yuv -w 1920 -h 1080 -f 30 -n frames -r 6 -b bitrate -p 6 -a 2

In above table, we set x265(veryslow) as a reference, others are compared with x265(veryslow). x265 is 2020/12/25 version.

Single thread for IPPPPPPPPP under suitbale bitrate

For a encoder, we normally take a tradeoff between picture quality and encoder sppeed. For a RTC encoder, performance on unit core or whole system capacity is more important. The performance of xin26x(HEVC) is x4 compared to x265 under single unit core. One important thing is that, the screen content coding performance of xin26x(HEVC) outperform x265 greatly both for speed and quality.

I would like to note that, to make fair comparison to x265, the lookahead and cu-tree are both enabled. In addition, ABR is adopted in both xin26x and x265. When it comes to real RTC world, none of these coding tools can be applied, so there will be a inevitable loss of PSNR for RTC encoder. But the speed for a real RTC encoder should be faster than the data in the table.

• Intel x86 with AVX2 support.

• Max resolution we support is 3860x2160.
• Max temporal layer we support is 3.
• For AV1, the outputted frame are all IDR. Please ignore encoder speed, currently AV1 encoder is pure C code, without SIMD or multi-thread optimization.
• Under evaluation mode, only ABR is supported.
• For VVC, please use vtm 10 to decode the bitstream. You can download vtm 10 from https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/-/releases/VTM-10.0

The main purpose of Xin26x is unification. Xin26x is designed to unify different video standards and different implementations for same video standard.

In past 30 years, there are a lot of video standards released by different groups. Fortunately, these standards are all block-based motion compensation and transform hybrid scheme. Actually, it never changed since h.261 had been released. Based on that, Xin26x is designed to unify mainstream video standards into ONE encoder. Xin26x is a flexible video encoder framework to accommodate all the video standard so far on this planet. Currently, Xin26x have implemented h.265 and h.266. For AV1, Xin26x supports static picture encoding. Later, Xin26x is planning to accommodate EVC.

For same video standard, there are different implememations target to different application scenario. In my opinion, there are mainly 3 categories of encoder according to application latency.

Different encoding tools are adopted for different encoder implementions. For example, B frame is normally not adopted for RTC(Real-Time Communication) encoder. Frame parallelism is not used for RTC encoder. Rate control for RTC encoder is very strict. Besides, lookahead and mb-tree are normally not applied on first 2 encoders. Screen content coding tools are normally considered for a RTC encoder. In current industry, Openh264 is for real time video communication application. X264 is mainly for offline and low latency. Xin26x begins at a RTC video encoder. To accommodate offline video coding tools and video standard evolution, the encoder architecture has been greatly refactored. Also to make encoder work under different application scenarios, multiple different rate control modes are designed in Xin26x.

I wish video coding standardization would take a revolution, break though current hybrid scheme, stop piling up computation for better compression rate in the future, then Xin26x reaches its end-of-life. Otherwise, Xin26x will keep catching up with the latest video coding standard, till I reach my end-of-life.

Basicly, Xin26x is purely a result of coding happiness pursuit. It is named after my 8 year old beautiful child. I would like her know how great her father is. After she grows up, I wish she would know how father loved her.

• VVC Deployment Challenges

Currently, I am open to both full-time and part-time opportunities. In the meantime, I am dedicating my time to the Xin26x project, focusing on further development and optimization. I am always happy to connect with teams working on interesting technical challenges.

Linkin:

https://www.linkedin.com/in/chao-zhou-2ab52b30a/