diff mbox series

[FFmpeg-devel] adpcm fixes and improvements

Message ID CAPYw7P5=iK4upnHx0WhnJqMO3h=KX7fbf-Pbq4u-jrB7OwomgQ@mail.gmail.com
State New
Headers show
Series [FFmpeg-devel] adpcm fixes and improvements | expand

Checks

Context Check Description
yinshiyou/make_loongarch64 success Make finished
yinshiyou/make_fate_loongarch64 success Make fate finished
andriy/make_x86 success Make finished
andriy/make_fate_x86 success Make fate finished

Commit Message

Paul B Mahol Aug. 15, 2023, 2:49 p.m. UTC 
Attached

Comments

Michael Niedermayer Aug. 16, 2023, 4:38 p.m. UTC | #1 
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

thx


[...]
Paul B Mahol Aug. 16, 2023, 4:53 p.m. UTC | #2 
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.


>
> thx
>
>
> [...]
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In a rich man's house there is no place to spit but his face.
> -- Diogenes of Sinope
> _______________________________________________
> 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".
>
Paul B Mahol Aug. 23, 2023, 4:29 p.m. UTC | #3 
Will apply ASAP!
Michael Niedermayer Aug. 23, 2023, 7:02 p.m. UTC | #4 
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

thx

[...]
Paul B Mahol Aug. 23, 2023, 7:04 p.m. UTC | #5 
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


> thx
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> If you think the mosad wants you dead since a long time then you are either
> wrong or dead since a long time.
> _______________________________________________
> 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 Niedermayer Aug. 23, 2023, 10:36 p.m. UTC | #6 
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" ?

git grep  -l ADPCM  libavformat/*c | wc -l
88

thx

[...]
Paul B Mahol Aug. 23, 2023, 10:51 p.m. UTC | #7 
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.

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".
>
Michael Niedermayer Aug. 24, 2023, 3:44 p.m. UTC | #8 
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".
Andreas Rheinhardt Aug. 24, 2023, 4:26 p.m. UTC | #9 
Michael Niedermayer:
> 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
> 

If a user wants his audio in small bits, he should not send 1GB packets.

- Andreas
Michael Niedermayer Aug. 24, 2023, 5:39 p.m. UTC | #10 
On Thu, Aug 24, 2023 at 06:26:36PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > 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
> > 
> 
> If a user wants his audio in small bits, he should not send 1GB packets.

Normally most users get their audio packets from a file or stream
they dont choose whats in that and dont choose the size of packets

the wav demuxer has an option to choose the maximum packet size but thats
wav demuxer specific.

am i missing something ?
the 1gb was an extreem example to show the issue, real files would
likely not be that extreem but still the existence of the wav demuxer
option to choose the maximum packet size shows there was a need for
limiting it.

And if you take packets from the wav demuxer and remux them into
something else then any size you can get out of wav, you will be
able to put in and later get out of any other container.

again am i missing something ?

thx

[...]
Paul B Mahol Aug. 24, 2023, 7:47 p.m. UTC | #11 
On Thu, Aug 24, 2023 at 7:39 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> On Thu, Aug 24, 2023 at 06:26:36PM +0200, Andreas Rheinhardt wrote:
> > Michael Niedermayer:
> > > 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
> > >
> >
> > If a user wants his audio in small bits, he should not send 1GB packets.
>
> Normally most users get their audio packets from a file or stream
> they dont choose whats in that and dont choose the size of packets
>
> the wav demuxer has an option to choose the maximum packet size but thats
> wav demuxer specific.
>
> am i missing something ?
> the 1gb was an extreem example to show the issue, real files would
> likely not be that extreem but still the existence of the wav demuxer
> option to choose the maximum packet size shows there was a need for
> limiting it.
>
> And if you take packets from the wav demuxer and remux them into
> something else then any size you can get out of wav, you will be
> able to put in and later get out of any other container.
>
> again am i missing something ?
>

wav demuxer may have set size to higher value than block_align value.
This patch just returns samples in one bigger frame at once if that is
possible.
The delay/latency is not introduced by this patch at all which seems your
only objective.
In fact delay/latency is same as in code without this patch.



>
> thx
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Into a blind darkness they enter who follow after the Ignorance,
> they as if into a greater darkness enter who devote themselves
> to the Knowledge alone. -- Isha Upanishad
> _______________________________________________
> 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".
>
Paul B Mahol Aug. 26, 2023, 11:01 a.m. UTC | #12 
Will apply soon.
diff mbox series

Patch

From ff913fa6f91dbe17972f39017cb766d517ecf044 Mon Sep 17 00:00:00 2001
From: Paul B Mahol <onemda@gmail.com>
Date: Tue, 15 Aug 2023 15:51:10 +0200
Subject: [PATCH 2/4] avcodec/utils: fix duration for ADPCM_MS

Signed-off-by: Paul B Mahol <onemda@gmail.com>
---
 libavcodec/utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index bd4131db62..61e2946c16 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -740,7 +740,7 @@  static int get_audio_frame_duration(enum AVCodecID id, int sr, int ch, int ba,
                     tmp = blocks * ((ba - 4LL * ch) * 2 / ch);
                     break;
                 case AV_CODEC_ID_ADPCM_MS:
-                    tmp = blocks * (2 + (ba - 7LL * ch) * 2LL / ch);
+                    tmp = blocks * ((ba - 6LL * ch) * 2LL / ch);
                     break;
                 case AV_CODEC_ID_ADPCM_MTAF:
                     tmp = blocks * (ba - 16LL) * 2 / ch;
-- 
2.39.1