[FFmpeg-devel] [PATCH] Fix unaligned fill_rectangle in rv34.c

Måns Rullgård mans
Fri Aug 21 12:40:22 CEST 2009


Kostya <kostya.shishkov at gmail.com> writes:

> On Fri, Aug 21, 2009 at 11:57:08AM +0200, Michael Niedermayer wrote:
>> On Thu, Aug 20, 2009 at 10:33:19AM +0300, Kostya wrote:
>> > On Thu, Aug 20, 2009 at 09:14:54AM +0200, Reimar D?ffinger wrote:
>> > > Hello,
>> > > rv34.c uses fill_rectangle with only 4 bytes alignment, which causes
>> > > crashes on 64 bit architectures without unaligned read support like
>> > > Sparc/Solaris.
>> > > This patch hacks rectangle.h to support this kind of use - this
>> > > seemed the simplest, even though rather hackish, way to me.
>> > 
>> > May I add that it happens when zeroing motion vectors for some
>> > macroblock, i.e. where there will be non-64bit align for sure.
>> > 
>> > Probably better solution would be to disable this code automatically for
>> > such archs. I don't remember an outcome of my discussion with Mans
>> > about that though.
>> 
>> I dont know about your discussion with mans, but if i remember correctly
>> and dont mix this up with some other issue, then at least my conclusion
>> was that your code is buggy and fails to align the code correctly.
>> IIRC something about using a random incorrect *_stride but i might
>> missremember
>
> That was another alignment issue which is fixed now.
> Now it happens with zeroing motion_val[] which has guaranteed alignment 32
> but even macroblocks will have motion_val[] with that alignment while
> some CPUs (Sparc) require aligment 64 to fill it as int64.

That leaves us with two options:

1. Fix the RV code to use correctly aligned buffers.
2. Do something like Reimar's patch.

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



More information about the ffmpeg-devel mailing list