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

[Michael Niedermayer]

On Thu, Aug 23, 2012 at 09:07:11PM +0300, Andrey Utkin wrote:
> 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(-)

somethimg similar commited

thanks

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

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120824/fc3fa434/attachment.asc>