[FFmpeg-devel] [PATCH] estimate stream durations using read_timestamp
Sat May 24 17:12:19 CEST 2008
On Sat, May 24, 2008 at 02:28:09PM +0200, elupus wrote:
> On Sat, 24 May 2008 14:15:23 +0200, Michael Niedermayer wrote:
> > On Sat, May 24, 2008 at 01:04:24PM +0200, elupus wrote:
> >> On Sat, 24 May 2008 13:00:53 +0200, elupus wrote:
> >>> Hi,
> >>> Here is a patch for libavformat to estimate stream durations using the
> >>> read_timestamp interface. This could most likely replace the special casing
> >>> for mpeg using read_packet. Thou i've not yet checked that.
> > your code is a duplicate of av_estimate_timings_from_pts().
> > One of the 2 has to be removed or you will have to explain why both are
> > usefull.
> > [...]
> Agreed, the new function doesn't use as you put it "undefined behavior" (in
> the nuv thread) of seeking the input stream somewhere and expecting
> read_packet to work. Thus it is more general.
Its undefined behavior from the user application. Its not undefined from
libavformat. After all demuxers themselfs can also use url_fseek().
> Then again, it does have to read each stream since read_timestamp is stream
> specific. Current code would read whole file if a stream doesn't contain
> one of the stream. Should be fixable with a check for
> DURATION_MAX_READ_SIZE in it too.
> Will fix that, remove the old function and test it with some mpegs and see
> that it doesn't seem to break anything.
We also would need benchmarks to see what effect the change has on speed,
especially with files with many streams (mpeg ts with 20 streams has to be
not slower ...)
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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel