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

[Michael Niedermayer]

Hi

On Sat, Aug 11, 2007 at 07:52:51AM +1000, Neil Brown wrote:
> 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 

this is a bug


> and st->duration to the estimate of 4:41 even though
> st->duration already has the correct value of 300837 (5:00).

this is a bug as well


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070811/71859ca3/attachment.pgp>