[FFmpeg-devel] Big frames and packet timestamp
nicolas.george at normalesup.org
Sun Sep 2 15:20:15 CEST 2012
A packet of APE data decodes in a very long frame (~1.67 seconds for
luckynight-partial.ape). To account for that, the decoder keeps the frame in
an internal buffer and returns it in several parts. More precisely, it does
call #0 with packet #0: return packet.size bytes used and 4608 samples
call #1 with packet #1: return 0 bytes used and 4608 samples
call #2 with packet #1: return 0 bytes used and 4608 samples
call #15 with packet #1: return 0 bytes used and 4608 samples
call #16 with packet #1: return packet.size bytes used and 4608 samples
call #17 with packet #2: return 0 bytes used and 4608 samples
Several decoders for obscure codecs use the same scheme.
It has a serious problem: from the outside, it is difficult to guess to what
sample the PTS of the packet applies. Currently, ffmpeg.c assumes that the
PTS applies to the first sample returned by the first call using that
packet. In the above example, that means call #1 and #17, and this is
This is, AFAICS, the cause for trac ticket #1712.
This is especially annoying since it requires quite a complex logic from the
application: fixing it in ffmpeg.c would not be enough, it would need to be
fixed in src_movie, ffprobe, and any application using libavcodec.
Does anyone have a suggestion on the best way to handle the issue?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel