[Ffmpeg-devel] Possible bug in reading PTS/DTS
Mon Apr 23 09:58:26 CEST 2007
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)
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 #0.0 -> #0.0
Stream #0.1 -> #0.1
Press [q] to stop encoding
timestamp discontinuity 95443677689, new offset= -95443677689
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
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?
More information about the ffmpeg-devel