On Fri, Sep 11, 2020 at 01:14:02PM +0000, Zane van Iperen wrote: > On Fri, 11 Sep 2020 13:29:39 +0200 > "Paul B Mahol" <[email protected]> wrote: > > > > > Should reduce decoding overhead. > > > > Signed-off-by: Paul B Mahol <[email protected]> > > --- > > libavcodec/adpcm.c | 7 +++++-- > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c > > index 71e37efde7..e409a3aa6a 100644 > > --- a/libavcodec/adpcm.c > > +++ b/libavcodec/adpcm.c > > @@ -1966,11 +1966,13 @@ static int adpcm_decode_frame(AVCodecContext > > *avctx, void *data, > > } > > break; > > case AV_CODEC_ID_ADPCM_PSX: > > + for (int block = 0; block < avpkt->size / > > FFMAX(avctx->block_align, 16 * avctx->channels); block++) { > > + int nb_samples_per_block = 28 * FFMAX(avctx->block_align, 16 * > > avctx->channels) / (16 * avctx->channels); > > Shouldn't get_nb_samples() be updated instead?
Nope. get_nb_samples() gives number of samples in single packet depending on its size. We here uses blocks and block_align to decode mutliple frames at once. Imagine decoding stereo int16 pcm so that you pick only 4 bytes each time. This would give so big overhead that it would be not usable at all. Some ADPCM codecs just do this, and thus in player give excessive CPU usage. Also when decoding with ffmpeg -i input -f null -, realtime speed is nowhere near optimum value. In my case with this patch and modified demuxer to return mutliple frames it changes from 50x to >1000x speed. _______________________________________________ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
