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

[Gravitator]

Originally Posted by Funky080900

What do you mean VVenC did not allocate necessary bitrate? You encoded with constant QP (-q 30).

Cropping did not reveal the problem in -q 30:

ffmpeg -ss 00:00:02 -t 00:00:06 -i c:/raw_1080p30.mkv -pix_fmt yuv420p -f rawvideo - | vvencapp.exe -s 1920x1080 --framerate 30 --threads 2 --preset medium -q 30 -i - --output c:\test.vvc && vvdecapp.exe -b c:\test.vvc -o c:\VVC.yuv && ffmpeg -video_size 1920x1080 -framerate 30 -pix_fmt yuv420p10le -i c:\vvc.yuv -c:v -acodec -vcodec utvideo -color_primaries 1 -color_trc 1 -colorspace 1 c:\final.mkv && del c:\vvc.yuv

The problem is --rskip (artifacts to the left of the tree).

Originally Posted by Funky080900

And there's no scene change detection in VVenC currently, so keyframes get placed in regular intervals.

That's the news!

[ksec]

How the H.266 video standard will help stream content way faster

https://thenextweb.com/news/h266-vvc...ming-standards

While MX Player prefers to stream its content on H.266, depending on the device and network conditions, it might have to fall back to other standards such as AV1 or H.265 on some devices, until playback support for the new standard is baked into chips that are used in those gadgets. Other streaming players will also face this challenge and have to follow suit for a while.

Mantri said that the company has been servicing content through H.266 standard to almost 20% of its customer base and it has received no complaints.

MXplayer in India are already serving 20% of their content with H.266?

Just Wow. It seems they uses Tencent software decoding [1] [2] within their Apps. And the paper [3] did a test and despite it is still early version 0.01, an Apple A12 used in iPhone XR and XS managed to decode with 30fps. Not sure anyone wants to do that due to battery issues but nevertheless it works.

Interesting.

[1] https://github.com/TencentCloud/O266player

[2] https://multimedia.tencent.com/news/202102011

[3] https://arxiv.org/pdf/2103.03612.pdf

[excellentswordfight]

Originally Posted by rwill

Damn, guys...

I just remembered some test of VP3 where someone compared VP3 to DivX 3.11 and he set the keyframe period to 9999 sec or frames, can't remember, in VP3 and then continued to complain about quality and seek times. Now DivX 3.11 was (hacked?) to place keyframes on scenecuts but VP3 just did what it was told. Didnt serve it well to take user input literally.

@Gravitator: Would you complain about broadcast too ? Because most broadcast encoders do not insert I frames on scene change as well. They rather run with a large fixed open gop because they do not care about the screen content.

Large? Most broacasters I've come across uses a short interval (good for channel switching) DVB recommendations for AVC/HEVC is to have an RAP interval of 2s... Closed GOPs are rather common as well. But yes, its rather common to use fixed GOP without scene cut detection.

[birdie]

Speaking of MX Player: it only allows to stream VVC files, it won't play local VVC files.

[benwaggoner]

Originally Posted by Gravitator

I corrected it to the number 60. What's the difference? The encoder did not catch the change - it did not allocate the necessary bitrate. It turned out correctly on x265.

Reference encoders may not do dynamic IDR detection by default. Lots of evaluation processes are done with fixed GOP durations.

[rwill]

Originally Posted by excellentswordfight

Large? Most broacasters I've come across uses a short interval (good for channel switching) DVB recommendations for AVC/HEVC is to have an RAP interval of 2s... Closed GOPs are rather common as well. But yes, its rather common to use fixed GOP without scene cut detection.

Ye, I meant large hierarchical GOPs, with like 4 or 5 hierarchies. Something like 15 or 31 B-Pictures. So a RAP interval of 32 or 64 depending on framerate.

[FranceBB]

Originally Posted by excellentswordfight

Large? Most broacasters I've come across uses a short interval (good for channel switching) DVB recommendations for AVC/HEVC is to have an RAP interval of 2s... Closed GOPs are rather common as well. But yes, its rather common to use fixed GOP without scene cut detection.

Yep and with keyframe = framerate generally, so every second you're able to get one.
Switching across channels would be a pain otherwise, so you're right.

Originally Posted by birdie

Speaking of MX Player: it only allows to stream VVC files, it won't play local VVC files.

Ah... I see...

[benwaggoner]

Originally Posted by rwill

Ye, I meant large hierarchical GOPs, with like 4 or 5 hierarchies. Something like 15 or 31 B-Pictures. So a RAP interval of 32 or 64 depending on framerate.

Yeah, some professional live encoders do some amazingly complex b-frame reference layering.

Obviously one can't have more B-frames than frames in the GOP, but these can get pretty complex even in 25 or 30 frames.

