[FFmpeg-devel] [PATCH] Don't produce potential double jump of timestamps on wrap

[Andrey Utkin]

The mpegts streams i work with sometimes get processed by lavf demuxer in such way:
Demuxed packet st:0 dts:8589889675 pts:8589893275 dur:3600 f:0x0
Demuxed packet st:0 dts:8589893275 pts:8589896875 dur:3600 f:0x0
Demuxed packet st:0 dts:8589896875 pts:8589900475 dur:3600 f:0x0
Demuxed packet st:0 dts:8589900475 pts:8589904075 dur:3600 f:0x0
Demuxed packet st:0 dts:8589904075 pts:8589907675 dur:3600 f:0x0
Demuxed packet st:0 dts:8589907675 pts:8589918475 dur:3600 f:0x0
Demuxed packet st:0 dts:8589911275 pts:8589911275 dur:3600 f:0x0
Demuxed packet st:0 dts:8589914875 pts:8589914875 dur:3600 f:0x0
Demuxed packet st:0 dts:8589918475 pts:8589929275 dur:3600 f:0x0
Demuxed packet st:0 dts:8589922075 pts:8589922075 dur:3600 f:0x0
Demuxed packet st:0 dts:8589925675 pts:8589925675 dur:3600 f:0x0
Demuxed packet st:0 dts:-5317 pts:5483 dur:3600 f:0x1
Demuxed packet st:0 dts:8589932875 pts:8589932875 dur:3600 f:0x0
Demuxed packet st:0 dts:1883 pts:1883 dur:3600 f:0x0
Demuxed packet st:0 dts:5483 pts:16283 dur:3600 f:0x0
Demuxed packet st:0 dts:9083 pts:9083 dur:3600 f:0x0
Demuxed packet st:0 dts:12683 pts:12683 dur:3600 f:0x0
Demuxed packet st:0 dts:16283 pts:27083 dur:3600 f:0x0
Demuxed packet st:0 dts:19883 pts:19883 dur:3600 f:0x0
Demuxed packet st:0 dts:23483 pts:23483 dur:3600 f:0x0
Demuxed packet st:0 dts:27083 pts:30683 dur:3600 f:0x0
Demuxed packet st:0 dts:30683 pts:34283 dur:3600 f:0x0
Demuxed packet st:0 dts:34283 pts:37883 dur:3600 f:0x0
Demuxed packet st:0 dts:37883 pts:41483 dur:3600 f:0x0
Demuxed packet st:0 dts:41483 pts:45083 dur:3600 f:0x0

This is usual mpegts timestamps discontinuity caused by overflow of 33 bits which hold time info. This field overflows every 26.5 hours.
It would be nothing to blame lavf, if not a _second_ jump, i mean dts:8589932875 after dts:-5317.
This makes handling of stream complicated. As you see, the timestamps in stream are actually correct.
Negative dts does not come from mpegts stream of demuxer, it is result of special processing in lavf/utils.c, and exactly that place is patched.
The patch i post eliminates this second jump, so demuxed packets will have such timestamps:
Demuxed packet st:0 dts:8589925675 pts:8589925675 dur:3600 f:0x0
Demuxed packet st:0 dts:8589929275 pts:8589940075 dur:3600 f:0x1
Demuxed packet st:0 dts:8589932875 pts:8589932875 dur:3600 f:0x0
Demuxed packet st:0 dts:1883 pts:1883 dur:3600 f:0x0

I could not think of other cases which are affected in unintended way by this patch, but it would be good if somebody finds such cases.

Forged file that reproduces this situation: http://dl.dropbox.com/u/43104344/ts_with_wrap_causing_bug.ts

---8<---
---
 libavformat/utils.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 251cd11..ab4d9f7 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1021,7 +1021,7 @@ static void compute_pkt_fields(AVFormatContext *s, AVStream *st,
         presentation_delayed = 1;
 
     if(pkt->pts != AV_NOPTS_VALUE && pkt->dts != AV_NOPTS_VALUE && pkt->dts - (1LL<<(st->pts_wrap_bits-1)) > pkt->pts && st->pts_wrap_bits<63){
-        pkt->dts -= 1LL<<st->pts_wrap_bits;
+        pkt->pts += 1LL<<st->pts_wrap_bits;
     }
 
     // some mpeg2 in mpeg-ps lack dts (issue171 / input_file.mpg)
-- 
1.7.8.6