x266 VVC Encoder

[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]

Originally Posted by LigH

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.

Originally Posted by PCU

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).

Originally Posted by PCU

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]

Originally Posted by FranceBB

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.

Originally Posted by 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.

Is the Fraunhofer free to test?

[birdie]

Originally Posted by PCU

Is the Fraunhofer free to test?

Would be great if you at least 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]

Originally Posted by birdie

Would be great if you at least 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 as a custom All-In-One encoder application (similar to ffmpeg) for an example...

[birdie]

Originally Posted by PCU

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...master/COPYING

[kurkosdr]

Originally Posted by benwaggoner

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]

Originally Posted by FranceBB

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]

Originally Posted by kurkosdr

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.

Originally Posted by kurkosdr

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).

Originally Posted by kurkosdr

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...

Originally Posted by kurkosdr

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...

Originally Posted by kurkosdr

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.

Originally Posted by kurkosdr

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]

Originally Posted by kurkosdr

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]

Originally Posted by benwaggoner

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" 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.

Originally Posted by benwaggoner

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).

Originally Posted by benwaggoner

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.

Originally Posted by benwaggoner

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

AV1 supports 10-bit and HDR.

Originally Posted by benwaggoner

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]

Originally Posted by lvqcl

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]

Originally Posted by kurkosdr

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.

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]

Originally Posted by benwaggoner

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.

Originally Posted by benwaggoner

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...

Originally Posted by benwaggoner

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.

Originally Posted by benwaggoner

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.

Originally Posted by benwaggoner

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.

Originally Posted by benwaggoner

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.

Originally Posted by benwaggoner

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.