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 B7E4D44F89 for ; Thu, 12 Jan 2023 15:37:52 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id D5B6A68B296; Thu, 12 Jan 2023 17:37:48 +0200 (EET) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 593B568A531 for ; Thu, 12 Jan 2023 17:37:42 +0200 (EET) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id 8E2841C0007 for ; Thu, 12 Jan 2023 15:37:41 +0000 (UTC) Date: Thu, 12 Jan 2023 16:37:40 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230112153740.GL1949656@pb2> References: <20230105205342.GE4028235@pb2> <20230106172506.GG4028235@pb2> <20230108144532.GC35806@pb2> MIME-Version: 1.0 In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH] libswresample: avoid s16p internal processing format 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="===============0260937239129236745==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============0260937239129236745== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cy9Nn4fUvYST66Pl" Content-Disposition: inline --cy9Nn4fUvYST66Pl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 08, 2023 at 04:18:44PM +0100, Paul B Mahol wrote: > On 1/8/23, Michael Niedermayer wrote: > > On Fri, Jan 06, 2023 at 07:01:06PM +0100, Paul B Mahol wrote: > >> On Fri, Jan 6, 2023 at 6:25 PM Michael Niedermayer > >> > >> wrote: > >> > >> > On Thu, Jan 05, 2023 at 11:08:25PM +0100, Paul B Mahol wrote: > >> > > On Thu, Jan 5, 2023 at 9:53 PM Michael Niedermayer < > >> > michael@niedermayer.cc> > >> > > wrote: > >> > > > >> > > > On Thu, Jan 05, 2023 at 01:44:10PM +0100, Paul B Mahol wrote: > >> > > > > Patch attached. > >> > > > > >> > > > > swresample.c | 3 ++- > >> > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > >> > > > > eee7a0685b44aa867562138a2e2437ecb8844612 > >> > > > 0001-libswresample-swresample-avoid-s16p-internal-transfe.patch > >> > > > > From 9c4cd60e2dd41cf98d693c8251f4cfade0807073 Mon Sep 17 00:00= :00 > >> > 2001 > >> > > > > From: Paul B Mahol > >> > > > > Date: Thu, 5 Jan 2023 13:40:12 +0100 > >> > > > > Subject: [PATCH] libswresample/swresample: avoid s16p internal > >> > transfer > >> > > > format > >> > > > > > >> > > > > Instead use float one by default for sample rate conversions. > >> > > > > The s16p internal transfer format produces visible and hearable > >> > > > > quantization artifacts. > >> > > > > >> > > > When does this occur and why? > >> > > > > >> > > > >> > > It occurs always. Just compare output with 16bit and > >> > > int32/float/double. > >> > > Look at other people report on internet. > >> > > Look at src.infinitewave.ca > >> > > >> > src.infinitewave.ca uses 32bit none of what it shows should touch the > >> > codepath > >> > you change. > >> > > >> > if we look at src.infinitewave.ca for swr we see 2 types of artifacts > >> > 1. Aliassing which is at maybe -120db with the actual signal at 0db > >> > i would like to see some evidence that a human can hear this > >> > > >> > >> For s16p<->s16p it is much lower, around -78dB thus this patch. > > > > ok but you pointed to the website that apparently uses >=3D32bit if i t= rust > > what they write. > > And even if they test this i cannot use that website to replicate the i= ssue > > and the fix >=20 > If one use pure 16bit processing sweep results are even worse. >=20 > Just resample using fltp/dblp/s32p and s16p and compare (it does not > matter what, just not simple sine constant frequencies waves) >=20 > The s16p result is much worse and contains huge quantization noises. >=20 > They are not that obviously easy to hear, but are there, and > difference is > -80dB for dithered 16bit input. >=20 > You can generate and display sweep with/out resampling all with > ffmpeg/ffplay.ffplay -f lavfi -i > aevalsrc=3D"sin(PI*t*t*t*100):s=3D96000",aresample=3D44100:tsf=3Ds16p,sho= wspectrum=3Dscale=3Dlog:color=3Dcool:overlap=3D0:fps=3D25:drange=3D96:legen= d=3D1 >=20 > Play with tsf=3Dvalues and drange=3D[96-150] > So, for 16bit input, drange=3D96 and tsf=3Ds16p looks fine, but that web > pages shows bad results, ok, i see the issue, thanks [...] > >> How so? > >> I really doubt that this patch do that. > > > > I could be missing something but > > int_sample_fmt is set to before 16bit and afterwards 32bit > > and alot of things are using this: > > set_audiodata_fmt(&s->postin, s->int_sample_fmt); > > set_audiodata_fmt(&s->midbuf, s->int_sample_fmt); > > set_audiodata_fmt(&s->preout, s->int_sample_fmt); > > > > rematrix seems using these > > swri_rematrix(s, preout, midbuf, out_count, preout=3D=3Dout= ); > > ... > > swri_rematrix(s, midbuf, postin, in_count, midbuf=3D=3Dout); > > > > so i assumed that this patch makes a difference for it. Again i could be > > missing > > something >=20 > Yes, but only if sample rates differ the fltp is used instead of s16p > for resampling. yes, i misread the patch so, i do agree that flt is a better default for resampling s16->s16 on modern hw using 16bit coeffs seems an optimization at the wrong place the patch breaks fate though also, i suggest to leave the s16p if either input or output is s8 teh default change is ok, if it doesnt cause bitexactness issues, otherwise it also needs to be done conditional on bitexact flag As a note, if someone is interrested, it should be possible to improve the quantization noise by using some more fancy noise shaping when building the coefficients. That would not reduce the quantization noise but it would spread it out so it would be less audible and vissible. Though thats only really usefull if one actually did hear it.=20 thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Whats the most studid thing your enemy could do ? Blow himself up Whats the most studid thing you could do ? Give up your rights and freedom because your enemy blew himself up. --cy9Nn4fUvYST66Pl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCY8ApPQAKCRBhHseHBAsP qwKzAJ0ZzZiNhAkNE3hff+lOLjTo0oUrHQCdGv9NM5++X6CFfP6+Pp4U2/2LtA4= =0rOc -----END PGP SIGNATURE----- --cy9Nn4fUvYST66Pl-- --===============0260937239129236745== 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". --===============0260937239129236745==--