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

[PatchWorKs]

Just an hint: for those who are looking for a friendly (multiplatform) GUI for coding tests, I would like to point out that Fastflix has VCC support since version 5.2.0.

Hope that helps.

[birdie]

Originally Posted by MoSal

Intel and AMD do support and play well with the open-source graphics stack. So, early support in libva is more of an expectation rather than a pleasant surprise.

VK_KHR_video_decode_vvc getting added to Vulkan, and subsequently getting implemented by some Mesa drivers, now that would be an interesting development (if/when it happens).

Fedora will disable it just like they did with many other codecs.

[MoSal]

Originally Posted by birdie

Fedora will disable it just like they did with many other codecs.

For the misguided minority that chooses to use Fedora as a desktop daily driver, a well maintained 3rd party repository always existed for the purpose of providing "freeworld" packages.

[birdie]

Originally Posted by MoSal

For the misguided minority that chooses to use Fedora as a desktop daily driver, a well maintained 3rd party repository always existed for the purpose of providing "freeworld" packages.

The misguided minority has been using Fedora since RedHat 5.1 in 1998 or something.

In terms of being the bleeding edge and stable simultaneously, it's the best distro. And it's the backbone of pretty much everything in Linux. SystemD, PulseAudio/PipeWire all started from within RedHat and were first pushed onto Fedora users.

[FranceBB]

I'm on Fedora as well, although I've been a much later adopter (I started with Fedora 23).

Originally Posted by birdie

PipeWire all started from within RedHat and were first pushed onto Fedora users.

Back when they were introduced I was skeptical, but Pipewire/Wireplumber solved so many long-standing issues I used to have with PulseAudio that it's been a very welcome change.

Originally Posted by MoSal

a well maintained 3rd party repository always existed for the purpose of providing "freeworld" packages.

Yep, I always use the freeworld packages from RPM Fusion.
I started using them back when I needed Chromium to be able to decode everything without artificial limitations, hence the chromium-freeworld. Even right now, I'm not using the normal FFMpeg free version but rather the one with everything in it so that all the things that rely on it (VLC, MPV etc) can properly decode whatever file I throw at them.

[benwaggoner]

Originally Posted by PatchWorKs

Just an hint: for those who are looking for a friendly (multiplatform) GUI for coding tests, I would like to point out that Fastflix has VCC support since version 5.2.0.

Your link is corrupt, FYI.

[Brazil2]

Originally Posted by benwaggoner

Your link is corrupt, FYI.

Because of a pesty " at the beginning of the URL.
Correct link: https://github.com/cdgriffith/FastFlix/releases/

[FranceBB]

Originally Posted by nevcairiel

You still need a decoder to actually utilize the libva interface for that - eg. ffmpeg needs to implement it.

I hoped someone was gonna do it and... well, that didn't take long.

https://github.com/intel/cartwheel-f...ses/tag/2024q2

In the changelog:

- ffmpeg-vaapi added VVC decode support
- ffmpeg-qsv added VVC decode support


How very nice and it's coming from Intel directly.
Hopefully it will then be upstreamed and from there spread everywhere, including in MPV and other players.

Looks like everything is finally coming together.
Now all we need, really, is x266.

[LigH]

At least uvg266 is available. And still alive: Latest release 2 weeks ago.

[GeoffreyA]

While it would be nice to see the elusive x266, FFmpeg merged the libvvenc wrapper about a month ago and Gyan has included it in his builds since July. FFmpeg supports muxing VVC into MP4 containers, and MPC-HC is playing these files tolerably well. So, VVC is seemingly ready for popular use from an encoding and decoding point of view.

I find that VVenC is marginally ahead of libaom in quality at the same bitrate but the medium preset is too slow for practical use. Fast and faster are quicker and have good quality. If Fraunhofer's encoder is representative of what H.266 is capable of, I think its gains are not big enough compared to AV1 to force a dramatic shift in the anime- and film-encoding community at least.

[benwaggoner]

Originally Posted by GeoffreyA

