Re: [FFmpeg-devel] [PATCH] libswresample: avoid s16p internal processing format

From: Tobias Rapp <t.rapp@noa-archive.com>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] libswresample: avoid s16p internal processing format
Date: Mon, 9 Jan 2023 11:41:11 +0100
Message-ID: <d1397571-53e4-6965-3fac-227e6ccc7c66@noa-archive.com> (raw)
In-Reply-To: <20230108144532.GC35806@pb2>

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 <michael@niedermayer.cc>
>> 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 <onemda@gmail.com>
>>>>>> 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-request@ffmpeg.org with subject "unsubscribe".