Re: Re:sketch implementation

	Hi,

	just for the record, I'd like to share some experience
	I gained writing a C++ MPEG4 codec:
 
	- Object-Oriented-ness becomes rather quickly useless 
	the more you dive into the "imperative" coding
	required for a codec. More, it can be a burden for
	the coder, and for the newbie passing-by "just to have
	a look" and eventually giving a hand for a small contribution.
	Only may the top-layer benefit from OO abstraction, but
	you soon get in the dirt underneath.

	- there's few place for real abstract object, as opposed
	to writing , dunno, widget classes, say.
	Most of the time, you *know* where you stand, what you
	are dealing with (Intra Block? Method3-predicted 8x16 block?).
	and what you are doing (fetching bits for a intra coeff? 	predicting a
motion vector?). There's no real need for some
	 block->predict() or whatever virtuals. It's quicker to write 
	an explicit C function void Predict_Intra_8x16_Block(...), 
	and sometime easier to understand for others.

	- Using virtual to switch Ref/C/MMX implementation is a
	little bit too much of hammering, i think. Why not simply
	use a good ol' function pointers array?? I works very well,
	and unlike virtual, they can be replaced at run-time on
	objects instances...

	Anyway, there is some kind of OO hierarchy worth in a codec,
	mainly because both the encoder and decoder will need to
	share some common syntax parameters + user settings, at
	least. A because an encoder *is* (partially) also a decoder.
	But the hierarchy usually stops here. Most of the remaining
	per-frame data required can be gathered into a cursor
	(or macroblock-iterator, if you prefer) collecting most
	of the imperative code, and thrown away after frame
	reconstruction.

	all the sudden, I fear I'm not that clear trying to explain
	myself :) Anyway, to summarize: I think the granularity is
	coarser than one might expect.


	bye,
		Skal

PS: as a side note: I don't think the specified Hadamard transform
(itrans()) is the best candidate for immediate MMX optimization.
It's been simplified to a point a good C-compiler can do great thing
with it. To my humble opinion, 1/4-pel prediction are far more
challenging...

PPS: my MPEG codec sources:
http://skal.planet-d.net/coding/mpeg4codec.html
With it, I was able to quickly hack the basis of a h264 decoder
within one hour (the code I already posted here was just a backport
of some funcs toward ref software, btw)



On Thu, 2003-03-27 at 14:48, Aitor Garay wrote:
> 
> > > 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').
> 
>      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
> _______________________________________________
> Hdot264-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/hdot264-devel
> 




-------------------------------------------------------
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