[FFmpeg-devel] Change 9963 introduces regression - start_time in asf.c

[Neil Brown]

On Friday August 10, michaelni at gmx.at wrote:
> Hi
> 
> On Fri, Aug 10, 2007 at 05:10:12PM +1000, Neil Brown wrote:
> > 
> > I have a video file:
> > 
> >    Seems stream 1 codec frame rate differs from container frame rate: 1000.00 (1000/1) -> 25.00 (25/1)
> >    Input #0, asf, from '/var/tmp/100 Celebration Presentation 1 - Final (v3w).wmv':
> >      Duration: 00:05:00.8, start: 1.579000, bitrate: 1550 kb/s
> >      Stream #0.0: Audio: wmav2, 44100 Hz, stereo, 160 kb/s
> >      Stream #0.1: Video: wmv3, yuv420p, 720x576, 1500 kb/s, 25.00 fps(r)
> > 
> > which is (as you can see) 5 minutes long.  When I look at it with
> > a more recent ffmpeg, I get a different duration:
> > 
> >   Duration: 00:04:41.0, start: 0.000000, bitrate: 1660 kb/s
> > 
> > (The same happens when I load it into kdenlive which uses ffmpeg libraries).
> > 
> > This has only started happening recently and I tracked it down to
> > change 9963 in ffmpeg.
> > 
> >   r9963 | michael | 2007-08-07 06:36:55 +1000 (Tue, 07 Aug 2007) | 2 lines
> > 
> >   ignore preroll, it is generally not what AVStream.start_time should contain
> 
> this change does not change AVStream.duration at least not directly so you 
> will have to provide
> more information (that is everything that is needed to reproduce the bug)
> or we cant help you
> 

I'll see if I can figure out how to produce a suitable 'test' wmv
file, but until then, maybe the following observations might get us a
bit closer?

The duration of "04:41.0" gets set in
av_estimate_timings_from_bit_rate.

ic->bit_rate is zero so it sums the individual bit rates of
 160040 and 1500000 to get 1660040
ic->duration is AV_NOPTS_VALUE and filesize is 58319439 so it
calculates a duration with av_rescale of 281051, which is 4:41.
Then because st->start_time == AV_NOPTS_VALUE, it sets st->start_time
to 0 and st->duration to the estimate of 4:41 even though
st->duration already has the correct value of 300837 (5:00).

It seems that if the codec doesn't set the start_time, then
any duration that it sets will be ignored as well - both
av_estimate_timings_from_bit_rate, and av_has_timings require both to
be set.

> 
> > 
> > 
> > Could it be that with this change, start_time isn't being set at all?
> > If it add code to explicitly set it to zero, I get the correct clip
> > length again.
> > Before I set it to 0, it's value is
> >   0x8000000000000000
> 
> start time is correct, your attempt to set it to 0 is _WRONG_
> 

Can you explain why?  Quite a lot of decoders seem to do it.

cd /home/VIDEO/src/ffmpeg/libavformat/
grep -n -e 'start_time *= *0;' *.c /dev/null
aiff.c:384:    st->start_time = 0;
avidec.c:367:            st->start_time = 0;
c93.c:91:    video->start_time = 0;
dv.c:220:       c->ast[i]->start_time = 0;
dv.c:287:    c->vst->start_time = 0;
dxa.c:130:    s->start_time = 0;
flvdec.c:255:    s->start_time = 0;
img2.c:216:        st->start_time = 0;
libnut.c:230:        st->start_time = 0;
matroskadec.c:2171:            st->start_time = 0;
mov.c:1040:    st->start_time = 0; /* XXX: check */
mov.c:1109:    st->start_time = 0; /* check */
mpc.c:107:    s->start_time = 0;
nsvdec.c:460:            st->start_time = 0;
nsvdec.c:481:            st->start_time = 0;
tta.c:77:    st->start_time = 0;
utils.c:1470:                    st->start_time = 0;
wv.c:157:    s->start_time = 0;


Thanks,
NeilBrown