Re: Re:sketch implementation

> > The first draft sketch has a major problem of too
> > much OO as I see it.
> 
> Well, we're going to argue between large and fine
> grained OO.  As I see it, things that should certainly
> be classes (thinking about a decoder here are:
>   An image (your Frame class)
>   The decoder itself
>   The loop filtering

    The most "fine grained" class in the draft proposal is the block/macroblock
class.  I believe that this is a key abstraction that should be reflected in the design.

    A main problem with the current version is that it is a template class and that is
keeping the array pointer to the samples.  In C++ templates are evil and 
difficult to understand and maintain.  Templates should be minized and used
in cases where flexibility/performance issues demand it.  Definitively 'BaseBlock'
should not be a template.  Regarding the array pointer, this is just a convenience
utility that is used in the straightforward implementations.  More optimized versions
should avoid this indirect indexing.  Definitively, this utility behaviour should be
moved out of 'BaseBlock'.  I will change the design in the next proposal to refect
these thoughts.

    Otherwise i think that the draft sketch is not extremely OO at all.  I wish you
know the proposals i had for the Java version... :-)

> One problem with using virtual functions to allow
> different classes to implement MMX, SSE, etc. is that
> two function indirections (thanks to virtual function
> table) are needed when a function is called.  This
> could be costly, I'm not sure.  Codecs like xvid use
> only one function pointer indirection (e.g. when I do
> a fast iDCT, I jump to the function pointed to by a
> funcion pointer whose value was set at
> initilialization when my processor was detected).  If
> this overhead of the double indirection is not
> significant, then we certainly should use virtual
> functions to implement different optimizations.

    There is a common misbelief that OO means slow.  This is not true at all, and less
in the C++ case.  Where are the performance penalties of C++ comparing to C?  As
you have noted, only in virtual methods, and that's the single reason why the 'virtual'
keyword exist in C++ ( in this context, not 'virtual classes').

    In our case, virtual methods are just entrypoints to very computationally expensive
routines, they are not used in other parts of the design.  For example, transformations
are so expensive ( computationally speaking) that an memory access ( the true cost
of a virtual method call) is negligible.  Just save a few machine instructions in the routine,
and the virtual cost is pay back.

    A virtual method is just a function pointer, so the cost is the same.

> The other reason for not using too much OO is it
> allows people who know C but not C++ to use the code.

    This could be the major problem.  But look at http://www.openh323.org/, it
is implemented in C++ ( a true fine grained OO design in this case) and it is a great
success.  The OO aspect of the codec is just an architectural issue, all key code
( transform, quantize, predict...) is plain procedural code packed into methods.
The most valuable contributions will come surely in that code.

    I believe that a clean, simple and stable OO design could be a key advantage
of OH264 over other alternatives.

    /AITOR




-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en