Greyish colours with bt2020 colourspace

[lnjX]

I'm using mlt over kdenlive and I think I found a "bug" or missing feature. The problem is that when I add a video with 10 bit colours, the output (in kdenlive and the rendered file) has inaccurate colours, everything is a bit greyish. There's no error message.

ffprobe output:

Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x1600 [SAR 1:1 DAR 12:5], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)

Even if mlt doesn't support rendering in 10-bit colours, it'd be great if it at least could read them and convert them to the correct 8-bit colours, so I don't need to reencode my source material.

I found a commit saying its adding 10 bit support, but it seems so it's only adding yuv422p16.

I openend a ticket for kdenlive, too: https://bugs.kde.org/show_bug.cgi?id=406935

[bmatherly]

I would guess that the problem is probably not 10bit. it is probably the colorspace: bt2020nc/bt2020/smpte2084 I'm not sure if BT2020 colorspaces have been properly implemented in MLT

[bmatherly]

Also, what version of MLT are you using? There may have been some related improvements recently: https://github.com/mltframework/mlt/commit/adc5a2284b3a1073cb364c5f07d1d7c97e94c937#diff-40048f17cd89d43fba3be583ace3aa80 Regardless of whether MLT can correctly convert from BT2020, it for sure does not support editing in high dynamic range. So, to set your expectations appropriately, you should expect any imported HDR content to be resampled down to SDR.

[lnjX]

I tested this with melt 6.12.0 and melt https://github.com/mltframework/mlt/commit/ca29df6bff11d28ef47d38682d2b532835666c46 (15th April, 2019), both have the exact same problem.

So, to set your expectations appropriately, you should expect any imported HDR content to be resampled down to SDR.

That's ok, it would only be nice, if I didn't need to reencode my sources.

[ddennedy]

I reproduced this with the Life of Pi trailer on hdrsamples.com. I tried adding support for the BT.2020 colorspace to the avformat producer, and I see it passing the proper values to libswscale now, but it is not affecting the appearance. It even reports "[swscaler] YUV color matrix differs for YUV->YUV, using intermediate RGB to convert". So, it appears libswscale is not handling this yet as when I general web searches people are using libavfilters colormatrix, colorspace, and zscale for this. I tried using colormatrix and colorspace without different results and do not have zscale integrated yet. Not sure what is wrong yet other than tone-mapping is not working.

[ddennedy]

I have used this technique with success (visual comparison with VLC playback): https://stevens.li/guides/video/converting-hdr-to-sdr-with-ffmpeg/ ffmpeg -i input.mkv -vf zscale=t=linear:npl=100,format=gbrpf32le, zscale=p=bt709,tonemap=tonemap=hable:desat=0,zscale=t=bt709:m=bt709:r=tv, format=yuv420p -c:v libx265 -crf 18 -preset slower output.mkv However, that is very heavy. We need to look into how VLC is doing the conversion in realtime.

[lnjX]

I think this fixed it in mpv: https://github.com/mpv-player/mpv/pull/668/files

Maybe something similar could be done here (or in ffmpeg?)?

[faridosc]

Would implementing OpenColorIO to handle color management fix this?

[ValZapod]

This has nothing to do with bt2020 or 10 bit. This is PQ (smpte2084) that makes the difference.