[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):
Hi,
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
broken.
* 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
problem.
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.
Thanks,
Tzvi
--
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