[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 #18 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
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.

Now, the driver makes a questionable decision, and GstV4L2 lacks some support
for MPEG TS. Let me explains.

Because GstV4l2 want to be agnostic, we let the driver decide of proper size.
So we set sizeimage to 0, and leave it to the driver to decide. 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. Though 188 is extremely
small, the overhead in GST and of all the ioctl involved will burn your CPU.

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. For mpegts, the buffer size will always be a multiple of 188
anyway.

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. If you take the time to improve, then this simple pipeline will
become sufficient. 

filesrc location="test.ts" ! tsparse ! identity sync=1 ! v4l2sink

But that should be filed in separate bugs. If I find that time, I might just do
myself the little adjustment. Thanks for reporting.

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