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

[Jamaika]

I don't know how it is in the US, but in the EU popularization and lack improvement MP4 codec is justified by company patents and legal acts RODO or ACTA2. New codec AV1 in mp4 - ok, but codec description is limited and archaic. Is the description recommended for processed video? Not recommended.
Card payments were reluctantly introduced in logistics in the era of KV. And it turned out that nobody don't want to pay in the KV era. GPS in the movie, money and crazy vacations. It's tax proof on the tray. What youtube or facebook?
The MKV container is considered by many companies as a pirate that has ruined DVD / Bluray. Great that it has extra subtitles, other functions. Unfortunately, it is for amateur programs.
What will the MP5 be like? I have no illusions as a layman. The MP5 will be an even more encrypted container for fast tracking by security systems.
Will MKV contain MPEG5 container under VVC ??? How should I know, but it probably won't be free.

[birdie]

News: x266 is already in development:

MulticoreWare announces the formation of x266 consortium and development of an open source code for VVC encoding is already underway. Similarly, MulticoreWare’s x265 consortium led the development of the open source code x265 for HEVC based encoding and become the mmost widely used HEVC encoding software.

Application areas of x266 will include encoding High Definition(HD) and Ultra High Definition(UHD- 4K and 8K) video for broadcasting, live streaming, Over The Top(OTT) video distribution, Adaptive Bit Rate(ABR) streaming, video storage and archiving, surveillance, screen content sharing, video teleconferencing, video games, eSports, immersive media such as 360-degree video, Virtual Reality (VR) etc.

x266 will be able to encode video with Standard, High Dynamic Range and Wide Color Gamut. It will also offer a user flexibility to trade-off speed of encoding with coding efficiency. Initial version of the x266 software will support single layer coding of 10 bits video with 4:2:0 chroma format. More advanced versions will support multilayer coding, higher than 10 bits depth video and higher than 4:2:0 chroma formats.

[Greenhorn]

non-reference (?) VVC implementation by Fraunhofer HHI:

https://github.com/fraunhoferhhi/vvenc

Seems to be in a very early state.

Offers a simple encoder with 4 presets and one tuning option, and multithreading, but no screen-content features, together with a complex encoder which seems to be a re-implementation of the VTM.

[Jamaika]

Originally Posted by Greenhorn

non-reference (?) VVC implementation by Fraunhofer HHI:

https://github.com/fraunhoferhhi/vvenc

Seems to be in a very early state.

Offers a simple encoder with 4 presets and one tuning option, and multithreading, but no screen-content features, together with a complex encoder which seems to be a re-implementation of the VTM.

Thanks for the info. Does this library have any JVETVVC history? Threads added.

Edit:
Added encoder VVEncoderApp.exe:
VVEncoderApp.exe --preset medium -i 111.yuv -s 1280x720 -t 4 -b 3000 -o str.266
Strange. Encoder isn't compatibile with Elecard StreamEye 4.5.974.
Time consuming coding problem. The encoder and decoder have to be created separately.
I don't know can user create any GOP?
https://www.sendspace.com/file/tjn6vy

[hajj_3]

There is a test transmission on a european satellite for a VVC broadcast: https://www.digitalbitrate.com/dtv.p...&sec=0&lang=en

[Jamaika]

I've been using GPAC MPEG4 very little lately. I noticed that 'initial tests for VVC support' has been added under OPENVVC.
I wonder. Will VVC be possible to import into MPEG4 container or become MPEG5 container?
https://github.com/gpac/gpac/commit/...87924b47e2ba3e

[FranceBB]

Originally Posted by hajj_3

There is a test transmission on a european satellite for a VVC broadcast: https://www.digitalbitrate.com/dtv.p...&sec=0&lang=en

Yep.
Astra 2E (28.2 ° E) tp. 14 (11.973 GHz, pol. V, SR: 31000, FEC: 9/10; DVB-S2 / 8PSK)

It was an 8K H.266 VVC 20.55 Mbit/s before.
Together with the audio channels it seems to be 27 Mbit/s now, though.

Doesn't look bad: 8K VVC Screenshot

I mean, sure, if you take a look at low lights like in this part, there's a lot of noise in both luma and chroma:



And in other parts, everything looks blurry and averaged out, but still, we're talking about 20-27 Mbit/s for an 8K stream, so it's not really bad.



As a matter of fact, broadcasting 8K contents at around 25 Mbit/s in H.266 VVC just like we're doing for 4K contents in H.265 HEVC at the very same bitrate would be a huge achievement.
Besides, I would totally prefer a blurry approach compared to a blocky one; after all, blocking is immediately noticeable by human eyes, while blurring is kinda not.
It looks like H.266 VVC continued with the same approach H.265 HEVC had and improved from there:



(Remember that those last screenshots are parts of an 8K frame)

[LigH]

Right, other codecs might have to flatten out noise a lot more to achieve this bppf ratio. May look even less obvious in motion.

[benwaggoner]

Originally Posted by LigH

Right, other codecs might have to flatten out noise a lot more to achieve this bppf ratio. May look even less obvious in motion.

And the psychovisual value of a pixel at 8K is very, very different than at 1080p. Different kinds of visual distortion will have different impacts at such different pixel density. For example, dithering-like artifacts are going to be essentially invisible at 8K, since small-moderate differences between individual pixels are effectively invisible.

[xooyoozoo]

Originally Posted by Greenhorn

non-reference (?) VVC implementation by Fraunhofer HHI:

