From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 6CF3B432DC for ; Thu, 24 Aug 2023 15:45:08 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id C7F2168C593; Thu, 24 Aug 2023 18:45:05 +0300 (EEST) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id F134768BE9D for ; Thu, 24 Aug 2023 18:44:58 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id 4DB47C0004 for ; Thu, 24 Aug 2023 15:44:58 +0000 (UTC) Date: Thu, 24 Aug 2023 17:44:57 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230824154457.GL7802@pb2> References: <20230816163803.GT7802@pb2> <20230823190226.GG7802@pb2> <20230823223613.GK7802@pb2> MIME-Version: 1.0 In-Reply-To: X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [PATCH] adpcm fixes and improvements X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============4747375983007550854==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============4747375983007550854== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YAtphYyk96k3MMQU" Content-Disposition: inline --YAtphYyk96k3MMQU Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 24, 2023 at 12:51:28AM +0200, Paul B Mahol wrote: > On Thu, Aug 24, 2023 at 12:36=E2=80=AFAM Michael Niedermayer > wrote: >=20 > > On Wed, Aug 23, 2023 at 09:04:35PM +0200, Paul B Mahol wrote: > > > On Wed, Aug 23, 2023 at 9:02=E2=80=AFPM 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=E2=80=AFPM 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:0= 0:00 > > > > 2001 > > > > > > > From: Paul B Mahol > > > > > > > Date: Tue, 15 Aug 2023 14:18:47 +0200 > > > > > > > Subject: [PATCH 3/4] avcodec/adpcm: use already existing poin= ter > > for > > > > 4xm > > > > > > > decoder > > > > > > > > > > > > > > Signed-off-by: Paul B Mahol > > > > > > > --- > > > > > > > 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 =3D 0; i < channels; i++) { > > > > > > > ADPCMChannelStatus *cs =3D &c->status[i]; > > > > > > > - samples =3D (int16_t *)frame->data[i]; > > > > > > > + samples =3D samples_p[i]; > > > > > > > for (int n =3D nb_samples >> 1; n > 0; n--) { > > > > > > > int v =3D bytestream2_get_byteu(&gb); > > > > > > > *samples++ =3D 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:0= 0:00 > > > > 2001 > > > > > > > From: Paul B Mahol > > > > > > > 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 u= sed > > > > in the commit message > > > > > > > > > > > ffmpeg -h demuxer=3Dwav > > > > 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 th= at 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 >=20 > The ADPCM decoders could be transformed to receive frame API if you really > care. >=20 >=20 > 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 >=20 > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". --=20 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. --YAtphYyk96k3MMQU Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZOd69QAKCRBhHseHBAsP q1L0AJsFFvfKiAr6ppMiobSALFn/1RKP3gCeKEyitbSzYeL1DcMclNaYIGNQS8I= =oxMF -----END PGP SIGNATURE----- --YAtphYyk96k3MMQU-- --===============4747375983007550854== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============4747375983007550854==--