How and why v4l2src able to take YV12 format?

[Nicolas Dufresne]

Le lundi 18 novembre 2019 à 13:13 -0500, Nicolas Dufresne a écrit :
> 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?

Can you test this patch for me ?

https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/merge_requests/392

> > > 
> > > 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