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

[birdie]

Probably the first Android ROM with built in VVC support (it's not specified whether it's for encoding or decoding, I guess it's decoding only):

https://forum.xda-developers.com/t/rom-11-0_r71-jaguar-oneplus-9-pro-official-v36-updated-september-8-2023.4394057/post-88979437

For OnePlus 9.

[benwaggoner]

Probably the first Android ROM with built in VVC support (it's not specified whether it's for encoding or decoding, I guess it's decoding only):

https://forum.xda-developers.com/t/rom-11-0_r71-jaguar-oneplus-9-pro-official-v36-updated-september-8-2023.4394057/post-88979437

For OnePlus 9.
Software decoder or actual hardware one?

[birdie]

Software decoder or actual hardware one?

You can bet 100% it's a software decoder. There's been no SoCs for mobile phones with HW VVC decoding support yet.

I have a sneaking suspicion Qualcomm Snapdragon 3 will be the first to support HW VVC decoding. We'll learn about that in just a few months.

[birdie]

More patent pools:

https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=161147

[benwaggoner]

You can bet 100% it's a software decoder. There's been no SoCs for mobile phones with HW VVC decoding support yet.

I have a sneaking suspicion Qualcomm Snapdragon 3 will be the first to support HW VVC decoding. We'll learn about that in just a few months.
Qualcomm wouldn't be surprising. And given the costs and variability of mobile bandwidth, it's the market where new codecs can have the quickest immediate customer benefit.

[hajj_3]

}I have a sneaking suspicion Qualcomm Snapdragon 3 will be the first to support HW VVC decoding. We'll learn about that in just a few months.

no vvc in that soc: https://www.qualcomm.com/products/mobile/snapdragon/smartphones/snapdragon-8-series-mobile-platforms/snapdragon-8-gen-3-mobile-platform

[birdie]

no vvc in that soc: https://www.qualcomm.com/products/mobile/snapdragon/smartphones/snapdragon-8-series-mobile-platforms/snapdragon-8-gen-3-mobile-platform

Right (https://docs.qualcomm.com/bundle/publicresource/87-71408-1_REV_B_Snapdragon_8_gen_3_Mobile_Platform_Product_Brief.pdf), that's a huge bummer (in VVC adoption) :-(

"Hardware-accelerated H.265, VP9, AV1 decoder".

Even SnapDragon 8 Gen 2 can decode 4K@30fps in software mode but battery life will be decimated.

[benwaggoner]

no vvc in that soc: https://www.qualcomm.com/products/mobile/snapdragon/smartphones/snapdragon-8-series-mobile-platforms/snapdragon-8-gen-3-mobile-platform
That is somewhat surprising, and disappointing.

[Emulgator]

Well, I wouldn't have expected VVCDec cast into mobile silicon this year.
Not from a chip manufacturer's view: energywise, bugfixwise, IP/patentwise I would have considered it too early days.
The few in business (only 2 or 3 fabs can do that, IIRC) got to deliver perfectly working batches in expensive 4nm for a few hard-earned dollars.
The slightest fault or unkept promise and the market will kill their margin.
Maybe the market will be ready to pay up again for the next feature set, on display end 2024, on the shelves 2025.
VVCDecoding effort will call for 3nm. Encoding ? way out.
Mobile devices can have 1TB on board today, mine from 2021 has 512GB, and I opted for AVC encoding, not HEVC.
No need for compressing the hell out of the private video, battery life will drop as we speak, and that counts as sale argument.

[kurkosdr]

That is somewhat surprising, and disappointing.
Nothing surprising here, very few people outside Doom9 have even heard of VVC, except perhaps 8K enthusiasts (all 3 of them) who may have heard it's the format intended for 8K broadcasts over sat or terrestrial (in the oft-chance such broadcasts ever happen). Hardware support for VVC is pretty slim (I am not gonna pretend 8K "Ultra-Ultra-HD" TVs are anything other than a niche, since they are basically an uncut motherglass of four UHD TVs posing as "innovation" that nobody cares about) and so is available VVC content. Everyone out there checks for HEVC and AV1 hardware support for 4K UHD resolutions, so that's what the industry is providing (for now, at least).

[benwaggoner]

Nothing surprising here, very few people outside Doom9 have even heard of VVC, except perhaps 8K enthusiasts (all 3 of them) who may have heard it's the format intended for 8K broadcasts over sat or terrestrial (in the oft-chance such broadcasts ever happen). Hardware support for VVC is pretty slim (I am not gonna pretend 8K "Ultra-Ultra-HD" TVs are anything other than a niche, since they are basically an uncut motherglass of four UHD TVs posing as "innovation" that nobody cares about) and so is available VVC content. Everyone out there checks for HEVC and AV1 hardware support for 4K UHD resolutions, so that's what the industry is providing (for now, at least).
VVC is getting momentum in living room devices already, and it is a big improvement over HEVC and AV1.

It doesn't enable any big high value content enabling features like HEVC did with HDR and 4K. HEVC was a particularly quickly adopted codec for those reasons.

[kurkosdr]

VVC is getting momentum in living room devices already, and it is a big improvement over HEVC and AV1.

It doesn't enable any big high value content enabling features like HEVC did with HDR and 4K. HEVC was a particularly quickly adopted codec for those reasons.
Out of curiosity, do you have an example of those living room devices? The only devices I've seen it in are 8K "Ultra-Ultra-HD" TVs (which is a gimmick less well-received by the public than stereoscopic 3D with none of the cool factor).

I want to see VVC becoming a thing in the broadcast world (terrestrial and satellite) where content fees/royalties don't matter and the 16Mbps minimum that HEVC requires for a UHD stream is just too much considering how crowded most multiplexes are. For example, the few countries here in Europe that have terrestrial UHD broadcasts (France and Spain) have 2 UHD channels max.

But again, I don't see VVC going anywhere because it seems broadcasters have settled on HEVC for UHD.

[hajj_3]

But again, I don't see VVC going anywhere because it seems broadcasters have settled on HEVC for UHD.

broadcasters are using hevc because there aren't many/any vvc set-top boxes available. Once companies can buy set-top boxes at a low cost with vvc then countries upgrading from older codecs will choose vvc.

[benwaggoner]

broadcasters are using hevc because there aren't many/any vvc set-top boxes available. Once companies can buy set-top boxes at a low cost with vvc then countries upgrading from older codecs will choose vvc.
Brazil used VVC + LC-EVC for the 2022 World Cup, using a very fashion-forward STB.

Adding a VVC decoder isn't going to impact the cost of a STB by more than a couple of dollars.

[hajj_3]

Brazil used VVC + LC-EVC for the 2022 World Cup, using a very fashion-forward STB.

Adding a VVC decoder isn't going to impact the cost of a STB by more than a couple of dollars.

few chipsets have vvc. You can't buy a cheap hisilicon or mediatek soc with vvc for example.

[kurkosdr]

Brazil used VVC + LC-EVC for the 2022 World Cup, using a very fashion-forward STB.
VVC + LC-EVC? Do we happen to know resolution, bit-depth, fps, and the bitrate used for those?

Adding a VVC decoder isn't going to impact the cost of a STB by more than a couple of dollars.
Amen. There is no reason UHD TVs that cost at least several hundred dollars shouldn't have an SoC capable of decoding VVC. it's the same short-sighted thinking that has kept terrestrial broadcasts in countries like the UK and Australia largely on MPEG2 SD: Too many TVs were sold without MPEG4 HD decoding support even after MPEG4 HD decoding became viable with an SoC, and now there is political resistance to discontinuing those MPEG2 SD services. Something similar is playing out today, with non-8K UHD TVs supporting only HEVC (which as said previously above cannot fit that many UHD channels in a mux). Imagine if HD had settled on MPEG2 or MPEG4 ASP, how few HD services we'd have. That's what's happening at the moment with UHD and HEVC.

[birdie]

SoCs supporting VVC decoding have existed for quite some time now (for more than a year):

https://en.wikipedia.org/wiki/Versatile_Video_Coding#Hardware

[hajj_3]

SoCs supporting VVC decoding have existed for quite some time now (for more than a year):

https://en.wikipedia.org/wiki/Versatile_Video_Coding#Hardware

the allegro and verisilicon are only ip blocks not chips. The mediatek chips are tv chips not set-top box chips. Only the realtek is a set top box soc. realtek charges much more than the competition for their socs which is why few devices use them.

[ksec]

That is somewhat surprising, and disappointing.

Especially Qualcomm has already show case VVC Hardware decoding in their Smartphone prototype this year. So I was expecting that to be announced with Snapdragon Gen 3.

There is a possibility that VVC decoding is there but disabled for various sort of reason.

Ateme has just announced their H.266 encoder.

[benwaggoner]

VVC + LC-EVC? Do we happen to know resolution, bit-depth, fps, and the bitrate used for those?
It was covered in a session at the SMPTE Media Technology Summit last month. I can't find a downloadable link to it somehow. Maybe it wasn't posted?

This is a pretty detailed link about it: https://www.frontiersin.org/articles/10.3389/frsip.2022.884254/full

[Jamaika]

LCEVC Decoder SDK
https://github.com/v-novaltd/LCEVCdec

[hajj_3]

https://accessadvance.com/wp-content/uploads/2023/11/2023Q4-VVC-Patent-Diagram-11-01-23-1536x1152.jpg

[Yups]

Intels next gen low power mobile chip Lunar Lake supports HW VVC decoding.

https://abload.de/img/3wmibf.png
https://forums.anandtech.com/threads/intel-meteor-arrow-lunar-panther-lakes-discussion-threads.2606448/page-142#post-41110064

[birdie]

That's really great, hopefully AMD will follow with either RDNA 3.5 (thought I don't have any hope for it, it sounds like a minor upgrade) or RDNA 4.0.

And it now sounds unlikely that NVIDIA will add a decoder in Blackwell, aka the GeForce 50 series but I won't be surprised if they do.

What I find befuddling is that there's been no news about x266 which was promised to be released in H2 2023. We are less than six weeks before the year end.

[kurkosdr]

What I find befuddling is that there's been no news about x266 which was promised to be released in H2 2023. We are less than six weeks before the year end.

They can always pull a Morotola and release right before H2 2023 expires.

For those not in the know, Motorola promised a "summer launch of Android 2.2 for Droid X" and they kept to the letter of their word by releasing Android 2.2 for the Droid X literally on the last day of summer:
https://finance.yahoo.com/news/2010-09-21-motorola-droid-x-getting-android-2-2-update-starting-tomorrow.html

Just don't ask how many unresolved issues were swept under the rug to achieve that.

[Emulgator]

Intels next gen low power mobile chip Lunar Lake supports HW VVC decoding.

Unfanned 8W power consumption, fanned 17-30W, thanks TSMC.
This is a big power saving achievement for any desktop and notebook segment.

So one may call that mobile, but no-go for a phone.
We are talking about 1..2W max for decoding, so such CPU may not be suitable for a phone.
Other SoC makers will try to get a share of the production capacity of hopefully 60000 wafers/month,
and these may have to wait..Besides, I am not against VVC, only my hope is measured against reality.

[ksec]

Unfanned 8W power consumption, fanned 17-30W, thanks TSMC.
This is a big power saving achievement for any desktop and notebook segment.

So one may call that mobile, but no-go for a phone.
We are talking about 1..2W max for decoding, so such CPU may not be suitable for a phone.
Other SoC makers will try to get a share of the production capacity of hopefully 60000 wafers/month,
and these may have to wait..Besides, I am not against VVC, only my hope is measured against reality.

Where did the 1-2W VVC Decoding came from?

[Emulgator]

Requirement for recent mobile phone energy plans, not concerning VVC in particular, just any decoding consumption has to pass through that needle's eye.
The rest of the phone wants to eat too. Any CPU/GPU load, display brightness, wifi 5G, audio processing & amplification, vibration, AI...

An iPhone 15 is reported to consume 4,5W in total while gaming:
https://www.notebookcheck.net/Severe-Apple-iPhone-15-Pro-Max-thermal-throttling-reported-as-A17-Pro-appears-to-push-surface-temperatures-to-48-C-during-gaming.753143.0.html
BTW, I am not with the pseudo-critical tone, 4,5W for gaming is an achievement, given the processing complexity of the task.
and +48°C are to be expected to be fair, I only linked to show the wattage.
Lets keep those 4W as a ballpark figure of a mobile phone's max. total consumption

A Huawei P30Pro (Kirin980) may eat 3,5W while shooting AVC, a P40Pro+ (Kirin990) 4,0W while shooting HEVC
the 4200mAh, 3,7V accu yields 15Wh, 18hrs playback tell: maybe 1,2W on playback.
If any new codec wants to spend just double watts, then let's imagine the bashing reports:
"Ouch, The new uphone only lasts 50% the time. What went wrong ?"

The larger available mobile phone batteries are around 4000..4200mAh, with 3,7V you can calculate 14,8Wh,
and they can not be made any bigger.

[hajj_3]

November 21, 2023 – MainConcept, the leading provider of video and audio codecs, has announced the latest version of its real-time encoding application for OTT and TV broadcasting workflows, Live Encoder 3.4. It comes with two powerful additions, support for VVC/H.266 and MPEG-5 LCEVC and aims to transform the way in which broadcasters and OTT content providers distribute live video, streamline workflows, and elevate the overall viewing experience.

https://www.mainconcept.com/mainconcept-launches-live-encoder-3.4-with-vvc-and-lcevc

[benwaggoner]

Requirement for recent mobile phone energy plans, not concerning VVC in particular, just any decoding consumption has to pass through that needle's eye.
The rest of the phone wants to eat too. Any CPU/GPU load, display brightness, wifi 5G, audio processing & amplification, vibration, AI..
Sure. But from folks I've talked to, the VVC decoder requires less mm^2 of a SoC than AV1, and draws a little less power as well.

[Emulgator]

Compared to AV1, I concur.

[benwaggoner]

Compared to AV1, I concur.
MPEG has been pretty good at keeping the decoder complexity increase generation to generation down to about 2x. Which, given Moore's Law, makes each generation quite a bit cheaper to add to a SoC at launch.

[birdie]

A full native VVC decoder for ffmpeg (most likely GIT or version 6.1) has been posted (https://patchwork.ffmpeg.org/project/ffmpeg/patch/TYSPR06MB6433294423DE121C79F33D4AAA88A@TYSPR06MB6433.apcprd06.prod.outlook.com/).

I will test it next week when/if I make it home.

vvc decoder plug-in to avcodec.
split frames into slices/tiles and send them to vvc_thread for further decoding
reorder and wait for the frame decoding to be done and output the frame

Features:
+ Support I, P, B frames
+ Support 8/10/12 bits, chroma 400, 420, 422, and 444 and range extension
+ Support VVC new tools like MIP, CCLM, AFFINE, GPM, DMVR, PROF, BDOF, LMCS, ALF
+ 295 conformace clips passed
- Not support RPR, IBC, PALETTE, and other minor features yet

Performance:
Asm optimizations still working in progress. please check
https://github.com/ffvvc/FFmpeg/wiki#performance-data for the latest

Contributors(based on code merge order):
Nuo Mi <nuomi2021 gmail.com>
Xu Mu <toxumu outlook.com>
frankplow <post frankplowman.com>
Shaun Loo <shaunloo10 gmail.com>

vvdec by Fraunhofer HHI is quite heavy. I've recently encoded a 1024x576@30 video (here's a sample (https://mega.nz/file/PgNiwLzA#pIRNACUVTpD1xcbWlo0Il4p_vv2E5nE4l5c-1Y5_hno) or full video (https://mega.nz/file/C10zmRxC#61UNJIkdaLIbAYrbGy34OrF_iyukqAaL6Vj_hGp--Rc) for anyone who's interested) using preset slow and q=31 and my 7840HS consumes over 20W (!) decoding it which is just staggering. I'm pretty sure vvdec will fail to decode 1080p videos in real time on my Zen 4 CPU.

[FranceBB]

That's an amazing news! The moment FFMpeg gets an internal decoder, it spreads everywhere (LAV, VLC, MPV, LWLibav, FFVideo etc) so this is definitely welcome.
About VVDec, I remember having a conversation with Ben a while ago (several months actually) about decoding H.266 and I haven't tried it recently to see if there was any progress, but from what you're saying everything stayed the same.
If that's the case, although it might be "ok-ish" for desktop CPUs, it's definitely not for laptops and definitely not for smartphones as they're gonna need hardware decoding.
For comparison, back when I was talking to Ben about this, I tried a 50p realtime decoding of a FULL HD video on my 8c/16th Intel Xeon and I'm sure that if it had a face it would have looked at me and said "haha nice try bro". xD (TL;DR it couldn't).
The fact that ffvvc reports 200+ fps on a FULL HD 60p clip on a puny 8c/16th i7 like the 12700K shows a really great performance advantage compared to VVDec.
I mean, if that's the case, then software decoding might actually become a thing for H.266 VVC and that would definitely drive adoption 'cause after that all we need is x266 (hopefully also coming in 2024) and then we're ready to go.
That being said, I don't wanna be too harsh on Fraunhofer given that it has allowed me to test and try and test and try over and over again using VVEnc and VVDec, including working on some interesting samples last year, so, although we all knew it wasn't gonna make it into production, hats off to Fraunhofer for providing something better than the default unusable (i.e too slow) VTM reference encoder.

[Jamaika]

https://github.com/ffvvc/FFmpeg/commit/6e8865cea286c4373d60234f6963ce618b81f9fd
Modest VVC profile
const AVProfile ff_vvc_profiles[] = {
{ AV_PROFILE_VVC_MAIN, "Main" },
{ AV_PROFILE_VVC_MAIN_10, "Main 10" },
{ AV_PROFILE_VVC_MAIN_10_444, "Main 10 4:4:4" },
{ AV_PROFILE_UNKNOWN },
};
It plays great on very old computer only VVC 10bit. Bad movie rewind.
Stream #0:0: Video: vvc (Main), yuv420p10le(tv), 1024x576, 25 fps, 30 tbr, 1200k tbn
[vvc @ 000001784014c7c0] Duplicate POC in a sequence: 31.0B f=0/0
[vvc @ 000001784014c7c0] Error parsing NAL unit #3.

Stream #0:0: Video: vvc (Main), yuv420p(tv), 1920x1080, 25 fps, 29.97 tbr, 1200k tbn
[vvc @ 000001c476f1e8f0] frame 13, P( 29, 13) failed with -1094995529

I understand that uvg266 is a thing of the past. It isn't accepted.

[benwaggoner]

VVC is well designed for efficient decoding - factored well for good parallelism and SIMD. I've heard several experts estimate that a software decoder of equivalent optimization for VVC would give a higher decode fps than AV1. Real-world, AV1 encoders are several years ahead in performance optimizations, of course. But VVC should be at least as viable as AV1 for SW decode on phones etcetera.

[v0lt]

FFmpeg seems to have added a VVC decoder (https://github.com/FFmpeg/FFmpeg/commit/301ed950d1c3c500d0c2eee8472587dc5e691c04)

[birdie]

FFmpeg seems to have added a VVC decoder (https://github.com/FFmpeg/FFmpeg/commit/301ed950d1c3c500d0c2eee8472587dc5e691c04)

Hooray! Finally! I'm now compiling it.

The original git repo (https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/301ed950d1c3c500d0c2eee8472587dc5e691c04) is still where it used to be.

[birdie]

The native VVC decoder in ffmpeg is simply amazing! It's at least twice as fast/efficient as vvdec.

Unfortunately it doesn't (https://github.com/ffvvc/FFmpeg/issues/181) yet play some pretty standard VVC videos.

[ShortKatz]

I've build a version of Handbrake with the current FFmpeg and I was able to open one vvc file out of my vvc video sample collection. So it indeed does not play some pretty standard VVC videos.

[Jamaika]

The native VVC decoder in ffmpeg is simply amazing! It's at least twice as fast/efficient as vvdec.

Unfortunately it doesn't (https://github.com/ffvvc/FFmpeg/issues/181) yet play some pretty standard VVC videos.

He doesn't like mp4 because there is no mp4 plugin.
He doesn't like mp4 because there is no mp4 plugin.
Input #0, vvc, from 'NovosobornayaSquare_1920x1080_track1.vvc':/0
Duration: N/A, bitrate: N/A
Stream #0:0: Video: vvc (Main), yuv420p(tv), 1920x1080, 25 fps, 59.94 tbr, 1200k tbn
[ffplay_buffer @ 0000021583a827f0] filter context - w: 1920 h: 1080 fmt: 0 csp: unknown range: unknown, incoming frame - w: 1920 h: 1080 fmt: 0 csp: unknown range: tv pts_time: NOPTS
[ffplay_buffer @ 0000021583a827f0] Changing video frame properties on the fly is not supported by all filters.
[ffplay_buffer @ 0000021583a827f0] filter context - w: 1920 h: 1080 fmt: 0 csp: unknown range: unknown, incoming frame - w: 1920 h: 1080 fmt: 0 csp: unknown range: tv pts_time: NOPTS

Poorly created mp4 container. Incorrect framerate.
Video
ID : 1
Format : VVC
Codec ID : vvc1
Codec ID/Info : Versatile Video Coding
Duration : 10 s 0 ms
Bit rate : 4 008 kb/s
Maximum bit rate : 5 196 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 60.000 FPS
Bits/(Pixel*Frame) : 0.032
Stream size : 4.78 MiB (100%)
Title : bin@GPAC2.3-DEV-rev550-gec2a3776-master
Encoded date : 2023-09-28 14:25:08 UTC
Tagged date : 2023-09-28 14:25:08 UTC
mdhd_Duration : 10067
Codec configuration box : vvcC

Idea:
mp4box.exe -raw 1 NovosobornayaSquare_1920x1080.mp4
ffmpeg_avx.exe -i NovosobornayaSquare_1920x1080_track1.vvc -c:v copy NovosobornayaSquare_1920x1080_track1.mp4 (Jamaika codec)
Output #0, mp4, to 'NovosobornayaSquare_1920x1080_track1.mp4':
Metadata:
encoder : Lavf60.20.100
Stream #0:0: Video: vvc (Main) (vvc1 / 0x31637676), yuv420p(tv), 1920x1080, q=2-31, 25 fps, 59.94 tbr, 1200k tbn
Press [q] to stop, [?] for help
[mp4 @ 00000264b8266c10] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
[mp4 @ 00000264b8266c10] pts has no value
Last message repeated 336 times
[mp4 @ 00000264b8266c10] pts has no valued=N/A
Last message repeated 262 times


It's already playing something. :)

[FranceBB]

It's at least twice as fast/efficient as vvdec.

I've been testing it too but although it does appear to be faster, it's not quite twice as fast compared to VVDec.
I'm currently sick at home and confined to bed (seasonal flu), but I'll make some more tests once I get better.
Just to be sure, do you have a particular file you tested it on where decoding was twice as fast? I wanna try it on my 8c/16th Xeon to see if the results you're getting are hardware dependent.

[birdie]

I've been testing it too but although it does appear to be faster, it's not quite twice as fast compared to VVDec.
I'm currently sick at home and confined to bed (seasonal flu), but I'll make some more tests once I get better.
Just to be sure, do you have a particular file you tested it on where decoding was twice as fast? I wanna try it on my 8c/16th Xeon to see if the results you're getting are hardware dependent.

The situation is quite complicated.

vvdec by itself is several times faster than the native VVC decoder in ffmpeg however the patch to integrate vvcdec into ffmpeg results in its performance advantage disappearing and getting even worse than native which sounds like the patch does something wrong.

I've described everything here (https://github.com/fraunhoferhhi/vvdec/issues/158#issuecomment-1875915496).

[FranceBB]

Ahhhhhh! Gotcha! Makes sense now.
Well I didn't know it was faster 'cause I always used it via the FFMpeg integration. This is interesting.
I think I have to redo all the tests with the native VVDec now and report back here, I'll keep you guys posted.

[hajj_3]

vvc datacentre decoder ip block: https://www.verisilicon.com/en/IPPortfolio/HantroVC9800D

it supports lots of other codecs too.

[Blue_MiSfit]

There's no mention of VVC on those marketing pages :)

[hajj_3]

There's no mention of VVC on those marketing pages :)

there is on the decoder one. i mis-read the encoder page though.

[v0lt]

Nightly builds of MPC-BE (https://github.com/Aleksoid1978/MPC-BE/wiki/Nightly-builds) can decode some VVC videos in MP4 container. There is also support for MPEG-TS and RAW, but this is more problematic.

[birdie]

vvdec has been updated to make it more than three times more energy (https://github.com/fraunhoferhhi/vvdec/issues/158#issuecomment-1898655263) efficient when it's being used as a decoding backend for ffmpeg (and other libs/apps using it) thanks to my input :-)

[benwaggoner]

vvdec has been updated to make it more than three times more energy (https://github.com/fraunhoferhhi/vvdec/issues/158#issuecomment-1898655263) efficient when it's being used as a decoding backend for ffmpeg (and other libs/apps using it) thanks to my input :-)
Well done!