v4l2sink: Playback does not work if V4L2 buffers are smaller than GStreamer buffers
Submitted by Tobias Modschiedler
Link to original bug (#749016)
Description
This topic was started in the discussion of bug 746834 at Comment 18 (https://bugzilla.gnome.org/show_bug.cgi?id=746834#c18).
If GStreamer source buffers are larger that V4L2 buffers (which makes sense for MPEG-TS data), copying them fails in gst_v4l2_buffer_pool_copy_buffer().
I'll copy the relevant part of Nicolas' comment here:
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.
I'm having problems coming up with a patch. The "multi-buffer" handling will probably be in gst_v4l2_buffer_pool_process() at label "copying". But what happens if only a part of the source buffer can be copied, i.e. not enough destination buffers can be acquired?