https://github.com/fraunhoferhhi/vvenc

Seems to be in a very early state.

Offers a simple encoder with 4 presets and one tuning option, and multithreading, but no screen-content features, together with a complex encoder which seems to be a re-implementation of the VTM.

They have a whitepaper with a few more details.

The most relevant performance graph:


The higher quality modes are still a magnitude too slow, but it's nice to see a (more) performant encoder that matches reference quality.

If they add scene-change detection and rate-control, the project becomes an almost-useable enthusiast encoder.

[benwaggoner]

Originally Posted by xooyoozoo

The higher quality modes are still a magnitude too slow, but it's nice to see a (more) performant encoder that matches reference quality.

If they add scene-change detection and rate-control, the project becomes an almost-useable enthusiast encoder.

Wow, that would be an incredible accomplishment this early in a codec's history.

A huge but rarely discussed advantage of the MPEG line of codecs is that each generation is heavily based on the previous one. So it's relatively straightforward to take an existing encoder and add some of the tools of the next one to get a compliant bitstream of reasonable quality. Not easy in absolute terms by any means, but relatively easy compared to building an encoder for a new codec without high-quality encoders to start with.

Back in the streaming wars, this was also a big reason why RealVideo and Windows Media codecs were able to come out with improvements so rapidly. Newer versions used the prior encoder as the basis, with new tools added. Being closed source and software only made compatibility a lot easier too, of course.

H.264 was the first time an open standards based approach demonstrated a huge advantage over proprietary codecs, a testament to the effectiveness of having many experts and stakeholders collaborating together.

[hajj_3]

VTM 10.2 is out: https://vcgit.hhi.fraunhofer.de/jvet...VTM/-/releases

[LigH]

New upload: VTM Encoder Version 10.2 [Windows][GCC 10.2.0][64 bit] ec4bb116

[Rusyn]

Hi, I am working on the latest version of VTM for VVC (10.2). I would like to know how many percent of a given frame is encoded using the affine transform. I assume that to figure it out, I need to know the total number of encoded macroblocks, and then how many of them were encoded using the affine transform, but I have no idea what lines of code in which encoder / decoder .cpp files I should add / modify. I would be grateful for any suggestions / tips. Thank you in advance

[FranceBB]

ffmpeg.exe -i "AVS Script.avs" -strict -1 -an -f yuv4mpegpipe -vf scale=848:480:in_color_matrix=bt709:in_range=limited:out_color_matrix=bt709:out_range=limited,format=yuv420p 111.yuv 
| encoder.exe -i 111.yuv -b "raw_video.vvc" -wdt 848 -hgt 480 --Profile=auto --Level=5.1 --Tier=main --FramesToBeEncoded=150 
--FrameRate=30000/1001 --InputBitDepth=8 --OutputBitDepth=8 --InternalBitDepth=8 
--InputChromaFormat=420 --ProgressiveSource 
--IntraPeriod=-1 --GOPSize=4 --TargetBitrate=25000 
--CTUSize=32 --MaxBTLumaISlice=32 --MaxBTChromaISlice=32 --MaxBTNonISlice=32 
--MaxTTLumaISlice=32 --MaxTTChromaISlice=32 
--MaxTTNonISlice=32 --Log2MaxTbSize=5 
--ConformanceWindowMode=0 --SEIDecodedPictureHash=3 
--BitstreamFile=vvc.bitsteam

pause

Output:

Error: found fewer Reference Picture Sets than GOPSize
Error: Invalid GOP structure given

How can I set the reference picture sets? --ref doesn't clearly work and I can't find anything in the documentation

[LigH]

As this seems to be a question specific to x266, it might better be asked in the x266 VVC Encoder thread. This one is rather generic or related to the Fraunhofer HHI reference.

I just even learned that x266 is already available...

Or not? Do you refer to the work of chenm001 who is not related to Multicoreware? Ooh, horay for trademarks.

[FranceBB]

Ah, no, no, sorry (I made a mistake and pasted something I shouldn't have pasted), now I'm referring to the VTM reference encoder by Fraunhofer, the one Jamaika has been posting about all the time.
But yeah, there are a lot of weird naming conventions out there right now, it's a bit of a mess.
And... no, x266 by Multicoreware isn't publicly available yet.
Still, my issue is that I get

Error: found fewer Reference Picture Sets than GOPSize
Error: Invalid GOP structure given

however I specified the correct GOP with a size of 4 and I set the --IntraPeriod to -1 which means automatic, so it should be ok.
I also took care of the CTU size and made sure that all the Slices were the same (so at least equal or less than it) and I set --Log2MaxTbSize to be less than 6, as suggested.
Still, it's complaining again. Why?
Besides, I think it should really allow default settings to go through rather than throwing errors all the time.
I mean, if someone doesn't specify anything, it throws an error 'cause it wants things to be specified.
If someone specifies them wrong, it doesn't clearly work, however there's very little documentation (at least, that's what I've found).
It's a bit of a pain to work with it, honestly...

[mikahawkins1]

It is pretty good when it comes to decoding.

[quietvoid]

I'm not sure a GOP with size 4 is gonna work, at least vvenc only allows 16 and 32.
The VTM example config files as well.

[FranceBB]

Originally Posted by quietvoid

I'm not sure a GOP with size 4 is gonna work, at least vvenc only allows 16 and 32.
The VTM example config files as well.

I set it to 16 and 32. Same thing happens. I mean, I get the very same error message.