Message ID | CAPYw7P5=iK4upnHx0WhnJqMO3h=KX7fbf-Pbq4u-jrB7OwomgQ@mail.gmail.com |
---|---|
State | New |
Headers | show |
Series | [FFmpeg-devel] adpcm fixes and improvements | expand |
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 |
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 [...]
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". >
Will apply ASAP!
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 [...]
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". >
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 [...]
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". >
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 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
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 [...]
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". >
Will apply soon.
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