On 2016-01-15 21:55, James Almer wrote: > On 1/15/2016 5:00 PM, James Darnley wrote: >> On 2016-01-15 03:55, James Almer wrote: >>> On 1/14/2016 11:05 PM, James Darnley wrote: >>>> diff --git a/libavcodec/x86/h264_deblock.asm >>>> b/libavcodec/x86/h264_deblock.asm >>>> index 5151f3c..20f0814 100644 >>>> --- a/libavcodec/x86/h264_deblock.asm >>>> +++ b/libavcodec/x86/h264_deblock.asm >>>> @@ -864,7 +864,47 @@ ff_chroma_inter_body_mmxext: >>>> DEBLOCK_P0_Q0 >>>> ret >>>> >>>> +cglobal h264_h_loop_filter_chroma422_8, 5, 7, 8, mmsize + >>>> ARCH_X86_64*2*mmsize >>> >>> This will not work with x86_32 compilers that don't have aligned stack >>> (Like msvc) >>> because r6 is needed to store the stack pointer. >> >> The other chroma deblock function I borrowed most of this from doesn't >> appear to use any guard against that (see a few lines above where my >> patch starts). Neither in assembly or in the init function. > > That's because the other chroma function doesn't allocate stack using x86inc > magic. > On x86_32 it uses r#m only and on x86_64 it handles the stack pointer by > itself.
I don't understand how that works then. It calls the cglobal macro. Does that not just assume missing args are 0? I'd better look and follow that more closely.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
