Versatile Video Coding (VVC) / H.266: HEVC successor

[Z2697]

I suddenly have this idea that a codec (the specification) is free doesn't necessarily mean that it's less profitable.
I mean, the commercial encoding solutions or whatever, and technical support.
Those who don't want to invest money into it, have the choice, unlike royalties, of course.

Just my conspiracy theory perhaps :rolleyes:

[birdie]

Too little too late?

https://accessadvance.com/2025/01/16/access-advance-announces-video-distribution-patent-pool-in-response-to-market-demand/

Access Advance Announces Video Distribution Patent Pool in Response to Market Demand
Pool Covers Internet Streaming of the HEVC, VVC, AV1, and VP9 Video Codecs in a Single License

Responding to growing market demand for an industry solution for codec licensing in the video distribution market, Access Advance LLC (“Advance”) is pleased to announce the launch of its Video Distribution Patent (“VDP”) Pool.

The VDP Pool will build upon the success of Advance’s existing HEVC and VVC Advance Patent Pools, which are supported by a substantial majority of video codec implementers and patent owners. It will provide a single one-stop-shop license, covering internet streaming with all four of the most recently developed video codecs (i.e., HEVC, VVC, AV1, and VP9) available today, with fixed tiered pricing scaled to the size of the video distributor’s business. This structure provides simplicity and predictability to internet video distributors, allowing them to choose which codec(s) to use based on technical and business merits rather than royalty costs or the need to negotiate multiple licenses.

[kurkosdr]

Too little too late?

https://accessadvance.com/2025/01/16/access-advance-announces-video-distribution-patent-pool-in-response-to-market-demand/

This is just for video distribution (aka for "content fees"), it doesn't concern vendors of encoders or decoders (so it doesn't concern implementers of encoders and decoders like Nvidia), and it's just one patent licensing entity of the many for VVC. Also, we don't know pricing.

The interesting bit is that Access Advance thinks they have patents essential for VP9 and AV1 video streaming in this patent pool. Will the patent holders go after Google (YouTube) for "content fees"? The patent holders in the Sisvel pools haven't gone after anyone despite their VP9 and AV1 patent pools being several years old by now, but I guess I am in the wrong thread for that (edit: created a thread (https://forum.doom9.org/showthread.php?t=186099))

[benwaggoner]

This is just for video distribution (aka for "content fees"), it doesn't concern vendors of encoders or decoders (so it doesn't concern implementers of encoders and decoders like Nvidia), and it's just one patent licensing entity of the many for VVC. Also, we don't know pricing.
Ambiguity in "content fees" is what can kill the encoder and decoder businesses though, as it can prevent demand for either.

[kurkosdr]

Ambiguity in "content fees" is what can kill the encoder and decoder businesses though, as it can prevent demand for either.
And that ambiguity is still there for VVC, Access Advance is merely 1 out of the 20 (https://forum.doom9.org/showthread.php?p=2009192#post2009192) patent licensing entities for VVC. Each of the remaining 19 has the right to demand its own distribution royalty ("content fee").

Generally, when it comes to streaming, I expect HEVC to be the end of the line for "FRAND" standards designed to step on as many patents as possible to achieve marginal gains (which is what the ISO and ITU video standards essentially are) and the future of streaming belongs to standards designed to step on zero patents if possible (excluding patents made available on a royalty-free basis). Internet speeds are getting better every year, so the streaming industry doesn't see the need to negotiate with 20 different licensing entities for marginal compression performance gains. I am even willing to bet Netflix could walk back HEVC if they could (they can't for back compat reasons) and VVC has even more greed around it than HEVC.

[benwaggoner]

And that ambiguity is still there for VVC, Access Advance is merely 1 out of the 20 (https://forum.doom9.org/showthread.php?p=2009192#post2009192) patent licensing entities for VVC. Each of the remaining 19 has the right to demand its own distribution royalty ("content fee").

Generally, when it comes to streaming, I expect HEVC to be the end of the line for "FRAND" standards designed to step on as many patents as possible to achieve marginal gains (which is what the ISO and ITU video standards essentially are) and the future of streaming belongs to standards designed to step on zero patents if possible (excluding patents made available on a royalty-free basis). Internet speeds are getting better every year, so the streaming industry doesn't see the need to negotiate with 20 different licensing entities for marginal compression performance gains. I am even willing to bet Netflix could walk back HEVC if they could (they can't for back compat reasons) and VVC has even more greed around it than HEVC.
Well, there's no arguing that MPEG is still making really good codecs. VVC offers great compression efficiency gains with relatively minor decode complexity increases. It certainly offers better efficiency than AV1 with lower decoder complexity. They've been pretty disciplined about only allowing in tools that offer worthwhile bitrate savings for the complexity.

But yeah, entirely decoupling technical design from IP questions has, in my personal opinion, failed for a couple of generations in a row now, and I don't see how taking the same approach for H.267 wouldn't yield the same problems.

And the classic MPEG approach failed with MPEG-4 part 2 as well. It was really only with MPEG-2 and AVC/H.264 where we wound up with a single patent pool with reasonable published terms that companies felt reasonably safe with (although there certainly was patent litigation anyway). The failure of Pt. 2 and the competition from VC-1 seemed to get H.264 patent holders scared enough to work together. I'm not sure why the threat of AV1/AV2 isn't doing the same thing today. The explosion of non-practicing entities resulting in a lot of IP is owned by companies without any stake in the ecosystem beyond rent extraction seems a likely factor.

I'm very glad to be a technologist with personal opinions, not someone whose day job is dealing with this IP stuff!

[birdie]

Has anyone tried Mainconcept's VVC encoder/decoder?

https://blog.mainconcept.com/mainconcept-vvc/h.266-decoder-overview-of-key-features-and-capabilities

In related news FFMpeg is getting serious about optimizing their VVC decoder:

https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2025#VVCwasmsimdoptimization

[Z2697]

It certainly offers better efficiency than AV1 with lower decoder complexity.

But if you look at the actual implementations, the dav1d decoder is even faster than (or at least very close to) FFmpeg libavcodec HEVC decoder, so I think there's no way that VVC can have better decoding performance.

[birdie]

But if you look at the actual implementations, the dav1d decoder is even faster than (or at least very close to) FFmpeg libavcodec HEVC decoder, so I think there's no way that VVC can have better decoding performance.

Citations needed. I don't think it's even close.

[Z2697]

Citations needed. I don't think it's even close.

Just from my own test. And you can do you own test as well if you don't trust me (which, you shouldn't, erm, trust so easily?)

A comparison of two video streams made by svt-av1 and x265 with same source content, similar bitrate and similar encoding speed, shows that the single thread decoding speed of dav1d is faster than libavcodec hevc, but multi thread performance is lower (but the CPU usage is scaling roughly "on par", I mean, dav1d is slower but also utilizes less CPU).

Of course, the comparison is FAR from ideal, there're so many things affecting the decoding speed, the different codec specification is already like night and day, and the partitioning, motion compensation etc etc... it's just too much noise.
I can't think of a way to make it more ideal, sadly.

But anyway, the dav1d is optimized like crazy, it seems.

[ksec]

I think it would be fair to say if HEVC decoder had similar optimisation of dav1d it would be faster / lower resources. The thing is dav1d has crazy amount of Assembly code in it and still getting even more assembly optimisation as of now. There are some cases dav1d is even faster than AVC decode.

Anyway back to VVC. I cant wait to see Brazil’s ambitious TV 3.0 using VVC + LCEVC together. I gather the rest of the Broadcasting world ( Europe and Japan ) are waiting for their results as well before moving forward. As I believe this is the first time a system has been designed with both OTA and OTT together. ( Not OTA plus OTT, but both having same weight. ) Latest VVC+LCEVC shows additional 40% Bitrate reduction on top of VVC on 4K materials. Large field test in 2025 and Full commercial deployment in 2026.

[kurkosdr]

Latest VVC+LCEVC shows additional 40% Bitrate reduction on top of VVC on 4K materials. Large field test in 2025 and Full commercial deployment in 2026.
So, what bitrates are we talking about for VVC+LCEVC? Assuming 25Mbps for HEVC 4K HDR10.

[Z2697]

I think it would be fair to say if HEVC decoder had similar optimisation of dav1d it would be faster / lower resources. The thing is dav1d has crazy amount of Assembly code in it and still getting even more assembly optimisation as of now. There are some cases dav1d is even faster than AVC decode.

Anyway back to VVC. I cant wait to see Brazil’s ambitious TV 3.0 using VVC + LCEVC together. I gather the rest of the Broadcasting world ( Europe and Japan ) are waiting for their results as well before moving forward. As I believe this is the first time a system has been designed with both OTA and OTT together. ( Not OTA plus OTT, but both having same weight. ) Latest VVC+LCEVC shows additional 40% Bitrate reduction on top of VVC on 4K materials. Large field test in 2025 and Full commercial deployment in 2026.

Yeah, so I restricted it to actual implementations specifically, because we all know how the theoretical performance compares.

[benwaggoner]

I think it would be fair to say if HEVC decoder had similar optimisation of dav1d it would be faster / lower resources. The thing is dav1d has crazy amount of Assembly code in it and still getting even more assembly optimisation as of now. There are some cases dav1d is even faster than AVC decode.
Yeah, software HEVC was never that big a thing as HEVC adoption was driven by hardware DRM & decoding scenarios. AV1 has had a much slower adoption ramp and is intrinsically a lot more complex, and so it's gotten a lot of sustained optimization over years.

Anyway back to VVC. I cant wait to see Brazil’s ambitious TV 3.0 using VVC + LCEVC together. I gather the rest of the Broadcasting world ( Europe and Japan ) are waiting for their results as well before moving forward. As I believe this is the first time a system has been designed with both OTA and OTT together. ( Not OTA plus OTT, but both having same weight. ) Latest VVC+LCEVC shows additional 40% Bitrate reduction on top of VVC on 4K materials. Large field test in 2025 and Full commercial deployment in 2026.
It is exciting indeed!

I do wonder how Brazil is dealing with the IP licensing of VVC.

[john33]

....

I do wonder how Brazil is dealing with the IP licensing of VVC.

I understand from a Brazilian friend that in order for patents, etc., to be recognised/acknowledged in Brazil, they have to be filed in Brazilian Portuguese. If they are not, they are ignored!

[kurkosdr]

I understand from a Brazilian friend that in order for patents, etc., to be recognised/acknowledged in Brazil, they have to be filed in Brazilian Portuguese. If they are not, they are ignored!
That's not unique to Brazil, Chinese patents have to be filed in Chinese, Japanese patents in Japanese etc. Some patent offices allow patents to be first filed in English (and the translation to follow some months later), but not exclusively in English.

As an aside, patents are only valid in the country that issues them, outside that country, they aren't worth the paper they are printed on. So, if you want your invention to be patented in a certain number of countries, you have to file on the patent office of every one of those countries separately. There are of course the EP patents, which apply to more than one country, but that's just only for some countries. And even then, some EPO countries (such as Greece) require a full translation within three months of the grant date to the country's official language for an EP patent to be considered valid in the country.

Lawyer firms have people that do the translation and also know how to file on the patent offices of all "important" countries and the EPO. It's also why MPEG LA's patent lists are so long btw, because one invention may be listed as several patents (of different countries).

Now, how will Brazil deal with the licensing requirements? They will pay a royalty to each licensing entity, duh.

[john33]

I think we both know the answer to that one!

[kurkosdr]

I think we both know the answer to that one!
Huh? I don't understand your post. But anyway, my point is, there is no magic way around SEP (https://en.wikipedia.org/wiki/Essential_patent) royalties just because you are not in the US. Companies that contribute inventions to standards organizations are smart enough to file in every "important" country.

Even software such as VLC exists because French law has a specific carve-out for computer software, other stuff still pays royalties.

[LigH]

New uploads: [Windows][GCC 14.2.0][64 bit]

Fraunhofer VVC Encoder ver. 1.13.1-rc1 (https://www.mediafire.com/file/jsp2ln2bl7azgrn/vvenc_1.13.1-rc1-9169430.7z/file) 9169430

Fraunhofer VVC Decoder ver. 3.0.0 (https://www.mediafire.com/file/enam7g8n323rq2u/vvdec_3.0.0-ea7d0af.7z/file) ea7d0af

[birdie]

Recent takes on VVC (https://streaminglearningcenter.com/articles/mile-high-video-2025-industry-leaders-discuss-vvc-adoption-challenges-and-opportunities.html) by various companies and individuals:

Jean-Baptiste Kempf, VLC
Q: A subject near and dear to both of us is VVC. We spoke about a year ago, and you said “VVC was dead.” I was surprised the latest version of FFmpeg had a VVC decoder in it. So, all jokes aside, what are you seeing from the industry regarding VVC adoption in the companies you work with now?
A: It’s the same, really. Unfortunately, I think the VVC use cases are too small and not interesting enough to become a massive thing. And the patent situation is even worse than the last one (HEVC), so for me it’s not compelling enough for mass adoption. But at the same time – as you know – I’m actually the one who sponsored the VVC decoder in FFmpeg, because the goal of FFmpeg (and VLC) is to support everything. That doesn’t mean I believe the codec is good or not; that’s not my problem. As a technical person, as head of VLC and an active member of MPEG, we support everything new. We need to support it. We support things like VP6, VP7, VP8, even VP9. (Those codecs are far less useful!) But I still think we’ll see a dual track of H.264 and AV1 in many cases. I feel that VP8 and VP9 will slowly give way to AV1, and that HEVC will stick around for broadcasting. Outside of broadcast, it’s just going to be H.264 and AV1. I’m not very optimistic about mass adoption of VVC or other newer codecs.

Thierry Fautier, Your Media Transformation
Q: In 60 seconds or less, what are your predictions about VVC?
A: VVC: great technology, poor adoption — and I cannot fix that. I’m not going to get into the patent discussion, but it’s a typical example. You saw my post recently on LinkedIn saying that for mobile devices it was AVC and HEVC for encoders. VVC… nobody’s touching it because it’s too complicated. The good news is that a VVC decoder on mobile does work: Alibaba presented a very decent implementation up to 4K. But if I want to encode, can I do it? No. (And I know your next question is going to be about the next codec. If we can’t sell VVC, how are we going to sell the next generation?) It’s remarkable to me that they’re even pursuing it, but I don’t want to go there.
Q: So you don’t see VVC having an impact? Is it never going to succeed?
A: You cannot say “never” — and don’t quote me on that — but I’d say VVC had high expectations and not too much results so far.
Q: So far, or ever?
A: Not so far. I think Brazil will launch it. Japan will make an 8K channel with it, but it’s not impactful. What I’d like to hear is the Chinese community saying, “We cannot use American technology, so let’s lean on VVC.” VVC would then be a huge success in China and maybe beyond China… maybe.

Will Law, Akamai
Q: How much interest are you seeing in VVC?
A: To be honest, not much, especially on the CDN side. Everyone’s practical. H.264 is still the dominant codec we deliver. There’s some uptake in HEVC, especially for 4K content now, but VVC is very, very little. More AV1 would be the third one in the mix. As a CDN, we’re codec-agnostic; we see MP4 containers, but we don’t know what’s inside. A lot of people ask for stats — surely we know who’s playing what. We don’t. We would have to dig into customer data and parse their objects to figure out the codecs they’re using. It’s a privacy issue and computationally too expensive to perform that kind of analysis.

In related news:

NHK develops ‘world first’ VVC-compatible real-time multi-layer video encoder (https://www.tvbeurope.com/media-management/nhk-develops-world-first-vvc-compatible-real-time-multi-layer-video-encoder)
The encoder can compress sub-content in real-time, using multi-layer encoding, which results in two videos being able to play via a single broadcast channel

[Z2697]

How is VVC not American technology? I mean it probably should be a "global technology" but using it for "no uncle sam" sounds like not practical.
China has AVS (https://en.wikipedia.org/wiki/Audio_Video_Standard) mainly for broadcasting but there's no real use case outside of broadcasting.

[ksec]

How is VVC not American technology? I mean it probably should be a "global technology" but using it for "no uncle sam" sounds like not practical.
China has AVS (https://en.wikipedia.org/wiki/Audio_Video_Standard) mainly for broadcasting but there's no real use case outside of broadcasting.

Somewhat counterintuitively VVC is pretty much Chinese. Most of the contribution in H.266 came from China, either Bytedance, Tencent, Alibaba or some other Chinese companies. With some input from Qualcomm and a few other EU companies. There are still US companies representatives in the H.266 development, but in terms of actual R&D it is pretty much Chinese + Japanese + EU.

Most of the US companies went with AOM.

Interestingly, may be Thierry Fautier doesn't know. Tencent is already trialing VVC streaming. Just not widely adopted yet

Q: I heard from another interviewee that China was not adopting anything from the Alliance for Open Media (like AV1) because they prefer open standards. Is that what you’re saying about China and VVC adoption?
A: China is indeed a market where things might go faster than in other parts of the world. There’s also the next-generation broadcast initiative in Brazil (TV 3.0) where VVC is in the toolbox. So there are a couple of places where I think the interest in VVC is more concrete at this point.

[GeoffreyA]

Somewhat counterintuitively VVC is pretty much Chinese. Most of the contribution in H.266 came from China, either Bytedance, Tencent, Alibaba or some other Chinese companies. With some input from Qualcomm and a few other EU companies. There are still US companies representatives in the H.266 development, but in terms of actual R&D it is pretty much Chinese + Japanese + EU.

Most of the US companies went with AOM.

Interestingly, may be Thierry Fautier doesn't know. Tencent is already trialing VVC streaming. Just not widely adopted yet

Any technology with wider involvement is welcome, particularly with the rise of economic nationalism west of the Atlantic, but at the end of the day, the proof of the pudding is in the eating. In a world without AV1, VVC would have likely gained more interest.

[Z2697]

I mean, China's "three letter agencies" have AVS that's better suited for that purpose.
The companies? They are free to use whatever they want, and for some reason they like to "show off" / bluff that very well. Maybe because many of them are / have streaming platforms.
(Just see how many Made in China encoders are in the MSU test recent years)
And they have a lot of AV1 stuff as well.

(Talking about MSU, I think its reference value is declining super fast, presumably after all those chinese companies joined the show and topping off the charts. I respect the developers and efforts that put into those encoders, but it's genuinely hard to believe they really are THAT performant. But you don't have any publically available executable to verify the result.)

[modus-ms325c]

In a world without AV1, VVC would have likely gained more interest.actually VVC would still be avoided like the plague, leading to AVC still being used regardless of anything.
plus, tech companies would've scrambled to rush out a video codec that's easier to adopt while putting on a show pretending that their shiny new codec is actually much better than MPEG's offerings.

all-in-all, doesn't matter anymore. if VVC can be declared dead owing to patent situations making it difficult/impossible to even use it, let's just follow suit by calling it such, dance on its "corpse", have a ball at doing so, and call it a day.

[kurkosdr]

actually VVC would still be avoided like the plague, leading to AVC still being used regardless of anything.
Most people forget that, when it comes to free-to-view web video, AVC is the exception, not the rule. We were largely using VP6 and VP7 before AVC (commonly packaged in flv files), not MPEG4 ASP, and we are now using VP9 and what became of VP10 (AV1) as the successor to AVC, not HEVC or VVC.

For one bright moment in time, the patent holders behind an ISO format (AVC) came together and collectively waived content fees for free-to-view web video, making VP8 irrelevant. But again, that was the exception to the rule. It was VP formats before that, and it's VP formats after that. Even without AOM, we'd still have gotten new VP formats from On2 Technologies, but arguably not as good.

[Z2697]

Most people forget that, when it comes to free-to-view web video, AVC is the exception, not the rule. We were largely using VP6 and VP7 before AVC (commonly packaged in flv files), not MPEG4 ASP, and we are now using VP9 and what became of VP10 (AV1) as the successor to AVC, not HEVC or VVC.

For one bright moment in time, the patent holders behind an ISO format (AVC) came together and collectively waived content fees for free web video, making VP8 irrelevant. But again, that was the exception to the rule. It was VP formats before that, and it's VP formats after that. Even without AOM, we'd still have gotten new VP formats from On2 Technologies, but arguably not as good.

I was just simply not born yet that time :o
But I think it weren't that long between the dawn of (free) online video streaming and the adpotion of AVC as the major codec.

[edison]

https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/refs/heads/release/7.1:/Changelog

version 7.1:
- Raw Captions with Time (RCWT) closed caption demuxer
- LC3/LC3plus decoding/encoding using external library liblc3
- ffmpeg CLI filtergraph chaining
- LC3/LC3plus demuxer and muxer
- pad_vaapi, drawbox_vaapi filters
- vf_scale supports secondary ref input and framesync options
- vf_scale2ref deprecated
- qsv_params option added for QSV encoders
- VVC decoder compatible with DVB test content
- xHE-AAC decoder
- removed DEC Alpha DSP and support code
- VVC encoding support via libvvenc
- perlin video source
- D3D12VA HEVC encoder
- Cropping metadata parsing and writing in Matroska and MP4/MOV de/muxers
- Intel QSV-accelerated VVC decoding
- MediaCodec AAC/AMR-NB/AMR-WB/MP3 decoding
- YUV colorspace negotiation for codecs and filters, obsoleting the
YUVJ pixel format
- Vulkan H.264 encoder
- Vulkan H.265 encoder
- stream specifiers in fftools can now match by stream disposition
- LCEVC enhancement data exporting in H.26x and MP4/ISOBMFF
- LCEVC filter
- MV-HEVC decoding
- minor stream specifier syntax changes:
- when matching by metadata (:m:<key>:<val>), the colon character
in keys or values now has to be backslash-escaped
- in optional maps (-map ....?) with a metadata-matching stream specifier,
the value has to be separated from the question mark by a colon, i.e.
-map ....:m:<key>:<val>:? (otherwise it would be ambiguous whether the
question mark is a part of <val> or not)
- multiple stream types in a single specifier (e.g. :s:s:0) now cause an
error, as such a specifier makes no sense
- Mastering Display and Content Light Level metadata support in hevc_nvenc
and av1_nvenc encoders
- libswresample now accepts custom order channel layouts as input, with some
constrains
- FFV1 parser

Which Intel GPU support QSV VVC decoding?

[olduser217]

Somewhat counterintuitively VVC is pretty much Chinese. Most of the contribution in H.266 came from China, either Bytedance, Tencent, Alibaba or some other Chinese companies. With some input from Qualcomm and a few other EU companies. There are still US companies representatives in the H.266 development, but in terms of actual R&D it is pretty much Chinese + Japanese + EU.

Most of the US companies went with AOM.

Interestingly, may be Thierry Fautier doesn't know. Tencent is already trialing VVC streaming. Just not widely adopted yet

https://www.lexisnexisip.com/wp-content/uploads/2024/07/2024-LexisNexis-Versatile-Video-Coding-Technology-Report.pdf

It seems like Qualcomm is still one of the largest, if not the largest contributor & patent holder related to VVC.

According to the report, VVC is probably more like an Asian dominant standard, rather than "pretty much Chinese", since both Japan & South Korea (and dont' forget Mediatek from Taiwan as well) have a lot of contributions and patents related to it as well.

[olduser217]

I mean, China's "three letter agencies" have AVS that's better suited for that purpose.
The companies? They are free to use whatever they want, and for some reason they like to "show off" / bluff that very well. Maybe because many of them are / have streaming platforms.
(Just see how many Made in China encoders are in the MSU test recent years)
And they have a lot of AV1 stuff as well.


Interestingly, AV1 is used by one of the largest video sharing website (bilibili) in China, together with AVC & HEVC.

[Z2697]

https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/refs/heads/release/7.1:/Changelog

version 7.1:
- Raw Captions with Time (RCWT) closed caption demuxer
- LC3/LC3plus decoding/encoding using external library liblc3
- ffmpeg CLI filtergraph chaining
- LC3/LC3plus demuxer and muxer
- pad_vaapi, drawbox_vaapi filters
- vf_scale supports secondary ref input and framesync options
- vf_scale2ref deprecated
- qsv_params option added for QSV encoders
- VVC decoder compatible with DVB test content
- xHE-AAC decoder
- removed DEC Alpha DSP and support code
- VVC encoding support via libvvenc
- perlin video source
- D3D12VA HEVC encoder
- Cropping metadata parsing and writing in Matroska and MP4/MOV de/muxers
- Intel QSV-accelerated VVC decoding
- MediaCodec AAC/AMR-NB/AMR-WB/MP3 decoding
- YUV colorspace negotiation for codecs and filters, obsoleting the
YUVJ pixel format
- Vulkan H.264 encoder
- Vulkan H.265 encoder
- stream specifiers in fftools can now match by stream disposition
- LCEVC enhancement data exporting in H.26x and MP4/ISOBMFF
- LCEVC filter
- MV-HEVC decoding
- minor stream specifier syntax changes:
- when matching by metadata (:m:<key>:<val>), the colon character
in keys or values now has to be backslash-escaped
- in optional maps (-map ....?) with a metadata-matching stream specifier,
the value has to be separated from the question mark by a colon, i.e.
-map ....:m:<key>:<val>:? (otherwise it would be ambiguous whether the
question mark is a part of <val> or not)
- multiple stream types in a single specifier (e.g. :s:s:0) now cause an
error, as such a specifier makes no sense
- Mastering Display and Content Light Level metadata support in hevc_nvenc
and av1_nvenc encoders
- libswresample now accepts custom order channel layouts as input, with some
constrains
- FFV1 parser

Which Intel GPU support QSV VVC decoding?

I think it's currently only on the Lunar Lake (mobile chips), not even on the same generation desktop chips, not to say the Arc video cards... so that euqals to... nothing? Anyone buying Lunar Lake?

(I guess "not to say" isn't quite fit in here, because Arc Battlemage was release after Lunar Lake... but you get the point, right? (am I getting the timeline correct?))

[GeoffreyA]

actually VVC would still be avoided like the plague, leading to AVC still being used regardless of anything.
plus, tech companies would've scrambled to rush out a video codec that's easier to adopt while putting on a show pretending that their shiny new codec is actually much better than MPEG's offerings.

all-in-all, doesn't matter anymore. if VVC can be declared dead owing to patent situations making it difficult/impossible to even use it, let's just follow suit by calling it such, dance on its "corpse", have a ball at doing so, and call it a day.

I think AVC hit critical mass in the field of encoding, and HEVC tightened it up a bit. Both haven't been matched in transparent encoding. AV1 found its place in low-bitrate encoding and anime (though HEVC still leads in the latter). As for VVC, well, I lament that the baby was stillborn, especially as one who awaited its birth and rapid growth to adulthood.

[excellentswordfight]

I think AVC hit critical mass in the field of encoding, and HEVC tightened it up a bit. Both haven't been matched in transparent encoding. AV1 found its place in low-bitrate encoding and anime (though HEVC still leads in the latter). As for VVC, well, I lament that the baby was stillborn, especially as one who awaited its birth and rapid growth to adulthood.
Yeah, at least HEVC could ride on the UHD and HDR wave, pretty much forcing any content provider interested in those two to use HEVC. Whats the USP for VVC? Yes, yes, 640K ought to be enough for anyone and so on, but tbh with 4k/UHD/HDR/HEVC I think we are starting to get to the top of the s curve were diminishing returns is very much in effect. I think the only killer feature today would be a clear savings cost, either from licensing and or encoding/decoding/distrubution cost.

[GeoffreyA]

I think it's currently only on the Lunar Lake (mobile chips), not even on the same generation desktop chips, not to say the Arc video cards... so that euqals to... nothing? Anyone buying Lunar Lake?

(I guess "not to say" isn't quite fit in here, because Arc Battlemage was release after Lunar Lake... but you get the point, right? (am I getting the timeline correct?))

Seems to be only Lunar Lake (https://www.guru3d.com/story/intel-is-the-first-to-support-h266-vvc-decoding-ahead-of-nvidia-and-amd/) at present. As far I can tell, the media engine of discrete Battlemage (https://www.techpowerup.com/review/intel-arc-b580/41.html) doesn't have VVC decoding. I imagine the cards were finalised with the earlier media engine, or at least the B580 was, whereas the CPU SoC division had the newer one included earlier in development. By the way, the B580 turns out to be an excellent GPU, the best in its category from a price point of view. If it had VVC decoding, that would have been a cherry on top.

[GeoffreyA]

Yeah, at least HEVC could ride on the UHD and HDR wave, pretty much forcing any content provider interested in those two to use HEVC. Whats the USP for VVC? Yes, yes, 640K ought to be enough for anyone and so on, but tbh with 4k/UHD/HDR/HEVC I think we are starting to get to the top of the s curve were diminishing returns is very much in effect. I think the only killer feature today would be a clear savings cost, either from licensing and or encoding/decoding/distrubution cost.

I agree that we're hitting a limit; I don't know what the exact numbers are, but surely, the human eye is nearing saturation. Will 8K be placebo in the home? Streaming and broadcasting have different concerns, but for us encoders, what we need from modern codecs is H.264/5 calibre at post-AV1 sizes, something contemporary codecs are not providing.

[kurkosdr]

I think the only killer feature today would be a clear savings cost, either from licensing and or encoding/decoding/distrubution cost.
There would be a case for reduction of distribution costs with VVC if the patent holders charged reasonable "content fees", but this isn't the case, in fact the patent holders have split themselves into 20 separate entities or so to maximize the royalties they could milk without technically running afoul of FRAND, so as distributor and you have to negotiate a "content fee" with each one. Good luck with that. Also keep in mind that internet bandwidth and storage get cheaper over time, while the patent holders responsible for the VVC licensing mess are getting greedier over time (VVC has double the patent-licensing entities of HEVC, and it might get even worse).

The streaming industry shifted to AV1 as its post-HEVC standard and that's it. The broadcast industry is stuck in HEVC for the foreseeable future (and some of it is still trying to get rid of MPEG2) so they aren't relevant to the VVC discussion, save for a few countries.

[benwaggoner]

I agree that we're hitting a limit; I don't know what the exact numbers are, but surely, the human eye is nearing saturation. Will 8K be placebo in the home?[-/QUOTE]
8K is already placebo for moving images, where motion blur eliminates any use of the actual precision. We tested carefully selected 8K 10-bit uncompressed 24p moving image content, viewed by expert golden eye viewers in an A/B/A/B comparison. There were a couple of clips where people sitting 55" form a 65" TV who had 20/10 vision could tell the difference.

Literally no consumer will be able to tell you if something is 4K or 8K while watching something without a reference.

For very static, sharp stuff like looking at text on a computer, it's possible for some people to tell, but people also lean in very close with computers. There being value at >>24 fps hasn't been disproven, but by definition that will only matter where there is motion and thus motion blur, so it seems unlikely. And has 100/120 fps is a sports thing, Even having a real-time 8Kp120 encoder that can produce flawless sharp quality at distribution bandwidth is many years away.

[Streaming and broadcasting have different concerns, but for us encoders, what we need from modern codecs is H.264/5 calibre at post-AV1 sizes, something contemporary codecs are not providing.
Really, the only place where modern encoders can deliver flawless quality at practical bitrates is with film grain or other random noise. The killer feature of AV1 could have been Film Grain Synthesis, but a reliable infrastructure of encoders and complain decoders hasn't emerged (a lot of early AV1 products had broken FGS, because there weren't any conformance tests available yet).

Now that is becoming a general standard that could be applied to any codec, so it's not AV1 specific (it's not in-loop, just metadata driven post processing). Hopefully AV2 will get universally compatible decoders so it could be an on-by-default option there at least.

AV1's FGS + VVC, or MPEG FGS + VVC are both technically viable too, with some good demos already done.

[benwaggoner]

There would be a case for reduction of distribution costs with VVC if the patent holders charged reasonable "content fees", but this isn't the case, in fact the patent holders have split themselves into 20 separate entities or so to maximize the royalties they could milk without technically running afoul of FRAND, so as distributor and you have to negotiate a "content fee" with each one. Good luck with that. Also keep in mind that internet bandwidth and storage get cheaper over time, while the patent holders responsible for the VVC licensing mess are getting greedier over time (VVC has double the patent-licensing entities of HEVC, and it might get even worse).

The streaming industry shifted to AV1 as its post-HEVC standard and that's it. The broadcast industry is stuck in HEVC for the foreseeable future (and some of it is still trying to get rid of MPEG2) so they aren't relevant to the VVC discussion, save for a few countries.
That's overstated. The user generated content industry (Facebook, YouTube) has tried to shift to AV1 where possible, as software decode without HW DRM is viable for them.

In premium content, it exists from both Netflix and Prime Video, given the installed base of decoders, there's no way that most premium HDR content isn't still delivered in HDR. We're still having mid-tier mobile devices and some TVs being launched without AV1 support. Once they're pretty much universal, we'll have AV1 mostly available in mobile within four years and in living room within ten years. But it's still a while before it could be even half of premium content.

Still, at a big enough scale, saving 30% of bandwidth costs on 20% of sessions can be more than enough savings to justify the effort. Of course, you'll get increased encoding and storage costs for the time being, as you can't stop using HEVC or even H.264 within the next few years, so AV1 would be an additional thing, not a replacement.

[GeoffreyA]

Really, the only place where modern encoders can deliver flawless quality at practical bitrates is with film grain or other random noise. The killer feature of AV1 could have been Film Grain Synthesis, but a reliable infrastructure of encoders and complain decoders hasn't emerged (a lot of early AV1 products had broken FGS, because there weren't any conformance tests available yet).

Now that is becoming a general standard that could be applied to any codec, so it's not AV1 specific (it's not in-loop, just metadata driven post processing). Hopefully AV2 will get universally compatible decoders so it could be an on-by-default option there at least.

AV1's FGS + VVC, or MPEG FGS + VVC are both technically viable too, with some good demos already done.

That's interesting, Ben, about the testing at 8K. It confirms my suspicions that the biological limit is being reached. A good thing, so we can put effort elsewhere. As for high frame rates, it's much in demand these days. I find it disagreeable for non-gaming content; there's a different feeling, losing that film effect, along with a mental strain, as if I would get a headache. Drop back to 24 and it's normal. No doubt, there is some early neurological training at play here.

Indeed, grain or random noise is the main challenge to video codecs, and proper film-grain synthesis could address this. Being an implementation problem, it will improve as time goes by.

[benwaggoner]

That's interesting, Ben, about the testing at 8K. It confirms my suspicions that the biological limit is being reached. A good thing, so we can put effort elsewhere. As for high frame rates, it's much in demand these days. I find it disagreeable for non-gaming content; there's a different feeling, losing that film effect, along with a mental strain, as if I would get a headache. Drop back to 24 and it's normal. No doubt, there is some early neurological training at play here.
24p seems pretty indelible for scripted content, although people like James Cameron try higher from time to time.

Where very high frame rates shine is sports. 120 is better for lots of people than 60, even.

Indeed, grain or random noise is the main challenge to video codecs, and proper film-grain synthesis could address this. Being an implementation problem, it will improve as time goes by.
No doubt. I'm not sure we've nailed it yet, but we should within a decade.

[birdie]

The State of the Video Codec Market 2025 (https://www.streamingmediaglobal.com/Articles/Editorial/Featured-Articles/The-State-of-the-Video-Codec-Market-2025-168627.aspx)

VVC is still DOA.

There are a few realities worth noting about the percentages shown in Figure 1. First, you’ll realize those savings only when streaming to compatible platforms, which will be well short of 100% of the time. Second, you’ll realize those savings only at the top rung of your encoding ladder—which, in fairness, is typically the most widely viewed rung. However, if you distribute lots of middle-rung content to mobile devices, you’ll be swapping a 2Mbps H.264 rung for a 2Mbps AV1 rung. The video should look better, improving the QoE for your viewers, but you’ll see no bandwidth savings.

In addition, as bandwidth costs drop, the savings drop as well. Twenty years ago, when it cost $0.50 to deliver a GB of video, a 50% savings was substantial. Today, BlazingCDN offers low-volume pricing starting at around $0.005/GB, making the bandwidth savings worth 100 times less today.

Beyond reduced savings, most codec proponents ignore the cost side of the equation. Before deploying a new codec, you have significant testing costs; if you have your own encoding pipeline, you have integration and testing costs. After deployment, you have the additional transcoding costs since you typically can’t drop one codec because you’re adopting another. The costs are all additive. You also have additional storage costs for the transcoded files and decreased caching efficiency at the edge because you may have to cache multiple versions of the encoded file for full coverage.

For VVC, almost 100% of TVs don't support HW VVC decoding and their SoCs are too weak to support it in software. For mobile users, again no HW support, so VVC videos will kill your battery.

Maybe 50 thousand or so Lunar Lake owners? Nope, that won't work for PC/laptop users either.

Looks like VVC will not be adopted in anything consumer any time soon or maybe ever.

Oh, what about the [warez] scene? Nothing. Completely ignored because the encoder is crazy slow.

[Blue_MiSfit]

I was fairly impressed with Spin Digital's live 9 (?) Mbps 4kp60 HDR VVC encode at NAB. It resoundingly outperformed NVENC AV1 and x265 at equal speed, despite using very fast settings and no tiles.

I didn't get too deep into the weeds about exactly how much CPU it was using, maybe 16 cores or something?

[GeoffreyA]

Oh, what about the [warez] scene? Nothing. Completely ignored because the encoder is crazy slow.

There was a good example of "Last Night in Soho," one of the first VVC encodes. A high-quality QP20 specimen, it took the group about a week using vvenc medium; its mild loss of grain only evident if one compares against the BluRay. As a bonus, it sported USAC audio.

[Z2697]

I was fairly impressed with Spin Digital's live 9 (?) Mbps 4kp60 HDR VVC encode at NAB. It resoundingly outperformed NVENC AV1 and x265 at equal speed, despite using very fast settings and no tiles.

I didn't get too deep into the weeds about exactly how much CPU it was using, maybe 16 cores or something?

Realtime 4K 60FPS on CPU? That's almost too good to be true.

[LigH]

@ birdie + GeoffreyA:

As much as I remember the last 2-3 decades, moviez pirates did not avoid encoding efforts to gain shareability while the average internet bandwidth was limited... having Gbps connections and TByte media today moves the goalpost. Burning a CD/DVD is out since many "Smart" TV sets have USB3 ports and rather compatible decoders for many established media formats.

[GeoffreyA]

@ birdie + GeoffreyA:

As much as I remember the last 2-3 decades, moviez pirates did not avoid encoding efforts to gain shareability while the average internet bandwidth was limited... having Gbps connections and TByte media today moves the goalpost. Burning a CD/DVD is out since many "Smart" TV sets have USB3 ports and rather compatible decoders for many established media formats.

Yes. Not so much the encoding complexity, but its offering little gain over AV1 at the cost of less compatibility.

[benwaggoner]

I was fairly impressed with Spin Digital's live 9 (?) Mbps 4kp60 HDR VVC encode at NAB. It resoundingly outperformed NVENC AV1 and x265 at equal speed, despite using very fast settings and no tiles.
I imagine it was using 64+ cores. Demos like this are normally using the fastest Xeon or EPYC processor they can find that'll run the demo. IIRC, MultiCoreWare were using at least 36 cores when they demoed live 4K HEVC software encoding ~7 years ago. Basically they use as many cores as they can scale to before the lower per-core performance winds up being a net negative. Xeon goes up to a max of 86 performance cores now.

[birdie]

Some interesting thoughts (https://www.linkedin.com/pulse/all-talk-playback-vvc-needs-focus-decode-first-jan-ozer-6aufe) about the codec from Jan Ozer.

If VVC advocates want to make the codec relevant before hardware catches up, they need to follow the AV1 playbook. That means:


Share Real-World Software Decode Performance: Meta’s 2023 post on Reels explained exactly how AV1 performed in practice: a 15% bitrate reduction at the same quality, 10% lower battery consumption, and 6% faster playback start time. They also shared performance results and the benchmarking effort needed to maintain high viewer QoE. That kind of transparency builds trust and sets expectations. VVC groups haven’t done this, and it shows. If companies are currently using VVC with software decode successfully, tell us about it. If not, say they're not, and quit alluding to a use case that doesn't exist.

Launch a VVC Equivalent of VCAT. Meta’s Video Codec Analysis Tool (VCAT) will give the industry a shared, testable way to evaluate decoder performance across device classes. If VVC is being tested internally, no one’s publishing results. Without shared metrics, no one can benchmark or optimize around it.

Fund an efficient, open-source decoder like dav1d. AOMedia funded dav1d to ensure AV1 playback worked on low-end phones and across platforms. It’s now the most widely used AV1 decoder, integrated into browsers, apps, and OS platforms. In contrast, VVC’s open-source decoder options are unoptimized and untested in the wild. When I shared in a LinkedIn post (https://www.linkedin.com/posts/thierryfautier_news-vvc-reaching-new-limits-if-you-remember-activity-7315345781572452352-as5P/?trk=article-ssr-frontend-pulse_little-text-block) that I was testing VVC decoders and found them twice as CPU-intensive as AV1, the author claimed this was unfair because VVC software players are “not as optimized as the AV1 one.” I snickered, stifled my sarcastic response ("that's the freaking point"), and commented, “I can only test what’s available.” That’s the gap. That’s the problem.

[modus-ms325c]

what are they hiding!? why obfuscate codec adoption flaws with insane tech demos that we'll never get to see in a million years?
i mean, what year do they think we're in, 1994?

[ksec]

Some interesting thoughts (https://www.linkedin.com/pulse/all-talk-playback-vvc-needs-focus-decode-first-jan-ozer-6aufe) about the codec from Jan Ozer.

Until MC-IF and its partners focus on decode-first deployment

That is not the job of MC-IF. In fact there is no such equivalent to AOM on the VVC Camp. Although one could argue it *should* be doing that job.

Consider Qualcomm still dont have Hardware encode and Decode for VVC suggest something is holding up. May be hardware complexity. I remember the New Adreno VPU was suppose to go into the X Elite but that didn't happen. Some last minutes changes but everything since has been using the old VPU block.

Nothing about VPU from Qualcomm on Twitter. I guess we will have to wait and see. ( Its not like x266 is even here anyway :eek::eek::eek:)