While it would be nice to see the elusive x266, FFmpeg merged the libvvenc wrapper about a month ago and Gyan has included it in his builds since July. FFmpeg supports muxing VVC into MP4 containers, and MPC-HC is playing these files tolerably well. So, VVC is seemingly ready for popular use from an encoding and decoding point of view.

Nice!

I find that VVenC is marginally ahead of libaom in quality at the same bitrate but the medium preset is too slow for practical use. Fast and faster are quicker and have good quality. If Fraunhofer's encoder is representative of what H.266 is capable of, I think its gains are not big enough compared to AV1 to force a dramatic shift in the anime- and film-encoding community at least.

Not even Fraunhofer would claim that VVCEnc is close to showing what VVC is capable of! It's a great early-stage encoder with sufficient speed and real-world functionality (rate control, frame type selection) to be practical for testing. The reference encoder is far more glacially slow than it, and also not really designed to make real-world bitstreams optimized for particular use cases.

It generally takes 3+ years of competition between commercial encoders to get a good sense of what a codec is capable of, and generally there's another 20-25% extra bitrate that can be squeezed out after that. We've still seen some significant real-world improvements to H.264 and HEVC encoding in the last couple of years. We're only now on the cusp of AV1's film grain synthesis becoming practical for real-world use. Even MPEG-2 saw significant compression efficiency improvements more than 20 years after it was standardized.

[Yups]

Originally Posted by FranceBB

I hoped someone was gonna do it and... well, that didn't take long.

https://github.com/intel/cartwheel-f...ses/tag/2024q2

In the changelog:

- ffmpeg-vaapi added VVC decode support
- ffmpeg-qsv added VVC decode support


How very nice and it's coming from Intel directly.
Hopefully it will then be upstreamed and from there spread everywhere, including in MPV and other players.

Looks like everything is finally coming together.
Now all we need, really, is x266.

Lunar Lake only by the looks of it. Battlemage G21 won't support it, Media Engine too old. Maybe G31 but this comes even later.

[GeoffreyA]

Originally Posted by benwaggoner

Not even Fraunhofer would claim that VVCEnc is close to showing what VVC is capable of! It's a great early-stage encoder with sufficient speed and real-world functionality (rate control, frame type selection) to be practical for testing. The reference encoder is far more glacially slow than it, and also not really designed to make real-world bitstreams optimized for particular use cases.

It generally takes 3+ years of competition between commercial encoders to get a good sense of what a codec is capable of, and generally there's another 20-25% extra bitrate that can be squeezed out after that. We've still seen some significant real-world improvements to H.264 and HEVC encoding in the last couple of years. We're only now on the cusp of AV1's film grain synthesis becoming practical for real-world use. Even MPEG-2 saw significant compression efficiency improvements more than 20 years after it was standardized.

Thanks, Ben! As you point out, encoders improve considerably over the course of their developmental life. x264 and x265 certainly bear testimony to that. I think it's a truth in most fields that it takes a while to reach that point of critical mass or excellence and it may not be clear earlier where that point is.

Of late, I've been encoding anime for archiving, trying to future-proof the encodes, and there was the choice of what codec to use. Our 2015 Samsung TV supports up to H.264 high 4.1. But anime benefits a lot from 10-bit colour depth; and so if I was going to break compatibility with that TV, I might as well go all the way, past HEVC, to AV1. Though tempted to use VVC, which I first experimented with in 2021, I decided the gains were too minimal over AV1 and wasn't too sure of Fraunhofer's encoder. In the end, I settled on libaom (main 10) and libopus, and the results are excellent.

[LigH]

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

Fraunhofer VVC Encoder ver. 1.12.0 d57c73d

Fraunhofer VVC Decoder ver. 2.3.0 c7e2f8b

uvg266: over here

[birdie]

VVC has been pronounced dead.

[FranceBB]

Originally Posted by birdie

VVC has been pronounced dead.

This is the graph from that article:



That graph shows where H.266 VVC is supposed to be based on prediction and clearly it isn't there, that's true, however it's far from being dead and to be fair it isn't even too far behind if you factor in the pandemic.

