[FFmpeg-devel] Big frames and packet timestamp

[Nicolas George]

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?

Regards,

-- 
  Nicolas George
-------------- 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/20120902/3e298946/attachment.asc>