[FFmpeg-devel] [Bugreport] and [Patch]: duration of TS streams is wrong when used near 2^33 wrap

Måns Rullgård mans
Mon Oct 29 11:40:29 CET 2007

Thorsten Jordan wrote:
> Hello,
> in libavformat/utils.c, the function av_estimate_timings_from_pts() is
> used also for TS streams. It seeks to begin of file and gets a PTS value
>  from a stream's packet and one value from the end.
> It then computes:
> line 1559ff:
> ***snip***
> 	...
>             end_time = pkt->pts;
>             duration = end_time - st->start_time;
>             if (duration > 0) {
> 	...
> ***snap***
> now for TS the PTS values are wrapping around at 2^33, so if the start
> pts is near 2^33 and the end pts is beyond it, end < start is true
> trivially, leading to no computed duration.
> How to fix that?
> e.g.: compute duration = (2^33 + end - start) & (2^33-1)
> pro: works for this and similar files
> con: would give still wrong values if the file is longer than 2^33 pts
> (26.5 hours), but rare case

It would fail also if the file has random PTS resets, as is quite common
on DVDs and some TV channels.

> it would not hurt for PS streams, as for PS the PTS is max. 2^32 iirc.

PS also uses 33-bit PTS.

> The attached patch does that.

I think this is a problem we shouldn't even be trying to solve.  If you
really must know the exact duration of the file you'll have to parse
the whole thing.

I'm inclined to say that rather than trying to guess the unknown, we should
simply report the duration of these files as unknown.

M?ns Rullg?rd
mans at mansr.com

More information about the ffmpeg-devel mailing list