[gst-devel] Regarding the broken MPEG

[Benjamin Otte]

Quoting "Ronald S. Bultje" <R.S.Bultje at students.uu.nl>:

> gst-launch-0.7 filesrc location=/media/clips/Trance\ Energy\ 2002\
> DvDSebRip.avi ! avidemux name=demux .video_00 ! ffdec_mpeg4 !
> ffcolorspace ! ximagesink demux.audio_00 ! mad ! osssink
> 
> gives me the "very slow playback" thing.
> 
_if_ there are no timestamp issues (that is you're absolutely sure from 
looking at gst-launch -v with fakesinks that the timestamps of every buffer 
are correct) I have no good idea how that would happen, though it's probably 
something simple I haven't thought about.

How an audiobased clock works (those same issues apply to the old clocking 
system, too):
  
  clock_time = activation_time + processed_samples * framerate

"clock_time" is the time the clock reports.
"activation_time" is the time the clock was activated.
"framerate" is obvious.
"processed_samples" is the number of samples the soundcard has processed (as 
you know you can query the delay to get an exact value). This value has a 
maximum: the number of samples written to the soundcard by the element. 
Measuring time this way assures that music will be played back slowly, but no 
samples will be dropped. (This is important for me when Rb hits a song in my 
collection that's on a HD that needs to spin up - it causes a 7 second delay, 
but the cock nicely waits.)

The problem:
When you use the above pipeline and the videosink goes into a wait for a time
that is bigger than the maximum time possible with all samples processed, we 
run into a deadlock, because the clock won't move forwards and the videosink 
won't stop waiting.

> gst-launch-0.7 filesrc location=/media/clips/Trance\ Energy\ 2002\
> DvDSebRip.avi ! avidemux name=demux .video_00 ! { queue ! ffdec_mpeg4 !
> ffcolorspace ! ximagesink } demux.audio_00 ! mad ! osssink
> 
> works initially. When ran in a debugger, it gives me the "very slow
> playback" thing after +/- 10s. Outside a debugger, it crashes after +/-
> 10s with a segfault, after a "(process:13131): GStreamer-CRITICAL **:
> file gstdata.c: line 242 (gst_data_unref): assertion
> `GST_DATA_REFCOUNT_VALUE (data) > 0' failed"... Result seems to be
> random, though, since I didn't get that warning the second time I ran it
> outside a debugger (still a segfault, though).
> 
That assertion has in all cases that I fixed been caused by unreffing an event 
after gst_pad_event_default'ing it. gst_pad_event_default takes the reference.
I'm pretty sure audio is fine (I haven't seen this for a long time in 
Rhythmbox), so I'd blame avidemux or ffdec.

> gst-launch-0.7 filesrc location=/media/clips/Trance\ Energy\ 2002\
> DvDSebRip.avi ! avidemux name=demux .video_00 ! ffdec_mpeg4 !
> ffcolorspace ! ximagesink demux.audio_00 ! { queue ! mad ! osssink }
> 
> "slow playback thing"
> 
This is most likely the same as without threads, because the main thread waits 
and the audio thread waits in an empty queue.

> gst-launch-0.7 filesrc location=/media/clips/Trance\ Energy\ 2002\
> DvDSebRip.avi ! avidemux name=demux .video_00 ! { queue ! ffdec_mpeg4 !
> ffcolorspace ! ximagesink } demux.audio_00 ! { queue ! mad ! osssink }
> 
> works.
> 
This is because you have 2 queues, so there's always enough data in both 
queues. The difference between clocks and waits will never be big enough so 
that one queue is empty while the other is full and waits for the time to 
advance.


Benjamin