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

[benwaggoner]

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]

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]

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

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

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

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

[LigH]

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

Fraunhofer VVC Encoder ver. 1.12.0 (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]

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

[FranceBB]

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]

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

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

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

[FranceBB]

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

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


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

[...]

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

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

[FranceBB]

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

[ksec]

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

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

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

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

[FranceBB]

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]

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.

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.

[Z2697]

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.

[GeoffreyA]

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]

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

You got the timeline mixed up here, vvdec was not accepted because the native decoder was in the works.

[FranceBB]

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]

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]

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)

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

[Z2697]

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]

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]

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]

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]

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.

[ksec]

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]

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]

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

[frankplow]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.

Not only VVC but also LC-EVC. Exciting times! ( But again lack of encoder for me to play with )

[LigH]

You can already include xeve and xevd in ffmpeg.

[excellentswordfight]

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]

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]

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]

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

[FranceBB]

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