[Bug 761165] New: Setting overlay parameters on v4l2sink fails

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 761165
           Summary: Setting overlay parameters on v4l2sink fails
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: dev at andin.de
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

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()).

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