[FFmpeg-devel] [PATCH] Ignore bad mapping in AAC (issue 1882)

[Alex Converse]

On Fri, May 28, 2010 at 2:51 AM, Cyril Russo <stage.nexvision at laposte.net>wrote:

>
> Le 27/05/2010 21:20, Alex Converse a ?crit :
>
>  On Thu, May 27, 2010 at 2:28 PM, Cyril Russo<stage.nexvision at laposte.net
>> >wrote:
>>
>>
>>
>>> Hi all,
>>>
>>>  The attached patch allows aac decoder to continue on a badly mapped AAC
>>> file (as shown in issue 1882 and the attached samples) by ignoring the
>>> badly
>>> tagged channel, instead of refusing to decode.
>>> It doesn't fix the mapping of such FAAC generated's stream (a bit too
>>> complex for my AAC knowledge).
>>>
>>>
>>>
>>>
>> I don't have the sample to test this on since roundup is down. However
>> based
>> on visual inspection, this seems to return the same underlying channel
>> element to two bitstream channel elements
>>
>>
>>
>>
> Yes, Alex, you've already answered on the bug tracker. The file contains
> SCE[0] CPE[0] CPE[0] LFE[0]
> The patch make libavcodec ignore the first CPE[0], so the file is, at
> least, decoded as 3.1 stream (and not 5.1 like intended, but it's not
> rejected).
>
>
But it isn't "ignoring" the first CPE, it's writing over the first CPE
clobbering channel element state from the previous frame.

Consider the output of the follow debug print:

av_log(NULL, AV_LOG_ERROR, "<%d.%x @ %p>\n", elem_type, elem_id, elem_type <
TYPE_DSE ? che : NULL);

<0.0 @ 0x7ff109c6a010>
<6.5 @ (nil)>
<1.0 @ 0x7ff109d0e010>
<6.a @ (nil)>
<1.0 @ 0x7ff109d0e010>
<6.a @ (nil)>
<3.0 @ 0x7ff109c6a010>

Both CPEs have the same address.