[FFmpeg-devel] Big frames and packet timestamp
michaelni at gmx.at
Sat Sep 15 03:41:36 CEST 2012
On Sun, Sep 02, 2012 at 03:20:15PM +0200, Nicolas George wrote:
> 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
> obviously wrong.
> 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?
if iam not missing something
the decoder should set correct timestamps in AVFrame based on the
timestamps on its input.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel