[Bug 746834] v4l2sink: driver is not queried for minimum number of buffers when propose_allocation is not called

[GStreamer (GNOME Bugzilla)]

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

--- Comment #10 from Tobias Modschiedler <tobias.modschiedler at cetitec.com> ---
OK, so when I just use the v4l2sink from git master and let the driver increase
the buffer count in REQBUFS as needed, playback doesn't really work. The
execution time (as reported by gst-launch) is about double to triple the
expected playback time. It seems that DQBUF is called much too early, blocking
the execution.

I suspect that gst_v4l2_buffer_pool_start() does not handle a changed buffer
count correctly. It seems that it only expects count to be smaller than
min_buffers, not larger. My latest patch changes it's behavior to re-calculate
min_latency when the count has changed. Also, copy_threshold is only enabled
when the number of buffers became smaller.

I'm not sure what setting copy_threshold actually causes, so does this make any
sense? The most important thing is to re-calculate min_latency, as
obj->min_buffers is always zero in my case (propose_allocation not called).

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