[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