Adjusting color range for vvenc

[birdie-github]

I don't understand how to reconcile my source video which is yuvj420p(pc, bt470bg/bt470bg/smpte170m, progressive) with the color formats that vvenc supports: yuv420, yuv420_10, yuv420_10_packed.

vvdec decodes to yuv420p10le which is what is seemingly necessary as an input. However no matter what I do to the input it results in a different color-range-wise output.

By default I used: ffmpeg -i *mp4 out.y4m. I've also tried, ffmpeg -i *mp4 -strict -1 -pix_fmt yuv420p10le out.y4m with -color_range 1 and -color_range 2. I've also tried -vf scale=in_range=limited:out_range=full and -vf scale=in_range=full:out_range=limited - no success either.

There's this post by John Carmack but it's about x265, not vvenc: https://news.ycombinator.com/item?id=20036710

Here's the source:

Here's the encode:

Screenshots are produced by mpv. As you can see the grass on the second shot (encode) is more yellow/red. The plastic glass shield is a lot darker - it almost lost its transparency.

[Jamaika1]

If we are talking about ffmpeg then for 8bit it should be: ffmpeg.exe -i VID_20190409_090117.mp4 -f rawvideo -vf scale=1920:1080:in_color_matrix=bt470bg:in_range=full:out_color_matrix=bt709:out_range=limited,format=yuv420p input.yuv Then the codec test. VVEncoderApp is only for bt709. I have problem with the 60000/1001 framerate uvg266e.exe -i "input.yuv" -o "output_uvg266.vvc" --no-info --input-bitdepth 8 --threads 4 --input-res 1920x1080 --input-fps 60000/1001 --input-format P420 --gop=16 --ref=4 --bipred --gop lp-g16d4t1 -p 256 --bitrate 6000000 --preset medium --level 6.2 --colormatrix bt709 xeve_app.exe -i "input.yuv" -o "output.evc" --info 0 -v 2 -q 30 -m 4 -d 8 -w 1920 -h 1080 -z 60000/1001 --preset medium --profile main --bitrate 6000000 --level-idc 6.2 --matrix-coefficients bt709 VVEncoderApp_avx.exe -v 5 -t 4 -s 1920x1080 --framerate 60000 --framescale 1001 -c yuv420 -q 30 --bitrate 6000000 --passes 1 --preset medium --level 6.2 --tier high -i "input.yuv" -o "output_vvenc.vvc"

[birdie-github]

-vf scale=in_color_matrix=bt470bg:in_range=full:out_color_matrix=bt709:out_range=limited,format=yuv420p

Will try this, thanks!

[birdie-github]

This has worked perfectly, thanks a ton!

[adamjw24]

So, first of all, please don't add resolutions to the issues, that's up to us.

Second, about your actual problem.

yuv420 vs yuv420p10le is about the data layout, both layouts can contain any color space you want. VVenC does not assume either full nor restricted range, and would just try to reproduce the input as good as possible.

Now your problem is the meaning of the values, which is independent of the sample representation within the core codec. The meaning of the samples values would be signaled in some form of high level or supplementary information. Here the question is, does your player understand those and apply them correctly?

For VVenC you could set --TransferCharacteristics=bt470bg --MatrixCoefficients=bt470bg (only directly available in FF-app, for simple app would need to be passed through the additional-parameter). Now your player should be able to understand the values correctly. This is of course assuming you are playing the VVC bitstream in your player directly. If you do conversions to and from YUV its up to you to maintain correct metadata.

To be fair tho, we only really test bt709 and bt2020 color spaces, so there might be more to be done here. Feedback appreciated.

[birdie-github]

@adamjw24

Here's the issue.

The second screenshot belongs to the y4m stream produced by vvdec, so the player, mpv, is unlikely to add any of its own processing (it absolutely does, it needs to convert yuv420_10 to RGB but it doesn't AFAIK change the palette).

Here's the resulting video.

[adamjw24]

Alright, I see the problem. Could you please list all the steps you do starting from the input file and define at which point do you view the results to see the difference described above?

Best regards, Adam

[birdie-github]

ffmpeg -i source.mp4 out.y4m
vvencapp --preset slower -qp 20 -i out.y4m --output=bit.266 # version 1.6.1
vvdecapp --bitstream bit.266 --output result.y4m # version 1.6.0

Take screenshots of source.mp4 and result.y4m.

This takes ~12 hours on my system, so instead of encoding everything you could instead:

ffmpeg -i source.mp4 -to 00:00:01 out.y4m - this will produce just a second long clip. You could go even lower, 00:00:00.5 (half a second).

[adamjw24]

View out.y4m and see if the problem is already visible there.

[adamjw24]

And if thats possible could you post the Y4M header of out.y4m?

[birdie-github]

View out.y4m and see if the problem is already visible there.

You're right, the resulting y4m file already looks different. Looks like this is an invalid bug report. Sorry.

[birdie-github]

And if thats possible could you post the Y4M header of out.y4m?

(This is a xz file, not zip).

short.y4m.xz.zip

[adamjw24]

And if thats possible could you post the Y4M header of out.y4m?

(This is a xz file, not zip).

short.y4m.xz.zip

Yeah, as I was expecting. The y4m does not have any color space related metadata. So thats the step your information gets lost. You would need to tell mpv when displaying the raw data what color space to use.

[birdie-github]

Let's close as invalid then.