<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=Windows-1252"> <META NAME="Generator" CONTENT="MS Exchange Server version 6.0.6487.1"> <TITLE>RE: [gst-devel] Regarding the broken MPEG</TITLE> </HEAD> <BODY>  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 </BODY> </HTML>