$ 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.

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. ;).

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?

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.

Created attachment 28788 [details]
spider+alsasink pipeline clocking log

Created attachment 28789 [details]
spider+osssink pipeline clocking log

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.

Unlikely to be fixed, but still a bug. Leave it open, even if only to dup others
to here.

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.

... so please just answer ... :)

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.

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.