[FFmpeg-devel] [PATCH] avcodec/adpcm: take into account block_align when decoding ADPCM_PSX

[Paul B Mahol]

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" <onemda at gmail.com> wrote:
> 
> > 
> > Should reduce decoding overhead.
> > 
> > Signed-off-by: Paul B Mahol <onemda at gmail.com>
> > ---
> >  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.