As I said, I very much think that H.266 VVC will be relevant for broadcasting and we're now in the phase in which we're seeing hardware decoding pop up in end user devices, I'm talking about TVs, but we can see it being readied in computers as well with the new Intel Lunar Lake graphics. Brazil, with its TV 3.0 getting readied, is gonna be the forerunner of H.266 VVC. If everything goes to plan, H.266 VVC transmissions will start before June 2026, so with that deadline in mind, let's see where we're at:


- July 2020 -> H.266 VVC specs finalized
- October 2020 -> VVEnc & VVDec by Fraunhofer are released
- July 2021 -> First chipset with hardware decoding released by MediaTek
- July 2022 -> First TV prototype shown at CES
- April 2024 -> Libav adds software decoding support (FFMpeg, MPV, Avisynth, VapourSynth)
- July 2024 -> Consumer TV becoming available
- September 2024 -> Intel Lunar Lake Graphics hardware decoding support


Which leads us to:

- 2025 -> Initial H.266 VVC broadcasting tests in Brazil
- 2026 -> Beginning of H.266 VVC transmissions in Brazil

so, mass consumer adoption (as far as TVs and decoders / set top boxes are concerned) needs to happen before June 2026. We're currently at the end of summer in 2024. Everything still looks very much on track.

[modus-ms325c]

Originally Posted by FranceBB

...

OK, I really hate that I have to "crawl out of the woodworks" (so to speak) to correct you on one minor thing, and that is the host country for the 2026 FIFA (Men's) World Cup.
Brazil isn't hosting this "big sporting event" thing, for one. Canada, Mexico, and the U-and-S-of-A are co-hosting the event, and it's a 100% legit sports event organizing op which, if the previous four FIFA WC events are any indication, is actually really hard to achieve, believe it or not.

MainConcept and Fraunhofer IIS are already shilling the TV 3.0 standard hard, with "VVC plus LCEVC iwth MPEG-H 3D Audio for personalized, immersive audio experiences!" being a massive selling point that no one has basically any idea how it's playing out in practice outside of some testing facilities and some showcases at some physical "tech event" or whatever.

in any case, please let TV 3.0 come in! embrace it with open arms if you can. we need this to be successful.

[FranceBB]

Ooops, yeah, I don't know where I got that from, my bad, fixed.

Indeed the Men's World Cup is gonna be jointly hosted by 16 cities in three North American countries: Canada, Mexico, and the United States.

Originally Posted by modus-ms325c

MainConcept and Fraunhofer IIS are already shilling the TV 3.0 standard hard

[...]

in any case, please let TV 3.0 come in! embrace it with open arms if you can. we need this to be successful.

Yeah, despite not being in Brazil, I really hope for it to be successful as it's gonna be a very good starting point for the rest of the broadcasting world. By the way, one of my relatives is a university professor there (he's been there for a long time, he's married, his wife is a doctor and they have a child). I'm not sure if I'll ever have the chance to visit them, though, but one day... maybe...

[FranceBB]

To add to my post above, after talking to Thierry Fautier, an expert in the field, it looks like Qualcomm is working on hardware decoding chips to be included in the various smartphones and we're gonna see them in consumer devices starting from 2026. Once again, I reaffirm my statement above: we're on track towards general availability in 2026. Don't write H.266 VVC off, it's far from dead, it's alive and it's gonna "wake up" really soon (2 years).

[ksec]

The amount of crap on the internet is at an absurd level. VVC roadmap delays, it wasn't even a roadmap in the first place as there are no organisation to push for this. Much rather what the industry expects to happen. Yes. It is around 12-24 months behind schedule but people forgot we have COVID during that and chip shortage which distorts the whole picture.

Getting that bit wrong is fine. I mean 99.99999% of all current news reporting are like that. Without Context. But then they have the audacity to include the AOM roadmap as the first image, pushed by an actual organisation with some of the most powerful tech company behind it, and promised to have hardware AV1 Decoder across ALL devices by 2020.

We are now quite close to 2025. It isn't even half way there.

Apart from the patents. VVC plus LCEVC will be interesting technology. Like I said in another thread it is actually showing better than expected results.