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

[ksec]

Originally Posted by RanmaCanada

I personally feel it is not as different IPC and different extensions will greatly affect the encoder speeds. Also, who still uses a x5660 as an encoder box? We know that AVX2 greatly increases the efficiency of HEVC, as we see the difference between zen+ and zen2. I just feel that this test is not even close to a real world situation, and it would be like testing modern video games on a gt210 and then claiming such complexities.

You can not extrapolate what a real world result would be from the conditions that were used.

They are all reference encoder and wouldn't have included any SIMD optimisation anyway. ( Apart from VTM )
So you have the same baseline to compare their inherent complexity.

[RanmaCanada]

Originally Posted by ksec

I am very angry. As I notice the BD Rate differences and decided to dig a little bit. But just before I absolute rant. Forgive me.

May be someone could explain to me, in a 2021 paper,

Why are they using JEM 3.0 and VTM 1.1, software that were from 3+ years ago?

For the same reason they are using hardware that's from 10+ years ago?

[Jamaika]

I posted the codec test because someone did something there. Probably the mega-data flow on the satellite. Nothing is said about amateur. As for the profession of filmmaker, editor. I see that a professional changes the processor every six months to a newer one to make it faster. The question is whether the movie is better. No, money matters here. What is the quality of the camera optics and filming technique? Does software such as Adobe Premiere keep up with the news of all graphics cards? I do not think so.
What about SIMD? VTM / AOM codecs have SIMD. The problem is that they are only for Windows 32bit.

[birdie]

Originally Posted by ksec

I am very angry. As I notice the BD Rate differences and decided to dig a little bit. But just before I absolute rant. Forgive me.

May be someone could explain to me, in a 2021 paper,

Why are they using JEM 3.0 and VTM 1.1, software that were from 3+ years ago?

I can't. Let's just pay this paper no attention and move on.

[ksec]

Originally Posted by birdie

I can't. Let's just pay this paper no attention and move on.

Ok.

[benwaggoner]

Originally Posted by RanmaCanada

I personally feel it is not as different IPC and different extensions will greatly affect the encoder speeds. Also, who still uses a x5660 as an encoder box? We know that AVX2 greatly increases the efficiency of HEVC, as we see the difference between zen+ and zen2. I just feel that this test is not even close to a real world situation, and it would be like testing modern video games on a gt210 and then claiming such complexities.

You can not extrapolate what a real world result would be from the conditions that were used.

Absolutely. Because real world codecs have a lot of variation in how well they can take advantage of paralleism and SIMD. And reference encoders comparisons tend to use quite exhaustive searches without the many early-exit heuristics that make real-world encoders fast enough for production use. That has real-world impact! While single-thread C-only x264 is MUCH faster than x265, when you've got a many core AVX2 capable CPU, the gap is much smaller, because H.264 just can't productively use that many threads and that wide SIMD.

Nor do reference comparison tests have the psychovisual tuning that real-world encoders use to make for good subjective quality across a wide range of content possible. Adaptive quantization, adaptive frame types, and VBV rate control are essential to a production encoder but not evaluated in reference comparisons.

The tools for that kind of psychovisual tuning aren't stressed in reference comparisons, and have a huge real-world impact. A big reason that VC-1 didn't have long-term viability against H.264 was that the adaptive QP signaling syntax in VC-1 was just a RLE of QP offsets. The overhead of doing that for most blocks in a frame was so high that it reduced how many bits were available for actually encoding those blocks. H.264 had a much more efficient syntax which made lots of intra-frame variation much more feasible.

AV1's requirement to not use any IP that was patented meant that lots of its tools weren't the optimal ones to do. So they wound up with ones with lots of potential variations to test, and ones that are expensive to decode and so expensive to try alternatives of. Which is why all the examples of "AV1 is better than HEVC" tend to be 10% lower bitrates on VMAF at >10x the encoding time. That's stuff that reference comparisons don't pick up on, but are very important to real-world viability.

And since AV1 was tuned using VMAF, it gets higher VMAF scores for the same subjective quality, and so VMAF is a worse tool to evaluate with. Once any metric is demonstrate to have good subjective correlation and starts to get used to make codec and encoder decisions, developers start optimizing for the metric directly instead of for the thing the metric is attempting to capture. And thus the subjective correlation and value of any given metric goes down the more it is optimized for. The VMAF ML model would be quite different if it were trained on MOS scores of AV1 encoded content instead of just x264.


Reference encoder comparisons have some value, and are the best we can do in early-stage codec development. But they are pretty limited in how accurately we can extrapolate real-world implementation capabilities.

[hajj_3]

https://spin-digital.com/announcements/vvc-player/

[birdie]

Some news:

1

Allegro DVT Launches the World’s First Hardware-Based VVC/H.266 Decoder Silicon IP

