[FFmpeg-devel] [PATCH] adpcm fixes and improvements

Paul B Mahol onemda at gmail.com
Thu Aug 24 01:51:28 EEST 2023


On Thu, Aug 24, 2023 at 12:36 AM Michael Niedermayer <michael at niedermayer.cc>
wrote:

> On Wed, Aug 23, 2023 at 09:04:35PM +0200, Paul B Mahol wrote:
> > On Wed, Aug 23, 2023 at 9:02 PM Michael Niedermayer <
> michael at niedermayer.cc>
> > wrote:
> >
> > > On Wed, Aug 16, 2023 at 06:53:42PM +0200, Paul B Mahol wrote:
> > > > On Wed, Aug 16, 2023 at 6:38 PM Michael Niedermayer <
> > > michael at niedermayer.cc>
> > > > wrote:
> > > >
> > > > > On Tue, Aug 15, 2023 at 04:49:05PM +0200, Paul B Mahol wrote:
> > > > > > Attached
> > > > >
> > > > > [...]
> > > > > >  adpcm.c |    2 +-
> > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > 3305dbe07ca935958fa213f5cadc339ad3cc3592
> > > > > 0003-avcodec-adpcm-use-already-existing-pointer-for-4xm-d.patch
> > > > > > From c6ad6dc7b8725d897e36399e5c7b8174caeb92e6 Mon Sep 17 00:00:00
> > > 2001
> > > > > > From: Paul B Mahol <onemda at gmail.com>
> > > > > > Date: Tue, 15 Aug 2023 14:18:47 +0200
> > > > > > Subject: [PATCH 3/4] avcodec/adpcm: use already existing pointer
> for
> > > 4xm
> > > > > >  decoder
> > > > > >
> > > > > > Signed-off-by: Paul B Mahol <onemda at gmail.com>
> > > > > > ---
> > > > > >  libavcodec/adpcm.c | 2 +-
> > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
> > > > > > index b0c3b91a3b..9993c9e531 100644
> > > > > > --- a/libavcodec/adpcm.c
> > > > > > +++ b/libavcodec/adpcm.c
> > > > > > @@ -1211,7 +1211,7 @@ static int
> adpcm_decode_frame(AVCodecContext
> > > > > *avctx, AVFrame *frame,
> > > > > >
> > > > > >          for (int i = 0; i < channels; i++) {
> > > > > >              ADPCMChannelStatus *cs = &c->status[i];
> > > > > > -            samples = (int16_t *)frame->data[i];
> > > > > > +            samples = samples_p[i];
> > > > > >              for (int n = nb_samples >> 1; n > 0; n--) {
> > > > > >                  int v = bytestream2_get_byteu(&gb);
> > > > > >                  *samples++ = adpcm_ima_expand_nibble(cs, v &
> 0x0F,
> > > 4);
> > > > >
> > > > > should be ok if tested
> > > > >
> > > > >
> > > > > > --
> > > > > > 2.39.1
> > > > > >
> > > > >
> > > > > >  libavcodec/adpcm.c                     |  388
> > > > > +++++++++++++++++----------------
> > > > > >  tests/ref/fate/adpcm-creative-8-2.6bit |    2
> > > > > >  tests/ref/fate/adpcm-creative-8-2bit   |    2
> > > > > >  tests/ref/fate/adpcm-creative-8-4bit   |    2
> > > > > >  tests/ref/fate/adpcm-ms-mono           |   60 +----
> > > > > >  5 files changed, 227 insertions(+), 227 deletions(-)
> > > > > > 1760df1de66b4227e71ffe942dedcf7d8a33ad48
> > > > > 0004-avcodec-adpcm-consume-all-input-when-decoding.patch
> > > > > > From 19789bca53548d672bff30b88a8838edaa876bdb Mon Sep 17 00:00:00
> > > 2001
> > > > > > From: Paul B Mahol <onemda at gmail.com>
> > > > > > Date: Tue, 15 Aug 2023 15:25:22 +0200
> > > > > > Subject: [PATCH 4/4] avcodec/adpcm: consume all input when
> decoding
> > > > > >
> > > > > > Stops multiple decoding calls for single packet.
> > > > > > Also makes decoding faster.
> > > > >
> > > > > This increases latency, which can be problem if packets are
> > > > > sufficiently large
> > > > >
> > > >
> > > > Then reduce size at demuxer level. there is option for it.
> > >
> > > if that is so, then please explain exactly which option should be used
> > > in the commit message
> > >
> > >
> > ffmpeg -h demuxer=wav
>
> what about the demuxers that are not named "wav" ?
>
>
I think you are blocking this just for sake of blocking because you have
nothing more constructive to do.
The delay is always present, unless packet size is exact as block align.
And for ADPCM this is irrelevant.

The ADPCM decoders could be transformed to receive frame API if you really
care.


git grep  -l ADPCM  libavformat/*c | wc -l
> 88
>
> thx
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> It is a danger to trust the dream we wish for rather than
> the science we have, -- Dr. Kenneth Brown
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>


More information about the ffmpeg-devel mailing list