[FFmpeg-devel] [PATCH] move ff_emulated_edge_mc() to dsputil

[Michael Niedermayer]

On Wed, Mar 05, 2008 at 11:20:34AM +0100, Aurelien Jacobs wrote:
> On Wed, 05 Mar 2008 08:25:51 +0200
> Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
> 
> > On Wed, 2008-03-05 at 01:04 -0500, Rich Felker wrote:
> > > On Wed, Mar 05, 2008 at 07:32:07AM +0200, Uoti Urpala wrote:
> > > > On Tue, 2008-03-04 at 23:51 -0500, Rich Felker wrote:
> > > > > Splitting dsputil.c and motion_est.c would be a major improvement in
> > > > > compilability. These files are waaaaaay too big and gcc stupidity
> > > > > results in very slow and memory-intensive compiling, probably due to
> > > > > useless searches for global optimizations or something.
> > > > 
> > > > In the case of motion_est.c I'd blame programmer stupidity more than
> > > > compiler stupidity. It has big av_always_inline functions and macros
> > > > using them which are then used lots of times. The code could be written
> > > > more efficiently. (That's the same issue I mentioned earlier when
> > > > discussing object sizes.)
> > > 
> > > Patch welcome.</michaelni>
> > 
> > http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-January/041456.html
> > 
> > Btw changing "av_always_inline int cmp" to "av_noinline int cmp" and
> > comparing object sizes before and after should give you some idea of the
> > amount of repeating code in that file.
> 
> This indeed makes a huge difference (gcc-4.1 x86).
> 
> with av_always_inline:
>    text    data     bss     dec     hex filename
>  484960       0       0  484960   76660 libavcodec/motion_est.o
> 
> with av_noinline:
>    text    data     bss     dec     hex filename
>  140566       0       0  140566   22516 libavcodec/motion_est.o
> 
> Now, I don't know exactly what to benchmark to see if it makes
> a big difference speedwise.

ff_pre_estimate_p_frame_motion()
ff_estimate_b_frame_motion()
ff_estimate_p_frame_motion()

with various common cases (SSE / SAD comparission, hpel/qpel, mbd 0/1,
interlacing, 4mv, chroma ME)

Sadly theres a lot which could be interresting to benchmark but even just a
subset of this would be interresting.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is not what we do, but why we do it that matters.
-------------- 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/20080305/056e2931/attachment.pgp>