xin26x - Open Source HEVC/VVC encoder

[birdie]

Someone has just mentioned this encoder on Wikipedia, perhaps, its author?

Nevertheless, it looks interesting:

https://github.com/pigpeppa/xin26x

Compares itself with x265 veryslow and encodes better at some presets at least in terms of BD-PSNR (dB) or so it seems.

Also promises to be three times (!) faster than x265 at comparable PSNR.

This looks rather impressive.

[GeoffreyA]

It does look interesting, especially the concept of unification.

[rwill]

birdie, you write "Open Source" but I dont see the source in the github repo...

[hajj_3]

birdie, you write "Open Source" but I dont see the source in the github repo...

you click on "code" then "Download zip", you then get this link: https://github.com/pigpeppa/xin26x/archive/refs/heads/master.zip

[GeoffreyA]

Some pieces are only released as static libraries.

[birdie]

birdie, you write "Open Source" but I dont see the source in the github repo...

git clone https://github.com/pigpeppa/xin26x.git has stopped working for you?? :confused:

Source code means source files - and they are there, you can browse and see them, what is that you're looking for?

[rwill]

git clone https://github.com/pigpeppa/xin26x.git has stopped working for you?? :confused:

Source code means source files - and they are there, you can browse and see them, what is that you're looking for?

Yes, Source code means source files, there aren't many in the github repo...

[rwill]

you click on "code" then "Download zip", you then get this link: https://github.com/pigpeppa/xin26x/archive/refs/heads/master.zip

Thanks for the tip, but actually I am not retarded.

[birdie]

