generic-library/ffmpeg
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

apedec: do not buffer decoded samples over AVPackets

Browse Source 
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
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
This commit is contained in:
Rafaël Carré 2013-08-27 17:35:49 +02:00 committed by Justin Ruggles
parent 84146963d2
commit 91d4cfb812
1 changed files with 1 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
libavcodec/apedec.c
View File

@ -1402,7 +1402,6 @@ static int ape_decode_frame(AVCodecContext *avctx, void *data,
int32_t *sample24;
int i, ch, ret;
int blockstodecode;
int bytes_used = 0;
/* this should never be negative, but bad things will happen if it is, so
check it just to make sure. */
@ -1468,7 +1467,6 @@ static int ape_decode_frame(AVCodecContext *avctx, void *data,
return AVERROR_INVALIDDATA;
}
bytes_used = avpkt->size;
}
if (!s->data) {
@ -1540,7 +1538,7 @@ static int ape_decode_frame(AVCodecContext *avctx, void *data,
*got_frame_ptr = 1;
return bytes_used;
return (s->samples == 0) ? avpkt->size : 0;
}
static void ape_flush(AVCodecContext *avctx)