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

[Luca Abeni]

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?



			Thanks,
				Luca