Re: Re: H.264 codec and optimization issues

 
Agreed your point(s). I just wanted to draw attention to the fact that depending on a "standard" implementation might lead to "blind optimization" efforts in the end. If OpenHdot264's goal is a DirectShow Filter working on the Intel platform, we might well have a look at the algorithm before just copying the equations into the code. People out there might have super-optimized implementations of the inverse transformation with shifts & adds, for example, but it might so happen that on other platforms, shifts and adds might not be the best way to handle the transformation. Example, take any DSP, where shifts and adds are performed by the same unit and multiplies can be done by two units. 
Cheers
Indrajit

 

 Aitor Garay <[email protected]> wrote:> 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 thecost of the transformation itself is optimized a lot, the cost of the function calls couldbe problematic.  That's why in OH264 the Transform::doForwardTransform() methodfor macroblocks is virtual, so a subclass can provide an optimized version for thesixteen 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 PMSubject: 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 alotof CPU. There's a nice MMX implementation suggestedin 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 structureand 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 wayto optimization comes first from doing detailed profiling to see where the performancepenalties come from.  Real life experience is full of cases of huge blind optimizationefforts that at the end result in to significant speed-ups because the bottleneck wasnot there.     Another lesson is that in H.264 ( and in all codecs in general), the performancehot-spots are located in a few "kernels" ( like transform, SAD, VLC...).  In thisaspect, the eventual performance penalties deriving from a "clean" implementationwill not impact performance in any significant way, since the bottlenecks will lieinto those kernels. ----- Original Message ----- From: Indrajit Chakrabarty To: [email protected] Sent: Monday, March 31, 2003 10:54 AMSubject: [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



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