Allegro DVT, the leading provider of video processing silicon IPs, today announced the immediate availability of its AL-D320 video decoder semiconductor IP core supporting the latest Versatile Video Coding (VVC/H.266) format. The AL-D320 core is the world’s first hardware IP to support the new VVC format with 8, 10 and 12-bit samples, chroma sampling of 4:2:0 and 4:2:2 and image resolutions and rates of up to 8K120. Added to this, the core continues to support H.264 and HEVC up to 12-bit and 4:4:4 chroma subsampling.

AL-D320 decoder IP is immediately available for integration by SoC vendors in various technology nodes ranging from 28nm down to 5nm and below through a seamless and proven HW and SW integration kit.

2

Access Advance Launches VVC/H.266 Video Patent Pool

Building on the success of its HEVC Advance Patent Pool, Access Advance today announced the launch of the VVC Advance Patent Pool and the Multi-Codec Bridging Agreement ("MCBA"). VVC is the next generation video codec standard finalized less than one year ago, which provides significant improvements in video compression of up to 50% over HEVC, enabling a new generation of products, ever more beautiful video, faster downloads, and improved savings on storage.

The license structure of the new VVC Advance Pool mirrors that of the HEVC Advance Platform Pool License recently announced, with royalty rates and caps set at a modest 25% increase over the equivalent HEVC Advance License structure. Please see https://www.accessadvance.com/vvc-ad...-rates-summary

Importantly, as requested by the marketplace, Licensees that have executed both the HEVC Advance and VVC Advance Platform Licenses will have the option to enjoy the benefits of the MCBA. The MCBA is not a third license; it is an agreement that bridges the HEVC Advance and VVC Advance Platform Licenses. Those Licensees who have executed all three agreements will enjoy a discounted royalty rate for their products that include both VVC and HEVC, paying the same royalty rate as they would pay for a product that includes only VVC, providing an effective 45% discount.

[amehri]

Hello everyone,

I want to optimize VVC decoder, I work with VTM 10. I have to understand the VTM decoder Code. Any suggestion, please!! (VTM code description with details).

[hajj_3]

The VVC advance fees look reasonable. The mpeg-la haven't been published yet though.

[ksec]

Originally Posted by birdie

Some news:

1




2

I was originally upset at the new Cap for VVC and MCBA being too high, now I have done some napkins maths it turns out they were likely targeting some outliner like Apple or Samsung.

But basically $0.5 per devices if you have a VVC logo. And that is excluding MPEG-LA terms.

[benwaggoner]

Originally Posted by ksec

I was originally upset at the new Cap for VVC and MCBA being too high, now I have done some napkins maths it turns out they were likely targeting some outliner like Apple or Samsung.

But basically $0.5 per devices if you have a VVC logo. And that is excluding MPEG-LA terms.

I also like that the VVC license includes HEVC, so it's a small incremental extra cost for a device that already supports HEVC. It'd be more adoption friction if HEVC and VVC had to be paid independently if both were used.

[hajj_3]

the 1st vvc hardware decoder ip block has been announced: https://www.businesswire.com/news/ho...der-Silicon-IP

[Jamaika]

New player video YUView for VVC
https://ient.github.io/YUView/

[benwaggoner]

Originally Posted by Jamaika

New player video YUView for VVC
https://ient.github.io/YUView/

Nice catch! Has some nice visualizations.

[Jamaika]

Unofficial plugin for VLC player. I don't know if it works.
https://github.com/InterDigitalInc/VTMDecoder_VLCPlugin

[hajj_3]

vvc royalty report by unified patents: https://www.scribd.com/document/5158...-Report-Public

[ksec]

Originally Posted by hajj_3

vvc royalty report by unified patents: https://www.scribd.com/document/5158...-Report-Public

Read it, ReRead it. Still couldn't understand.

VVC FRAND per-unit Royalty Rate = $0.05.

Basically they are saying Bandwidth cost has decreased so much the "value" of the codec over AVC / H.264 as anchor point as becomes negligible.

I dont even know where to begin.

[benwaggoner]

Originally Posted by ksec

Read it, ReRead it. Still couldn't understand.

VVC FRAND per-unit Royalty Rate = $0.05.

Basically they are saying Bandwidth cost has decreased so much the "value" of the codec over AVC / H.264 as anchor point as becomes negligible.

I dont even know where to begin.

Yeah. Bandwidth savings are just part of the value of newer codecs. Being able to improve quality of service to lower bandwidth customers is also huge. And helping customers watch more content under their capped/metered bandwidth is also important. There are also material costs to higher bitrates in content encoding, storage, and CDN cache consumption (lower bitrates means more minutes of content can be cached at the edge).

Also, the claimed compression efficiency advantages of AV1 really haven't been proven out with double-blind subjective evaluation with real-world encoding scenarios.

Unified Patents does lots of important work, but I'm not so thrilled by this analysis.

[hajj_3]

Originally Posted by benwaggoner

Unified Patents does lots of important work, but I'm not so thrilled by this analysis.

They are clearly trying to make out as though it only deserves a tiny fee so that if it ever goes to court over FRAND costs/terms that they can use this as one of their arguments.