[FFmpeg-devel] [PATCH] Port x264 SSE2 deblocking code to H.264 decoder

Michael Niedermayer michaelni
Fri Dec 19 14:45:45 CET 2008


u   On Fri, Dec 19, 2008 at 05:40:44AM -0800, Jason Garrett-Glaser wrote:
> On Fri, Dec 19, 2008 at 1:42 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Thu, Dec 18, 2008 at 10:25:53PM -0800, Jason Garrett-Glaser wrote:
> >> On Thu, Dec 18, 2008 at 8:28 PM, Jason Garrett-Glaser
> >> <darkshikari at gmail.com> wrote:
> >> > On Thu, Dec 18, 2008 at 5:34 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> >> On Thu, Dec 18, 2008 at 05:22:51PM -0800, Jason Garrett-Glaser wrote:
> >> >>> On Thu, Dec 18, 2008 at 5:09 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> >>> > On Thu, Dec 18, 2008 at 04:47:24PM -0800, Jason Garrett-Glaser wrote:
> >> >>> >> OK, now we have luma_intra in DSPutil, so this should be easier.
> >> >>> >>
> >> >>> >> Michael: how should we rename the x264 functions?  My thought was just
> >> >>> >> to s/x264/ff_h264/ or something of the sort, which would modify the
> >> >>> >> code from x264's version but make it trivial to modify the code before
> >> >>> >> committing any updates from x264.  It wouldn't need ugly #defines
> >> >>> >> either.
> >> >>> >
> >> >>> > didint loren post some patch that changed cglobal to add a prefix
> >> >>> > automagically ...
> >> >>>
> >> >>> Shouldn't that be a separate patch?  If it's fine, can I commit his
> >> >>> patch now then?
> >> >>
> >> >> ive approved his patch, so yes you can apply it of course
> >> >
> >> > applied (sorry for forgetting credit, forgot to add Loren's name to
> >> > commit message).
> >> >
> >> > Updated x264 deblock patch attached.
> >> >
> >> > Dark Shikari
> >> >
> >>
> >> Small error in patch fixed.
> > [...]
> >> @@ -2853,6 +2864,23 @@
> >>          }
> >>  #endif
> >>
> >> +#if defined(CONFIG_GPL) && defined(HAVE_YASM)
> >> +        if( mm_flags&FF_MM_MMXEXT )
> >> +        {
> >
> >> +#ifdef ARCH_X86
> >> +            c->h264_v_loop_filter_luma_intra = ff_x264_deblock_v_luma_intra_mmxext;
> >> +            c->h264_h_loop_filter_luma_intra = ff_x264_deblock_h_luma_intra_mmxext;
> >> +#endif
> >
> > why is this under ARCH_X86 ?
> > ARCH_X86 is always defined in this context
> 
> Under 64-bit, x264 doesn't compile functions that are never used on
> 64-bit (e.g. cases where all x86_64 machines would use the SSE2 code
> instead of MMXEXT, so why waste binary space).  In x264, ARCH_X86 and
> ARCH_X86_64 are mutually exclusive.
> 
> Should I use #ifndef ARCH_X86_64 then?

#ifdef ARCH_X86_32 should work

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081219/c32cc8f1/attachment.pgp>



More information about the ffmpeg-devel mailing list