[FFmpeg-devel] [patch 3/3] Make timing calculations less dependant on start_time being defined.

[Michael Niedermayer]

Hi

On Fri, Aug 24, 2007 at 02:16:47PM +1000, Neil Brown wrote:
[...]
> > > So I could
> > >    ffmpeg -ss 0:0:1.15  .... -async 1
> > > 
> > > And get a correctly decoded file, but that really shouldn't be needed.
> > > 
> > > So: would you accept this?
> > 
> > what about setting dts_delta_threshold to something small? (no iam not
> > suggesting this as solution, just curious, it think it should fix this)
> 
> Yes, setting -dts_delta_threshold to 1 removes the leading black
> silences, and gives my audio and video in sync.
> 
> 
> Having reflected on this some more, I think a code problem is really
> that start_time isn't being set properly.
> ffmpeg clearly doesn't cope well with start_time being AV_NOPTS_VALUE
> unless the first frame in the file has a pts of 0.
> The MLT framework (used by kdenlive) also seem to handle this
> situation poorly.
> 
> Maybe we should be reading the beginning of the stream and looking for
> the pts in the first packet?

yes


> 
> I note that 'utils.c' does this via av_estimate_timings_from_pts but
> only for mpeg and mpegts.  I tried calling that if 'asf' as well, but
> that didn't work - something got badly confused.
> 
> [asf @ 0x2b63e74d9780]ff asf bad header e1  at:9402
> [asf @ 0x2b63e74d9780]invalid packet_length -511371426 at:9405
> [asf @ 0x2b63e74d9780]freeing incomplete packet size 2437, new 4831
> 
> I guess it would need to be more careful about stepping over the file
> header???

the asf demuxer is a little sensitive with having the file position moved
around randomly like av_estimate_timings_from_pts does, and no i dont know
precissely what is causing the problem here

also i agree that ideally we should use av_estimate_timings_from_pts for
more formats than just mpeg (actually for all which have a
AVInputFormat.read_timestamp() which simply means all which are capable
to find the timestamp based on some file position
also maybe av_estimate_timings_from_pts() should be changed to use
read_timestamp() instead of low level seeking behind the demuxers
back ...

but none of this is really needed for solving the start_time issue its
needed for finding a accurate duration though if none is provided by
the file header ... actually i dont know if there are many cases where
thats the case
to find the start_time simply setting it if its unknown from the
pkt.pts after the call to av_read_frame_internal() in av_find_stream_info()
should do the trick ...

patch welcome like always :)

i wonder why iam too lazy to just commit such trivial fixes directly ...
but actually i think this has its advantages, as other people work with
the code to fix these issues and it improves their understanding of the
code -> more people who understand the code -> more people who can work
with the code, review patches, fix bugs, ...

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

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- 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/20070824/cd44f92a/attachment.pgp>