After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 599289 - [mpegdemux] avoid sending too many small buffers
[mpegdemux] avoid sending too many small buffers
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-10-22 11:44 UTC by Andreas Frisch
Modified: 2015-07-29 14:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
this patch significantly speeds it up (3.08 KB, patch)
2009-10-22 11:44 UTC, Andreas Frisch
needs-work Details | Review

Description Andreas Frisch 2009-10-22 11:44:47 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.
Comment 1 Sebastian Dröge (slomo) 2009-10-24 14:13:58 UTC
What exactly is this patch trying to do and why?
Comment 2 Jan Schmidt 2009-10-25 17:56:27 UTC
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.
Comment 3 Andreas Frisch 2009-10-25 20:40:13 UTC
sorry incorrect initial report: problem was such a high load (on the slower platforms 100% cpu), not a preroll delay
Comment 4 Andreas Frisch 2009-10-25 20:43:07 UTC
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 5 Sebastian Dröge (slomo) 2011-05-30 06:36:59 UTC
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.
Comment 6 Edward Hervey 2013-07-17 06:32:26 UTC
Andreas, is this still a problem in 1.x ?
Comment 7 Andreas Frisch 2013-07-17 08:42:50 UTC
technically yes, since the demux still issues the smallest possible chunks (in my example 2296 bytes per buffer)
Comment 8 Edward Hervey 2013-07-17 08:49:17 UTC
In that case could you update the patch for current git ?
Comment 9 Alexandre Franke 2015-07-29 14:45:04 UTC
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!