GNOME Bugzilla – Bug 796753
video: 4K resolutions defaults to BT2020 which is uncommon for 8bit formats
Last modified: 2018-11-03 12:08:50 UTC
First, let me describe the issue my end users are actually seeing after updating from 1.12.4 to 1.14.1, which caused me to investigate this. https://gist.github.com/pauldotknopf/18b4671bff8521201d07e5b21d71ebfe/ The encoded videos for 1.12 played back with normal colors and pretty much every decoder out there. After updating to 1.14, the videos played back on some decoders (Mac OSX Quick Time being one) with the reds being pink. I through both a 1.12 video and a 1.14 into media info to compare. Take a look at the gist files "media-info-output-for-1.12-mp4.log" and "media-info-output-for-1.14-mp4.log". I noticed the colorspace was different. 1.12 negotiated bt601 and 1.14 negotiated bt2020. After seeing this, I used capsfilter to force bt709 on 1.14 and the decoders worked correctly. I would say this fixed my issue and move on, but something tells me there is a deeper issue that needs looking at. So here I am. Here are my test video files: https://drive.google.com/drive/folders/18VP3d6Tz3SPbVZZFVTochTrXYDxWyHqQ?usp=sharing test-1.12.4.mp4 - This played back fine on all decoders. I wasn't forcing colorimetry here. test-1.14.1.mp4 - This caused reds to be pink on some decoders. I wasn't forcing colorimetry here. test-1.14.1-with-forced-bt709-caps.mp4 - I forced bt709 here with capsfilter, and problematic decoders handled it correctly. Here was the command I used to record the videos: gst-launch-1.0 -e v4l2src ! video/x-raw,width=2160,height=3840,format=YV12 ! vaapih264enc ! qtmux ! filesink location=test.mp4 In the gist are also the dots files for both 1.12 and 1.14, and you can see it negotiates different colorimetries for the same driver. This was the command used for those dot files: gst-launch-1.0 -e v4l2src ! video/x-raw,width=3840,height=2160,format=YV12 ! autovideosink sync=false With the gist file "v4l2-ctl.log", you can see that my camera is reporting bt709. I am working on getting a GST_DEBUG="v4l2*:7" now.
Just looked up, vaapih264enc have no colorimetry support, it's visible as the colorimetry SEI is no in the h264 bitstream. When we look at the sample, we notice that the transfer function is 0 instead of 5/11 (BT709/BT20202_12). My guess is that BT2020_12 transfer is likely not stored properly by qtmux (or not supported).
Created attachment 372956 [details] gstreamer debug log for v4l2 negotation gst-launch-1.0 -e v4l2src ! video/x-raw,width=3840,height=2160,format=YV12 ! autovideosink sync=false
Any ideas why bt2020 is being negotiated? v4l2-ctl camera reports bt709.
Created attachment 372957 [details] gstreamer debug log for v4l2 recording gst-launch-1.0 -e v4l2src ! video/x-raw,width=$WIDTH,height=$HEIGHT,format=YV12 ! mfxh264enc ! qtmux ! filesink location=test.mp4
I forgot to add. This issue happens with both vaapih264enc and mfxh264enc, so the issue isn't likely the encoder. It also happened on a custom source element I wrote for a non-v4l2 driver. It didn't report a colorspace. #define MY_SOURCE_CAPS "video/x-raw," \ "format=UYVY," \ "width=3840," \ "height=2160," \ "framerate=30/1," \ "pixel-aspect-ratio=1/1" My custom element wasn't giving a source caps with a specific colorimetry, but with 1.14, bt2020 was decided. On 1.12, non-bt2020 was decided (don't remember off hand if it was 601 or 709). I didn't initially report this because when I was investigating the issue, I found that it happened with the built in v4l2src as well, so it might be useful information for you.
This driver does not report colorimetry (return colorpsace 0, which is invalid, means unimplemented basically). In that case, the colorimetry is being decided by gst_video_info_from_caps() and since 1.14, we not longer probe the colorimetry because it's bogus to do so. That being said, why BT2020 bs BT709, I don't know, for 8bit formats I would expect BT709 to be a better choice, and also more widely supported. One of the issue that raises here, is that QTMUX does not fully support BT2020, and writes an invalid colorimetry into the 'colr' box. In the output, GStreamer fixes it properly, but it might not be the case for all players. Moving to -base.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/470.