RE: project extension proposal

Hi there, this is my first post into this list. Hi All!

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. 

Take MSSG (Mpeg Software Simulation Group) MPEG2 decoder and libmpeg2 for an
example. The MSSG decoder tried to show many aspects of the standard in a
clear but not efficient way. Most companies took the source and started
patching all over it to make it faster... It works, but it ends being a
mess. 
Take libmpeg2, Aaron Holtzman looks at the standard and gets a feeling of
the whole picture. Then he goes an rewrites an scheme that focuses on actual
performance and usability. No support for scalabilty profiles, no bitstream
checkings, much more compact and simple. 

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

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

Take care
Alberto


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