[FFmpeg-devel] [PATCH] Assign unique values to AV_CPU_FLAG_IWMMXT and AV_CPU_FLAG_ALTIVEC.
Wed Sep 8 19:44:52 CEST 2010
Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> On Wed, Sep 08, 2010 at 11:41:54AM -0400, Ronald S. Bultje wrote:
>> On Wed, Sep 8, 2010 at 11:32 AM, Janne Grunau <janne-ffmpeg at jannau.net> wrote:
>> > On Wed, Sep 08, 2010 at 09:55:04AM -0400, Ronald S. Bultje wrote:
>> >> On Wed, Sep 8, 2010 at 7:44 AM, Janne Grunau <janne-ffmpeg at jannau.net> wrote:
>> >> > if (mm_flags && FF_MM_MMX)
>> >> > ? ? ? ?cpuflags |= SWS_CPU_CAPS_MMX;
>> >> > if (mm_flags && FF_MM_ALTIVEC)
>> >> > ? ? ? ?cpuflags |= SWS_CPU_CAPS_ALTIVEC;
>> >> >
>> >> > had strange results since SWS_CPU_CAPS_MMX != SWS_CPU_CAPS_ALTIVEC.
>> >> > Easily solveable with adding HAVE_(MMX|ALTIVEC) && to the ifs.
>> >> This should all be under ARCH_PPC or HAVE_MMX and similar. x86-family
>> >> CPUs supporting altivec don't exist.
>> > yes, the working code has 'if (HAVE_ALTIVEC && mm_flags & FF_MM_ALTIVEC)'
>> Excellent. Stefano, do you think it makes sense to document these
>> flags a little so that it's obvious that altivec can only be used
>> conditionally based on HAVE_ALTIVEC, x86-flags based on HAVE_MMX etc.?
>> This should really be documented to prevent this from coming up again
>> or causing issues for people.
> Defining them to 0 for the "wrong" architectures like Michael suggested
> might be the nicer solution...
That means cluttering up public headers with fragile ifdefs.
mans at mansr.com
More information about the ffmpeg-devel