Versatile Video Coding (VVC) / H.266: HEVC successor [Archive] - Page 2

benwaggoner

12th June 2024, 22:33

You mean like how Hollywood studios picked the winner of the HD-DVD vs Blu-Ray format war by deciding one day to only throw content at one format (Blu-Ray) while letting the other rot (HD-DVD)? This happened shortly after BD+ gave studios the hope of unbreakable DRM. Whatever studio support HD-DVD had dried up right there and then.
It was more that Sony, who had thought they bet Blu-ray on the success of the PS3, realized they'd also bet the PS3 on the success of Blu-ray, and spent about $1B paying studios to adopt Blu-ray and drop HD-DVD.

Or how Hollywood studios cut out MacOS X from Blu-Ray and HD-DVD support because MacOS X didn't provide the DRM infrastructure Hollywood studios demanded for Blu-Ray and HD-DVD?
Given that better content security than DVD was a core motivation for new disc formats, it was utterly expected that they weren't going to support a "just buy a Mac!" sized hole for pirates to drive through.

Expected by Apple as well, who knew what they needed to do to support HW encryption, and got it as part of their Intel transition.

It doesn't matter what happened in the distant past, today pre-recorded content is king and DRM is legally empowered by the DMCA. Hollywood studios can cut out from their encrypted content whatever OS and hardware combination doesn't comply with their arbitrary demands.
Studios could only invalidate DRM keys for content on their own wholly-owned streaming services, and I am not aware of them ever doing so. Content distributed by other streaming services control their own DRM keys.

And their demands for secure video paths and HW license stores are hardly "arbitrary" - they have been well documented and understood for years.

