[Gstreamer-bugs] [Bug 144384] - [opt/mpeg] slow playback

[bugzilla-daemon at bugzilla.gnome.org]

http://bugzilla.gnome.org/show_bug.cgi?id=144384
GStreamer | gstreamer (core) | Ver: HEAD CVS





------- Additional Comments From rbultje at ronald.bitfreak.net  2004-06-15 12:40 -------
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?

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You are the QA contact for the bug, or are watching the QA contact.