[Ffmpeg-devel] Possible bug in reading PTS/DTS
Mon Apr 23 11:26:34 CEST 2007
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
> 5) look at the output:
> FFmpeg version SVN-r8792, Copyright (c) 2000-2007 Fabrice Bellard, et al.
> 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
> 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:
> dts=0.000 pts=0.000
> stream #1:
> dts=0.002 pts=0.002
> stream #1:
> dts=0.019 pts=0.019
> stream #0:
> dts=8589.931 pts=0.000
> timestamp discontinuity 95443677689, new offset= -95443677689
> stream #0:
> dts=8589.935 pts=8589.938
> 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
> 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
> (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.
T +32  2 790 29 41
F +32  2 790 29 02
E mailto:mbardiaux at mediaxim.be
Vorstlaan 191 Boulevard du Souverain
Brussel 1160 Bruxelles
More information about the ffmpeg-devel