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

[benwaggoner]

II'm surprised not to see you at the zoom meeting, Ben.

My scope is really anything between lens to cornea and mic to eardrum these days, so I'm always terribly neglecting two things whenever I'm paying attention to one ;).

[DTL]

No mention of CUDA in the slides, just a very vague "GPU hardware acceleration" as things that will be looked into, so I asked the question myself on whether it will be OpenCL or other open initiatives

As from some version of Microsoft DX12 at the beginning of 202x the motion estimation data from hardware MPEG encoder ASIC is now available as operation system API service (AMD/NVIDIA and in some time Intel accelerators independent) I hope the designers of MPEG codecs may finally start to use it. At least as some starting point of motion estimation with possible onCPU refinement. Though even in its initial release ME API have full mature precision of 1/4 pel. The progress may be with quality of motion vectors in the future ASIC releases (more correct MVs with naturally noised sources and many-frame analysis instead of current 2-frames only).

[birdie]

FOSDEM 2023 VVEnc/VVDec presentation:

https://www.phoronix.com/news/Open-Source-VVC-H266

[birdie]

A patch series to support vvdec in ffmpeg has been submitted (https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230210174106.44514-2-thomas.ff@spin-digital.com/) for the third time.

[FranceBB]

A patch series to support vvdec in ffmpeg has been submitted (https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230210174106.44514-2-thomas.ff@spin-digital.com/) for the third time.

And knowing the AV1 fanboys in the ffmpeg community, it will probably be rejected again, although I sincerely hope that it won't. I even tried to reach out to them everywhere before, but I couldn't convince them...

[birdie]

And knowing the AV1 fanboys in the ffmpeg community, it will probably be rejected again, although I sincerely hope that it won't. I even tried to reach out to them everywhere before, but I couldn't convince them...

They [ffmpeg project] don't have the manpower to review the patches. That's the only reason they've not been merged. They have not been rejected.

I want to compile the upcoming FFMPeg 6.0 release with these patches and start experimenting with VVC a lot more. I love the codec ;-)

[quietvoid]

I'm not sure but I think the reason is mostly that a native decoder in FFmpeg is preferable, and it is already an ongoing project.
So there isn't much point to adding vvdec, at least IMO.

[nevcairiel]

And knowing the AV1 fanboys in the ffmpeg community, it will probably be rejected again, although I sincerely hope that it won't. I even tried to reach out to them everywhere before, but I couldn't convince them...

You really have no clue what you are talking about.

None of these patches were ever actually "rejected" at all, having a large patch set go through various iterations is entirely normal part of development, as reviews point out problems and improvements. This is just how the development process works. Large patchsets rarely get merged on the first try, even less so if they are from external contributors or companies, since those don't necessarily know all the details to make it work perfectly without review. It may be going slow as review bandwidth is limited, but there certainly was no rejection, and just the normal development process going on.

And as pointed out above, a native VVC decoder for ffmpeg is actually in development as well, independent of vvdec or other external libraries.

Contrary to some other projects, development of new features does not happen inside the main ffmpeg tree. So unfinished/in-progress things don't just get merged unless they are considered "finished", at least to a degree of being usable and not making future changes harder.

[birdie]

I'm not sure but I think the reason is mostly that a native decoder in FFmpeg is preferable, and it is already an ongoing project.
So there isn't much point to adding vvdec, at least IMO.

FFMpeg developers themselves are not aware of this development. No idea where you got this information from.

I've not seen a single development tree/tag/branch with anything VVC decoding related either.

[nevcairiel]

FFMpeg developers themselves are not aware of this development. No idea where you got this information from.

I've not seen a single development tree/tag/branch with anything VVC decoding related either.

Not sure what "FFmpeg developers" you are talking to, but if they were of the active kind, they surely would have noticed this project on the mailing list.

The development tree is here:
https://github.com/ffvvc/FFmpeg

Its still quite under development and not finished yet, but should be somewhat usable.

