How and why v4l2src able to take YV12 format?

[Nicolas Dufresne]

Le lundi 18 novembre 2019 à 12:54 -0500, Nicolas Dufresne a écrit :
> Le lundi 18 novembre 2019 à 07:39 -0600, jeyp4 a écrit :
> > I modified GST_V4L2_USE_LIBV4L2=1 in a shell. But still v4l2src can't take
> > YV12 format?
> > 
> > nvidia at jetson:~$ echo $GST_V4L2_USE_LIBV4L2
> > 
> > nvidia at jetson:~$ GST_V4L2_USE_LIBV4L2=1
> > nvidia at jetson:~$ echo $GST_V4L2_USE_LIBV4L2
> > 1
> > nvidia at jetson:~$ gst-launch-1.0 -v v4l2src device=/dev/video0 !
> > 'video/x-raw,format=(string)YV12,width=1280,height=720' ! xvimagesink
> > Setting pipeline to PAUSED ...
> > Pipeline is live and does not need PREROLL ...
> > Setting pipeline to PLAYING ...
> > ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Internal
> > data stream error.
> > Additional debug info:
> > gstbasesrc.c(3055): gst_base_src_loop ():
> > /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
> > streaming stopped, reason not-negotiated (-4)
> > Execution ended after 0:00:00.000127687
> > Setting pipeline to PAUSED ...
> > Setting pipeline to READY ...
> > Setting pipeline to NULL ...
> > Freeing pipeline ...
> > nvidia at jetson:~$ gst-inspect-1.0 --version
> > gst-inspect-1.0 version 1.14.5
> > GStreamer 1.14.5
> > https://launchpad.net/distros/ubuntu/+source/gstreamer1.0
> 
> On master, it throws an error about colorimetry. I suspect libv4l2 does
> not emulate that very well. Try commenting out that check, might work
> for you, works for me on master. I'll need to investigate for a proper
> workaround.
> 
> https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/master/sys/v4l2/gstv4l2object.c#L3627

Some more context, libv4l2 seems to set fmt->fmt.pix.colorspace to 0,
which is V4L2_COLORSPACE_DEFAULT, which is not supposed to be set by
drivers.

The whole story is that we suggest (try_fmt) 3:2:2:1 (in v4l2 values of
colorspace, range, matrix, transfer), and libv4l2 returns 0:2:2:1. We
fail at parsing this, and for some reason we endup leaving 3:2:2:1 into
the caps. So that when we get to do set_fmt, we have 3:2:2:1 (bt709) in
the caps. At this stage, because it was in the caps, we do validate and
fail.

To make the libv4l2 behaviour even more strange, when we do S_FMT, the
return colorimetry is not 8:0:0:0:0 (so JPEG with default for
everything). That make sense considering it will decode jpeg for us.
But why didn't it returned that in TRY_FMT seems like a libv4l2 bug to
me.

So I think this should be fixed in libv4l2 of course, but we could also
consider dropping the colorimetry from the caps to be set if the
parsing failed. That should have worked too I guess.

> 
> > 
> > 
> > 
> > --
> > Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel