Re: [FFmpeg-devel] [PATCH] libswresample: avoid s16p internal processing format
On Thu, Jan 12, 2023 at 05:09:18PM +0100, Paul B Mahol wrote: > On 1/12/23, Michael Niedermayer wrote: > > On Thu, Jan 12, 2023 at 03:20:06PM +0100, Paul B Mahol wrote: > >> On 1/8/23, Michael Niedermayer wrote: > >> > On Fri, Jan 06, 2023 at 07:04:59PM +0100, Paul B Mahol wrote: > >> >> On Fri, Jan 6, 2023 at 7:01 PM 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 < > >> >> >> mich...@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. > >> >> > > >> >> > Also for others and reports for swr its is lower than exact -120dB > >> >> > > >> >> > > >> >> > 2. Reflection and attenuation at the transition frequency > >> >> >> With linear filters there is a tradeof between attenuation of the > >> >> >> passband, reflection of frequencies beyond, latency and so on > >> >> >> You can have a perfect sharp cutoff with no attenuation and no > >> >> >> refelection > >> >> >> that requires a infinitly long filter. And while this looks best in > >> >> >> this > >> >> >> frequency plot, does it actually sound best ? If you can hear > >> >> >> -120db > >> >> >> signals you surely would then also hear the ringing long before a > >> >> >> gunshot > >> >> >> from such long filter. > >> >> >> > >> >> > > >> >> One can always change linear FIR to be min phase FIR kernel. > >> > > >> > I certainly would welcome a wider range of filters in swr, if you want > >> > to > >> > add > >> > any low delay sinc approximation or in fact i would welcome any filter > >> > you want to add. > >> > >> There is that afdelaysrc filter patch on ML to add FIR coefficient > >> generation for fractional delay audio filter that can be also used as > >> a interpolation FIR filter. And to me it seems better at same number > >> of taps than already used/available ones in soxr and swr. > > > > Please add improvments into swr, if you have any! > > > > > >> > >> Also I have done prototype of resampling filter using afir filter via > >> custom filters in filtergraph and it operates at similar speeds like > >> soxr (in these very non optimized approach) and providing better/wider > >> frequency output at highest band. > > > > Can it be added into swr ? > > It will use libavutil/tx.h for convolution. ok of course > > But I need first to research more and write actual code that does > out/in sample rate ratio factorization and do lot of benchmarks > comparing normal ratios with very big ones and make sure that approach > is always faster than swr/soxr and at same time providing better/same > quality. > Also need to add min phase version of filter and compare what > performance/latency it can bring at all. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To
Re: [FFmpeg-devel] [PATCH] libswresample: avoid s16p internal processing format
On 1/12/23, Michael Niedermayer wrote: > On Thu, Jan 12, 2023 at 03:20:06PM +0100, Paul B Mahol wrote: >> On 1/8/23, Michael Niedermayer wrote: >> > On Fri, Jan 06, 2023 at 07:04:59PM +0100, Paul B Mahol wrote: >> >> On Fri, Jan 6, 2023 at 7:01 PM 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 < >> >> >> mich...@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. >> >> > >> >> > Also for others and reports for swr its is lower than exact -120dB >> >> > >> >> > >> >> > 2. Reflection and attenuation at the transition frequency >> >> >> With linear filters there is a tradeof between attenuation of the >> >> >> passband, reflection of frequencies beyond, latency and so on >> >> >> You can have a perfect sharp cutoff with no attenuation and no >> >> >> refelection >> >> >> that requires a infinitly long filter. And while this looks best in >> >> >> this >> >> >> frequency plot, does it actually sound best ? If you can hear >> >> >> -120db >> >> >> signals you surely would then also hear the ringing long before a >> >> >> gunshot >> >> >> from such long filter. >> >> >> >> >> > >> >> One can always change linear FIR to be min phase FIR kernel. >> > >> > I certainly would welcome a wider range of filters in swr, if you want >> > to >> > add >> > any low delay sinc approximation or in fact i would welcome any filter >> > you want to add. >> >> There is that afdelaysrc filter patch on ML to add FIR coefficient >> generation for fractional delay audio filter that can be also used as >> a interpolation FIR filter. And to me it seems better at same number >> of taps than already used/available ones in soxr and swr. > > Please add improvments into swr, if you have any! > > >> >> Also I have done prototype of resampling filter using afir filter via >> custom filters in filtergraph and it operates at similar speeds like >> soxr (in these very non optimized approach) and providing better/wider >> frequency output at highest band. > > Can it be added into swr ? It will use libavutil/tx.h for convolution. But I need first to research more and write actual code that does out/in sample rate ratio factorization and do lot of benchmarks comparing normal ratios with very big ones and make sure that approach is always faster than swr/soxr and at same time providing better/same quality. Also need to add min phase version of filter and compare what performance/latency it can bring at all. > > thx > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Awnsering whenever a program halts or runs forever is > On a turing machine, in general impossible (turings halting problem). > On any real computer, always possible as a real computer has a finite > number > of states N, and will either halt in less than N cycles or never halt. > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libswresample: avoid s16p internal processing format
On Thu, Jan 12, 2023 at 03:20:06PM +0100, Paul B Mahol wrote: > On 1/8/23, Michael Niedermayer wrote: > > On Fri, Jan 06, 2023 at 07:04:59PM +0100, Paul B Mahol wrote: > >> On Fri, Jan 6, 2023 at 7:01 PM 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 < > >> >> mich...@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. > >> > > >> > Also for others and reports for swr its is lower than exact -120dB > >> > > >> > > >> > 2. Reflection and attenuation at the transition frequency > >> >> With linear filters there is a tradeof between attenuation of the > >> >> passband, reflection of frequencies beyond, latency and so on > >> >> You can have a perfect sharp cutoff with no attenuation and no > >> >> refelection > >> >> that requires a infinitly long filter. And while this looks best in > >> >> this > >> >> frequency plot, does it actually sound best ? If you can hear -120db > >> >> signals you surely would then also hear the ringing long before a > >> >> gunshot > >> >> from such long filter. > >> >> > >> > > >> One can always change linear FIR to be min phase FIR kernel. > > > > I certainly would welcome a wider range of filters in swr, if you want to > > add > > any low delay sinc approximation or in fact i would welcome any filter > > you want to add. > > There is that afdelaysrc filter patch on ML to add FIR coefficient > generation for fractional delay audio filter that can be also used as > a interpolation FIR filter. And to me it seems better at same number > of taps than already used/available ones in soxr and swr. Please add improvments into swr, if you have any! > > Also I have done prototype of resampling filter using afir filter via > custom filters in filtergraph and it operates at similar speeds like > soxr (in these very non optimized approach) and providing better/wider > frequency output at highest band. Can it be added into swr ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libswresample: avoid s16p internal processing format
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 < > >> > mich...@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 >=32bit if i trust > > what they write. > > And even if they test this i cannot use that website to replicate the issue > > and the fix > > If one use pure 16bit processing sweep results are even worse. > > Just resample using fltp/dblp/s32p and s16p and compare (it does not > matter what, just not simple sine constant frequencies waves) > > The s16p result is much worse and contains huge quantization noises. > > They are not that obviously easy to hear, but are there, and > difference is > -80dB for dithered 16bit input. > > You can generate and display sweep with/out resampling all with > ffmpeg/ffplay.ffplay -f lavfi -i > aevalsrc="sin(PI*t*t*t*100):s=96000",aresample=44100:tsf=s16p,showspectrum=scale=log:color=cool:overlap=0:fps=25:drange=96:legend=1 > > Play with tsf=values and drange=[96-150] > So, for 16bit input, drange=96 and tsf=s16p 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(>postin, s->int_sample_fmt); > > set_audiodata_fmt(>midbuf, s->int_sample_fmt); > > set_audiodata_fmt(>preout, s->int_sample_fmt); > > > > rematrix seems using these > > swri_rematrix(s, preout, midbuf, out_count, preout==out); > > ... > > swri_rematrix(s, midbuf, postin, in_count, midbuf==out); > > > > so i assumed that this patch makes a difference for it. Again i could be > > missing > > something > > 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. thx [...] -- 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. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject
Re: [FFmpeg-devel] [PATCH] libswresample: avoid s16p internal processing format
On 1/8/23, Michael Niedermayer wrote: > On Fri, Jan 06, 2023 at 07:04:59PM +0100, Paul B Mahol wrote: >> On Fri, Jan 6, 2023 at 7:01 PM 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 < >> >> mich...@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. >> > >> > Also for others and reports for swr its is lower than exact -120dB >> > >> > >> > 2. Reflection and attenuation at the transition frequency >> >> With linear filters there is a tradeof between attenuation of the >> >> passband, reflection of frequencies beyond, latency and so on >> >> You can have a perfect sharp cutoff with no attenuation and no >> >> refelection >> >> that requires a infinitly long filter. And while this looks best in >> >> this >> >> frequency plot, does it actually sound best ? If you can hear -120db >> >> signals you surely would then also hear the ringing long before a >> >> gunshot >> >> from such long filter. >> >> >> > >> One can always change linear FIR to be min phase FIR kernel. > > I certainly would welcome a wider range of filters in swr, if you want to > add > any low delay sinc approximation or in fact i would welcome any filter > you want to add. There is that afdelaysrc filter patch on ML to add FIR coefficient generation for fractional delay audio filter that can be also used as a interpolation FIR filter. And to me it seems better at same number of taps than already used/available ones in soxr and swr. Also I have done prototype of resampling filter using afir filter via custom filters in filtergraph and it operates at similar speeds like soxr (in these very non optimized approach) and providing better/wider frequency output at highest band. > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The real ebay dictionary, page 1 > "Used only once"- "Some unspecified defect prevented a second use" > "In good condition" - "Can be repaird by experienced expert" > "As is" - "You wouldnt want it even if you were payed for it, if you knew > ..." > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libswresample: avoid s16p internal processing format
On 1/9/23, Tobias Rapp wrote: > On 08/01/2023 15:45, 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 < mich...@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 >=32bit if i trust >> what they write. >> And even if they test this i cannot use that website to replicate the >> issue >> and the fix >> >> I just wanted to know how i can test this. You are testing it too ... >> so i can see what you see >> Id like to make sure this is the correct fix for the problem and >> Id like to make sure its used when it makes sense and not when not. > > IIRC a similar sweep graph can be created with "Spek" from > http://spek.cc/ but haven't used that application for a while. The SRC Spek is both slow and limited in range of dB, so it should never be used by pro users. > comparison website apparently provides the input files for testing, see > the instructions at http://src.infinitewave.ca/faq.html. > > Regards, Tobias > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libswresample: avoid s16p internal processing format
On 08/01/2023 15:45, 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 < mich...@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 >=32bit if i trust what they write. And even if they test this i cannot use that website to replicate the issue and the fix I just wanted to know how i can test this. You are testing it too ... so i can see what you see Id like to make sure this is the correct fix for the problem and Id like to make sure its used when it makes sense and not when not. IIRC a similar sweep graph can be created with "Spek" from http://spek.cc/ but haven't used that application for a while. The SRC comparison website apparently provides the input files for testing, see the instructions at http://src.infinitewave.ca/faq.html. Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libswresample: avoid s16p internal processing format
On 1/8/23, Michael Niedermayer wrote: > On Fri, Jan 06, 2023 at 07:04:59PM +0100, Paul B Mahol wrote: >> On Fri, Jan 6, 2023 at 7:01 PM 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 < >> >> mich...@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. >> > >> > Also for others and reports for swr its is lower than exact -120dB >> > >> > >> > 2. Reflection and attenuation at the transition frequency >> >> With linear filters there is a tradeof between attenuation of the >> >> passband, reflection of frequencies beyond, latency and so on >> >> You can have a perfect sharp cutoff with no attenuation and no >> >> refelection >> >> that requires a infinitly long filter. And while this looks best in >> >> this >> >> frequency plot, does it actually sound best ? If you can hear -120db >> >> signals you surely would then also hear the ringing long before a >> >> gunshot >> >> from such long filter. >> >> >> > >> One can always change linear FIR to be min phase FIR kernel. > > I certainly would welcome a wider range of filters in swr, if you want to > add > any low delay sinc approximation or in fact i would welcome any filter > you want to add. I have hack for simple cases when one of decimation/interpolation factor is 1 than there is single only FIR kernel applied and then one do not use naive convolution which is O(N^2) but O(Nlog(N)) when using RDFT/FFT. For bigger filter sizes it makes filtering amazingly faster. (from <80x to >400x). So I'm interested in making it faster if possible for any combination of decimation/interpolation. > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The real ebay dictionary, page 1 > "Used only once"- "Some unspecified defect prevented a second use" > "In good condition" - "Can be repaird by experienced expert" > "As is" - "You wouldnt want it even if you were payed for it, if you knew > ..." > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libswresample: avoid s16p internal processing format
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 < >> > mich...@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 >=32bit if i trust > what they write. > And even if they test this i cannot use that website to replicate the issue > and the fix If one use pure 16bit processing sweep results are even worse. Just resample using fltp/dblp/s32p and s16p and compare (it does not matter what, just not simple sine constant frequencies waves) The s16p result is much worse and contains huge quantization noises. They are not that obviously easy to hear, but are there, and difference is > -80dB for dithered 16bit input. You can generate and display sweep with/out resampling all with ffmpeg/ffplay.ffplay -f lavfi -i aevalsrc="sin(PI*t*t*t*100):s=96000",aresample=44100:tsf=s16p,showspectrum=scale=log:color=cool:overlap=0:fps=25:drange=96:legend=1 Play with tsf=values and drange=[96-150] So, for 16bit input, drange=96 and tsf=s16p looks fine, but that web pages shows bad results, thus I think that they use >16bit and tsf=s16p. But anyway the filter kernel is quantized to 16bit for s16p and if 16bit input is dithered results are also worse for s16p, because if you reformat s16p to flt/s32p and resample and then convert back to s16p errors are bigger than 1/2 bits range when compared to direct s16 resampling. > > I just wanted to know how i can test this. You are testing it too ... > so i can see what you see > Id like to make sure this is the correct fix for the problem and > Id like to make sure its used when it makes sense and not when not. > > >> >> Also for others and reports for swr its is lower than exact -120dB > > The 120 was by "eye" from teh chart on the web i didnt meassure it > > >> >> >> 2. Reflection and attenuation at the transition frequency >> > With linear filters there is a tradeof between attenuation of the >> > passband, reflection of frequencies beyond, latency and so on >> > You can have a perfect sharp cutoff with no attenuation and no >> > refelection >> > that requires a infinitly long filter. And while this looks best in >> > this >> > frequency plot, does it actually sound best ? If you can hear -120db >> > signals you surely would then also hear the ringing long before a >> > gunshot >> > from such long filter. >> > >> > also what actually is the optimal frequency response of this filter ? >> > with a 22khz cutoff, a 22.1khz sine should be silence is that >> > really subjectively better than a 21.9khz sine ? >> > Iam not sure about this. Has someone done actual hearing tests with >> > actual real audio? the sinc filter originates from the idea of lossless >> > reconstruction of frequencies below nyquist if iam not mistaken, but >> > humans >> > are not trying to losslessly restore a block of frequencies. A human >> > listener >> > generally wants to enjoy listening to some media. Has someone looked >> > into >> > what is actually best for that real use case ? >> > This question matters because with it we can tune the filter parameters >> > to >> > target humans. >> > >> > But lets push the doubts about choosing resampling purely based on >> > frequency >> > analysis away. >> > swresample has several parameters with which you can tune this: >> > we have a filter_size, if thats bigger you
Re: [FFmpeg-devel] [PATCH] libswresample: avoid s16p internal processing format
On Fri, Jan 06, 2023 at 07:04:59PM +0100, Paul B Mahol wrote: > On Fri, Jan 6, 2023 at 7:01 PM 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 < > >> mich...@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. > > > > Also for others and reports for swr its is lower than exact -120dB > > > > > > 2. Reflection and attenuation at the transition frequency > >> With linear filters there is a tradeof between attenuation of the > >> passband, reflection of frequencies beyond, latency and so on > >> You can have a perfect sharp cutoff with no attenuation and no refelection > >> that requires a infinitly long filter. And while this looks best in this > >> frequency plot, does it actually sound best ? If you can hear -120db > >> signals you surely would then also hear the ringing long before a gunshot > >> from such long filter. > >> > > > One can always change linear FIR to be min phase FIR kernel. I certainly would welcome a wider range of filters in swr, if you want to add any low delay sinc approximation or in fact i would welcome any filter you want to add. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libswresample: avoid s16p internal processing format
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 < > > mich...@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 >=32bit if i trust what they write. And even if they test this i cannot use that website to replicate the issue and the fix I just wanted to know how i can test this. You are testing it too ... so i can see what you see Id like to make sure this is the correct fix for the problem and Id like to make sure its used when it makes sense and not when not. > > Also for others and reports for swr its is lower than exact -120dB The 120 was by "eye" from teh chart on the web i didnt meassure it > > > 2. Reflection and attenuation at the transition frequency > > With linear filters there is a tradeof between attenuation of the > > passband, reflection of frequencies beyond, latency and so on > > You can have a perfect sharp cutoff with no attenuation and no refelection > > that requires a infinitly long filter. And while this looks best in this > > frequency plot, does it actually sound best ? If you can hear -120db > > signals you surely would then also hear the ringing long before a gunshot > > from such long filter. > > > > also what actually is the optimal frequency response of this filter ? > > with a 22khz cutoff, a 22.1khz sine should be silence is that > > really subjectively better than a 21.9khz sine ? > > Iam not sure about this. Has someone done actual hearing tests with > > actual real audio? the sinc filter originates from the idea of lossless > > reconstruction of frequencies below nyquist if iam not mistaken, but humans > > are not trying to losslessly restore a block of frequencies. A human > > listener > > generally wants to enjoy listening to some media. Has someone looked into > > what is actually best for that real use case ? > > This question matters because with it we can tune the filter parameters to > > target humans. > > > > But lets push the doubts about choosing resampling purely based on > > frequency > > analysis away. > > swresample has several parameters with which you can tune this: > > we have a filter_size, if thats bigger you should get closer to the ideal > > sinc. Theres phase_shift which may reduce the (i assume) unhearable > > aliasing. > > And cutoff which should allow to tune the (i assume) hearable > > reflection/attenuation tradeoff also theres filter_type to allow you to > > tune the > > window function. > > > > If there are issues reported by people using their ears, please provide > > more > > details, iam interrested in these cases. > > > > > > > > > > > > > > This change should be limited to the case that benefits, this would > > force > > > > this > > > > even without resampling in some cases. > > > > > > > > > > It is forced only if sample rates between input and output differs. > > > > If iam not mistaken it affects rematrixing without resampling too > > > > 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(>postin, s->int_sample_fmt); set_audiodata_fmt(>midbuf, s->int_sample_fmt); set_audiodata_fmt(>preout, s->int_sample_fmt); rematrix seems using these swri_rematrix(s, preout, midbuf, out_count, preout==out); ... swri_rematrix(s, midbuf, postin, in_count,
Re: [FFmpeg-devel] [PATCH] libswresample: avoid s16p internal processing format
On Fri, Jan 6, 2023 at 7:01 PM 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 < >> mich...@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. > > Also for others and reports for swr its is lower than exact -120dB > > > 2. Reflection and attenuation at the transition frequency >> With linear filters there is a tradeof between attenuation of the >> passband, reflection of frequencies beyond, latency and so on >> You can have a perfect sharp cutoff with no attenuation and no refelection >> that requires a infinitly long filter. And while this looks best in this >> frequency plot, does it actually sound best ? If you can hear -120db >> signals you surely would then also hear the ringing long before a gunshot >> from such long filter. >> > One can always change linear FIR to be min phase FIR kernel. > >> also what actually is the optimal frequency response of this filter ? >> with a 22khz cutoff, a 22.1khz sine should be silence is that >> really subjectively better than a 21.9khz sine ? >> Iam not sure about this. Has someone done actual hearing tests with >> actual real audio? the sinc filter originates from the idea of lossless >> reconstruction of frequencies below nyquist if iam not mistaken, but >> humans >> are not trying to losslessly restore a block of frequencies. A human >> listener >> generally wants to enjoy listening to some media. Has someone looked into >> what is actually best for that real use case ? >> This question matters because with it we can tune the filter parameters to >> target humans. >> >> But lets push the doubts about choosing resampling purely based on >> frequency >> analysis away. >> swresample has several parameters with which you can tune this: >> we have a filter_size, if thats bigger you should get closer to the ideal >> sinc. Theres phase_shift which may reduce the (i assume) unhearable >> aliasing. >> And cutoff which should allow to tune the (i assume) hearable >> reflection/attenuation tradeoff also theres filter_type to allow you to >> tune the >> window function. >> >> If there are issues reported by people using their ears, please provide >> more >> details, iam interrested in these cases. >> >> >> > >> > >> > > This change should be limited to the case that benefits, this would >> force >> > > this >> > > even without resampling in some cases. >> > > >> > >> > It is forced only if sample rates between input and output differs. >> >> If iam not mistaken it affects rematrixing without resampling too >> > > How so? > I really doubt that this patch do that. > > >> >> thx >> >> [...] >> -- >> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB >> >> The real ebay dictionary, page 1 >> "Used only once"- "Some unspecified defect prevented a second use" >> "In good condition" - "Can be repaird by experienced expert" >> "As is" - "You wouldnt want it even if you were payed for it, if you knew >> ..." >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libswresample: avoid s16p internal processing format
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 < > mich...@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. Also for others and reports for swr its is lower than exact -120dB 2. Reflection and attenuation at the transition frequency > With linear filters there is a tradeof between attenuation of the > passband, reflection of frequencies beyond, latency and so on > You can have a perfect sharp cutoff with no attenuation and no refelection > that requires a infinitly long filter. And while this looks best in this > frequency plot, does it actually sound best ? If you can hear -120db > signals you surely would then also hear the ringing long before a gunshot > from such long filter. > > also what actually is the optimal frequency response of this filter ? > with a 22khz cutoff, a 22.1khz sine should be silence is that > really subjectively better than a 21.9khz sine ? > Iam not sure about this. Has someone done actual hearing tests with > actual real audio? the sinc filter originates from the idea of lossless > reconstruction of frequencies below nyquist if iam not mistaken, but humans > are not trying to losslessly restore a block of frequencies. A human > listener > generally wants to enjoy listening to some media. Has someone looked into > what is actually best for that real use case ? > This question matters because with it we can tune the filter parameters to > target humans. > > But lets push the doubts about choosing resampling purely based on > frequency > analysis away. > swresample has several parameters with which you can tune this: > we have a filter_size, if thats bigger you should get closer to the ideal > sinc. Theres phase_shift which may reduce the (i assume) unhearable > aliasing. > And cutoff which should allow to tune the (i assume) hearable > reflection/attenuation tradeoff also theres filter_type to allow you to > tune the > window function. > > If there are issues reported by people using their ears, please provide > more > details, iam interrested in these cases. > > > > > > > > > This change should be limited to the case that benefits, this would > force > > > this > > > even without resampling in some cases. > > > > > > > It is forced only if sample rates between input and output differs. > > If iam not mistaken it affects rematrixing without resampling too > How so? I really doubt that this patch do that. > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The real ebay dictionary, page 1 > "Used only once"- "Some unspecified defect prevented a second use" > "In good condition" - "Can be repaird by experienced expert" > "As is" - "You wouldnt want it even if you were payed for it, if you knew > ..." > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libswresample: avoid s16p internal processing format
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 > 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 2. Reflection and attenuation at the transition frequency With linear filters there is a tradeof between attenuation of the passband, reflection of frequencies beyond, latency and so on You can have a perfect sharp cutoff with no attenuation and no refelection that requires a infinitly long filter. And while this looks best in this frequency plot, does it actually sound best ? If you can hear -120db signals you surely would then also hear the ringing long before a gunshot from such long filter. also what actually is the optimal frequency response of this filter ? with a 22khz cutoff, a 22.1khz sine should be silence is that really subjectively better than a 21.9khz sine ? Iam not sure about this. Has someone done actual hearing tests with actual real audio? the sinc filter originates from the idea of lossless reconstruction of frequencies below nyquist if iam not mistaken, but humans are not trying to losslessly restore a block of frequencies. A human listener generally wants to enjoy listening to some media. Has someone looked into what is actually best for that real use case ? This question matters because with it we can tune the filter parameters to target humans. But lets push the doubts about choosing resampling purely based on frequency analysis away. swresample has several parameters with which you can tune this: we have a filter_size, if thats bigger you should get closer to the ideal sinc. Theres phase_shift which may reduce the (i assume) unhearable aliasing. And cutoff which should allow to tune the (i assume) hearable reflection/attenuation tradeoff also theres filter_type to allow you to tune the window function. If there are issues reported by people using their ears, please provide more details, iam interrested in these cases. > > > > This change should be limited to the case that benefits, this would force > > this > > even without resampling in some cases. > > > > It is forced only if sample rates between input and output differs. If iam not mistaken it affects rematrixing without resampling too thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libswresample: avoid s16p internal processing format
On Thu, Jan 5, 2023 at 9:53 PM Michael Niedermayer 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 > This change should be limited to the case that benefits, this would force > this > even without resampling in some cases. > It is forced only if sample rates between input and output differs. > > thx > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The day soldiers stop bringing you their problems is the day you have > stopped > leading them. They have either lost confidence that you can help or > concluded > you do not care. Either case is a failure of leadership. - Colin Powell > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libswresample: avoid s16p internal processing format
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? This change should be limited to the case that benefits, this would force this even without resampling in some cases. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The day soldiers stop bringing you their problems is the day you have stopped leading them. They have either lost confidence that you can help or concluded you do not care. Either case is a failure of leadership. - Colin Powell signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