Are any live encoders using RADL yet? Those should be helpful for fixed GOP durations.

[rwill]

Originally Posted by benwaggoner

Yeah, some professional live encoders do some amazingly complex b-frame reference layering.

Obviously one can't have more B-frames than frames in the GOP, but these can get pretty complex even in 25 or 30 frames.

Are any live encoders using RADL yet? Those should be helpful for fixed GOP durations.

I think live encoders go with RASL/CRA to avoid the slight quality "flash" you get with RADL. RADL is more for bitstream splicing. I have not seen many streams from live encoders though so I don't know really.

[contemporarymind]

Originally Posted by rwill

I think live encoders go with RASL/CRA to avoid the slight quality "flash" you get with RADL. RADL is more for bitstream splicing. I have not seen many streams from live encoders though so I don't know really.

RADL considerably affect overall coding efficiency compared to RASL depending on GOP size and intra period. Now that VVC allows for reference picture resampling, you can do bitstream splicing/http streaming also with RASL pics. check https://arxiv.org/pdf/2103.06675

[ksec]

Originally Posted by contemporarymind

RADL considerably affect overall coding efficiency compared to RASL depending on GOP size and intra period. Now that VVC allows for reference picture resampling, you can do bitstream splicing/http streaming also with RASL pics. check https://arxiv.org/pdf/2103.06675

VVC continues to surprise me.

[LigH]

So welcome on board, contemporarymind

[benwaggoner]

Originally Posted by ksec

VVC continues to surprised me.

Yeah, takes years before all the interesting nooks and crannies of a new codec get understood, and how the different parts interact with different kinds of content and use cases.

There's still stuff that HEVC that I seen thoroughly explored and optimized, like adaptive SAO parameters.

[FranceBB]

Avisynth Script:

ColorBars(1920, 1080, pixel_type="YV12")

ChangeFPS(23.976)

trim(0, 100)

VVEnc:

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

pause

VVDec:

vvdecapp.exe -b "VVC.h266" -o "VVC.yuv"

ffmpeg.exe -video_size 1920x1080 -framerate 24 -pix_fmt yuv420p -i "VVC.yuv" -c:v ffvhuff -color_primaries 1 -color_trc 1 -colorspace 1 -y "final.mkv"

pause

Final decoded result:




So it looks as if somewhere it gets converted and it's no longer yuv420p 8bit.
What happened?

[Gravitator]

Originally Posted by FranceBB

So it looks as if somewhere it gets converted and it's no longer yuv420p 8bit.
What happened?

Dec YUV > -pix_fmt yuv420p10le

[Funky080900]

Originally Posted by FranceBB

So it looks as if somewhere it gets converted and it's no longer yuv420p 8bit.
What happened?

VVenC wants raw yuv not y4m. Also, you should tell VVenC the frame rate (-r 24), especially when you use rate control. VVenC defaults to 60 fps, so unless you tell VVenC the frame rate, 250 kbps specified would give you ~ 100 kbps for a 24 fps input (250kbps/60×24=100kbps).

ffmpeg -i "AVS Script.avs" -pix_fmt yuv420p -f rawvideo - | vvencapp -s 1920x1080 -r 24 -c yuv420 --internal-bitdepth 8 --preset medium -b 250000 -p 1 -rs 10 -o VVC.266 -i -

vvdecapp -b VVC.266 -o - | ffmpeg -s:v 1920:1080 -framerate 24 -pixel_format yuv420p -f rawvideo -thread_queue_size 64 -i - -c ffvhuff -color_primaries 1 -color_trc 1 -colorspace 1 final.mkv -y

[benwaggoner]

A curse upon all video tools that support .yuv without supporting .y4m!

[rwill]

Originally Posted by benwaggoner

A curse upon all video tools that support .yuv without supporting .y4m!

I like .yuv more and .y4m is somewhat dated. I dont know if it even supports more than 8 bit officially.

With .yuv you can cut out a snippet very precisely just by skipping and copying blocks of bytes with a fixed size. Like with the Unix tool 'dd'. Cant do that with .y4m. And what does one save by using .y4m ? No need to specify size and fps ?

[birdie]

A paper on H.266 > H.265:

https://arxiv.org/pdf/2109.06555.pdf

[Balling]

"So it looks as if somewhere it gets converted and it's no longer yuv420p 8bit."

This is nv21 or nv12, i.e. semi-planar
ffplay.exe -video_size 1920x1080 -framerate 24 -pix_fmt nv21 -i file

You can also try yuv420p10 and p010le!


"y4m is somewhat dated"

Heh, we just updated it to support more stuff, i.e. ffmpeg color range extension!

See https://code.videolan.org/videolan/x...uests/69/diffs