Re: project extension proposal

> I guess I should know exactly what the goals of hdot264 are, but assuming is
> the creation of a usable codec there should definitely be a rewrite in the
> sources. 

    I agree with you, but as Christoph noted in previus messages, people will
not get fun in working in a rewrite of the codec, at least in the initial stages where
no visible results are get.  I agree with him also.  It's a tricky issue... :-(

> The same approach would sound like a good idea for hdot264 although it
> sounds like quite a daunting task! 

    It is ineed.  And more with H.264!

> About Java implementations... I don't think it would be a good idea as it
> would be incredibly sloooow, and you can model things more than fine with
> simple C or C++.

    Well, as i stated early, the objective of the Java implementation is not to be
performance efficient.  It aims to be clear, safe, extensible and flexible.  Java
( or C#, or Eiffel) make the task much more safe, no more out of index array
accesses...

    I understand that most of the people would not be interested in a clean Java
implementation, since it use is mainly for learning and research.  People want
an efficient implementation that outperforms DivX and similar codecs in quality/rate.

    Respecting the C/ASM version performance issue, it's going to be a headache
anyway.  I have been using the H264 codec from VSS.  They have made a great
work with it, and they report that for full frame _playback_ they need a 3GHz Pentium
IV ( http://forum.vsofts.com/viewtopic.php?t=18).  Enconding is even much more
painfull: intra prediction, CABAC or CAVLC, multiple reference frames, in-loop
deblocking filtering... not taking into account the huge complexity this supposes.

    A performance efficient implementation _must_ use MMX/SSE/SSE2/AltiVec
instructions to parallelize things up.  Much times, a choice must be done, efficiency
or the rest ( clear code, flexibility...).  Anyway, i believe that a clean new C++
implementation could achieve both goals, even using native SIMD code.  May be
it is not necessary to resort to Java for it...

    /AITOR
   

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf 
> Of Aitor Garay
> Sent: Tuesday, March 25, 2003 8:37 AM
> To: [email protected]
> Subject: Re: [Hdot264-devel] project extension proposal
> 
> 
> 
> > I guess most reference implementations are like that. At 
> least MPEG-4 
> > versions are. They grew over years, being changed all the 
> time. Once 
> > they compile they are good to "fix" a bitstream format and test for 
> > compliance, but learning from them it difficult.
> 
>     Not confirmed, but I have heard that the roots of the 
> H.264 reference software go to MPEG-2.  It evolved to H.263 
> and now to H.264.  Too many (de)generations...
>   
> > My suggestions is: Do it the way XVID did.
> > Start more or less with the reference implementation, so you have a
> > running plattform. Then replace more and more code by more 
> readable and
> > hopefully faster code until finally all old code has been 
> replaced.  
> > Starting from scrathc, without a running encoder, 
> developing is no fun.
> > You have to see the codec advancing, getting faster, getting more
> > efficient.
> 
>     Your are very rigth, there is no fun in developing a 
> codec without getting inmediate results, but there is also no 
> fun at all in refactoring functions of hundreds of lines that 
> do nine or ten different things at the same time and whose 
> name has nothing to do with any of them.  And if those 
> functions use heavily global data things get even worst... :-(
> 
> > If you (and others) are willing to create a java model: Great! Many 
> > people will benefit from it. But I doubt that many people 
> will be as 
> > altruistic, to create a new version that runs even slower than the 
> > present one. Much more people will be interested to help create a 
> > _faster_ and therefore _usable_ version.
> 
>     Your are again rigth, but may be so much complexity in 
> the reference software will make people think twice before 
> trying to hack into it.  Someone with great insight of it 
> should start with a deep cleaning and refactoring to make it 
> more amenable to general hacking.
> 
>     /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