Hi,
I'm getting bad performance when playing an mpeg2 elementary stream with playbin2. Example clip: https://www.dropbox.com/s/cd9kxmj1ug21438/video.m2v
The pipeline used by playbin2 is similar to: filesrc ! mpegvideoparse ! queue ! mpeg2dec ! xvimagesink When playing with the pipeline myself, I can fix the perfomance issue in 2 ways: 1. leave out mpegvideoparse: filesrc ! queue ! mpeg2dec ! xvimagesink 2. insert a queue before mpegvideoparse: filesrc ! queue ! mpegvideoparse ! queue ! mpeg2dec ! xvimagesink
It seems to me that there should be a queue in front of the parse element. Playbin2 always insert a queue between demuxing and parsing. As this is an elementary clip, playbin2 leaves out the demuxing and the queue after it.
Should playbin2 insert a queue before parsing even if there is no demuxing necessary? Or am I looking at it the wrong way?
GStreamer version:
base: 0.10.36 good: 0.10.31
bad: 0.10.23 ugly: 0.10.19
Best regards, Christophe
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Administrator
|
On Wed, 2012-11-14 at 10:36 +0100, Christophe Oosterlynck wrote:
> Hi, > > The pipeline used by playbin2 is similar to: > filesrc ! mpegvideoparse ! queue ! mpeg2dec ! xvimagesink It actually has a queue before the sink (which is important, because otherwise you're throttling the mpeg2dec processing everytime an outputted frame needs to wait for its display time). None the less, various fixes (including performance ones) have gone into mpegvideoparse and other elements since that release. _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
I forgot to mention that I've tried the HEAD of the 0.10 branch already as I saw some performance fixes there. However, it doesn't make any difference. Would 0.11 make a big difference?
The fact that inserting a queue between the filesrc and the mpegvideoparse element solves my problem, is not relevant? I shouldn't be focussing on that but rather on performance issues in mpegvideoparse? It probably won't be any other element as I have the same result when using fluvadec + fluvasink instead of mpeg2dec + xvimagesink.
On Wed, Nov 14, 2012 at 4:14 PM, Edward Hervey <[hidden email]> wrote: On Wed, 2012-11-14 at 10:36 +0100, Christophe Oosterlynck wrote: _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
I meant 1.0 instead of 0.11
On Wed, Nov 14, 2012 at 4:20 PM, Christophe Oosterlynck <[hidden email]> wrote: I forgot to mention that I've tried the HEAD of the 0.10 branch already as I saw some performance fixes there. However, it doesn't make any difference. Would 0.11 make a big difference? _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
In reply to this post by Christophe Oosterlynck
On Wed, 2012-11-14 at 16:20 +0100, Christophe Oosterlynck wrote:
Hi, > The fact that inserting a queue between the filesrc and the > mpegvideoparse element solves my problem, is not relevant? I shouldn't > be focussing on that but rather on performance issues in > mpegvideoparse? It is an interesting observation, because at first glance it seems somewhat implausible. If you put a queue between filesrc and the parser, you force the parser to operate in push mode rather than pull mode, so the flow is going to be like: while (filesrc_read_data) mpeg_video_parse_chain () whereas if the parser operates in pull mode, it should be like: while (parser_pull_data_from_filesrc) mpeg_video_parse_chain () (Not necessarily literally, but in principle). Maybe the parser is pulling way too small chunks from filesrc in one go, leading to lots of buffer merging overhead, while filesrc reads larger buffers in one go? It would be interesting to profile. There are also some patches in bugzilla I think, but they apply to both modes of operation equally. Not sure if 1.0 (no more 0.11) will make a huge difference, likely not - but only one way to find out :) It would certainly increase the chances of someone looking at profiling results or patches. Cheers -Tim > On Wed, Nov 14, 2012 at 4:14 PM, Edward Hervey <[hidden email]> > wrote: > On Wed, 2012-11-14 at 10:36 +0100, Christophe Oosterlynck > wrote: > > Hi, > > > > > The pipeline used by playbin2 is similar to: > > filesrc ! mpegvideoparse ! queue ! mpeg2dec ! xvimagesink > > > It actually has a queue before the sink (which is important, > because > otherwise you're throttling the mpeg2dec processing everytime > an > outputted frame needs to wait for its display time). > > None the less, various fixes (including performance ones) have > gone into > mpegvideoparse and other elements since that release. > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
It seems that gstreamer 1.0 plays my clip smoothly without a queue between filesrc and mpegvideoparse. I tried finding out which patch could have solved my issue. I thought it was bug 672701 [1] but the patch for this is already in 0.10 branch and I still have the problem when using the HEAD of 0.10 branch.
I have attached profiling results to this mail:
callgrind.out.noqueue = gstreamer-0.10 and no queue between filesrc and mpegvideoparse = slow callgrind.out.queue = gstreamer-0.10 and queue between filesrc and mpegvideoparse = smooth
callgrind.out.1.0 = gstreamer-1.0 and no queue between filesrc and mpegvideoparse = smooth Any other ideas how this might have been solved in the 1.0 version? I would like to backport the fix to 0.10 as I'm using QtMobility which uses gstreamer-0.10. Thanks,
Christophe On Wed, Nov 14, 2012 at 4:40 PM, Tim-Philipp Müller <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel callgrind.out.tar.gz (641K) Download Attachment |
Free forum by Nabble | Edit this page |