[FFmpeg-devel] [PATCH] avcodec/aacdec: don't force HE-AACv2 profile if no PS info is present

[James Almer]

On 7/22/2022 11:56 AM, Andreas Rheinhardt wrote:
> James Almer:
>> On 7/22/2022 11:23 AM, Andreas Rheinhardt wrote:
>>> James Almer:
>>>> On 7/18/2022 10:57 AM, Andreas Rheinhardt wrote:
>>>>> James Almer:
>>>>>> On 7/14/2022 9:10 AM, Andreas Rheinhardt wrote:
>>>>>>> James Almer:
>>>>>>>> Should fix ticket #3361
>>>>>>>>
>>>>>>>> Signed-off-by: James Almer <jamrial at gmail.com>
>>>>>>>> ---
>>>>>>>> This also needs an update to some fate ref samples i'll upload
>>>>>>>> before
>>>>>>>> pushing
>>>>>>>> (fate-aac-al_sbr_ps_04_ur and fate-aac-al_sbr_ps_06_ur which are now
>>>>>>>> decoded
>>>>>>>> properly as he_aac mono, so the .s16 files need to be replaced).
>>>>>>>>
>>>>>>>
>>>>>>> We have both a fixed-point AAC as well as a floating point AAC
>>>>>>> decoder.
>>>>>>> Is there actually a test that tests that the output they produce is
>>>>>>> reasonably close? If not, could we make the test so that the same
>>>>>>> file
>>>>>>> is decoded once with the fixed-point and once with the floating-point
>>>>>>> decoder and then compared?
>>>>>>
>>>>>> That wouldn't help much, i think. Almost all changes to *_template.c
>>>>>> files are going to affect both decoders, so a breakage would not be
>>>>>> detected if you compare their output with each other as they would
>>>>>> both
>>>>>> exhibit it.
>>>>>>
>>>>>
>>>>> I actually thought that the aac_fixed tests used checksums instead of
>>>>> ref files; then changes and breakages would be visible by changes to
>>>>> these files. Apparently I was wrong about that and the ref files are
>>>>> used for both aac and aac_fixed. But a test like the one outlined above
>>>>> would nevertheless obviate the need for a new ref file.
>>>>
>>>> Judging by
>>>> https://git.videolan.org/?p=ffmpeg.git;a=blob;f=tests/fate/aac.mak;h=1743428f544fad8946dba11dd4ecec0630eb70a6;hb=HEAD#l117
>>>>
>>>> it seems at least for these samples the fixed decoder does not generate
>>>> a decoded stream comparable to the float one, so I'll just upload a new
>>>> raw pcm file.
>>>
>>> When I decode both of these streams with git master, the left channel is
>>> pretty much identical, yet the right channel of the fixed-point decoder
>>> is silent and the right channel of the floating point decoder is not.
>>> With this patch applied, the result are two mono streams that are pretty
>>> much identical: The test sample created by the floating-point decoder
>>> works with the fixed-point decoder test (if one uncomments and modifies
>>> the latter). So the issue with aac-al_sbr_ps_06_ur is not a reason to
>>> upload new samples.
>>
>> Ok, can you suggest how to add a test that decodes with the fixed point
>> decoder then compares that with the output of the float decoder? Is
>> there a helper in fate.sh already for this?
>>
> 
> There is currently no helper in fate-run.sh for this.

Yeah, figures that's the case. Can you suggest how one would work for this?

> 
>>>
>>> - Andreas
>>>
>>> PS: libfdk-aac produces a file that looks pretty much like the floating
>>> point decoder from git master. Are you sure your patch is correct?
>>
>> Yes, they duplicate the single channel in the stream and output it as
>> stereo, something that should be done by a filter if that's what the
>> user wants. Decoding a mono sample should generate a mono stream.
> 
> Not really. The channels are different.

./ffmpeg -c:a libfdk_aac -i ../samples/aac/al_sbr_ps_04_new.mp4 -af 
channelmap=channel_layout=mono:map=0 -f md5 -

has the same result as

./ffmpeg -c:a libfdk_aac -i ../samples/aac/al_sbr_ps_04_new.mp4 -af 
channelmap=channel_layout=mono:map=1 -f md5 -

Same with the samples in the ticket.

> 
> - Andreas
> _______________________________________________
> 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".