[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 #17 from Tobias Modschiedler <tobias.modschiedler at cetitec.com> ---
Created attachment 300767
  --> https://bugzilla.gnome.org/attachment.cgi?id=300767&action=edit
Requested GStreamer log.

Well, with the latest patch (actually with any of the patches), playback does
somewhat work for me. But now I see that the CPU load is quite high: 40% to 80%
just for playing back without decoding. So I might still be having problems
with slow copying (as you suspected). I noticed that if I increase the bitrate
(or just enable extensive GStreamer logging), a lot of video data is lost.

My pipeline might be a bit unusual/strange/shitty:
filesrc location="test.ts" !
"video/mpegts, systemstream=(boolean)true, packetsize=(int)188" !
tee name=t !
queue ! tsdemux ! fakesink sync=true t. !
queue ! rndbuffersize min=188 max=188 !
v4l2sink device=/dev/video0 io-mode=2 sync=true

Basically, I just want to put the "raw" MPEG-TS data into the v4l2 device, but
with the right timing from the stream. That's why there's the tsdemux in the
pipeline which throws away the data.

The rndbuffersize just forces a buffer size of 188 Byte, because the driver
does not support anything else. When I omit it, I get flooded by the message
"gst_buffer_resize_range: assertion 'bufmax >= bufoffs + offset + size'
failed". I don't know if this is a driver bug or just caused by the strange
pipeline.

Anyway, I attached the log with GST_DEBUG="v4l2*:7" after applying this latest
patch.

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