[Ffmpeg-cvslog] CVS: ffmpeg/libavformat mov.c,1.101,1.102

The Wanderer inverseparadox
Sat Mar 11 00:35:59 CET 2006

Michael Niedermayer wrote:

> Hi
> On Fri, Mar 10, 2006 at 03:23:06PM -0500, The Wanderer wrote:
>> Michael Niedermayer CVS wrote:
>>> Update of /cvsroot/ffmpeg/ffmpeg/libavformat
>>> In directory mail:/var2/tmp/cvs-serv12806
>>> Modified Files:
>>> 	mov.c 
>>> Log Message:
>>> simplify timebase if possible
>>> ignore edit lists instead of always failing
>> <snip>
>>> @@ -2109,8 +2125,13 @@
>>>             pts = dts + duration;
>>>         }else
>>>             pts = dts;
>>> -        pkt->pts = pts;
>>> -        pkt->dts = dts;
>>> +
>>> +        st= s->streams[ sc->ffindex ];
>>> +        assert(pts % st->time_base.num == 0);
>> I have files which fail to play (in MPlayer with -demuxer lavf) on
>> this assertion. Is there information I could provide which would be
>> useful in tracking down why (the 'in case of a crashing bug'
>> information doesn't seem obviously appropriate, since this isn't
>> really a crash), or should I just upload one of the files to
>> incoming/?
> hmm what values do st->time_base.num/den/pts have?

According to gdb, at the point at which the failure would occur:

st->time_base.num: 2048
st->time_base.den: 48000
pts: 4160

(Weirdly enough, attempting to 'step' forward from there to confirm that
the failure does in fact occur immediately afterward resulted in gdb
maxing my CPU with no output for the fifteen seconds or so before I
interrupted it. It doesn't take nearly that long for a failure to occur
when running the program independently...)

> and yes upload a file

Uploading now (at ungodly slow rates), filename 'op174 - bad pts vs.
time base numerator.mp4'. The accompanying text file just reiterates the
basic problem.

(Here's hoping I haven't forgotten something...)

       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.

More information about the ffmpeg-cvslog mailing list