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

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 5972 bytes --]

On Thu, Aug 24, 2023 at 12:51:28AM +0200, Paul B Mahol wrote:
> On Thu, Aug 24, 2023 at 12:36 AM Michael Niedermayer <michael@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@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@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@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@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@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.

IIUC, before this patch if a 1gb sized ADPCM packet comes from a demuxer
that is decoded in small kb sized pieces and returned at that granularity
to the user.
after this patch (please correct me if iam wrong)
you get a failure as the decoded data is not even addressable with int
but lets assume int is 64bits, you get a 4gb or something like that
audio frame. It maybe faster to decode that in one go but by how much is that
faster from lets say decode it in 10-100kb sized chunks ?

IMHO theres a point where it is too big, and simply returning the data
to the user with some granularity lower than "unlimited" makes sense.
Iam not asking for a new feature, rather your patch removes this

thx


> 
> 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@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
> >
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Homeopathy is like voting while filling the ballot out with transparent ink.
Sometimes the outcome one wanted occurs. Rarely its worse than filling out
a ballot properly.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".