x266 VVC Encoder

[birdie]

Development is already underway (https://multicorewareinc.com/x266-a-state-of-the-art-open-source-code-for-vvc-encoding-by-multicoreware-inc/):

MulticoreWare announces the formation of x266 consortium and development of an open source code for VVC encoding is already underway. Similarly, MulticoreWare’s x265 consortium led the development of the open source code x265 for HEVC based encoding and become the mmost widely used HEVC encoding software.

Application areas of x266 will include encoding High Definition(HD) and Ultra High Definition(UHD- 4K and 8K) video for broadcasting, live streaming, Over The Top(OTT) video distribution, Adaptive Bit Rate(ABR) streaming, video storage and archiving, surveillance, screen content sharing, video teleconferencing, video games, eSports, immersive media such as 360-degree video, Virtual Reality (VR) etc.

x266 will be able to encode video with Standard, High Dynamic Range and Wide Color Gamut. It will also offer a user flexibility to trade-off speed of encoding with coding efficiency. Initial version of the x266 software will support single layer coding of 10 bits video with 4:2:0 chroma format. More advanced versions will support multilayer coding, higher than 10 bits depth video and higher than 4:2:0 chroma formats.

[FranceBB]

Great news!! :D

[microchip8]

Awesome!

[Greenhorn]

Hopefully, this will get off to a good start; the availability of a genuinely good encoder seems like it'll be critical for VVC.

[ksec]

Hopefully x265 and x266 being developed by the same team would speed things up a little bit.

What that means is that we could see EVC, VVC and AV2 Encoder all appearing within a year.

[hajj_3]

What that means is that we could see EVC, VVC and AV2 Encoder all appearing within a year.

AV2? That would be a bad idea as it would make it less likely for AV1 to receive mass adoption. They should wait 2.5yrs more to ratify AV2.

Also lots of patents will have expired over 5yrs since AV1 was ratified it they wait.

[ksec]

AV2? That would be a bad idea as it would make it less likely for AV1 to receive mass adoption. They should wait 2.5yrs more to ratify AV2.

Also lots of patents will have expired over 5yrs since AV1 was ratified it they wait.

Yes..... and the originally schedule for AV2 is 2020. And AV1 was suppose to be 2017....

They sure should take their time to ratify, but who knows.

[FranceBB]

Hopefully x265 and x266 being developed by the same team would speed things up a little bit.

Yep, that's the idea.
I really hope it will be ready for 2021. That would be great.

(On the other hand, it would mean that now I don't have any excuses not to buy a new CPU...)

Speaking of new hardware, what about decoding support? Is there anything in program? Like new gen GPUs?

[birdie]

To be honest I'm a lot more excited by VVC than AV1. The former looks like a codec which will be embraced by the scene and which will be viable for end users. AV1 is so computationally expensive it's suitable only for Google with their insane compute resources. SVT-AV1 is fast and ... blurry at all presets. Of course, patents and everything, only it doesn't matter for your personal archival purposes.

Also, AV1/H.265/VP9 basically offer nothing/very little vs. H.264 in terms of transparent near-lossless compression where H.264 is still the king. I wonder if H.266 could change that.

[hajj_3]

(On the other hand, it would mean that now I don't have any excuses not to buy a new CPU...)

Now is a bad time to buy a new cpu. AMD's zen 3 cpu's are going to be released soon, i'd wait until then before buying.

Speaking of new hardware, what about decoding support? Is there anything in program? Like new gen GPUs?

VVC was only ratified recently, it will likely take 1.5-2.5yrs for hardware decoders to ship in apu's or gpu's. So not likely until 2022.

[tnti]

Hope that there is something new in the rate control algorithm of X266.

[Cary Knoop]

Is VCC specced to support floating point code values?

[benwaggoner]

Hope that there is something new in the rate control algorithm of X266.
Like what?

[tnti]

Like what?

You should understand Alibaba's S265 encoder.

[benwaggoner]

You should understand Alibaba's S265 encoder.
What about it? Is there a particular rate control feature you'd like to see adopted elsewhere? If so, can you provide details?

[tnti]

What about it? Is there a particular rate control feature you'd like to see adopted elsewhere? If so, can you provide details?

https://www.livevideostack.cn/news/taobao-hevc-h265-cdn-rtc/
Sorry, there is no English version of the PPT.

[benwaggoner]

https://www.livevideostack.cn/news/taobao-hevc-h265-cdn-rtc/
Sorry, there is no English version of the PPT.
Can you offer a summary? I can't read Chinese, nor can most of us here.

[quietvoid]

Does anyone have more info about this repo here: https://github.com/chenm001/x266
Looks like just a research implementation but curious.

[FranceBB]

Does anyone have more info about this repo here: https://github.com/chenm001/x266
Looks like just a research implementation but curious.

The last release says "on Oct 21, 2017" when the standard wasn't even remotely a thing and was so far away from being finalized. I don't think it's something official nor from Multicoreware...

[tnti]

Does anyone have more info about this repo here: https://github.com/chenm001/x266
Looks like just a research implementation but curious.

Min Chen temporarily has no time to maintain this open source project.
I asked about this in July 2020.:sly:

[chenm001]

Min Chen temporarily has no time to maintain this open source project.
I asked about this in July 2020.:sly:

I have enough time since September 2020, I focus on my x266 encoder and decoder after that.

[chenm001]

Does anyone have more info about this repo here: https://github.com/chenm001/x266
Looks like just a research implementation but curious.

Thank you interesting of my projects.

That is my research tree, the goal is a hybrid video processing system since HEVC is a little complicated and WC almost can't be implemented as a real world product.
So I think software as a framework with hardware acceleration components is a good idea.

However, my previous employer is a China company, they almost prohibit any spare time work, either related to company products or unrelated.
As a result, my project has been frozen for almost 2 years, it is unfreezing now because I am unemployed since September 2020, I can continue to contribute to my projects.

[chenm001]

The last release says "on Oct 21, 2017" when the standard wasn't even remotely a thing and was so far away from being finalized. I don't think it's something official nor from Multicoreware...

It is not related to Multicoreware, it is my research tree...

[FranceBB]

It is not related to Multicoreware, it is my research tree...

Oh, ok, got it. I was asking 'cause I know Multicoreware was working on x266 and I would have been surprised to find the repository on GitHub out of the blue, just like that.


However, my previous employer is a China company, they almost prohibit any spare time work, either related to company products or unrelated.
As a result, my project has been frozen for almost 2 years, it is unfreezing now because I am unemployed since September 2020, I can continue to contribute to my projects.

Oh... Sorry to hear that, man...
I hope you'll find something else.
By the way, I didn't know that Chinese companies had such strict regulations... but I guess I should have expected that, given that they banned pretty much everything on the internet...
Anyway, take care, I'm sure you'll find another job.

[chenm001]

Oh, ok, got it. I was asking 'cause I know Multicoreware was working on x266 and I would have been surprised to find the repository on GitHub out of the blue, just like that.



Oh... Sorry to hear that, man...
I hope you'll find something else.
By the way, I didn't know that Chinese companies had such strict regulations... but I guess I should have expected that, given that they banned pretty much everything on the internet...
Anyway, take care, I'm sure you'll find another job.

Thank you.
I guess most China companies want t share nothing, no idea.

btw: Based on the Multicoreware scramble for x266 registering trademarks, I maybe rename my x266 to m266 or similar.
However, the project name is not important, I will still focus on make a really world high performance encoder and decoder products.

[tnti]

Thank you.
I guess most China companies want t share nothing, no idea.

btw: Based on the Multicoreware scramble for x266 registering trademarks, I maybe rename my x266 to m266 or similar.
However, the project name is not important, I will still focus on make a really world high performance encoder and decoder products.

According to past practice, it should be named T26X.：:stupid:

[soresu]

Hopefully x265 and x266 being developed by the same team would speed things up a little bit.

What that means is that we could see EVC, VVC and AV2 Encoder all appearing within a year.

AV2 is in deep dev mode at the moment but nowhere near finished at this point from what I gather from the commits on the AOM experimental branch.

I'd be surprised if we saw it even in 2022, more likely 2023 at the earliest?

[soresu]

To be honest I'm a lot more excited by VVC than AV1. The former looks like a codec which will be embraced by the scene and which will be viable for end users. AV1 is so computationally expensive it's suitable only for Google with their insane compute resources. SVT-AV1 is fast and ... blurry at all presets. Of course, patents and everything, only it doesn't matter for your personal archival purposes.

Also, AV1/H.265/VP9 basically offer nothing/very little vs. H.264 in terms of transparent near-lossless compression where H.264 is still the king. I wonder if H.266 could change that.

From what I gather on the AV1 discord libaom has come on in leaps and bounds in both speed and memory consumption since SVT AV1 came out guns blazing on the speed front.

As for near lossless compression - I don't think that this is an aspect of the codec standard so much as the implementation.

x264 had an insane level of focus on replacing XviD at all levels, and it did eventually do that by about 2010/11 timeframe from what I remember - I think that this focus was the real reason that x264 is still the high bitrate king of the OSS encoders.

I've seen benchmarks that show x265 isn't even the best H265/HEVC encoder out there (HW265 was it?), so it seems there is definitely room for improvement.

II think that the rav1e people are focused on being a true open source x264 successor in terms of quality in their endgame, although it will probably take until well past the release of AV2 to reach that goal.

[benwaggoner]

"Best" is a very subjective word! For streaming, "transparent near-lossless compression" is a nice aspiration, but the focus is on "best quality within available bandwidth." Near lossless is more for content usable as source for additional reencoding, like ProRes, as a term of art.

The Beamr HEVC encoder is general thought of the highest quality option these days. Not sure what HW265 is.

Does rav1e have a team focused on psychovisual optimization algorithms? I wasn't sure what's happening with them after all the Mozilla layoffs.

It's amazing how influential x265's "Rate Factor" has been; we see --crf equivalents or straight --crf popping up all over the place these days. With the complexity of AV1 and VVC, I want to think that there are deeper ways to take advantage of the new codec features. Actual QP is less important any many ways given the novel ways that artifacts are suppressed. VVC's ability to encode high-QP motion without any block pattern becoming apparent is a game changer.

[Losko]

I stumbled upon this:
https://github.com/fraunhoferhhi/vvenc
Pure C++, open source (but I didn't read the license yet) and cross platform: looks promising!

[benwaggoner]

I stumbled upon this:
https://github.com/fraunhoferhhi/vvenc
Pure C++, open source (but I didn't read the license yet) and cross platform: looks promising!
Yeah, definitely more practical performance than the reference encoder. Although the efficiency hit from multithreading is quite high. It's probably better for making test streams than in demonstrating potential bitrate savings versus other codecs, at least so far. Fraunhofer has a history of making good quality encoders.

[PCU]

Friends, what format do you think Google will use in the future: H.266 or AV1?
Please compare: Elecard/MainConcept H.266 with x266.

[nevcairiel]

With Google, you mean YouTube? I don't think they are likely to adopt a brand new MPEG codec, they have avoided HEVC entirely and only begrudgingly offer H.264 as a fallback when VP9 isn't available.

[PCU]

With Google, you mean YouTube? I don't think they are likely to adopt a brand new MPEG codec, they have avoided HEVC entirely and only begrudgingly offer H.264 as a fallback when VP9 isn't available.

What about: Facebook, Twitter, Instagram?

[birdie]

What about: Facebook, Twitter, Instagram?

As far as I know there are no representatives of these companies here on these forums, so unlikely anyone could give you a definitive answer.

[FranceBB]

As far as I know there are no representatives of these companies here on these forums, so unlikely anyone could give you a definitive answer.

Which is a shame. :(
On the other hand, we know that Facebook is still stuck on H.264 and it won't allow anything over HD 30p.
So for instance I generally record simple 3840x2160 60p videos in H.265 100 Mbits with my phone. If I upload them to Facebook they will be downscaled to 1280x720 using a simple Bicubic as resizing kernel, frames will be dropped to 30p and it will be re-encoded to low bitrate H.264.
This is nowhere near what a user expects in 2021.
We've been complaining a lot about YouTube and the fact that videos are low bitrate, 8bit only and full of banding, but at least you can upload up to 8K 60p there and if you upload HLG or PQ it will be preserved and passed through to supported devices (while showing a puny LUT conversion on SDR ones). I mean, this is at least something. Facebook on the other hand is simply ridiculous, but I think they don't care as 95% of their users is using Mobile Phones on relatively poor networks and tiny displays so they don't care... :(

[ksec]

Facebook is pretty much Anti-MPEG, or at least certain SVP seems to be this way. Twitter doesn't really care about these sort of thing. They have never even participate in the input of any codec discussion, on or offline AFAIK. Instagram tends to follow Facebook, although both Facebook and Instagram is supporting JPEG XL rather than AVIF so at least they seems to be pragmatic about it rather than ideological.

At the end of the day I think ( or I would like to think ) it really is some market force and business decisions. With Apple now supporting VP9 via partial hardware acceleration, and I would imagine better hardware acceleration in the future ( No one has tested the new Hardware Decoder Block on A15 yet ), may be VP9 HDR will be fully hardware accelerated.

Note: Some "site" decide to label Apple as supporting AV1 hardware acceleration and gave zero fact or evidence that is the case, and somehow someone continuously edit this information to be included as fact on wiki.

Modern Internet Video Giant like Facebook and Youtube now have different set of priorities most may not realise. Bandwidth Cost is falling, and it is falling faster than we expected. With enough peering, bandwidth is quite literally free. ( Cloudflare's CEO made this point very very clear. ) It is storage and compute that are now the cost centre. Storage prices hasn't moved at all. And Compute hasn't gotten faster anywhere near the complexity of a new codec. Introducing a new codec means adding another storage cost for every video they have. For Netflix, they can afford to re-encode their whole catalog every three months just to gain on additional image quality via encoder improvement. Their priorities are very different to Facebook or Youtube. But Netflix doesn't like MPEG. Or at least their engineers doesn't like it due to patents and royalty.

Basically we might very well end up with something similar to what we currently have. H.264 and HEVC / VP9.

I would love to be wrong though since I quite like what VVC is showing so far. But the patent pool situation from VVC, MPEG-LA has yet to announce their pricing, 10 months after their initial announcement.

That is from Internet Video Companies perspective. From broadcasting, I gather the industry is quite excited especially those from Asia.

[benwaggoner]

Friends, what format do you think Google will use in the future: H.266 or AV1?
Please compare: Elecard/MainConcept H.266 with x266.
Google was a founder of AOM and primary contributor of AV1, which started with the libvpx codebase and VP9 design. They've been vocally opposed to patent-bearing codecs for years now, and specifically coded out Chrome's support for passing HEVC decode to a system decoder.

Google's YouTube has always been the primary user of VP 7, 8, and 9, and now AV1, which they've used to drag devices into supporting their players to get access to new YouTube quality tiers.

I think it is very safe to assume that Google will continue to support AV1, and will work hard to make AV2 the next big codec. It would be a profound about-face for them to even allow VVC to be decodable in Chrome, let alone actually publish content using it.

[PCU]

Google was a founder of AOM and primary contributor of AV1, which started with the libvpx codebase and VP9 design. They've been vocally opposed to patent-bearing codecs for years now, and specifically coded out Chrome's support for passing HEVC decode to a system decoder.

Google's YouTube has always been the primary user of VP 7, 8, and 9, and now AV1, which they've used to drag devices into supporting their players to get access to new YouTube quality tiers.

I think it is very safe to assume that Google will continue to support AV1, and will work hard to make AV2 the next big codec. It would be a profound about-face for them to even allow VVC to be decodable in Chrome, let alone actually publish content using it.

Thanks.
What about Netflix & others? discs are dead these days.

[PCU]

Who do you think abandons a royalty-free codec and pays for a codec like H.266? http://www.emoticonr.com/design/yahoo/devil.gif

[birdie]

https://multicorewareinc.com/news/join-us-at-ces-2022/

Let’s Get Together at CES2022 this January in
Las Vegas



Join us at CES to learn more about our

Vision & Non-Vision (Radar, LiDAR, IMU, GPS, etc.) Sensors
Video Solutions (x266™, x265 & Ultraziq)
Human Behavior Intelligence (HBI) platform leveraging the latest AI & ML technologies &
LipSync – Video QC Tool

MulticoreWare is expertise in developing algorithms for various technologies including Camera (RGB, LWIR, ToF), Radar, Lidar, and IMUs to solve challenges in ADAS / AV sensor technology with R&D focus and on optimization of existing algorithms for edge deployment.

MulticoreWare’s industry-leading video codec products (x266™/x265/Ultraziq) have been deployed in live streaming or VOD services across many broadcast customers, video streaming services, movie studios, postproduction facilities, video system developers worldwide.

HuBe.ai – a highly scalable AI/API/SaaS Platform for all aspects of Human Behavior. With HuBe.ai, customers can accelerate the application development to track human behavior or augment existing solutions with similar functionalities to detect and identify distress/anomaly, assess people effectively in terms of communication & behavior, etc.

We also offer ML Engineering Services serving a wide group of customers with solutions like Hardware Platform Compilers & Toolchains, SDK Libraries, and Algorithm & Data Engineering solutions.

The first public unveiling of x266.

[PCU]

Guys, has anyone ever tested the x266 encoder to see if it is better than AV1 encoders or not?
Do you think the visual quality of H.266 is better than AV1?

[LigH]

It is hard to test a codec which is not available to the public.

You can test Google AV1 vs. Fraunhofer VVC. But Multicoreware x266 is not available yet, IIRC.

[FranceBB]

It is hard to test a codec which is not available to the public.

Multicoreware x266 is not available yet.

Yep, precisely.
The repository is still private and there are no builds around, let alone the source code, so no one tested it.

has anyone ever tested the x266 encoder to see if it is better than AV1 encoders or not?


The only one we did test was VVEnc by Fraunhofer, which was good enough to defeat x264 and x265 at 25 Mbit/s in UHD (you can see my tests in the VVC topic with screenshots and SSIM and the difference - especially between H.265 and H.266 was really really small, but that might be because x265 has been around for quite some time and VVEnc has not).


Do you think the visual quality of H.266 is better than AV1?


I haven't tested it against AV1, but it should be better than AV1 on paper.
Perhaps that's gonna be my next test when I'll have time.

[PCU]

Yep, precisely.
The repository is still private and there are no builds around, let alone the source code, so no one tested it.



The only one we did test was VVEnc by Fraunhofer, which was good enough to defeat x264 and x265 at 25 Mbit/s in UHD (you can see my tests in the VVC topic with screenshots and SSIM and the difference - especially between H.265 and H.266 was really really small, but that might be because x265 has been around for quite some time and VVEnc has not).



I haven't tested it against AV1, but it should be better than AV1 on paper.
Perhaps that's gonna be my next test when I'll have time.

http://www.emoticonr.com/design/yahoo/thumbs-up.gif

It is hard to test a codec which is not available to the public.

You can test Google AV1 vs. Fraunhofer VVC. But Multicoreware x266 is not available yet, IIRC.

Is the Fraunhofer free to test?

[birdie]

http://www.emoticonr.com/design/yahoo/thumbs-up.gif

Is the Fraunhofer free to test?

Would be great if you at least (https://en.wikipedia.org/wiki/Versatile_Video_Coding) visited the Wikipedia article on the matter where all the available H.266 codecs are already listed:

https://github.com/fraunhoferhhi/vvenc
https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM

Yes, they are "free" to test - what more can one ask for where the source code is freely available.

[PCU]

Would be great if you at least (https://en.wikipedia.org/wiki/Versatile_Video_Coding) visited the Wikipedia article on the matter where all the available H.266 codecs are already listed:

https://github.com/fraunhoferhhi/vvenc
https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM

Yes, they are "free" to test - what more can one ask for where the source code is freely available.

Yes, I saw the source code, but I meant exactly that, it's so weird that Fraunhofer put the source on Github, I just said I mean, can this source be used in a free program?

[LigH]

See Jamaika's XEVE (https://forum.doom9.org/showthread.php?p=1959462#post1959462) as a custom All-In-One encoder application (similar to ffmpeg) for an example...

[birdie]

Yes, I saw the source code, but I meant exactly that, it's so weird that Fraunhofer put the source on Github, I just said I mean, can this source be used in a free program?

https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/-/blob/master/COPYING

[kurkosdr]

Google was a founder of AOM and primary contributor of AV1, which started with the libvpx codebase and VP9 design. They've been vocally opposed to patent-bearing codecs for years now, and specifically coded out Chrome's support for passing HEVC decode to a system decoder.

Google's YouTube has always been the primary user of VP 7, 8, and 9, and now AV1, which they've used to drag devices into supporting their players to get access to new YouTube quality tiers.

I think it is very safe to assume that Google will continue to support AV1, and will work hard to make AV2 the next big codec. It would be a profound about-face for them to even allow VVC to be decodable in Chrome, let alone actually publish content using it.

If I may add, the majority of websites have historically avoided patented formats that come with "content fees" so they won't have to pay said "content fees" for every picture or video they distribute (which can be a problem considering how thin per-content profit margins are for web content available as free-to-view/ad-supported). It's the reason why there was almost no web content encoded in JPEG2000, Mpeg2 or Mpeg4 ASP in the past. Websites just used good old JPEG for pictures and for video they used Cinepak (and after that WMV or Quicktime, often both in order to effortlessly serve both Windows and Mac).

In addition, browser vendors that offer their browsers as free downloads (such as Mozilla and Google) avoid patented codecs so they won't have to pay a "decoder fee" with every download. Sure, they could use the system codecs where available, but the "where available" part causes an inconsistent experience. Also, blocking system codecs is a form of "gatekeeping" to keep patented codecs out of the web so they won't have to be dragged into paying "decoder fees" later.

If you think about it, H.264 was the exception to the rule, the only ISO video compression standard to be widely used in the web. Firstly because it blew everything out of the water at the time in terms of efficiency, secondly because it had hardware acceleration in almost every computer (if not full, at least assisted) back when full software decoding was still an issue on low-powered PCs, and thirdly because it was imposed on browser vendors by the proprietary Adobe Flash plugin (which meant browser vendors couldn't "gatekeep" it out of their browsers).

None of these conditions apply today. Someone needs to break it to H.265 and H.266 patent holders that they aren't getting the kind of windfall they did from H.264 patents. This includes Apple.

[kurkosdr]

We've been complaining a lot about YouTube and the fact that videos are low bitrate, 8bit only and full of banding, but at least you can upload up to 8K 60p there and if you upload HLG or PQ it will be preserved and passed through to supported devices (while showing a puny LUT conversion on SDR ones). I mean, this is at least something.(

Wait, 8-bit HLG is something that's actually done in the wild? Does it mean we could get HLG on TV channels in Europe? Here in Europe, I doubt we 'll get more than 2-3 UHD channels per country, considering some countries are still trying to fully get out of Mpeg2 SD and that UHD requires double the bitrate compared to HD (even when H.265 is used). So, if someone could work HLG into 8-bit to retrofit all those HD H.264 channels with HLG, that would be great.

Also, how does the signalling work so the decoder won't decode it as SDR in YouTube? Is it at the stream level or at the container level?

[FranceBB]

Wait, 8-bit HLG is something that's actually done in the wild?

Only by Sony cameras like the Sony A7 III as it's technically not compliant.
TL;DR you cannot go on air in 8bit in UHD.



Does it mean we could get HLG on TV channels in Europe?


There are already UHD channels in Europe.
For instance, at Sky we've been airing in UHD BT2020 SDR in H.265 4:2:0 25 Mbit/s 10bit planar since 2015 and in UHD BT2020 HDR HLG 4:2:0 25 Mbit/s 10bit planar since 2018. And not just Sports, but also Cinema (so movies).




Here in Europe, I doubt we 'll get more than 2-3 UHD channels per country


The problem ain't UHD, the problem is the fact that Hotbird is overcrowded and bitrate is expensive as f...





considering some countries are still trying to fully get out of Mpeg2 SD


This is an issue everywhere...
If I get a content, I have to encode an SD version, a FULL HD version and a UHD version as we have the same channels on air with 3 different codecs and 3 different resolutions.
This is a huge waste of bitrate.
My biggest satisfaction would be to see all the SD channels shut down one day, 'cause this is a problem for lots and lots of broadcasters...


if someone could work HLG into 8-bit to retrofit all those HD H.264 channels with HLG, that would be great.


Not gonna happen, not with H.264, not in 8bit, not in HLG.
That's just Sony's poor hardware trying to squeeze the best out of it with 8bit Full Range HLG in H.264.


Also, how does the signalling work so the decoder won't decode it as SDR in YouTube? Is it at the stream level or at the container level?

In linear channels?
The encoded stream is correctly flagged as arib-std-b67 and with the color matrix BT2020. Those channels are backwards compatible with BT2020 SDR TVs.

[benwaggoner]

If I may add, the majority of websites have historically avoided patented formats that come with "content fees" so they won't have to pay said "content fees" for every picture or video they distribute (which can be a problem considering how thin per-content profit margins are for web content available as free-to-view/ad-supported). It's the reason why there was almost no web content encoded in JPEG2000, Mpeg2 or Mpeg4 ASP in the past. Websites just used good old JPEG for pictures and for video they used Cinepak (and after that WMV or Quicktime, often both in order to effortlessly serve both Windows and Mac).
Cinepak got used because it was the first universal video codec. There weren't any content fees for any good codecs on Mac/PC back then.
J2K required much more compute for relatively minor efficiency improvements over JPEG.
Neither MPEG-2 or MPEG-4 ASP were quality-competitive against the best streaming codecs of their era.
MPEG-4 ASP decode became pretty universal pretty quickly. I wrote a DV Magazine article about using it as a universal codec for Robert X. Cringley's web site back in the late 90's.

One certainly can argue that IP concerns about J2K, MPEG-2, and MP4ASP slowed down development that prevented competitive implementations from emerging. But I can't think of any format that was abandoned due to distribution licensing concerns. Encoder licensing concerns arguably killed VP6 for Flash, with YouTube skipping straight from H.263 to H.264.

In addition, browser vendors that offer their browsers as free downloads (such as Mozilla and Google) avoid patented codecs so they won't have to pay a "decoder fee" with every download. Sure, they could use the system codecs where available, but the "where available" part causes an inconsistent experience. Also, blocking system codecs is a form of "gatekeeping" to keep patented codecs out of the web so they won't have to be dragged into paying "decoder fees" later.
Chrome and Firefox do "pass to system decoder" perfectly well for H.264. What I spoke of was their explicitly disabling HEVC support to prop up less technically competitive alternatives for ideological reasons. Which has largely meant H.264 and very little HDR on the desktop.

If you think about it, H.264 was the exception to the rule, the only ISO video compression standard to be widely used in the web. Firstly because it blew everything out of the water at the time in terms of efficiency, secondly because it had hardware acceleration in almost every computer (if not full, at least assisted) back when full software decoding was still an issue on low-powered PCs, and thirdly because it was imposed on browser vendors by the proprietary Adobe Flash plugin (which meant browser vendors couldn't "gatekeep" it out of their browsers).
H.264 become the dominant web codec well before HW decoding became universal. That's why x264 has --tune fastdecode. The MPEG design process prioritizes low decoder complexity increases versus efficiency gains, which helped a lot. Early H.264 on the web was all Baseline profile, and SW decode was a pretty reasonable lift. After a few years of Moore's Law, Main and High profiles became viable. Sure MP4-ASP and WMV3 were somewhat faster per-pixel, but only somewhat, so the efficiency gains of H.264 made the difference. Still, a well-tuned VC1 AP was well matched with H.264 Baseline in the mid aughts. x264 was really H.264's killer feature. It's hard to beat the development power of hundreds of quality and speed obsessed piracy groups around the world working with lots of different kinds of content. Once --cutree was introduced and VC1 encoder development largely ceased (~2009?) x264 pulled farther and farther away.

None of these conditions apply today. Someone needs to break it to H.265 and H.266 patent holders that they aren't getting the kind of windfall they did from H.264 patents. This includes Apple.
It really depends by market. HEVC, H.264, and MPEG-2 all made patent holders buckets of money (MPEG-2 most of all). Not that much premium content is played in browsers on Mac/Windows. TV and phone companies, cable companies, etc are very comfortable with paying additional codec licensing fees in return for a very high standard of interoperability and 2x better compression efficiency. VVC clearly has the compression efficiency improvements vital to those industries, and a "good enough" licensing regime will be successful, even if it isn't suitable for non-DRM web content.

For all the "HEVC is dead!" claims, a huge amount of content is watched in HEVC with hardware decoders, including nearly all HDR premium content.

[Blue_MiSfit]

For all the "HEVC is dead!" claims, a huge amount of content is watched in HEVC with hardware decoders, including nearly all HDR premium content.

QFT.

Lots of UHD streaming happening from premium services in the last 6 years like Netflix, Disney+, Amazon Prime, Hulu, iTunes, VUDU, Movies Anywhere etc. The common thread? HEVC :)

[kurkosdr]

Cinepak got used because it was the first universal video codec. There weren't any content fees for any good codecs on Mac/PC back then.
J2K required much more compute for relatively minor efficiency improvements over JPEG.
Neither MPEG-2 or MPEG-4 ASP were quality-competitive against the best streaming codecs of their era.
MPEG-4 ASP decode became pretty universal pretty quickly. I wrote a DV Magazine article about using it as a universal codec for Robert X. Cringley's web site back in the late 90's.

One certainly can argue that IP concerns about J2K, MPEG-2, and MP4ASP slowed down development that prevented competitive implementations from emerging. But I can't think of any format that was abandoned due to distribution licensing concerns. Encoder licensing concerns arguably killed VP6 for Flash, with YouTube skipping straight from H.263 to H.264.
Ok, I agree that the situation with JPEG2000 and MPEG-2 is murky, but MPEG-4 ASP failed due to licensing concerns. Windows XP didn't provide codecs for it to avoid a "decoder fee", browsers didn't provide codecs for it for the same reason, websites didn't touch it due to the dreaded "content fee" (https://blog.chiariglione.org/the-impact-of-mpeg-standards/) and used WMV and QT instead. I haven't seen a single video on the web (from a non-pirate page) that used MPEG-4 ASP. Pirates used it because, when you are distributing unauthorized copies of the latest Disney movie, content fees are the least of your worries as far as legality is concerned.

BTW I can think of a format that was abandoned due to distribution licensing concerns: H.264, which was abandoned from YouTube, the biggest online video platform. And HEVC, which was abandoned from YouTube before it even got adopted. Yes, "content fees" matter to platforms like YouTube. And "decoder fees" matter for browser vendors. Netflix also avoids streaming H.264 or HEVC if they can stream AV1.


Chrome and Firefox do "pass to system decoder" perfectly well for H.264.
Yes, they do pass H.264 to system decoder because they also provide an H.264 decoder, so there is no inconsistency (at least for Chrome).

What I spoke of was their explicitly disabling HEVC support to prop up less technically competitive alternatives for ideological reasons.
To which I say: Thank you Mozilla and Google! I don't want to pay for the HEVC patent thicket every time I download a browser (or indirectly every time I watch a free video), not when a good-enough alternative exists. Nor do I want to have family and relatives asking me about codec packs and where to find them. Also, we can't count on Google to subsidize the HEVC patent thicket payments for Chrome like they do for H.264. It's just silly from a financial perspective. AV1 is good-enough. Thanks to all the patents that expired during the last 20 years, we don't need MPEG anymore in order to have an open video format that allows for decent encoders. That's why the patent holders behind HEVC have a sad (https://blog.chiariglione.org/a-crisis-the-causes-and-a-solution/).


Which has largely meant H.264 and very little HDR on the desktop.

AV1 supports 10-bit and HDR.


For all the "HEVC is dead!" claims, a huge amount of content is watched in HEVC with hardware decoders, including nearly all HDR premium content.
Good for them, considering they are charging for every piece of content they show. The web is just fine with AV1 and doesn't have to pay any "content fee" or "decoder fee". Thank you Google and Mozilla for making it happen.

[lvqcl]

h.264, which was abandoned from youtube
wdym?

[lvqcl]

(Why did the forum software change all text to lowercase in my previous post?)

[kurkosdr]

H.264, which was abandoned from YouTube.

wdym?

YouTube is all VP9 and AV1 nowadays, with VP8 for backwards compatibility. You can probably get YouTube to serve a 720p H.264 stream as a "last resort" extreme backward compatibility stream, but I don't know if they even do that anymore.

In the past, YouTube was all H.264 for 720p and 1080p.

[benwaggoner]

BTW I can think of a format that was abandoned due to distribution licensing concerns: H.264, which was abandoned from YouTube, the biggest online video platform. And HEVC, which was abandoned from YouTube before it even got adopted. Yes, "content fees" matter to platforms like YouTube. And "decoder fees" matter for browser vendors. Netflix also avoids streaming H.264 or HEVC if they can stream AV1.
YouTube still serves tons of H.264. That's all that Apple devices get, IIRC, among others. It has been deemphasized, but certainly not abandoned. H.264 is likely to remain the only universally supported bitstream in browsers & hardware decoders for 5+ more years.

HEVC is pretty much universally supported in current HW decoders, although there are people still using older devices without it, particularly for things like TVs with slower refresh cycles. I'm not aware of anyone shipping a mobile devices without HW HEVC support for several years now.

Yes, they do pass H.264 to system decoder because they also provide an H.264 decoder, so there is no inconsistency (at least for Chrome).
In our ABR multi-codec world, "consistency" hasn't been a big factor for a long time. It's pretty rare someone watches an imbedded .mp4 these days.

To which I say: Thank you Mozilla and Google! I don't want to pay for the HEVC patent thicket every time I download a browser (or indirectly every time I watch a free video), not when a good-enough alternative exists. Nor do I want to have family and relatives asking me about codec packs and where to find them. Also, we can't count on Google to subsidize the HEVC patent thicket payments for Chrome like they do for H.264. It's just silly from a financial perspective. AV1 is good-enough. Thanks to all the patents that expired during the last 20 years, we don't need MPEG anymore in order to have an open video format that allows for decent encoders. That's why the patent holders behind HEVC have a sad (https://blog.chiariglione.org/a-crisis-the-causes-and-a-solution/).
There would be no cost to Google or Mozilla to support passthrough to HEVC decode. I don't know there would be any distribution fee at all. That does reiterate the problems with HEVC licensing - it's not like there's a single source of truth to figure out what you have to pay for doing what, and what you don't have to pay for at all. For H.264, MPEG-LA had a nice PowerPoint summary available to the public.

Oh, there are certainly costs to not supporting HEVC. Bandwidth consumption has been higher than needed for a given quality for years now. Browser and PC HDR is years behind where it could have been. 4K on PC is years behind where it could have been.

Software decoders are fine for short-form user-generated content. But they don't have the DRM robustness for premium 4K or HDR content, which is why that's almost entirely viewed on other kinds of devices that have HW decoders. SW decoders also eat more power, and there are absolutely devices that could have played a 2 hour movie in HW HEVC that will run out of battery before hitting 2 hours in SW AV1.

Globally, the aggerate impact of all those computers burning watts to decode software codecs on YouTube despite HW decoders being available has been ballparked as several MW.

AV1 supports 10-bit and HDR.
Nominally. But 10-bit decode is still materially slower/more power hungry than 8-bit in current mainstream released browsers. And what's your favorite AV1 encoder well-tuned for HDR-10 encoding using the PQ EOTF? I've not found any that are actually competitive with HEVC encoders form three years ago, let alone state of the art.

Good for them, considering they are charging for every piece of content they show. The web is just fine with AV1 and doesn't have to pay any "content fee" or "decoder fee". Thank you Google and Mozilla for making it happen.
The web is highly diverse. And viewership of streaming services in browsers has been dropping rapidly year-on-year. A big reason why Netflix et al have been pushing people to use apps over browsers is that they can HEVC, HDR, DD+ audio, and other media technologies they can't from a browser.

[kurkosdr]

YouTube still serves tons of H.264. That's all that Apple devices get, IIRC, among others. It has been deemphasized, but certainly not abandoned. H.264 is likely to remain the only universally supported bitstream in browsers & hardware decoders for 5+ more years.
Even Apple has begrudgingly started supporting VP9 on newer devices. So, for YouTube, H.264 is indeed a "last resort" compatibility stream wherever VP8, VP9 or AV1 cannot be used. Funny what happens when the biggest online video provider (aka YouTube) says "sorry Apple, I will not pay content fees towards your HEVC patent thicket and I will use an alternative standard instead". Did I say "thank you Google" already?

All Apple achieves by refusing to support AV1 is making their product offerings a bit worse. Their problem not ours.


HEVC is pretty much universally supported in current HW decoders, although there are people still using older devices without it, particularly for things like TVs with slower refresh cycles. I'm not aware of anyone shipping a mobile devices without HW HEVC support for several years now.

(and)

Oh, there are certainly costs to not supporting HEVC. Bandwidth consumption has been higher than needed for a given quality for years now. Browser and PC HDR is years behind where it could have been. 4K on PC is years behind where it could have been.

Software decoders are fine for short-form user-generated content. But they don't have the DRM robustness for premium 4K or HDR content, which is why that's almost entirely viewed on other kinds of devices that have HW decoders. SW decoders also eat more power, and there are absolutely devices that could have played a 2 hour movie in HW HEVC that will run out of battery before hitting 2 hours in SW AV1.

Globally, the aggerate impact of all those computers burning watts to decode software codecs on YouTube despite HW decoders being available has been ballparked as several MW.

All of them temporary problems now that VP9 and AV1 have wide industry support and ship on new devices. Also, the aggregate MWs are a red herring: the watt impact per person is small. I don't see why any of this stuff justifies paying content fees for the next two decades just to have video on the world wide web. Premium services can do whatever they want. These services charge for the content, so they can presumably pay the content fees (though Netflix streams AV1 wherever possible, since AV1 achieves at least bitrate parity with HEVC and has no content fees, which means the economics work in favour of AV1). I want the ability to have video on YouTube (or a site some startup has made) without the website having to pay to the HEVC patent thicket (or the H.264 patent thicket) any content fees. Or me having to pay to download the browser. Or having to care about "system codecs". Which brings me to...


In our ABR multi-codec world, "consistency" hasn't been a big factor for a long time. It's pretty rare someone watches an imbedded .mp4 these days.

(and)

There would be no cost to Google or Mozilla to support passthrough to HEVC decode.
There is a cost in that users of the browser will have to deal with system codecs, which for most users is rarely fun (videos that work on one computer won't work on another, on the same browser and version, try explain that to people!). That's what I mean by "consistency". The product (browser) won't be consistent across computers. It's the reason Chrome was forced to implement H.264 despite H.264 system codecs being a thing. And you know services from Apple will exclusively use HEVC just to force every browser to implement it, so they can the collect those sweet fees. In contrast, anyone can ship a browser with a software VP8, VP9 and AV1 decoder without any fees and have videos work on every computer the browser runs on.


Nominally. But 10-bit decode is still materially slower/more power hungry than 8-bit in current mainstream released browsers. And what's your favorite AV1 encoder well-tuned for HDR-10 encoding using the PQ EOTF? I've not found any that are actually competitive with HEVC encoders form three years ago, let alone state of the art.
If you want perfectly-tuned HDR for your 90" OLED 8K StratoDef TV then download the app and pay for the content. On the web, the ability to implement standards without paying fees (and the resulting consistency from not having to pay fees) is valued more than perfectly-tuned HDR (or DD+ for that matter). The web can do just fine with "good enough" AV1 HDR10+ and HLG. It already does.


The web is highly diverse. And viewership of streaming services in browsers has been dropping rapidly year-on-year. A big reason why Netflix et al have been pushing people to use apps over browsers is that they can HEVC, HDR, DD+ audio, and other media technologies they can't from a browser.

At this point, it's impossible for the web to keep premium services happy. You give them Widevine (so they supposedly won't move to apps), they ask for more DRM. If you give them that, then they'll ask for HEVC. And then for something else.

So, why bother? Just let those premium services have their apps and deliver a more plain service on the web.


I don't know there would be any distribution fee at all.

Hmm, let me see... There are content fees for Mpeg 4 ASP, there are content fees for H.264 (no, I don't care if it was waived for a small number of years as part of a promotion), but somehow, magically, there is even a snowball's chance in hell there won't be content fees for HEVC, despite the patent owners having gotten more aggressive to the point the can't even form a common patent pool anymore... Why does the web need this mess? To satisfy some people complaining about HDR tuning? Nah, just give those people AV1 HDR10+ or HLG and tell them to bugger off.


That does reiterate the problems with HEVC licensing - it's not like there's a single source of truth to figure out what you have to pay for doing what, and what you don't have to pay for at all. For H.264, MPEG-LA had a nice PowerPoint summary available to the public.

Again, why does the web need this mess? How is it compatible with the open nature of web standards? It's not.

[kurkosdr]

Only by Sony cameras like the Sony A7 III as it's technically not compliant.
TL;DR you cannot go on air in 8bit in UHD.
I had a second look at HLG3 footage, and indeed it looks as flat as S-log, so most SDR viewers probably won't be able to stomach it if you were to feed it to a broadcast H.264 stream. So even if you could software-upgrade HDR TVs to recognise HLG3 somehow, it's still out of the question due to how bad it looks on SDR displays.

I guess most H.264 HD channels will do tone-mapped content (from HDR) and call it a day. Which means the handling of tone-mapped content will be a big differentiator for consumer HDR TVs for the years to come, much like the quality of upscaling and denoising of mpeg2 SD channels was a big differentiator for early consumer HD TVs (and still is in some countries like the UK, which has 12 HD channels and several dozen Mpeg2 SD ones, all of them at crappy bitrates).


There are already UHD channels in Europe.
For instance, at Sky we've been airing in UHD BT2020 SDR in H.265 4:2:0 25 Mbit/s 10bit planar since 2015 and in UHD BT2020 HDR HLG 4:2:0 25 Mbit/s 10bit planar since 2018. And not just Sports, but also Cinema (so movies).

The problem ain't UHD, the problem is the fact that Hotbird is overcrowded and bitrate is expensive as f...


Terrestrial is the big problem IMO. Many of us in the EU and UK live in rented apartments and cannot drill holes through walls and mount satellite dishes outside.

A terrestrial DVB-T2 mux can fit a grand total of 3 UHD channels. Indeed, any countries doing UHD trials are broadcasting just 2-3 UHD channels on one mux, and I doubt they will manage to free up more than one mux due to the 4G and 5G spectrum releases (and terminating H.264 is out of the question considering some countries are still facing resistance when trying to terminate mpeg2). So, I disagree, UHD bitrate requirements are very much a problem. The terrestrial broadcasting world should have waited for VVC so they can at least get 6 UHD channels per mux. If you though HD was a failure on terrestrial, wait and see how UHD will do.

[LigH]

(Why did the forum software change all text to lowercase in my previous post?)

Because "everything in uppercase" is treated as yelling and rude. It doesn't care about acronyms. There is no "intelligent software"... :cool:

[FranceBB]

I guess most H.264 HD channels will do tone-mapped content (from HDR) and call it a day.

I wish, but no...
I mean "no" to a certain extent. As long as a broadcaster is also a producer, anything can be done (for instance for sports contents, tonemapping HLG to BT709 SDR can be done on the fly without any issues), but try to do that on a movie and it's gonna be a digital rights madness 'cause some Hollywood companies DO NOT want you to tonemap on the fly. For instance, when they send us HDR PQ stuff and we convert them to HLG according to the maxCll info they provide, they always want to test our conversion methods via agreed test patters etc, but most of them will never sign an agreement for on-the-fly HDR PQ or HDR HLG to BT709 SDR tonemapping.
(It would be cool, but it ain't gonna happen 'till the Hollywood guys will change their minds :( )



(and still is in some countries like the UK, which has 12 HD channels and several dozen Mpeg2 SD ones, all of them at crappy bitrates).

Eheheheh as long as you watch itv, channel 4 etc, but if you watch Sky, that's gonna be a UHD H.265 HDR HLG 10bit stream re-encoded and dithered down from an internal 12bit DNxHQX (so 800 Mbit/s) mezzanine file, so the quality is there ;)



Terrestrial is the big problem IMO. Many of us in the EU and UK live in rented apartments and cannot drill holes through walls and mount satellite dishes outside.


Right! We're slowly but surely shifting towards internet tv, though, for anyone who can't mount a satellite dish and has a decent enough connection. Sky Glass is just an example, along with the new Sky Q Mini decoder.

OMG I sound like a salesman now xD



A terrestrial DVB-T2 mux can fit a grand total of 3 UHD channels. Indeed, any countries doing UHD trials are broadcasting just 2-3 UHD channels on one mux, and I doubt they will manage to free up more than one mux due to the 4G and 5G spectrum releases (and terminating H.264 is out of the question considering some countries are still facing resistance when trying to terminate mpeg2). So, I disagree, UHD bitrate requirements are very much a problem. The terrestrial broadcasting world should have waited for VVC so they can at least get 6 UHD channels per mux. If you though HD was a failure on terrestrial, wait and see how UHD will do.

Sorry, we've been talking past each other, I clearly meant satellite and... well... satellite-wise the UK has Astra 2E/2F/2G all dedicated to its channels, so it's easier to handle there. In Europe, every EU nation (and some non-eu ones) airs on Hotbird 13E. Can you imagine how overcrowded it is?


About terrestrial, I gotta be fair: I have no clue as I've never been interested...

[lvqcl]

YouTube is all VP9 and AV1 nowadays, with VP8 for backwards compatibility. You can probably get YouTube to serve a 720p H.264 stream as a "last resort" extreme backward compatibility stream, but I don't know if they even do that anymore.

Well, it's really not true. It's VP8 that doesn't exist anymore on YouTube, and every video has h.264 versions. Many live streams are h.264 only, like that -
format code extension resolution note
91 mp4 256x144 269k , avc1.4d400c, 30.0fps, mp4a.40.5
92 mp4 426x240 507k , avc1.4d4015, 30.0fps, mp4a.40.5
93 mp4 640x360 962k , avc1.4d401e, 30.0fps, mp4a.40.2
94 mp4 854x480 1282k , avc1.4d401f, 30.0fps, mp4a.40.2
300 mp4 1280x720 2922k , avc1.4d4020, 60.0fps, mp4a.40.2
301 mp4 1920x1080 5552k , avc1.4d402a, 60.0fps, mp4a.40.2 (best)




There would be no cost to Google or Mozilla to support passthrough to HEVC decode.
AFAIK HEVC decode in Edge Chromium is still broken --

https://techcommunity.microsoft.com/t5/discussions/hevc-video-decoding-broken-with-b-frames/m-p/2077247
https://answers.microsoft.com/en-us/windows/forum/all/hevc-video-has-stuttered-playback/56d047c1-dd76-4dc3-8544-58ec09133984
https://techcommunity.microsoft.com/t5/discussions/hevc-main-10-video-playback-is-heavily-stuttering/m-p/1959752

-- and Microsoft doesn't care much.

[birdie]

YouTube is all VP9 and AV1 nowadays, with VP8 for backwards compatibility. You can probably get YouTube to serve a 720p H.264 stream as a "last resort" extreme backward compatibility stream, but I don't know if they even do that anymore.

In the past, YouTube was all H.264 for 720p and 1080p.

This is not the case, 1080p H264 is still there for all new videos:

youtube-dl -F 'https://www.youtube.com/watch?v=zcI6SFiK_yk'
[youtube] zcI6SFiK_yk: Downloading webpage
[info] Available formats for zcI6SFiK_yk:
format code extension resolution note
249 webm audio only tiny 41k , webm_dash container, opus @ 41k (48000Hz), 759.27KiB
250 webm audio only tiny 54k , webm_dash container, opus @ 54k (48000Hz), 991.55KiB
251 webm audio only tiny 107k , webm_dash container, opus @107k (48000Hz), 1.92MiB
140 m4a audio only tiny 129k , m4a_dash container, mp4a.40.2@129k (44100Hz), 2.32MiB
160 mp4 256x144 144p 35k , mp4_dash container, avc1.4d400c@ 35k, 24fps, video only, 650.61KiB
394 mp4 256x144 144p 57k , mp4_dash container, av01.0.00M.08@ 57k, 24fps, video only, 1.02MiB
278 webm 256x144 144p 71k , webm_dash container, vp9@ 71k, 24fps, video only, 1.28MiB
133 mp4 426x240 240p 57k , mp4_dash container, avc1.4d4015@ 57k, 24fps, video only, 1.02MiB
395 mp4 426x240 240p 72k , mp4_dash container, av01.0.00M.08@ 72k, 24fps, video only, 1.30MiB
242 webm 426x240 240p 78k , webm_dash container, vp9@ 78k, 24fps, video only, 1.40MiB
134 mp4 640x360 360p 97k , mp4_dash container, avc1.4d401e@ 97k, 24fps, video only, 1.75MiB
396 mp4 640x360 360p 132k , mp4_dash container, av01.0.01M.08@ 132k, 24fps, video only, 2.37MiB
243 webm 640x360 360p 135k , webm_dash container, vp9@ 135k, 24fps, video only, 2.43MiB
135 mp4 854x480 480p 150k , mp4_dash container, avc1.4d401e@ 150k, 24fps, video only, 2.70MiB
244 webm 854x480 480p 209k , webm_dash container, vp9@ 209k, 24fps, video only, 3.76MiB
397 mp4 854x480 480p 233k , mp4_dash container, av01.0.04M.08@ 233k, 24fps, video only, 4.18MiB
136 mp4 1280x720 720p 275k , mp4_dash container, avc1.4d401f@ 275k, 24fps, video only, 4.94MiB
247 webm 1280x720 720p 319k , webm_dash container, vp9@ 319k, 24fps, video only, 5.73MiB
398 mp4 1280x720 720p 464k , mp4_dash container, av01.0.05M.08@ 464k, 24fps, video only, 8.32MiB
399 mp4 1920x1080 1080p 947k , mp4_dash container, av01.0.08M.08@ 947k, 24fps, video only, 16.96MiB
248 webm 1920x1080 1080p 1065k , webm_dash container, vp9@1065k, 24fps, video only, 19.08MiB
137 mp4 1920x1080 1080p 1227k , mp4_dash container, avc1.640028@1227k, 24fps, video only, 21.98MiB
18 mp4 640x360 360p 383k , avc1.42001E, 24fps, mp4a.40.2 (44100Hz), 6.87MiB
22 mp4 1280x720 720p 404k , avc1.64001F, 24fps, mp4a.40.2 (44100Hz) (best)

This is a three days old clip.

[benwaggoner]

This thread is about x266, not VVC in general. Let's move discussion about VVC in general to that thread.

[MoSal]

OMG I sound like a salesman now xD



Don't worry. No one here is going to fall for it before all HFR content
is properly encoded and an HFR option is provided (e.g. Football Highlights) ;)

Nothing in life bugs me more than an official source giving a video/live stream more than enough bitrate, but dropping half the frames for no good reason whatsoever. Yet for some reason, that seems to be the norm online, and doing it right is the exception.

[benwaggoner]

Don't worry. No one here is going to fall for it before all HFR content
is properly encoded and an HFR option is provided (e.g. Football Highlights) ;)

Nothing in life bugs me more than an official source giving a video/live stream more than enough bitrate, but dropping half the frames for no good reason whatsoever. Yet for some reason, that seems to be the norm online, and doing it right is the exception.
Please move discussion of VVC in general to the HEVC successor: Versatile Video Coding (https://forum.doom9.org/showthread.php?t=174940) thread.

This thread is specifically for discussions of the (unreleased!) x266 VVC encoder.

[ksec]

I think kurkosdr replies generally summarise everything that is annoying with Alliance for Open Media and their supporters. ( to say the least )

AV1 is not patent free, it is royalty free. There is a big difference between the two. The FUD on content fees and myth of patent free is still here, 2022. Fascinating world of misinformation being spread.

I would love to see a truly patent free codec, or if they could just take out the 10ish patent on EVC baseline profile. But AV1 is not a patent free codec.

H264 is not dead. Not in anyway shape of form, doesn't matter how you slice it.

Video Codec is not only used on the Web. And the web does not equal to all YouTube.

Apple is not even the largest beneficial, or even 10% of HEVC or VVC patent fee structure.

Because of these ideology over actual technical and market reality, we end up having browser vendor supporting AVIF and refuse to support JPEGXL. Which is also royalty free and open standard. And a technically better image codec on the web.

Alliance for Open Media have its place and purpose. I just wish they work on AV2 asap and learn from all the experience they had with AV1. But at least AV1 hardware decoder is finally coming. Three years behind their original schedule.

Finally this is a x266 thread. I wish we have new forum features where I could give a thumbs up like those QFT replies above.

I am already looking at beyond VVC with ECM. ~50% bitrate reduction compared to VVC Reference Encoder.

[FranceBB]

Finally this is a x266 thread.


I hope we're gonna have the new forum section soon-ish.
Like end of 2022 with all the H.266 VVC related topics moved there?


I wish we have new forum features where I could give a thumbs up

Trust me, you don't wanna have "likes" and "reactions" in a forum. Doom9 has been nearly identical for years, basically since 2001 Link (https://web.archive.org/web/20011128063251/http://forum.doom9.org/) and I sort of like the way it is with its "retro" look.


I am already looking at beyond VVC with ECM. ~50% bitrate reduction compared to VVC Reference Encoder.

Playing against the reference encoder is easy, try against VVEnc by Fraunhofer which is the closest thing we have to a real encoder. I might make more experiments with VVEnc (or indeed when x266 will come out), but I don't have time, I never have time to do the stuff I like... :(

[rwill]

I would love to see a truly patent free codec, or if they could just take out the 10ish patent on EVC baseline profile.


Wasn't the goal of the EVC Baseline profile to use no patented tools and techniques at all ? I think it was designed this way. Source please that it uses technology where active patents still apply ?

[ksec]

Wasn't the goal of the EVC Baseline profile to use no patented tools and techniques at all ? I think it was designed this way. Source please that it uses technology where active patents still apply ?

https://en.wikipedia.org/wiki/Essential_Video_Coding

The base consist of tools that were made public more than 20 years ago or for which a Type 1 declaration is received. Type 1, or option 1, means "royalty-free", in the nomenclature used in ISO documents.

The baseline has a few tools with patent that has yet to be expired but are granted the usage for free. Basically EVC baseline is royalty free or soon to be patent free.

[benwaggoner]

EVC baseline is technically promising in offering royalty free that is quite a bit better than H.264 at much lower complexity/cost than AV1 (or even VP9). And the optional tool design should make higher profiles a lot more resilient against submarine patents and such. Haven't heard too much about practical implementations lately, although Covid obscures lots of things trade shows used to reveal.

[FranceBB]

But at least AV1 hardware decoder is finally coming. Three years behind their original schedule.

I was looking into this this afternoon out of curiosity. Looks like NVIDIA introduced it only from the GeForce RTX 3050 Ti / RTX 3050 onwards, so:

- RTX 3050
- RTX 3050 Ti
- RTX 3060
- RTX 3060 Ti
- RTX 3070
- RTX 3070 Ti
- RTX 3080
- RTX 3090

and it's 4:2:0 only and 8bit/10bit but no 12bit.

On the bright side, H.265 is finally seeing some love for 4:4:4 as well, in fact 8bit, 10bit, 12bit 4:4:4 H.265 is hardware decoded. :D
This is indeed good and I'd love to see 4:2:2 and 4:4:4 be supported at high bit depth for other codecs as well (like H.264).

This might be slightly off topic, but one of the things I'm having hard time to decode is Motion JPEG2000 Intra Class 4:4:4 12bit XYZ BT2020 SDR in UHD and Motion JPEG2000 Intra Class RGB 12bit HDR PQ which movie studios seem to love. It's making my 20c/40th Xeon suffer and I can't still see it decoded in real time... :(
I'm sure the studios are using an hardware playback port to decode this (like we do with Omneon for MPEG-2 and Versio for H.264) but there must be another way, surely.
Also, I think that the reason why it's so hard to decode is that it's actually using the Wavelet Transform which is applied to the whole picture at once (so it can't be parallelized) instead of the DCT applied to blocks and macroblocks of different sizes like we have in MPEG codecs (but I might be wrong).

[ksec]

This might be slightly off topic, but one of the things I'm having hard time to decode is Motion JPEG2000 Intra Class 4:4:4 12bit XYZ BT2020 SDR in UHD and Motion JPEG2000 Intra Class RGB 12bit HDR PQ which movie studios seem to love. It's making my 20c/40th Xeon suffer and I can't still see it decoded in real time...

I dont know of any decent open source solution to Motion JPEG 2000. All of them are commercial software. I do know Nvidia has a nvJPEP2000 library on CUDA, but I have never played around with it.

[Blue_MiSfit]

libopenjpeg is pretty good :)

But we're getting off topic!

[Emulgator]

....but one of the things I'm having hard time to decode is Motion JPEG2000 Intra Class 4:4:4 12bit XYZ BT2020 SDR in UHD and Motion JPEG2000 Intra Class RGB 12bit HDR PQ which movie studios seem to love. It's making my 20c/40th Xeon suffer and I can't still see it decoded in real time...
I'm sure the studios are using an hardware playback port to decode this (like we do with Omneon for MPEG-2 and Versio for H.264) but there must be another way, surely.
Software: Kakadu et al., Hardware: Barco Silex et al.

[rwill]

Kakadu is much faster than OpenJPEG for me.

[benwaggoner]

At the time (before I was involved in SMPTE) I figured that J2K was used for digital cinema in large part to make it that much harder for pirates to be able to play them on PCs ;).

[ksec]

at the time (before i was involved in smpte) i figured that j2k was used for digital cinema in large part to make it that much harder for pirates to be able to play them on pcs ;).

rofl.

[LigH]

Security via obscurity...

[Balling]

At the time (before I was involved in SMPTE) I figured that J2K was used for digital cinema in large part to make it that much harder for pirates to be able to play them on PCs ;).

There were no such leaks. Only some masters in ProRes.

[Balling]

BTW, funny that you mention it https://docs.nvidia.com/cuda/nvjpeg2000/userguide.html

[benwaggoner]

There were no such leaks. Only some masters in ProRes.
Yeah there was sure a lot of belt and suspenders in security for DCI. I'm sure they would have been cracked eventually hadn't much more useful formats like ProRes HQ come out. And which have a lot more threat vectors.

[Dann0245]

https://multicorewareinc.com/news/meet-multicoreware-at-nab2022-in-las-vegas/

https://i.slow.pics/CBLiD4hX.png

[nevcairiel]

They have been listing x266 for convention schedules going back 6 months or so (going back to IBC 2021 in November), nevertheless more information has not really been made public in all that time.

[rwill]

https://multicorewareinc.com/news/meet-multicoreware-at-nab2022-in-las-vegas/


I read between the lines and it tells me a lot about the state x266 is in.

[FranceBB]

Ah, so more info and hopefully we're gonna have a date about when it's gonna be officially released.
I look forward to toss VVEnc and integrate x266 'cause so far I've had to work around the VVEnc limitations.

[BuccoBruce]

I'm hoping MCW working on this means VVC won't face as much of an uphill battle with functional rate control or single threaded performance as VP9/AV1 did. Anyone know what their demo at NAB was like?


AFAIK HEVC decode in Edge Chromium is still broken --

https://techcommunity.microsoft.com/t5/discussions/hevc-video-decoding-broken-with-b-frames/m-p/2077247
https://answers.microsoft.com/en-us/windows/forum/all/hevc-video-has-stuttered-playback/56d047c1-dd76-4dc3-8544-58ec09133984
https://techcommunity.microsoft.com/t5/discussions/hevc-main-10-video-playback-is-heavily-stuttering/m-p/1959752

-- and Microsoft doesn't care much.

That was a side effect of a regression in their HEVC Extension, downgrading it fixed it as soon as the bug was introduced in 2020. I'd know, I still have Microsoft.HEVCVideoExtension_1.0.31823.0_x64__8wekyb3d8bbwe.appx on my NAS for any machines that I forgot to disable Store updates for it on! It does finally work fine now, they did something to either the extension itself or Edge in March (likely both) and finally fixed it, nearly two years later. I wonder if they've actually paid out to HEVC Advance / MPEG LA for all the free HEVC Video Extensions from Device Manufacturer downloads out there.

You used to be able to build Chromium itself using a modified ffmpeg build that could play anything (including HEVC) but the old methods you can find online no longer work.

At the time (before I was involved in SMPTE) I figured that J2K was used for digital cinema in large part to make it that much harder for pirates to be able to play them on PCs ;).

:D

[LigH]

HEVC issues do not belong to this thread... per se. But you are probably right, making a mistake once does not guarantee it won't happen twice, in the area of media technology.

In the meantime, before x266 gets available, uvg266 (https://forum.doom9.org/showthread.php?t=184093) is about to get useable. When anyone has the time and knowledge to make MABS support it, let's test it together...

[rwill]

Any news?

And does anyone know if x266 will have a deep psycho-visual pipeline? Modern encoders seem to put their focus there.

[Jamaika]

https://www.videoaktiv.de/2022110436675/news/markt/mainconcept-vvc/h.266-freie-betaphase-zum-hevc-nachfolger-gestartet.html
Anyone tested? Worth the sin? What hardware for the new codec?

[LigH]

I doubt that x266 will be made by Fraunhofer, Jamaika... wrong thread for that link.

[birdie]

Updates on x266 (https://forum.doom9.org/showthread.php?p=1982204#post1982204).

[DTL]

And does anyone know if x266 will have a deep psycho-visual pipeline? Modern encoders seem to put their focus there.

I hope at some stage they will finally actively integrate noise reduction to reuse motion search data in both noise reduction and encoding stages. As I currently know only AV1 of modern enough codecs have more or less good progress to 'temporal noise reduction' with some not very few number of frames used.

[benwaggoner]

I hope at some stage they will finally actively integrate noise reduction to reuse motion search data in both noise reduction and encoding stages. As I currently know only AV1 of modern enough codecs have more or less good progress to 'temporal noise reduction' with some not very few number of frames used.
Do you mean FGS or something else?

FGS is really an out-of-band process, not a codec feature per se. An encoder just gets the degrained source and grain reconstruction metadata to include. Which is a perfectly rational approach; grain removal is hard, complex, and advancing quickly. There's lots of benefit in grain removal not being normative, and just having the reconstruction be normative.

[birdie]

The last webinar questions have been answered (http://bit.ly/3EB0Hdk).

I'm a little bit dumbfounded because seemingly some questions have been misunderstood, some others have very basic and uninformative answers.

[PatchWorKs]

For those who are interested in, latest FastFilx beta added x266 support (through VVCEasy (https://github.com/MartinEesmaa/VVCEasy)):
https://github.com/cdgriffith/FastFlix/releases/tag/5.2.0b3

[FranceBB]

Unlikely given that x266 hasn't been released yet for public availability and it's not even available to Multicoreware's partners right now.
Looks like they added VVDec and VVEnc by Fraunhofer, which is still an H.266 Decoder and Encoder, but done by a different company.

Different projects, same goals.

[rwill]

Looks like they added VVDec and VVEnc by Fraunhofer, which is still an H.266 Decoder and Encoder, but done by a different company.

Fraunhofer is not a company but an registered association.

[ksec]

The last webinar questions have been answered (http://bit.ly/3EB0Hdk).

I'm a little bit dumbfounded because seemingly some questions have been misunderstood, some others have very basic and uninformative answers.

Well I don’t think they misunderstood any question. I think they intentionally avoid answering it directly. It is just part of PR.

I would love to test x266. Both as still image like HEIC and video. At least both Mediatek and Qualcomm are on board with VVC. If Apple follows through that is potentially 95%+ of Mobile market.

[benwaggoner]

The last webinar questions have been answered (http://bit.ly/3EB0Hdk).

I'm a little bit dumbfounded because seemingly some questions have been misunderstood, some others have very basic and uninformative answers.
Is Ultraziq a rebranded/enhanced implementation of UHDKit?

[Blue_MiSfit]

It sure seems to be.

[kurkosdr]

The last webinar questions have been answered (http://bit.ly/3EB0Hdk).
So, we finally have a date: H2 2023. This means that everyone will have to withhold complaints about when x266 will be released to 1st Jan 2024.

BTW I also think some of the answers are being evasive, but people need to understand that corporations can share only what they can share. But they shared a release date, so that's good.

At least both Mediatek and Qualcomm are on board with VVC. If Apple follows through that is potentially 95%+ of Mobile market.
Out of curiosity, what will be the case for this? Firefox and Chrome (which are the majority of the browser market) have decided to not adopt any ISO/ITU standard beyond H.264, so that rules web video out, and broadcast and Blu-Ray UHD content belongs to HEVC (too much of an installed base to revert now, imagine if MPEG4 ASP had become the standard for FullHD, that's what essentially happened with UHD and HEVC), which means VVC-encoded videos will be unplayable in the majority of UHD televisions. My only guess is 8K UHD content, which is generally assumed to be VVC-encoded, but this raises the question if smartphones can encode 8K UHD content, in VVC.

[benwaggoner]

Out of curiosity, what will be the case for this? Firefox and Chrome (which are the majority of the browser market) have decided to not adopt any ISO/ITU standard beyond H.264, so that rules web video out, and broadcast and Blu-Ray UHD content belongs to HEVC (too much of an installed base to revert now, imagine if MPEG4 ASP had become the standard for FullHD, that's what essentially happened with UHD and HEVC), which means VVC-encoded videos will be unplayable in the majority of UHD televisions. My only guess is 8K UHD content, which is generally assumed to be VVC-encoded, but this raises the question if smartphones can encode 8K UHD content, in VVC.
Chrome added support for HEVC in the fall, if a system HEVC decoder is available. So it's plausible they'll do the same for VVC in a few year (and plausible they won't).

[kurkosdr]

Chrome added support for HEVC in the fall, if a system HEVC decoder is available.
So, Google decided to screw over Linux and Mozilla after initially joining them in their decision to not implement patent-encumbered formats newer than H.264. Why I am not surprised?

[benwaggoner]

So, Google decided to screw over Linux and Mozilla after initially joining them in their decision to not implement patent-encumbered formats newer than H.264. Why I am not surprised?
I think it is more a matter of prioritizing users over ideological purity. AV1 hasn't really caught on for HDR content, nor have practical benefits of it over HEVC been demonstrated. Everything but browsers can do HEVC these days, and the browser HDR market hasn't been big enough to justify spending 2-4x more time to encode AV1 HDR files for them. Allowing HEVC passthrough to system decoders doesn't require any patent engagement by Google, and adds compatibility with a whole lot of premium content that would otherwise not be available in a browser versus a standalone app.

And Linux systems certainly do support HEVC playback. There's not a build-in software player, but CPU/GPU HW HEVC decoders can certainly be accessed under lots of Linux distributions.

I can't speak to Mozilla's plan, but they certainly could add the "we won't have a decoder, but we'll pass HEVC on to one that exists."

Chrome and Firefox supported HEVC passthrough around a decade ago, as codec passthrough used to be done by default if a decoder was available. That functionality was explicitly blocked by the browsers later.

Supporting VVC in the same way will be quite straightforward once we start seeing PC systems with VVC decoders (I'd expect some PC CPU or GPUs with support to launch by late 2024.).

[ksec]

Out of curiosity, what will be the case for this? Firefox and Chrome (which are the majority of the browser market) have decided to not adopt any ISO/ITU standard beyond H.264, so that rules web video out, and broadcast and Blu-Ray UHD content belongs to HEVC (too much of an installed base to revert now, imagine if MPEG4 ASP had become the standard for FullHD, that's what essentially happened with UHD and HEVC), which means VVC-encoded videos will be unplayable in the majority of UHD televisions. My only guess is 8K UHD content, which is generally assumed to be VVC-encoded, but this raises the question if smartphones can encode 8K UHD content, in VVC.

Future TV broadcast standard like Brazil have chosen VVC. HDR and 4K ( It doesn't even need to be 8K ) Broadcast will also likely be using a new video codec standard. There are also other Streaming Services which doesn't rely on Web. Especially outside of EUR and North America. Even in 4K HDR Content VVC will still be much better than HEVC.

[FranceBB]

Allowing HEVC passthrough to system decoders doesn't require any patent engagement by Google, and adds compatibility with a whole lot of premium content that would otherwise not be available in a browser versus a standalone app.

Yep, that's exactly it, in fact I really don't see anything wrong with this approach. After all, if a user has an H.265 capable hardware decoder in his GPU, it means that the GPU manufacturer already paid the royalty to be able to decode it (and therefore included it in the final GPU price that the user paid). In other words, given that the user has *theoretically* already paid the fee, having such a functionality artificially blocked inside the browser wouldn't make any sense, so I'm totally in favor of this approach. I, myself, have an H.265 capable GPU in terms of decoding and indeed chrome://gpu shows it:

https://i.imgur.com/8Twnv6E.png

and indeed if I try to play an H.265 stream it works like a charm:

https://i.imgur.com/Nn9BkfD.png


I'm using the DASH reference player: https://reference.dashif.org/dash.js/nightly/samples/dash-if-reference-player/index.html to test with the following stream: https://dash.akamaized.net/dash264/TestCasesUHD/2a/5/MultiRate.mpd

https://i.imgur.com/8leWwei.png

[kurkosdr]

And Linux systems certainly do support HEVC playback. There's not a build-in software player, but CPU/GPU HW HEVC decoders can certainly be accessed under lots of Linux distributions.
No, not consistently at least. HEVC hardware decoding acceleration on Desktop Linux depends on the driver used, since GPU vendors are unclear on whether the royalty is paid on the hardware sale or on the driver download, which scares away open-source driver authors. Fedora had to disable hardware decoding of patent-encumbered formats for that very reason. And then there is the problem of perfectly functional GPUs which however don't have HEVC hardware decoding acceleration.

Google decided to screw Desktop Linux users over and treat them as lesser Chrome users after promising they wouldn't do that (in order to drum up support for VP9). Why am I not surprised? The next step is Mozilla getting blamed for not treating Desktop Linux users as lesser Firefox users too.

Remember when the web was universally accessible and not subject to whether you've gone through the MPEG LA and Access Advance tollbooths? I do.

[birdie]

Remember when the web was universally accessible and not subject to whether you've gone through the MPEG LA and Access Advance tollbooths? I do.

I do, the only video format at the time being numb 8bit palette GIF.

Neither APNG, nor MNG ever took off.

[rwill]

I do, the only video format at the time being numb 8bit palette GIF.

Neither APNG, nor MNG ever took off.

That was because GIF being a completely open format and totally not patent encumbered was a perfect match for the Web of the People. Right comrades ?

*edit*
So whats going on with x266? Cant be that hard to write a H.266 encoder. Looking at their feature roadmap I think it would take me just 2-3 man-months to get to a working release....

[kurkosdr]

That was because GIF being a completely open format and totally not patent encumbered was a perfect match for the Web of the People.
I kind of expected this comment, despite being plain wrong: The GIF compression patent was a patent ambush. In other words, the patent holder came to assert and collect after the format had been already widely implemented. The royalty-free PNG was invented shortly afterwards precisely because the web was always meant to be universally accessible, but inertia was king (as always). After the GIF compression patent expired, universal accessibility was restored. Then YouTube made the Flash Player plugin and H.264 mandatory. Even today, the legacy of Flash Player lives on because H.264 was implemented at the browser level in order to encourage websites to move on from Flash Player. But what's the point of HEVC on the web? A slightly worse format than AV1 that is patent-encumbered? And has the patent mess of HEVC been sorted out yet or there are still multiple patent pools that you need to negotiate with? And how many patent pools exactly are essential to HEVC this week? What a mess. But again, I am not surprised Google proved to be a backstabbing company. They are an ad agency masquerading as a tech company after all.

[FranceBB]

Fedora had to disable hardware decoding of patent-encumbered formats for that very reason. And then there is the problem of perfectly functional GPUs which however don't have HEVC hardware decoding acceleration.


This is a video shot with my Google Pixel 6 Pro in H.265 the other day:


General
Complete name : /home/FranceBB/Downloads/PXL_20230309_182128484.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom/iso2/mp41)
File size : 102 MiB
Duration : 13 s 592 ms
Overall bit rate : 63.1 Mb/s
Encoded date : UTC 2023-03-09 18:21:43
Tagged date : UTC 2023-03-09 18:21:43
xyz : +45.4339+9.2417/

Video
ID : 3
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L6.1@Main
Codec ID : hvc1
Codec ID/Info : High Efficiency Video Coding
Duration : 13 s 589 ms
Bit rate : 62.8 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 60.000 FPS
Minimum frame rate : 45.662 FPS
Maximum frame rate : 93.652 FPS
Real frame rate : 60.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.126
Stream size : 102 MiB (100%)
Title : VideoHandle
Language : English
Encoded date : UTC 2023-03-09 18:21:43
Tagged date : UTC 2023-03-09 18:21:43
Color range : Full
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Codec configuration box : hvcC

Audio
ID : 2
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : mp4a-40-2
Duration : 13 s 592 ms
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 319 KiB (0%)
Title : SoundHandle
Language : English
Encoded date : UTC 2023-03-09 18:21:43
Tagged date : UTC 2023-03-09 18:21:43

Other
Type : meta
Duration : 13 s 589 ms
Bit rate mode : Variable



This is me playing it with hardware decoding through MPV on my Fedora 37 x64: https://i.imgur.com/YXrv2At.png


as you can see, being an 8bit yv12 (4:2:0 planar) Full Range BT709 60p UHD video, it's being hardware decoded by the GPU in nv12 using vaapi.


To do this, you need to add the following lines in mpv.conf

#Here we enable hardware decoding for everything
hwdec=auto
hwdec-codecs=all
vd-lavc-check-hw-profile=no

#Here we fallback to software if there's no hardware decoding
vd-lavc-software-fallback=yes

#Here we set the video sync (useful with GNOME)
video-sync=display-resample-desync


in case anyone needs it, here's my full mpv.conf that needs to be placed in /etc/mpv: Link (https://mega.nz/file/OYtW1ZgQ#7-LdOvps-E33NptK2JsryjsaC-bKgolf5FrCCi1srXo)


As far as chrome is concerned, unless you need to stay on the official Google Chrome, you can use chromium, in particular chromium-freeworld from RPM Fusion which still includes all the decoders which are not included in the standard version of chromium afaik.

https://github.com/rpmfusion/chromium-freeworld

just

sudo dnf install chromium-freeworld

and that's it.

[kurkosdr]

This is a video shot with my Google Pixel 6 Pro in H.265 the other day:




This is me playing it with hardware decoding through MPV on my Fedora 37 x64: https://i.imgur.com/YXrv2At.png


as you can see, being an 8bit yv12 (4:2:0 planar) Full Range BT709 60p UHD video, it's being hardware decoded by the GPU in nv12 using vaapi.


To do this, you need to add the following lines in mpv.conf

#Here we enable hardware decoding for everything
hwdec=auto
hwdec-codecs=all
vd-lavc-check-hw-profile=no

#Here we fallback to software if there's no hardware decoding
vd-lavc-software-fallback=yes

#Here we set the video sync (useful with GNOME)
video-sync=display-resample-desync


in case anyone needs it, here's my full mpv.conf that needs to be placed in /etc/mpv: Link (https://mega.nz/file/OYtW1ZgQ#7-LdOvps-E33NptK2JsryjsaC-bKgolf5FrCCi1srXo)


As far as chrome is concerned, unless you need to stay on the official Google Chrome, you can use chromium, in particular chromium-freeworld from RPM Fusion which still includes all the decoders which are not included in the standard version of chromium afaik.

https://github.com/rpmfusion/chromium-freeworld

just

sudo dnf install chromium-freeworld

and that's it.
Ok, how did you do this? Proprietary Nvidia or AMD drivers? Not everyone has an Nvidia or AMD GPU, most systems have Intel GPUs. Fedora with the default drivers can't decode HEVC even if the GPU has hardware acceleration:
https://www.reddit.com/r/Fedora/comments/xpt34f/fedora_37_drops_vaapi_accelerated_hardware_video/
This is due to GPU vendors' unwillingness to clarify whether the royalty is paid on the hardware sale or on the driver download.

Also, Chromium can't sync to Google Account anymore so it's useless for most people (another little bit of backstabbing by Google, surprise surprise).

Please note that while I don't hate HEVC or VVC per se, I hate those HEVC and VVC fanboys that try to downplay the massive IPR problems of those codecs (and how this could affect the universal accessibility of the web) by pointing to system codecs as the solution, conveniently ignoring the fact system codec support is inconsistent and hence not universal. And yes, HEVC and VVC do have massive IPR problems: Again, how many patent pools exactly are essential to HEVC this week? Same for VVC?

[FranceBB]

Ok, how did you do this? Proprietary Nvidia or AMD drivers?

I totally get the pain of using proprietary NVIDIA drivers on Linux, particularly 'cause for me NVIDIA drivers are almost always broken at every kernel update and the fact that NVIDIA isn't willing to open source a damn thing is pretty annoying as it left the Nouveau project guys in the dark, with GPUs running at the lowest possible clock speeds with no hope for re-clocking. Sure, the latest changes bring a bit of hope as they would allow for some GPUs to be reclocked, however it only works for newer GPUs so anyone with a 900 series like me will be left in the dark with either a buggy proprietary driver or a slow unusable open source one.

Leaving this sad chapter aside, that thing was actually done from my old 2016 era laptop, which has an Intel i7 6700HQ (which has the HD Graphics 530 inside it) and an NVIDIA GTX950M. The latter runs on Nouveau drivers and is almost never used as it's totally useless: official NVIDIA drivers are almost always broken while Nouveau drivers don't allow reclocking so...

https://i.imgur.com/isKUQQO.png

Anyway, long story short, the test was actually run using the HD Graphics 530 which can decode H.265 8bit (but not 10bit, why Intel, whyyyyyyyyy?!) via hardware and it did actually work. Of course, if I use the official Google Chrome and not the freeworld chromium version, on the other hand, the screen will stay pitch black with just the audio playing.


Fedora with the default drivers can't decode HEVC even if the GPU has hardware acceleration


I asked DBelton from the Fedora community and he helped me long time ago. I can't remember which Intel drivers and decoders he and Marko made me install through both the command line and Fedy, but the whole thing worked and it's still working today. You should definitely go to the Fedora Forum and ask, they'll help you just like they helped me back in 2016.


Also, Chromium can't sync to Google Account anymore so it's useless for most people (another little bit of backstabbing by Google, surprise surprise).


I'm totally with you on this, to be fair.
That has been one of the things that annoyed me incredibly 'cause it was a bit of a stab in the back to all the open source developers who worked on the various chromium forks.
I have some friends of mine who actively contribute and when that thing happened they didn't really take it well.
I, myself, didn't take it well either 'cause on the little Windows XP community I'm part of we have some people providing some constantly backported version of chromium (the last one being 108) and of course I haven't been able to sync my account ever since Google blocked it for third party forks... :(



Please note that while I don't hate HEVC or VVC per se, I hate the HEVC and VVC fanboys that try to downplay the massive IPR problems of those codecs

I mean, this is Doom9 not a reddit subforum, so professional people are here, so it's unlikely you'll ever meet any fanboy and I can assure you neither me nor Ben is.
But again, MPEG codecs have always been here and they're here to stay, so even if you were to get a couple more people on Doom9 jumping on the AV1 (and possibly AV2) bandwagon, it would change literally nothing (I know it's hard, but it's true). I mean, think about every 8K broadcaster, every future 8K BD manufacturer etc, what do you think it's gonna happen? Love it or hate it, H.266 VVC will be a thing just like H.265, H.264 and MPEG-2 have and there will be hardware encoders, hardware decoders, playback ports for playout systems and indeed GPUs manufacturers supporting those for consumer-tier profiles (NVIDIA almost definitely and then Intel and probably AMD) as well as hardware decoding support in mobile phones.

This is inevitable, it is going to happen and, in my opinion, it's not a bad thing.


By the way, to prove that I'm not biased in any way, even though my job is literally to create mezzanine files which are by definition going to be MPEG codec based (like XDCAM-50 and XAVC Intra Class 300) and will be played on hardware playback ports in playout systems, I did create (very recently) some AV1 files too for distribution as I was asked to do so for a few trailers (around 50 clips) that were gonna be played over the internet on web pages of our website. (https://forum.doom9.org/showthread.php?t=183907) So, you see, although AV1 (and in the future AV2) might become a web thing, I can almost definitely guarantee you that it will never happen for linear broadcasting anywhere in the world and that's just the way it is.

[kurkosdr]

Future TV broadcast standard like Brazil have chosen VVC. HDR and 4K ( It doesn't even need to be 8K ) Broadcast will also likely be using a new video codec standard. There are also other Streaming Services which doesn't rely on Web. Especially outside of EUR and North America. Even in 4K HDR Content VVC will still be much better than HEVC.
With some rare exceptions like Brazil, most countries chose HEVC for their UHD broadcasts years ago, so VVC for broadcasting is irrelevant for most parts of the world. The following is a good example:
https://www.google.com/search?q=site:digitalbitrate.com+vvc
https://www.google.com/search?q=site:digitalbitrate.com+hevc

The only broadcasting area I see VVC succeeding is 8K UHD content, which will probably be 2-3 channels per satellite or so, considering how scarce bitrate is in most satellites. Irrelevant in the big scheme of things, but still technically interesting.

Streaming boxes could be a big win for VVC, but it faces competition from AV1 and the existing HEVC installed base. That's a space to watch.

[kurkosdr]

I asked DBelton from the Fedora community and he helped me long time ago. I can't remember which Intel drivers and decoders he and Marko made me install through both the command line and Fedy, but the whole thing worked and it's still working today. You should definitely go to the Fedora Forum and ask, they'll help you just like they helped me back in 2016.
That's why I asked what are you using btw, because you have to do at least some things to get HEVC working in Fedora (and other Desktop Linux distros). Having to install codecs is the problem here, because officially recommending those codecs to people can be considered as "inducing" patent infringement. It's why Fedora can't show a pop-up saying "run the following commands to install such and such codec".

This is the problem I am highlighting here: Once you have to tell people that they need to have this and that, and can't even tell them how, the whole universal accessibility concept of the web is lost.

[benwaggoner]

No, not consistently at least.
Well, it is Linux we're talking about there's not a lot it has done consistently across distributions in terms of advanced digital media and graphical stuff.

Google decided to screw Desktop Linux users over and treat them as lesser Chrome users after promising they wouldn't do that (in order to drum up support for VP9). Why am I not surprised? The next step is Mozilla getting blamed for not treating Desktop Linux users as lesser Firefox users too.

Remember when the web was universally accessible and not subject to whether you've gone through the MPEG LA and Access Advance tollbooths? I do.
I certainly don't remember that for digital video, ever. I spent years making a lot of money encoding RealVideo, Windows Media, and QuickTime versions of the same content for the web as plenty of customers only had one of the three. When we got to more universal playback, it was due to the ubiquity of Flash's H.263 decoder support. We did have a while where browsers became powerful enough at H.264 + AAC-LC because universal enough that a single file could play on >99% of web browsers, but it was only a few years between that becoming reliable and HDR (with a 10-bit encoding requirement) becoming important.

Browsers have been about the only place where HEVC hasn't been universal the last five years.

[ksec]

With some rare exceptions like Brazil, most countries chose HEVC for their UHD broadcasts years ago, so VVC for broadcasting is irrelevant for most parts of the world. The following is a good example:
https://www.google.com/search?q=site:digitalbitrate.com+vvc
https://www.google.com/search?q=site:digitalbitrate.com+hevc

The only broadcasting area I see VVC succeeding is 8K UHD content, which will probably be 2-3 channels per satellite or so, considering how scarce bitrate is in most satellites. Irrelevant in the big scheme of things, but still technically interesting.

Streaming boxes could be a big win for VVC, but it faces competition from AV1 and the existing HEVC installed base. That's a space to watch.

Because you are comparing the current state and future state. The world is much bigger than North America and EUR. VVC are already in use in India. And China is getting ready too.

[ksec]

That's why I asked what are you using btw, because you have to do at least some things to get HEVC working in Fedora (and other Desktop Linux distros). Having to install codecs is the problem here, because officially recommending those codecs to people can be considered as "inducing" patent infringement. It's why Fedora can't show a pop-up saying "run the following commands to install such and such codec".

This is the problem I am highlighting here: Once you have to tell people that they need to have this and that, and can't even tell them how, the whole universal accessibility concept of the web is lost.

As far as I am aware. The HEVC and AVC decoding issue is only a concern using third party open source drivers. So if you have something like Ubuntu which installs drivers from Nvidia and Intel you would have no problem. the argument is basically that what ever patent there is, those official drivers are being accounted for.

But considering this is Fedora / Redhat, the company which declare AAC-LC as patent free ( Thank God ). This comes a little bit of a surprise. Especially after this has been the norm for years before declaring it unsafe. But they are now under IBM, I guess legal have a different interpretation.

Anyway we only have wait a few more years before AVC patents expires. We will have a truly parent free half decent video codec.

[kurkosdr]

Well, it is Linux we're talking about there's not a lot it has done consistently across distributions in terms of advanced digital media and graphical stuff.
When it comes to video, it's because of legal roadblocks, not technical reasons. Stop trying to deflect.


I certainly don't remember that for digital video, ever. I spent years making a lot of money encoding RealVideo, Windows Media, and QuickTime versions of the same content for the web as plenty of customers only had one of the three. When we got to more universal playback, it was due to the ubiquity of Flash's H.263 decoder support. We did have a while where browsers became powerful enough at H.264 + AAC-LC because universal enough that a single file could play on >99% of web browsers, but it was only a few years between that becoming reliable and HDR (with a 10-bit encoding requirement) becoming important.
From the browser's perspective, RM, WMV and QT/MOV were binary blobs to be downloaded, so it was out of scope. The problem started with the Flash Player plugin and then continued with HTML5 video tag leaving the format unspecified (nice implementable specification there folks).


Browsers have been about the only place where HEVC hasn't been universal the last five years.
For a good reason. The web is supposed to be universally accessible and universally implementable, which means it avoids patent-encumbered formats (more so patent-encumbered formats with multiple patent pools). Eventually, this boils down to whether you consider access to the web a fundamental human right. I do.

[birdie]

That was because GIF being a completely open format and totally not patent encumbered was a perfect match for the Web of the People. Right comrades ?

*edit*
So whats going on with x266? Cant be that hard to write a H.266 encoder. Looking at their feature roadmap I think it would take me just 2-3 man-months to get to a working release....

I guess they don't want to make public something which is a lot worse (both in quality and performance) than already existing codecs such as VVEnc.

And VVEnc is quite good actually albeit slow but not much slower than e.g. libaom.

[rwill]

Well, it is Linux we're talking about there's not a lot it has done consistently across distributions in terms of advanced digital media and graphical stuff.


Remember when the web was universally accessible and not subject to whether you've gone through the MPEG LA and Access Advance tollbooths? I do.


I certainly don't remember that for digital video, ever. I spent years making a lot of money encoding RealVideo, Windows Media, and QuickTime versions of the same content for the web as plenty of customers only had one of the three. When we got to more universal playback, it was due to the ubiquity of Flash's H.263 decoder support. We did have a while where browsers became powerful enough at H.264 + AAC-LC because universal enough that a single file could play on >99% of web browsers, but it was only a few years between that becoming reliable and HDR (with a 10-bit encoding requirement) becoming important.

Browsers have been about the only place where HEVC hasn't been universal the last five years.

I support that on the Web the baseline should be a 160x120 Theora video and those platforms that want better have to support H.264/HEVC or VVC. So the < 1% market share Linux Desktop guys get their stamp sized video and have no reason to complain anymore and the rest ( > 99% market share ) can finally move on, which they have already anyway.

Personally I don't get the Linux Desktop people. They are a clear minority but defend and make demands for their fragmented platform like some Otaku does for his waifu.

[rwill]

I guess they don't want to make public something which is a lot worse (both in quality and performance) than already existing codecs such as VVEnc.

And VVEnc is quite good actually albeit slow but not much slower than e.g. libaom.

Well should this be the case they have to be somewhat careful, lest they will never have anything to release ever.

[kurkosdr]

I support that on the Web the baseline should be a 160x120 Theora video and those platforms that want better have to support H.264/HEVC or VVC. So the < 1% market share Linux Desktop guys get their stamp sized video and have no reason to complain anymore and the rest ( > 99% market share ) can finally move on, which they have already anyway.

Personally I don't get the Linux Desktop people. They are a clear minority but defend and make demands for their fragmented platform like some Otaku does for his waifu.
As a person who uses Desktop Linux professionally, I can attest that I don't think I am entitled to "make demands" for Blu-Ray playback or access to every AAA PC game that gets released or anything like that. But access to the web is a human right. It's necessary for people to do things like filing taxes or searching for information so they can do their jobs. This means the web has to be universally accessible.

Oh, and your 160x120 Theora video thing, besides being stupid (downscaling loses a ton of information which can be important for things like tutorials) is something that's not even guaranteed to be there. Theora mandated as a minimum format with the same resolution as the other available formats would be a good idea because at least it makes for an implementable HTML5 spec.

But anyway, you don't have to care about my opinion. Have you ever wondered why W3C didn't propose a format for the HTML5 video tag? It's because they have a principle to not include patented-encumbered technology in W3C standards, which means their views are closer to mine than yours. But since they couldn't agree on a royalty-free standard, they left it unspecified (because that totally makes sense, I guess).

Also, people here forget a good 5% of Windows users run versions older than Windows 8, which means they aren't guaranteed to have HEVC OS codecs and probably run old PCs with old GPUs without hardware HEVC decoding either. But I know, those are poor people. Who cares if they can access the web?

[rwill]

<..> I can attest that I don't think I am entitled to "make demands" <..> But access to the web is a human right. <..> Theora mandated as a minimum format with the same resolution as the other available formats would be a good idea <..>

Wow - access to video on the web a human rights issue - this sure escalated fast.

[FranceBB]

Also, people here forget a good 5% of Windows users run versions older than Windows 8, which means they aren't guaranteed to have HEVC OS codecs and probably run old PCs with old GPUs without hardware HEVC decoding either.

There will always be a compatibility fallback in streaming platforms, though.
I mean, nowadays you would probably get H.265 HEVC for HDR UHD contents and H.264 AVC for SDR FULL HD 8bit and lower and I think that's going to stay for a very very very long time. I mean, if you watch a TV Series on streaming platform x and you go there with, let's say, Windows XP and a backported version of Chromium (currently Chromium 108 is the latest that has been backported), it will almost definitely serve you the H.264 version at all resolutions and bitrate combinations, ranging from FULL HD to HD to SD and possibly lower streams with AAC audio which is perfectly decodable. Speaking of which, even via software only decoding, H.264 nowadays is pretty well handled, so I don't really think it's gonna be a problem anytime soon as H.264 is here to stay. Ironically AV1 would be much harder to decode for an x86 SSE4.1 max operating system, so much so that even Google itself offers VP9 + Opus rather than AV1 to the Windows XP users even for UHD contents.

This is me on Windows XP Professional x86 with the Extended Microsoft Support which ended on July 2019 and Chromium 108:

- YouTube - VP9 + Opus (https://i.imgur.com/v4uAGee.png)
- BBC - H.264 + AAC (https://i.imgur.com/qxOcdz2.png)


I guess they don't want to make public something which is a lot worse (both in quality and performance) than already existing codecs such as VVEnc.


I guess that's the point.

Well should this be the case they have to be somewhat careful, lest they will never have anything to release ever.

Well, the current situation is the following while comparing with VTM, however no comparisons were done against VVEnc:

https://i.imgur.com/zIXwr46.png

[kurkosdr]

There will always be a compatibility fallback in streaming platforms, though.
I mean, nowadays you would probably get H.265 HEVC for HDR UHD contents and H.264 AVC for SDR FULL HD 8bit and lower and I think that's going to stay for a very very very long time. I mean, if you watch a TV Series on streaming platform x and you go there with, let's say, Windows XP and a backported version of Chromium (currently Chromium 108 is the latest that has been backported), it will almost definitely serve you the H.264 version at all resolutions and bitrate combinations, ranging from FULL HD to HD to SD and possibly lower streams with AAC audio which is perfectly decodable.
First of all, even H.264 system codecs are not guaranteed to exist on Windows Vista and earlier, so some browsers will fail H.264 decoding on those OSes too. Also, even this H.264 fallback is not guaranteed to exist on all websites (this is why W3C's decision to not include some mandatory format for the HTML5 video tag was a big omission). This is why I think Mozilla's and Google's initial decision to restrict decoding on formats with a palatable IPR situation was the right one, given the nature of the spec. Even H.264 was problematic enough from an IPR standpoint (but that was grandfathered in, I guess).

[benwaggoner]

When it comes to video, it's because of legal roadblocks, not technical reasons. Stop trying to deflect.
There is no legal roadblock to passing off bitstreams to drivers that pass them on to hardware components that I am aware of.

From the browser's perspective, RM, WMV and QT/MOV were binary blobs to be downloaded, so it was out of scope. The problem started with the Flash Player plugin and then continued with HTML5 video tag leaving the format unspecified (nice implementable specification there folks).
Correct. And that period covers the majority of the history of video in browsers, circa 1995-2016 or so, depending on how one defines it.

For a good reason. The web is supposed to be universally accessible and universally implementable, which means it avoids patent-encumbered formats (more so patent-encumbered formats with multiple patent pools). Eventually, this boils down to whether you consider access to the web a fundamental human right. I do.
Is access to the web at stake here somehow? It seems we're more talking about "access to anything that anyone could publish to the web."

The fundamental challenge is that digital media is really complex, with heavy compute and real-time requirements. That's very different that the original goals of the web, which focused on publishing content in a way that different clients could render in ways that maximally preserve the information being presented. Stuff that requires constant heavy compute with real-time requirements was way out of scope.

Media codecs are also really complex beasts, with an enormous number of tools that need to be combined in very complex ways to provide enough improvement to merit the high costs of adopting a new format. So far, the MPEG/ISO process has, despite its many drawbacks, created codecs sufficiently superior to alternatives that they become dominant despite those limitations.

This is because Moore's Law and hand-tuned assembly and hardware DRM and vsync and lots of stuff that other web stuff doesn't require become essential.

H.263 has been patent free for decades. It was good enough for Flash and YouTube to become juggernauts. But the advancements around video codecs are too important and complex for content publishers to be happy to stick with a "good enough" format like we have with JPEG and PNG for so long.

This is how it has always been, and I don't see a clear alternative that would be long-term sustainable. Maybe if AV2 winds up being just better than VVC, sure. But we're still not going to see anyone publishing premium HDR content to web browsers without DRM, because that would cannibalize other revenue streams way more than the Linux market could add. And if somehow movie studios were forced to release their high value content in ways they can't preserve a good share of that value, we'll just have less and cheaper content made.

We have Peak TV because streaming enabled new business models that made it possible to monetize depth of engagement; before the only way to increase revenue was to increase number of viewers of ads, however apathetic they are. Anyone who prefers to make content under different business models is welcome to do so, and plenty do. Anyone who only wants to watch content produced via business models or distributed with technology they approach of is welcome to do so.

None of us have a right to make content creators make the content we want the way we want it under terms that we define.

[benwaggoner]

But anyway, you don't have to care about my opinion. Have you ever wondered why W3C didn't propose a format for the HTML5 video tag? It's because they have a principle to not include patented-encumbered technology in W3C standards, which means their views are closer to mine than yours. But since they couldn't agree on a royalty-free standard, they left it unspecified (because that totally makes sense, I guess).
There are and were able patent-free video codecs available to pick from. MPEG-1, H.263, and Theora, for example. I presume they weren't picked because they weren't good enough to be competitive, but they certainly did exist. H.263 was the dominant web codec for several years, before Flash added H.264.

Also, people here forget a good 5% of Windows users run versions older than Windows 8, which means they aren't guaranteed to have HEVC OS codecs and probably run old PCs with old GPUs without hardware HEVC decoding either. But I know, those are poor people. Who cares if they can access the web?
There is no version of Windows guaranteed to have HEVC out of the box. Pretty much all OEM systems do and have for years. But a system builder could certainly build a system that doesn't, with some effort.

[kurkosdr]

Oh ffs, what do VP8 and Theora have to do with v-sync? And when did they have any kind of issues with assembly hand-tuning (which all software decoders and encoders have)? If you are gonna post such long posts, at least try to make sense.

Also, VP8 was certainly good enough, and Theora was good enough as a fallback, and W3C could have chosen either as a mandatory format for the video tag to define an implementable HTML5 spec (which is kind of an important attribute for a spec, if you haven't noticed), but some "important" members with lots of patents in the patent pools (Apple and Microsoft) blocked that. Design-by-committee at its worst.

And no, the primary purpose of W3C is not to please content creators or care about hardware DRM, the primary purpose of W3C is to define implementable standards for the web, in case you also failed to notice.


There is no legal roadblock to passing off bitstreams to drivers that pass them on to hardware components that I am aware of.
[...]
There is no version of Windows guaranteed to have HEVC out of the box. Pretty much all OEM systems do and have for years. But a system builder could certainly build a system that doesn't, with some effort.
That's the problem here. With no mandatory format defined in the spec, the browser can't guarantee the implementation of the spec no matter what software decoders it bundles (I hope this plain fact is apparent to everyone). And passing to system codecs doesn't guarantee successful decoding either due to what you said there and the other issues mentioned in this thread. The fact Chrome and Firefox used to agree on what formats to decode offered some hope that the mess the W3C farted out as a purported standard would at least be defacto standardised, and formats with particularly bad IPR issues avoided in the process as a bonus, but nope. it's a mess that will stay that way. Can't wait until some evolution of WMV becomes an important codec for the web. Why not? If it comes into existence, there will be a system decoder for it in most Windows PCs (and Macs, since Apple will probably license it). Just pass it to the system codecs!

[kurkosdr]

Is access to the web at stake here somehow? It seems we're more talking about "access to anything that anyone could publish to the web."
According to this line of thinking, IE with its incompatible JavaScript and ActiveX wasn't breaking compatibility with other web browsers, just with something that someone could publish. But according to this line of thinking, what's the point of even having web standards?

[kurkosdr]

H.263 has been patent free for decades.
No, and certainly not for decades.
https://meta.wikimedia.org/wiki/Have_the_patents_for_h.263_expired_yet%3F

[rwill]

Well, the current situation is the following while comparing with VTM, however no comparisons were done against VVEnc: <..>

This is how VVenC stacks up against x265...

https://github.com/fraunhoferhhi/vvenc/wiki/Encoder-Performance

There seems to be no mischief going on with x265 settings as far as I can tell from the x265 command lines.
If you look at "VVenC: Runtime vs PSNR BD-rate" x265 placebo has 30% higher BD-rate than HM-16.24.
They specify the x265 command line to be "--preset {0,1,2,3,…,9} --tune psnr --crf {17,22,27,32} --keyint 1s --min-keyint 1s --profile main10 --output-depth 10", so thats PSNR tune with CRF bitrate control.

Now either HM got really good in the last couple years or x265 aged like milk or.. well I don't know. 'placebo' preset should be closer to HM really.

VTM having some SIMD optimizations now makes it less of a pushover performance wise but it still lacks threading. Adding some conservative mode decision + threading and you should end up where VVenC 'slow' is.

But I am really surprised by how bad x265 is compared against HM-16.24. And the x265 guys (those that are still left anyway) now want to make a competitive VVC encoder?

Well good luck then.

[rwill]

There are and were able patent-free video codecs available to pick from. MPEG-1, H.263, and Theora, for example. I presume they weren't picked because they weren't good enough to be competitive, but they certainly did exist. H.263 was the dominant web codec for several years, before Flash added H.264.

I am still hoping for EVC Baseline Profile to somehow get off the ground. While not patent free its supposed to be royalty free. It allows for a really tiny efficient implementation because of its small toolset.

Hoping for something remotely usable that is truly patent free in the year 2023, where almost everything promising regarding video has been at least patented twice, appears to be some sort of pipe dream to me.

[benwaggoner]

This is how VVenC stacks up against x265...

https://github.com/fraunhoferhhi/vvenc/wiki/Encoder-Performance

There seems to be no mischief going on with x265 settings as far as I can tell from the x265 command lines.
If you look at "VVenC: Runtime vs PSNR BD-rate" x265 placebo has 30% higher BD-rate than HM-16.24.
They specify the x265 command line to be "--preset {0,1,2,3,…,9} --tune psnr --crf {17,22,27,32} --keyint 1s --min-keyint 1s --profile main10 --output-depth 10", so thats PSNR tune with CRF bitrate control.
HM has always offered better quality within its limitations than x265, with epochal patience. x265 was always better in quality @ perf, and supports all the rate control, adaptive quantization, etcetera stuff needed for practical real-world encoding.

HM can absolutely be better at delivering better mean PSNR with fixed-QP, fixed GOP encoding without VBV. But that's not a thing anyone actually watches.

But I am really surprised by how bad x265 is compared against HM-16.24. And the x265 guys (those that are still left anyway) now want to make a competitive VVC encoder?
It's "bad" at stuff no x265 customers or users want to do. This is always true about reference encoders versus commercial encoders.

I expect that VVCEnC already beats the reference encoder using real-world scenarios and performance requirements. And x266 certainly would need to as well for a meaningful 1.0 release.

[benwaggoner]

I am still hoping for EVC Baseline Profile to somehow get off the ground. While not patent free its supposed to be royalty free. It allows for a really tiny efficient implementation because of its small toolset.

Hoping for something remotely usable that is truly patent free in the year 2023, where almost everything promising regarding video has been at least patented twice, appears to be some sort of pipe dream to me.
The only thing I've heard about EVC in the last few years is the base codec for the ML extensions in the MPAI-EVC project: https://mpai.community/standards/mpai-evc/about-mpai-evc/

Although MPAI seem to be pivoting focus to the newer end-to-end ML MPAI-EEV codec: https://mpai.community/standards/mpai-eev/about-mpai-eev/

[kurkosdr]

I am still hoping for EVC Baseline Profile to somehow get off the ground. While not patent free its supposed to be royalty free. It allows for a really tiny efficient implementation because of its small toolset.

Hoping for something remotely usable that is truly patent free in the year 2023, where almost everything promising regarding video has been at least patented twice, appears to be some sort of pipe dream to me.
Unfortunately, nobody wants EVC. Mozilla and Google don't want it due to the "Baseline" vs "Additional tools enabled" thing (sure, you can choose to decode without using the additional tools, but at what quality cost?), and Microsoft and Apple don't want it because it's a threat to HEVC and by extension the patents they have in HEVC.

[ksec]

I am still hoping for EVC Baseline Profile to somehow get off the ground. While not patent free its supposed to be royalty free. It allows for a really tiny efficient implementation because of its small toolset.

Hoping for something remotely usable that is truly patent free in the year 2023, where almost everything promising regarding video has been at least patented twice, appears to be some sort of pipe dream to me.

Yes. While The E stands for Essential, I could actually argued it should stand for Efficiency. How on earth did they manage to achieve something better than AVC Part 10, while simultaneously being computationally less expensive to decode. It also uses mostly H.264 era patents. And would actually becomes patents free relatively quickly. If it was combined with LC-EVC ( Another set of standard ) it would give HEVC level plus quality with a much lower complexity. But yes... a pipe dream to me as well.

[kurkosdr]

It also uses mostly H.264 era patents. And would actually becomes patents free relatively quickly. If it was combined with LC-EVC ( Another set of standard ) it would give HEVC level plus quality with a much lower complexity.
Do we have a patent list for EVC Baseline and Non-Baseline? LC-EVC?

[birdie]

https://i.ibb.co/drBKJk9/message.png

[benwaggoner]

Unfortunately, nobody wants EVC. Mozilla and Google don't want it due to the "Baseline" vs "Additional tools enabled" thing (sure, you can choose to decode without using the additional tools, but at what quality cost?), and Microsoft and Apple don't want it because it's a threat to HEVC and by extension the patents they have in HEVC.
Lots of incumbent players, including Apple, already have HEVC encode and decode capabilities, and generally a new codec has to offer >40% compression efficiency reductions to justify the huge transitional costs of shifting an ecosystem. It seems like HEVC licensing hit the "good enough" threshold while EVC didn't have path to big gains over HEVC. VVC clearly does have that path, with the >40% bitrate reduction quite feasible within the next couple of years.

Apple's done very will the the HEIC (HEVC still frame) format for photography, cutting file sizes a bunch over JPEG, and offering better quality with sharp edged and synthetic content. EVC would have had to offer something really compelling for Apple to introduce a new non-backwards compatible format.

[nakTT]

https://i.ibb.co/drBKJk9/message.png
Nice one!:thanks:

I have been waiting for x266 for while now.

[kurkosdr]

Their faq says:
What's your very rough and approximate ETA for the public x266 1.0 release?
H2 2023 is what we are looking at for the release of x266. An update will be given for the same

To me this means that they will release until 31st December 2023 or an update will be given on 1st January 2024.

Anyway, the GPL obligates them to provide source code if they release, so the only way for them to avoid releasing source code is to avoid releasing at all, basically abandon the whole project. I don't think they will do that considering the effort they've already put in.

[oibaf]

Unfortunately, nobody wants EVC. Mozilla and Google don't want it due to the "Baseline" vs "Additional tools enabled" thing (sure, you can choose to decode without using the additional tools, but at what quality cost?)...

Any source for this? I didn't find any.

[birdie]

Doesn't look like we're getting x266 this year:

Hello Artem,

Thanks for reaching out and for your continued enthusiasm. The x266 video codec development is on-going. If you have any specific requirement, please let us know. I am sure our team can help you out with the right solution. And when the x266 codec is nearing completion, we will get in touch with you!

Best Regards,
Suchithra Thyagarajan

[rwill]

(sure, you can choose to decode without using the additional tools, but at what quality cost?)

Any source for this? I didn't find any.

I think he pulled that one out of his rear as you cannot decode EVC Main Profile streams with a EVC Baseline decoder.

[rwill]

Doesn't look like we're getting x266 this year:

What a fail.

He noted your enthusiasm though. Maybe you should start a Go-Fund-Me to support their development effort. I mean Duke Nukem Forever took a while too. BTW anyone got news of Star Citizen?

[FranceBB]

I don't think they will do that considering the effort they've already put in.

This and the fact that they would upset the companies funding the development via the current x266 consortium partnership program (like the one I work for).
In other words, we will get x266, that's for sure, the only question is "when".

[rwill]

Anyway, the GPL obligates them to provide source code if they release, so the only way for them to avoid releasing source code is to avoid releasing at all, basically abandon the whole project. I don't think they will do that considering the effort they've already put in.

What makes you think they have to adhere to the GPL?

[kurkosdr]

What makes you think they have to adhere to the GPL?
All the VideoLan code that's inside. VideoLan has given them "selling exceptions" for the binaries (which allows them to distribute the binaries under a license different than the GPL), but they have to release the source code under the GPL.

[benwaggoner]

Maybe you should start a Go-Fund-Me to support their development effort. I mean Duke Nukem Forever took a while too. BTW anyone got news of Star Citizen?
I think Star Citizen is more of an example of how little can be completed despite huge developer funding!

[rwill]

All the VideoLan code that's inside. VideoLan has given them "selling exceptions" for the binaries (which allows them to distribute the binaries under a license different than the GPL), but they have to release the source code under the GPL.

I think you are mistaken.

Multicoreware is distributing x265 under a different License to their paying customers so their customers do not have to release their products under the GPL. Multicoreware paid of the x264 people for that or customers of Multicoreware have to deal with x264's commercial arm. I see no reason for Multicoreware to distribute binaries under a different license as x265 its source is available openly. Customers of Multicoreware can compile and link to it mostly freely and can keep their stuff to themself.

And I wonder where you got the information from that there is VideoLan code inside of x266. Do you have access to x266's source code? The x264 code x265 is based on has not been state of the art for a long time.
From my perspective it would be one of the first things I would replace - from a business and development perspective.

[rwill]

I think Star Citizen is more of an example of how little can be completed despite huge developer funding!

Well they completed lots of development progress videos. And Starships for this hangar thing...

This is what Star Citizen is all about right?

[kurkosdr]

I think you are mistaken.

Multicoreware is distributing x265 under a different License to their paying customers so their customers do not have to release their products under the GPL. Multicoreware paid of the x264 people for that or customers of Multicoreware have to deal with x264's commercial arm.
That's what "selling exceptions" is. A compiled binary of x265 that is distributed under a different license than the GPL (for a price) so it can be integrated into a product without the product being bound by the GPL. It can be done if you have the copyright to the entire x265, which VideoLan and MulticoreWare do. Basically a form of dual-licensing.

More info here:
https://www.fsf.org/blogs/rms/selling-exceptions
(warning: some FSF lecturing, but generally a good rundown of what it is about)

[kurkosdr]

And I wonder where you got the information from that there is VideoLan code inside of x266. Do you have access to x266's source code? The x264 code x265 is based on has not been state of the art for a long time.
From my perspective it would be one of the first things I would replace - from a business and development perspective.
Good point, but we haven't any indication they are starting from scratch either. Big rewrites tend to cost more than expected, take more time than expected, and not be better than a targeted refactoring, so there is a good chance they'll keep the existing VideoLan code inside

[kurkosdr]

I think he pulled that one out of his rear as you cannot decode EVC Main Profile streams with a EVC Baseline decoder.
First things first: You don't gain anything by being a rude twat, nor are you contributing anything to the forum. Also, I don't care what pretend indignation you're going to use as "justification" for being a rude twat.

Secondly, according to Wikipedia, EVC Main Profile "consists of a royalty-free subset (baseline) and individually switchable enhancements". Also, "each of the 21 payable (aka non-Baseline) tools can be individually turned off and, when necessary, replaced by a corresponding cost-free baseline profile tool. This structure makes it easy to fall back to a smaller set of tools in the future, if, for example, licensing complications occur around a specific tool, without breaking compatibility with already deployed decoders.". This means an EVC baseline decoder can decode EVC Main with a quality hit, right? Haven't played with an EVC encoder because I haven't found a compelling reason to, but again, the ability to have the payable tools be switchable and replaceable by cost-free aka baseline tools is the big sell of EVC.

[rwill]

I contributed by calling you out. What are you contributing to the forum by spreading misinformation about EVC?

[kurkosdr]

I contributed by calling you out. What are you contributing to the forum by spreading misinformation about EVC?
You could've said "this person made a mistake". People make honest mistakes, you know. Nobody needs a jerk who treats another person's mistake as an opportunity to be a rude twat.

Also, I still don't understand what ISO means by "individually switchable enhancements", I thought it meant that a Baseline decoder can play Main.

[rwill]

You could've said "this person made a mistake". People make honest mistakes, you know. Nobody needs a jerk who treats another person's mistake as an opportunity to be a rude twat.

I see this somewhat differently.

In my opinion, if there is something we do not need, its people that pretend they contribute facts but have themself no idea what they are talking/writing about and are thus generating unfounded rumors. And Indeed when I look around the Internet there are a lot of these people. There are people lurking this forum looking for information regarding video compression. They shouldn't have to fact check everything that is stated here - but with the amount of half-knowledged people posting here I guess they have to anyway. Here I would like to take moment to applaud oibaf for asking for a source for that statement from you above. There is also a difference between a mistake and a made up fact. Some would even argue that making up facts is a form of lying.

Now regarding calling a person out I think it does not matter how it is done foremost, but that it is done. There is nothing worse than leaving misinformation uncontested. How this is done is secondary and comes down to personal preference. I, for example, am a fanboy of clear and direct communication. I even have problems understanding what someone wants when sugar coating and gift wrapping is applied to objection.

I am sorry that you are upset about the way I brushed your statement - that Google and Mozilla don't want EVC because of EVCs Design and that it is possible to decode a Main Profile stream with a Baseline decoder - off, but that you then quote Wikipedia, come to the false conclusions based on that quote and then more or less admit that you have no knowledge about the matter at all is pretty disappointing regarding further discussion.

I am somewhat at a loss.

[kurkosdr]

Now regarding calling a person out I think it does not matter how it is done foremost, but that it is done. There is nothing worse than leaving misinformation uncontested. How this is done is secondary and comes down to personal preference. I, for example, am a fanboy of clear and direct communication. I even have problems understanding what someone wants when sugar coating and gift wrapping is applied to objection.
Nobody asked you to "sugarcoat" anything. You can be clear and direct and not be a rude twat at the same time. If you had said "made it up" instead of "pulled that one out of his rear" I wouldn't mind. Basic politeness should be a given and shouldn't take any effort on your part to achieve it.

This is more true in fuzzy subjects. For example, care to explain what do you mean by "decode"? Can an EVC Baseline decoder decode EVC Main in any capacity? Even with artifacts and dropped frames and such? Because that's "decodable". Also, that's what the whole "individually switchable coding tools" is supposed to mean, that you can skip stuff and still be able to decode the bitstream to some capacity. If ISO redefined the term you can see how it can be confusing.

[rwill]

This is more true in fuzzy subjects. For example, care to explain what do you mean by "decode"? Can an EVC Baseline decoder decode EVC Main in any capacity? Even with artifacts and dropped frames and such? Because that's "decodable". Also, that's what the whole "individually switchable coding tools" is supposed to mean, that you can skip stuff and still be able to decode the bitstream to some capacity. If ISO redefined the term you can see how it can be confusing.

This is getting better and better with each post. Have a nice day.

[kurkosdr]

This is getting better and better with each post. Have a nice day.
Look man, if you are trying to pull of the "grumpy video engineer" vibe, let me tell you it's not working. You just come off as rude.

Anyway, I'll ask someone else in some other thread what that "individually switchable coding tools" thing actually means. We are off-topic anyway.

[ksec]

Any news on x266?

[birdie]

Any news on x266?

Nothing. It's extremely delayed.

[FranceBB]

Nothing from my side either... One of my colleagues even tagged the actual guys working on it on a post on LinkedIn but they never replied... :(

[LigH]

No, this is the wrong thread. The x266 VVC encoder will be a specific encoder, and any other encoder is not the topic here. A general thread for all VVC development would be over here (https://forum.doom9.org/showthread.php?t=174940).
In your case, even creating a new thread would be suitable, as I believe you want to discuss an issue specific to this encoder you are using.

Regarding double backslashes: This may happen in programming languages like Python because a backslash is both a path separator in Windows and an escape character for special characters (C printf).

[guest]

No, this is the wrong thread. The x266 VVC encoder will be a specific encoder, and any other encoder is not the topic here. A general thread for all VVC development would be over here (https://forum.doom9.org/showthread.php?t=174940).
In your case, even creating a new thread would be suitable, as I believe you want to discuss an issue specific to this encoder you are using.

Regarding double backslashes: This may happen in programming languages like Python because a backslash is both a path separator in Windows and an escape character for special characters (C printf).

OK, thanks LigH, I will post it there, and see what happens, if that fails then I might consider starting a specific thread.

But the double backslash, would that be an error in how the app was written, or Windows...or even the version of Python.

Are there any usable VCC encoder GUI's available, yet ??

I will delete the below post.

[LigH]

The problem is not the double backslash, but rather that the converter expects a JPEG file in the Windows\system32 directory. No files should be created there by any application. It might miss a proper path to the temp.jpg file and look in default directories alternatively because it did not find it where it should have looked instead, which might be okay for required DLLs but not for data files.

Not many VVC encoders exist yet. Most are still in a testing phase and not well optimized. So there is not much incentive yet in creating a GUI for an encoder which may change rather much in the future. But searching Google for "VVC encoder GUI", I did find a few projects. And I would recommend to search the VideoHelp software archive for "VVC" too, now and then, pretty sure new ones will appear there sooner or later.

[birdie]

All GUI encoding applications suck by definition. If the OP is really interested in video encoding, they must learn to use console. It's not so difficult, children at the age of 9 do it in a few days.

[benwaggoner]

All GUI encoding applications suck by definition. If the OP is really interested in video encoding, they must learn to use console. It's not so difficult, children at the age of 9 do it in a few days.
That is probably one of the biggest changes over my career. From 1995-2010 or so, the GUI tools offered as much or more control as command line. The decline of the workstation software market and the transition to cloud-based adaptive streaming really hurt us there. The last commercial GUI tool that offered pretty much complete parameter access while offering the kind of live preview and parameter rationalization features only GUI can do well was Expression Encoder.

One could do a lot with a commercial-grade GUI to the various open and closed source libraries out there with say $5M of developer, product, UX design, and test resources. But who would collectively spend >>$5M on such a product anymore?

I tried to kick off an effort to do something like this back in 2002-2003, but my second kid was born and spending 80 hours a week to roll the dice on a startup didn't seem like a wise or practical option.

[ksec]

We are coming close to Mid Year 2024......

[rwill]

We are coming close to Mid Year 2024......

Maybe its time to "contribute a reasonable investment towards development of the x266 encoder" again.

[FranceBB]

Well, Sky (Comcast) is already in the Multicoreware partnership program and has been for years now (due to x265), so we're already playing our part I guess...

[birdie]

We are coming close to Mid Year 2024......

Multicoreware has adopted Valve time. :D

[Sirber]

The website from the original post is dead

[FranceBB]

The website from the original post is dead

Yes but the x266 page was just moved to a different page on the multicoreware website.

https://multicorewareinc.com/what-we-do/audio-video-solutions/x266-vvc-encoder/

[birdie]

The website from the original post is dead

You say the link is dead, I'd say the project is dead. :rolleyes:

They promised to release the encoder at the latest 8 months ago. Instead, there's been nothing but silence since then.

[LigH]

I could speculate that they lost developers, found new ones, and those first work on x265 features for different platforms (most commits in the last weeks were related to AArch64).

[GeoffreyA]

You say the link is dead, I'd say the project is dead. :rolleyes:

They promised to release the encoder at the latest 8 months ago. Instead, there's been nothing but silence since then.

It's disappointing. I'd think there are big problems in the encoder, so they're hesitant to release it, or perhaps it's even struggling against x265 and VVenC.

[LigH]

Or it is more profitable to first improve x265 for commercial uses before starting x266 with basic features.

[hajj_3]

Or it is more profitable to first improve x265 for commercial uses before starting x266 with basic features.

this is likely the reason as there aren't that many devices with h.266 hardware decoders so not many companies want to use it yet.

[birdie]

this is likely the reason as there aren't that many devices with h.266 hardware decoders so not many companies want to use it yet.

At the moment there are no consumer devices with a HW VVC decoder.

Intel's Lunar Lake is three weeks away and I'm far from sure it will be a smashing success.

[LigH]

Intel's Lunar Lake is three weeks away and I'm far from sure it will be a smashing success.

Laying off semiconductor experts (https://www.businesspost.ie/news/revealed-intel-offers-irish-staff-up-to-e500k-in-exit-packages-under-layoff-plan/) to preserve the Management Board???

Lunar Lake designs will be all by TSMC.

[kurkosdr]

You say the link is dead, I'd say the project is dead. :rolleyes:
I'd say the VVC format is dead. No optical disc format is using it (like 4K Blu-Ray settled on HEVC), no satellites are broadcasting in it, very few countries have terrestrial broadcasts in it, no browser supports passthrough for it (and even high-end GPUs sold today can't decode it), and very few OTT services are streaming in it. Compare this with HEVC's adoption 4 years after its finalization.

People have stocked up on HEVC-capable UHD TVs during the past 8 years, and good luck telling them that their perfectly good UHD TV (which is already receiving or streaming UHD content in HEVC) isn't good for receiving or streaming UHD because of this newfangled "VVC" thing. It's the same problem that doomed MPEG4 ASP: no new resolution came with it, and breaking existing MPEG2 SD receivers was a no-no. Also, AV1 has captured whatever niche VVC may had as the successor to HEVC in subscription streaming services like Netflix (free-to-view services like YouTube and Twitch were always out of the question for VVC).

Is developing x266 worth it to satisfy a few countries and a few OTT services? Probably not. I'd say Multicoreware has simply lost interest and has moved to the next big thing (MV-HEVC for the Vision Pro? They are gradually adding (https://bitbucket.org/multicoreware/x265_git/commits/?search=MV) MV-HEVC support in x265).

Let's see what ISO and ITU achieve with ECM.

[FranceBB]

No optical disc format is using it (like 4K Blu-Ray settled on HEVC), no satellites are broadcasting in it, very few countries have terrestrial broadcasts in it, no browser supports passthrough for it (and even high-end GPUs sold today can't decode it), and very few OTT services are streaming in it.


It will take time but they'll come.
We're just beginning to see proper software decoding support and the recent commits by Intel itself are laying the foundation of hardware decoding in the upcoming Lunar Lake integrated graphics of their CPUs and I'm sure NVIDIA will follow. If everything goes well, we're gonna have both software and hardware decoding before the end of the year. Of course, there's still no content for it, so it will take a while, but I'm sure we're gonna get there. I think that what hindered the adoption (in Europe) was a very unfortunate series of events that delayed further investments to some future date, but I'm sure we'll get there if and when 8K will become a thing.

[kurkosdr]

It will take time but they'll come.
We're just beginning to see proper software decoding support and the recent commits by Intel itself are laying the foundation of hardware decoding in the upcoming Lunar Lake integrated graphics of their CPUs and I'm sure NVIDIA will follow. If everything goes well, we're gonna have both software and hardware decoding before the end of the year. Of course, there's still no content for it, so it will take a while, but I'm sure we're gonna get there. I think that what hindered the adoption (in Europe) was a very unfortunate series of events that delayed further investments to some future date, but I'm sure we'll get there if and when 8K will become a thing.
8K is a solution looking for a problem to solve, so I wouldn't bet on it, even outside Europe.

Also, broadcasters are still finishing the transition to HEVC, and the ones that haven't started the transition want to use the existing installed base of UHD TVs sold over the past 8 years, telling people they should buy decoder boxes for their new or newish UHD TVs is a tough sell. A few countries have announced VVC plans, but they are the exception. Much like with MPEG4 ASP vs MPEG2, nobody wants to break compatibility with an existing huge installed base for 25~30% gains.

Let's see what ECM achieves. At least it'll be worth the compatibility breakage.

Anyway, my main point is: look at the clues. Multicoreware is more pre-occupied with adding MV-HEVC to x265 than bother to give an update for x266. Whatever demand for VVC encoding there is out there, it's less even compared to boutique stuff like spatial videos for the Vision Pro (which isn't exactly flying off the shelves).

[rwill]

look at the clues

You seem to be drawing certain conclusions from the "clues" for the industry. Like that implementing MV-HEVC is currently more important than working on a VVC encoder.

Now I am drawing different conclusions from the "clues" for MCW. Because most other commercial HEVC encoders got MV-HEVC over a year ago and those companies now all have a more or less working VVC encoder implementation.

[GeoffreyA]

Leaving out broadcasting, I think it's important to consider VVC in relation to AV1. The latter has archieved a fair bit of usage; it plays all right on most computers and devices; there is hardware decoding in current C/GPUs; post-2020 TVs tend to play it; and people, like anime encoders and, ahem, "others," have got familiar with the tools.

VVC, on the other hand, beats AV1 by a fraction, if Fraunhofer's encoder is representative. (Thankfully, there is now encoding in FFmpeg and decoding in players, though in diminution of this, Matroska demuxing hasn't been implemented, hindering usage in anime.) So, why break compatibility, or familiarity, for a small improvement? Indeed, that question still plays out with AV1 and HEVC a lot of the time.

As kurkosdr points out, it reminds me of MPEG-4 ASP and MPEG-2, where the gains were too small, despite DivX's marketing and later adoption in hardware. Then, when H.264 came out, there was no contest; it left older formats in the dust.

[LigH]

Remember, there is also uvg266 (https://forum.doom9.org/showthread.php?t=184093) as useable VVC encoder. It may not support the whole range of features in depth but is worth trying as casual alternative.

[GeoffreyA]

Remember, there is also uvg266 (https://forum.doom9.org/showthread.php?t=184093) as useable VVC encoder. It may not support the whole range of features in depth but is worth trying as casual alternative.

Thanks. I haven't tried that one yet.

[ksec]

VVC, on the other hand, beats AV1 by a fraction,


I guess people have different definition of fraction. But I see average around 10% BD-Rate and up to 20% when compared to AV1. And that is against an AV1 encoder that is quite well tuned.

And we may actually see more VVC hardware Encoder in camera and smartphone than AV1.

[GeoffreyA]

I guess people have different definition of fraction. But I see average around 10% BD-Rate and up to 20% when compared to AV1. And that is against an AV1 encoder that is quite well tuned.

And we may actually see more VVC hardware Encoder in camera and smartphone than AV1.

To be sure, there is a clear visual difference, and the picture is sharper and more consistent within the frame. I much prefer it. AV1, at least mainline aom, loses a lot of details and overdoes it with temporal filtering (which has occasional defects, too, when applied to keyframes and must be adjusted). There's a new SVT-AV1-PSY fork that I want to try, though, and their low-luminance quantisation dropping got merged into mainline. At any rate, I have looked forward to VVC for years but feel disappointed these days how everything has gone.

[ksec]

Time of the year to ask if x266 code name Duke Nukem Forever will come.

[birdie]

Time of the year to ask if x266 code name Duke Nukem Forever will come.

https://m.media-amazon.com/images/I/41x244sdEXL._AC_UF894,1000_QL80_.jpg

:p

[GeoffreyA]

The truth---or source code---is out there :)

[quietvoid]

Apparently they're still working on it: https://www.youtube.com/watch?v=GE4xMNnMEyE

[microchip8]

This is the way...

[rwill]

What does "Average Speedup 0.01x" mean ? I have a suspicion but cannot be sure.

[Z2697]

What does "Average Speedup 0.01x" mean ? I have a suspicion but cannot be sure.

I think it means the x266 is 100x slower than x265, or x266 is 100x faster than VTM. (x265 is also ~100x faster than HM)
Which one is you suspect?

[birdie]

Apparently they're still working on it: https://www.youtube.com/watch?v=GE4xMNnMEyE

It's alive!!

Why is it a very low bitrate 720p stream, I've no idea.

What does "Average Speedup 0.01x" mean ? I have a suspicion but cannot be sure.

It means it's 100 times slower. One of the slides says:

"Additional ASM and performance Optimization" (sic)

Looks like they started relatively late, maybe a year ago. Of course they couldn't show us anything at the beginning of 2024.

[birdie]

The most pertinent details from the clip above.

I wonder how x266 compares to svt-av1-psy/libaom and VVenc.

Comparisons were made at a very high bitrate, so there's hope that x266 won't blur everything like VVEnc/libaom do by default.

[rwill]

I think it means the x266 is 100x slower than x265, or x266 is 100x faster than VTM. (x265 is also ~100x faster than HM)
Which one is you suspect?

I suspect its ~100x slower than x265.

And one thing I tried to reproduce was the x265 Netflix-Tango YUV PSNR of 41.7db but whatever I do at veryslow or placebo I fail. Their x265 must have much better performance than the binary I got.

[Z2697]

If that's true why they call 100x slower 0.01x speedup LOL.
I don't think it's really 100x slower. Even VVenC is not 100x slower than x265.
(We can throw reference encoder out of the window)

There are ASM optimizations already in x266, according to the "enabled features" slide in that video.

[ksec]

The most pertinent details from the clip above.

I wonder how x266 compares to svt-av1-psy/libaom and VVenc.

Comparisons were made at a very high bitrate, so there's hope that x266 won't blur everything like VVEnc/libaom do by default.

Well at least the Samsung clip is 4.8Mbps for 4K 60Fps. I think that is pretty low bitrate if you ask me. Youtube serve 1080P 50fps with VP9 at 4Mbps.

Would be interesting to see how it compares, but AV1 is now extremely weak tuned, while x266 doesn't even have all of its features implemented yet.

[GeoffreyA]

If that's true why they call 100x slower 0.01x speedup LOL.
I don't think it's really 100x slower. Even VVenC is not 100x slower than x265.
(We can throw reference encoder out of the window)

There are ASM optimizations already in x266, according to the "enabled features" slide in that video.

It looks like it's relative to x265. So that could be a trick way of obscuring the number. Surprising for it to be 100x slower, but perhaps they're using preset placebo or something.

VVenC was up and running and in the public's hands almost five years ago. x266 really has its work cut out for it.

[Z2697]

I'm being (maybe too) optimistic ;)

[GeoffreyA]

I'm being (maybe too) optimistic ;)

Dark Shikari and akupenguin are sorely needed to come back and do some codec magic in 2025 :)

[FranceBB]

Dark Shikari and akupenguin are sorely needed to come back and do some codec magic in 2025 :)

It would be a dream, but unfortunately I don't really see Jason ever making a comeback... :(
There's been a lot going on in his personal life and he even changed name (I won't comment further on this out of respect). I don't personally know him, but there are still people here who have been knowing him for a long time and they hinted at this a while ago.

But... you know, although highly unlikely, I'd say "never say never"... We've seen Avisynth legends like Didee and Dogway making a comeback, so who knows...

Regardless, he will forever be considered a legend on Doom9 for everything he has done (and not only around here but pretty much everywhere on the web).

[benwaggoner]

I suspect its ~100x slower than x265.

And one thing I tried to reproduce was the x265 Netflix-Tango YUV PSNR of 41.7db but whatever I do at veryslow or placebo I fail. Their x265 must have much better performance than the binary I got.
If they're testing PSNR, they might have used --tune psnr?

[benwaggoner]

Dark Shikari and akupenguin are sorely needed to come back and do some codec magic in 2025 :)
It would be nice, but they didn't have much of a role in x265, or anything with x264 for more than a decade.

Lots of good stuff here: https://web.archive.org/web/20121221131527/http://x264dev.multimedia.cx/

[rwill]

If they're testing PSNR, they might have used --tune psnr?

This is very likely, but so have I.

The most simple command would be:

./x265 --input Netflix_Tango_4096x2160_60fps_10bit_420.y4m --profile main10 --tune psnr --bitrate 10900 --pass 1 -o trash.265 --preset veryslow --psnr -I 300
./x265 --input Netflix_Tango_4096x2160_60fps_10bit_420.y4m --profile main10 --tune psnr --bitrate 10900 --pass 2 -o trash.265 --preset veryslow --psnr -I 300


For this I get a Global YUV PSNR of 40.8045db.

I got the Netflix_Tango sequence from Derf's collection.

[Z2697]

.5 more to go
had to use pbratio=1.4 to get into < 10900 kbps bitrate
with default pbratio the bitrate is 11197.41 kbps psnr is 41.263
I use the same source downloaded from Derf's collection, I just encoded it with x264 lossless fastdecode (it really get slow to decode without it)

>ffmpeg -v 0 -i X:\Netflix_Tango_4096x2160_60fps_10bit_420.lossless.mkv -f yuv4mpegpipe -strict -1 - | x265 --input - --y4m^
--profile main10 --qp 29 --tune psnr --psnr -oNUL -I300 --rdoq 2 -b3 --asm avx512 --ref 6 --tu-intra-depth 2 --tu-inter-depth 2^
--limit-refs 0 --rd 6 --no-early-skip --no-strong-intra-smoothing --subme 7 --max-merge 5 --pbratio 1.4

y4m [info]: 4096x2160 fps 60/1 i420p10 sar 1:1 unknown frame count
raw [info]: output file: NUL
x265 [info]: HEVC encoder version 4.1+96-5de5f564
x265 [info]: build info [Windows][clang 19.1.7][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 AVX512
x265 [info]: Main 10 profile, Level-6 (Main tier)
x265 [info]: Thread pool created using 32 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 6 / wpp(34 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 2 inter / 2 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 7 / 5
x265 [info]: Keyframe min / max / scenecut / bias : 30 / 300 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 20 / 3 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 6 / off / off
x265 [info]: Rate Control : CQP-29
x265 [info]: tools: rd=6 rdoq=2 rskip mode=1 signhide tmvp b-intra lslices=8
x265 [info]: tools: deblock sao dhdr10-info
x265 [info]: frame I: 1, Avg QP:26.00 kb/s: 57963.36 PSNR Mean: Y:40.464 U:48.380 V:46.834
x265 [info]: frame P: 74, Avg QP:29.00 kb/s: 25317.55 PSNR Mean: Y:39.710 U:47.284 V:45.060
x265 [info]: frame B: 219, Avg QP:31.33 kb/s: 5735.02 PSNR Mean: Y:39.524 U:47.394 V:45.138
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%

encoded 294 frames in 61.10s (4.81 fps), 10841.60 kb/s, Avg QP:30.73, Global PSNR: 41.242

[rwill]

the bitrate is 11197.41 kbps psnr is 41.263 [...]

[some other run:]

encoded 294 frames in 61.10s (4.81 fps), 10841.60 kb/s, Avg QP:30.73, Global PSNR: 41.242


Please note that what x265 reports as the Global PSNR is not what one expects when wanting the Global YUV PSNR, that encoders like VVEnc or such report. I have not searched really hard but never have seen Multicorewares way of calculating it somewhere else - whatever it is, it not the Global YUV PSNR and results in higher values most of the time.

You should use a third party tool to calculate the true Global YUV PSNR to be able to compare it to other encoders.

[Z2697]

double globalPsnr = (m_analyzeAll[layer].m_psnrSumY * 6 + m_analyzeAll[layer].m_psnrSumU + m_analyzeAll[layer].m_psnrSumV) / (8 * m_analyzeAll[layer].m_numPics);


I thought you are using x265's PSNR calculation because you used --psnr

in FFmpeg the plane weights are calculated by their resolution:

sum = 0;
for (j = 0; j < s->nb_components; j++)
sum += s->planeheight[j] * s->planewidth[j];
average_max = 0;
for (j = 0; j < s->nb_components; j++) {
s->planeweight[j] = (double) s->planeheight[j] * s->planewidth[j] / sum;
average_max += s->max[j] * s->planeweight[j];
}


Which is a bit weird, the chroma planes (which have higher PSNR) have higher weights in FFmpeg, but the final average PSNR is lower... maybe it's because FFmpeg is averaging the MSE then calculate PSNR at the end, rahter than averaging PSNR? I have no idea.


av_log(ctx, AV_LOG_INFO, "PSNR%s average:%f min:%f max:%f\n",
buf,
get_psnr(s->mse, s->nb_frames, s->average_max),
get_psnr(s->max_mse, 1, s->average_max),
get_psnr(s->min_mse, 1, s->average_max));
}


Anyway, if they are comparing two of their encoders, I assume that doesn't hurt. x266 should have the same way of PSNR calculation as x265.

[ksec]

It would be a dream, but unfortunately I don't really see Jason ever making a comeback... :(
There's been a lot going on in his personal life and he even changed name (I won't comment further on this out of respect). I don't personally know him, but there are still people here who have been knowing him for a long time and they hinted at this a while ago.

But... you know, although highly unlikely, I'd say "never say never"... We've seen Avisynth legends like Didee and Dogway making a comeback, so who knows...

Regardless, he will forever be considered a legend on Doom9 for everything he has done (and not only around here but pretty much everywhere on the web).

I know money isn't everything and I am not a millionaire that could bootstrap the whole thing. But I could easily see myself donating a thousand dollar just to see this dream come true. I am sure if we get enough company and people together the sum of money could be something.

I really want another encoder that takes the no nonsense approach. As a matter of fact I wish they could be back to work on x264 in a way that breaks H.264 limitation but in a completely patent free way.

[filler56789]

<!-- snip -->

Well, you really should not expect Dark Shikari to return if you insist on being a proud transphobe...

I know this is "off-topic", but so are your misplaced ""thoughts"" or ""opinions"".

[/END_OF_DISCUSSION]

[FranceBB]

I know money isn't everything and I am not a millionaire that could bootstrap the whole thing. But I could easily see myself donating a thousand dollar just to see this dream come true. I am sure if we get enough company and people together the sum of money could be something.

Speaking of money, I'm a technical guy, not a financial guy, so I don't know what the agreement between Comcast / Sky and Multicoreware is, but all I know is that we're sponsoring the development and I'm very proud that the company I work for is using some of the revenues to finance open source projects. :)

[kurkosdr]

<!-- snip -->

I know this is "off-topic", but so are your misplaced ""thoughts"" or ""opinions"".

[/END_OF_DISCUSSION]
And what you don't understand is that you can't drop in the middle of a conversation, accuse someone else of being <whatever>, provide zero context, and then unilaterally end the discussion, not without coming off as a complete and utter moron.

And yes, I know my post is also insulting, but since this is apparently allowed, I might as well join the fun.

[kurkosdr]

Dark Shikari and akupenguin are sorely needed to come back and do some codec magic in 2025 :)
What are the chances even fairly techy people owning VVC-capable hardware? Why would they spend effort improving an encoder for a standard they probably can't play? x264 benefited from all that H.264 decoding hardware in GPUs, as well as H.264 being the chosen format for HD resolutions in most consumer electronics. This meant volunteers had an incentive to improve x264 to see better pictures on their hardware. But for UHD resolutions (and HDR content), this spot is now occupied by HEVC and to a degree AV1.

In this sense, it's good that x266 is commercially sponsored, since we may eventually see it happening. Who knows, it might prove useful in the future.

[Z2697]

What are the chances even fairly techy people owning VVC-capable hardware? Why would they spend effort improving an encoder for a standard they probably can't play? x264 benefited from all that H.264 decoding hardware in GPUs, as well as H.264 being the chosen format for HD resolutions in most consumer electronics. This meant volunteers had an incentive to improve x264 to see better pictures on their hardware. But for UHD resolutions (and HDR content), this spot is now occupied by HEVC and to a degree AV1.

In this sense, it's good that x266 is commercially sponsored, since we may eventually see it happening. Who knows, it might prove useful in the future.

You knew software decoders do exist, right?
That being said, having HW decoder is certainly better.

[kurkosdr]

You knew software decoders do exist, right?
That being said, having HW decoder is certainly better.
Hmm... Can VVC be decoded in software without having the latest and greatest CPU? And with what software?

[FranceBB]

There are two main software decoders: VVDec and Libav.
The latter was created later compared to VVDec and was originally written in plain C, but then it got manually written intrinsics in assembly and it has been closing the gap over the last year.
In particular, the open source decoder inside libav was written by Nou Mi and Frank Plowman. I was able to chat to them both but in particular Frank recently held a workshop at Sky in which he detailed what led to the creation of the decoder and how to detect issues with it.

https://i.imgur.com/223V2te.png


The reason why this is particularly important is that when they introduced the decoder, it ended up spreading everywhere, from Avisynth and VapourSynth indexers like LWLibavVideoSource() and FFVideoSource(), to players like MPV and VLC and of course FFMpeg itself which is used pretty much universally. It was a major thing. When it was first released, it surely struggled to decode videos on most CPUs, but then again, it was just plain C without any assembly, while nowadays the picture is very different.

Here's the decoding benchmark (and remember that you only really need the fps to match the one of the content when you're actually watching something and not indexing to re-encode):


Test 1:
Chicago Fire FULL HD H266 Main10 12Mbits 25p YV12 BT709 SDR 10bit AC3 2ch 48000Hz.ts

120 fps
Intel Xeon E5-2637 v4 3.50GHz dual socket 8c/16th, 64GB RAM

111 fps
Intel i7 5930K 3.50GHz single socket 6c/12th 32GB RAM


Test 2:
Judas and the Black Messiah SD H266 Main10 3Mbits 25p YV12 BT601 SDR 10bit AC3 2ch 48000Hz.ts

620 fps
Intel Xeon E5-2637 v4 3.50GHz dual socket 8c/16th, 64GB RAM

631 fps
Intel i7 5930K 3.50GHz single socket 6c/12th 32GB RAM

Test 3:
The Creator FULL HD H266 Main10 12Mbits 25p YV12 BT709 SDR 10bit AC3 2ch 48000Hz.ts

121 fps
Intel Xeon E5-2637 v4 3.50GHz dual socket 8c/16th, 64GB RAM

116 fps
Intel i7 5930K 3.50GHz single socket 6c/12th 32GB RAM


If you need the samples let me know and I'll send them over (trimmed down obviously, not the whole thing). To test it yourself you just need to download the latest version of MPV from master ;)
I'll generate some UHD files too to see how well it copes, but the future definitely looks exciting, software wise. :)

[Z2697]

Frank recently held a workshop at Sky in which he detailed what led to the creation of the decoder and how to detect issues with it.


I'm very curious about the details here, there's patchset for libvvdec (and libvvenc) inclusion as 3rd party components before the native vvc decoder, at least what we can see in public ffvvc fork.
Eventually libvvenc did get into official FFmpeg, but not libvvdec.

vvdec is still faster than libav vvcdec, by 1.37x (1T) or more depending on the requested threads, on Zen 5.
I think FFmpeg has a "tradition" of implementing MPEG decoders natively AND not support 3rd party ones?
(while VP series have libvpx and libdav1d as well as native VP9 and AV1(HW decoding only))

Is it OK for you to share some stories?

[GeoffreyA]

I'm very curious about the details here, there's patchset for libvvdec (and libvvenc) inclusion as 3rd party components before the native vvc decoder, at least what we can see in public ffvvc fork.
Eventually libvvenc did get into official FFmpeg, but not libvvdec.

vvdec is still faster than libav vvcdec, by 1.37x (1T) or more depending on the requested threads, on Zen 5.
I think FFmpeg has a "tradition" of implementing MPEG decoders natively AND not support 3rd party ones?
(while VP series have libvpx and libdav1d as well as native VP9 and AV1(HW decoding only))

Is it OK for you to share some stories?

There was some mild controversy a few years back about using vvdec. Nuo Mi argued that it would speed up work getting the infrastructure ready for the native decoder, which was already being developed at that time.

[GeoffreyA]

But... you know, although highly unlikely, I'd say "never say never"... We've seen Avisynth legends like Didee and Dogway making a comeback, so who knows...

Regardless, he will forever be considered a legend on Doom9 for everything he has done (and not only around here but pretty much everywhere on the web).

I agree, it's unlikely. But never say never!

I really want another encoder that takes the no nonsense approach. As a matter of fact I wish they could be back to work on x264 in a way that breaks H.264 limitation but in a completely patent free way.

Indeed, there's probably compression and quality to be had by backporting some modern techniques to x264.

[ksec]

Hmm... Can VVC be decoded in software without having the latest and greatest CPU? And with what software?

Hmm...... VVC is already being software decoded on Smartphone for nearly 3 years in Apps for certain regions.

[GeoffreyA]

Hmm...... VVC is already being software decoded on Smartphone for nearly 3 years in Apps for certain regions.

With libdav1d, we've seen what continuous optimisation can achieve, so FFmpeg's VVC decoder could, in theory, reach something similar.

[Z2697]

As a matter of fact I wish they could be back to work on x264 in a way that breaks H.264 limitation but in a completely patent free way.

When you break H.264 limitation in a certain way you've essentially created... H.265.
Or anything. It will be a new codec anyway.
New codec means incompatible with existing decoders, you need to at least hack the decoder for it to work.

[birdie]

Test 1:
Chicago Fire FULL HD H266 Main10 12Mbits 25p YV12 BT709 SDR 10bit AC3 2ch 48000Hz.ts

120 fps
Intel Xeon E5-2637 v4 3.50GHz dual socket 8c/16th, 64GB RAM

111 fps
Intel i7 5930K 3.50GHz single socket 6c/12th 32GB RAM

Test 3:
The Creator FULL HD H266 Main10 12Mbits 25p YV12 BT709 SDR 10bit AC3 2ch 48000Hz.ts

121 fps
Intel Xeon E5-2637 v4 3.50GHz dual socket 8c/16th, 64GB RAM

116 fps
Intel i7 5930K 3.50GHz single socket 6c/12th 32GB RAM



1080p and such massive beasts of CPUs don't really look too good IMO.

Would be great if you compared ffmpeg's native H266 decoder with VVdec.

[BlueSwordM]

To be honest, these numbers are not great, but the CPUs aren't great anymore; they're not massive beasts anymore.

The 5930K is Haswell, and Xeon E5 v4 chips are Broadwell.

[benwaggoner]

Indeed, there's probably compression and quality to be had by backporting some modern techniques to x264.
What do you mean by " no nonsense approach?"

Arguably, x264's brilliance was from ignoring PSNR and focusing on all sorts of nonsense like adaptive quantization, psychovisually weighted QP, tuning for anime content, etc. It was really a big departure from how encoders had traditionally been designed and tuned, by a very different set of people than normally worked on encoders historically.

We can forget what a brilliant weirdo x264 was sometimes because so many of its crazy ideas inspired so much that followed that they seem obvious and standard in retrospect.

But CRF and MB-Tree were not obvious before x264 implemented them. Single pass at constant perceptual quality but VBV enforcement was also very novel.

[rwill]

We can forget what a brilliant weirdo x264 was sometimes because so many of its crazy ideas inspired so much that followed that they seem obvious and standard in retrospect.

Did not take long for the industry to go full "VMAF approved" style after that. I blame people being too lazy to look at their videos after encoding, they just want the computer to say "its ok" and be done.

[LigH]

will not mention MVCD or KVCD ever again :o

[ksec]

When you break H.264 limitation in a certain way you've essentially created... H.265.
Or anything. It will be a new codec anyway.
New codec means incompatible with existing decoders, you need to at least hack the decoder for it to work.

Indeed incompatible, I am thinking a much higher resources usage, but patent free / patent expired codec. I think Main Profile is near Patent Free, we are a few more years till High Profile is mostly patent free as well.

With Larger block size, macroblock, more / higher aggressive transform adaptivity basically brute force everything we have in H.264. I am wondering if we could reach compression that is HEVC+.

[benwaggoner]

Did not take long for the industry to go full "VMAF approved" style after that. I blame people being too lazy to look at their videos after encoding, they just want the computer to say "its ok" and be done.
Well, it sure would be so convenient to have an AI that tunes quality based on ratings from an AI that rates quality!

Alas, quality is only as good as humans perceive it to be, not AIs, and subjective correlation still isn't great. P1204.3 can outdo VMAF, but they are both ML-trained metrics and such reliant on the quality of their ground truth training data. VMAF was quite limited originally by being tested only on a relatively small set of x264 variations (mainly just varying CRF and frame size).

But AI optimizing for AI scoring can yield some weird results. For example, as VMAF excludes chroma, enabling chroma qp offset turning for VMAF will make chroma look much worse in exchange for slightly improved luma.

And no one has a good, practical metric for noise/grain similarity yet.

[kurkosdr]

Indeed incompatible, I am thinking a much higher resources usage, but patent free / patent expired codec. I think Main Profile is near Patent Free, we are a few more years till High Profile is mostly patent free as well.

With Larger block size, macroblock, more / higher aggressive transform adaptivity basically brute force everything we have in H.264. I am wondering if we could reach compression that is HEVC+.
It seems like you are looking to make something like EVC Baseline. Can't you use EVC Baseline instead? An open-source encoder and decoder called "xeve" exists.

Problem is hardware support for standalone players. OEMs add support for formats only when they are needed to implement some headline feature.

[Z2697]

It seems like you are looking to make something like EVC Baseline. Can't you use EVC Baseline instead? An open-source encoder and decoder called "xeve" exists.

Problem is hardware support for standalone players. OEMs add support for formats only when they are needed to implement some headline feature.

I think the point is x264-level quality, both the encoding outcome and the design of encoder itself.
XEVE is not of that level of quality... yet? Or will it?

[kurkosdr]

I think the point is x264-level quality, both the encoding outcome and the design of encoder itself.
XEVE is not of that level of quality... yet? Or will it?
The authors of xeve claim better-than-x264-level quality for EVC Baseline: https://github.com/mpeg5/xeve

So it can probably achieve x264-level quality.

[benwaggoner]

The authors of xeve claim better-than-x264-level quality for EVC Baseline: https://github.com/mpeg5/xeve

So it can probably achieve x264-level quality.
It's impossible to extrapolate without knowing how the other encoders were tuned. The "twice as good as HEVC" seems really, really implausible, particularly given that we have much more mature HEVC encoders available, like x265.

As always: https://web.archive.org/web/20141103202912/http://x264dev.multimedia.cx/archives/472

[benwaggoner]

The authors of xeve claim better-than-x264-level quality for EVC Baseline: https://github.com/mpeg5/xeve

So it can probably achieve x264-level quality.
Based on codec features, yeah, I suspect an equivalently well optimized EVC Baseline could outperform x264.

x264 has a crazy amount of optimization for a wide variety of use cases and content types, so making something in x264's ballpark is pretty monumental class. x265 itself got a big head start by building on top of x264's source code and algorithms.

[birdie]

Multicoreware Inc. claims the x266 encoder is not dead (https://multicorewareinc.com/beyond-x265-and-on-to-x266/) while providing zero new information about the state of its development.

[soresu]

Mmmph, sounds like they probably had little interest in putting any significant resource into x266, until they saw the AV2 announcement and got spooked.

[rwill]

Hey if you need some samples of what EVC Baseline is capable of just drop a request with the link to the (clean plz) source here.

[LigH]

I remember Jamaika providing xeve/xevd for a longer while, and MABS can compile it and link it into ffmpeg. But EVC is somewhere in between, by far not as complex as VVC.

[rwill]

I remember Jamaika providing xeve/xevd for a longer while, and MABS can compile it and link it into ffmpeg. But EVC is somewhere in between, by far not as complex as VVC.

Was this in response to my post? Because I would not use xeve to encode.

[LigH]

Yes.

Is there any serious reason why you discourage the use of xeve?

[rwill]

Xeve is untuned and is missing a lot of things state of the art encoders have.

[Z2697]

Was this in response to my post? Because I would not use xeve to encode.

Is it your in-house encoder? Could you perhaps drop *cough* *cough* an executable? ;)

Unlikely things aside, I think Big Buck Bunny or Tears of Steel is good for a "widedly accepted benchmark".

[LigH]

I would like to suggest to continue talk about EVC in the related thread:

EVC - Essential Video Coding / MPEG-5 (https://forum.doom9.org/showthread.php?t=176055)

But I am no moderator. So it is just a private suggestion...

[rwill]

So, I encoded that Tears of Steel and Stem2 linked in Bens HEVC Encoding Challenge thread with my EVC Encoder with the settings we agreed on there.

Here are the results:

Stem2: https://drive.google.com/file/d/1O3gvz0M_w6958dnYB0ZFHYSxX3azXlQU/view?usp=sharing

Tears of Steel: https://drive.google.com/file/d/1OxhckgOvOiND5AsvfNMLIN0ufmp9skBo/view?usp=sharing

So the fanbois can wait until x265 and maybe x266 reach that kind of quality stability - if ever.

Did I mention that my encoders are developed for "to scale" so that they fix quality problems themselves in later passes when doing multipass? Just start the job and fetch the expected result later. No more handcrafted streams. Long way to go for some certain other encoder developer I guess.


So because its EVC, to play the streams in realtime in a player, the most easiest way is to convert them to a playable format like AVC or HEVC.
With xevd, x265 and mp4box being freely available one way to do it, for Stem2, would look like this:


xevdb_app.exe -i stem2_3840x2160_4mbit.evc -s --output-bit-depth 10 -o dec_3840x2160_10b.yuv

./x265-10b.exe --input dec_3840x2160_10b.yuv --input-res 3840x2160 --input-depth 10 --fps 24000/1001 --sar 1 --hrd --aud --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --max-cll "10000,400" --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" --preset slow --tune ssim --crf -8.0 -b 3 --b-pyramid --b-adapt 0 --ssim --psnr -o temp.265

mp4box -add temp.265 -new stem2_3840x2160_4mbit_playable.mp4


There will be a small generational loss but nothing big.

[Z2697]

So, I encoded that Tears of Steel and Stem2 linked in Bens HEVC Encoding Challenge thread with my EVC Encoder with the settings we agreed on there.

Here are the results:

Stem2: https://drive.google.com/file/d/1O3gvz0M_w6958dnYB0ZFHYSxX3azXlQU/view?usp=sharing

Tears of Steel: https://drive.google.com/file/d/1OxhckgOvOiND5AsvfNMLIN0ufmp9skBo/view?usp=sharing

So the fanbois can wait until x265 and maybe x266 reach that kind of quality stability - if ever.

Did I mention that my encoders are developed for "to scale" so that they fix quality problems themselves in later passes when doing multipass? Just start the job and fetch the expected result later. No more handcrafted streams. Long way to go for some certain other encoder developer I guess.


So because its EVC, to play the streams in realtime in a player, the most easiest way is to convert them to a playable format like AVC or HEVC.
With xevd, x265 and mp4box being freely available one way to do it, for Stem2, would look like this:


xevdb_app.exe -i stem2_3840x2160_4mbit.evc -s --output-bit-depth 10 -o dec_3840x2160_10b.yuv

./x265-10b.exe --input dec_3840x2160_10b.yuv --input-res 3840x2160 --input-depth 10 --fps 24000/1001 --sar 1 --hrd --aud --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --max-cll "10000,400" --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" --preset slow --tune ssim --crf -8.0 -b 3 --b-pyramid --b-adapt 0 --ssim --psnr -o temp.265

mp4box -add temp.265 -new stem2_3840x2160_4mbit_playable.mp4


There will be a small generational loss but nothing big.

I'm not sure there's much fanboism going on. It's just what we got, unless you can release your encoders.

XEVD does support y4m output though, if the space is not a concern (probably, your commands are using YUV medium file already) we can output Y4M and directly play it.
When you are doing your own testing, do you have better ways to play it, maybe some industiral hardware, or your secret sauce decoder?

And what's the "fix quality problems themselves" really mean? Doesn't the x264 multipass already fix some problems with single pass ABR?

[rwill]

I'm not sure there's much fanboism going on. It's just what we got, unless you can release your encoders.


Well or the community bands together again, forks x265 or starts fresh, and make something truly open source. Its really sad, I know quite some people that would be able to contribute to x265 but won't due to Multicorewares contribution policy.


XEVD does support y4m output though, if the space is not a concern (probably, your commands are using YUV medium file already) we can output Y4M and directly play it.
When you are doing your own testing, do you have better ways to play it, maybe some industiral hardware, or your secret sauce decoder?


I do not recommend to play back the raw file because harddrives are kinda slow. I also do not recommend to write raw video on SSDs because of their wear level. When the players I use do not support a format I, most of the time, use shorter clips where the raw video fits into RAM and I play that without lag.


And what's the "fix quality problems themselves" really mean? Doesn't the x264 multipass already fix some problems with single pass ABR?

The goal is that each additional pass makes the result better in regards to VBV constrained bit distribution problems and converging to a consistent quality target for the whole sequence while removing artifacts that might be perceived as disrupting. Now most amateur users of x264/x265 don't care about VBV and CRF bitrate control is producing ok'ish consistent quality. Problems arise with x26x when trying to do professional encodes that have certain constraints. Professional employees are paid by the hour so tweaking video settings to work around a quality problem, which can take hours or even days, is to be avoided.

[LigH]

Is there any sane reason to post all of this in a thread about a future x266 encoder despite EVC not being VVC even, instead of in a thread about EVC?

[rwill]

Is there any sane reason to post all of this in a thread about a future x266 encoder despite EVC not being VVC even, instead of in a thread about EVC?

Hausmeister.