[FFmpeg-devel] [PATCH 2/2] libavcodec: Implementation of AC3 fixed point decoder

Nedeljko Babic Nedeljko.Babic at imgtec.com
Mon Apr 15 16:14:07 CEST 2013


Hi,

>Hi,
>
>I just wanted to mention that I'm not someone of charge of anything
>for ffmpeg: I just wanted to look at a FP implementation.

I am thankful for your comments whether you are in charge or not.

>>>> -                memcpy(((float*)frame->data[ch]) + AC3_BLOCK_SIZE*blk, output[ch], 1024);
>>>> +                memcpy(((SHORTFLOAT*)frame->data[ch]) + AC3_BLOCK_SIZE*blk, output[ch], 1024);
>>>
>>>I thought SHORTFLOAT was int16_t. How come it is the same copy size?
>>>I'm surprised this overwrite does not crash the decoder.
>>>
>>
>> Depending on flag CONFIG_AC3_FIXED, SHORTFLOAT is either int16_t (for fixed point decoder) or float
>> (for floating point decoder). Since output is also defined as SHORTFLOAT, memcpy is working
>> correctly.
>
>Yes but output[ch] is AC3_BLOCK_SIZE elements, ie 256. The 1024 is
>fine for 256*sizeof(float), but not here: you're overreading and
>overwriting the buffers. This 1024 should be changed to
>AC3_BLOCK_SIZE*sizeof(SHORTFLOAT).
>
>And answering myself, you didn't notice it because this happens only
>on error recovery, and you are probably not using corrupted streams.
>

You are correct and I'll fix it in the next patch.

>>>> +static int ac3_fixed_sqrt(int x)
>>>
>>>This is entirely dependent on the FP format, but that could go into
>>>the Fixed context header (not the struct itself) as a helper function.
>>
>> I will move it to header.
>
>I don't know what naming convention we could have, but maybe naming it
>fp12_fixed_sqrt(x) would be suited to match the format rather than
>where it is used?
>
>Someone else should comment on this FP DSP design.

I don't have a problem with your suggestion, so unless someone gives
a remark on this, I will use it in the next patch


Thanks
-Nedeljko


More information about the ffmpeg-devel mailing list