[Bug 791471] v4l2object: non-default colorimetry broken for v4l2h264enc

[GStreamer (GNOME Bugzilla)]

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

--- Comment #9 from Philipp Zabel <p.zabel at pengutronix.de> ---
I have removed all colorimetry checks from the driver to allow GStreamer to set
any colorimetry on either queue in any order.
I have also removed the size dependent default colorimetry setting (bt601 for <
720p, bt709 otherwise) and always let the driver default to bt601.
It still fails if I force any non-default colorimetry:

gst-launch-1.0 --gst-debug=*v4l2*:6 videotestsrc !
video/x-raw,colorimetry=bt709 ! v4l2h264enc ! fakesink

0:00:00.487893333   371  0x147a350 DEBUG                   v4l2
gstv4l2object.c:4076:gst_v4l2_object_set_format:<v4l2h264enc0:src> Setting
format to video/x-h264, stream-format=(string)byte-stream,
alignment=(string)au, profile=(string)baseline, level=(string)4,
width=(int)320, height=(int)240, pixel-aspect-ratio=(fraction)1/1,
framerate=(fraction)30/1, interlace-mode=(string)progressive,
colorimetry=(string)bt709, multiview-mode=(string)mono,
multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono
0:00:00.488061333   371  0x147a350 DEBUG                   v4l2
gstv4l2object.c:3512:gst_v4l2_object_set_format_full:<v4l2h264enc0:src>
progressive video
0:00:00.488115000   371  0x147a350 DEBUG                   v4l2
gstv4l2object.c:3650:gst_v4l2_object_set_format_full:<v4l2h264enc0:src> Desired
format 320x240, format H264 stride: 0
0:00:00.488164667   371  0x147a350 DEBUG                   v4l2
gstv4l2object.c:3701:gst_v4l2_object_set_format_full:<v4l2h264enc0:src> Desired
format is 320x240, format H264, nb planes 1
0:00:00.488210000   371  0x147a350 DEBUG                   v4l2
gstv4l2object.c:3710:gst_v4l2_object_set_format_full:<v4l2h264enc0:src>  
stride 0
0:00:00.488257333   371  0x147a350 DEBUG                   v4l2
gstv4l2object.c:3744:gst_v4l2_object_set_format_full:<v4l2h264enc0:src> Got
format of 320x240, format H264, nb planes 1, colorspace 1
0:00:00.488306000   371  0x147a350 DEBUG                   v4l2
gstv4l2object.c:3754:gst_v4l2_object_set_format_full:<v4l2h264enc0:src>  
stride 0, sizeimage 155648
ERROR: from element /GstPipeline:pipeline0/v4l2h264enc:v4l2h264enc0: Device
'/dev/video14' does not support bt709 colorimetry
Additional debug info:
gstv4l2object.c(4042): gst_v4l2_object_set_format_full ():
/GstPipeline:pipeline0/v4l2h264enc:v4l2h264enc0:
Device wants bt601 colorimetry

The issue seems to be that we set CAPTURE format first in v4l2videoenc, but
v4l2object doesn't even try to set our desired colorspace:

  if (V4L2_TYPE_IS_OUTPUT (v4l2object->type)) {
    if (is_mplane) {
      format.fmt.pix_mp.colorspace = colorspace;
      format.fmt.pix_mp.quantization = range;
      format.fmt.pix_mp.ycbcr_enc = matrix;
      format.fmt.pix_mp.xfer_func = transfer;
    } else {
      format.fmt.pix.colorspace = colorspace;
      format.fmt.pix.quantization = range;
      format.fmt.pix.ycbcr_enc = matrix;
      format.fmt.pix.xfer_func = transfer;
    }

    GST_DEBUG_OBJECT (v4l2object->dbg_obj, "Desired colorspace is %d:%d:%d:%d",
        colorspace, range, matrix, transfer);
  }

Note the missing "Desired colorspace" from the logs.
If I enable that (and the initialization of these local variables above) for
CAPTURE instead, I get it rolling:

0:00:00.586204333   385  0x1e5d150 DEBUG                   v4l2
gstv4l2object.c:4076:gst_v4l2_object_set_format:<v4l2h264enc0:sink> Setting
format to video/x-raw, format=(string)I420, width=(int)320, height=(int)240,
framerate=(fraction)30/1, multiview-mode=(string)mono,
colorimetry=(string)bt709, interlace-mode=(string)progressive,
pixel-aspect-ratio=(fraction)1/1
0:00:00.586345000   385  0x1e5d150 DEBUG                   v4l2
gstv4l2object.c:3512:gst_v4l2_object_set_format_full:<v4l2h264enc0:sink>
progressive video
0:00:00.586394000   385  0x1e5d150 DEBUG                   v4l2
gstv4l2object.c:3650:gst_v4l2_object_set_format_full:<v4l2h264enc0:sink>
Desired format 320x240, format YU12 stride: 320
0:00:00.586453000   385  0x1e5d150 DEBUG                   v4l2
gstv4l2object.c:3701:gst_v4l2_object_set_format_full:<v4l2h264enc0:sink>
Desired format is 320x240, format YU12, nb planes 1
0:00:00.586508666   385  0x1e5d150 DEBUG                   v4l2
gstv4l2object.c:3710:gst_v4l2_object_set_format_full:<v4l2h264enc0:sink>  
stride 320
0:00:00.586550666   385  0x1e5d150 DEBUG                   v4l2
gstv4l2object.c:3728:gst_v4l2_object_set_format_full:<v4l2h264enc0:sink>
Desired colorspace is 3:2:2:1
0:00:00.586619333   385  0x1e5d150 DEBUG                   v4l2
gstv4l2object.c:3744:gst_v4l2_object_set_format_full:<v4l2h264enc0:sink> Got
format of 320x240, format YU12, nb planes 1, colorspace 3
0:00:00.586686666   385  0x1e5d150 DEBUG                   v4l2
gstv4l2object.c:3754:gst_v4l2_object_set_format_full:<v4l2h264enc0:sink>  
stride 320, sizeimage 115200

It seems to me that for v4l2videoenc, we should probe both the src and sink
colorimetry caps from the CAPTURE queue in case the driver limits OUTPUT
colorimetry to the currently set CAPTURE value?
And set_format_full for the encoder needs to set colorimetry on the CAPTURE
queue instead of the OUTPUT queue.

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