[Ffmpeg-devel] Possible bug in reading PTS/DTS

[Michel Bardiaux]

Luca Abeni wrote:
> Hi all,
> 
> I found a "strange feature" in ffmpeg. Basically, in some cases video 
> PTSs and DTSs read from a stream have a strange offset respect to audio 
> timestamps (I noticed this problem when trying to debug a strange 
> ffserver behaviour, but the problem appears in ffmpeg.c too).
> 
> How to reproduce the problem:
> 1) Get ffmpeg from svn
> 2) Configure and compile; compile output_example
> 3) ./output_example test.mpg
> 4) ./ffmpeg -v 10 -dump -i test.mpg -f avi /dev/null
> (the "-f avi /dev/null" part is not relevant; the problem is in reading 
> test.mpg)
> 5) look at the output:
> FFmpeg version SVN-r8792, Copyright (c) 2000-2007 Fabrice Bellard, et al.
>    configuration:
>    libavutil version: 49.4.0
>    libavcodec version: 51.40.4
>    libavformat version: 51.12.1
>    built on Apr 23 2007 09:26:45, gcc: 4.1.2 20060928 (prerelease) 
> (Ubuntu 4.1.1-13ubuntu5)
> Input #0, mpeg, from 'test.mpg':
>    Duration: 00:00:01.8, start: 0.000000, bitrate: 1802 kb/s
>    Stream #0.0[0x1e0], 1/90000: Video: mpeg1video, yuv420p, 352x288, 
> 1/25, 104857 kb/s, 25.00 fps(r)
>    Stream #0.1[0x1c0], 1/90000: Audio: mp2, 44100 Hz, stereo, 64 kb/s
> File '/dev/null' already exists. Overwrite ? [y/N] Output #0, avi, to 
> '/dev/null':
>    Stream #0.0, 1/90000: Video: mpeg4, yuv420p, 352x288, 1/25, q=2-31, 
> 200 kb/s, 25.00 fps(c)
>    Stream #0.1, 1/90000: Audio: mp2, 44100 Hz, stereo, 64 kb/s
> Stream mapping:
>    Stream #0.0 -> #0.0
>    Stream #0.1 -> #0.1
> Press [q] to stop encoding
> stream #1:
>    keyframe=1
>    duration=0.002
>    dts=0.000  pts=0.000
>    size=208
> stream #1:
>    keyframe=1
>    duration=0.002
>    dts=0.002  pts=0.002
>    size=209
> [...]
> stream #1:
>    keyframe=1
>    duration=0.002
>    dts=0.019  pts=0.019
>    size=209
> stream #0:
>    keyframe=1
>    duration=0.004
>    dts=8589.931  pts=0.000
>    size=6731
> timestamp discontinuity 95443677689, new offset= -95443677689
> stream #0:
>    keyframe=0
>    duration=0.004
>    dts=8589.935  pts=8589.938
>    size=3135
> 
> See? There is a big jump between audio and video PTSs (audio and video 
> are supposed to be synchronized, so the PTSs should be comparable, no?). 
> The "timestamp discontinuity..." message appears every time there is a 
> switch between audio and video packets.
> 
> My understanding of the problem:
> I think the problem is due to the fact that only 33 bits of the ts are 
> valid, while someone (ffmpeg.c or libavformat/utils.c) gets confused and 
> considers 64 bits... The problem happens every time the ts cross the 
> 2^33 value. output_example makes it more visible because it generates a 
> first DTS equal to -3600, so the first DTS seen by ffmpeg.c is 
> 8589930992 (= 2^33 - 3600). ffmpeg is wrong in thinking it is a big 
> value (ffmpeg.c seems to think it is a 64bit value), because it 
> represents a negative value (it really is a 33bit value). Then, things 
> become even more messy... The second PTS/DTS pair should be 3600/0, but 
> ffmpeg.c sees 8589938192/8589934592 (note that this is 3600/0 + 2^33). 
> This happens because libavformat/utils.c:compute_pkt_fields() changes 
> the timestamps from 3600/0 to those values by calling lsb2full().
> 
> This bug (if it is a bug) can be easily fixed by adding a "& 
> st->pts_wrap_bits" in all the places where ffmpeg.c uses pkt.pts and 
> pkt.dts.
> 
> My question:
> where is the bug?
> In ffmpeg.c (and ffserver.c), that should use only 33 bits of the ts (as 
> suggested above), or in libavformat, that should present timestamps so 
> that user programs do not have to care about st->pts_wrap_bits?
> I would tend to say the problem is in ffmpeg.c, but I'd like to have a 
> confirmation...
> (If the problem really is in the user application, I can prepare and 
> send a patch fixing ffmpeg.c and ffserver.c)
> 
> Or maybe the problem is in my (mis)understanding of this issue?

I'm not sure the problem is in decoding. I find it rather strange that 
the first frame, which is a keyframe, does not have PTS=DTS.

That said, given a file with timestamps crossing the 33-bits boundary, I 
dont think the solution should be to reproduce internally the deficiency 
of the container. Instead, the sequence of TS should always be 
increasing, in this case 2^33 should be added to *every* PTS and DTS.

Greetings,
-- 
Michel Bardiaux
R&D Director
T +32 [0] 2 790 29 41
F +32 [0] 2 790 29 02
E mailto:mbardiaux at mediaxim.be

Mediaxim NV/SA
Vorstlaan 191 Boulevard du Souverain
Brussel 1160 Bruxelles
http://www.mediaxim.com/