<!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>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Hi Benjamin,<BR>
<BR>
thanks for the reply.<BR>
<BR>
> > gst-launch-0.7 filesrc location=/media/clips/Trance\ Energy\ 2002\<BR>
> > DvDSebRip.avi ! avidemux name=demux .video_00 ! ffdec_mpeg4 !<BR>
> > ffcolorspace ! ximagesink demux.audio_00 ! mad ! osssink<BR>
> ><BR>
> > gives me the "very slow playback" thing.<BR>
> ><BR>
> _if_ there are no timestamp issues (that is you're absolutely sure from<BR>
> looking at gst-launch -v with fakesinks that the timestamps of every buffer<BR>
> are correct) I have no good idea how that would happen, though it's probably<BR>
> something simple I haven't thought about.<BR>
<BR>
Yes, the timestamps are correct. I first thought of that, too.<BR>
<BR>
It'd be really cool if you could help with this. :).<BR>
<BR>
> The problem:<BR>
> When you use the above pipeline and the videosink goes into a wait for a<BR>
> time that is bigger than the maximum time possible with all samples<BR>
> processed, we run into a deadlock, because the clock won't move forwards and<BR>
> the videosink won't stop waiting.<BR>
<BR>
Hm, is there any chance I can test that this is happening?<BR>
<BR>
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?<BR>
<BR>
> > 10s with a segfault, after a "(process:13131): GStreamer-CRITICAL **:<BR>
> > file gstdata.c: line 242 (gst_data_unref): assertion<BR>
> > `GST_DATA_REFCOUNT_VALUE (data) > 0' failed"... Result seems to be<BR>
> > random, though, since I didn't get that warning the second time I ran it<BR>
> > outside a debugger (still a segfault, though).<BR>
> ><BR>
> That assertion has in all cases that I fixed been caused by unreffing an<BR>
> event after gst_pad_event_default'ing it. gst_pad_event_default takes the<BR>
> reference. I'm pretty sure audio is fine (I haven't seen this for a long<BR>
> time in Rhythmbox), so I'd blame avidemux or ffdec.<BR>
<BR>
Seems reasonable, I'll check that.<BR>
<BR>
> > gst-launch-0.7 filesrc location=/media/clips/Trance\ Energy\ 2002\<BR>
> > DvDSebRip.avi ! avidemux name=demux .video_00 ! { queue ! ffdec_mpeg4 !<BR>
> > ffcolorspace ! ximagesink } demux.audio_00 ! { queue ! mad ! osssink }<BR>
> ><BR>
> > works.<BR>
> ><BR>
> This is because you have 2 queues, so there's always enough data in both<BR>
> queues. The difference between clocks and waits will never be big enough so<BR>
> that one queue is empty while the other is full and waits for the time to<BR>
> advance.<BR>
<BR>
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? :).<BR>
<BR>
Ronald</FONT>
</P>
</BODY>
</HTML>