[Bug 761165] New: Setting overlay parameters on v4l2sink fails
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Wed Jan 27 00:55:55 PST 2016
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.
More information about the gstreamer-bugs
mailing list