[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 #12 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
(In reply to Tobias Modschiedler from comment #10)
> 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.

Are you sure it isn't the copy the slow down everything ? When
propose_allocation() isn't called, it means that buffer will arrive to the sink
and will need to be copied to V4L2 memory. You can use perf to profile it.

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

That's true that the latency "without doing anything" won't be right at the
moment. About the copy threshold it's probably only implement for capture
device.

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