On Wed, Aug 28, 2013 at 08:38:01PM +0200, Rafaël Carré wrote: > Le 27/08/2013 17:35, Rafaël Carré a écrit : > > 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 > > --- > > libavcodec/apedec.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c > > index d28e51a..2605623 100644 > > --- a/libavcodec/apedec.c > > +++ b/libavcodec/apedec.c > > @@ -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) > > > > lgtm.
yes, sometimes patches look good even to their authors _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
