[Bug 682770] v4l2src: should renegotiate

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Sat Mar 29 13:21:37 PDT 2014


https://bugzilla.gnome.org/show_bug.cgi?id=682770
  GStreamer | gst-plugins-good | git

--- Comment #27 from Nicolas Dufresne <nicolas.dufresne at collabora.co.uk> 2014-03-29 20:47:38 UTC ---
I'll try and implement this for 1.4. There is 2 scenarios right now:

a) We are copying to downstream (or generic pool)
b) We are pushing buffer from our pool

Note that a is not currently present, though it's a bug, as if downstream don't
support strides, and our driver has a stride that don't match the default
stride provided by VideoInfo, we should be copying.

For case a), there is nothing to do, we can just de-activate, reconfigure,
re-activate our pool

For case b), in the context of 1.4, we will operate a drain query. It is not
ideal, it will introduce larger gap then needed, but it should work. The drain
query purpose will be to reclaim our buffers. Obviously, if the result of a
drain query didn't manage to reclaim our buffers, we won't be renegotiating.
Camerabin should get ready for that imho, and should not assume the
renegotiation applied immediately. A mix or non-fixed caps and videoscaler
could allow immediate result I think, regardless of how many buffer the sources
may be emitting, before actually changing resolution (if it ever change).

As a first step to this, I need to implement an allocator, in order to actually
track the memory.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- 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