rigaya/QSVEnc

master-display data modification

CraftyDlx opened this issue · 4 comments

Using QSVEncC 7.54 for transcoding a HEVC HDR video to AV1 HDR. Extracting the HDR meta data from the source file to json, shows me the following:

                    "red_x": "34000/50000",
                    "red_y": "16000/50000",
                    "green_x": "13250/50000",
                    "green_y": "34500/50000",
                    "blue_x": "7500/50000",
                    "blue_y": "3000/50000",
                    "white_point_x": "15635/50000",
                    "white_point_y": "16450/50000",
                    "min_luminance": "50/10000",
                    "max_luminance": "40000000/10000"

what would be --master-display G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50) for cli. Now using

QSVEncC64.exe -i source.mkv --codec av1 --master-display copy --max-cll copy --colormatrix auto --colorprim auto --transfer auto --chromaloc auto --colorrange auto -o target.mkv

or inserting directly

QSVEncC64.exe -i source.mkv --codec av1 --master-display G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50) --max-cll copy --colormatrix auto --colorprim auto --transfer auto --chromaloc auto --colorrange auto -o target.mkv

shows me correct data on the cli, except the master-display data which appear to be strongly modified:

Screen Shot 11-28-23 at 01 24 AM

Extracting meta data from the resulting file gives me the following master-display data:

                    "red_x": "44564/65536",
                    "red_y": "20972/65536",
                    "green_x": "17367/65536",
                    "green_y": "45220/65536",
                    "blue_x": "9830/65536",
                    "blue_y": "3932/65536",
                    "white_point_x": "20493/65536",
                    "white_point_y": "21561/65536",
                    "min_luminance": "82/16384",
                    "max_luminance": "1024000/256"

What am I missing? Is this a bug or do I need some kind of additional parameter to have the color data etc. handled properly?

rigaya commented

I think it's actually the same.

For example
"red_x": "34000/50000" = 0.68
and
"red_x": "44564/65536" = 0.68

It's only that the denominator changed, the values are kept the same.

Okay, the resulting video looks indeed the same but is there a way to keep the original values, just for making testing and comparing easier?

I've also seen that there's a auto VPP ColorFormatConversion from p010 to nv12. Makes me wonder, since nv12 is used for 12bit videos and p010 (10bit) should be fine for HDR 10bit to HDR 10bit. MediaInfo says the resulting video is 10bit though and the colorspace has not changed, so why is this conversion happening? Thanks.

rigaya commented

It is simple fraction thing, there is no conversion done, the value is kept as-is. You can compare by floating point if you want.

You'll need to add --output-depth 10 for 10bit depth encoding.

Right, then the VPP entry in the cli is gone (but the denominator still changes though). Well, thanks, I think I can go on with these settings.