video: 4K resolutions defaults to BT2020 which is uncommon for 8bit formats
Submitted by pau..@..il.com
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.
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.