[FFmpeg-devel] [PATCH] avcodec/h264: mmxext 4:2:2 chroma deblock/loop filter

[Ronald S. Bultje]

Hi,

On Fri, Jan 15, 2016 at 4:47 PM, James Darnley <james.darnley at gmail.com>
wrote:

> 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.


Yes, it uses %ifnum on %4. If it's a number, it takes it as stack mem, else
it takes it as name of first function argument.

Ronald