[Bug 796753] New: v4l2src negotiates wrong colorspace (bt2020 instead of bt709), causes some decoders to turn reds to pink.

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=796753

            Bug ID: 796753
           Summary: v4l2src negotiates wrong colorspace (bt2020 instead of
                    bt709), causes some decoders to turn reds to pink.
    Classification: Platform
           Product: GStreamer
           Version: 1.14.1
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: pauldotknopf at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.