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 144384 - [opt/mpeg] slow playback
[opt/mpeg] slow playback
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: 0.8.5
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 138435
 
 
Reported: 2004-06-15 05:07 UTC by Ronald Bultje
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
spider+alsasink pipeline clocking log (3.59 KB, text/plain)
2004-06-17 03:24 UTC, Ronald Bultje
Details
spider+osssink pipeline clocking log (18.20 KB, text/plain)
2004-06-17 03:24 UTC, Ronald Bultje
Details

Description Ronald Bultje 2004-06-15 05:07:04 UTC
Play http://gstreamer.freedesktop.org/media/incoming/Metallica - One.mpg

Horribly slow (no CPU usage) using opt. Basicgthread is fine.
Comment 1 Johan (not receiving bugmail) Dahlin 2004-06-15 08:58:41 UTC
$ gst-launch filesrc location=Metallica\ -\ One.mpg ! mpegdemux name=demux ! {
queue ! mpeg2dec ! xvimagesink } { demux. ! queue ! mad ! osssink }

Works just fine here. Assume that you're talking about gst-player which uses
only one thread.
Comment 2 Ronald Bultje 2004-06-15 14:02:02 UTC
gst-player uses multiple threads, but the queues are located differently. And
yes, I'm talking about gst-player. End users don't use gst-launch. ;).
Comment 3 Ronald Bultje 2004-06-15 16:40:16 UTC
I'll try to be somewhat more clear.

The pipeline that always works is:

gst-launch filesrc location=file.mpg ! mpegdemux name=d ! { queue ! mpeg2dec !
ffcolorspace ! ximagesink } d. ! { queue ! mad ! audioconvert ! audioscale!
audiosink }

The pipeline in gst-player that fails:

gst-launch filesrc location=file.mpg ! spider name=s ! { queue ! ffcolorspace !
ximagesink } s. ! { queue ! audioconvert ! audioscale! audiosink }

Which - though I'll have to confirm this tonight - essentially expands to this
pipeline (there's some spideridentities that I'm leaving out):

gst-launch filesrc location=file.mpg ! mpegdemux name=d ! mpeg2dec { queue !
ffcolorspace ! ximagesink } d. ! mad ! { queue ! audioconvert ! audioscale!
audiosink }

The exact questions that I'm interested in:
* why does the one work using opt and the other doesn't, whereas both work using
 basigthread? More in detail, why does the location of a queue around
non-syncing/non-waiting elements (the decoders) make a difference? They should
just process data; why do they wait?
* which element (or is it the scheduler) is responsible for this?
* how should we design a solution?
Comment 4 Ronald Bultje 2004-06-17 03:23:33 UTC
Something interesting. I confirmed (from spider debug logs) that spider indeed
plugs the above line. However, the same pipeline without spider plugging that
together works fine. How are those different? So in gst-launch:

./gst-launch filesrc location=/media/clips/Metallica\ -\ One.mpg ! spider name=s
! { queue ! ffcolorspace ! ximagesink } s. ! { queue ! audioconvert ! audioscale
! alsasink }

is slow.

./gst-launch filesrc location=/media/clips/Metallica\ -\ One.mpg ! mpegdemux
.video_00 ! mpeg2dec ! { queue ! ffcolorspace ! ximagesink } mpegdemux0.audio_00
! mad ! { queue ! audioconvert ! audioscale ! alsasink }

is ok.

Why? Is this because of the spideridentities? That seems unlikely. So is spider
doing something odd to added elements that doesn't happen by default? Or the
reverse, so not doing something that normally happens?

Also, the spider+alsa+thread one hangs, the spider+oss/esd+thread ones don't
hang but are still extremely sluggish. Clocking logs of oss and alsa follow.
Comment 5 Ronald Bultje 2004-06-17 03:24:14 UTC
Created attachment 28788 [details]
spider+alsasink pipeline clocking log
Comment 6 Ronald Bultje 2004-06-17 03:24:45 UTC
Created attachment 28789 [details]
spider+osssink pipeline clocking log
Comment 7 Thomas Vander Stichele 2004-07-06 13:33:49 UTC
is it correct when I say that the problem you're seeing is not reproducible in
gst-launch, without spider in the pipeline, but it is with spider in the pipeline ?

Like I said, bugs in opt without spider can be fixed.  Bugs with spider involved
are unlikely to get fixed by anyone.
Comment 8 Ronald Bultje 2004-07-06 14:06:23 UTC
Unlikely to be fixed, but still a bug. Leave it open, even if only to dup others
to here.
Comment 9 Thomas Vander Stichele 2004-07-06 14:59:06 UTC
I didn't close it :) I'm just trying to establish if it's something that is
likely/possible to be fixed anytime soon.  So please just answer so I can focus
on the bugs we are trying to get fixed.
Comment 10 Thomas Vander Stichele 2004-07-16 13:39:27 UTC
... so please just answer ... :)
Comment 11 Ronald Bultje 2004-07-16 16:00:14 UTC
I answered, the question is yes. If you add any loopbased element in between the
decoders, it shows that behaviour, and hence it does that same thing for spider.
Comment 12 Ronald Bultje 2004-09-13 21:14:31 UTC
Well, whatever, playbin plays this and since we'll now have a player that plays
this I guess I don't care any longer. Let's mark this solved.