[Ffmpeg-devel] [PATCH]: Too much alignment assumed by H264 decoder

[Luca Barbato]

Ivan Kalvachev wrote:
> 2005/12/22, Mike Melanson <mike at multimedia.cx>:
> 
>>David S. Miller wrote:
>>
>>>These uint64_t cast memory operations cause unaligned accesses on
>>>platforms such as Sparc, there really isn't anything in the
>>>datastructures to ensure this level of alignment.
>>>
>>>But uint32_t seems to work fine, as the following patch against
>>>current CVS implements.
>>
>>        Wait... run that by me again: 8-byte alignment causes crashes but
>>4-byte alignment is okay? I hope I don't have to point out that this
>>doesn't make much sense. Or are you saying that the compiler you are
>>using on Sparc does not support 8-byte alignment and so the data
>>structure is being aligned on a random boundary?
>>
>>        I must contend that if something in FFmpeg is aligned on an 8-byte
>>boundary, it it probably that way for a good reason. One such reason is
>>SIMD operations.
> 
> 
> Hum.. how about using memset instead of this manual filling?
> I'm sure it would be trivial to write an SIMD optimized memset.
> We need it in few other places (e.g. better than dsp.clear_blocks)

libfreevec should have some useful stuff, I hadn't the time to test 
extensively on ffmpeg but looks interesting enough.

lu

-- 

Luca Barbato

Gentoo/linux Developer		Gentoo/PPC Operational Leader
http://dev.gentoo.org/~lu_zero