[FFmpeg-devel] [PATCH] swresample/rematrix: fix mixing of center channels

[James Almer]

On 1/13/2025 5:30 PM, Michael Niedermayer wrote:
> Hi
> 
> On Mon, Jan 13, 2025 at 03:51:07PM -0300, James Almer wrote:
>> On 1/13/2025 12:49 AM, Michael Niedermayer wrote:
>>> Hi James
>>>
>>> On Sun, Jan 12, 2025 at 06:52:55PM -0300, James Almer wrote:
>>>> On 1/12/2025 6:25 PM, Michael Niedermayer wrote:
>>>>> Hi
>>>>>
>>>>> On Sat, Jan 11, 2025 at 11:13:30AM -0300, James Almer wrote:
>>>>>> With this, the output from
>>>>>>
>>>>>> ffmpeg -i $fate-samples/ac3/monsters_inc_5.1_448_small.ac3 -af aresample,aformat=channel_layouts=mono -f s16le -
>>>>>>
>>>>>> matches the one from
>>>>>>
>>>>>> ffmpeg -downmix mono -i $fate-samples/ac3/monsters_inc_5.1_448_small.ac3 -f s16le -
>>>>>>
>>>>>> When testing with tiny_psnr.
>>>>>>
>>>>>> Signed-off-by: James Almer <jamrial at gmail.com>
>>>>>> ---
>>>>>>     libswresample/rematrix.c | 4 ++--
>>>>>>     1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>
>>>>> This worsense test results:
>>>>
>>>> What test is this, and how is it read?
>>>
>>> its just tests/swresample
>>>
>>> and a dumb script that tries to compare its output to spot cases that worsen
>> Is this any better? (Also makes the above command line match)
> 
> Can we take a step back here.
> 
> please explain what you are fixing exactly
> 
> the matrix should be 1.0 on channels that exist before and afterwards
> so a speaker thats there before the mix and after the mix produces the
> same sound. That should naively be closest to correct,
> Speakers which disappear need to have their sound mixed into existing
> speakers. But existing speakers that dont change should not have their
> output change if the goal is to replicate the input
> 
> Of course maybe something else is better in some case (i dont know)
> but id like to read an explanation what and why. Not just that it
> matches something else

The line in question is the coeff to mix front center from input to 
front center from output in case front L/R channels from input are also 
mixed into front center (so surround/3.1 -> mono, 5.1 -> mono, etc).

The current coeff doesn't match the behavior of the downmix code in the 
ac3 decoder. Seeing it's the only coeff here where the value is outright 
overwritten rather than being subtracted/added, it's probably bogus, and 
I'm trying to find the (most) correct one that gives equal results.

> 
> thx
> 
> [...]
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20250113/5d9afe8e/attachment.sig>