Setting overlay parameters on v4l2sink fails
Andreas Naumann
dev at andin.de
Mon Jan 25 06:08:22 PST 2016
Hi Nicolas,
would this suffice?
Index: gst1-plugins-good-1.6.0/sys/v4l2/gstv4l2sink.c
===================================================================
--- gst1-plugins-good-1.6.0.orig/sys/v4l2/gstv4l2sink.c 2015-03-05
12:07:44.000000000 +0100
+++ gst1-plugins-good-1.6.0/sys/v4l2/gstv4l2sink.c 2016-01-25
14:56:12.995743849 +0100
@@ -250,7 +250,10 @@
struct v4l2_format format;
memset (&format, 0x00, sizeof (struct v4l2_format));
- format.type = V4L2_BUF_TYPE_VIDEO_OVERLAY;
+ if ( v4l2sink->v4l2object->vcap.capabilities &
V4L2_CAP_VIDEO_OUTPUT_OVERLAY )
+ format.type = V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY;
+ else
+ format.type = V4L2_BUF_TYPE_VIDEO_OVERLAY;
if (v4l2_ioctl (fd, VIDIOC_G_FMT, &format) < 0) {
GST_WARNING_OBJECT (v4l2sink, "VIDIOC_G_FMT failed");
Am 25.01.2016 um 13:32 schrieb Andreas Naumann:
>
>
> Am 22.01.2016 um 20:10 schrieb Nicolas Dufresne:
>> The overlay support in v4l2sink was designed by TI
>> before V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY was added. Contribution are
>> welcome, as long as it's backward compatible.
>
> I see, thanks for the background info. I'll try to come up with
> something compatible.
>
>>
>> Nicolas
>>
>> p.s. isn't those thing deprecated in favour of G_SELECTION now ? what
>> does vivid do ?
>
> As far as i can see vivid implements both. The v4l2 API docu still lists
> G_SELECTION as experimental..
> Is there any other somewhat mature gst-sink that enables using overlay
> planes?
>
>>
>> Le vendredi 22 janvier 2016 à 14:12 +0100, Andreas Naumann a écrit :
>>> Hi,
>>>
>>> i observed positioning of video overlays using the v4l2sink
>>> parameters
>>> like 'overlay-left' doesnt work. Digging a little I found out the
>>> VIDIOC_G_FMT/VIDIOC_S_FMT ioctl's dont reach the overlay-driver due
>>> to
>>> being filtered in the kernels v4l2 ioctl dispatcher functions because
>>> my
>>> driver is not a VFL_DIR_RX but TX type.
>>>
>>> After reading the Linux for Video API docu, it seems that the
>>> S/G_FMT
>>> function are indeed intended for the Capture/Rx part of the Video
>>> Overlay Interface. Somehow I cant image such a device but anyway,
>>> the
>>> code that checks for RX is in place since 2012.
>>>
>>> Now, the gstreamer v4l2sink does need a TX device doesnt it? So with
>>> current kernels, the video-overlay ioctls cant ever work, or what am
>>> I
>>> missing?
>>>
>>> Digging further I came across another type, that is
>>> V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY. This is per API doc intended for
>>> output and shares the data structures for S/G_FMT ioctls with
>>> V4L2_BUF_TYPE_VIDEO_OVERLAY. So I tried telling my driver that he
>>> supports such an interface and redirected the existing s/g_fmt
>>> function
>>> pointers (as I saw in some other implementation, I think omap).
>>> On v4l2sink side its a oneliner to change to using that interface (
>>> gst_v4l2sink_sync_overlay_fields()).
>>>
>>> Voila, the positioning works!
>>>
>>> Now, is this the way to go or what do the experts think?
>>>
>>>
>>> cheers,
>>> Andreas
>>>
>>>
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> gstreamer-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
More information about the gstreamer-devel
mailing list