The weird thing in this case is that HDMI 2.1 is required only if you want 4K@120fps, and Hollywood doesn't serve any 4K@120fps content, but they can still mandate all kinds of DRM requirements by acting as gatekeepers to the HDMI spec. DisplayPort is technically a thing but isn't a thing on TVs (due to lack of eARC support), so you want at least one HDMI 2.1 port if you want to output 4K@120fps to a TV (which means GPU vendors can't boycott HDMI 2.1). And then there is the open question of whether encrypted 8K content will be allowed on DisplayPort or be HDMI 2.1-only.
I'm missing your point here. Pretty much the only things that can play out HDMI 2.1 so far are recent GPUs and game consoles. Most streaming media players and all disc players are still on HDMI 2.0, and some other than that.

Also, you can do DisplayPort to HDMI 2.1 with an adaptor. Nvidia's professional A-series GPUs have 4 DP and no HDMI ports, so I've used an external adaptor to get 120 fps, which has worked well.

The lack of eARC isn't why TVs don't have DisplayPort input. It's more than TV SoCs don't have support for it, so it would be quite expensive to add it.

kurkosdr

14th June 2024, 13:39

It was more that Sony, who had thought they bet Blu-ray on the success of the PS3, realized they'd also bet the PS3 on the success of Blu-ray, and spent about $1B paying studios to adopt Blu-ray and drop HD-DVD.
HD-DVD was also paying studios (https://gizmodo.com/sony-reportedly-launches-investigation-over-ps5-pro-spe-1851349949), but AACS had already been cracked by then, so the very moment BD+ arrived of Blu-Ray (giving studios the hope of uncrackable DRM), all studios dropped HD-DVD immediately.

Given that better content security than DVD was a core motivation for new disc formats, it was utterly expected that they weren't going to support a "just buy a Mac!" sized hole for pirates to drive through.
My point is, studios will cut out more popular platforms than Desktop Linux if they don't get the DRM infrastructure they want, so the "boycott" suggested by another person won't work.

Studios could only invalidate DRM keys for content on their own wholly-owned streaming services, and I am not aware of them ever doing so. Content distributed by other streaming services control their own DRM keys.

And their demands for secure video paths and HW license stores are hardly "arbitrary" - they have been well documented and understood for years.
My point is, the DMCA's doesn't define what copyright holders can demand as part of the DRM infrastructure. If studios decide one day to require a DNA sample, all hardware vendors out there will have to incorporate it into their hardware to gain access to Hollywood content. I am absurd on purpose, but it shows the absurdity of the DMCA's anticircumvention provisions.

And yes, their demands are arbitrary. Just look how Microsoft jumped through every DRM hoop there is out there only for Disney to decree that Disney+ will only be available in 720p on Windows (on Edge and on the Microsoft Store app). Funny thing is, pirates are extracting CDMs from tablets and Smart TVs so the interwebs is still full of Disney WEB-DL torrents (in 4K HDR). But if you are a customer and have a Windows-centric UHD setup, you are screwed even if you've ensured your setup is compliant with the highest tier Widevines and PlayReadys. Did I say arbitrary? I did.

benwaggoner

14th June 2024, 17:32

HD-DVD was also paying studios (https://gizmodo.com/sony-reportedly-launches-investigation-over-ps5-pro-spe-1851349949), but AACS had already been cracked by then, so the very moment BD+ arrived of Blu-Ray (giving studios the hope of uncrackable DRM), all studios dropped HD-DVD immediately.
HD-DVD and Blu-ray coexisted on the market for over a year, from October 2006 to January 2008.

Wikipedia has a decent overview: https://en.wikipedia.org/wiki/High-definition_optical_disc_format_war

I was working on Microsoft's HD-DVD throughout that period, and paid a lot of attention to the blow-by-blows of what was happening inside the industry as well as for the consumers.

My point is, studios will cut out more popular platforms than Desktop Linux if they don't get the DRM infrastructure they want, so the "boycott" suggested by another person won't work.
I'm not sure what you think rights holders should do instead? Leave gaping security holes just so people on low market share operating systems with older hardware can play optical disks instead of just buying a player?

And yes, their demands are arbitrary. Just look how Microsoft jumped through every DRM hoop there is out there only for Disney to decree that Disney+ will only be available in 720p on Windows (on Edge and on the Microsoft Store app). Funny thing is, pirates are extracting CDMs from tablets and Smart TVs so the interwebs is still full of Disney WEB-DL torrents (in 4K HDR). But if you are a customer and have a Windows-centric UHD setup, you are screwed even if you've ensured your setup is compliant with the highest tier Widevines and PlayReadys. Did I say arbitrary? I did.
Studio DRM rules are complex, but a lot hinges on software versus hardware DRM, secure license stores, and that sort of thing. The lower the security, the lower quality of content can be licensed. Pretty much anything can do 480p, most 720p, the large majority 1080p, with UHD and HDR the most limited, and almost never in web browsers to date (more feasible in desktop apps). While the issues are certainly complex, often confusing, and commonly have compromises to balance security and market size, they are absolutely not arbitrary.

IIRC, getting full SL3000 level security on Windows requires Windows 11, a GPU from the last few years, and TPM 2.0. Last I looked maybe 18 months ago, <10% of Windows PCs met those requirements (it's certainly higher now but still well less than 50%).

No one believes that any specific technical means would cause piracy to vanish! The goal is to make piracy more difficult to do and make it easier to potentially identify who pirated the video. That discourages piracy-by-default by a casual mass of customers. Piracy being a hassle means more people decide it's just a better use of their time and money to get the content legitimately. And we've seen that the combination of having piracy of the best quality version more challenging while having affordable and easy to use official ways to access the content is highly successful.

But piracy can't be stopped outright, and everyone involved in content protection knows it. The "photon exploit" of putting a really good camera on a tripod aimed at a really good TV in a dark room isn't closable. But that exploit is an expensive hassle, and runs the risk of forensic watermarking identifying who pirated the content.

Blue_MiSfit

15th June 2024, 02:07

I couldn't have said it better myself :)

It's easy to judge the rules that Hollywood studios impose on the streaming of their content from the outside without context, but it all makes sense with some experience.

ShortKatz

15th June 2024, 16:55

FFmpeg has today added the possibility to add VVC encoding support using --enable-libvvenc via Fraunhofer VVenC.

Edit: It works, but is very slow, about speed=0.012x for 4k on my MacBook Pro.

birdie

15th June 2024, 19:44

Indeed (https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/c75940db290478df657c09089605d221dc47118e).

Add external encoder VVenC for H266/VVC encoding.
Register new encoder libvvenc.
Add libvvenc to wrap the vvenc interface.
libvvenc implements encoder option: preset,qp,qpa,period,passlogfile,stats,vvenc-params,level,tier.
Enable encoder by adding --enable-libvvenc in configure step.

ShortKatz

15th June 2024, 22:46

Are there VVenC options to speed encoding up a bit? I did my first test with
ffmpeg -i input.mp4 -acodec copy -vcodec libvvenc -preset medium -q 30 output.mp4
Which is really very slow.

benwaggoner

16th June 2024, 00:21

Are there VVenC options to speed encoding up a bit? I did my first test with
ffmpeg -i input.mp4 -acodec copy -vcodec libvvenc -preset medium -q 30 output.mp4
Which is really very slow.
It's still a pretty early encoder, and doesn't seem to actively being developed to be a practical high-volume production encoder.

A lot of speed optimization is both needed and very achievable.

birdie

16th June 2024, 11:56

Are there VVenC options to speed encoding up a bit? I did my first test with
ffmpeg -i input.mp4 -acodec copy -vcodec libvvenc -preset medium -q 30 output.mp4
Which is really very slow.

vvenc can actually use all the cores unlike e.g. libaom which is ... single-threaded for all I know.

You really need a device with as many cores as possible to encode into VVC. The standard itself is at the very least 10 times more computationally expensive than HEVC to encode.

And unfortunately in my tests x265 is better than vvenc at lower resolutions (1080p and below) and decent bitrates. Don't ask me why or how. The last time I compared vvenc-1.11.1 (preset=slower) and x265 3.5 (preset=veryslow) and I was unpleasantly surprised.

Looks like new codecs (AV1, VVC) are heavily optimized for 1440p and higher resolutions and fancy features like HDR, 10/12 bit encoding and VR and H.264/x264 and H.265/x265 still beat them at 1080p and below for visually lossless encoding.

Jamaika

16th June 2024, 14:58

Are there VVenC options to speed encoding up a bit? I did my first test with
ffmpeg -i input.mp4 -acodec copy -vcodec libvvenc -preset medium -q 30 output.mp4
Which is really very slow.

What's the problem? Let's see
static const AVOption options[] = {
{ "preset", "set encoding preset", OFFSET(preset), AV_OPT_TYPE_INT, {.i64 = 2}, 0, 4, VE, "preset"},
{ "faster", "0", 0, AV_OPT_TYPE_CONST, {.i64 = VVENC_FASTER}, INT_MIN, INT_MAX, VE, "preset" },
{ "fast", "1", 0, AV_OPT_TYPE_CONST, {.i64 = VVENC_FAST}, INT_MIN, INT_MAX, VE, "preset" },
{ "medium", "2", 0, AV_OPT_TYPE_CONST, {.i64 = VVENC_MEDIUM}, INT_MIN, INT_MAX, VE, "preset" },
{ "slow", "3", 0, AV_OPT_TYPE_CONST, {.i64 = VVENC_SLOW}, INT_MIN, INT_MAX, VE, "preset" },
{ "slower", "4", 0, AV_OPT_TYPE_CONST, {.i64 = VVENC_SLOWER}, INT_MIN, INT_MAX, VE, "preset" },
{ "qp", "set quantization", OFFSET(qp), AV_OPT_TYPE_INT, {.i64 = 32}, -1, 63, VE },
{ "qpa", "set subjective (perceptually motivated) optimization", OFFSET(qpa), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, VE},
{ "passlogfile", "Filename for 2 pass stats", OFFSET(stats), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, VE},
{ "stats", "Filename for 2 pass stats", OFFSET(stats), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, VE},
{ "period", "set (intra) refresh period in seconds", OFFSET(intra_refresh_sec), AV_OPT_TYPE_INT, {.i64 = 1}, 1, INT_MAX, VE },
{ "vvenc-params", "set the vvenc configuration using a :-separated list of key=value parameters", OFFSET(vvenc_opts), AV_OPT_TYPE_DICT, { 0 }, 0, 0, VE },
{ "level", "Specify level (as defined by Annex A)", OFFSET(level), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, VE},
{ "tier", "set vvc tier", OFFSET(tier), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, VE, "tier"},
{ "main", "main", 0, AV_OPT_TYPE_CONST, {.i64 = 0}, INT_MIN, INT_MAX, VE, "tier"},
{ "high", "high", 0, AV_OPT_TYPE_CONST, {.i64 = 1}, INT_MIN, INT_MAX, VE, "tier"},
{NULL}
};
if (avctx->thread_count > 0)
params.m_numThreads = avctx->thread_count;

So it should be
ffmpeg -i input.mp4 -acodec copy -vcodec libvvenc -vvenc-params preset=4 -threads 4 -q 30 output.mp4

birdie

16th June 2024, 15:23

"VVC is dead", VideoLAN president:

https://www.youtube.com/watch?v=6xUhpZXPbBM

kurkosdr

16th June 2024, 15:28

HD-DVD and Blu-ray coexisted on the market for over a year, from October 2006 to January 2008.

Wikipedia has a decent overview: https://en.wikipedia.org/wiki/High-definition_optical_disc_format_war
If you look at the dates closely, any studios that used HD-DVD (even exclusively) dropped it the moment BD+ became a thing. Some of them admit it openly and some not, but it played a huge role. More information: https://web.archive.org/web/20080301215043/http://blog.wired.com/27bstroke6/2008/02/how-crypto-won.html

I'm not sure what you think rights holders should do instead? Leave gaping security holes just so people on low market share operating systems with older hardware can play optical disks instead of just buying a player?
Studios? Nothing, they are the perpetrators here. The only solution is to repeal DMCA's anti-circumvention provisions or replace them with something that protects the users' rights to fair use, format-shifting, and content ownership. And yes, I consider DRM an attack on fair use, format-shifting, and content ownership. Just look at the recent example of Warner Bros deleting content that users had purchased. Or not being able to rip a DVD or Blu-Ray you've bought and having to pay again to stream the same movie on your tablet.

Also keep in mind that Audio CDs don't have DRM (any attempt to add it like XCP and CDS ended in failure and dropped), Amazon's MP3 store has no DRM, and iTunes dropped its DRM, and yet record labels are making tons of money. Not as much money as if they had successfully coerced you into re-buying your Audio CDs as DRM-ed iTunes songs, but they are still making tons of money.

Anyway, you are on a website that has a "Decrypting" sub-forum and has published multiple articles criticizing DRM and the DMCA's anti-circumvention provisions (inside and outside the forums), so best stop it here before we fill 10 pages discussing this, see those other resources instead.

The gist of the story is that, with the DMCA's anti-circumvention provisions in place, "boycotts" won't work, the studios will simply cut out any platform that doesn't comply with their arbitrary demands.

IIRC, getting full SL3000 level security on Windows requires Windows 11, a GPU from the last few years, and TPM 2.0. Last I looked maybe 18 months ago, <10% of Windows PCs met those requirements (it's certainly higher now but still well less than 50%).
If I build a PC that complies with SL3000, will Disney+ work on 1080p and UHD (because that's what SL3000 was supposed to be for)? Nope. Nobody has managed to get it working, regardless of configuration. See why I say "arbitrary demands"?

The "photon exploit" of putting a really good camera on a tripod aimed at a really good TV in a dark room isn't closable.
Recording movies playing on a flat-screen TV is what the MPAA proposed in the past as a way for teachers to exercise their fair-use rights:
https://arstechnica.com/tech-policy/2009/05/mpaa-teachers-should-video-record-tv-screens-not-rip-dvds/
but now it's apparently a "piracy exploit" (and is been targeted by schemes like Cinavia as a "loophole" to be closed). See how DRM in its current form slowly redefines fair-use rights as "piracy" (if not de-jure, certainly de-facto)?

rwill

16th June 2024, 18:29

I'm not sure what you think rights holders should do instead? Leave gaping security holes just so people on low market share operating systems with older hardware can play optical disks instead of just buying a player?

Ah, but what would these people do with a player. Most of these people won't buy discs even if they have a player. A player is useless without discs.

rwill

16th June 2024, 18:36

Recording movies playing on a flat-screen TV is what the MPAA proposed in the past as a way for teachers to exercise their fair-use rights:
https://arstechnica.com/tech-policy/2009/05/mpaa-teachers-should-video-record-tv-screens-not-rip-dvds/
but now it's apparently a "piracy exploit" (and is been targeted by schemes like Cinavia as a "loophole" to be closed). See how DRM in its current form slowly redefines fair-use rights as "piracy" (if not de-jure, certainly de-facto)?

I do not think the problem is with a teacher showing his pupils some snippets of a movie in a classroom.

I think the problem is with certain people making whole movies available as CamRips available on the internet for download.

kurkosdr

16th June 2024, 20:10

I do not think the problem is with a teacher showing his pupils some snippets of a movie in a classroom.
And yet, the teacher's fair use rights are affected. Not only the teacher has to film the video from a flat-screen TV in real-time (as per MPAA instructions), but if the resulting DVD with the snippets gets played on a standalone Blu-ray player, it can trigger a Cinavia warning (and mute playback).

Instead, people who know some things about DRM know not to use Blu-ray players for copied content that may contain Cinavia (aka content copied from DVDs or Blu-rays) and aren't affected.

I think the problem is with certain people making whole movies available as CamRips available on the internet for download.
And yet, not a single DRM system has managed to stop those people. Also, ever notice how DRM systems for movies tend to persist even if the DRM has been cracked to bits? Unlike the videogame industry where Denuvo is usually removed after cracked for a given title? It's as if fair-use, format-shifting, and content ownership are the real targets here. Not that compromising users' fair-use, format-shifting, and content ownership is acceptable even if some magic DRM that stops "pirates" existed, but it shows the true priorities of DRM: You can rip an audio CD to your tablet using Windows Media Player or iTunes, but not a DVD because DVD contains DRM (and the anti-circumvention provisions of the DMCA come into play). Also, MicroSD cards and MemoryStick cards support DRMed content but no studio has provided official support for ripping DVDs to MicroSD or MemoryStick using those DRM schemes. I wonder why... maybe selling the same content over and over has something to do with it.

Anyway, this topic has been well-covered in doom9 (both forum.doom9.org and doom9.org). But I can't let it slide when people try to bring up the "content security" excuse.

modus-ms325c

16th June 2024, 21:42

Unlike the videogame industry where Denuvo is usually removed after cracked for a given title?except not really?
FFXV WINDOWS EDITION has a Steam ver with denuvo *still* built-in, same with MGSV. both hadn't had a new crack in *years*.
FIFA16, JD2017, Handball17, M&MH7 and even EA SWBF1 got their actual real crack literally YEARS after they were released and they (NOT the cracks themselves!) still have denuvo.

kurkosdr

17th June 2024, 00:56

except not really?
FFXV WINDOWS EDITION has a Steam ver with denuvo *still* built-in, same with MGSV. both hadn't had a new crack in *years*.
FIFA16, JD2017, Handball17, M&MH7 and even EA SWBF1 got their actual real crack literally YEARS after they were released and they (NOT the cracks themselves!) still have denuvo.
I said usually, not always. Meanwhile studios still release all the DVDs with CSS (despite CSS being cracked to bits by this point) just to prevent format-shifting (aka ripping) using common tools. Gotta sell the same content multiple times somehow.

rwill

17th June 2024, 05:44

@ShortKatz: Is this with an Intel or ARM MacBook Pro ?

@birdie: Regarding x265 being better than vvenc at low resolutions ->

TL/DR:

vvenc: 40.1422 YUV PSNR
x265: 38.3294 YUV PSNR
Mystery HEVC: 38.7632 YUV PSNR

Long Version:

I don't know... does not look like x265/HEVC being better than vvenc at low resolutions.

Encoding good old 352x288 foreman_cif.yuv at 200kbit/sec yields:

vvenc:

./vvencapp -i foreman_cif.yuv -s 352x288 -c yuv420 --framerate 25 --framescale 1 --preset slower -b 200k --pass 1 --rcstatsfile stats.stats --sdr sdr_709 -o foreman_cif.266 -ip 300 --qpa 0
./vvencapp -i foreman_cif.yuv -s 352x288 -c yuv420 --framerate 25 --framescale 1 --preset slower -b 200k --pass 2 --rcstatsfile stats.stats --sdr sdr_709 -o foreman_cif.266 -ip 300 --qpa 0

vvencapp [info]: Total Time: 1139.730 sec. Fps(avg): 0.263 encoded Frames 300

298009 Jun 17 06:38 foreman_cif.266

-> 40.1422 YUV PSNR

x265:

./3.6+1-dd1ef69b2/Win64/x265 --input foreman_cif.yuv --fps 25 --input-res 352x288 --input-depth 8 --profile main10 --tune psnr --bitrate 200 --pass 1 -o trash_x265.265 --preset placebo --psnr -I 300
./3.6+1-dd1ef69b2/Win64/x265 --input foreman_cif.yuv --fps 25 --input-res 352x288 --input-depth 8 --profile main10 --tune psnr --bitrate 200 --pass 2 -o trash_x265.265 --preset placebo --psnr -I 300

encoded 300 frames in 105.40s (2.85 fps), 196.70 kb/s, Avg QP:32.86, Global PSNR: 38.391
encoded 300 frames in 118.37s (2.53 fps), 200.31 kb/s, Avg QP:32.50, Global PSNR: 38.639
(2 passes, and x265 seems to calculate Global PSNR 'differently')

304084 Jun 17 06:38 trash_x265.265

-> 38.3294 YUV PSNR

Mystery HEVC Encoder:

??????????????

Encoding time: 113.30 sec
Encoding time: 120.61 sec

300111 Jun 17 06:38 trash_mystery.265

-> 38.7632 YUV PSNR

birdie

17th June 2024, 06:56

I'm not a big believer in PSNR and I generally prefer to inspect the results using my old analogue eyes.

Also, I mentioned visually lossless encoding and PSNR at 40 doesn't look like it at the slightest. Shouldn't it be much much higher?

You're not testing how well these encoders behave at visually lossless encoding, you've tested how much they maimed the source video when being severely bitrate constrained. I couldn't care less about this usage scenario. In fact I don't understand who and why would ever need it.

oibaf

17th June 2024, 10:36

What is the "Mystery HEVC Encoder"?

rwill

17th June 2024, 10:45

Well, do you have a source for your statement that x265 is better than vvenc at lower resolutions at visually lossless encoding? Besides your analogue eyes?

birdie

17th June 2024, 12:22

Whelp, here it is (https://mega.nz/folder/ipVR0ZRI#Prw_EZpKQ-ez3nMHLqlhbA).

Open the PNG files and check how vvenc abso-fecking-lutely crushed the thumb fine details. The difference is night and day. And I've not even used any fancy x265 encoding flags.

And the encoding time for vvenc was about 20 times longer. It's a disaster.

And that's why I don't trust PSNR and other fancy automatic video quality assessment metrics. You may get better numbers but the net result will be utter crap.

kurkosdr

17th June 2024, 13:29

birdie

17th June 2024, 13:58

Why do people still use PSNR other than a complementary metric? It should be well-known by this point that PSNR doesn't accurately measure picture quality because it tends to favor blur over maintaining psychovisual quality. Use SSIM (or VMAF).

I'm not well versed in all these metrics but what I'm looking forward to is a metric that finds contrast edges and compares based on that.

Contrast edges are the image areas where you can clearly see lines and other abrupt changes that are not gradients. Video codecs have been able to encode gradients with a very high efficiency lately but that's not what video encoding IMO is in general about.

There have been a number of AI encoding companies that have popped up recently, and that's exactly what they're doing. They use AI techniques to identify the areas of the frame that are gradients or something that doesn't require a lot of bitrate and the areas that have fine detail. Then they tell the video codec how to use its bitrate allocation for that frame, and the result is spectacular.

SSIM is probably it but I've heard that encoders have learned to cheat this metric as well, so I still prefer to use my eyes to judge the end result.

birdie

17th June 2024, 14:18

birdie

17th June 2024, 14:32

And SSIM doesn't seem to paint the right picture either Image similarity comparison simulating human perception (https://github.com/kornelski/dssim) :

$ dssim img-source.png img-vvenc.png img-x265.png
0.002890 img-vvenc.png
0.003232 img-x265.png

0 meaning no difference and then going to infinity for something completely different.

It's only PNG that seems to get it right:

ls -l *png
587014 img-vvenc.png
657898 img-x265.png
689009 img-source.png

Where there's more complexity you get a bigger file size.

kurkosdr

17th June 2024, 14:40

Most modern codecs allow you to "tune" for a particular metric (at least for psnr or ssim), x265 does, does vvcenc have the ability to "tune" for a particular metric? If so, try comparing x265 and vvcenc both "tuned" for the same metric.

And then there is always the possibility that vvcenc sucks for 1080p SDR content compared to x265.

birdie

17th June 2024, 14:41

Most modern codecs allow you to "tune" for a particular metric (at least for psnr or ssim), x265 does, does vvcenc have the ability to "tune" for a particular metric? If so, try comparing x265 and vvcenc both "tuned" for the same metric.

I've not tuned x265 or vvenc for anything and that's exactly how most people use video codecs. I've used 100% default settings (except for disabling SAO for x265 which blurs out everything).

And then there is always the possibility that vvcenc sucks for 1080p SDR content compared to x265.

Exactly what I claimed earlier: modern codecs, AV1/VVC are optimized for 4K/HDR/10/12bit videos.

kurkosdr

17th June 2024, 18:16

I've not tuned x265 or vvenc for anything and that's exactly how most people use video codecs. I've used 100% default settings (except for disabling SAO for x265 which blurs out everything).
By disabling SAO, you did change something in x265. I wonder what the equivalent of SAO for VVC is (and what the switch is on vvcenc)

But anyway, the correct procedure is to use the same tuning or disable any tunings, no matter what the default settings are.

ShortKatz

17th June 2024, 18:40

@ShortKatz: Is this with an Intel or ARM MacBook Pro ?

It is an Intel MacBook Pro (would like to wait for M4 for my switch).

birdie

17th June 2024, 19:49

By disabling SAO, you did change something in x265. I wonder what the equivalent of SAO for VVC is (and what the switch is on vvcenc)

But anyway, the correct procedure is to use the same tuning or disable any tunings, no matter what the default settings are.

https://github.com/fraunhoferhhi/vvenc/wiki/Usage - I don't see anything SAO (Sample Adaptive Offset loop filter) related.

You'd think that a brand new codec with roughly three times more instruments (algos) to conserve bitrate doesn't need some special options not to blur everything out, no?

Anyways, I've reenabled SAO for x265, the result is slightly softer but still substantially better than for vvenc at the same bitrate.

All the files have been uploaded to the same shared mega folder.

VVC implements an additional new in-loop Adaptive Loop Filter (ALF) on top of the DBF and the SAO filter, the latter remaining unchanged compared to HEVC.

No idea how to disable it.

Edit:

Interesting. CTU32 is faster because of smaller search space, but for your command also because of the improved multi-threading, this explains the very high differences. To have a proper comparison you'd also need to compare the resulting quality.

To reduce blurriness I'd recommend trying one of: --ALF=0, --MCTF=0. It'll significantly increase the bitrate, so you might also just want to try to decrease QP/increase target bitrate.

Source (https://github.com/fraunhoferhhi/vvenc/discussions/203#discussioncomment-3837464).

benwaggoner

18th June 2024, 03:34

And vmaf straight out lies about my encodes:

$ vmaf -r source.y4m -d vvenc.y4m
VMAF version 2.3.0
30 frames ⡃⢐ 31.97 FPS
vmaf_v0.6.1: 99.889631

$ vmaf -r source.y4m -d x265.y4m
VMAF version 2.3.0
30 frames ⡃⢐ 31.61 FPS
vmaf_v0.6.1: 99.843432

$ vmaf -r source.y4m -d source.y4m
VMAF version 2.3.0
30 frames ⡃⢐ 31.01 FPS
vmaf_v0.6.1: 99.914262

1. It says vvenc did a better job while my eyes clearly see otherwise
2. It assigns near perfect scores to the encodes both of which are hardly visually lossless
3. When the source is equal to the result the score is not 100. That's just funny.
VMAF is just a machine learning MOS predictor trained originally on some pretty basic x264 variants and subjective ratings scores. I hope Netflix has added newer codecs and modes to its ground truth data, but I would be seriously surprised if the public VMAF model has ever seen a VVC bitstream, and so doesn't have any implicit knowledge of how people would subjectively rate VVC-style artifacts.

Like any ML model, VMAF does pretty well in interpolating values within the range of things tested in its ground truth data corpus, but is going to be a lot less predictable at extrapolating values for content that has attributes outside of what it has been trained on.

Still, it's about as good as we have for "objective" metrics. The p1204 metric in full reference mode but excluding bitstream data may do as well or better.

As always in the early days of encoder development and tuning, we need to rely on our eyeballs first and foremost until we get updated metrics and/or some experience with how to usefully apply existing metrics.

rwill

22nd June 2024, 13:29

What is the "Mystery HEVC Encoder"?

That is... a Mystery!

It is an Intel MacBook Pro (would like to wait for M4 for my switch).

Hm, some of my Mac using colleagues reported thermal Problems when they did processing for more than 5 Minutes or so. And I hope yours is new enough to support AVX2.
M4 eh? When I look at the vvenc source the x86 specific folder has around 900kb of files, the arm specific folder 50kb. Good Luck ..

MZ/X

2nd July 2024, 16:02

Just a notification about a VVC/H266 capable Windows video player.

The latest Mpxplay-MMC v3.21 uses FFmpeg v6.1.1 with VVdec Fraunhofer Versatile Video Decoder v2.3.x (20240625) to play VVC encoded content.
AV1 sw/hw decoding and DVB devices are also supported.
There are 32/64 bit and installer/portable versions.

Homepage: https://mpxplay.sourceforge.net
FB page: https://www.facebook.com/mpxplay

FranceBB

3rd July 2024, 00:06

Looks like there's gonna be some joy for those running Linux as well as far as H.266 hardware decoding is concerned.
In the last release of libva (https://github.com/intel/libva/releases/) (2.22) from Intel the changelog says:

- Added VVC decode LibVA interface.

This is almost definitely for the GPUs included in the upcoming Intel Lunar Lake processors, so come September of this year whoever is gonna buy those processors is gonna have VA-API support for H.266 hardware decoding, which means MPV hardware decoding straight out of the box. Now that's pretty cool.

birdie

3rd July 2024, 08:05

FranceBB

3rd July 2024, 13:06

Lunar Lake laptops are yet to be released.

Yep, but by the end of the year, so things are starting to come together. :)

nevcairiel

3rd July 2024, 13:08

which means MPV hardware decoding straight out of the box. Now that's pretty cool.

It does not mean that. You still need a decoder to actually utilize the libva interface for that - eg. ffmpeg needs to implement it. And with expensive mobile-only hardware being the only testbed .. unless Intel sponsors a developer to do that by providing hardware, might take a while.

FranceBB

3rd July 2024, 22:07

Ah... I see... :(

MoSal

4th July 2024, 00:50

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

PatchWorKs

4th July 2024, 07:35

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

Hope that helps.

birdie

4th July 2024, 15:02

MoSal

4th July 2024, 22:14

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 (https://rpmfusion.org/) always existed for the purpose of providing "freeworld" (https://admin.rpmfusion.org/pkgdb/package/free/mesa-freeworld/) packages.

birdie

5th July 2024, 09:16

For the misguided minority that chooses to use Fedora as a desktop daily driver, a well maintained 3rd party ;) repository (https://rpmfusion.org/) always existed for the purpose of providing "freeworld" (https://admin.rpmfusion.org/pkgdb/package/free/mesa-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

5th July 2024, 13:59

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

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.

a well maintained 3rd party repository (https://rpmfusion.org/) always existed for the purpose of providing "freeworld" (https://admin.rpmfusion.org/pkgdb/package/free/mesa-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

9th July 2024, 19:26

Brazil2

10th July 2024, 00:38

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

FranceBB

17th July 2024, 22:14

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

https://github.com/intel/cartwheel-ffmpeg/releases/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. :D
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

17th July 2024, 22:28

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

GeoffreyA

18th July 2024, 14:56

benwaggoner

18th July 2024, 18:49

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

19th July 2024, 00:10

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

https://github.com/intel/cartwheel-ffmpeg/releases/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. :D
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

19th July 2024, 09:57

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

19th July 2024, 20:48

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

Fraunhofer VVC Encoder ver. 1.12.0 (https://www.mediafire.com/file/n31gl1nuqepwsaq/vvenc_1.12.0-d57c73d.7z/file) d57c73d

Fraunhofer VVC Decoder ver. 2.3.0 (https://www.mediafire.com/file/ztehu2gst8c4zkd/vvdec_2.3.0-c7e2f8b.7z/file) c7e2f8b

uvg266: over here (https://forum.doom9.org/showthread.php?p=2004533#post2004533)

birdie

24th August 2024, 13:08

VVC has been pronounced dead (https://streaminglearningcenter.com/codecs/the-reality-of-codec-adoption-in-six-pictures.html).

FranceBB

24th August 2024, 17:18

VVC has been pronounced dead (https://streaminglearningcenter.com/codecs/the-reality-of-codec-adoption-in-six-pictures.html).

This is the graph from that article:

https://streaminglearningcenter.com/wp-content/uploads/2024/08/codec_adoption2-768x429.png

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

24th August 2024, 18:07

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

24th August 2024, 18:34

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.

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

25th August 2024, 22:24

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

31st August 2024, 02:46

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.

FranceBB

31st August 2024, 16:59

On a more positive news, it looks like Nou Mi is still working on libav's H.266 VVC decoder as he just added manually written AVX2 assemblies: Link (https://github.com/FFmpeg/FFmpeg/commit/15eb10c6deea1103d5ae7c5acd36e10af511672b)
If I find the time (and that's a big "if") this week and I'll compile a new version of FFMpeg to test how the decoder is doing in my series of sample test clips in terms of speed now that AVX2 have been introduced. :)
Hopefully it will reduce the gap between libav and VVDec.

birdie

31st August 2024, 21:47

Z2697

3rd September 2024, 05:34

GeoffreyA

3rd September 2024, 09:55

They said they were not going to accept libvvdec and that's why Nuo Mi had to write a "native" decoder from scratch (no one forced him of course, but if anyone wants vvc decode in ffmpeg, someone has to write a native one).
It's not like they "forced" people to write native av1 decoder, they just use libdav1d, but hey, what can I say, perhaps the fact that the dav1d is developed by videolan makes them happier.

I remember reading the discussion about that. There seemed to be politics going on, where one of the developers was opposing that anything VVC should be included. There was also opposition to the native decoder that Nuo Mi and others had been working on for some time. If I remember correctly, Mi reasoned that, if not the native decoder, using libvvdec for the time being would allow them to work on the CBS module, etc.

nevcairiel

3rd September 2024, 11:13

FranceBB

3rd September 2024, 13:05

Yep, the native decoder was in the works and therefore they pushed back on the inclusion of VVDec much to Adam Wieckowski's disappointment.
I was also a bit disappointed and many people were, 'cause the whole thing wasn't 100% clear back then and many people thought that the patches were being refused 'cause there were some hardcore AV1 supporter that wanted to see H.266 VVC fail. That wasn't true, of course, but the fact that people didn't know that there was a native decoder in the works led to some very speculative (and often rude) comments in the mailing list and on various channels. What's ironic is that the refinement and improvement of the H.266 VVC decoder were done as one of the projects of the Google Summer of Code 2023 Link (https://summerofcode.withgoogle.com/archive/2023/organizations/ffmpeg) by Nuo Mi, Anton Khirnov and of course Frank Plowman, so, ironically, Google, the one behind AV1, sponsored that. This obviously brought all the flame and the controversies to an end, but still the amount of disinformation that spread earlier on was astonishing and the whole thing was very sad to read... :(

Z2697

3rd September 2024, 21:10

I didn't really paid attention to the timeline when I saw that conversation, that's true. I can't find it again, anyone has link to that mailing list thread? (where they also discussed libdav1d being integrated and libopus being the only non-experimental encoder for opus, but the main topic is libvvdec)

GeoffreyA

3rd September 2024, 21:44

Z2697

4th September 2024, 14:36

https://patchwork.ffmpeg.org/comment/60589/

That's exactly what I was looking for! Thanks!

So the conversation was indeed happend long before we see the work of native vvc decoder in public, but after being reminded by nevcairiel and FranceBB I realized I shouldn't just imagine some conspiracy based on that. I mean maybe there're non-public developments.

Nuo Mi said in that thread:
We will not have a useable native vvc decoder in 0.5~1 years.

I don't know if that "we" refers to a team that Nuo Mi is/was in and was already working on native vvc decoder that moment.

GeoffreyA

4th September 2024, 15:36

I think it will be hard to know without asking Nuo Mi. If we look at the ffvvc fork where they developed the decoder, the first commits by Mi were after the date of that discussion (except for one related to HEVC).

https://github.com/ffvvc/FFmpeg/commits/main/?author=nuomi2021&after=e81b6d78fc2ddf8edd53a6a052713354ef8d27c2+34

hajj_3

5th September 2024, 00:08

Allegro DVT Launches The Industry’s First Real-Time VVC/H.266 Encoder IP

https://www.allegrodvt.com/news/allegro-dvt-industrys-real-time-vvc-h-266-encoder-ip/

birdie

5th September 2024, 13:11

Allegro DVT Launches The Industry’s First Real-Time VVC/H.266 Encoder IP

https://www.allegrodvt.com/news/allegro-dvt-industrys-real-time-vvc-h-266-encoder-ip/

That's old news and I mentioned it in the WP article (https://en.wikipedia.org/wiki/Versatile_Video_Coding#Hardware) several weeks ago.

ShortKatz

6th September 2024, 16:56

ksec

7th September 2024, 02:08

The experimental flag for VVC was removed from FFmpeg today. If you now build mpv with the most recent FFmpeg, you can play VVC files. I've tested this with 5 different VVC samples, all played without issue.

Which means we should expect this to officially land in 7.1, hopefully this October if not November.

Now we just need an encoder to play with. Unfortunately that is slower than expected. Normally we have experimental encoder first before decoder being officially a feature on FFmpeg.

Z2697

9th September 2024, 08:45

Which means we should expect this to officially land in 7.1, hopefully this October if not November.

Now we just need an encoder to play with. Unfortunately that is slower than expected. Normally we have experimental encoder first before decoder being officially a feature on FFmpeg.

libvvenc is available now, or actually, available for quite some time now.

ShortKatz

10th September 2024, 17:31

Yes, you can build FFmpeg with --enable-libvvenc to get VVC encoding support. But encoding speed is very very slow.

frankplow

12th September 2024, 20:21

Last time I checked vvdec was three times faster. I don't think ffmpeg's implementation is even close to closing the gap :-) And palette support is yet to be merged.

VVdeC also does not support the Main 10 4:4:4 profile, which includes the Palette tool.

I think Nuo Mi is focussing on performance now, seeing as the decoder is nearly Main 10 compliant. I haven't seen a difference quite as significant as 3x for some time and the gap is closing.

https://files.frankplowman.com/FFmpeg_vs_VVdeC_Sep_2024.png

(i7-8700k, 12 hyperthreads)

Jamaika

13th September 2024, 10:18

Codec VVenc quality does not pass the test with ffmpeg
https://www.sendspace.com/file/5nfqhn
frame= 0 fps=0.0 q=0.0 size= 1KiB time=N/A bitrate=N/A speed=N/A
ERROR: In function "lastPOCInCache" in RateCtrl.h:185: Accessing empty cache
[vost#0:0/libvvenc @ 000001c546ea4310] Error submitting video frame to the encoder
[vost#0:0/libvvenc @ 000001c546ea4310] Error encoding a frame: Generic error in an external library
[vost#0:0/libvvenc @ 000001c546ea4310] Task finished with error code: -542398533 (Generic error in an external library)
[vf#0:0 @ 000001c54705b300] All consumers returned EOF
[vost#0:0/libvvenc @ 000001c546ea4310] Terminating thread with return code -542398533 (Generic error in an external library)

birdie

13th September 2024, 16:27

VVdeC also does not support the Main 10 4:4:4 profile, which includes the Palette tool.

I think Nuo Mi is focussing on performance now, seeing as the decoder is nearly Main 10 compliant. I haven't seen a difference quite as significant as 3x for some time and the gap is closing.

(i7-8700k, 12 hyperthreads)

I tested the builtin decoder months ago before optimizations and even in your example VVDec is almost twice as fast for the 4K sample so there's plenty room for improvement.

I'm quite sure the builtin decoder will surpass VVDec performance wise eventually but we are not there yet.

LigH

14th September 2024, 10:20

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

Fraunhofer VVC Encoder ver. 1.12.0 (https://www.mediafire.com/file/loxwl3kfpw8mc0m/vvenc_1.12.0-a1996a8.7z/file) a1996a8

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

birdie

17th September 2024, 08:24

At IBC 2024:

4K 120fps VVC Playback with Ali266 on Snapdragon X Elite PC by Qualcomm and Alibaba
Qualcomm's Aytac Biber and Yan Ye from Alibaba will demonstrate the real-world benefits and capabilities of a decoder optimized for VVC running on Qualcomm's Snapdragon X Elite platform. This demonstration highlights the Snapdragon platform's capabilities in delivering 4K at 120 frames per second without dropping frames of skipping video. Qualcomm and Alibaba will illustrate the significant compression benefits of VVC, which allow for up to 50 percent reduction in video size and improvement of video start-up latency by 5 percent.

VVC and Web RTC Low Latency for Cloud Gaming by Ericsson
Ericsson's Per-Erik Brodin and Lukasz Litwic will showcase one the world's first integration of VVC with WebRTC for low latency video streaming in real time. Addressing the challenges of cloud gaming, Ericsson experts will demonstrate streaming a remotely rendered game to a web application running in a browser, and on mobile devices (both old and new). The application of this integration will generate an enhanced user experience with less buffering, increased game responsiveness and faster times accessing content.

IMAX, MediaKind, Fraunhofer HHI and Ericsson present their work on encoder optimisations and film grain processing
The encoder optimization papers include a means to optimize the trade-off between bit storage and transcoding in multi-profile video delivery systems, whilst the other uses a Large Modal Model (LMM) to successfully improve content-aware encoding decisions.

Next, film grain. A well-known problem which presents increasing challenges as codec efficiency improves - and it is not going away, as movie directors continue to choose film for artistic effect. One of our papers presents and illustrates the Film Grain Synthesis system employed in VVC, while the other aims to produce an objective perceptual assessment metric by training a model with examples from expert viewers’ subjective assessments. This is important as typical video coding assessment metrics do not work well when comparing synthesized film grain.

Z2697

17th September 2024, 08:40

The current form of FG synthesis is TRASH, using it in any case other than "contents designed for FG synthesis" (which apparently is not a real thing) is abuse.

benwaggoner

18th September 2024, 10:16

The current form of FG synthesis is TRASH, using it in any case other than "contents designed for FG synthesis" (which apparently is not a real thing) is abuse.
You mean the old one from AVC that has been recycled? AFAIK the only customer-facing use of it was a singular HD-DVD release circa 2007.

I was asking some questions about it at IBC, and wasn't able to get a straight answer for how and how well it works with HDR. If it is based on 709 code values, it could give some weird results with HDR.

It's hard to judge the quality of the synthesis without having better parameterization and removal algorithms up front. IMAX demoed a Film Grain Similarity metric at IBC that looks promising; having to do everything with subjective evaluation really slow things down.

benwaggoner

18th September 2024, 10:18

At IBC 2024:
All the papers are now available for download here:

https://www.ibc.org/technical-papers/ibc-technical-papers-presentation-sessions/9995.article

Z2697

18th September 2024, 12:04

You mean the old one from AVC that has been recycled? AFAIK the only customer-facing use of it was a singular HD-DVD release circa 2007.

I was asking some questions about it at IBC, and wasn't able to get a straight answer for how and how well it works with HDR. If it is based on 709 code values, it could give some weird results with HDR.

It's hard to judge the quality of the synthesis without having better parameterization and removal algorithms up front. IMAX demoed a Film Grain Similarity metric at IBC that looks promising; having to do everything with subjective evaluation really slow things down.

I mean what is widely and easily available now, which just mean those in AV1 (there's no one-click solution on MPEG side as far as I know of).
The parameterization and removal algorithms up front is exactly what I mean. I know perceptual noise substitution is working in audio codecs pretty well but it's just far more complicated when it comes to video. As of now they are just putting some funny dancing dots on the screen and demolishing high frequency.
(Is there a way to make a static or less dynamic pattern out of AV1's FGS?)

benwaggoner

23rd September 2024, 19:29

I mean what is widely and easily available now, which just mean those in AV1 (there's no one-click solution on MPEG side as far as I know of).
The parameterization and removal algorithms up front is exactly what I mean. I know perceptual noise substitution is working in audio codecs pretty well but it's just far more complicated when it comes to video. As of now they are just putting some funny dancing dots on the screen and demolishing high frequency.
(Is there a way to make a static or less dynamic pattern out of AV1's FGS?)
There's a lot that can be tweaked in AVFG1.

At IBC IMAX demonstrated their new Film Grain Similarity objective metric. I've not tested hands-on with it, but even if it is only mediocre, that's going to be a huge step forward in making FGS works. Right now we have to eyeball how similar grain is subjectively to know if it did a decent job.

GeoffreyA

24th September 2024, 07:59

This is reminscent of the advanced features in MPEG-4 ASP that were not very usable. Then, H.264 did some of those things right and in simpler fashion. Or, at least, that was the case with quarter pixel. GMC's ideas saw later use in AV1.

ksec

29th September 2024, 16:01

4K 120fps VVC Playback with Ali266 Software decoder on Snapdragon X Elite PC with no drop frames? The future is bright!

Any news about H.266 encoders?

benwaggoner

30th September 2024, 18:35

4K 120fps VVC Playback with Ali266 Software decoder on Snapdragon X Elite PC with no drop frames? The future is bright!

Any news about H.266 encoders?
A number of live encoders were demonstrated at IBC, and some academic papers. Most of the academic work seems to be using VVEnc for testing now, and are getting competitive results out of it.

There was at least one 8Kp60 live encoder demonstrated, which was pretty amazing.

benwaggoner

1st October 2024, 02:13

4K 120fps VVC Playback with Ali266 Software decoder on Snapdragon X Elite PC with no drop frames? The future is bright!
VVC is really impressive in its balance of compression efficiency improvement for increase in decoder complexity. It offers significantly better compression than AV1 with significantly less silicon.

Of course, given Moore's Law, the actual relative cost of decoders keep dropping generation by generation. It was only a few decades ago that $5/decoder was considered an acceptable license fee for a MPEG-2 decoder, given it was only a fraction of the cost.

Having a decoder that pushed a phone SoC cost up by even $2 would be a dealbreaker today for high volume low margin devices.

LigH

1st October 2024, 08:28

Modern video codecs are highly asymmetrical in general. The main effort in the encoder is searching for reduncancies that can be used to avoid intra coding. Reproducing content from previously known content in a decoder, in relation, hardly costs any CPU power.

birdie

1st October 2024, 19:42

BTW ffmpeg 7.1 with VVC decoding support elevated to official status has been released:

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

There's also an xHE-AAC decoder though its implementation is incomplete.

kurkosdr

2nd October 2024, 18:05

VVC is really impressive in its balance of compression efficiency improvement for increase in decoder complexity. It offers significantly better compression than AV1 with significantly less silicon.

Of course, given Moore's Law, the actual relative cost of decoders keep dropping generation by generation. It was only a few decades ago that $5/decoder was considered an acceptable license fee for a MPEG-2 decoder, given it was only a fraction of the cost.
The corollary is also true: Thanks to Moore's Law, silicon is relatively cheap nowadays, so it's preferable to throw some extra silicon to an AV1 encoder (compared to an VVC encoder) than deal with the licensing costs of VVC (with every one of the 10 patent-licensing entities). This explains the success of AV1 in services like Netflix.

ksec

3rd October 2024, 14:24

LigH

3rd October 2024, 14:30

You can already include xeve and xevd in ffmpeg.

excellentswordfight

4th October 2024, 13:29

Of course, given Moore's Law, the actual relative cost of decoders keep dropping generation by generation.
Moore's Law at an economical level is deader then dead, the cost of a 5/4nm TSMC waffer has pretty much stayed the same for four years according to all estimates i've seen, and that goes for a lot other process nodes as well, and new advance nodes has worse transistor/usd than previous nodes. It used to be the case that you wanted to migrate to a smaller node cause it was cheaper (maybe not the most cutting edge one initially), but nowdays the cheapest nodes are really old at this point, and even there I dont think cost is dropping cause of inflation and lack of technical advancements.

There is a reason why we barely seen any drop in consumer electronic the last couple of years. Part is ofc the pandemic and inflation, but there is also just a matter of physics and reality of increase in complexity of new nodes.

It has been discussed for at least 10 years; that this was going to happen, and yes we are now there, and has been for a couple of years now.

"In the dynamic field of semiconductor technology, the ongoing discourse surrounding Moore’s Law has experienced a notable evolution, prominently featuring Zvi Or-Bach’s (MonolithIC 3D’ CEO) 2014 assertion. His statement that transistor cost scaling reached a pivotal juncture at 28 nm has attracted significant attention. The statement was recently validated by Milind Shah from Google in the Short Course (SC1.6 ) at IEDM 2023. The unequivocal statement, “Transistor cost scaling (0.7X) stalled at 28 nm and remains flat gen over gen,” confirms what was initially foreseen in earlier public viewpoints and blogs in 2014 predicting the conclusion of Moore’s Law."

https://www.semiconductor-digest.com/moores-law-indeed-stopped-at-28nm/

Even Nvidia flagged for this back in 2012 that this trend would lead to a huge spike in costs if we wanted to continue to scale performance with transistors count...

benwaggoner

4th October 2024, 21:01

Moore's Law at an economical level is deader then dead, the cost of a 5/4nm TSMC waffer has pretty much stayed the same for four years according to all estimates i've seen, and that goes for a lot other process nodes as well, and new advance nodes has worse transistor/usd than previous nodes. It used to be the case that you wanted to migrate to a smaller node cause it was cheaper (maybe not the most cutting edge one initially), but nowdays the cheapest nodes are really old at this point, and even there I dont think cost is dropping cause of inflation and lack of technical advancements.

There is a reason why we barely seen any drop in consumer electronic the last couple of years. Part is ofc the pandemic and inflation, but there is also just a matter of physics and reality of increase in complexity of new nodes.

It has been discussed for at least 10 years; that this was going to happen, and yes we are now there, and has been for a couple of years now.

"In the dynamic field of semiconductor technology, the ongoing discourse surrounding Moore’s Law has experienced a notable evolution, prominently featuring Zvi Or-Bach’s (MonolithIC 3D’ CEO) 2014 assertion. His statement that transistor cost scaling reached a pivotal juncture at 28 nm has attracted significant attention. The statement was recently validated by Milind Shah from Google in the Short Course (SC1.6 ) at IEDM 2023. The unequivocal statement, “Transistor cost scaling (0.7X) stalled at 28 nm and remains flat gen over gen,” confirms what was initially foreseen in earlier public viewpoints and blogs in 2014 predicting the conclusion of Moore’s Law."
Yeah, things have really slowed down. It's amazing we had a run as long as we had; I remember working on an industrial marketing video in the mid 90's touting "deep sub micron" support - down to 400 nm!

For. compression it's not so bad, as we benefit a lot from multiple cores and SIMD instructions, so we about as big a generation-on-generation throughput improvement as anyone.

And smaller processes still give us better density and thermals, which should allow for more performance (less time for a signal to cross from one edge to the other of a SoC) and probably better FLOPS/watt and thus FLOPS/$ due to reduced power consumption for the processing itself and the cooling required.

Some process stability would still allow for better refinement and optimization for existing processes. When each architecture revision is coupled with a new process, that doesn't really leave that long to make sure the bang-per-transistor is really optimized, and means that backwards compatibility is a higher priority, as a new revision will be be out before existing software is deprecated.

If we knew we were going to be stuck at 1 nm for a decade plus, we could really think hard about the optimal long-term ISA and architectures, and be able to build hardware and software towards much less of a moving target.

I was at the Samsung Developer Conference yesterday, and they were really touting RISC-V for Tizen (their OS for pretty much everything but phones). Perhaps related?

benwaggoner

4th October 2024, 21:04

tl;dr we should be thinking about throughput per watt as a big factor in the ROI of new processes at least as much as $/transistor. For many applications the lifetime cost of power for computing and cooling will be a lot more than the cost of the processor. So we still have some runway of economic benefit from smaller processes even if the $/transistor starts rising significantly.

hajj_3

31st October 2024, 17:27

https://accessadvance.com/wp-content/uploads/2024/10/2024Q4-VVC-Patent-Diagram-10-01-24-1440x1080.jpg

FranceBB

2nd November 2024, 16:13

More interesting stuff coming from Intel with the two following commits to lavc

1)
https://github.com/FFmpeg/FFmpeg/commit/4dc18c78cd1872a6de0b9640a4c5eca35f5dfbfd

2) https://github.com/FFmpeg/FFmpeg/commit/e726fdeb0550d121e287fc9c5ee6673ab8f66bf4

They have now exposed hardware decoding APIs in lavc so that even on Linux their new Lunar Lake GPUs can have hardware accelerated decoding for H.266 VVC. This will again spread soon via ffmpeg to things like MPV and it will make H.266 decoding easier. I know that Intel isn't exactly in a good place right now, but it's nice to see them directly contributing to open source projects. Also we're still at the end of 2024, it's a long way before July 2026, but it's nice to see widespread software decoding support thanks to libav and now the first cross platform hardware decoding support. :)

Z2697

2nd November 2024, 16:18

FranceBB

2nd November 2024, 17:04

What's July 2026 about?

TX, i.e beginning of linear channel tv transmissions in H.266 VVC to end consumer devices.

Z2697

2nd November 2024, 17:51

TX, i.e beginning of linear channel tv transmissions in H.266 VVC to end consumer devices.

Long way to go ;)

kurkosdr

2nd November 2024, 20:25

TX, i.e beginning of linear channel tv transmissions in H.266 VVC to end consumer devices.
Source? And what countries?

FranceBB

3rd November 2024, 14:54

Source? And what countries?

Nothing new here, I'm still talking about Brazil.
I don't live there, but I'm keeping an eye on TV 3.0 and what the V-Nova guys post on LinkedIn 'cause they're gonna be at the forefront of this, so if they succeed then H.266 more generally will succeed in broadcast.

The timeline stayed the same so far by the way, but I've added the new hardware decoding support that Intel just submitted to lavc:

- 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, VLC, MPV, Avisynth, VapourSynth)
- July 2024 -> Consumer TV becoming available
- September 2024 -> Intel Lunar Lake Graphics hardware decoding support
- November 2024 -> Lavc adds hardware decoding support for Intel Lunar Lake Graphics (FFmpeg, VLC, MPV)

Which leads us to:

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

Selur

8th November 2024, 08:34

Does any of the vvc encoders atm. support other color sampling than 4:2:0 ?

LigH

8th November 2024, 13:13

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

Fraunhofer VVC Encoder ver. 1.12.1-rc1 (https://www.mediafire.com/file/a4leabop1lldw97/vvenc_1.12.1-rc1-da540e6.7z/file) da540e6

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

birdie

9th November 2024, 09:41

Does any of the vvc encoders atm. support other color sampling than 4:2:0 ?

The second link in Google and https://en.wikipedia.org/wiki/Versatile_Video_Coding

Have you even tried?

https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM

YUV420
YUV422
YUV444

and 12bit encoding (probably)

It's dead slow.

Z2697

9th November 2024, 13:29

If you take "4:0:0" into account... hmm... both VVenC and uvg266 seem to support that.
And while VVenC have options related to 4:4:4 and 4:2:2 in the command line help message, it throws error when I give it YUV444 Y4M, I think it's not implemented yet.

LigH

9th November 2024, 13:58

VTM is the "reference software", hardly optimized at all. If any encoder is "complete", then this one. But not practically useable.

PS: You can try vvencFFapp:

--InputChromaFormat [420] input file chroma format (400, 420, 422, 444)

Please note that the options are so verbose, you better create a configuration file instead of trying to feed all options via CLI.

Selur

9th November 2024, 14:34

VTM is the "reference software", hardly optimized at all. If any encoder is "complete", then this one. But not practically useable.
I agree, VTM is not useable.

vvencapp states:
-c, --format [yuv420] set input format (yuv420, yuv420_10, yuv420_10_packed, yuv400 (gray), yuv400_10
uvg266 states:
--input-format <string> : P420 or P400 [P420]

=> I will look at vvencFFapp then. (ah, only the full help does state InputChromaFormat :))

Thanks!

Cu Selur

Sagittaire

9th November 2024, 18:58

VTM is the "reference software", hardly optimized at all. If any encoder is "complete", then this one. But not practically useable.

Well if you use x265 with preset placebo or SVT-AV1 with preset 0, you obtain really low speed too. Use the slowest preset for codec is never obligation.

VVCEnc with preset "faster" will produce the same speed than "veryslow" for x264, "slow" for x265 or "complexity 5" for SVT-AV1.

Moreover VVCEnc is not really optimized for more than 12 thread. If you want make encoding at 100% CPU charge for 32 thread CPU and more, you must use multipart encoding.

For exemple for VVCEnc in fast mode preset you obtain 20 fps for 1080p10 for 7950X CPU and 40 fps for preset faster.

Jamaika

9th November 2024, 23:52

Does any of the vvc encoders atm. support other color sampling than 4:2:0 ?
Try this: https://www.sendspace.com/file/tia55v

ffmpeg_avx2.exe -v verbose -f concat -safe 0 -i mylist_v.txt -f concat -safe 0 -i mylist_a.txt -c:v libvvenc -vb 6000k -c:a aac -ac 2 -ar 48000 -ab 128k -frames:v 100 -movflags faststart -threads 0 -vf scale=1920:1080:in_range=full: out_range=full,format=yuv422p10le 112.vvc
vvencapp_avx2.exe -i 111.y4m -s 1920x1080 -c yuv422 -b 6M -ip 256 --passes 1 --fps 30000/1001 -o 111.vvc

[libvvenc @ 000001f236eabd30] libvvenc version: 1.12.1-0f7b70d
[libvvenc @ 000001f236eabd30] vvenc [notice]: Internal format : 1920x1080 29.97 Hz SDR
vvenc [notice]: Threads : 10 (parallel frames: 4)
vvenc [notice]: Rate control : VBR 6 Mbps single-pass
vvenc [notice]: Perceptual optimization : Enabled
vvenc [notice]: Intra period (keyframe) : 256
vvenc [notice]: Decoding refresh type : CRA
vvenc [notice]: Sequence PSNR output : Linear average only
vvenc [notice]: Hexadecimal PSNR output : Disabled
vvenc [notice]: Sequence MSE output : Disabled
vvenc [notice]: Frame MSE output : Disabled
vvenc [notice]: Cabac-zero-word-padding : Enabled
vvenc [notice]: Frame index : all frames
vvenc [notice]: Profile : main_10_444
vvenc [notice]: Level : 4
vvenc [notice]: CU size : 128
vvenc [notice]: Max TB size : 64
vvenc [notice]: Min CB size : 4
vvenc [notice]: Motion search range : 384
vvenc [notice]: QP : 33
vvenc [notice]: Max dQP signaling subdiv : 2
vvenc [notice]: Cb QP Offset (dual tree) : 0 (0)
vvenc [notice]: Cr QP Offset (dual tree) : 0 (0)
vvenc [notice]: GOP size : 32
vvenc [notice]: PicReordering : 1
vvenc [notice]: Input bit depth : (Y:10, C:10)
vvenc [notice]: MSB-extended bit depth : (Y:10, C:10)
vvenc [notice]: Internal bit depth : (Y:10, C:10)
vvenc [notice]: cu_chroma_qp_offset_subdiv : -1
vvenc [notice]: log2_sao_offset_scale_luma : 0
vvenc [notice]: log2_sao_offset_scale_chroma : 0
vvenc [notice]: Cost function : Lossy coding
vvenc [notice]: Film grain analysis : 0

Output #0, vvc, to '112.vvc':
Metadata:
encoder : Lavf61.9.100
Stream #0:0: Video: vvc, 1 reference frame, yuv422p10le(pc, progressive), 1920x1080, q=2-31, 6000 kb/s, 29.97 fps, 29.97 tbn

Selur

10th November 2024, 08:33

Hmm, you are using an intermediate file, which I want to avoid.
Also looking at your calls:
ffmpeg_avx2.exe -v verbose -f concat -safe 0 -i mylist_v.txt -f concat -safe 0 -i mylist_a.txt -c:v libvvenc -vb 6000k -c:a aac -ac 2 -ar 48000 -ab 128k -frames:v 100 -movflags faststart -threads 0 -vf scale=1920:1080:in_range=full: out_range=full,format=yuv422p10le 112.vvc
vvencapp_avx2.exe -i 111.y4m -s 1920x1080 -c yuv422 -b 6M -ip 256 --passes 1 --fps 30000/1001 -o 111.vvc
I'm confused.
Why encode the audio when you output 112.vvc?
Where does 111.y4m come from and how can it be input and output?
using:
ffmpeg -y -loglevel fatal -noautorotate -nostdin -threads 8 -i "G:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -pix_fmt yuv422p10le -strict -1 -fps_mode passthrough -f yuv4mpegpipe - | vvencapp --input - --size 640x352 --y4m 1 -c yuv422 --framerate 25 --framescale 1 --internal-bitdepth 10 --bitrate 0 --qp 20 --profile "auto" --level "auto" --tier "main" --preset medium --qpa 1 --sdr sdr_470bg --mtprofile -1 --ifp -1 --intraperiod 250 --output "g:\test_422.vvc"
results in:
Error parsing option "format,c" with argument "yuv422".
Error parsing option "format,c" with argument "yuv422".
error: bitstream file name must be specified (--output=bit.266)

=> sorry, I can't make heads or tails out of your calls.

Cu Selur

Jamaika

10th November 2024, 08:42

Why encode the audio when you output 112.vvc?
My mistake and rush. You can create MOV in ffmpeg.
Where does 111.y4m come from and how can it be input and output?
ffmpeg.exe -y -i film_java_d.avi -f yuv4mpegpipe -pix_fmt yuv422p -frames:v 100 -strict -1 111.y4m
using:
ffmpeg -y -loglevel fatal -noautorotate -nostdin -threads 8 -i "G:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -pix_fmt yuv422p10le -strict -1 -fps_mode passthrough -f yuv4mpegpipe - | vvencapp --input - --size 640x352 --y4m 1 -c yuv422 --framerate 25 --framescale 1 --internal-bitdepth 10 --bitrate 0 --qp 20 --profile "auto" --level "auto" --tier "main" --preset medium --qpa 1 --sdr sdr_470bg --mtprofile -1 --ifp -1 --intraperiod 250 --output "g:\test_422.vvc"
results in:
Error parsing option "format,c" with argument "yuv422".
Error parsing option "format,c" with argument "yuv422".
error: bitstream file name must be specified (--output=bit.266)

=> sorry, I can't make heads or tails out of your calls.
And there should be an error. Incorrect input format entered.

Selur

10th November 2024, 08:52

using vvencFFapp:
ffmpeg -y -loglevel fatal -noautorotate -nostdin -threads 8 -i "G:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -pix_fmt yuv422p10le -strict -1 -fps_mode passthrough -f yuv4mpegpipe - | vvencFFapp --InputFile - --Size 640x352 --y4m 1 --InputBitDepth 10 --InputChromaFormat 422 --fps 25/1 --TargetBitrate 0 --QP 20 --Profile "auto" --Level "auto" --Tier "main" --preset medium --qpa 1 --sdr sdr_470bg --MTProfile -1 --IFP -1 --IntraPeriod 250 --BitstreamFile "g:\test_422.vvc"
I get:
vvencFFapp: VVenC, the Fraunhofer H.266/VVC Encoder, version 1.12.1-rc1 [Windows][GCC 14.2.0][64 bit][SIMD=AVX2]
Parameter Check Error: Intern chroma format must be either 400, 420
error: input chroma format must be either 400, 420

And there should be an error. Incorrect input format entered.
I do not get it:
-c, --format [yuv420] set input format (yuv420, yuv420_10, yuv420_10_packed, yuv400 (gray), yuv400_10 (gray10)
you used:
vvencapp_avx2.exe -i 111.y4m -s 1920x1080 -c yuv422 -b 6M -ip 256 --passes 1 --fps 30000/1001 -o 111.vvc
So I assumed that you patched that version somehow and yuv422 would be allowed now.
=> I do not get how your '-c yuv422' works for you,..

Jamaika

10th November 2024, 09:01

So I assumed that you patched that version somehow and yuv422 would be allowed now.
=> I do not get how your '-c yuv422' works for you,..
It's true I didn't change the descriptions. I'm just an amateur.
It should be 'yuv422_10'.
I'm not sure if I wrote it down correctly?
size_t frameSize = (width * height * uiBitsPerPx) >> 3;

if ( packed && bitdepth == 10 && chromaFormat == VVENC_CHROMA_420 )
{
size_t stride = width * 5 / 4;
size_t lumaSize = stride * height;
size_t chromaSize = lumaSize >> 2;
frameSize = lumaSize + chromaSize + chromaSize;
}

if ( packed && bitdepth == 10 && chromaFormat == VVENC_CHROMA_422 )
{
size_t stride = width / 2;
size_t lumaSize = stride * height;
size_t chromaSize = lumaSize >> 2;
frameSize = lumaSize + chromaSize + chromaSize;
}

if ( packed && bitdepth == 10 && chromaFormat == VVENC_CHROMA_444 )
{
size_t stride = width;
size_t lumaSize = stride * height;
size_t chromaSize = lumaSize >> 2;
frameSize = lumaSize + chromaSize + chromaSize;
}
And lastly. If I added it correctly then do we have decoder for yuv 422 and 444.

Jamaika

10th November 2024, 15:20

Testing:
Compatibility between different vvc creators in 10bit. There is no player or codec for 8bit.
I haven't tested in two years.

ffmpeg.exe -y -i "Video.mp4" -f yuv4mpegpipe -vf scale=1920:1080:in_range=full:out_range=full,format=yuv420p10le -frames:v 100 -strict -1 111.y4m
ffmpeg.exe -y -i "Video.mp4" -f yuv4mpegpipe -vf scale=1920:1080:in_range=full:out_range=full,format=yuv422p10le -frames:v 100 -strict -1 112.y4m
ffmpeg.exe -y -i "Video.mp4" -f yuv4mpegpipe -vf scale=1920:1080:in_range=full:out_range=full,format=yuv444p10le -frames:v 100 -strict -1 113.y4m

vvencapp_avx2.exe --verbosity 3 -i 111.y4m --y4m -s 1920x1080 -c yuv420_10 --preset medium --fps 30000/1001 -b 6M -ip 256 --passes 1 --threads -1 -o 111.vvc

uvg266_10bit_avx2.exe -i 111.y4m -o 112.vvc --input-file-format y4m --input-res 1920x1080 --input-format P420 --input-bitdepth 10 --preset medium --input-fps 30000/1001 --bitrate 6000000 --vps-period 256 --info --threads auto --range pc

ffmpeg_avx2.exe -y -v info -i "Best of Rallye Rally Crash & Mistakes 2018 by ToutAuCable.mp4" -c:v libvvenc -vb 6000k -r 30000/1001 -frames:v 100 -movflags faststart -threads 0 -vf scale=1920:1080:in_range=full: out_range=full,format=yuv420p10le 113.vvc

EncoderApp_REXT.exe --SummaryVerboseness -c "encoder_randomaccess_vtm.cfg" --InputFile=111.y4m --BitstreamFile=114.vvc --SourceWidth=1920 --SourceHeight=1080 --FrameRate=30000/1001 --InputBitDepth=10 --InternalBitDepth=0 --OutputBitDepth=10 --MSBExtendedBitDepth=10 --InputChromaFormat=420 --ChromaFormatIDC=420 --ConformanceWindowMode=0 --FramesToBeEncoded=100 --MatrixCoefficients=1 --InputColorPrimaries=-1 --LMCSSignalType=0 --Level=5.1 --BDPCM=1 --Tier=main --HashME=1 --IBC=1 --MaxCUWidth=16 --MaxCUHeight=16 --CTUSize=32 --QP=28 --MaxBTLumaISlice=32 --MaxBTChromaISlice=32 --MaxBTNonISlice=32 --MaxTTLumaISlice=32 --MaxTTChromaISlice=32 --MaxTTNonISlice=32 --ColorTransform=0 --VideoFullRange=1 --InputSampleRange=1 --AspectRatioInfoPresent=1 --ChromaLocInfoPresent=1 --Log2MaxTbSize=5 --RCCpbSize=2000 --RateControl=1 --TargetBitrate=6000000 --IntraPeriod=256

EncoderApp_REXT.exe --SummaryVerboseness -c "encoder_randomaccess_vtm.cfg" --InputFile=112.y4m --BitstreamFile=115.vvc --SourceWidth=1920 --SourceHeight=1080 --FrameRate=30000/1001 --InputBitDepth=10 --InternalBitDepth=0 --OutputBitDepth=10 --MSBExtendedBitDepth=10 --InputChromaFormat=422 --ChromaFormatIDC=422 --ConformanceWindowMode=0 --FramesToBeEncoded=100 --MatrixCoefficients=1 --InputColorPrimaries=-1 --LMCSSignalType=0 --Level=5.1 --BDPCM=1 --Tier=main --HashME=1 --IBC=1 --MaxCUWidth=16 --MaxCUHeight=16 --CTUSize=32 --QP=28 --MaxBTLumaISlice=32 --MaxBTChromaISlice=32 --MaxBTNonISlice=32 --MaxTTLumaISlice=32 --MaxTTChromaISlice=32 --MaxTTNonISlice=32 --ColorTransform=0 --VideoFullRange=1 --InputSampleRange=1 --AspectRatioInfoPresent=1 --ChromaLocInfoPresent=1 --Log2MaxTbSize=5 --RCCpbSize=2000 --RateControl=1 --TargetBitrate=6000000 --IntraPeriod=256

EncoderApp_REXT.exe --SummaryVerboseness -c "encoder_randomaccess_vtm.cfg" --InputFile=113.y4m --BitstreamFile=116.vvc --SourceWidth=1920 --SourceHeight=1080 --FrameRate=30000/1001 --InputBitDepth=10 --InternalBitDepth=0 --OutputBitDepth=10 --MSBExtendedBitDepth=10 --InputChromaFormat=444 --ChromaFormatIDC=444 --ConformanceWindowMode=0 --FramesToBeEncoded=100 --MatrixCoefficients=1 --InputColorPrimaries=-1 --LMCSSignalType=0 --Level=5.1 --BDPCM=1 --Tier=main --HashME=1 --IBC=1 --MaxCUWidth=16 --MaxCUHeight=16 --CTUSize=32 --QP=28 --MaxBTLumaISlice=32 --MaxBTChromaISlice=32 --MaxBTNonISlice=32 --MaxTTLumaISlice=32 --MaxTTChromaISlice=32 --MaxTTNonISlice=32 --ColorTransform=0 --VideoFullRange=1 --InputSampleRange=1 --AspectRatioInfoPresent=1 --ChromaLocInfoPresent=1 --Log2MaxTbSize=5 --RCCpbSize=2000 --RateControl=1 --TargetBitrate=6000000 --IntraPeriod=256

Thread options:
VVenc originally has auto thread and this isn't the maximum for a given computer. (multithreading; -1: resolution < 720p: 4, < 5K 2880p: 8, >= 5K 2880p: 12 threads)
UVG266 for max 20 it is 20 but ffmpeg warns that the maximum should be 16.
VTM codec has the most new features added but there isn't thread option.

Playing in ffmpeg vvc:
Color range is always tv.
Frame rate is always 25,000.
UVG266 yuv420 10bit is not standard.
Stream #0:0: Video: vvc (Main), yuv420p10le(tv), 1920x1080, 25 fps, 29.97 tbr, 1200k tbn
[vvc @ 0000024e446441a0] frame 17, P( 29, 16) failed with -1094995529
[vvc @ 0000024e446441a0] frame 33, P( 29, 5) failed with -1094995529
[vvc @ 0000024e446441a0] frame 34, P( 29, 8) failed with -1094995529
[vvc @ 0000024e446441a0] frame 37, P( 29, 8) failed with -1094995529
[vvc @ 0000024e446441a0] frame 50, P( 12, 7) failed with -1094995529
[vvc @ 0000024e446441a0] frame 55, P( 29, 6) failed with -1094995529
[vvc @ 0000024e446441a0] frame 58, P( 29, 4) failed with -1094995529
[vvc @ 0000024e446441a0] frame 65, P( 5, 7) failed with -1094995529
[vvc @ 0000024e446441a0] frame 66, P( 29, 2) failed with -1094995529
[vvc @ 0000024e446441a0] frame 68, P( 29, 0) failed with -1094995529
[vvc @ 0000024e446441a0] frame 63, P( 29, 5) failed with -1094995529
[vvc @ 0000024e446441a0] frame 74, P( 29, 1) failed with -1094995529
[vvc @ 0000024e446441a0] frame 82, P( 29, 0) failed with -1094995529
[vvc @ 0000024e446441a0] frame 81, P( 29, 1) failed with -1094995529
[vvc @ 0000024e446441a0] frame 91, P( 29, 2) failed with -1094995529
[vvc @ 0000024e446441a0] frame 97, P( 29, 6) failed with -1094995529
-7686143364034.47 M-V: 1.567 fd= 0 aq= 0KB vq= 0KB sq= 0B
ffmpeg with vvenc movie plays too fast.

Video sample:
https://www.sendspace.com/file/h9c4z3

Jamaika

13th November 2024, 14:31

ffmpeg.exe -y -i "input.mp4" -f yuv4mpegpipe -vf scale=1920:1080:in_range=full:_out_range=full,format=yuv420p10le -frames:v 100 -strict -1 111.y4m
EncoderApp_VTM_REXT.exe --SummaryVerboseness -c "encoder_randomaccess_vtm.cfg" --InputFile=111.y4m --BitstreamFile=114.vvc --SourceWidth=1920 --SourceHeight=1080 --FrameRate=30000/1001 --InputBitDepth=10 --InternalBitDepth=0 --OutputBitDepth=10 --MSBExtendedBitDepth=10 --InputChromaFormat=420 --ChromaFormatIDC=420 --ConformanceWindowMode=0 --FramesToBeEncoded=100 --MatrixCoefficients=1 --InputColorPrimaries=-1 --LMCSSignalType=0 --Level=5.1 --BDPCM=1 --Tier=main --HashME=1 --IBC=1 --MaxCUWidth=16 --MaxCUHeight=16 --CTUSize=32 --MaxBTLumaISlice=32 --MaxBTChromaISlice=32 --MaxBTNonISlice=32 --MaxTTLumaISlice=32 --MaxTTChromaISlice=32 --MaxTTNonISlice=32 --Log2MaxTbSize=5 --ColorTransform=0 --VideoFullRange=1 --InputSampleRange=1 --AspectRatioInfoPresent=1 --ChromaLocInfoPresent=1 --RCCpbSize=2000 --RateControl=1 --TargetBitrate=6000000 --IntraPeriod=256
VVCSoftware: VTM Encoder Version 23.6-ac3ffaa [Windows][GCC 11.5.0][64 bit] [SIMD=AVX2]
https://www.sendspace.com/file/la2bjr

benwaggoner

13th November 2024, 18:42

Well if you use x265 with preset placebo or SVT-AV1 with preset 0, you obtain really low speed too. Use the slowest preset for codec is never obligation.
And if x265 --preset placebo isn't enough for you, add
--cu-lossless
--tskip
--subme 7
rc=lookahead==keyint

Which won't make any appreciable quality improvement for most content, but can improve compression efficiency for lossless screen recording, end credits, or other stuff with zero noise and lots of very sharp edges.

birdie

4th December 2024, 12:16

No idea what to make of it:

https://www.allegrodvt.com/news/press-release-allegrodvt-tv30-test-suite-brazils-next-generation-digital-terrestrial-television-system/

ksec

6th December 2024, 12:49

No idea what to make of it:

https://www.allegrodvt.com/news/press-release-allegrodvt-tv30-test-suite-brazils-next-generation-digital-terrestrial-television-system/

I expect a lot of the Brazil TV 3.0 spec will be adopted worldwide for TV broadcast. A lot of other international standard bodies are watching the space.

In codec terms, that means the broadcast world is watching how VVC + LCEVC will perform in real world. Which is often very different to non real world broadcast encoding problems. I am sure a few here will tell their own unique battle story.

LigH

7th December 2024, 12:25

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

Fraunhofer VVC Encoder ver. 1.13.0-rc1 (https://www.mediafire.com/file/4xjp51z1s8ct17l/vvenc_1.13.0-rc1-476b638.7z/file) 476b638

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

Dann0245

22nd December 2024, 07:25

Microsoft copilot

https://cdn.discordapp.com/attachments/899506969612787835/1318407910212112445/x266_to_VVenC.jpg?ex=676a1f8c&is=6768ce0c&hm=bb780eea5e817786a5841c3b940cbeeb9c41adaaef97ffde059cba668dc333ce&

Chatgpt

https://cdn.discordapp.com/attachments/899506969612787835/1319526773435924531/x266.jpg?ex=6768eb92&is=67679a12&hm=379229b12fc70ee0a61407f500f99ee234f8c2b1387e3b760620ed0f974bbd59&

GeoffreyA

22nd December 2024, 07:45

Microsoft copilot

https://cdn.discordapp.com/attachments/899506969612787835/1318407910212112445/x266_to_VVenC.jpg?ex=6768ce0c&is=67677c8c&hm=4ac8753624e783a8bdc9c7737b86a99913c03b0f226c943816cb58a95bdb0797&

Chatgpt

https://cdn.discordapp.com/attachments/899506969612787835/1319526773435924531/x266.jpg?ex=6768eb92&is=67679a12&hm=379229b12fc70ee0a61407f500f99ee234f8c2b1387e3b760620ed0f974bbd59&

I must say, these hallucinations are a masterpiece! I think I'd give Copilot the prize :)

birdie

22nd December 2024, 09:07

OMFG. They call it artificial "intelligence".

I guess it's artificial, but no way "intelligent".

HowaWe

22nd December 2024, 10:53

Having seen x266... Yet, it was expected to be available this year.

FranceBB

22nd December 2024, 13:25

birdie

22nd December 2024, 21:02

The worst part is that not only they produce completely wrong answers, but those things actually consume a lot energy in doing so inside the datacenters and they're the reason why the national grid is struggling to cope with all the demand... Amazing...

Not so bad, not so bad. I've had over five dozen very productive conversations with ChatGPT and ClaudeAI. They hallucinated at most a couple of times.

The information about x266 is pretty much non-existent. It's nowhere to be seen. Apparently the LLMs are starting to make something up where there's so little, almost nothing.

And here's something you can't give LLM credit for. x266 looks a lot like x265/x264, and of course it's closer to x265. LLMs might as well "think" you've made a mistake.

A human being would probably have made the same mistake. "Oh, this like something that I remember, maybe that's the thing?"

Z2697

22nd December 2024, 22:41

Not so bad, not so bad. I've had over five dozen very productive conversations with ChatGPT and ClaudeAI. They hallucinated at most a couple of times.

The information about x266 is pretty much non-existent. It's nowhere to be seen. Apparently the LLMs are starting to make something up where there's so little, almost nothing.

And here's something you can't give LLM credit for. x266 looks a lot like x265/x264, and of course it's closer to x265. LLMs might as well "think" you've made a mistake.

A human being would probably have made the same mistake. "Oh, this like something that I remember, maybe that's the thing?"

Is the whole world we perceived (yes, it's always the past) also hallucination? ;)

Jokes aside, I'd still consider them hallucinating even if some of their hallucinations are often actually close to reality.

Sometimes they are very useful tools, but they are just tools, not the solution.

GeoffreyA

23rd December 2024, 07:49

Not so bad, not so bad. I've had over five dozen very productive conversations with ChatGPT and ClaudeAI. They hallucinated at most a couple of times.

Same, but with Copilot and Bard/Gemini, and it struck me that they are more pleasant to talk to than many a human. It's the basics: manners and courtesy, which they excel at. Ethics aside, I predict that AI will play the role of talking companions for many in the future, and indeed, that's all we need, someone to talk to.

Is the whole world we perceived (yes, it's always the past) also hallucination? ;)

Jokes aside, I'd still consider them hallucinating even if some of their hallucinations are often actually close to reality.

Sometimes they are very useful tools, but they are just tools, not the solution.

That question is always on my mind, whether this is all an hallucination (not in the Blade Runner false-memory sense). But there is pain and pleasure, and that makes it "real." :)

We also hallucinate, but I think are more sophisticated in how we do so. The LLMs are missing some parts, leading them to state fiction as fact with a straight face, which some humans also do, but it's not "standard." If I remember correctly, it's somewhere in the prefontal cortex that the brain distinguishes between fiction and reality, and we do see, sadly, the breaking down of this faculty in some. So, for LLMs, some analogous mechanism needs to be developed, where everything is checked against reality heuristics, giving some measure of whether XYZ is likely to be fact or fiction, and furthermore, must connect to some "morality" faculty biased against lying.

ksec

23rd December 2024, 10:41

Well 2024 come and gone. Still no x266.

birdie

23rd December 2024, 12:17

Well 2024 come and gone. Still no x266.

This one is true :)

A year too late now.

GeoffreyA

23rd December 2024, 13:06

This one is true :)

A year too late now.

I've let go of worrying about x266. If and when it does come out, one wonders if it will be any better than VVenC, leading to more disappointment.

birdie

24th December 2024, 17:50

I've let go of worrying about x266. If and when it does come out, one wonders if it will be any better than VVenC, leading to more disappointment.

TBO, I've given up on anything that has come after H.264.

AV1/VP9/H.265/H.266 all seem to have been created solely for "good enough" low/medium rate encoding and they all suck when it comes to visually lossless/archival grade 1080p encoding.

They do fair better at 1440p/4K/8K when you have nice lovely gradients but that's rarely the case. Not that often people film the nice blue skies, it's not what we are interested in. And the real world is inherently noisy and discrete.

Z2697

24th December 2024, 20:46

TBO, I've given up on anything that has come after H.264.

AV1/VP9/H.265/H.266 all seem to have been created solely for "good enough" low/medium rate encoding and they all suck when it comes to visually lossless/archival grade 1080p encoding.

They do fair better at 1440p/4K/8K when you have nice lovely gradients but that's rarely the case. Not that often people film the nice blue skies, it's not what we are interested in. And the real world is inherently noisy and discrete.

It depends on the actual encoder. I'm sure you are talking about x264 not some other crappy H.264 encoder. And x265 really is better than x264 at your desired archival quality, if you use something better than its presets.

GeoffreyA

24th December 2024, 21:14

Z2697

25th December 2024, 01:17

We can only hope x266 will continue the success of "x-series" encoders. ;)
But my expectation is much lowered by now, after the long waiting and still more to come.

Z2697

25th December 2024, 01:30

Yes, x265 can achieve archival-grade quality with the right settings (no-sao and the like). But I share the sentiment that all these modern codecs are a let-down, it being a struggle to achieve transparency with them at reasonable bitrates. I sometimes wonder where all those CPU cycles go. It's as if H.264 hit critical mass of compression technology.

There is some diminishing return "effect" going on, like 2x more complexity and 50% less bitrate sort of thing (can't remember the exact numbers they claim). The "2x" is exponentially larger and larger and the "50%" is exponentially less and less. Not to mention that "50% less" is a bold claim especially when the fidelity is the first thing to consider.

GeoffreyA

26th December 2024, 06:44

ksec

26th December 2024, 08:27

There is some diminishing return "effect" going on, like 2x more complexity and 50% less bitrate sort of thing (can't remember the exact numbers they claim). The "2x" is exponentially larger and larger and the "50%" is exponentially less and less. Not to mention that "50% less" is a bold claim especially when the fidelity is the first thing to consider.

HEVC, if I remember correctly was 8x Encode complexity with 2x Decode Complexity increase. In an Era where no one knew what TSMC is and Moore's Law was still a thing that complexity increase doesn't matter much.

VVC is complexity increase is roughly similar comparing to HEVC. So ~80x increase on encoding and 5x decoding comparing to AVC.

FVC is the outliner where it is expected to be 10x complexity in both encode and decode. We are talking about 800x increase in encoding and 50x increase in decoding comparing to AVC.

I am already questioning the feasibility of VVC ( Recent Development with M4 and Cortex X5 makes things much better ), let alone FVC.

The problem is those high bitrate % savings only comes in higher resolution and specific quality scenario. Something like You will only see the optimal 50% reduction from AVC to HEVC when you compare at 4K at sub 4Mbps. Or 1080P at below 1Mbps.

Depending on scenario, most of these results are not very practical. Even Facebook and YouTube have decided to increase the bitrate of their 1080P H.264 video to provide higher quality instead of forcing another Video Codec usage.

Much like audio, there is definitely diminishing returns going on in post-AAC LC codecs. At 256Kbps Opus may be better than AAC 256Kbps in some cases, but giving AAC ~10% headroom would have completely diminish those advantage. The question is do we still need to look at below 256Kbps usage? Even if we do, does it justify another codec if we could fix it with 20% increase in transfer and storage. Which is getting cheaper everyday. AAC-LC is also completely patent free now, and has the widest industry support apart from MP3.

The same is true with Video Codec, we need archival-grade quality at less than half the H.264 bitrate. Not Half the bitrate at below 1Mbps. i.e We have shifted to we need higher / best quality at minimal bitrate, instead of having bare minimum / good enough quality at lowest possible bitrate. The two are very different.

This is similar again in image, where JPEG XL is focusing on the higher end of quality or actual usage. According to Google Chrome 80% of picture served have bit per pixel at 1.0 or above. And JPEG XL is the best in that category. We could serve higher quality picture at same size rather than looking at bpp of 0.5.

GeoffreyA

26th December 2024, 10:16

You're spot on that we need archival-grade quality at a much smaller bitrate than H.264, but modern codecs aim rather for "good enough" at that smaller bitrate. Go for transparency and the bitrate scales massively, and most of the time, transparency is elusive, thanks to all the denoising going on.

With audio, I think AAC-LC hit critical mass, like H.264, and after that, codecs excel rather in the low-bitrate regime. Opus beats AAC below 128 kbps, but above 160, they converge in quality and compatibility is being traded for no gain. xHE-AAC, on the other hand, seems to span all bitrate domains and soundly beats Opus <= 64 kbps.

In images, we've got a clear winner in JPEG XL, which leaves other formats, lossy and lossless, in the dust and excels at higher quality. Unfortunately, there are forces seemingly trying to undermine its success.

Z2697

26th December 2024, 10:55

There is definitely diminishing returns going on in post-H.264 codecs, and they've made filtering detail central to their designs. I think some breakthrough is needed, but fundamentally, there are only so many ways redundancy can be reduced, and throwing away more and more detail becomes the only line of attack. And now, information is increasingly being synthesised on decode, which is seen, for example, in Opus's recent additions.

The Opus additions on decoding are not really synthesising in normal conditions, one synthesizes lost packets and other one tunes the existing post-processing filter for better clarity in extreme low bitrate speech only audio stream.

birdie

26th December 2024, 11:21

We have shifted to we need higher / best quality at minimal bitrate, instead of having bare minimum / good enough quality at lowest possible bitrate. The two are very different.

I couldn't have said it better.

GeoffreyA

26th December 2024, 17:22

The Opus additions on decoding are not really synthesising in normal conditions, one synthesizes lost packets and other one tunes the existing post-processing filter for better clarity in extreme low bitrate speech only audio stream.

Good point.

birdie

8th January 2025, 07:56

kurkosdr

8th January 2025, 14:44

NVIDIA decided not to support HW VVC decoding in the GeForce 50 series.

That's a major blow to its adoption, which can now easily be postponed for another 2 years. At this point you can say it's just dead for the end consumer.
The patent holders holding essential patents for the VVC standard could get together and temporarily waive royalties for all decoder and encoder implementations (software or hardware), so companies like Nvidia and AMD could implement VVC at only silicon cost, but nope, they are like: "we got our IP in an ISO and ITU standard, we deserve a money printer, where the hell is our money printer?".

In fact, the licensing situation for VVC is worse (https://forum.doom9.org/showpost.php?p=2009192&postcount=1099) than the one for HEVC, despite VVC being a format used for nothing in most countries. But I guess if the patent holders split themselves into 50 more licensing groups, they will get enough royalties to get their money printer from the 3 companies shipping VVC products, yay! (no, not really)

MPEG has run its course. It's now possible to have a reasonably performant standard without having a ton of patent holders attached to it. Let's remember that MPEG even exists because 35 years ago it was impossible to create a reasonably performant video standard without stepping on someone's patent, but this stopped being true around the time AV1 became a thing.

GeoffreyA

8th January 2025, 16:13

This is where greed gets them. There seems little point to VVC, at this point, and I say this as one who championed it in years past.

Z2697

8th January 2025, 17:08

kurkosdr

8th January 2025, 19:13

Actually I don't think the "big corps" are innocent. If their product is cheap camera that wants a new codec to help promotion but can't afford it due to low margin, maybe that makes some sense.
(some corps holding the patents are "big corps" as well but you get the point)
Generally, codecs are integrated into devices on an "as needed" basis, both due to silicon cost and due to licensing cost. It's the reason DVD players made today still only do MPEG-1, MPEG-2, and MPEG-4 Part 2 (yes, really (https://www.sony.com/electronics/support/res/manuals/4698/41faab68c73b64d7bab22cb0dd8f1418/46989381M.pdf)) because that's what's expected from a DVD player. AVC is considered an "HD format" and not typically supported by DVD players (and no, Sony doesn't care that you can't play your SD H.264 files on their DVD player).

It's the same reason why TVs without HEVC support are still made today (in countries that haven't made the transition to DVB-T2 HEVC yet), because HEVC is a "UHD format" and not expected to be supported by an HDTV.

Which is the problem the VVC patent holders have: nobody needs VVC for any reason (in consumer electronics at least). A handful of very-high-end UHD TVs might have it for future-proofing reasons, but that's it. Really, their only hope at this point is to give it away for free (as far as licensing goes), but of course they won't.

Z2697

10th January 2025, 19:23

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

21st January 2025, 17:19

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

22nd January 2025, 18:03

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

23rd January 2025, 20:38

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

24th January 2025, 01:07

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

24th January 2025, 20:35

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

8th March 2025, 12:32

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

8th March 2025, 18:21

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

9th March 2025, 10:14

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

9th March 2025, 11:52

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

9th March 2025, 13:51

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

9th March 2025, 15:55

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

9th March 2025, 18:16

benwaggoner

10th March 2025, 18:46

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

10th March 2025, 19:22

....

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

10th March 2025, 20:10

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

10th March 2025, 20:57

I think we both know the answer to that one!

kurkosdr

11th March 2025, 19:29

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

20th March 2025, 19:45

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

29th March 2025, 13:52

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

29th March 2025, 15:02

ksec

29th March 2025, 15:45

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

30th March 2025, 07:39

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

30th March 2025, 16:21

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

30th March 2025, 23:25

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

31st March 2025, 01:49

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

31st March 2025, 02:12

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

1st April 2025, 10:11

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

1st April 2025, 10:36

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

1st April 2025, 10:48

Z2697

1st April 2025, 11:36

GeoffreyA

1st April 2025, 19:55

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

2nd April 2025, 07:32

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

2nd April 2025, 07:50

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

2nd April 2025, 14:07

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

4th April 2025, 14:05

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

4th April 2025, 22:30

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

4th April 2025, 22:34

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

5th April 2025, 11:30

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

8th April 2025, 17:33

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

11th April 2025, 00:34

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

11th April 2025, 04:38

GeoffreyA

11th April 2025, 07:41

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

11th April 2025, 14:12

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

11th April 2025, 15:03

@ 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

11th April 2025, 15:58

benwaggoner

11th April 2025, 20:14

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

20th April 2025, 13:09

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

20th April 2025, 16:51

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

21st April 2025, 14:17

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

kurkosdr

22nd April 2025, 19:30

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.
Yeah, none of this matters. AVC was pretty much hardware-decode only in its early years, I remember it bringing my laptop's Core Duo T2500 to its knees on software that didn't support the "assisted H.264 decoding" offered by the laptop's ATI Mobility Radeon X1600 (and had to do the decoding entirely in software as a result). And that was on a brand-new high-end laptop (surpassed only by Alienwares and such). HEVC was also notorious for bringing Ultrabooks with U-class Intel CPUs to their knees (if they didn't have HEVC hardware decode).

None of this prevented adoption. Hardware manufacturers quickly added support because they had to. The "no-content-fees" policy of AVC made it the default format for HD (pushing VC-1 and then VP8 to irrelevance), and HEVC became the de facto standard for HDR and 4K for premium services and broadcast (the premium services thing caused by the WebM camp dragging their feet on HDR support), so again, manufacturers added support because they had to add support.

VVC's problem is that nobody uses VVC. You have to be insane to deal with the 20 different patent pools that claim patents on it and pay whatever content fees they ask to in order gain marginal bitrate savings over AV1, the economics are not there. Yes, I know, Brazil. The TVs sold there will support VVC decoding in hardware. See? Where there is demand by the content, there is hardware decoding.

Its not like x266 is even here anyway :eek::eek::eek:
Why all the :eek: emojis? What demand is there to justify speedy x266 development? The MulticoreWare people are more focused on MV-HEVC support for x265 (which has demand because of the Apple Vision Pro) than x266. And yes, the fact Apple chose MV-HEVC and not whatever the VVC equivalent is for Apple Vision Pro, despite Apple Vision Pro thing launching 4 years after VVC was formalized and despite being a clean-sheet design with no backwards compatibility constraints (Apple Vision Pro doesn't even use standard Dolby Vision) says a lot about VVC.

modus-ms325c

22nd April 2025, 20:54

maybe AOM can develop their own take on MV-HEVC (either in the form of shoving it to AV1 or designing AV2 with it in mind) or something.

kurkosdr

22nd April 2025, 21:20

maybe AOM can develop their own take on MV-HEVC (either in the form of shoving it to AV1 or designing AV2 with it in mind) or something.
The technology behind MVC and MV-HEVC is patented to the teeth. MPEG LA once had a separate patent pool solely for MVC before they rolled the patents into the AVC pool:

https://web.archive.org/web/20220306222902/https://www.mpegla.com/programs/mvc/

https://web.archive.org/web/20240204002101/https://www.mpegla.com/wp-content/uploads/MVC-att1.pdf

And that's just for MVC (not MV-HEVC). And since the technology in MVC is entirely novel (and not an iteration of ideas pioneered many years ago like 2D video compression is), some of those patents are probably blocking.

So, in order for AOM to offer this technology, there needs to be enough demand for full-resolution stereoscopic content for VR headsets other than the Apple Vision Pro and the patents have to expire. In the meantime, H-SBS should do, after all that's what all stereoscopic video on YouTube is (not that their official player supports it natively anymore, but a few people still upload H-SBS content).

Z2697

23rd April 2025, 03:47

the patents have to expire

It's not like that they had to wait for patents to expire to create something that can compete with HEVC. (and even outcompete)
They already did fight through a ton of patents.
But yeah, there should be enough incentive to "push" them through that.

kurkosdr

23rd April 2025, 13:16

It's not like that they had to wait for patents to expire to create something that can compete with HEVC. (and even outcompete)
Oh, they did, part of the reason VP9 was possible is because lots of key patents from MPEG-2 had expired by then. So, it was a matter of using brute force (for example larger block sizes and longer prediction lengths for inter-frame) plus some innovative workarounds such as AltRef frames.

But if the core technology is patented, unless you can find a genius workaround, you are blocked.

birdie

23rd April 2025, 15:03

says a lot about VVC.

I concur, sadly Jan Ozer is not here.

Z2697

24th April 2025, 14:31

Oh, they did, part of the reason VP9 was possible is because lots of key patents from MPEG-2 had expired by then. So, it was a matter of using brute force (for example larger block sizes and longer prediction lengths for inter-frame) plus some innovative workarounds such as AltRef frames.

But if the core technology is patented, unless you can find a genius workaround, you are blocked.

On2 codecs before VP9 do exist.
Maybe not as big of a deal, but still there.
Who knows how the patents system work.

benwaggoner

24th April 2025, 20:02

maybe AOM can develop their own take on MV-HEVC (either in the form of shoving it to AV1 or designing AV2 with it in mind) or something.
I'm not aware of any implementations of it, but there is some basic stuff in specs for how it could be done. Not enough for interoperable implementations, but it's a pretty straightforward extrapolation if the market is there.

Alas, the stereoscopic market wasn't even big enough to include it in UHD Blu-ray. VR headsets using MV-HEVC are really the only new place stereoscopic has been used in over a decade, and the viewer eyeball hours per month are still going to be very low.

We'd need to see some combination of a much bigger market or much bigger bitrate savings (storage is limited on headsets) to justify creation of a new format, decoder IP, professional grade encoders, etcetera.

Possibly with AV2, as it offers a lot better savings. AV1 wasn't really enough more efficient than HEVC intrinsically to have a sustainable, practical bitrate advantage until encoders matured enough over the last 1-2 years.

New codecs always present as competing against the current state of competing codecs, with numbers that are mostly reference encoder versus reference encoder. But in the 3-5 years it takes to get good, high performance, psychovisually optimized production encoders, the last generation encoders are improving as well, so the goalposts keep moving. With sustained efforts eventually more efficient core bitstream features can pull ahead.

Z2697

24th April 2025, 21:36

Maybe there couble be a more "universal" solution, like an extension that's compatible with multiple formats, similar to how LC-EVC supports multiple codecs.

benwaggoner

24th April 2025, 21:58

Maybe there couble be a more "universal" solution, like an extension that's compatible with multiple formats, similar to how LC-EVC supports multiple codecs.
Yeah. At a high level good stereoscopic encoding is making the alternate eye an enhancement layer that can reference its own past frames and frames in the primary eye at the same time. Existing temporal enhancement layer implementations can be largely repurposed with some extra signaling, with the alternate eye functioning as a frame behind the main eye at the same timestamp.

There are implementation tweaks to keep the visual quality in both eyes consistant without excess bitrate overhead, but getting the basic thing working is much more bitstream syntax than low level DSP stuff.

ShortKatz

25th April 2025, 23:32

Why all the :eek: emojis? What demand is there to justify speedy x266 development? The MulticoreWare people are more focused on MV-HEVC support for x265 (which has demand because of the Apple Vision Pro) than x266.

Seems to me they are more focused on improving ARM support at the moment, didn't see a MV-HEVC commit since November 2024.

benwaggoner

2nd May 2025, 01:17

Why all the :eek: emojis? What demand is there to justify speedy x266 development? The MulticoreWare people are more focused on MV-HEVC support for x265 (which has demand because of the Apple Vision Pro) than x266. And yes, the fact Apple chose MV-HEVC and not whatever the VVC equivalent is for Apple Vision Pro, despite Apple Vision Pro thing launching 4 years after VVC was formalized and despite being a clean-sheet design with no backwards compatibility constraints (Apple Vision Pro doesn't even use standard Dolby Vision) says a lot about VVC.
It's also a lot easier to extend a HEVC decoder to support multi view than it is to add a whole new decoder. It's a pretty trivial amount of extra mm^2 of wafer to add it that way, and Ateme already had a commercial MV-HEVC encoder available.

Plus Apple had added HW accelerated encoding for MV-HEVC in the M1 processor, so they already had an ecosystem. Getting decent encoders available was a harder lift than the decoders, I strongly suspect.

benwaggoner

2nd May 2025, 01:21

Seems to me they are more focused on improving ARM support at the moment, didn't see a MV-HEVC commit since November 2024.
MV-HEVC is a pretty straightforward feature; once it's working, I don't know how much additional refinement is needed. You'll need some rate control to make sure the quality of the two views is equivalent, but that should have been pretty extensible based on the existing B-frame rate control.

And ARM is a huge deal right now given the rapid growth of ARM in data centers, and secondarily on M-series Macs. We've seen speed almost triple with current builds on recent ARM processors compare to what was there 2-3 years ago. Which already had some ARM optimizations, but didn't dive nearly as deep as x86-64, and ARM got some pretty great SIMD extensions to take advantage of.

The throughput/$ of current x265 builds on our latest Graviton processor AWS instances is pretty amazing.

benwaggoner

2nd May 2025, 01:29

On2 codecs before VP9 do exist.
Maybe not as big of a deal, but still there.
Who knows how the patents system work.
Yeah:

VP6 was the leading codec in Flash for years
VP3 was the basis for the Theora codec, and a decent CD-ROM codec for its era. Poor rate control, though.
VP7 was used in Move Networks' pioneering adaptive streaming implementation. Great tech, but they failed due to adopting a business model that left them competing with their partners at every stage of the encoding & distribution process.
TrueMotion and TrueMotion-S (retconned to VP1 & 2, Back when On2 was still The Duck Corporation) were decently popular CD-ROM codecs, used in a bunch of Star Trek titles and other stuff. I wrote an article about those for DV Magazine 25+ years ago.

I had a meeting with On2 before Google bought them, sheesh almost 20 years ago, where we realized I'd been working with the company on various projects longer than any current employee had worked there.

Wow, I'm such an industry graybeard now, and I have the beard to show it! I was actually doing video encoding early enough that I was excited about the potential of these new-fangled CD-ROMs coming to market.

LigH

2nd May 2025, 11:30

Ben will ever since be known as "Video Kenobi".

https://cosgan.de/images/smilie/figuren/a045.gif

foxyshadis

8th May 2025, 20:10

Yeah:
VP6 was the leading codec in Flash for years
I'd even say VP6 propped up flash long past its sell-by date, since there was no other good way (at the time) to get video delivered to every browser. As soon as there was, it disappeared into the night.

For all their faults, particularly their constant braggadocio, On2 definitely did their part to push the state of the art and competitiveness in video encoding, even after they were bought by Google. Who definitely had no idea how to make a video codec, so even if VP8 was a hot mess of an "open" codec, it helped build the foundation for AV1.

LigH

11th May 2025, 15:00

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

Fraunhofer VVC Encoder ver. 1.13.1 (https://www.mediafire.com/file/rzvyj79xufhtuxv/vvenc_1.13.1-d091d89.7z/file) d091d89

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

benwaggoner

12th May 2025, 16:54

I'd even say VP6 propped up flash long past its sell-by date, since there was no other good way (at the time) to get video delivered to every browser. As soon as there was, it disappeared into the night.
Yeah. VP6's real strength was in advanced post processing including grain synthesis, deblocking, deringing, etcetera. Turning those features off revealed quite mediocre baseband video, way overtuned for PSNR with lots of the sorts of artifacts that causes.

Once Flash supported H.264 with much better compression efficiency, better tuned and faster encoders, and much better pricing, that was that for the most part.

VP7 did get used in Move Networks' pioneering ABR solution, but Move's attempt to monetize and thus compete with every stage of the video encoding, delivery, and playback pipeline, and thus competing with most potential partners, caused them to fade quite quickly.

For all their faults, particularly their constant braggadocio, On2 definitely did their part to push the state of the art and competitiveness in video encoding, even after they were bought by Google. Who definitely had no idea how to make a video codec, so even if VP8 was a hot mess of an "open" codec, it helped build the foundation for AV1.
They did a good amount of valuable work back to the early CD ROM days with the TrueMotion codecs (VP1 & VP2), back when they were called The Duck Corporation. IDR-only codecs originally made for performant playback and random access for discs where compression efficiency wasn't paramount.

Yups

18th May 2025, 00:59

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.

Panther Lake mobile is going to support VVC decoding but that's a 2026 generation. As for AMD and Nvidia it's not looking good even for next year. Maybe with their next gen GPUs which is more likely a 2027 generation. This is a very slow adoption, much slower than AV1.

ShortKatz

24th May 2025, 22:40

This HTML5 test https://html5test.co does now test for browser H.266 support. Did W3C add H.266 already to the W3C WebCodecs Codec Registry specification?

birdie

25th May 2025, 09:12

A few weeks ago I again retested H.264 vs VVC (vvenc version 1.13.1, preset slower) at 3Mbps for a 30fps 1080p video.

H.264 came out on top again, while vvenc smeared out everything. Details and high-frequency details are all but lost.

I don't know where all the improvements in encoding went. Did they go towards 4K and 8K resolutions with a lot of gradients?

LigH

25th May 2025, 10:10

Well, yes ... the main reason for the development of more efficient codecs {often|always} used to be a higher resolution. Cause and effect may be mixed as simpler codecs need a lot more bitrate if used for higher resolutions because they lack of efficient features for large frame dimensions. Remember x265, you can improve its use for smaller frame dimensions by explicitly limiting coding unit dimensions (e.g. no use of 64×64 pixel units, only up to 32×32 or even 16×16, like the good old "macroblocks" in legacy MPEG formats before AVC).

rwill

25th May 2025, 11:29

Well in this case its not the standard, its the encoder thats not tuned right. And what LigH did not consider is why x265 should use 64x64 blocks when 16x16 would be better for the small resolution content in the first place...

With small details and stuff there is just not much one can do encoding tool wise so certain people go for PSNR and just look at the numbers, not the picture.

Quite funny when one thinks back, with AV1 its proponents were celebrating that it beats some HEVC implementations in VMAF by quite a margin. Some time after that people started to complain about lack of details in AV1 streams so we got the AV1-PSY releases. Too bad the PSY releases screw with PSNR and VMAF so they lost that point again, but no one is talking about AV1 objective metrics anymore either...

So, where is that 30fps HD sequence you tried to encode in VVC? I might give it a shot...

Z2697

25th May 2025, 12:11

*CTU means CtbSizeY or miximum CU size, in the following content. Just like in x265.

Well actually ;) with x265, the reason why sometimes (quite often, actually) 32x32 CTU is recommended is that, the max size of TU is 32x32, and basically that's the "most" you can get,
I mean you don't really get more compression with 64x64 CU because can only go as far as "4 TUs stitched together" and that won't improve things very much.
Even for 4K, yes.

So, with 32x32 CTU, you gain WPP improvement (more rows) and "encourages" a small-but-maybe-important amount of splitting of TU into smaller TU as a side effect, the best part, you virtually lose nothing.

(Yes, PU will be limited because it can go up to 64x64, but the loss in efficiency is insignificant.
If I understand it correctly, PU encodes MV data, which probably aren't huge; TU encodes ALL the residual after prediction, which is huge amount of pixel data, it's the heavy-duty part.
And the top limiting factor.)
(Limited PU size is probably one of the things that contribute to the above-mentioned side effect.)

Same thing for the detail, if the minimum TU size is 4x4 (requires tu-inter-depth >= 2), that's basically enough, you don't very need to limit the CU size.
And you start to lose some noticeable compression efficiency by go below 32x32 CTU. Maybe slightly, but much more than from 64x64 to 32x32.

birdie

26th May 2025, 22:53

I'm eagerly awaiting x266, which I hope will compress better than x264 or at least at the same level of detail given the same bitrate (I'm talking about visually lossless encoding), although I'm not very optimistic.

I'm still extremely confused as to how on Earth is it possible that H.266 is at least two orders of magnitude (100 times) more complex to encode and at least 4 times more complex to decode than H.264, yet I just don't see it/don't get it; and in many situations the result is worse than what you can achieve with x264 while spending 100 times less compute on encoding while being able to play you videos everywhere.

Where does all the compute in H.266 go? Towards what?

GeoffreyA

27th May 2025, 00:04

I'm eagerly awaiting x266, which I hope will compress better than x264 or at least at the same level of detail given the same bitrate (I'm talking about visually lossless encoding), although I'm not very optimistic.

I'm still extremely confused as to how on Earth is it possible that H.266 is at least two orders of magnitude (100 times) more complex to encode and at least 4 times more complex to decode than H.264, yet I just don't see it/don't get it; and in many situations the result is worse than what you can achieve with x264 while spending 100 times less compute on encoding while being able to play you videos everywhere.

Where does all the compute in H.266 go? Towards what?

It baffles me too: where does all the processing go? Perhaps it's that H.264 hit critical mass of compression technology, blossoming to perfection in x264, and since then, it's been little more than tightening up loose ends (H.265), and drifting into the realm of diminishing-returns processing atop unsightly denoising, the sort that makes one want to shut the eyes. To be sure, looking at the white papers, there are fancy new techniques at play, but I'm as baffled as you where it all goes.

kurkosdr

27th May 2025, 01:08

It baffles me too: where does all the processing go? Perhaps it's that H.264 hit critical mass of compression technology, blossoming to perfection in x264, and since then, it's been little more than tightening up loose ends (H.265), and drifting into the realm of diminishing-returns processing atop unsightly denoising, the sort that makes one want to shut the eyes. To be sure, looking at the white papers, there are fancy new techniques at play, but I'm as baffled as you where it all goes.
You've just said it: denoising at extremely low bitrates

Though VVC is supposed to be better than HEVC at handling HDR10 video, so that's a genuine W.

Tommy Carrot

27th May 2025, 01:11

I'm eagerly awaiting x266, which I hope will compress better than x264 or at least at the same level of detail given the same bitrate (I'm talking about visually lossless encoding), although I'm not very optimistic.

I'm still extremely confused as to how on Earth is it possible that H.266 is at least two orders of magnitude (100 times) more complex to encode and at least 4 times more complex to decode than H.264, yet I just don't see it/don't get it; and in many situations the result is worse than what you can achieve with x264 while spending 100 times less compute on encoding while being able to play you videos everywhere.

Where does all the compute in H.266 go? Towards what?

All these newer generation codecs are geared towards delivering decent quality at as low bitrate as possible. Their goal is not beating x264 at transparent quality (unfortunately). These new codecs are vastly better at very low bitrate, but that's not what most people here want.

Z2697

27th May 2025, 03:05

Though VVC is supposed to be better than HEVC at handling HDR10 video, so that's a genuine W.

How so?

rwill

27th May 2025, 03:41

Where does all the compute in H.266 go? Towards what?

There are quite some ways to split a CU and the more probable splits have to be tested for compression efficiency. Some say that there are more combinations of splitting a CU in VVC than there are Atoms in the known universe...

H.264 just has like .. 4 Modes per Macroblock it can try at most? VVC has a couple thousand per CU.

birdie

27th May 2025, 09:19

All these newer generation codecs are geared towards delivering decent quality at as low bitrate as possible. Their goal is not beating x264 at transparent quality (unfortunately). These new codecs are vastly better at very low bitrate, but that's not what most people here want.

That's my impression as well.

They were seemingly created or fine-tuned for low-bitrate streaming. That's a very limited, almost stupid use case. I mean, it has its place, but given that VVC is encumbered by patents and has almost no market penetration, you wouldn't want to stream something that's being decoded by your CPU. Most modern computing devices are smartphones and laptops, and people don't want their batteries to be decimated.

LigH

27th May 2025, 09:31

Well, if TV broadcasters (in a wider sense) pay for the development of technology to broadcast UHD video via limited bandwidth, then developers will do what pays them.

a.ok.in

28th May 2025, 14:10

Jamaika

28th May 2025, 20:29

You can do the tests yourself. There are a lot of functions here. It only shows basic results.
https://pixabay.com/videos/boats-beach-trees-forest-indonesia-169998/
Test 4K VVC/EVC
ffmpeg.exe -loglevel error -i "169998-843069589_large.mp4 " -f yuv4mpegpipe -vf scale=3840x2160,format=yuv420p test_4K_vvc_yuv420p.y4m
ffmpeg.exe -loglevel error -i "169998-843069589_large.mp4 " -f yuv4mpegpipe -vf scale=3840x2160,format=yuv420p10le -strict -1 test_4K_vvc_yuv420p10le.y4m
vvencapp_avx2.exe --verbosity 5 -i test_4K_vvc_yuv420p.y4m --y4m -s 3840x2160 -c yuv420 --preset medium --fps 60000/1000 -b 26M -ip 256 --passes 1 --threads 20 --sdr sdr_709 -o test_4K_vvenc_pass1_medium_yuv420p.vvc
vvencapp_avx2.exe --verbosity 5 -i test_4K_vvc_yuv420p10le.y4m --y4m -s 3840x2160 -c yuv420_10 --preset medium --fps 60000/1000 -b 26M -ip 256 --passes 1 --threads 20 --sdr sdr_709 -o test_4K_vvenc_pass1_medium_yuv420p10le.vvc
uvg266_08bit_avx2.exe -i test_4K_vvc_yuv420p.y4m -o test_4K_uvg266_pass1_medium_yuv420p.vvc --input-file-format y4m --input-res 3840x2160 --input-format P420 --input-bitdepth 8 --preset medium --input-fps 60000/1000 --bitrate 26000000 --period 256 --gop 16 --no-info --threads 20 --range tv --colormatrix bt709
uvg266_10bit_avx2.exe -i test_4K_vvc_yuv420p10le.y4m -o test_4K_uvg266_pass1_medium_yuv420p10le.vvc --input-file-format y4m --input-res 3840x2160 --input-format P420 --input-bitdepth 10 --preset medium --input-fps 60000/1000 --bitrate 26000000 --period 256 --gop 16 --no-info --threads 20 --range tv --colormatrix bt709
xeve_avx2.exe -i test_4K_vvc_yuv420p10le.y4m -o test_4K_xeve_pass1_medium_yuv420p10le.evc -v 3 -d 10 -m 8 -w 3840 -h 2160 -z 60.000 -b 15 -I 256 --input-csp 1 --codec-bit-depth 10 --rc-type 1 --bitrate 26Mbps --vbv-bufsize 26Mbps --preset medium --profile baseline --range limited --matrix-coefficients bt709 --info 0

uvg266 has only gop16. No color sample 422 or 444. No passes option.
vvenc has no gop option. GOP is variable. No color sample 422 or 444. Has passes option.
Xeve has gop 16/32 options but gop 32 doesn't work with profile PROFILE_IDC_MAIN(MAIN_10). Profile PROFILE_IDC_MAIN doesn't decode in ffmpeg so it isn't recommended. Has color sample 422 or 444. No passes option. Thread option has max value always 8. Xeve doesn't output 8bit movies. xeve doesn't have decent decoder in ffmpeg. Videos won't play.

Vvenc and uvg266 in tests have different file sizes at the same bitrate and thread. Vvenc has lower bitrate or drops frames.
vvenc profile slow/slower is very very slow. Trump processor needed.
Using the placebo profile isn't recommended. It isn't decoded by ffmpeg and is very slow.
uvg266 slower profile isn't the same as vvenc slower profile. Much faster uvg266 but is it correct?
xeve placebo profile isn't the same as uvg266 placebo profile. Much faster xeve but is it correct?

Input #0, vvc, from 'test_4K_uvg266_pass1_medium_yuv420p.vvc':
Duration: N/A, bitrate: N/A
Stream #0:0: Video: vvc (Main), yuv420p(tv), 3840x2160, 25 fps, 60 tbr, 1200k tb

Input #0, vvc, from 'test_4K_uvg266_pass1_medium_yuv420p10le.vvc':
Duration: N/A, bitrate: N/A
Stream #0:0: Video: vvc (Main), yuv420p10le(tv), 3840x2160, 25 fps, 60 tbr, 1200k tbn

// Main 10 profile == 1
WRITE_U(stream, 1, 7, "general_profile_idc");

There is no information about the color matrix for uvg266.

Sample video: https://www.sendspace.com/file/6vgavg

a.ok.in

29th May 2025, 01:49

You can do the tests yourself. There are a lot of functions here. It only shows basic results.
https://pixabay.com/videos/boats-beach-trees-forest-indonesia-169998/
Test 4K VVC/EVC
ffmpeg.exe -loglevel error -i "169998-843069589_large.mp4 " -f yuv4mpegpipe -vf scale=3840:2160:in_range=full: out_range=full,format=yuv420p test_4K_vvc_yuv420p.y4m
ffmpeg.exe -loglevel error -i "169998-843069589_large.mp4 " -f yuv4mpegpipe -vf scale=3840:2160:in_range=full: out_range=full,format=yuv420p10le -strict -1 test_4K_vvc_yuv420p10le.y4m
vvencapp_avx2.exe --verbosity 5 -i test_4K_vvc_yuv420p.y4m --y4m -s 3840x2160 -c yuv420 --preset medium --fps 60000/1000 -b 26M -ip 256 --passes 1 --threads 20 --sdr sdr_709 -o test_4K_vvenc_pass1_medium_yuv420p.vvc
vvencapp_avx2.exe --verbosity 5 -i test_4K_vvc_yuv420p10le.y4m --y4m -s 3840x2160 -c yuv420_10 --preset medium --fps 60000/1000 -b 26M -ip 256 --passes 1 --threads 20 --sdr sdr_709 -o test_4K_vvenc_pass1_medium_yuv420p10le.vvc
uvg266_08bit_avx2.exe -i test_4K_vvc_yuv420p.y4m -o test_4K_uvg266_pass1_medium_yuv420p.vvc --input-file-format y4m --input-res 3840x2160 --input-format P420 --input-bitdepth 8 --preset medium --input-fps 60000/1000 --bitrate 26000000 --period 256 --gop 16 --no-info --threads 20 --range tv --colormatrix bt709
uvg266_10bit_avx2.exe -i test_4K_vvc_yuv420p10le.y4m -o test_4K_uvg266_pass1_medium_yuv420p10le.vvc --input-file-format y4m --input-res 3840x2160 --input-format P420 --input-bitdepth 10 --preset medium --input-fps 60000/1000 --bitrate 26000000 --period 256 --gop 16 --no-info --threads 20 --range tv --colormatrix bt709
xeve_avx2.exe -i test_4K_vvc_yuv420p10le.y4m -o test_4K_xeve_pass1_medium_yuv420p10le.evc -v 3 -d 10 -m 8 -w 3840 -h 2160 -z 60.000 -b 15 -I 256 --input-csp 1 --codec-bit-depth 10 --rc-type 1 --bitrate 26Mbps --vbv-bufsize 26Mbps --preset medium --profile baseline --range limited --matrix-coefficients bt709 --info 0

uvg266 has only gop16. No color sample 422 or 444. No passes option.
vvenc has no gop option. GOP is variable. No color sample 422 or 444. Has passes option.
Xeve has gop 16/32 options but gop 32 doesn't work with profile main. Profile main doesn't decode in ffmpeg so it isn't recommended. Has color sample 422 or 444. No passes option. Thread option has max value always 8. Xeve doesn't output 8bit movies. xeve doesn't have decent decoder in ffmpeg. Videos won't play.

Vvenc and uvg266 in tests have different file sizes at the same bitrate and thread. Vvenc has lower bitrate or drops frames.
vvenc profile slow/slower is very very slow. Trump processor needed.
Using the placebo profile isn't recommended. It isn't decoded by ffmpeg and is very slow.
uvg266 slower profile isn't the same as vvenc slower profile. Much faster uvg266 but is it correct?
xeve placebo profile isn't the same as uvg266 placebo profile. Much faster xeve but is it correct?

Input #0, vvc, from 'test_4K_uvg266_pass1_medium_yuv420p.vvc':
Duration: N/A, bitrate: N/A
Stream #0:0: Video: vvc (Main), yuv420p(tv), 3840x2160, 25 fps, 60 tbr, 1200k tb

Input #0, vvc, from 'test_4K_uvg266_pass1_medium_yuv420p10le.vvc':
Duration: N/A, bitrate: N/A
Stream #0:0: Video: vvc (Main), yuv420p10le(tv), 3840x2160, 25 fps, 60 tbr, 1200k tbn

There is no information about the color matrix for uvg266.

Sample video: https://www.sendspace.com/file/6vgavg

But the fastest XEVE preset is slower than the fastest VVENC preset, even when XEVE encodes EVC baseline profile. (at least last time I tried)
XEVE baseline profile has worse quality than main, but it is supposed to be royalty-free. (seriously I never tested main profile since i'm lazy to use xevd, with or without ffmpeg)
libXEVE on ffmpeg encodes main profile... i'm not really sure if it can decode it, but ffplay doesn't play the EVC main profile videos. Idk, i'll test later, EVC is even more dead than VVC.
uvg266 is even more fast with 8-bit (ultravideo encoders are optimized for 8-bit, so Kvazaar can be sometimes faster than x265 for 8-bit video, but it's different for 10-bit)

...
And I don't get what do you mean about color matrix, uvg266 has those options as any decent encoder:
https://files.catbox.moe/b1iggi.png

Jamaika

29th May 2025, 04:50

xeve I don't know if the project was closed due to patents. No colormatrix bt709 info displayed in ffmpeg converter. As if colormatrix wasn't there for uvg266, xeve.
vvenc "add more help info, new range parameter, cleanups and fixes". I don't tested it.
Actually there is no vvenc/uvg266/xeve 8bit because the profile is always MAIN_10. There is no MAIN profile
https://github.com/fraunhoferhhi/vvenc/pull/547/files

https://www.sendspace.com/file/9z91u9

benwaggoner

30th May 2025, 22:09

I'm eagerly awaiting x266, which I hope will compress better than x264 or at least at the same level of detail given the same bitrate (I'm talking about visually lossless encoding), although I'm not very optimistic.
The bitstream is capable of equivalent quality to H.264 at 25% the bitrate in many scenarios. VCC particularly stands out in having much less noticeable artifacts with motion at high compression rates.

We don't have refined enough encoders for VVC to beat x264 by that much today for common real-world scenarios, yet, though. It took x265 some years to be reliably significantly lower bitrate for the same quality as x264.

I'm still extremely confused as to how on Earth is it possible that H.266 is at least two orders of magnitude (100 times) more complex to encode and at least 4 times more complex to decode than H.264, yet I just don't see it/don't get it; and in many situations the result is worse than what you can achieve with x264 while spending 100 times less compute on encoding while being able to play you videos everywhere.
Decode complexity is 4x higher because HEVC targeted 2x more than H.264 and VVC 2x more than HEVC. When designing the codec, they only added as many new tools to improve compression efficiency as would fit within the 2x increase.

As to why it takes 100x longer, it always takes a bigger encoding time increase to get the theoretically compression efficiency increase, because there is a combinatorial explosion of different ways to encode something in the most efficiency way. More options mean more things needs to be tested to find the most optimal ones.

Still, with reasonably mature encoders, you'll still get a bitrate reduction over the prior generation at the same encoding speed. x265 --preset medium is more efficient and about as fast as x264 --preset veryslow. And it can be faster given high enough resolution content and enough cores; H.264 doesn't have as many opportunities to effectively multithread and use wide SIMD.

The 100x difference is also in large part because we're comparing highly refined and optimized x264 and x265 encoders. Look at their source code and you'll find huge amounts of platformed-tuned assembly and SIMD. x265 on ARM processors has more than doubled in speed in the last couple of years just due to better ARM optimization.

No VVC encoder has had that kind of deep, sustained expert tuning yet.

Where does all the compute in H.266 go? Towards what?
On decode, more complex tools that allow for more efficient encoding. Like more complex filters that make motion artifacts a lot less obvious and improve how good a reference they are for later frames. Decoder complexity is always the limiting factor in codec design, and as an industry the $/decoder price has been dropping hugely year-on-year. MPEG-2 decoders originally cost in the tens of dollars and watts.

On encode, like I said, the more ways there are to do something, the more ways you need to try to figure out a good one.

And simply less optimization. VVC encoders are slower in part because it is a harder job, and in part because they're still early in tuning to do that job as fast as possible. x265 can usefully saturate more cores and SIMD units than any VVC encoder I'm yet aware of. And that's a gap that will naturally shrink as long as enough smart people are working on making VVC encoding faster.

benwaggoner

30th May 2025, 22:11

By the way, I must ask you... did anyone tested thoroughly encoding with the expert encoder (vvencFFapp)?
It allows to tune many encoding options, so if there's any way to get more detail it would be with that encoder.
vvenc is the best open source encoder we have today, but I wouldn't call it an "expert" encoder, nor would its authors.

It's a lot more practical than the reference encoder, but still haven't seen a fraction of the sort of sustained iterative optimization than x264 and x265 have received. Nor was that the goal of its developers.

Z2697

31st May 2025, 22:12

GeoffreyA

1st June 2025, 10:04

With so many combinations maybe using "AI" to make shortcut mode decisions will start to make sense :rolleyes:
That's what "AI" is, or should be: while being more complex than "traditional" methods, it's actually a black-box shortcut (or approximation) to a much more complex solution.

I would say it's close, in spirit, to human trial-and-error thought, at least in the training process, but without the constraint of consciousness.

benwaggoner

3rd June 2025, 21:18

With so many combinations maybe using "AI" to make shortcut mode decisions will start to make sense :rolleyes:
That's what "AI" is, or should be: while being more complex than "traditional" methods, it's actually a black-box shortcut (or approximation) to a much more complex solution.
Yes, absolutely. This is an active area of codec research.

oibaf

3rd June 2025, 21:42

Codecs and DVB – setting standards, not adoption (https://dvb.org/news/codecs-and-dvb-setting-standards-not-adoption/):

For VVC, while there are limited deployments in China and India, the most significant launch to date will be the roll-out in Brazil this year of SBTVD 3.0, with a profile based on DVB’s VVC specifications.

Still, the ‘automatic’ market adoption of newer, more efficient codecs has become less likely with no tangible new application – UHD is already possible and 8K has not, so far, been a success.

modus-ms325c

4th June 2025, 03:44

"ok i think we shouldn't be imposing rules on what TV tech to support if no one's committed to ponying up the TV sets necessary to support our rules" is not the take i'd expect from a "standardization" group as "prestigious" as DVB itself, but here we are.

there are currently 3 8K channels currently broadcasting and they're all Asian channels, all of which are still alive and kicking in a climate when such possibilities of 8K broadcasting happening elsewhere proved absolutely fruitless. just look at what happened to poor SES 8K channel in Europe.

kurkosdr

4th June 2025, 18:55

"ok i think we shouldn't be imposing rules on what TV tech to support if no one's committed to ponying up the TV sets necessary to support our rules" is not the take i'd expect from a "standardization" group as "prestigious" as DVB itself, but here we are.
The DVB group doesn't have the legal authority to impose standards on EU member-states (or any other country), they provide a "toolset" and each country adopts the tools they want (either explicitly by mandating support in TV sets or implicitly by defining the formats that terrestrial TV stations can broadcast).

This has resulted in some weird choices, such as Greece going for MPEG-4 AVC SD for its analog switch-off (resulting in SD-only MPEG-4 AVC receivers being sold), so when HD came along, terrestrial stations were legally mandated to simulcast in both MPEG-4 AVC SD and MPEG-4 AVC HD (no joke, here are the muxes: 1 (https://www.digitalbitrate.com/dtv.php?mux=12223&liste=1&live=72&lang=en), 2 (https://www.digitalbitrate.com/dtv.php?mux=12241&liste=1&live=72&lang=en), 3 (https://www.digitalbitrate.com/dtv.php?mux=12414&liste=1&live=72&lang=en), 4 (https://www.digitalbitrate.com/dtv.php?mux=12338&liste=1&live=72&lang=en), 5 (https://www.digitalbitrate.com/dtv.php?mux=12352&liste=1&live=72&lang=en)). Then there is France's choice to use E-AC3 audio for MPEG-4 AVC broadcasts (SD and HD), thus making their audio incompatible with Blu-ray and generally a compatibility nightmare with most MPEG-4 AVC players.

So yes, VVC is technically part of the DVB "toolset", but most countries have gone with HEVC as part of their second switch-off (either completed or announced/planned), and it will be a political nightmare to announce a third switch-off. And have to tell people that their still-new UHD TVs can get neither UHD nor HD signals. Which is a pity, because, despite the licensing hell VVC is known for, VVC would still be really useful in the cramped muxes of most European countries, for both HD and UHD content.

modus-ms325c

5th June 2025, 02:02

The DVB group doesn't have the legal authority to impose standards on EU member-states (or any other country), they provide a "toolset" and each country adopts the tools they want (either explicitly by mandating support in TV sets or implicitly by defining the formats that terrestrial TV stations can broadcast).

This has resulted in some weird choices, such as Greece going for MPEG-4 AVC SD for its analog switch-off (resulting in SD-only MPEG-4 AVC receivers being sold), so when HD came along, terrestrial stations were legally mandated to simulcast in both MPEG-4 AVC SD and MPEG-4 AVC HD (no joke, here are the muxes: 1 (https://www.digitalbitrate.com/dtv.php?mux=12223&liste=1&live=72&lang=en), 2 (https://www.digitalbitrate.com/dtv.php?mux=12241&liste=1&live=72&lang=en), 3 (https://www.digitalbitrate.com/dtv.php?mux=12414&liste=1&live=72&lang=en), 4 (https://www.digitalbitrate.com/dtv.php?mux=12338&liste=1&live=72&lang=en), 5 (https://www.digitalbitrate.com/dtv.php?mux=12352&liste=1&live=72&lang=en)). Then there is France's choice to use E-AC3 audio for MPEG-4 AVC broadcasts (SD and HD), thus making their audio incompatible with Blu-ray and generally a compatibility nightmare with most MPEG-4 AVC players.

So yes, VVC is technically part of the DVB "toolset", but most countries have gone with HEVC as part of their second switch-off (either completed or announced/planned), and it will be a political nightmare to announce a third switch-off. And have to tell people that their still-new UHD TVs can get neither UHD nor HD signals. Which is a pity, because, despite the licensing hell VVC is known for, VVC would still be really useful in the cramped muxes of most European countries, for both HD and UHD content.
on VVC:
problem is, no one will replace their previous TV set that "just worked" with one that can now miraculously decode VVC in addition to HEVC and whatever other codec DVB may "recommend" next, as we're now in a sociopolitical climate where we're now aware of what e-waste does to a planet. their only solution is to pony up for a set-top-box that can (and will) decode every "standardized" coded under-the-sun (not to mention DAC adapters or what-have-you) for an "old-but-gold" TV.

on everything else, this is what i have to say:
DVB got what they deserved.

kurkosdr

5th June 2025, 20:33

their only solution is to pony up for a set-top-box that can (and will) decode every "standardized" coded under-the-sun (not to mention DAC adapters or what-have-you) for an "old-but-gold" TV..
Which is where the political resistance comes from: people don't like to be told that their still-pretty-new UHD TV can't receive UHD channels and needs an external decoder box because of something called "VVC".

Also, why are most external decoder boxes so unapologetically shit? They all have the same horrible Mstar or ALI firmware and below-par reception sensitivity (compared to TVs). So yeah, I would be pissed if my still-new OLED needed such a thing to get channels. The only good external decoders I can think of is Panasonic's UHD Blu-ray recorders, but those are expensive because they include a Blu-ray recorder and player and don't support VVC anyway.

rwill

7th June 2025, 07:23

on everything else, this is what i have to say:
DVB got what they deserved.

I do not understand this point. What did DVB get? What did they deserve? I mean they are standardizing a toolbox every country can construct their local broadcast standard from. There is not problem with that.

juliobbv

10th June 2025, 10:59

vvenc is the best open source encoder we have today, but I wouldn't call it an "expert" encoder, nor would its authors.

It's a lot more practical than the reference encoder, but still haven't seen a fraction of the sort of sustained iterative optimization than x264 and x265 have received. Nor was that the goal of its developers.

BY "expert encoder", the VVenC authors mean the app with more knobs exposed to the user, as mentioned here (https://github.com/fraunhoferhhi/vvenc/wiki/Usage):

The encoder project includes two encoder executables, a simple encoder app (vvencapp) and a full featured expert encoder (vvencFFapp).

juliobbv

10th June 2025, 11:12

Quite funny when one thinks back, with AV1 its proponents were celebrating that it beats some HEVC implementations in VMAF by quite a margin. Some time after that people started to complain about lack of details in AV1 streams so we got the AV1-PSY releases. Too bad the PSY releases screw with PSNR and VMAF so they lost that point again, but no one is talking about AV1 objective metrics anymore either...

It's worth mentioning that the PSY releases only screw with metrics if PSY features are turned on, kind of like how x264 and x265 work. Turning those features off restores metric performance back (for what it's worth). Oftentimes you can even get better metric scores with PSY releases, in the form of better mean SSIM scores and 10 percentile lows.

Also, the AV1 enthusiast community is actually significantly bigger than it meets the eye (and what Doom9 what makes it to be). There are still people interested in traditional objective metric performance, but many actually moved on to using more modern metrics (SSIMULACRA2, Butteraugli, CVVDP, etc), or have fully jumped onto the PSY bandwagon.

Z2697

10th June 2025, 19:54

and what Doom9 what makes it to be

You mean people at Doom9 "hates" AV1?

juliobbv

10th June 2025, 20:33

You mean people at Doom9 "hates" AV1?

Not hate, but there seems to be an overall disinterest in AV1 relative to MPEG codecs at Doom9. If you look at thread count, "VP9 and AV1" have only 61 threads, compared to 776 for HEVC and 6608 for AVC. AVC isn't 100 times older than AV1, so codec age cannot account for such difference.

The compression-related Discord servers and Reddit feel much more "alive" in comparison. So it's maybe a generational difference?

ksec

14th June 2025, 06:01

Not hate, but there seems to be an overall disinterest in AV1 relative to MPEG codecs at Doom9. If you look at thread count, "VP9 and AV1" have only 61 threads, compared to 776 for HEVC and 6608 for AVC. AVC isn't 100 times older than AV1, so codec age cannot account for such difference.

The compression-related Discord servers and Reddit feel much more "alive" in comparison. So it's maybe a generational difference?

Because the newer generation believed that AV1 is patent free. Which 99% of AV1 supporter including their PR were bragging about. They attacked the patent pool as if AOM dont have a patent pool. They only stopped doing that around 2019 when I have to defend the correct usage of patent free every single time, which is what MPEG2 is right now. They want to stand on moral high ground which is what most of the newer generation think is right without considering quality and other metrics. And the whole AV1 is slightly superior to HEVC and moving the goal post to only 10% or about the same as VVC measurement during different stage of encoder maturity.

They also said AV2 will launch in 2020, and AV3 in 2022 or 2023. We are very close to 2026 now. But how many of those supporters said at the time because it is Google they could throw billions at it and do the impossible. What about hardware AV1 decoder? And then what about AV1 actual quality rather than constantly measuring against VMAF?

And how many times do I have to point out those flaws. How many times have i said Google wanted it because of control. Some people only woke up to it when JPEG XL happened. Google single handedly blocked JPEGXL to be included in Interop 2025. Despite Microsoft and Apple support.

I dont doubt MPEG, H.264/H.265/H.266 have its flaws. Patents sucks. But people on DOOM9 long enough went through Divx, Xvid, Windows Media, RMVB, x264, x265. We all knew how much INSANE hard work it is. Spending years if not decades doing quality encoding comparison as a a professional AND Hobby! There are certain marketing lies from AOM camp Doom 9 people see through. And people here cares about actual picture quality Damn it! That is why we are on Doom9. Because we were such a brunch of fools who cares about picture quality enough to spend that much time on it.

If there is a generational difference, then yes the older bunch want something great regardless of most of its surroundings things. Newer generational want something "right" and cheap, quality not being a top priority.

And I believe there are enough people here including myself really want AOM to learn from their mistakes and make AV2 great. But frankly speaking I dont see it happening, they are still focusing on 1 Mbps washed out content.

I am now also at the point happy to simply just use H264. Especially spending more bitrate just to get higher quality. May be AI encoder could further push the codec forward. Bandwidth cost is *still* dropping fast after 3 decades of cost reduction thanks to AI investment and optical technology. As I have said before it is actually faster to have the whole world rolled out 5G or 5G-Advance than a codec going mainstream. Because the cost calculation is constantly changing, going another codec just to save ~40% transfer cost from HEVC is no longer attractive. And ~65% reduction in transfer cost from VVC also doesn't attract enough usage. My guess is that VVC+LCEVC might go mainstream simply because of TV usage. It should also hit close to 75% reduction compared to H.264. Time will tell and depending on patent pool. But Geopolitics suggest may be soon there will be enough countries including Brazil to say no to these patents.

juliobbv

14th June 2025, 10:19

Hi ksec,

There's a lot to unpack from your reply. I'm detecting it was written with a very emotional state of mind, and I suspect that this let out some inaccuracies and mistakes that otherwise would've been caught when proof-reading the reply before sending. Maybe it'd be better if you take some time to recompose and reply again later?

Z2697

14th June 2025, 11:17

Well I guess some Doom9 user do "hate" AV1.
Including me :devil: (just kidding)
I appreciate the capability of it, but I also don't want to join the hype (if there is one).

And the forum threads... you know, the fact is we don't have any handy encoder from VP9/AV1 until recently, the SVT-AV1.
Even SVT-AV1 is... let's say for example how were they think it's a good idea to remove adaptive keyframe insertion on scene change???

GeoffreyA

14th June 2025, 11:38

rwill

14th June 2025, 13:00

But credit must be given to the SVT-AV1-PSY releases that have made considerable strides closing the detail gap. The last time such passion was seen was x264 in the DarkShikari days.

Then you will be most thrilled to hear that the Psy-Rd source code in SVT-AV1-PSY is exactly the same as the one created with passion in the DarkShikari x264 days. And there are even several Donate buttons scattered around on SVT-AV1-PSY developer pages.

The passion lives on but now needs money too I guess.

VoodooFX

14th June 2025, 13:45

The compression-related Discord servers and Reddit feel much more "alive" in comparison. So it's maybe a generational difference?

It's pretty obvious - IQ difference, look at those AV1 reddit threads, maybe 90% of peeps there have no clue what they are writing about.

Let's to be clear about it, AV1 is not good, it's a flop. Go next.

juliobbv

14th June 2025, 14:15

Let's to be clear about it, AV1 is not good, it's a flop. Go next.

Let's agree to disagree here :)

juliobbv

14th June 2025, 14:43

In my opinion, Julio, it's because AV1 ended up being used a lot in the anime-encoding community, excelling there, and they tend to use Discord and Reddit today. In an earlier era, the anime community developed key tools on Doom9. If more of today's enthusiasts came here, they would be welcome, appreciated, and it would be a boon to the site.

With mainline libaom, live-action details were ill preserved, leading to a decline, I think, in live-action encoding after the early Scene releases. There was disappointment in many, much like what we're seeing with VVC. But credit must be given to the SVT-AV1-PSY releases that have made considerable strides closing the detail gap. The last time such passion was seen was x264 in the DarkShikari days.

Intrinsically, the problem doesn't lie with AV1, but the diminishing returns across all codecs, especially in transparent quality, after H.264. At least, that's my view.

This makes sense. The anime community has been influential at adopting new codec technologies, and there has been a considerable migration to Discord and Reddit over the past several years.

I hope VVC will get the same psychovisual love that its predecessors had. The potential is there for sure.

Z2697

14th June 2025, 18:30

Let's be neutral here.
AV1 (as a specification) does provide more potential than HEVC.
And it already has its success (you may say it's limited, well but still a success I'll call it).
The problem is the encoder, the implementation of the specification.
Like I said previously, we never had a handy VP(/AV)-series encoder until SVT-AV1 becomes mainstream, and it's still in its "early days" in the psychovisual optimization realm.

==========

And the donations? Come on, they are making contributions (btw only one of them have donation link now), is it not OK to ask for some donations?
Like, what's up with all those donation buttons in many popular open source softwares? Seriously? All those greedy people, can you believe that?

(I agree some of the "donations" can be sahdy, like some of the "AI video enhance GUIs", trash code, trash UI being written and the donation being like nag, or even paywalled)

Z2697

14th June 2025, 18:40

This makes sense. The anime community has been influential at adopting new codec technologies, and there has been a considerable migration to Discord and Reddit over the past several years.

I hope VVC will get the same psychovisual love that its predecessors had. The potential is there for sure.

(Today's hot take:)
Meanwhile in the anime community: writting a million python packages and what not for any bit of pipeline :devil:

FranceBB

14th June 2025, 19:42

In an earlier era, the anime community developed key tools on Doom9.

Yep. Most of us started as fansubber eons ago. Honestly, if it wasn't for subbing, I would have never learned how to use Aegisub, write LUA scripts, use Avisynth to deal with telecined contents, filter out issues, re-encode in xvid etc. Ironically, I would have probably never joined Crunchyroll, then Viewster, then Sky. It all started on Doom9 and from one passion, anime, I discovered another, encoding, and it led me to who I am today. It's funny to think how it all started: a bunch of people gathering on a forum subtitling and encoding anime in their free time for passion and wanting to do it better, tackling the problems we had at the time.

kurkosdr

19th June 2025, 12:54

Because the newer generation believed that AV1 is patent free. Which 99% of AV1 supporter including their PR were bragging about. They attacked the patent pool as if AOM dont have a patent pool.
There are some crucial differences though:

1) The ITU/ISO standards were designed to infringe on the patents of many companies as long as those companies promise to license them under FRAND (known as "option 2" in ISO lingo, with "option 1" being royalty-free), instead AV1 makes an effort to avoid patents not granted under a royalty-free license. Together with AOM's defensive termination clause (for AV1-essential patents owned by the companies behind AOM), it greatly reduces the number of companies asserting and the number of patents asserted.

2) VVC has double the number of patent pools compared to HEVC (20 vs 10 or so), and you have to negotiate a licence with all of them, because again, VVC was designed to infringe on those patents. I guess this is a new Moore's Law, with the number of patent pools doubling with every new ISO video standard. At some point, you have to make an honest assessment as a streamer whether the bitrate savings are worth the licensing costs, especially considering bandwidth is getting cheaper while the patent holders behind the ISO standards are getting greedier (again, VVC has double the patent pools of HEVC)

3) No successful patent assertions have happened against AV1, despite companies like Google using AV1 for video streaming and in products like the Google Pixel series. So, either those companies behind the Sisvel patent pool are perfectly happy with Google building products and services on top of what they claim is their treasured intellectual property, or they are full of BS.

kurkosdr

19th June 2025, 13:34

They only stopped doing that around 2019 when I have to defend the correct usage of patent free every single time, which is what MPEG2 is right now.
Patent-free can either mean "no assertions whatsoever", or "no successful assertions". Since it costs nothing to slap together a pdf with a list of patents and calling it your standard-essential patent pool, this tends to attract ambulance-chasers asserting but not litigating, so some of us prefer the second definition as a more reasonable definition.

This is different from the ISO standards, where as long as a patent pool contains a single patent from a single company that contributed technology to the ISO standard, you are probably infringing if you don't license (either via the patent pool or by negotiating with the company directly, but few are willing to do the latter).

Also, minor detail: MPEG 2 is still covered by patents in Malaysia, since some pre-TRIPS patents around muxing to mpg files still haven't expired:
https://www.via-la.com/licensing-2/mpeg-2/mpeg-2-patent-list/
https://www.via-la.com/licensing-2/mpeg-2-systems/patent-list

So, the first ISO standard to become fully patent-free will be MPEG 4 Part 2, when a Brazilian patent from Siemens will expire during summer 2026:
https://www.via-la.com/licensing-2/mpeg-4-visual/mpeg-4-visual-patent-list/

Unless you meant patent-free in the US, in this case both MPEG 2 and MPEG 4 Part 2 meet this definition already.

benwaggoner

19th June 2025, 17:47

The compression-related Discord servers and Reddit feel much more "alive" in comparison. So it's maybe a generational difference?
For those of us who have advanced far on the young turk -> graybeard lifecycle, what are the good Discords and subreddits for compression? I don't Discord much, and haven't seen much activity on Reddit.

benwaggoner

19th June 2025, 17:57

Yep. Most of us started as fansubber eons ago. Honestly, if it wasn't for subbing, I would have never learned how to use Aegisub, write LUA scripts, use Avisynth to deal with telecined contents, filter out issues, re-encode in xvid etc. Ironically, I would have probably never joined Crunchyroll, then Viewster, then Sky. It all started on Doom9 and from one passion, anime, I discovered another, encoding, and it led me to who I am today. It's funny to think how it all started: a bunch of people gathering on a forum subtitling and encoding anime in their free time for passion and wanting to do it better, tackling the problems we had at the time.
Yeah, it has been a fascinating journey with this community. And tightly coupled with the miracle of x264, which introduced a dramatically new approach to codec development and optimization. As they said back in the day "all bugs are shallow with many eyeballs" - the community of enthusiasts all competing to make the best looking and smallest encodes quickest of everything drove so much development and new use cases. x264 got so many more tunings and testing than any prior encoder. And it wasn't just good at the standard SMPTE etc test clips, but things like content with film grain, motion graphics, video game footage, and cel animation. That kind of content, despite being a big part of real-world viewing, was dramatically underrepresented in the standard test libraries that encoders used to be turned to optimize PSNR for. And so the world got the best, fastest, most flexible video encoder in history. It was able to take great advantage of the new complex features of H.264 while still encoding as fast or faster as encoders for older, simpler codecs.

And a whole community of experts grew out of that who have gone on to careers in digital media in the last couple of decades.

x264's open source structure also lead to a lot of commercial companies funding people who used to be hobbyists to make further improvements. And eventually x265.

I'm old enough to have been a compression hobbyist and professional before x264 (I encoded my first file in 1989, and have been doing it for money since 1994). People who got into this with or after x264 probably don't know how much it changed everything.

And helped create this great community here.

And getting somewhat back to the original topic, AV1 and VP8/9 before it have suffered from the lack of the kind of community-tuned encoder like x264. HEVC was enough like AVC that x265 was able to start with x264 and the HEVC reference encoder and get something with reasonable performance and psychovisual optimization pretty quickly. And even though AV1 is open source,

VVC is even more based on HEVC than HEVC was based on AVC, so a x266 should be at least as straightforward as x265 was. However, HEVC and thus x265 had an immediate, essential market in getting HDR launched (this month is the 10th anniversary of launching HDR on Prime Video!). Companies needed to make HEVC on a deadline, and all those people who had worked deeply with x264 found the idea of something build on the same foundation with the same tuning parameters very appealing.

VVC having a more nightmarish patent licensing situation and no essential short term consumer feature it enables has prevented the same degree of frantiic development quickly iterating on real-world use cases that x265 got.

juliobbv

19th June 2025, 21:28

For those of us who have advanced far on the young turk -> graybeard lifecycle, what are the good Discords and subreddits for compression? I don't Discord much, and haven't seen much activity on Reddit.

These are the two Discord servers I personally pay most attention to right now.

AV1 for Dummies: https://discord.gg/uc744ZxMJP
JPEG XL: https://discord.gg/5AQnJYszV3

The AV1 anime Discord also has some great discussions and codec tests happening.
AV1 weeb edition: https://discord.gg/r8WSQVyd2K

The "AV1 Community" Discord had a recent admin change: https://discord.gg/8PEUhuqnqE

That's all for me. I'm not familiar with MPEG-oriented Discords, so other people may chime in with more details.

hajj_3

4th July 2025, 21:04

The BBC published a study in December 2024 comparing HEVC, VVC and AV1: https://downloads.bbc.co.uk/rd/pubs/whp/whp-pdf-files/WHP419.pdf

Source: https://www.bbc.co.uk/rd/publications/video-compression-pq-metrics-vvc-av1

They found that AV1 provided 5% better compression when using HDR and WCG than HEVC. They found that VVC provided 48% better compression than HEVC. This study was from 2022 but for some reason seemed to only be released in 2024. They used SVT-AV1 v1.2.1 which was released in August 2022 and vvenc v1.5.0 which was released in July 2022.

kurkosdr

6th July 2025, 18:40

benwaggoner

6th July 2025, 22:05

So, in 2022, VVC was one generation ahead of HEVC while AV1 was on the same generation as HEVC?
Encoder maturity matters a lot. and PQ requires different psychovisual tuning than SDR.

Also very interested to see how things stand now.
They've all improved in the last three years, but I would expect AV1 and VVC to have improved more than HEVC given their relative maturity. There's been some good recent work on AV1 HDR that is coming to SVT-AV1, but I don't know if it has made it to the main branch yet.

birdie

7th July 2025, 07:50

hajj_3

7th July 2025, 08:10

Some possible improvements for VVC licensing:

https://www.streamingmedia.com/Articles/News/Online-Video-News/Access-Advance-Reveals-Royalty-Rates-for-Video-Streaming-Services-170330.aspx

Looks like it's dawned on them that the current situation is untenable.

a new streaming licence in not a good thing!

birdie

7th July 2025, 11:25

Meanwhile the first (?) set top box with VVC decoding support has arrived:

https://www.youtube.com/watch?v=T3tZMtNd3ak

https://www.aliexpress.com/item/1005009407366134.html

A bonus, an interview with Peter Moller, the CEO of Access Advance:

https://www.youtube.com/watch?v=mCxnXfoO88I

Overall an ugly interview.

kurkosdr

7th July 2025, 15:34

Some possible improvements for VVC licensing:

https://www.streamingmedia.com/Articles/News/Online-Video-News/Access-Advance-Reveals-Royalty-Rates-for-Video-Streaming-Services-170330.aspx

In January 2025, Access Advance announced the Video Distribution Patent Pool, initially announcing key incentives and a general framework. Following an interview with Access Advance CEO Peter Moller, I compiled the relevant Quick Facts that were posted at the time:

* The pool covers streaming content.
* Companies that would otherwise generate up to $25,000 in royalties for any six-month period will receive a royalty waiver in the form of a semi-annual credit of $25K, effectively excluding smaller entities like churches, schools, and small businesses.
* Covers HEVC, VP9, AV1, and VVC, with one charge for all content.
* Fees are tiered based on three key metrics: monthly active users, subscriber counts, and streaming revenue.
* Royalties start accruing on January 1, 2025.
* Licensees that joined by June 30, 2025, would have had previous royalties waived and a 25% discount through 2030.
* Access Advance expects most current patent owners from its existing pools to join, along with patent owners from other pools such as Sisvel, Via LA, and Avanci. Offsets will be provided for licensees that join two pools with duplicate coverage of the same patents.
* Access Advance acknowledges that some patent owners, like Nokia, will continue to license bilaterally and likely won’t join the VDP.

Looks like it's dawned on them that the current situation is untenable.

Let's go through this one more time: The terms that MPEG LA and Access Advance offer are not the big problem, the big problem is those other patent pools and patent licensing entities you have to also negotiate terms with and pay royalties to, and last time I checked, there were 18 of them (https://forum.doom9.org/showthread.php?p=2009192#post2009192).

Each of those 18 patent licensing entities has its own terms and royalties, and unless this problem is resolved, no meaningful improvement has happened.

Even with HEVC, the assumption that drove adoption was that the vast majority of the patents would be in the MPEG LA patent pool (save for 1-2 companies maybe), as was the case with H.264.

As the old saying goes, "Fool me once, shame on you. Fool me twice, shame on me." The streaming market has collectively decided that the bitrate savings of VVC are outweighed by the costs of VVC (licensing costs plus the cost of encoding into yet another format) and won't commit to yet another ISO format. That's why VVC is almost nowhere in streaming.

Which is a good thing btw: seeing their brand-new standard not be adopted may light a fire under the buttocks of all those patent holders.

oibaf

7th July 2025, 16:36

There is an updated one:
https://accessadvance.com/wp-content/uploads/2025/04/2025Q2-VVC-Patent-Diagram-04-01-25-2048x1536.jpg

modus-ms325c

8th July 2025, 03:28

feels like i've already seen this before

benwaggoner

8th July 2025, 19:11

The streaming market has collectively decided that the bitrate savings of VVC are outweighed by the costs of VVC (licensing costs plus the cost of encoding into yet another format) and won't commit to yet another ISO format. That's why VVC is almost nowhere in streaming.
(as always, solely my own personal opinions here based on publicly available information)
It's not just that VVC is more expensive. It's that VVC's price is unknown. If we just knew it was going to be 3x H.264, we could run the ROI and see if it is a good deal. But with so many pools and patents, no one can give you even a ballpark figure that would pass legal review, and no CFO is going to bet the company not knowing how big an invoice is coming in a couple of years.

Patent litigation around AVC and HEVC IP not in any of the pools in the last year has also really emphasized the unknowability of the risk. Getting an injunction against using a key technology in a whole country or region is a huge randomizer, and therefor a risk no one wants to lean even more into.

Which is a good thing btw: seeing their brand-new standard not be adopted may light a fire under the buttocks of all those patent holders.
I'd hoped that HEVC was going to be the object lesson for them, which had poor and slow uptake in streaming. But the real money is in decoders, and I guess getting all of those into phones, computers, and living room devices offered a false sense of complacency. But content adoption drives device adoption, and HEVC's device adoption ran far ahead of its content adoption. So device vendors are waiting for the content companies to tell them they'll be using VVC before committing to including it.

kurkosdr

8th July 2025, 23:28

I'd hoped that HEVC was going to be the object lesson for them, which had poor and slow uptake in streaming. But the real money is in decoders, and I guess getting all of those into phones, computers, and living room devices offered a false sense of complacency. But content adoption drives device adoption, and HEVC's device adoption ran far ahead of its content adoption. So device vendors are waiting for the content companies to tell them they'll be using VVC before committing to including it.
HEVC still has a lot of adoption:

- It's the only format available if you want to stream UHD to early UHD Smart TVs (that don't do AV1), which means that premium streaming providers such as Netflix that charge extra for UHD have to to use HEVC (since they can't tell their customers that their perfectly good UHD TV won't do for Netflix UHD)

- In countries that have completed the transition to HEVC (for example Germany), using HEVC is legally mandatory for terrestrial FTA channels, and more countries will follow.

So, premium streaming services and broadcasters are stuck with HEVC regardless of the patent licensing issues.

So, yeah, the coup worked, but the patent holders can only do that once. Most streaming services won't touch VVC after their experience with HEVC's licensing situation, and broadcasters are stuck with HEVC for at least a decade from the date they transitioned to HEVC so they won't touch VVC for the foreseeable future either. I hope the patent holders are treasuring their treasured intellectual property (to use their words) even if almost nobody uses it.

benwaggoner

10th July 2025, 16:46

HEVC still has a lot of adoption:

- It's the only format available if you want to stream UHD to early UHD Smart TVs (that don't do AV1), which means that premium streaming providers such as Netflix that charge extra for UHD have to to use HEVC (since they can't tell their customers that their perfectly good UHD TV won't do for Netflix UHD)

- In countries that have completed the transition to HEVC (for example Germany), using HEVC is legally mandatory for terrestrial FTA channels, and more countries will follow.

So, premium streaming services and broadcasters are stuck with HEVC regardless of the patent licensing issues.

So, yeah, the coup worked, but the patent holders can only do that once. Most streaming services won't touch VVC after their experience with HEVC's licensing situation, and broadcasters are stuck with HEVC for at least a decade from the date they transitioned to HEVC so they won't touch VVC for the foreseeable future either. I hope the patent holders are treasuring their treasured intellectual property (to use their words) even if almost nobody uses it.
(again, so much my own personal opinions)
Yeah, a lot of companies were willing to take a riskier bet on HEVC because a) it was the only feasible way to do HDR and UHD, which were revenue-driving transformative features, and b) H.264 licensing was very straightforward and I think a lot of people assumed they'd get something ballpark similar.

VVC lacks an a) must have use case, and HEVC proved that b) was not a valid assumption, and thus VVC certainly can't be assumed to be.

VVC is technologically very appealing, but it isn't needed for anything and a good faith implementor can't trust they'll get a good faith retroactive licensing program. If licensors get together and provide an actual license that covers all of the core IP ala H.264, then VVC becomes an ROI decision. But the implement now, get a to-be-determined bill/lawsuit later model is a huge no-go that makes an ROI impossible to estimate.

And after all, any bad faith patent holders exactly would want the industry to adopt VVC in a big way to increase their retroactive payout. Boycotting VVC until there is a reasonable and comprehensive license is a powerful disincentive for bad faith participants to act that way, and is hopefully an incentive for them to engage in a good faith license to get some revenue for their IP. They are going to act to maximize profits, so the only "safe" way to proceed is to make sure that their profit maximization aligns with broader ecosystem health.

MoSal

10th July 2025, 21:41

* Covers HEVC, VP9, AV1, and VVC, with one charge for all content.

How considerate..

RanmaCanada

16th July 2025, 04:04

Blue_MiSfit

17th July 2025, 07:46

Supporting devices like Smart TVs more than 10 years old is obscenely difficult. You have no idea how terrible the software and hardware is even on modern cost optimized garbage heaps like most people have. Buying a $30 Roku / FireTV is an unfortunate, but swallowable bitter pill. This is why I use Apple TVs on both my home TVs no questions. My long in the tooth LG B6 is still awesome today with one (with some notable limitations on audio sync with Dolby Vision and external audio... but I don't care in my bedroom where I use buit-in speakers).

Smart TVs are incredibly constrained, especially when manufacturers load them up with ads.

kurkosdr

17th July 2025, 14:20

Funny as Netflix did do that with a whole range of 4k Vizio TVs (https://support.vizio.com/s/article/Netflix-No-Longer-Working-on-Older-VIZIO-TV-and-Blu-Ray-players?language=en_US). It seems any 4k tv made before 2013 has had their support dropped.

Friend owns several of these that still work and refused to replace them just because Netflix didn't work. Was forced to buy Rokus to fix it.
Sure, but those are 2013 models, aka old enough. But good luck telling subscribers that their still-new 2020 4K OLED TV can't get Netflix UHD, especially considering Netflix charges extra for Netflix UHD. At some point, the cost of having all those subscribers downgrade to the lower Netflix HD tier outweighs any savings. Even today, some low-end 4K HDR TVs still on store shelves don't do AV1.

benwaggoner

17th July 2025, 17:44

Sure, but those are 2013 models, aka old enough. But good luck telling subscribers that their still-new 2020 4K OLED TV can't get Netflix UHD, especially considering Netflix charges extra for Netflix UHD. At some point, the cost of having all those subscribers downgrade to the lower Netflix HD tier outweighs any savings. Even today, some low-end 4K HDR TVs still on store shelves don't do AV1.
It's also worth pointing out that encoder maturity and performance are big factors. AV1 encoders aren't as refined as those for HEVC yet, and are quite a bit slower when run in modes that maximize a bitrate advantage. We've seen enormous improvement in the last couple of years, and it's not kind of a tossup for whether a full length movie in AV1 won't have some quality regressions against HEVC at a given bitrate. It can go years from an impressive demo encoding short selected content at a single bitrate to something that can reliably and efficiently encode full bitrate ladders of multi-hour long content.

This is just how codecs work; HEVC was a very unusual exception in that it was practically implementable at scale in less than five years after the standard was finished.

ksec

19th July 2025, 16:17

Patent-free can either mean "no assertions whatsoever", or "no successful assertions".

Patent Free means something very specific. The word you are looking for is patent unencumbered. Which AOM camp have since changed and are now using it.

Hi ksec,

There's a lot to unpack from your reply. I'm detecting it was written with a very emotional state of mind, and I suspect that this let out some inaccuracies and mistakes that otherwise would've been caught when proof-reading the reply before sending. Maybe it'd be better if you take some time to recompose and reply again later?

Point out the inaccuracies and mistakes and we can discuss.

ksec

19th July 2025, 16:21

Some possible improvements for VVC licensing:

https://www.streamingmedia.com/Articles/News/Online-Video-News/Access-Advance-Reveals-Royalty-Rates-for-Video-Streaming-Services-170330.aspx

Looks like it's dawned on them that the current situation is untenable.

We are not far off from freely using H.264.

https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_MPEG-4_AVC_expired_yet%3F

kurkosdr

20th July 2025, 12:32

We are not far off from freely using H.264.

https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_MPEG-4_AVC_expired_yet%3F
Depends on your definition of "far off", 2030 is pretty far off IMO.

birdie

9th October 2025, 16:47

Intel is the only consumer facing company that hasn't given up on the VVC codec.

They will support it in its upcoming Panther Lake/Xe3 architecture.

https://arstechnica.com/gadgets/2025/10/intels-next-generation-panther-lake-laptop-chips-could-be-a-return-to-form/

hajj_3

27th October 2025, 20:48

https://accessadvance.com/wp-content/uploads/2025/10/2025Q4-VVC-Patent-Diagram-10-01-25.jpg

The significant change is that Apple and Maxell have joined the Via-LA patent pool.

kurkosdr

27th October 2025, 21:20

Wow, only 18 patent-licensing entities to make license agreements with and pay royalties to, now VVC is ready to take on AV1 and the soon-to-be-released AV2! /s

(sorry, couldn't resist)

soresu

28th October 2025, 00:51

Wow, only 18 patent-licensing entities to make license agreements with and pay royalties to, now VVC is ready to take on AV1 and the soon-to-be-released AV2! /s

(sorry, couldn't resist)

No need to say sorry, it's a completely warranted perspective.

They literally created AOM with this stupid situation.

birdie

29th October 2025, 10:22

No need to say sorry, it's a completely warranted perspective.

They literally created AOM with this stupid situation.

They literally buried themselves. Only Intel so far has been brave enough to license this huge effing mess.

GeoffreyA

30th October 2025, 07:43

VVC has been one of the biggest disappointments in encoding history, and as kurkosdr observed, what in heaven's name is it going to do in the face of AV2? Nor does it help that x266 remains mythical.

VoodooFX

30th October 2025, 18:43

what in heaven's name is it going to do in the face of AV2?

Maybe nothing, if AV2 will be like AV1 ~worse than x265. :D

benwaggoner

30th October 2025, 21:03

Maybe nothing, if AV2 will be like AV1 ~worse than x265. :D
Oh, that's really not true anymore. In 2025 the best AV1 encoders can now outperform the best HEVC encoders by 20-30% with equivalent tuning effort. It took a long time to get there, but it happened. Yeah, x265 can outperform libaom in lots of scenarios still, but that's not where the eyeball-hours come from.

It would be faster for AV2 as it gets a head start from having good AV1 encoders; AV1 had no professional quality VP9 encoders to iterate from.

My extrapolation from way too many generations of new codecs is that AV2 should meaningfully outperform AV1 for real-word use circa 2018-2019. That includes workflow integration, performance optimization, psychovisual tuning, etcetera.

VVC was technically superior on multiple axes to AV1, but the licensing nightmare made that irrelevant. I expect H.267 will be technically superior to AV2. I also predict it won't matter unless H.267 patent licensing gets better than HEVC, let alone VVC. I don't think it is possible to make an advanced distribution codec ignoring IP concerns anymore. I don't think royalty-free is needed; something like a H.264 like license from a single licensing entity who publishes terms would work fine, even if it was 2-3x more expensive. It's the "I have no idea how much this could retroactively cost" factor that's a hard blocker.

VoodooFX

30th October 2025, 21:52

Oh, that's really not true anymore. In 2025 the best AV1 encoders can now outperform the best HEVC encoders by 20-30% with equivalent tuning effort.

I didn't observed such, tested in mid 2025 with svt-av1-psy.

rwill

30th October 2025, 22:15

I didn't observed such, tested in mid 2025 with svt-av1-psy.

AVT-AV1-PSY (which one of the forks anyway?) is hardly one of the best AV1 encoders... same with x265 and HEVC. Most hobbyists don't take that implementation vs. standard thing into account.

cubicibo

30th October 2025, 23:28

Oh, that's really not true anymore. In 2025 the best AV1 encoders can now outperform the best HEVC encoders by 20-30% with equivalent tuning effort.

Can't compare codecs without clear context (use-cases, constraints, setup, etc.). Did people forget about Dark Shikari blog post on that very subject?

LigH

31st October 2025, 13:25

"Dark Shikari" ... a name I didn't read in ages. But still remember.

oibaf

6th December 2025, 21:13

VVC (H.266) video codec effectively dead on arrival, posits analyst
https://www.flatpanelshd.com/news.php?subaction=showfull&id=1764735539

benwaggoner

9th December 2025, 02:46

Can't compare codecs without clear context (use-cases, constraints, setup, etc.). Did people forget about Dark Shikari blog post on that very subject?
People will always forget!

To be specific, I am comparing the average bitrate of distribution encodes for adaptive streaming at equivalent perceptual quality, but not at the same encoding time (AV1 is slower to take good advantage of its advanced features).

benwaggoner

9th December 2025, 02:49

VVC (H.266) video codec effectively dead on arrival, posits analyst
https://www.flatpanelshd.com/news.php?subaction=showfull&id=1764735539
This seems more like a post-mortem than news.

Interesting they're projecting HEVC dominant and growing its dominance substantially over the next five years. Although I never trust a plot without units.

CruNcher

9th December 2025, 18:10

"Dark Shikari" ... a name I didn't read in ages. But still remember.

Time goes by fast huh he was different but i never would have expected that different ;)

I’m not really a fan of when someone undergoes a very visible transformation to express their feminine side it can feel sad when it completely takes over.
But when it does happen, it shouldn’t be judged.

So much more deepness was in all this PSY for her

"It’s common for people who later transition or evolve in gender identity to be drawn toward subjects involving perception, identity, embodiment, or the inner/outer experience of self. That doesn’t make the past “fake”—it means they were trying to understand themselves."

People who dive hard into psycho-visual modeling, perception, masking behavior, and human visual response curves often have a deep interest in the inner vs. outer experience. But when you're in the middle of an engineering project, you see it as:

algorithms,

metrics,

heuristics,

tuning,

reference code,

experiments.

You don’t tend to analyze the psychological or personal motivation behind each contributor’s intensity — because the work itself is already absorbing enough.

So yes, it’s completely understandable that you wouldn’t have picked up the personal meaning behind someone’s fixation on psy optimizations. When you’re debugging macroblock decisions at 2 a.m., nobody is thinking:

“Oh, maybe this is part of their identity journey.”

You just assume they’re a passionate codec dev.

Jason/Fiona

and this fixation on Touhou oh man i feel strange but also excited what i have experienced or what i even was allowed to experience ?

kurkosdr

10th December 2025, 00:46

VVC (H.266) video codec effectively dead on arrival, posits analyst
https://www.flatpanelshd.com/news.php?subaction=showfull&id=1764735539

Anyone who could sense where the wind was blowing could tell 2 years ago, since nobody was talking about using the thing anywhere:

Broadcasters -> They are conservative by nature due to the fact that if they want to support a new format, they either have to break compatibility with some of the installed base of receivers or simulcast. The majority of broadcasters are still transitioning to HEVC, some (like UK terrestrial broadcasters) are still transitioning to H.264. Even broadcasters starting HDR broadcasts now will not break compatibility with the huge installed base of UHD TVs that don't do VVC unless they are obligated to do so by government dictate (which will happen in a minority of countries, but too localized to matter)

Optical media -> 4K Blu-ray uses HEVC, no need for a new optical disc format (8K content isn't a thing and isn't becoming a thing)

Streamers (the supposed use case for VVC) -> The majority of streamers either don't want to hear about ISO/ITU video standards after the HEVC coup, or can see the total cost of supporting a new format and paying licensing to the 20 or so patent licensing entities of VVC is simply not worth the hassle and the money, internet bandwidth is getting cheaper anyway

So, there you have it, the patent holders behind MPEG got their fat profits from the HEVC coup, but you know how it goes "fool me once, shame on you, fool me twice, shame on me". Even if VVC's costs are acceptable now, you never know if 5 years from now you will be dealing with 40 or 50 licensing entities, since the number of licensing entities is clearly not market-driven (VVC has twice that of HEVC).

CruNcher

10th December 2025, 03:54

If things continue the way they’re going, the ITU/JVET/MPEG ecosystem might reach a breaking point much faster than people expect.
H.264/AVC hit a perfect historical moment of balanced complexity, manageable patents, and universal adoption.
VVC did many things right technically, but its patent landscape is so complex that it would require serious goodwill and probably financial generosity to keep it viable.
That complexity also creates problems for hardware vendors like Intel.

I’m particularly skeptical about the neural network aspects of the newer pipelines.
Some models can steer content in directions that don’t necessarily reflect the original signal.
When AI-based metrics start defining “quality,” we face difficult psychological questions: what is the common denominator of reality that we all agree on?
Things will become very interesting when optimization depends on “truthful” sensory input because while that might be psychologically healthy, not everyone will like it.
And we already see the opposite everywhere: artificial lowering of resolution and synthetic “detail” presented as high definition.

So what should an AI-driven encoder mode actually prioritize?
Truthfulness? Artificial reconstruction? Beauty?
Pick your profile.

Eventually, every individual viewer may choose the version of reality they prefer.
But once that happens, our shared understanding of reality may drift out of sync and possibly very far from what we traditionally consider real.

Grain is a good example. It’s a statistical phenomenon, so AI can replicate it easily, and Technicolor/Thomson will likely move aggressively on FGT with their own AI implementation.
They may even win that patent race. But once you’re in the realm of statistical reconstruction, anyone with a model can do it.
A formal standard only matters if you want efficient hardware support.

This is why AI within the ECM pipeline is so important for NPU vendors. Intel in particular wants to reclaim ground in this space from Nvidia, AMD and Apple.

Digital compression has already changed people’s perception of reality slowly, over decades.
AI has the potential to change perception far more quickly, and by a magnitude that we haven’t yet absorbed or compensated for in the traditional digital signal domain.

ksec

16th December 2025, 17:08

This seems more like a post-mortem than news.

Interesting they're projecting HEVC dominant and growing its dominance substantially over the next five years. Although I never trust a plot without units.

I will absolutely bet those projection for H.264 decline are way too optimistic and it will stay higher than 50% for longer than anyone expected.

Especially now DRAM and NAND price are skyrocketing and will be the case till at least 2028 I wont be surprised a lot of lower end devices wont get new media decoding engine upgrade for a very long time. The same goes with CPU upgrade for software decoding on Smartphone.

Z2697

16th December 2025, 21:13

I will absolutely bet those projection for H.264 decline are way too optimistic and it will stay higher than 50% for longer than anyone expected.

Especially now DRAM and NAND price are skyrocketing and will be the case till at least 2028 I wont be surprised a lot of lower end devices wont get new media decoding engine upgrade for a very long time. The same goes with CPU upgrade for software decoding on Smartphone.

The "common" RAM and SSD size is more than enough to implement a new decoder, I don't understand the connection here.
And if storage is expensive, it's more likely that people (except videophiles) will prefer "more advanced" space-saving codecs.
But, nowadays the biggest incentive behind codec adoption is probably bandwidth, since most of the video are streamed, and they are not really saving space for the platform, they just add another re-encode option to the stack because of compatibility needs.

Z2697

16th December 2025, 21:51

The only "AI" feature currently in ECM is JVET-AJ0249: Neural network-based intra prediction with DIMD mode derivation.
Which sounds like harmless :)

Let's recap how intra prediction works:
With reconstructed pixels from single row / column of pixels from above and left,
it extrapolates pixels from neighbor pixels in the estimated direction (limited to some number of choices) to fill the current block (angular mode),
or use average of all neighbor pixels to fill the current block (DC mode),
or it interpolates each pixel's value in current block by coordinate, again from only two lines of neighbor pixel (planar mode).

The NN is just used to choose modes...

And then comes residual.
Prediction + residual = reconstruction

birdie

18th December 2025, 12:08

There’s an interesting (and somewhat depressing) real-world data point around VVC that seems worth sharing here, especially in light of the ongoing H.267/ECM discussion.

Oppo has recently filed what appears to be one of the first VVC SEP suits (https://ipfray.com/oppo-fires-back-at-asus-in-china-files-first-known-vvc-sep-suit/), targeting ASUS in China. What makes this notable is that ASUS doesn’t ship its own VVC implementation; any hypothetical VVC capability would come indirectly via Intel Lunar Lake. In other words, we’re already seeing litigation before VVC has any meaningful deployment or demand.

I raised this broader adoption/licensing concern directly with Vadim Seregin (Qualcomm / MPEG), along with a more technical question about VVC’s near-lossless behavior at high bitrates. His response was polite and technically correct, but also illustrative of a larger disconnect.

Near-lossless: VVC does have a lossless mode (VTM), but that doesn’t really address the practical observation that current VVC encoders (e.g. vvenc) tend to preserve fine detail worse than HEVC / AVC in high-bitrate, near-lossless regimes. This looks like a side effect of stronger RD-optimized tools and filtering rather than an encoder bug.

Adoption / licensing: The response was essentially that licensing issues are “not related to standards development.” That may be true from a committee perspective, but from an implementer’s point of view, licensing is the dominant constraint. A codec that cannot be shipped safely might as well not exist, regardless of its compression gains.

What worries me is that this same separation of concerns appears to be repeating for ECM / H.267: technical progress continuing in parallel with increasingly hostile or opaque licensing signals. The Oppo–ASUS case feels less like a meaningful dispute and more like an early warning of HEVC-style fragmentation — except this time there is already a viable, widely deployed royalty-free alternative.

I’m not claiming VVC is “dead” as a specification, but as a practical ecosystem choice it’s hard to see how these signals encourage adoption outside of narrow or captive niches.

benwaggoner

20th December 2025, 00:09

benwaggoner

20th December 2025, 00:19

The response was essentially that licensing issues are “not related to standards development.” That may be true from a committee perspective, but from an implementer’s point of view, licensing is the dominant constraint. A codec that cannot be shipped safely might as well not exist, regardless of its compression gains.

What worries me is that this same separation of concerns appears to be repeating for ECM / H.267: technical progress continuing in parallel with increasingly hostile or opaque licensing signals. The Oppo–ASUS case feels less like a meaningful dispute and more like an early warning of HEVC-style fragmentation — except this time there is already a viable, widely deployed royalty-free alternative.
Yep, 100%. Given the pretty exponential growth in the number of patents and unique patent holders each MPEG codec cycle, the IP risk is getting worse more than the compression efficiency is getting better. VVC could cost 3x more to license than H.264 did at launch and still have a great ROI for a variety of use cases. But a CFO could well look at VVC licensing and conclude that the actual net licensing cost will be retroactively determined by a series of 12 residents of the Eastern District of Texas. That's hard to put into Excel.

I hope that, like the failure of MPEG-4 part 2 and threat of VC-1 did for H.264, the failure of anyone to make money from VVC licensing and the threat of AV2 will inspire the patent holders to decide it's better to share slices of a big pie rather than fight over slices from a tiny shrinking pie.

kurkosdr

20th December 2025, 21:14

I hope that, like the failure of MPEG-4 part 2 and threat of VC-1 did for H.264, the failure of anyone to make money from VVC licensing and the threat of AV2 will inspire the patent holders to decide it's better to share slices of a big pie rather than fight over slices from a tiny shrinking pie.
Nope, not gonna happen. The patent holders around MPEG know that AOM will keep shrinking the pie left for MPEG standards no matter what. Even if someone has a "golden patent" that they manage to successfully assert against AV1 or AV2, it's much easier for the tech giants behind AOM to buy that single patent (or the entity that owns it) than deal with the licensing hell that is the recent MPEG standards (where every patented invention that makes a minor 0.1% difference is added to the standard and becomes a licensing landmine on its own). In plain English, MPEG standards are designed to infringe on as many patents as possible (not the intent, but that's what ends up happening when you don't take IP issues into account) while AOM standards adopt a more value-based approach of only including royalty-free technologies to achieve performance similar to MPEG standards. This of course means that AOM will keep expanding at the detriment of MPEG standards.

And again, the patent holders around MPEG know this. They know HEVC will be their last hurrah (HEVC is the lowest common denominator for HDR content, so it will be with us forever) and they know the only income they'll see from VVC will be from those few countries that adopt it for broadcasting and those high-end 4K TVs that feature VVC as future-proofing. Seriously, that's the pie for VVC, it's small and it won't get any bigger.

So, what did the patent holders around MPEG do with this knowledge at hand? Answer: They have entered "milking mode", trying to extract as much revenue as possible (by splitting themselves into multiple licensing entities and jacking up royalty fees as much as they can without technically running afoul of FRAND) before MPEG becomes too irrelevant financially to even bother participating in the meetings that produce the new standards.

Z2697

21st December 2025, 15:33

kurkosdr

22nd December 2025, 00:16

There's the speculation that they are going to milk HEVC as well, based on the Dell and HP allegedly disabled HEVC decoder with on laptops... (more like "shipped without that (https://apps.microsoft.com/detail/9n4wgh0z6vhq) M$ store extension" than disabled?)
So yeah things are not looking good for MPEG. Unless they can suddenly make MPEG codecs royalty free there's no way they are gonna compete with AOM.
My whole point was they have already gone into "milking mode" for HEVC because they know it will be their last hurrah. That's the reason they split into multiple patent licensing entities and then started jacking up the fees. Because that's how you milk an ISO standard without technically running afoul of FRAND. They also try to milk VVC, but as I said, that pie is very small, so no matter how hard they milk (and hard they are and will), what they'll get from VVC is paltry either way.

Again, they already know all of this. The knew it before the VVC spec was finalized (that streamers were looking at AV1 as their next-gen standard not VVC, that most broadcasters aren't going VVC, and that no 8K optical disc utilizing VVC will happen), in fact, they knew it after VP9 happened and showed the world Google wasn't planning to abandon their royalty-free codec efforts after VP8. They know MPEG is going the way of the Edison Trust/MPPC because it's now possible to have competitive video compression standards without having to "pool" hundreds or thousands of patents. So, much like the Edison Trust/MPPC, they try to make as much money as they can before their last essential patents expire. There is no reason for them to think of goodwill or the future of MPEG standards anymore, their only concern is to not technically run afoul of the "R" part of FRAND (emphasis on "technically"). So, we'll just have to tolerate the milking until their HEVC-essential patents expire.

birdie

24th December 2025, 08:35

Finally, there has been a major improvement in licensing: Access Advance acquires Via Licensing Alliance’s HEVC, VVC patent pools (https://ipfray.com/breaking-access-advance-acquires-via-licensing-alliances-hevc-vvc-patent-pools/) But there are multiple licensors beyond these two patent pools, according to Wikipedia they are: "Apple, Canon, Ericsson, Fraunhofer, Google, Huawei, Intel, Interdigital, LG, Maxell, Microsoft, Nokia, Oppo, Qualcomm, Samsung, Sharp and Sony".

The usual criticism remains however: What the Access Advance / Via LA Deal Doesn’t Change About Codec Adoption (https://streaminglearningcenter.com/articles/what-the-access-advance-via-la-deal-doesnt-change-about-codec-adoption.html)

However, it doesn’t make VVC necessary, and that’s the most critical factor in motivating short- or even mid-term codec adoption. It also doesn’t address concerns about Nokia-style licensing claims, which is the most crucial consideration for publisher adoption.

hajj_3

24th December 2025, 11:52

press releases from Access Advance and Via-LA merging their HEVC and VVC patent pools:

https://accessadvance.com/2025/12/15/access-advance-and-via-licensing-alliance-announce-hevc-vvc-program-acquisition/
https://www.accessnewswire.com/newsroom/en/electronics-and-engineering/access-advance-and-via-licensing-alliance-announce-hevc%2fvvc-program-acq-1117638

VCL Advance (Video Codec Licensing Advance) patent pool has now been formed, here are the fees:

https://i.ibb.co/Rkrx83C4/Screenshot-2025-12-24-112517.png

rwill

24th December 2025, 12:14

birdie

24th December 2025, 12:37

rwill

24th December 2025, 14:04

If only a few people on this forum use or are interested in the codec, then we will not get better encoders or decoders, and this codec will essentially become irrelevant or outright dead.

And the only way to launch it is to make it less scary, i.e. solve the licensing situation.

We were promised x266 when? Two years ago? It's seen zero public releases yet.

I don't think you people can "solve the licensing situation" by making posts on this board here. I think you have to be quite high up in large $$$ corporations and make the right decisions there.

Regarding x266 being late, that one is on Multicoreware. Maybe its political, maybe development is stuck, who knows - I suggest to not depend on their software.

Some time ago I implemented some basic VVC encoder. That took me maybe some months on and off doing some other things in between. Instead of lamenting about the licensing situation here you could have done the same if, instead of spending your free time on the licensing situation, you had honed your video codec programming skills in the past years. But I get that programming is not for everyone and that complaining is cheaper for the head.

GeoffreyA

24th December 2025, 15:12

I think the problem most in need of solving is that of grain.

ksec

26th December 2025, 09:15

The "common" RAM and SSD size is more than enough to implement a new decoder, I don't understand the connection here.
And if storage is expensive, it's more likely that people (except videophiles) will prefer "more advanced" space-saving codecs.
But, nowadays the biggest incentive behind codec adoption is probably bandwidth, since most of the video are streamed, and they are not really saving space for the platform, they just add another re-encode option to the stack because of compatibility needs.

The connection is that RAM and NAND are expensive and they have to save up cost on somewhere. SoC cost as well as decoding engine IP all goes together and may suffer.

kurkosdr

26th December 2025, 20:51

I wonder why you are all so interested in the IP situation regarding video codecs. As far as I know no one here is even remotely invested or has a business where licensing costs make up a above neglect-able amount. I mean people on this board are making lists and are really fixated on IP validity and lapse times - yet no one here is affected by them.

Well, that's the problem, the licensing mess for HEVC is so bad that we are affected by it.

Let me outline the mess in more detail:

- HP & Dell are disabling HEVC support on certain laptops (https://www.guru3d.com/story/why-hp-dell-are-disabling-hevc-support-on-certain-laptops/) because of the licensing mess. This means that you can't trust a new laptop bought from Best Buy (even when left on the pre-installed OS) to support HEVC out of the box. Imagine if we had new PCs in 2017 not supporting H.264 out of the box.

- Neither Windows 10 nor Windows 11 include HEVC support out of the box. Remember when anyone on Windows 7 could be trusted to have an H.264 system decoder provided by the OS? Nice times. This meant that, when XP went EOL, the majority of Windows PCs had an H.264 decoder at the OS level that browsers could use. Not so with HEVC (when Windows 7 and 8.1 went EOL). Ironically, a Senior Director at Microsoft had called the VPx codecs the "Esperado and Kligon" of codecs (https://web.archive.org/web/20110112232434/https://blogs.msdn.com/b/tims/archive/2011/01/11/an-open-letter-from-the-president-of-the-united-states-of-google.aspx) back in 2011, yet today, Microsoft relies on VP9 and AV1 as their next-gen codecs, and whatever value an HEVC decoder brings to the table, Microsoft apparently doesn't deem it high enough to justify the licensing cost of having an HEVC decoder in Windows 10 and 11 out of the box.

- Absolutely no browser for Windows comes with a bundled HEVC decoder (like Chrome came with an H.264 decoder), because again, no browser vendor considers the licensing cost to be worth it

Do you see now why some of us were highly sceptical of the "pass it down to system codecs bro" people (aka people like you)?

PROTIP: When the licensing situation of a standard is especially crap, system codecs cannot be assumed to exist at either the OS or GPU driver level, even on Windows.

Do you see now why some of us are glad that the open web was spared from the licensing mess surrounding HEVC?

Call me old-fashioned, but web pages (at least of the open kind, aka those without Widevine DRM) should be decodable by just an application (commonly called a "browser"), without the browser having to rely on system-level peculiarities that may or may not exist on a particular system for successful decoding. Sure, the browser can use system-level peculiarities for acceleration, but there should be an application-level fallback. H.264 kind-of has that in the form of Chrome's built-in H.264 software decoder, call me back when HEVC has the same on at least one browser available for Windows (the most popular OS for laptops and desktops).

And VVC is shaping up to be the same mess and worse.

---

About H.264, there are edge cases such as Desktop Linux systems not having OS-level codecs (because the GPU vendors can't be arsed to clarify whether the royalty is paid per hardware or per driver download), so there is some value in watching H.264 patents for expiration, since that would make the H.264 universal in all browsers, not just Chrome (which isn't available in all non-PC platforms, or you may prefer another browser). I was given a corporate laptop without H.264 codecs, and my preferred browser (Firefox) would occasionally give me codec errors, so I switched to Chrome. But I admit those are edge cases, H.264 has proven very popular on the open web because its availability is "good enough". Not something I personally like (I prefer universal to "good enough"), but the market has decided. HEVC failed to clear even that "good enough" bar, with former allies such as Windows (Microsoft) turning their backs to HEVC's licensing mess.

rwill

29th December 2025, 11:36

Ah I get it now. You don't want to pay money for certain things and are of the opinion that some things just should be free.

I too was leaning towards communism when I was younger but this went away once I moved out of my parents place and had to sustain myself.

kurkosdr

29th December 2025, 14:32

Ah I get it now. You don't want to pay money for certain things and are of the opinion that some things just should be free.
Lol, talk about not having a clue how things work on the web. It doesn't matter if your system has an HEVC decoder (and how many HEVC decoders you have bought), it matters whether your viewers have an HEVC decoder.

Please go ahead and make a page serving HEVC video and tell any Windows 10 and Windows 11 users that they might have to buy something called an "HEVC video extension" from the Microsoft Store and see how far you get. Instead, VP9 and AV1 have built-in decoders in Chrome, Firefox, and Edge. And yes, you can provide an H.264 fallback, but then you have the problem of viewers complaining 4K and HDR not working and the like. Why do that when VP9 and AV1 exist?

.I too was leaning towards communism when I was younger but this went away once I moved out of my parents place and had to sustain myself.
Yeah, sure, because Microsoft is well-known for being "communist". This is what you people fail to understand: The patent holders holding essential patents for HEVC somehow managed to piss off Microsoft (the company that used to mock the VPx codecs), we are talking about an achievement here. The non-inclusion of an HEVC decoder in Windows 10 and 11 was the inflection point that made HEVC irrelevant on the web for good (since you can't assume system codecs exist on Windows, even after Windows 7 and 8.1 EOL). With no bundled HEVC decoder in any Windows browser, that sealed the deal.

For the record, I was never leaning towards communism, then or now, I perceive HEVC's failure on the web to be a market-based one.

rwill

29th December 2025, 15:05

You are trying really hard to misunderstand me. You also now suddenly mention something called "the web".

Anyway, have a nice day.

Z2697

29th December 2025, 15:58

I guess we all know something called "the web"... How you've been here otherwise?

rwill

29th December 2025, 17:39

I guess we all know something called "the web"... How you've been here otherwise?

Sure, but what does "the web" need 4k and HDR for? kurkosdr is shifting goal posts again because he knows HEVC works well in TVs and Smartphones. It is widely accepted that TVs and Smartphones cost money and part of that money is for IP. While apparently with "the web" it is not acceptable to pay even a dollar for high end technology.

"the web" has its video standards but because these cannot fully replace what a 2k$ TV set has to offer certain people complain about companies that just want some return on their investment.

kurkosdr

29th December 2025, 18:45

Sure, but what does "the web" need 4k and HDR for?
Quite frankly, not much, most people watch movies on Smart TVs and smartphones today. But VP9 and AV1 is there is you want to watch your YouTube and Twitch videos in 4K HDR from your browser.

kurkosdr is shifting goal posts again because he knows HEVC works well in TVs and Smartphones. It is widely accepted that TVs and Smartphones cost money and part of that money is for IP.
If so, how much VVC video is streamed to TVs and Smartphones? Looks like HEVC support in TVs and smartphones is a backwards compatibility concern and ISO/ITU formats are mostly dead after HEVC, and the next step is AV1. Funny how the market has a way of navigating away from expensive IP that fails the cost-benefit analysis.

While apparently with "the web" it is not acceptable to pay even a dollar for high end technology.
Yes, it's been that way since Microsoft started giving away Internet Explorer for free (which was high-end technology at the time), anyone who tried to ignore that reality ended up bankrupt (Netscape).

In plain English, people expect browsers to be either bundled for no extra cost with the OS or be available for download for free. When it comes to Windows, neither the browser bundled with Windows (Edge) nor any of the popular freely downloadable browsers offers built-in HEVC decoding. That's a market-based failure for HEVC right there, considering H.264 had Chrome. Also, Windows doesn't even offer system codecs for HEVC, so relying on the presence of system codecs is unreliable.

Z2697

29th December 2025, 18:54

"the web" has its video standards but because these cannot fully replace what a 2k$ TV set has to offer certain people complain about companies that just want some return on their investment.

Except that "the web" controls TVs and phones now. (most of)

kurkosdr

29th December 2025, 19:07

Except that "the web" controls TVs and phones now. (most of)
Sure, but why make a webpage that only works with TVs and phones when AV1 is universal?

modus-ms325c

2nd January 2026, 17:51

technically speaking, you are correct, Netscape did get bankrupt, for the exact reasons you mentioned above and then some, albeit very slowly.

however, i remember there being a massive mutiny on E.M. Meen's X platform (back when it wasn't actually such, 5-6 years in fact) over a tweet someone did on how they were involved in the final hours of shipping IE6. (or was it IE5?) either way, to put it very mildly, it was widely seen (by Netscape devs and its users, albeit they're not necessarily the only ones to emit such backlash, as will be described now) as Microsoft's inability to admit responsibility on the damage they've caused on shoving their buggy, unstable, and quite frankly unsecure and/or just straight-up paranoid browser onto everyone's PCs, one that saw many pages require it even. though such effects would not be felt until much later.

aside from that, i remember a time when simply locking videos behind an Adobe Flash install message or any other piece of external decoder software (think RealMedia, Windows Media, etc. and i mean actual software) was the worst you could've done on "the web". if nothing else, it was your choice to either install the required components to watch a video or not at all, tho in all honesty, that wasn't a choice so much as a mandatory requirement for seeing anything at all there.

as of today, however, should your device contain video+audio decoding support for free without you even noticing even slightly, that choice is now forced on you.

"the web" also did not support MPEG codec stuff at all, in any way, whatsoever unless licensed to, and bundled, with external software that you also had to install, but hey, at least it was free.

do go on in an self-destructive performative outrage rampage on how communism is bad tho.

kurkosdr

2nd January 2026, 20:45

do go on in an self-destructive performative outrage rampage on how communism is bad tho.
Communism is bad in the sense it doesn't work in the real world, it requires either perfect people or a perfect government (depending on how you define it). It's like designing a wireless system that assumes zero signal attenuation, or designing a chip assuming zero signal propagation. Designing such a system, unconstrained from the constraints of the real world, is a blast, but has no practical application. But please do go on in an self-destructive performative outrage rampage on how this isn't true.

But why are we even discussing this? Ah yeah, because someone brought up communism as a distraction tactic.

---

Back in the real world, the failure of HEVC on the web is a failure of the patent holders holding essential patents to understand the market around the web. Again, H.264 had a browser for Windows (Chrome) that supported it consistently regardless of the presence of system codecs, and H.264 is free of content fees for free-to-view web video, HEVC has neither of those.

GeoffreyA

2nd January 2026, 21:16

kurkosdr

2nd January 2026, 21:37

In my humble and uninformed opinion on patents and such matters, HEVC should have become the baseline years ago, but it hasn't happened.
It would have if the patent holders had picked the same licensing model as H.264: comfortable single-pool licensing with a royalty cap (so companies like Microsoft that often sell their OS for peanuts to volume licensees and OEMs don't have to worry about per-copy royalties to multiple pools and can instead write one large check to a single pool and even offer HEVC as a bundled codec in Edge browser for Windows 7 and 8.1 users) and waive content fees for free-to-view content.

But no, they got greedy and as a result are now stuck with broadcasters and Blu-ray instead, both very conservative markets not looking to move to VVC any time soon. And let's not forget, premium streamers like Netflix that are not looking at VVC as their next gen standard.

But I believe this has been discussed to death.

modus-ms325c

2nd January 2026, 23:53

ok, after a bit of thought in how i responded (plus i don't intend to shill communism nor will i denounce it, let alone even talk about it anymore as it's against doom9 rules and rwill should've known better in how to respond anyway) i decided it's time not to engage with this thread anymore and only lurk it instead. i feel, it's best not to milk the "VVC sucks cuz' MPEG sucks cuz' they milk VVC dry with patents and whatever else" cow here, and i will also not discuss on whatever "technical brilliance" VVC has going for it either because, let's be honest, "technical brilliance" is way past its prime and is likely already exhausted in terms of anyone even remotely talking about it, anyway, so who cares.

as for the things i'm willing to engage in? well, once the inevitable AV2 codec comes out with certain (officialy distributed) videos containing not only it but H.264, VP9, AV1 video tracks (streams in YouTube terms) as well... once i discover that the AV2 stream is significantly worse in every way in terms of video quality, detail retention, or literally any kind of retaining whatever imperfections AV2 is capable of doling out compared to the aforementioned codec tracks... i promise that i'll raze this fucking site with the most insane rant against AV2 you'll ever witness. but not here, and most certainly not now.

peace out.

benwaggoner

5th January 2026, 17:51

i will also not discuss on whatever "technical brilliance" VVC has going for it either because, let's be honest, "technical brilliance" is way past its prime and is likely already exhausted in terms of anyone even remotely talking about it, anyway, so who cares
That seems to be an idiosyncratic take! How does good design not matter? As long as network bandwidth and storage are not infinite, getting better compression efficiency gains with less increase in SoC mm^2 is always going to matter.

once i discover that the AV2 stream is significantly worse in every way in terms of video quality, detail retention, or literally any kind of retaining whatever imperfections AV2 is capable of doling out compared to the aforementioned codec tracks... i promise that i'll raze this fucking site with the most insane rant against AV2 you'll ever witness.
Given we only have in-development reference encoders for AV2, and not any commercial-grade psychovisually tuned one, I think it's challenging to say much about how good AV2 will look once we have those things in a few years. HEVC was kind of a unique case in getting practical encoders so early in its lifespan, as it was really the only practical option to get 4K HDR, which the content and consumer electronics companies were aligned with as a big way to make a lot more money. None of the codecs since then, or that I see looking forward, really have any new content types they unlock; they mainly are to do what we already can at lower bitrates.

benwaggoner

5th January 2026, 18:02

It would have if the patent holders had picked the same licensing model as H.264: comfortable single-pool licensing with a royalty cap (so companies like Microsoft that often sell their OS for peanuts to volume licensees and OEMs don't have to worry about per-copy royalties to multiple pools and can instead write one large check to a single pool and even offer HEVC as a bundled codec in Edge browser for Windows 7 and 8.1 users) and waive content fees for free-to-view content.

But no, they got greedy and as a result are now stuck with broadcasters and Blu-ray instead, both very conservative markets not looking to move to VVC any time soon. And let's not forget, premium streamers like Netflix that are not looking at VVC as their next gen standard.
4K Blu-ray was the last optical disc format and HEVC the last codec to be adopted in one. The core technology simply doesn't make sense anymore. Consumer broadband can easily exceed Blu-ray read speeds and with much better latency, and flash memory is approching the cost of manufacturing a Blu-ray disc. Bear in mind that even a triple-layer 4K is only 100 GB max, and I can get a 128 GB flash drive for about $8/each in bulk, and under $4 for one equivalent to a dual layer disc.

It was an eye opener for me a few years ago when I discovered I could install a game about 3x faster as a download than off a disc. UHD Blu-ray spec is only 144 Mbps, and the current game consoles go up to maybe 400 Mbps maximum in ideal circumstances, and often less in practice. Glacial compared to gigabit internet.

benwaggoner

5th January 2026, 18:08

In my humble and uninformed opinion on patents and such matters, HEVC should have become the baseline years ago, but it hasn't happened. Indeed, AV1 seems closer to being a universal successor to H.264, and that momentum will likely carry on with AV2.
In what markets do you see AV1 becoming universally used outside of perhaps YouTube? Most HDR streaming is still HEVC as far as I can tell.

I fear that we'll never see a codec as universal as H.264 was, where we've been able to assume for 10+ years that anything that can play back video has a High Profile hardware H.264 decoder. We still are seeing new pretty high volume lower cost phones being sold without AV1 decode, over halfway to HEVC's patents expiring. I think AV2 is more likely as a universal successor by 2035 or so. Phones have a shorter replacement cycle, but people are holding on to PCs and especially home electronics for longer and longer. There are a lot of very good high end TVs only a couple of years old for which HEVC will remain the best available decoder.

benwaggoner

5th January 2026, 18:14

Yeah, sure, because Microsoft is well-known for being "communist". This is what you people fail to understand: The patent holders holding essential patents for HEVC somehow managed to piss off Microsoft (the company that used to mock the VPx codecs), we are talking about an achievement here. The non-inclusion of an HEVC decoder in Windows 10 and 11 was the inflection point that made HEVC irrelevant on the web for good (since you can't assume system codecs exist on Windows, even after Windows 7 and 8.1 EOL). With no bundled HEVC decoder in any Windows browser, that sealed the deal.
Yeah, this is a good take. And HEVC decode was a free built-in feature until very late in Windows 10 development! Whichever NPE holdouts unwilling to give Microsoft an acceptable license for Windows really shot themselves in the foot. HEVC made enough money in consumer electronics that the lesson was apparently not signaled clearly enough for VVC, leaving some companies fighting brutally hard for a bigger slice of a very tiny pie. Perhaps that will discourage some of the more patent-trollish companies from investing in getting much H.267 IP. The companies that own the bulk of the patents are being appropriately cooperative, but all it takes is a single essential patent out of thousands held by the wrong entity to shit in the pool so everyone gets kicked out.

GeoffreyA

5th January 2026, 23:01

In what markets do you see AV1 becoming universally used outside of perhaps YouTube? Most HDR streaming is still HEVC as far as I can tell.

I fear that we'll never see a codec as universal as H.264 was, where we've been able to assume for 10+ years that anything that can play back video has a High Profile hardware H.264 decoder. We still are seeing new pretty high volume lower cost phones being sold without AV1 decode, over halfway to HEVC's patents expiring. I think AV2 is more likely as a universal successor by 2035 or so. Phones have a shorter replacement cycle, but people are holding on to PCs and especially home electronics for longer and longer. There are a lot of very good high end TVs only a couple of years old for which HEVC will remain the best available decoder.

Thanks for the response, Ben. No doubt, my statement on AV1 was too strong; HEVC reigns in markets such as HDR streaming and optical media, and AV1 hardware decode isn't universal. libdav1d helped immensely, but more battery is going to be used on many a device. Pre-2020 TVs likely have no support.

Outside YouTube, it has seen a bit of success on the high seas, particularly in anime. Netflix is serving about 30% and deploying FGS. I would say the codec feels close in spirit to H.264, and there is a great deal of fondness for it, despite its early struggles in performance and detail. Then, the popular SVT-AV1 forks, where we haven't seen such relentless drive since x264. I can only see AV1's use increasing, and hopefully AV2 will inherit a lot of the work done, say, in the tuned encoders.

modus-ms325c

6th January 2026, 02:48

That seems to be an idiosyncratic take! How does good design not matter? As long as network bandwidth and storage are not infinite, getting better compression efficiency gains with less increase in SoC mm^2 is always going to matter.VVC licensing situation is being talked about all the time at just about every opportunity, no one's gonna focus on the actual technological features that it has right now.
more like how the codec itself is being held hostage by its insane ecosystem. i mean, just by talking about its insane features alone already makes me bored to fucking tears already.
Given we only have in-development reference encoders for AV2, and not any commercial-grade psychovisually tuned one, I think it's challenging to say much about how good AV2 will look once we have those things in a few years. HEVC was kind of a unique case in getting practical encoders so early in its lifespan, as it was really the only practical option to get 4K HDR, which the content and consumer electronics companies were aligned with as a big way to make a lot more money. None of the codecs since then, or that I see looking forward, really have any new content types they unlock; they mainly are to do what we already can at lower bitrates.i mean, ok, but "AV2 is in development so we don't really know" is one thing.
4K Blu-ray was the last optical disc format and HEVC the last codec to be adopted in one. The core technology simply doesn't make sense anymore. Consumer broadband can easily exceed Blu-ray read speeds and with much better latency, and flash memory is approching the cost of manufacturing a Blu-ray disc. Bear in mind that even a triple-layer 4K is only 100 GB max, and I can get a 128 GB flash drive for about $8/each in bulk, and under $4 for one equivalent to a dual layer disc.

It was an eye opener for me a few years ago when I discovered I could install a game about 3x faster as a download than off a disc. UHD Blu-ray spec is only 144 Mbps, and the current game consoles go up to maybe 400 Mbps maximum in ideal circumstances, and often less in practice. Glacial compared to gigabit internet.you do know for a fact that UHD Blu-ray playback is heavily reliant on your internet connection, right? you do know that for a fact, right?
(legal) digital download services can also reach service termination at just about any time now, and existing UHD-BD discs may become a massive useless paperweight in leau to DIVX DVDs, just in case UHD-BD DRM stops working and/or ends service sooner than expected.
Yeah, this is a good take. And HEVC decode was a free built-in feature until very late in Windows 10 development! Whichever NPE holdouts unwilling to give Microsoft an acceptable license for Windows really shot themselves in the foot. HEVC made enough money in consumer electronics that the lesson was apparently not signaled clearly enough for VVC, leaving some companies fighting brutally hard for a bigger slice of a very tiny pie. Perhaps that will discourage some of the more patent-trollish companies from investing in getting much H.267 IP. The companies that own the bulk of the patents are being appropriately cooperative, but all it takes is a single essential patent out of thousands held by the wrong entity to shit in the pool so everyone gets kicked out.oh my god lol

kurkosdr

6th January 2026, 23:10

you do know for a fact that UHD Blu-ray playback is heavily reliant on your internet connection, right? you do know that for a fact, right?
(legal) digital download services can also reach service termination at just about any time now, and existing UHD-BD discs may become a massive useless paperweight in leau to DIVX DVDs, just in case UHD-BD DRM stops working and/or ends service sooner than expected.
Huh? When it comes to on-disc content, UHD Blu-rays can be copied 1:1 with the help of a tool like DVD Fab (the paid version obv) and a "friendly" drive (that is, a drive that implements BDXL but doesn't implement UHD Blu-ray's DRM that locks "unauthorised" software out of the drive). So, that's your guaranteed "insurance" against the discs becoming a paperweight.

Also, UHD Blu-ray DRM is 100% local, it doesn't need to "phone home" to decrypt a disc. In plain English, you can do it in a submarine with a new disc that has never been in the drive before, as long as your player has been updated beforehand. So as long as you have a legit disc and an updated player, you own the content.

modus-ms325c

7th January 2026, 02:12

Huh? When it comes to on-disc content, UHD Blu-rays can be copied 1:1 with the help of a tool like DVD Fab (the paid version obv) and a "friendly" drive (that is, a drive that implements BDXL but doesn't implement UHD Blu-ray's DRM that locks "unauthorised" software out of the drive). So, that's your guaranteed "insurance" against the discs becoming a paperweight.

Also, UHD Blu-ray DRM is 100% local, it doesn't need to "phone home" to decrypt a disc. In plain English, you can do it in a submarine with a new disc that has never been in the drive before, as long as your player has been updated beforehand. So as long as you have a legit disc and an updated player, you own the content.OK, let's see how reliable these methods are in ~4-20 years, assuming internet access hasn't gone out the way of the wazoo and/or isn't just out-and-out dead anymore.

kurkosdr

7th January 2026, 22:18

OK, let's see how reliable these methods are in ~4-20 years, assuming internet access hasn't gone out the way of the wazoo and/or isn't just out-and-out dead anymore.
Tools like DVDFab require online activation, so if DVDFab's online activation service goes down, yeah, the tool won't work anymore on new computers.

But as long as DVDFab's activation service is online, there is nothing Hollywood can do to prevent UHD Blu-rays from being copied 1:1 (with the right "friendly" drive), because again, the content is on the frickin' disc and is encrypted using a long-compromised encryption system, it's not dependent on a Hollywood-provided service or server.

And let's not forget that tools such as XReveal exist that don't require online activation. While it misses some features (such as removal of Screen Pass/BD-J menu countermeasures), you can still use it to copy just the main movie (again, with the right "friendly" drive).

And let's not also forget that you can buy a UHD Blu-ray player, update it so that it plays all your existing discs, and never update it/connect it to the internet ever again, since UHD Blu-ray playback requires no internet connection/updates/phoning home for discs pressed before the currently installed update was released.

What's even the debate here? That theoretically, the entire internet can go down, and anyone not already having a copy of Xreveal won't be able to download it? Or that they won't be able to buy a UHD Blu-ray player? Under this scenario, the same applies for tools like VLC, so... even VCDs are theoretically "internet dependent" since they are not playable if you don't already have a copy of a tool to play them or a standalone player.

benwaggoner

10th January 2026, 00:55

i mean, ok, but "AV2 is in development so we don't really know" is one thing.
The AV2 bitstream hasn't been quite locked down, but it has been feature complete in terms of content types for a long time now. More might get added later; MVC-HEVC wasn't part of the HEVC 1.0 spec. But what AV2 is and can do with what profiles at launch is well define.

you do know for a fact that UHD Blu-ray playback is heavily reliant on your internet connection, right? you do know that for a fact, right?
No, A Blu-ray player can still play a movie without any internet connection. Are you thinking of BD-Live content or something? That's orthogonal to actually playing back the video and audio content on disc. A blu-ray player may require an internet connection for setup, but I don't know of any mainstream discs or players that won't playback the content without internet connectivity. Bear in mind Blu-ray was designed a couple of decades ago when the idea of having always-on internet in every car or vacation cabin was years from happening. The first Blu-ray players and discs were launched a year before the first 2G-only iPhone.

modus-ms325c

10th January 2026, 19:50

i was exclusively talking about Ultra HD Blu-Ray, but yeah BD-Live definitely checks out.

kurkosdr

10th January 2026, 20:23

i was exclusively talking about Ultra HD Blu-Ray, but yeah BD-Live definitely checks out.
And I was also exclusively talking about Ultra HD Blu-Ray, and I am telling you again that the content is on-disc and encrypted with a long-compromised encryption system, with commercially available software to crack said encryption system. Also, authorized players require no phoning home to view the disc, as long as the player has been updated with a firmware update released after the disc was pressed.

BD-Live is used for extra content (when it's used), or more appropriately extra extra content, since Ultra HD Blu-rays have a good amount of extra content on-disc in addition to the main movie. UHD Blu-rays (not just plain Blu-rays) were designed so that the on-disc content is viewable without an internet connections.

So yes, when you buy a UHD Blu-ray disc, you aren't reliant on a remote server or even an internet connection for the on-disc content, not anymore than a regular Blu-ray anyway.

/end off-topic

modus-ms325c

11th January 2026, 02:36

yeah, i get it. UHD BDs not reliant on internet connection, yadda yadda yadda.
i just don't want to keep talking here for longer than i oughta. i've exhausted all the words i could pull out of my brain with this shit, and again i just don't want to keep talking.

so let's leave it at that, okay? let me leave it at that. least i can do.

Z2697

11th January 2026, 05:21

We know that preservation of media we like is all important.
But your starting point is straightly incorrect.
This does not make you look like a tired hero at the end of a movie or whatever it is that you thought of.

modus-ms325c

12th January 2026, 18:48

oibaf

15th January 2026, 11:38

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

15th January 2026, 21:49

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

14th February 2026, 01:36

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

14th February 2026, 11:24

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

15th February 2026, 21:51

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

18th February 2026, 06:10

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

8th April 2026, 09:02

LigH

8th April 2026, 11:03

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

kurkosdr

10th April 2026, 15:52

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

10th April 2026, 19:10

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

10th April 2026, 19:22

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

That's been my impression as well.

kurkosdr

10th April 2026, 21:26

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

22nd June 2026, 20:00

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

22nd June 2026, 20:09

benwaggoner

1st July 2026, 19:05

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

I've seen a lot of "AI upscaling" where they didn't get fundamentals like aspect ratio, frame rate, or deinterlacing/inverse telecine working. AI upsampling can do some impressive stuff IF the fundamentals are already done correctly, but can't make up for getting the input wrong in ways we could fix in AVISynth 20 years ago.

CruNcher

3rd July 2026, 06:43

oh yeah test some Ai Video SaaS that let you do Image2Video with your own reference it can get funny how some think different of AR and the scaling pipeline in these WebApps some are at least go a more advanced way asking you first about your input source and what you want but some others its like most of the times with these SaaS Gambling time :D

But its funny to Hack their APIs last time i used a funny trick to make one of their Services think i have enough credits and created 40 Videos for 40 credits 1 credit for 1080p 10 seconds ;)
But those Chinese found me and fixed it silently after some time realizing it was a bit to cheap ;)
Wonderful when so much AI is used to create even the Backends but it was more interesting what i saw when it comes to resolution those differences they advertise they not really hold up with so much high frequencies getting lost on so many SaaS and Models and their setups between their Models and Video Encoder can also be funny.
Interesting is also that so many have their own Models but behind that are just renamed Frontier Models of others the Chinese have feeling wise thousands of Reselling Endpoints by now ;)

Also found some interesting LTDs registered in the UK mostly of Chinese Resellers but with crazy Chinese Adresses that make 0 sense ;)
"Internet and Post Delivery"
Postboxes ;)
AI registered LTDs mostly