GNOME Bugzilla – Bug 599289
[mpegdemux] avoid sending too many small buffers
Last modified: 2015-07-29 14:45:04 UTC
Created attachment 146031 [details] [review] this patch significantly speeds it up in playbin2-plugged playbacks of mpeg1 video containers, we observed an excessive delay before going into playing.
What exactly is this patch trying to do and why?
my reading is that it attempts to aggregate contiguous fragments of a stream and send them as one large buffer, instead of multiple smaller pushes. It only aggregates buffers when the next packet has no timestamp - if there's a new timestamp, it sends any aggregated data and starts collecting new data so that seems OK. It will cause problems with sparse streams, because data may be accumulated until the next packet arrives on that stream - which may be a considerable time. I suspect it may also cause data at the end of the stream not to be sent, as it doesn't seems to do anything on EOS. In general, the idea has merit (reduce the overhead of pushing multiple small buffers). I don't know if it could be done more elegantly or more efficiently with GstBufferLists.
sorry incorrect initial report: problem was such a high load (on the slower platforms 100% cpu), not a preroll delay
on containers muxed with very small packet sizes, on the 300 MIPS embedded cpu, we can raise efficency by two-thirds with the patch
Comment on attachment 146031 [details] [review] this patch significantly speeds it up Any progress on this, maybe by using GstBufferList? Just merging multiple buffers seems wrong though, you're breaking the framing of the container format with this and require decoders to split the buffers into separate packets again.
Andreas, is this still a problem in 1.x ?
technically yes, since the demux still issues the smallest possible chunks (in my example 2296 bytes per buffer)
In that case could you update the patch for current git ?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!