There is also a GSoC 2023 project (https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2023#AssemblycodeforVVCdecoder) listed to enlist a student to help with writing Assembly for it, as well as a general task to get involved with work on it, if you need any more "evidence" that its a real thing endorsed by the FFmpeg project itself.

[FranceBB]

Perhaps, Nevicarel, but from my own experience of ffmpeg contributions, they're left hanging there and not merged without any real explanation on why. Just to name one, I've been waiting for them to merge this for 6 months now and no one replied to my emails and in the ticket there's only someone who uses the nickname Elon Musk (almost definitely not the *real* Elon Musk) which says "No" without providing any details. https://trac.ffmpeg.org/ticket/9864
Nicolas already asked too and yet, nothing.
This led us to actually include the patch ourselves and compile a custom version of FFMpeg, thus running a completely separate version from the rest of the world, which isn't nice of course.
And by the way, yes, we're running that very custom version in production 24/7.
What does that patch do?
It allows DolbyED2 5.1.4 decoding and fixes a decoding error in DolbyE 5.1 in which the decoded audio was slightly shorter than it should have been.
Why they refused it? Dunno.

comment: by Francesco Bucciantini
So... any chance of any of the patches being merged to master anytime soon?

comment by Elon Musk
Nope

Here I've also been blatantly ignored:


comment: by Francesco Bucciantini
Hi everyone,
happy new year.
As you can see this pull request has been stagnating for the last 6 months, forcing us at Sky to build our own FFMpeg with the patch applied.
We've been trying to contact the current maintainer via email on different occasions, but we never had an a reply.
Is there any other maintainer we can talk to?
Thank you in advance,
Frank

so I've now lost faith... :(
My comment might have seemed a bit unfair at a first glance and if I upset someone, I apologize, but believe me, this is a bit frustrating for us as well 'cause I always get nice feedback and collaboration from everyone here on Doom9, especially in the Avisynth community, so when I went to ask a bunch of stuff to the FFMpeg community I thought it was gonna be the same, but apparently it's not...
If you DO know maintainers in the FFMpeg community and you do actually care about the progress of the whole project, then please, for the sake of avcodec, allow me to talk to them and ask for an explanation or at least to take it into consideration so that we can change/adjust the patch and provide some feedback to Nicolas, otherwise we're all losing time for nothing.
For us, DolbyE and DolbyED2 decoding is something very important which we do on a daily basis.
I know that it might not be important for some people, but for some other it's a vital thing to have and work properly.
I mean, you're the developer of LAV filters, after all, aren't you? (Which I use, by the way, so thanks for that too) So if avcodec becomes better it's also gonna be a good thing for LAV, right? :)

[birdie]

Not sure what "FFmpeg developers" you are talking to, but if they were of the active kind, they surely would have noticed this project on the mailing list.

The development tree is here:
https://github.com/ffvvc/FFmpeg

Its still quite under development and not finished yet, but should be somewhat usable.

There is also a GSoC 2023 project (https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2023#AssemblycodeforVVCdecoder) listed to enlist a student to help with writing Assembly for it, as well as a general task to get involved with work on it, if you need any more "evidence" that its a real thing endorsed by the FFmpeg project itself.

Woah, that looks amazing. A single person endeavour so far but it's quite active.

[FranceBB]

Woah, that looks amazing. A single person endeavour so far but it's quite active.

that was my same reaction.
I have no idea who nuomi2021 is, but looks like he's doing everything on his own with 130 commits O_O

[birdie]

BTW, I wasn't too wrong: development (of ffmpeg's own VVC decoder) started (https://github.com/ffvvc/FFmpeg/commit/58adf8866bc1f4e564dac39e64fd14b2ec937e3e) only on January 14th, 2023, i.e. just a month ago.

[nevcairiel]

Thats when the first version was published, you don't stamp that much out in a day. Some of the code has a 2021 copyright header. Not that people can't make mistakes in putting those in, and without the author telling us its impossible to know, but I would bet a good part of 2022 was this already being worked on.

[birdie]

Thats when the first version was published, you don't stamp that much out in a day. Some of the code has a 2021 copyright header. Not that people can't make mistakes in putting those in, and without the author telling us its impossible to know, but I would bet a good part of 2022 was this already being worked on.

Regardless it's great it's being worked on, albeit it seems like it's too late. The format was finalized over two years ago.

[benwaggoner]

Regardless it's great it's being worked on, albeit it seems like it's too late. The format was finalized over two years ago.
A couple-three of years from standardization to practical real-world use is pretty standard. Encoders need to be made and tuned, decoders need to be designed and shipped in products, etc.

HEVC was standardized in 2013 and didn't see much use until 2015. And since it was pretty much required to do practical 4K and HDR, there was a lot more appetite to use it an an early stage of development. Broad use of HEVC for 1080p SDR stuff was more around 2017.

VVC is a great codec, but there isn't some huge new market it enables like HDR, so implementers are more inclined to wait until it is end-to-end capable of handling current scenarios at much lower bitrates.

[rwill]

VVC is a great codec, but there isn't some huge new market it enables like HDR, so implementers are more inclined to wait until it is end-to-end capable of handling current scenarios at much lower bitrates.

From what I remember VVC was positioned as the codec to enable 8k. I guess there is just not that much demand for that amount of pixels currently, except for maybe 360° videos or similar.

Maybe 1080p HDR is enough for the viewing setup most people have anyway...

[FranceBB]

From what I remember VVC was positioned as the codec to enable 8k. I guess there is just not that much demand for that amount of pixels currently


Could be.
Japan also seems to be the only country currently broadcasting 8K contents (mostly documentaries or opera concerts), while other countries have only done sporadic tests on single events. They (the Japanese) even went to Milan to record at the "La Scala" theatre in Italy (its English meaning would be "The stair") and they didn't need any external help. They had their own cameras, lenses, video mixers, ingest, etc and I'm told they did everything on their own. Unfortunately I couldn't see any of that 'cause I wasn't invited... :(
Anyway, they're airing in H.265 mostly 'cause there aren't yet any widespread hardware encoder for H.266 VVC nor hardware decoders in commercial set-top-boxes or TVs. It would be interesting to know if they have any plan to switch to H.266 VVC once it becomes widely available, but unfortunately I don't know anybody at NHK to ask that... :(

On top of that, I also don't live anywhere near the footprint of BSAT 4A 110.0°E 11977 nor have an H.265 8K compatible receiver to get the NHK BS 8K feed either :(

https://sky-brokers.com/wp-content/uploads/2021/02/BSat-4a-Ku-band-coverage-500x333.png

[olduser217]

Could be.
Japan also seems to be the only country currently broadcasting 8K contents (mostly documentaries or opera concerts), while other countries have only done sporadic tests on single events. [/IMG]

China has an 8K channel since January 2022, using China AVS3 though.

https://zh.wikipedia.org/wiki/%E4%B8%AD%E5%A4%AE%E5%B9%BF%E6%92%AD%E7%94%B5%E8%A7%86%E6%80%BB%E5%8F%B08K%E8%B6%85%E9%AB%98%E6%B8%85%E9%A2%91%E9%81%93

[benwaggoner]

From what I remember VVC was positioned as the codec to enable 8k. I guess there is just not that much demand for that amount of pixels currently, except for maybe 360° videos or similar.
Yeah, 4K YUV pixels appears to be sufficient to saturate the human visual system at a viewing distance where the viewing angles to the sides of the screen are acceptable.

Maybe 1080p HDR is enough for the viewing setup most people have anyway...
For a lot of people it will be enough, and it's generally enough for SDR. HDR benefits more from higher resolutions as it can have way higher local contrast. I think 1440p would have hit perceptual saturation for SDR.

[Balling]

ticket there's only someone who uses the nickname Elon Musk (almost definitely not the *real* Elon Musk)

That is Paul B Mahol aka richardpl. almost is the keyword here, I am not sure it is even his real name.

[FranceBB]

By the way, thank you, Balling for letting me know that pinging the mailing list is normal. I tried again, let's see how it goes this time. I mean, in the whole ticket you seem to be the only one who replied and actually cared...
Hopefully the question and reply between me and you there will keep it up in the list until some of the maintainers will care...

[LigH]

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

VTM Encoder/Decoder Version 19.2 (https://www.mediafire.com/file/q8wdc6ov1lr0ozy/VTM_19.2_2a4ebfe9.7z/file) 2a4ebfe9

Fraunhofer VVC Encoder ver. 1.7.0 (https://www.mediafire.com/file/2ir8lq1ah0ji1la/vvenc_1.7.0-4d3db39.7z/file) 4d3db39

Fraunhofer VVC Decoder ver. 1.6.1 (https://www.mediafire.com/file/z1sg9wxfyt0nsp8/vvdec_1.6.1-36a6d13.7z/file) 36a6d13

[~ VEGETA ~]

is there any concise explanation of how VVC\H266 works? not too detailed and technical, similar to HEVC explanation in HEVC forums.

also, is it supported in mpv or so yet?

[FranceBB]

is there any concise explanation of how VVC\H266 works?

Well, for those who can read in Italian I explained it in one of my academic papers here: Link (https://view.publitas.com/p222-8308/francesco-bucciantini-utilizzo-delle-trasformate-nella-codifica-delle-immagini-fisse-in-movimento-ed-audio/page/150) (There are also pictures ehehehehe).

however since this is an English-speaking forum, I'll translate a few lines of what I wrote:


The new codec was developed starting from H.265 but introduced new encoding techniques and new optimizations; for instance prediction and motion-compensation were improved and concepts like Prediction Unit (PU) and Transform Unit (TU) have been removed. The main difference between H.265 and H.266 is that the first uses a Quad-Tree (QT) structure, while the second uses an MTT partition structure which includes the QT. In H.265 each frame is divided in several CTU (Coding Tree Unit). Each CTU has a block of luma and two blocks of chroma with corresponding sizes. The maximum size available for the luma block is 128x128 and the maximum for the chroma is 64x64. Besides, only the QT partition type is available for H.265, which limits the shape of the sub-CU to a square. In H.266 we have instead the MTT partition structure which includes 5 structures: BT_H (Horizontal Binary Tree Partition), BT_V (Vertical Binary Tree Partition), TT_H (Horizontal Ternary Tree Partition), TT_V (Vertical Ternary Tree Partition) and QT. Among them, the size ratio of the 3 parts in the partition structure is 1:2:1. The MTT partition structure allows the CU to be partitioned in an asymmetric way.


There are lots of other things to talk about like the transform used, plenty of new coding tools etc, but I can't translate my whole paper to English.

I'm pretty sure there are lots of very valid articles in English across the internet, but if you can't find any and you're curious, I think Google Translate *should* be able to translate my paper to English automatically for you. ;)


EDIT: Wait, perhaps you meant how the Fraunhofer's VVC Encoder works and not how the VVC/H.266 codec works? If that's the case, just take a look at our discussion from a while ago here: https://forum.doom9.org/showthread.php?t=174940&page=24

and you can start from a base cmd of:

ffmpeg.exe -i "AVS Script.avs" -strict -1 -an -f yuv4mpegpipe - | vvencapp.exe -i - --preset medium --format yuv420 --bitrate 25000 --profile auto --level 5.0 --passes 1 --output "VVC.h266"

pause

and then experiment



also, is it supported in mpv or so yet?


Yes... No... It's complicated.
Yes if you compile with a custom patch.
No if you use the standard binaries automatically compiled from the latest master.
Also, MPV leverages on FFMpeg and the best software decoder we have right now is VVDec but the patch to integrate it to master has been rejected by the FFMpeg devs 3 times. A friend of mine went to the last convention in person and said that it's coming so... if it wasn't "3rd time lucky" it will probably be "4th time lucky", but in the meantime one guy is also developing his own decoder within libav so that decoding won't depend on Fraunhofer (the author of VVDec) but rather be integrated within the other decoders, so now we don't know whether they're gonna wait for it and integrate it instead of VVDec or whether they're gonna integrate VVDec first and then replace it with the libav implementation or if they'll just keep both.

As I said, it's a mess.

[~ VEGETA ~]

thanks for your quick response.

I appreciate if you can write a new thread putting some very basic not-so-technical brief explanation. I know it is hard but it is not like writing technical papers, just specifying stuff so we can understand how the codec works and why it is hugely better than hevc despite using the same method of motion-estimation, referencing,etc..

I don't think any encoder\decoder is usable now, we need years.

[Dann0245]

thanks for your quick response.

I appreciate if you can write a new thread putting some very basic not-so-technical brief explanation. I know it is hard but it is not like writing technical papers, just specifying stuff so we can understand how the codec works and why it is hugely better than hevc despite using the same method of motion-estimation, referencing,etc..

I don't think any encoder\decoder is usable now, we need years.

There is a MPV mod which uses vvdec for decoding VVC. https://github.com/MartinEesmaa/VVCEasy/blob/master/MPV.md#download-mpv-windowsandroid-player-libvvdec--xhe-aac-plugin
VVdec performance is not good as (AV1) dav1d decoder, but that is the only VVC playable right now.

VVC samples:
https://drive.google.com/drive/folders/1JK1-k2_EfcgvQgQDzWRmBw7VgQLBaNI4
https://www.isize.co/portfolio/demo2/
https://www.dropbox.com/s/v5oforc2nqqul8v/MOS__VVC_HEVC_1.8m_3.0m_Oct16_2019.zip?dl=0

[LigH]

To be of practical use, ffmpeg and related projects would also need to detect a VVC stream inside containers like MP4; but nobody really takes my bug report serious, yet, although it should be a small task, compared to implementing a whole decoder.

[FranceBB]

nobody really takes my bug report serious, yet

if it can make you feel any better, they've been actively ignoring me as well...

[birdie]

The SpinDigital latest/last VVC patch series allows ffmpeg to encode and decode (read play in mpv) VVC/H.266 but it's not complete yet.

For instance I couldn't mux an elemental H.266 stream with AAC audio into mkv but it worked for mp4 (or was it vice versa - I don't remember now).

Also, VVC decoding [using vvdec] requires a lot of CPU resources - it's comparable to software decoded AV1.

vvdec really could use more optimizations.

If anyone's interested I can upload/share my ffmpeg/mpv builds for Fedora 37 x86_64. Don't ask for your own distro build as I'm on vacation now and my laptop is not suitable for firing up VMs with your favourite distro, let alone building software.

[FranceBB]

It's your lucky day, Artem, 'cause I'm on Fedora xD

[Jamaika]

For instance I couldn't mux an elemental H.266 stream with AAC audio into mkv but it worked for mp4 (or was it vice versa - I don't remember now).
Now I see. The funny thing now is that the unfinished decoder is on ffvvc. The MP4 decoder bass plugin for all VVC codecs was made by Martin. When it connects, muxer/demuxer should work thearetically. :D

[birdie]

It's your lucky day, Artem, 'cause I'm on Fedora xD

mpv / ffmpeg with VVC decoding support for Fedora 37 (https://mega.nz/file/rk0DkLqa#ZUcCmpIEB-3rDGI4ckk7gOeOGjgFQ9L-Ho4BStHCuQs).

The installation instructions are in the archive.

sha256sum ffmpeg+mpv-with-vvc-decoding-support-f37.tar.xz
c6fc12b058da084e2695a01e6ac595f5f57bb4c6bc2d3864c0e065531cd79dc0 ffmpeg+mpv-with-vvc-decoding-support-f37.tar.xz

[FranceBB]

Thank you! :D
Tested right up and it's actually working on my Fedora 37 ;)

[birdie]

Thank you! :D
Tested right up and it's actually working on my Fedora 37 ;)

Could you test 4K 60fps video playback? Specifically this (https://www.elecard.com/storage/video/NovosobornayaSquare_3840x2160.bin) one? Other (https://www.elecard.com/videos) clips.

Can your rig play it without dropping frames? ;-) Press Shift + I too see the statistics - most importantly "Dropped frames".

My Core i5 6200U can barely handle a 1080p clip. Near 100% CPU use and almost zero headroom.

[Jamaika]

Test ffmpeg + vvc
ffmpeg.exe -i "iphone6s_4k.mov" -c:v libuvg266 -vb 3000k -c:a ac3 -ac 2 -ab 128k -s 1920x1080 -frames 100 -pix_fmt yuv420p output_uvg266.mts --> OK
ffmpeg.exe -i "iphone6s_4k.mov" -c:v libuvg266 -vb 3000k -c:a ac3 -ac 2 -ab 128k -s 1920x1080 -frames 100 -pix_fmt yuv420p output_uvg266.mov --> decoder ffvvc + vvc_mp4toannexb_bsf.c MartinEesmaa Error {no header}
ffmpeg.exe -i "iphone6s_4k.mov" -c:v libuvg266 -vb 3000k -c:a ac3 -ac 2 -ab 128k -s 1920x1080 -frames 100 -pix_fmt yuv420p output_uvg266.mkv --> no file

ffmpeg.exe -i "iphone6s_4k.mov" -c:v libxeve -vb 3000k -c:a ac3 -ac 2 -ab 128k -s 1920x1080 -frames 100 -pix_fmt yuv420p output_xeve.mts --> no file
ffmpeg.exe -i "iphone6s_4k.mov" -c:v libxeve -vb 3000k -c:a ac3 -ac 2 -ab 128k -s 1920x1080 -frames 100 -pix_fmt yuv420p output_xeve.mov --> OK
ffmpeg.exe -i "iphone6s_4k.mov" -c:v libxeve -vb 3000k -c:a ac3 -ac 2 -ab 128k -s 1920x1080 -frames 100 -pix_fmt yuv420p output_xeve.mkv --> no file

ffmpeg.exe -f avs3 -i "SFTI_1920x1080.bin" -c:v libx264 -vb 3000k -an -s 1920x1080 -pix_fmt yuv420p output_x264.mov --> error {no frames}
ffmpeg.exe -f vvc -i "NovosobornayaSquare_1920x1080.bin" -c:v libx264 -vb 3000k -an -s 1920x1080 -pix_fmt yuv420p output_x264.mov --> error {no file}
[vvc @ 0000025b0ee2b5f0] No start code is found.
[vvc @ 0000025b0ee2b5f0] Error splitting the input into NAL units.

[benwaggoner]

Also, VVC decoding [using vvdec] requires a lot of CPU resources - it's comparable to software decoded AV1.

vvdec really could use more optimizations.
Honestly "comparable to SW AV1" is a pretty big accomplishment this early in VVC's life cycle, and speaks to a real good job of balancing decoder cost/complexity with compression efficiency gains.

AV1 is a bear to implement in hardware.

[hajj_3]

VeriSilicon delivered multi-format hardware video decoder Hantro VC9000D supporting 8K@120FPS VVC/H.266 to customers

source: https://www.verisilicon.com/en/PressRelease/HantroVC9000D

[FranceBB]

Could you test 4K 60fps video playback?

Dude, you wanna kill my CPU? XD

Jokes aside, I run Fedora on my personal computer at home, so it's not really powerful like the Intel Xeon workstations I have at work (20c/40th) or the servers I have there (56c/112th), it's just a puny little i7 6700HQ with 4c/8th at 2.60GHz and no AVX-512 just AVX2 (yes, it could go higher like 3.5GHz single core or 3.2GHz all cores, but it would start throttling like crazy, so...)
I use it mainly to read my email, browse the internet, post random stuff on Doom9, Facebook, Linkedin, occasionally watch YouTube (mainly Sky News or Linus Tech Tips) etc.
I mean, all very basic stuff.


Anyway, FULL HD H.266 VVC playback, no problem, but with UHD 60p it was begging me to pull the plug as it just wanted to die at 95°C, all cores 100%.


TL;DR no, I cannot play UHD 60p H.266 VVC without dropping frames on a 4 core laptop (nor I expected to).

Honestly "comparable to SW AV1" is a pretty big accomplishment this early in VVC's life cycle

It's not comparable, by the way.
In my test AV1 is lighter than H.266 VVC, probably because they had a lot of time to optimize software decoding.

[birdie]

Dude, you wanna kill my CPU? XD

Jokes aside, I run Fedora on my personal computer at home, so it's not really powerful like the Intel Xeon workstations I have at work (20c/40th) or the servers I have there (56c/112th), it's just a puny little i7 6700HQ with 4c/8th at 2.60GHz and no AVX-512 just AVX2 (yes, it could go higher like 3.5GHz single core or 3.2GHz all cores, but it would start throttling like crazy, so...)
I use it mainly to read my email, browse the internet, post random stuff on Doom9, Facebook, Linkedin, occasionally watch YouTube (mainly Sky News or Linus Tech Tips) etc.
I mean, all very basic stuff.


Anyway, FULL HD H.266 VVC playback, no problem, but with UHD 60p it was begging me to pull the plug as it just wanted to die at 95°C, all cores 100%.


TL;DR no, I cannot play UHD 60p H.266 VVC without dropping frames on a 4 core laptop (nor I expected to).



It's not comparable, by the way.
In my test AV1 is lighter than H.266 VVC, probably because they had a lot of time to optimize software decoding.

LOL. OK ;-) Thanks.

Yeah, sorry, I stand corrected, currently software VVC decoding using VVdeC is considerably more CPU intensive than AV1 decoding.

Sorry for misleading people earlier. My Ryzen 7 5800X chewed VVC 4K 60fps no problem and I didn't quite pay attention to power consumption or CPU usage. It must have been a lot higher than AV1.

[birdie]

From the lead Fraunhofer HHI VVC developer, Adam Wieckowski :

AV1 decoding is really much more optimized. The dav1d decoder has more lines of assembly code than Linux kernel. We don't have the knowledge or the resources to put in this kind of work.

To be fair, the best way to improve vvdec right now would be to rewrite it, because the performance is bound by the software structure that we inherited from VTM, even if heavily optimized. And we are not going to do this. We are still working on minor improvements, but don't expect really big leaps for vvdec anytime soon. ffvvc might someday be more efficient than vvdec, but by that time I expect HW support to be fairly broad.

The only bigger thing being worked on right now is the error resilience.

[FranceBB]

My Ryzen 7 5800X chewed VVC 4K 60fps no problem

ehehehe that's an 8c/16th 3.8GHz (max 4.7GHz) desktop CPU from 2020, no wonder it managed to decode it unlike my 4c/8th 2.6GHz laptop CPU from 2015 :P

Even benchmark values here get to the point of ridiculous in favor of your desktop CPU xD Intel i7 6700HQ vs AMD Ryzen 7 5800X (https://cpu.userbenchmark.com/Compare/Intel-Core-i7-6700HQ-vs-AMD-Ryzen-7-5800X/m34954vs4085)

[benwaggoner]

Sounds like we need the dav1d equivalent for VVC. Aomdec was similar to the Fraunhofer work here: optimizing the reference decoder, but not attempting to build a ground-up performance optimized decoder for real-world use.

[LigH]

From the lead Fraunhofer HHI VVC developer, Adam Wieckowski :

Does this quote have a shareable source?

[birdie]

Does this quote have a shareable source?

This (https://github.com/fraunhoferhhi/vvdec/issues/132#issuecomment-1479376672).

[DTL]

From the lead Fraunhofer HHI VVC developer, Adam Wieckowski :

Simple (and cheap to develop) C-reference implementation may be only for quality comparison. It will be truly free opensource working demo of a new codec. Github friendly. And to show the benefit from new version in compare with old products. For general industry it may be completely zero reason to invest into SIMD-optimized very hard to develop implementation for general purposes CPUs with SIMD co-processors just to make freeware version with no commertial benefit. For the quickly shrinking number of PC real users. The commertial developemnt is oriented into real market with real number of users to get money. May you can found ASIC for VVC decoding in some new smartphone in a few months later and it will outperform many massively-multicore expensive Xeons.

If codec will be accepted by industry it will be implemented in ASIC with all requirement performance for enduser setup (set-top-box or internal display decoder or a chip for handheld smartphone and so on).

[birdie]

VVenC 1.8 has been released (https://github.com/fraunhoferhhi/vvenc/releases/tag/v1.8.0).

Changes over v1.8.0-rc1

deprecated obsolete chroma QP control mechanism (to be removed in the next release)
removed deprecated parameters for partitioning control


Changes over v1.7.0

vvencFFapp removed from default installation
Speedups (~15% for faster/~5% for slower/~10% for other presets)
Improved error messages
Added temporal ALF APS prediction, closing the efficiency gap between single- and multi-threaded operation
Extended BIM by extrapolating parameters to non MCTF-filtered frames
Various fixes
Usability improvements
Various improvements

[MartinEesmaa]

I just want to let note, that I updated new FFmpeg master and MPV with VVCEasy new builds. I tried ffvvc in Windows, but it was error, so I switched from ffvvc to external VVC decoder of my own repository.

https://github.com/MartinEesmaa/VVCEasy/commit/39f09eda995163bfa3d47df0fbacc45942bb0420
https://github.com/MartinEesmaa/VVCEasy/commit/b60990621852cb62eb82142055eff0809530813e

- Martin Eesmaa

[Gravitator]

Всем привет!
Martin Eesmaa, help?
ffmpeg -i space_6s.mkv -f yuv4mpegpipe - | vvencapp --y4m -i - --fps 24000/1001 --preset fast -q 30 -o y4m.266
av_interleaved_write_frame(): Broken pipe
[out#0/yuv4mpegpipe @ 000001fdd23bac00] Error muxing a packet
[out#0/yuv4mpegpipe @ 000001fdd23bac00] Error writing trailer: Broken pipe

> sample (https://files.videohelp.com/u/227452/space_6s.mkv)