GNOME Bugzilla – Bug 749016
v4l2sink: Playback does not work if V4L2 buffers are smaller than GStreamer buffers
Last modified: 2018-11-03 15:00:18 UTC
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?
This bug lacks some context. What fails is: ... some TS ... ! v4l2sink It fails because in GStreamer we group multiple TS packet together, while the driver request 188bytes per buffer. I don't recall if the driver is limited to 188bytes or if it would accept bigger buffers, but we don't have anyway to negotiate that right now. I don't think this code should be made generic, it is very specific to mpegts. You have an mpegts buffer which is N*188 bytes. What you can do (in v4l2sink), is to create a sub-buffer for each 188bytes and pass it through the pool_process() method. You already know that your pool isn't used by the demuxers for mpegts, as this isn't supported anyway. If it was, the demuxers would have asked for a certain size, which would have just worked. Now, I'm saying 188 bytes, obviously I mean to read the size from the buffers provided by the driver. This way, N*188 will be supported. This only applies to fixed sized packet format. E.g. H264 driver in the kernel currently expect bytestream to be split in video frames. Though it's not impossible that some day a format would be added for "true bytestream", and then we could extend this mechanism.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/185.