playbin2 and mpeg2 elementary stream: perfomance issue

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

playbin2 and mpeg2 elementary stream: perfomance issue

Christophe Oosterlynck
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
Reply | Threaded
Open this post in threaded view
|

Re: playbin2 and mpeg2 elementary stream: perfomance issue

Edward Hervey
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
Reply | Threaded
Open this post in threaded view
|

Re: playbin2 and mpeg2 elementary stream: perfomance issue

Christophe Oosterlynck
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:
> 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
Reply | Threaded
Open this post in threaded view
|

Re: playbin2 and mpeg2 elementary stream: perfomance issue

Christophe Oosterlynck
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?

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:
> 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
Reply | Threaded
Open this post in threaded view
|

Re: playbin2 and mpeg2 elementary stream: perfomance issue

Tim-Philipp Müller-2
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
Reply | Threaded
Open this post in threaded view
|

Re: playbin2 and mpeg2 elementary stream: perfomance issue

Christophe Oosterlynck
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:
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


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

callgrind.out.tar.gz (641K) Download Attachment