The author showed up (https://www.reddit.com/r/VVC/comments/1vp8yw3/comment/p4401gf/) on Reddit:

Hello, I’m the author, so I can probably answer some of your questions.

Xin26x is a personal encoder. It was actually first released on August 14, 2020. Coincidentally, that’s also my daughter’s birthday and the day VVC was finalized.

In the beginning, Xin26x was released as a library. Over the past few years, the encoder architecture has evolved quite a lot, and more and more coding tools have been added and improved. You can see this pretty clearly if you go through the Git log.

As for the performance improvements, you can take a look at the source code. I’ve already made the VVC source code public.

From my point of view, x265 is basically built on top of the HM codebase, with some rate-control algorithms from x264 added to it. HM was mainly designed as a reference implementation, rather than as a codebase intended for a commercial encoder. If I get a chance, I may write a separate article about this and explain my thoughts in more detail.

I’ll also open the HEVC and and other low-level code soon.

Thanks for your interest in Xin26x!

[Z2697]

I saw him registered Doom9 account. New account need to wait several days before he can post though.

[Swede]

I've backdated him so he's ok to post now if he wants to.

[czhou2]

Hello, I am the author. Feel free to ask me anything about Xin26x.

Xin26x is a personal encoder project. It supports hevc/vvc/av1. For a long time, it has been released on GitHub as a library. Recently, I've been considering releasing the source code module by module.

Currently, except for h26x_core, h265_encoder, and h265_core, all modules are publicly available.

I've already opened up the hardest and most critical part of the code -- h266_encoder. You can actually do source-level debugging and profiling of h266_encoder if you want to learn more about Xin26x. There's no need to hide the really challenging stuff. ��

Thanks!

[birdie]

Hello, I am the author. Feel free to ask me anything about Xin26x.

Xin26x is a personal encoder project. It supports hevc/vvc/av1. For a long time, it has been released on GitHub as a library. Recently, I've been considering releasing the source code module by module.

Currently, except for h26x_core, h265_encoder, and h265_core, all modules are publicly available.

I've already opened up the hardest and most critical part of the code -- h266_encoder. You can actually do source-level debugging and profiling of h266_encoder if you want to learn more about Xin26x. There's no need to hide the really challenging stuff.

Thanks!

Hi!

I have a few questions, if you don't mind.

1. Since you're working so deeply on video coding, what are your thoughts on this discussion regarding vvenc?

https://github.com/fraunhoferhhi/vvenc/discussions/495

VVC has far more coding tools and much higher complexity than H.264, yet it seems difficult if not impossible to achieve large gains over older codecs on the kinds of content and quality levels that matter most to ordinary users, as opposed to large-scale streaming services where delivery bandwidth and decoder compatibility have very different trade-offs.

I'm curious whether you think this is fundamentally a limitation of modern codec design, a problem with encoder implementation/optimization, or simply a consequence of the particular quality metrics and test material being used.

2. Secondly, since you appear to be from China, and presumably have some insight into the local video-coding industry: what do you think about proprietary Chinese encoders such as Taotian S26X?

According to MSU's 2025 codec comparison, it currently achieves the best results in the world under their methodology:

https://www.compression.ru/video/codec_comparison/2025/main_report.html

I'm curious why so many Chinese encoders remain completely proprietary and are never released publicly. S26X is just one example; there seem to have been dozens of Chinese encoders over the years. Is there a particular business or technical reason for this?

3. I've seen Xin26x outperform x265 in some comparisons. Do you intend to compete directly with vvenc as well?

https://github.com/fraunhoferhhi/vvenc

4. Do you have any shared cloud storage where you keep your encodes, preferably together with the original source files?

It would be interesting to inspect the actual encode/source pairs, especially for difficult content. Even a relatively small public sample would be useful.

5. Is anyone else involved in maintaining or developing Xin26x, or is it currently entirely your own project?

I'm asking partly because of the bus factor. Given how much work has obviously gone into it, I'd hate to see the project disappear if you eventually become unable to maintain it.

6. Have you ever considered accepting donations or using something like GitHub Sponsors or GoFundMe?

I'd genuinely be interested in supporting the project. One of the things I'd love to be able to do is recompress my own video collection at near-transparent quality while substantially reducing the bitrate—ideally something on the order of 2× where the source material allows it.

So far, I haven't found a modern codec/encoder combination that is particularly compelling for that use case. Perhaps AV2 will eventually be suitable, but that's still unknown.

Thanks for releasing your work, and congratulations on getting this far. Xin26x is a very interesting project.

[GeoffreyA]

Yes, not too long ago in a grain comparison here, x264 gave the modern encoders stiff competition. If I remember correctly, VVenC simply collapsed.

[Z2697]

It's hard to see where's the confusion coming from.
Coding standard and encoder are two different thing.
New coding tools are there to provide more "choice" and that's where the computation is going.
But your residual isn't going anywhere (if you want "archival"), especially with dynamic grain.
And if you keep the feature scale* the same, the larger blocks have a limited use case but encoder may still evaluate all of them.

It's a legitimate question but there's no need to harass developers over and over.
If it's a feature request, do so.

*I don't want to refer to it as resolution, think about the idea of having a same image at 1080p and 4k vs. stack 4 1080p image to get 4k, the scale of the features in the image is different in former but the same in latter.

[birdie]

I didn't mean to harass anyone, it was [a] genuine question[s] for a person who's deep into modern codecs.

[Z2697]

According to MSU's 2025 codec comparison

LOL, I won't believe a single word from their report unless those encoders are available to the public.
It has been ruined since those chinese companies found out a new way of boasting.
(To be clear, I just don't like the "marketing", no beef with the developers (unless they are the one(s) pushing these marketing acts)
19210

[birdie]

LOL, I won't believe a single word from their report unless those encoders are available to the public.
It has been ruined since those chinese companies found out a new way of boasting.
(To be clear, I just don't like the "marketing", no beef with the developers (unless they are the one(s) pushing these marketing acts)
19210

Is this a real picture from this comparison? Looks like a joke.

The MSU media lab has made a fool of itself.

[Z2697]

Is this a real picture from this comparison? Looks like a joke.

The MSU media lab has made a fool of itself.

It's from the

Bitrate/quality—usecase “Slow (1 fps),” camping sequence, Y-VMAF (v0.6.1) metric

Plot in free version of the report.
The spike is from "Taotian S266".
Switching to VMAF-NEG eliminates this spike, which indicate that the "encoder" is doing some sharpening to achieve a artificially high score.
(You might want to call it cheating)

The reason for it to be a confidential encoder is then, to hide the fact that they are cheating?
I mean believe it or not, there are non-chinese companies making proprietary encoders, but chinese companies are only ones that are submitting to and sponsoring(!) the competition. Because they are using this well known competition as their marketing tool.

And the "bitrate percentage" MSU invented and claimed better than BD-rate?
It's showing x264 need 2.5x~3x the bitrate to catch up x265! While the wildest dreams of the standard designers is 2x...
WTF, really.

BTW according to MSU the "Taotian S26X" is actually using a proprietary standard, as well as some other participants, this can be a good reason for them to be not available anywhere.

Next is more of a rant but you might not know how greedy they are.
Most of them have their own video platform, they are using their user as CDN while in the mean time lowering their bitrate to a extreme even for paid content.
(to be fair, US streaming giants are probably doing it as well, the point is at different level!)

[czhou2]

Hi!

I have a few questions, if you don't mind.

1. Since you're working so deeply on video coding, what are your thoughts on this discussion regarding vvenc?

https://github.com/fraunhoferhhi/vvenc/discussions/495

VVC has far more coding tools and much higher complexity than H.264, yet it seems difficult if not impossible to achieve large gains over older codecs on the kinds of content and quality levels that matter most to ordinary users, as opposed to large-scale streaming services where delivery bandwidth and decoder compatibility have very different trade-offs.

I'm curious whether you think this is fundamentally a limitation of modern codec design, a problem with encoder implementation/optimization, or simply a consequence of the particular quality metrics and test material being used.

2. Secondly, since you appear to be from China, and presumably have some insight into the local video-coding industry: what do you think about proprietary Chinese encoders such as Taotian S26X?

According to MSU's 2025 codec comparison, it currently achieves the best results in the world under their methodology:

https://www.compression.ru/video/codec_comparison/2025/main_report.html

I'm curious why so many Chinese encoders remain completely proprietary and are never released publicly. S26X is just one example; there seem to have been dozens of Chinese encoders over the years. Is there a particular business or technical reason for this?

3. I've seen Xin26x outperform x265 in some comparisons. Do you intend to compete directly with vvenc as well?

https://github.com/fraunhoferhhi/vvenc

4. Do you have any shared cloud storage where you keep your encodes, preferably together with the original source files?

It would be interesting to inspect the actual encode/source pairs, especially for difficult content. Even a relatively small public sample would be useful.

5. Is anyone else involved in maintaining or developing Xin26x, or is it currently entirely your own project?

I'm asking partly because of the bus factor. Given how much work has obviously gone into it, I'd hate to see the project disappear if you eventually become unable to maintain it.

6. Have you ever considered accepting donations or using something like GitHub Sponsors or GoFundMe?

I'd genuinely be interested in supporting the project. One of the things I'd love to be able to do is recompress my own video collection at near-transparent quality while substantially reducing the bitrate—ideally something on the order of 2× where the source material allows it.

So far, I haven't found a modern codec/encoder combination that is particularly compelling for that use case. Perhaps AV2 will eventually be suitable, but that's still unknown.

Thanks for releasing your work, and congratulations on getting this far. Xin26x is a very interesting project.

I'm currently traveling, but I'll answer these questions once I get back. I think these are very meaningful questions.

Thank you!

[czhou2]

Hi!

I have a few questions, if you don't mind.

1. Since you're working so deeply on video coding, what are your thoughts on this discussion regarding vvenc?

https://github.com/fraunhoferhhi/vvenc/discussions/495

VVC has far more coding tools and much higher complexity than H.264, yet it seems difficult if not impossible to achieve large gains over older codecs on the kinds of content and quality levels that matter most to ordinary users, as opposed to large-scale streaming services where delivery bandwidth and decoder compatibility have very different trade-offs.

I'm curious whether you think this is fundamentally a limitation of modern codec design, a problem with encoder implementation/optimization, or simply a consequence of the particular quality metrics and test material being used.

2. Secondly, since you appear to be from China, and presumably have some insight into the local video-coding industry: what do you think about proprietary Chinese encoders such as Taotian S26X?

According to MSU's 2025 codec comparison, it currently achieves the best results in the world under their methodology:

https://www.compression.ru/video/codec_comparison/2025/main_report.html

I'm curious why so many Chinese encoders remain completely proprietary and are never released publicly. S26X is just one example; there seem to have been dozens of Chinese encoders over the years. Is there a particular business or technical reason for this?

3. I've seen Xin26x outperform x265 in some comparisons. Do you intend to compete directly with vvenc as well?

https://github.com/fraunhoferhhi/vvenc

4. Do you have any shared cloud storage where you keep your encodes, preferably together with the original source files?

It would be interesting to inspect the actual encode/source pairs, especially for difficult content. Even a relatively small public sample would be useful.

5. Is anyone else involved in maintaining or developing Xin26x, or is it currently entirely your own project?

I'm asking partly because of the bus factor. Given how much work has obviously gone into it, I'd hate to see the project disappear if you eventually become unable to maintain it.

6. Have you ever considered accepting donations or using something like GitHub Sponsors or GoFundMe?

I'd genuinely be interested in supporting the project. One of the things I'd love to be able to do is recompress my own video collection at near-transparent quality while substantially reducing the bitrate—ideally something on the order of 2× where the source material allows it.

So far, I haven't found a modern codec/encoder combination that is particularly compelling for that use case. Perhaps AV2 will eventually be suitable, but that's still unknown.

Thanks for releasing your work, and congratulations on getting this far. Xin26x is a very interesting project.

1.Compared with H.264, H.265 requires roughly four times the computational complexity while delivering about a 50% bitrate reduction. In comparison, H.266 requires roughly ten times the computational complexity of H.265, but delivers less than a 40% bitrate reduction. So, in terms of PSNR gained per unit of computational cost, the cost-effectiveness is getting worse and worse.

Personally, I think H.266 and H.265 still have some use cases in certain large-scale streaming applications, where bandwidth savings can justify the additional computational cost. However, in real-time scenarios such as RTC, people may be more inclined to use the more cost-effective H.264.

2. I've heard of S26X. Personally, I don't think Chinese developers are any better than developers elsewhere in the world. However, given my position, I don't think it's appropriate for me to comment on this publicly.

3.I have no intention of competing with VVENC. My original motivation for open-sourcing my work was simply to showcase my expertise and hopefully find a suitable job, as I’m currently unemployed. If I were currently employed, I most likely wouldn’t have made my code public. Of course, the project itself is driven by my passion for video encoding.

That said, I do think VVENC could be improved. In my view, encoders that use the reference software as their codebase are not particularly efficient in terms of memory management. There are a lot of inefficient memcpy and memset operations in the code, which can have a significant impact on performance.

4. That is a good idea. I probably will do it shortly.

5. For now, it’s basically a one-person project. A video encoder needs to be adapted and optimized for different use cases, and there are still many scenarios that Xin26x doesn’t support well enough. For example, some rate-control features are still missing. At the moment, the optimizations are also limited to x86, with no ARM-specific optimizations yet. These areas genuinely require more people and development resources to improve.

6. I’d be very happy if I could receive some funding or sponsorship to help keep the project going.

This is my personal engineering perspective on why VVC adoption has been slower than expected.
https://github.com/pigpeppa/xin26x/blob/master/docs/vvc-deployment-challenges.md
Overall, I think the challenges facing video coding are something that require experts from different fields to work together. Standardization and implementation need to evolve together. When designing new algorithms, we also need to consider implementation complexity and the overall cost-effectiveness. Some algorithms may appear relatively simple when evaluated at the C/C++ level, but that does not necessarily reflect their true complexity when implemented with SIMD.

As you mentioned, recompressing video while maintaining essentially transparent quality and significantly reducing the bitrate may be theoretically achievable. However, for a video coding standard to become widely adopted and mature, a supporting hardware ecosystem is essential. Without hardware support, it is difficult for a new coding standard to achieve broad real-world deployment.

These are just my personal opinions, and I’m always happy to discuss and exchange ideas with everyone.

[Z2697]

[COLOR="Red"]1.Compared with H.264, H.265 requires roughly four times the computational complexity while delivering about a 50% bitrate reduction. In comparison, H.266 requires roughly ten times the computational complexity of H.265, but delivers less than a 40% bitrate reduction. So, in terms of PSNR gained per unit of computational cost, the cost-effectiveness is getting worse and worse.

The feature scale* plays an important role.
It's not even that easy to get the 50% reduction of H.265 in 1080p videos, and if H.264 with 8x8 DCT is "good enough" for 1920x1080p, then H.265 with 32x32 DCT is "good enough" for up to 7680x4320p.
So when we are not handling post-8K videos that often, the gain from (sadly) larger and larger blocks are just going to decline for sure.

*I don't want to refer to it as resolution, think about the idea of having a same image at 1080p and 4k vs. stack 4 1080p image to get 4k, the scale of the features in the image is different in former but the same in latter. (copy-pasted this part because it's on another page)

[GeoffreyA]

The feature scale* plays an important role.
It's not even that easy to get the 50% reduction of H.265 in 1080p videos, and if H.264 with 8x8 DCT is "good enough" for 1920x1080p, then H.265 with 32x32 DCT is "good enough" for up to 7680x4320p.
So when we are not handling post-8K videos that often, the gain from (sadly) larger and larger blocks are just going to decline for sure.

*I don't want to refer to it as resolution, think about the idea of having a same image at 1080p and 4k vs. stack 4 1080p image to get 4k, the scale of the features in the image is different in former but the same in latter. (copy-pasted this part because it's on another page)

As we reach the biological limit of our eyes, which, as I understand, can't resolve much more than 4K, the traditional method of throwing scale and compute at encoding will grow futile, if it hasn't already done so. Some radical new techniques are wanted; or, perhaps, it is the nature of the information that it can't be compressed more. Hence, the contemporary trend of denoising, generation, and so on.