[gst-devel] Regarding the broken MPEG

[Bultje, R.S.]

Hi Benjamin,

thanks for the reply.

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

Yes, the timestamps are correct. I first thought of that, too.

It'd be really cool if you could help with this. :).

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

Hm, is there any chance I can test that this is happening?

Anyway, since this seems to be a theoretical issue, and maybe practical: can we prevent this? E.g. by adding a max. wait time, after which the video clock waits up?

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

Seems reasonable, I'll check that.

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

I'll do some more testing. Do you have any ideas on how tim improve all this (clocking) so that default spider video pipelines work? :).

Ronald
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20040301/5314c47b/attachment.htm>