apedec: do not buffer decoded samples over AVPackets
authorRafaël Carré <funman@videolan.org>
Tue, 27 Aug 2013 15:35:49 +0000 (17:35 +0200)
committerReinhard Tartler <siretart@tauware.de>
Sun, 1 Jun 2014 00:07:52 +0000 (20:07 -0400)
commit65c3593792a9702d9e4135bba46b1ca186afed6c
tree573a1a599478eb3c7e8472ba5ce40808776cfe86
parentb7b798a1afb1bfb1365b4ce67985351967c229d4
apedec: do not buffer decoded samples over AVPackets

Only consume an AVPacket when all the samples have been read.

When the rate of samples output is limited (by the default value
of max_samples), consuming the first packet immediately will cause
timing problems:

- The first packet with PTS 0 will output 4608 samples and be
consumed entirely
- The second packet with PTS 64 will output the remaining samples
(typically, a lot, that's why max_samples exist) until the decoded
samples of the first packet have been exhausted, at which point the
samples of the second packet will be decoded and output when
av_decode_frame is called with the next packet).

That means there's a PTS jump since the first packet is 'decoded'
immediately, which can be seen with avplay or mplayer: the timing
jumps immediately to 6.2s (which is the size of a packet).

Sample: http://streams.videolan.org/issues/6348/Goldwave-MAClib.ape

Bug-Debian: http://bugs.debian.org/744901
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
(cherry picked from commit 91d4cfb8127f1de6c4ad173a30fffe584700046d)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
libavcodec/apedec.c