Re: Re: H.264 codec and optimization issues

"Aitor Garay" <[email protected]> Mon, 31 Mar 2003 14:37:18 +0200
Newsgroups gmane.comp.video.h264.devel
Message-ID <007f01c2f782$44e87790$bcb31fac@HAJC0062>
> The second "disease" of this codec is the huge amount of function calls, alot of cpu 
> time is wasted on them (especially when you get alot of 4x4 subblocks), so smart data structure
> and codec design is crucial.

    That's true.  With 4x4 transformations, a call is done for each 16 pixels.  When the
cost of the transformation itself is optimized a lot, the cost of the function calls could
be problematic.  That's why in OH264 the Transform::doForwardTransform() method
for macroblocks is virtual, so a subclass can provide an optimized version for the
sixteen 4x4 transforms if it can, or rely on the default version if it can not.

----- Original Message ----- 
  From: [email protected] 
  To: [email protected] 
  Sent: Monday, March 31, 2003 1:51 PM
  Subject: Re: Re: [Hdot264-devel] H.264 codec and optimization issues


        The first thig I saw in the mentioned document is that the Interpolation filters consume alot
        of CPU. There's a nice MMX implementation suggested
        in the jvt ftp pattaya JVT-G025.pdf that's worth examination.

        The second "disease" of this codec is the huge amount of function calls, alot of cpu 
        time is wasted on them (especially when you get alot of 4x4 subblocks), so smart data structure
        and codec design is crucial.


              <[email protected]>
              Re: [Hdot264-devel] H.264 codec and optimization issues 

                  I believe that the lesson that should be learned from this paper it's that the way
              to optimization comes first from doing detailed profiling to see where the performance
              penalties come from.  Real life experience is full of cases of huge blind optimization
              efforts that at the end result in to significant speed-ups because the bottleneck was
              not there.

                  Another lesson is that in H.264 ( and in all codecs in general), the performance
              hot-spots are located in a few "kernels" ( like transform, SAD, VLC...).  In this
              aspect, the eventual performance penalties deriving from a "clean" implementation
              will not impact performance in any significant way, since the bottlenecks will lie
              into those kernels.
               
              ----- Original Message ----- 
                From: Indrajit Chakrabarty 
                To: [email protected] 
                Sent: Monday, March 31, 2003 10:54 AM
                Subject: [Hdot264-devel] H.264 codec and optimization issues


                Dear All

                Please have a look at the following paper "Implementation of H.264 decoder on general-purpose processors with media instructions" which is available at

                http://www.ee.princeton.edu/~ykchen/publications/H264.html

                This paper talks about several modules in the JVT codec and there is an interesting discussion about the implementation and optimization of the inverse transform using shifts and adds only. In the end, for an SSE/SSE2 or even MMX implementation, using shifts and adds may not be very optimal!

                 

                Cheers,
                Indrajit

                 





----------------------------------------------------------------
                Do you Yahoo!?
                Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! 


------------------------------------------------------------------------





------------------------------------------------------------------------
       


------------------------------------------------------------------------------
  Walla! Mail, Get Your Private, Free E-mail from Walla! at:
  http://mail.walla.co.il