[FFmpeg-devel] [PATCH] Fix non-rounding up to next 16-bit aligned bug in IFF decoder

Måns Rullgård mans
Thu Apr 29 17:05:56 CEST 2010


Sebastian Vater <cdgs.basty at googlemail.com> writes:

> M?ns Rullg?rd a ?crit :
>> Michael Niedermayer <michaelni at gmx.at> writes:
>>
>>   
>>> On Thu, Apr 29, 2010 at 03:36:07PM +0200, Sebastian Vater wrote:
>>> [...]
>>>     
>>>> static void decodeplane8(uint8_t *dst,
>>>>                          const uint8_t *buf,
>>>>                          const unsigned buf_size,
>>>>                          const unsigned bps,
>>>>                          const unsigned plane)
>>>> {
>>>>     START_TIMER;
>>>>     const uint8_t *end = dst + (buf_size * 8);
>>>>     const uint64_t *lut = plane8_lut[plane];
>>>>     for(; dst < end; dst += 8) {
>>>>         const uint64_t v  = AV_RN64A(dst) | lut[*buf++];
>>>>         AV_WN64A(dst, v);
>>>>     }
>>>>     STOP_TIMER("decodeplane8");
>>>> }
>>>>       
>>> this looks very nice
>>>     
>>
>> Is the length always a multiple of 8 now?  Earlier you said 4...
>> What's the deal?
>
> Seems you're mixing this with sth. up...

Never mind, I'm stupid.  The input is read a byte at a time, so
there's got to be something there.  Writing something random in the
padding area of the decoded image should be harmless.

> But I assume that AVPacket->data and AVFrame->linesize[0] are aligned to
> 16 bytes for allowing e.g. MMX processing the image data. ;-)

AVPacket.data has no alignment constraints.  Each line in the decoded
image is aligned to 8 or 16 bytes depending on things.

-- 
M?ns Rullg?rd
mans at mansr.com



More information about the ffmpeg-devel mailing list