[Bug 749016] v4l2sink: Playback does not work if V4L2 buffers are smaller than GStreamer buffers

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=749016

Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nicolas.dufresne at collabora.
                   |                            |co.uk

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

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