[Ffmpeg-devel] Re: [RFC] mpeg2 422 encoding.

[Michael Niedermayer]

Hi

On Thu, Apr 13, 2006 at 02:56:38PM +0200, Baptiste COUDURIER wrote:
> Hi
> 
> Michael Niedermayer wrote:
> >[...]
> > 
> > you did, but gcc doesnt like your code, the mpeg4 mb encode code is 7% 
> > slower now (meassured with START/STOP_TIMER)
> > 
> > the problem with gcc likely is that there are various limits on inlining
> > and gcc includes the manual inlining from always_inline so that
> > forcing a function to be inlined will cause another function to no longer
> > be inlined
> > 
> > either
> > A. add always_inline everywhere (not realistic)
> > B. change the limits via command line paramaters to gcc
> > C. inline fewer functions
> > D. reduce the size of the inlined stuff
> > E. use the preprocessor to do the inlineing so that gcc doesnt know (ugly)
> > F. combination of the above
> > 
> > note, "nm mpegvideo.o" shows which functions are in there (the missing ones
> > where inlined everywhere), and IIRC there is a option for gcc too which 
> > prints warnings if something wasnt inlined which had a inline keyword ...
> > 
> 
> All right. I added -Winline to gcc parameters and indeed, even atm some
> functions are not inlined. Basically add_dct, put_dct.
> Im not feeling really confortable in code optimization. I miss the basics.
> 
> I'll only check for 420 in the code for now. May I ask what is the exact
> performance test you are using ? START/STOP_TIMER around encode_mb ?

the exact test i used is:
Index: mpegvideo.c
===================================================================
RCS file: /cvsroot/ffmpeg/ffmpeg/libavcodec/mpegvideo.c,v
retrieving revision 1.513
diff -u -r1.513 mpegvideo.c
--- mpegvideo.c 31 Mar 2006 20:43:37 -0000      1.513
+++ mpegvideo.c 13 Apr 2006 20:50:43 -0000
@@ -4849,7 +4849,7 @@
 //            int d;
             int dmin= INT_MAX;
             int dir;
-
+START_TIMER
             if(s->pb.buf_end - s->pb.buf - (put_bits_count(&s->pb)>>3) < MAX_MB_BYTES){
                 av_log(s->avctx, AV_LOG_ERROR, "encoded frame too large\n");
                 return -1;
@@ -5342,6 +5342,7 @@
                     ff_h263_loop_filter(s);
             }
 //printf("MB %d %d bits\n", s->mb_x+s->mb_y*s->mb_stride, put_bits_count(&s->pb));
+STOP_TIMER("encode_mb")
         }
     }

and i also added -mcpu=athlon -mtune=athlon -march=athlon to the flags but i
see no reason why either the flags not the exact START/STOP_TIMER location
would make a big difference ...



> What is a "significant" number of runs ?

a few seconds of video (preferably not a few seconds of the same almost
unchanged picture though)


> 
> Btw, I still have a bug with -mbd bits, and it's a bit annoying (green
> bottom chroma macroblock in P frames, if using -bf > 8 the bug vanish).
> Since you best know mpegvideo.c, do you see where it could be located ?

maybe its caused by:

        s->dest[0] = s->rd_scratchpad;
        s->dest[1] = s->rd_scratchpad + 16*s->linesize;
        s->dest[2] = s->rd_scratchpad + 16*s->linesize + 8;

the + 8 would cause some overlap ...

it could also be something else

[...]
-- 
Michael

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is