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

[oibaf]

VVC Patent Challenges on the Horizon (https://www.unifiedpatents.com/insights/2026/1/14/vvc-patent-challenges-on-the-horizon)

The team at Unified IP Services is using Pearl to examine the quality of patents alleged to be essential to the Versatile Video Coding (VVC) standard. Patents owned by Ideahub, Intellectual Discovery, IP Bridge, and others are being reviewed.

[benwaggoner]

VVC Patent Challenges on the Horizon (https://www.unifiedpatents.com/insights/2026/1/14/vvc-patent-challenges-on-the-horizon)
Good news if it can happen. Unified Patents has been doing the work of heroes for years now.

[FranceBB]

I don't know exactly what they mean by this, but while going through the release notes of Android 17 (https://developer.android.com/about/versions/17/release-notes) there's a very interesting entry in the Audio & Video section:


VVC Support: Added platform support for Versatile Video Coding (H.266).


Unfortunately I have a Pixel 6 Pro which means that I'm still on Android 16 and I can't install the latest Beta of Android 17 as they haven't made it available for it (yet), so only people with newer Pixel phones can install it.
According to David Ronca (who used to work at both Netflix and Meta before retiring) this doesn't mean that there's a software decoder in there:


This means that the Android Media layer will detect VVC video input and if the app registers a VVC decoder, then VVC playback will be possible. It does not mean Android will include a VVC decoder.


Reading more online about this, Joao Sierra (who works on Embedded Systems for NOS SGPS) said



Google basically enabled the infrastructure for an OEM to add VVC support on its own (basic stuff like MIME types and other stuff into android MediaCodec framework). Previously, if an OEM wanted to add VVC support, it would need to add a custom OEM specific API extension for it.

If the latest MediaTek and Qualcomm chipsets had VVC support, MTK/QC would need to implement a custom API to access the decoder. Android until version 16 doesnt have any vendor neutral api to acess vvc decoders. Apps on the playstore to use that VVC decoder had to explicity call those proprietary vendor specific APIs. The apps would be complex because now they would need to have explicit code paths for each of the chipsets.



So, in other words, it looks like they basically added the ability to interact with the hardware decoders by calling a standardized API within the Android Media Framework, just like what happens for all the other codecs, so that the individual applications won't have to integrate separately with those potentially spanning several different manufacturers. Nonetheless, it will still be up to the various Smartphone manufacturers (like Samsung etc) to pay the royalties and implement the hardware decoders 'cause there won't be a software decoder built in by default.

Still, does it mean that hardware decoders in smartphones are finally coming?

[birdie]

Still, does it mean that hardware decoders in smartphones are finally coming?

The codec IP has been around for years and, from what I've heard, it's much cheaper than including AV1 support, which requires a far bigger transistor budget. Therefore, it must be about royalties. Even Apple, a VVC licensor (!!), refuses to support the codec, which suggests that the licensing situation is beyond repair.

I wonder if we'll see Lunar Lake/Panther Lake based Android tablets with VVC support.

[FranceBB]

Today I installed Android 17 Beta 1 on my Google Pixel 6 Pro which doesn't obviously have an hardware decoder and sure enough I can confirm there's no software decoder included, so David and Joao were right, it's just the API in the Media Framework to talk to hardware decoders.

[benwaggoner]

The codec IP has been around for years and, from what I've heard, it's much cheaper than including AV1 support, which requires a far bigger transistor budget. Therefore, it must be about royalties. Even Apple, a VVC licensor (!!), refuses to support the codec, which suggests that the licensing situation is beyond repair.

I wonder if we'll see Lunar Lake/Panther Lake based Android tablets with VVC support.
It's not just royalties in principle. It's that the actual cost for licensing cannot be known in advance and so many entities are claiming essential patents without being part of any patent pool. And with predatory patent holders waiting until a codec is in wide use before asserting claims and demanding outrageously high licensing costs the cost of licensing VVC at this point is unbound. And you can't calculate a ROI with a ??? for cost.

All the legal battles happening now over HEVC is very much patent trolls eating their own seed corn for future MPEG codecs.

[birdie]

Took them years to admit (https://github.com/fraunhoferhhi/vvenc/issues/644#issuecomment-3853730012) that:

We are aware of VVenC producing rather "soft" content. What would be needed is a --tune highrate (possibly activating automatically at high-enough rates), adapting to high-rate encoding (VVenC performs better at mid-to-low bitrate range), which is a todo.

VVenc will probably become better than x264/x265 at high bitrate encoding.

[LigH]

This sounds similar to x265's SAO feature, mocked as "smooth all out".

[kurkosdr]

Took them years to admit (https://github.com/fraunhoferhhi/vvenc/issues/644#issuecomment-3853730012) that:

We are aware of VVenC producing rather "soft" content. What would be needed is a --tune highrate (possibly activating automatically at high-enough rates), adapting to high-rate encoding (VVenC performs better at mid-to-low bitrate range), which is a todo.

VVenc will probably become better than x264/x265 at high bitrate encoding.

How high is "high-enough" though? If you have to give VVC HEVC-like bitrates so it won't blur out the content, then you might as well use HEVC.

This goes back to a point I made on another thread, that VVC (and AV1, and post-HEVC standards in general) rely too much on coding tools that are essentially post-processing signalling/hinting to hide the compression artifacts with blur (temporal and spatial) to game common metrics such as PSNR and SSIM rather than genuinely capturing more detail at lower bitrates. Maybe we've hit the limits of entropy with HEVC-era standards for normal content?

[rwill]

Took them years to admit (https://github.com/fraunhoferhhi/vvenc/issues/644#issuecomment-3853730012) that:



VVenc will probably become better than x264/x265 at high bitrate encoding.

That the dev writes that the decoder has to "support film grain technology" makes me rather sad and makes me question my faith.

[birdie]

Maybe we've hit the limits of entropy with HEVC-era standards for normal content?

That's been my impression as well.

[kurkosdr]

That the dev writes that the decoder has to "support film grain technology" makes me rather sad and makes me question my faith.
I actually like film grain synthesis (because the decoder can be modified to ignore the FGS signal altogether and I won't have to look at that crap).

Imagine if a movie had interlace artifacts throughout (not just in a few scenes to give an "old video" look, but in all or most scenes), this is how film grain throughout the movie looks to some of us.

[CruNcher]

I actually like film grain synthesis (because the decoder can be modified to ignore the FGS signal altogether and I won't have to look at that crap).

Imagine if a movie had interlace artifacts throughout (not just in a few scenes to give an "old video" look, but in all or most scenes), this is how film grain throughout the movie looks to some of us.

Oh in AI you can get that feeling back a nice artifact are epsilon sampling errors you get the interlace feeling back with it

to compare film grain with interlacing though is a strange psy compare

[LigH]

The worst AI misimprovement (Verschlimmbesserung) I saw so far was an upscale of Classic Doctor Who seasons without deinterlacing first. Looks okay in most scenes with a rather static camera, but when the camera moves backwards in a hallway, the whole scene starts wobbling. I bet I would have done that much better. Even without AI. But I can't afford Blu-ray boxes at the moment...