[FFmpeg-devel] Big frames and packet timestamp

[Michael Niedermayer]

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
> that:
> 
> 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
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120915/4b2ada6e/attachment.asc>