[FFmpeg-trac] #735(undetermined:new): Incorrect DTS sync in OGG codec

FFmpeg trac at avcodec.org
Tue Dec 13 10:07:37 CET 2011

#735: Incorrect DTS sync in OGG codec
             Reporter:  zvi       |                    Owner:
                 Type:  defect    |                   Status:  new
             Priority:  normal    |                Component:  undetermined
              Version:  0.8.7     |               Resolution:
             Keywords:  ogg sync  |               Blocked By:
             Blocking:            |  Reproduced by developer:  0
Analyzed by developer:  0         |

Comment (by zvi):


 I have tested against the git HEAD (commit
 8349dbfe46140373082f43ca090dac22696afbb4 from Mon Dec 12 14:48:53 2011
 +0200) and the problem persists.

 You can easily reproduce it using these two commands (I have attached the
 relevant files).
 * ffmpeg -y -i in.mp4 -vcodec libtheora -b 1000k -acodec libvorbis out.ogv
 * ffmpeg -y -i out.ogv -vcodec copy -acodec copy out2.ogv
 * The resulting '''out.ogv''' file is broken (the audio drifts quickly and
 goes out of sync with the video).

 This appears to be a breakage in the '''OGG''' reader, since it happens
 whenever you COPY or possibly even read OGG streams.
 It's ''much worse'' actually when COPYing the stream into a '''webm'''
 container, see attachment ''out2.webm'', where the audio is choppy and
 * ffmpeg -y -i out.ogv -vcodec libvpx -acodec copy out2.webm
 * The resulting '''out2.webm''' has choppy and illegible audio.

 See attached files for examples (you can test the above commands against).

 I've traced ''ffmpeg'' calls to ''av_read_frame()'' and I think I see a
 1. It reads a stream of '''audio''' packets starting with DTS=0 (the
 following packets have no DTS but ffmpeg interpolates it from the first
 valid one it received)
 2. It then reads a stream of '''video''' packets.
 3. Another stream '''audio''' packets comes in. Again, only the first one
 has a DTS defined for it, however, that values is not continuous with the
 last interpolated value in (1). While the ''last'' packet in (1) ''ends''
 with DTS=10941, the ''first'' packet in (3) ''starts'' with DTS=154048.
 There is an unexplained gap here since the DTS has been advancing in steps
 of 64.

 I don't know if that's normal however this doesn't happen in other
 containers (like MP4 & WEBM for example).

 I hope I have provided enough information to go by (output of the calls
 appears in my previous response). If not, please let me know what else
 should I supply.


Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/735#comment:3>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list