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

[MartinEesmaa]

Hi, Gravitator!

It seems vvencapp reported an error message of your sample file:

Parameter Check Error: Detected non-standard Frame Rate 13978/583 (23.98 Hz). Default TicksPerSecond (27000000) can not be used. possible TicksPerSecond: 8149174

You need to add --tickspersec -1 or possible number of console said example 8149174 on vvencapp console command to encode probably VVC video.

I encoded your sample file on my FFmpeg VVCEasy command, but three duplicated frames:

ffmpeg_vvceasy -i space_6s.mkv -c:v libvvenc -preset faster -b:v 0 -qp 30 y4m.266
frame= 149 fps= 16 q=0.0 Lsize= 902kB time=00:00:05.96 bitrate=1238.5kbits/s dup=3 drop=0 speed=0.631x
video:902kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000%

- Martin Eesmaa

[Gravitator]

It doesn't help.

[MartinEesmaa]

Why it doesn't help?

I know why ticks per second could be quite moderate difficult, but I hope Multicoreware x266 encoder doesn't need ticks per second necessary, so we should wait a little bit to get x266 encoder in H2 2023.

Here is the transcoded from your matroska sample file to Y4M report:

YUV4MPEG2 W1920 H1080 F13978:583 Ip A1:1 C420mpeg2 XYSCSS=420MPEG2

Try change from F13978:583 to F24000:1001 without using tickspersecond command.

- Martin Eesmaa

[Gravitator]

The output of the parameter validation error continues.

[Gravitator]

This problem has a connection with the output of yuv4mpegpipe (rawvideo goes without an error).

[MartinEesmaa]

Oh ok, I see the rawvideo does not have problems, but Y4M does only some errors for some reasons of frame rate per second.
I looked issue for reference: https://github.com/fraunhoferhhi/vvenc/issues/252.
This could be bug for Fraunhofer HHI VVC encoder.

Maybe I encoded your sample file to libx264 with matroska container without duplicates frames, but encoding to raw bitstream reports duplicate frames. So I think VVC matroska is not finished yet.

I think Fraunhofer HHI VVC encoder is experimental I'd say, but I recommend we wait for Multicoreware x266 encoder or just make issue/discussion to vvenc github repository.

- Martin Eesmaa

[Gravitator]

They are already treating > https://github.com/fraunhoferhhi/vvenc/pull/255

[Gravitator]

Replace --tickspersecond -1 with --tickspersec -1 > It's going fine now

[MartinEesmaa]

Sorry, my bad. It's tickspersec, not tickspersecond. I hope the tickspersec -1 is gonna encode probably.

- Martin Eesmaa

[Yups]

chipsandcheese compared HEVC, AV1, VVC....interesting read.

Codecs for the 4K Era: HEVC, AV1, VVC and Beyond

[birdie]

Originally Posted by Yups

chipsandcheese compared HEVC, AV1, VVC....interesting read.

Codecs for the 4K Era: HEVC, AV1, VVC and Beyond

From the research: "VVenC is still in heavy development and doesn’t currently support CRF. Therefore, we use the next best option – two-pass variable bitrate (VBR) – for VVC"

What? What version did they use? From 2 years ago?

From https://github.com/fraunhoferhhi/vvenc/wiki/Usage

--qp,-q 	32 	Quantization parameter (0..63)

which is basically CRF.

[nevcairiel]

QP and CRF is not the same. CRF will modify the QP to compensate for frame complexity, providing similar "perceived" quality for all frames, while keeping bitrate in check.
Constant QP is the simplest compression mode you can think of, really, as you don't do any rate-control at all.

[hajj_3]

Originally Posted by birdie

What? What version did they use? From 2 years ago?

it says they used v1.7.0 which was released 5 months ago.

[birdie]

A native VVC decoder has been submitted to FFmpeg: https://www.mail-archive.com/ffmpeg-...eg.org/#147681

There's a number of objections, so it's not yet a done deal.