<font face="verdana, sans-serif" style="font-size:13px">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.</font><div style="font-family:arial,sans-serif;font-size:13px">

<font face="verdana, sans-serif"><br></font></div><div style="font-family:arial,sans-serif;font-size:13px"><font face="verdana, sans-serif">I have attached profiling results to this mail:</font></div><div style="font-family:arial,sans-serif;font-size:13px">

<font face="verdana, sans-serif">callgrind.out.noqueue = gstreamer-0.10 and no queue between filesrc and mpegvideoparse = slow</font></div><div style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:verdana,sans-serif">callgrind.out.queue = gstreamer-0.10 and queue between filesrc and mpegvideoparse = smooth</span></div>

<div style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:verdana,sans-serif">callgrind.out.1.0 = gstreamer-1.0 and no queue between filesrc and mpegvideoparse = smooth</span><font face="verdana, sans-serif"><br>

</font><div><font face="verdana, sans-serif"><br></font></div><div><font face="verdana, sans-serif">[1] </font><a href="https://bugzilla.gnome.org/show_bug.cgi?id=672701" target="_blank">https://bugzilla.gnome.org/show_bug.cgi?id=672701</a></div>

<div><br></div><div>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.</div><div><br></div><div>Thanks,</div>

<div><br></div><div>Christophe</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 14, 2012 at 4:40 PM, Tim-Philipp Müller <span dir="ltr"><<a href="mailto:t.i.m@zen.co.uk" target="_blank">t.i.m@zen.co.uk</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, 2012-11-14 at 16:20 +0100, Christophe Oosterlynck wrote:<br>
<br>
Hi,<br>
<br>
</div><div class="im">> The fact that inserting a queue between the filesrc and the<br>
> mpegvideoparse element solves my problem, is not relevant? I shouldn't<br>
> be focussing on that but rather on performance issues in<br>
> mpegvideoparse?<br>
<br>
</div>It is an interesting observation, because at first glance it seems<br>
somewhat implausible. If you put a queue between filesrc and the parser,<br>
you force the parser to operate in push mode rather than pull mode, so<br>
the flow is going to be like:<br>
<br>
   while (filesrc_read_data)<br>
     mpeg_video_parse_chain ()<br>
<br>
whereas if the parser operates in pull mode, it should be like:<br>
<br>
   while (parser_pull_data_from_filesrc)<br>
     mpeg_video_parse_chain ()<br>
<br>
(Not necessarily literally, but in principle). Maybe the parser is<br>
pulling way too small chunks from filesrc in one go, leading to lots of<br>
buffer merging overhead, while filesrc reads larger buffers in one go?<br>
<br>
It would be interesting to profile. There are also some patches in<br>
bugzilla I think, but they apply to both modes of operation equally.<br>
<br>
Not sure if 1.0 (no more 0.11) will make a huge difference, likely not -<br>
but only one way to find out :) It would certainly increase the chances<br>
of someone looking at profiling results or patches.<br>
<br>
 Cheers<br>
<span class="HOEnZb"><font color="#888888">  -Tim<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
> On Wed, Nov 14, 2012 at 4:14 PM, Edward Hervey <<a href="mailto:bilboed@gmail.com">bilboed@gmail.com</a>><br>
> wrote:<br>
>         On Wed, 2012-11-14 at 10:36 +0100, Christophe Oosterlynck<br>
>         wrote:<br>
>         > Hi,<br>
><br>
>         ><br>
>         > The pipeline used by playbin2 is similar to:<br>
>         > filesrc ! mpegvideoparse ! queue ! mpeg2dec ! xvimagesink<br>
><br>
><br>
>         It actually has a queue before the sink (which is important,<br>
>         because<br>
>         otherwise you're throttling the mpeg2dec processing everytime<br>
>         an<br>
>         outputted frame needs to wait for its display time).<br>
><br>
>         None the less, various fixes (including performance ones) have<br>
>         gone into<br>
>         mpegvideoparse and other elements since that release.<br>
><br>
>         _______________________________________________<br>
>         gstreamer-devel mailing list<br>
>         <a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
>         <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
><br>
><br>
> _______________________________________________<br>
> gstreamer-devel mailing list<br>
> <a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
> <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br>
<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</div></div></blockquote></div><br></div>