[FFmpeg-trac] #424(avcodec:open): A/V desync on transport stream
FFmpeg
trac at avcodec.org
Thu Oct 20 15:37:54 CEST 2011
#424: A/V desync on transport stream
------------------------------------+-----------------------------------
Reporter: cehoyos | Owner:
Type: defect | Status: open
Priority: normal | Component: avcodec
Version: git-master | Resolution:
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 1
Analyzed by developer: 1 |
------------------------------------+-----------------------------------
Changes (by mjs973):
* analyzed: 0 => 1
* cc: mjs973@… (added)
* component: undetermined => avcodec
* reproduced: 0 => 1
Comment:
I analyzed this file in greater depth. The ffmpeg h264 decoder is doing
the right thing, it is the bitstream that is wrong. I see two problems,
which are completely unrelated.
1. The video stream was re-muxed at the the wrong frame rate. The original
h264 elementary stream is 60.0 frames per second, but the .ts container
was created using 30.0 frames per second.
2. This h264 elementary stream contains "buffering period SEI" and "pic
timing SEI". The value in the pic timing dpb_output_delay field is
completely wrong. It is typically a small interger value like "2", but in
this sample it is 15628 (and it increments by 2 for each frame.) I'd guess
this is a firmware error in the camcorder that created the compressed
video stream.
These SEI are optional in h264, and they are not needed for this stream.
So, a workaround for this camcorder bug would be to re-mux the stream and
tell the re-muxer to remove all the pic timing SEI NALs.
I don't see an easy way for the h264 decoder to work around this bug. The
way I read the h.264 spec, such a large value for dpb_output_buffer is
legal, but it is very, very unusual.
--
Ticket URL: <http://www.ffmpeg.org/trac/ffmpeg/ticket/424#comment:6>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list