[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 #19 from Tobias Modschiedler <tobias.modschiedler at cetitec.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #18)
> Ok, the patch is nearly correct, I'd get the min buffer (if zero) in
> set_config() of the pool instead of set_default(). This is because if you
> driver had multiple formats, it would have had multiple minimum.

In this patch, it's not done in set_defaults(), that was in a previous patch.
Now I moved it to object_setup_pool(), just before the call to
buffer_pool_new(), because then the format should be decided on (or can it
still change?).

> The
> driver in this case has a simple restriction, this value must be a multiple
> of 188 bytes. It dumbly return 188, because it's a valid value.

> GstV4l2 also kind of lack some support. If the buffer is bigger then the
> v4l2 buffer size, it simply fails. It's fine for raw data, but for encoded
> data it should probably spread the data over multiple buffers and properly
> set the size for the last one.

> I think we could have mpegts specific code to select a decent default size
> (N * 188), or change the driver to pick a better default. Then if a buffer
> is bigger and we have encoded data, we should loop (copy and queue), until
> all data has been consumed.

OK, I understand. Would it be possible to reasonably use larger buffers (N*188)
with an unmodified GstV4L2 right now? (If the driver chooses this size.)

> Thanks for reporting.
Thanks for helping me understand things better!

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