Re: project extension proposal
Christoph Lampert <[email protected]> Tue, 25 Mar 2003 16:55:59 +0100 (CET)
| Newsgroups | gmane.comp.video.h264.devel |
|---|---|
| Message-ID | <[email protected]> |
On Tue, 25 Mar 2003, Aitor Garay wrote: > Hello hdot264-devel!, > > A few months ago i started working on H.264. During this time i > have been digging inside the reference software trying to see how > things worked. My _personal_ experience is that the reference > software is, at least, a huge mess. I'm not questioning at all the > correctness of it, just say that the structure and coding style of it > make it very hard to understand, modify or optimize. 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. > I haven seen that the approach taken in this project is to rely > on the reference software ( RS). This makes a lot of sense, since a > huge amount of work is saved. But if the objective of the project is > to implement an efficient codec, for example using MMX/AltiVec > instructions, then the RS must be, again at least, _heavily_ > refactored. The RS is still under development by the standard group, > so a parallel development based on it should be very careful when > merging it with new released versions. > > So, i propose two things: > > First. It could be great to have a very clean implementation of a > H.264 codec in a safe language, for example Java. The objective is to > have a clean and safe implementation that could be used as a testbench > for new algorithms/ideas and as a learning tool. I'm sure that an > initial implementation ( excluding motion estimation and CABAC) could > be implemented in a very reasonable amount of time. It would be good to have a clean implementation in Java or anything else. But I guess not many people would be willing to create a second reference implementation. And a Java version would only be that: good for learning, but not for using. > Second. Instead of investing time and effort in understanding and > refactoring an unfinished reference software, i propose to start a > more or less clean implementation. And i mean more or less because i > believe that starting from scratch makes not sense. A lot of useful > and very good work has been made in the RS and other codecs ( xdiv...) Our name is XVID... XDIV? That sounds like a pentium bug or so :-( > that must be reused. The clean implementation should use code from > both RS and other codecs and be refactored in best way is believed. 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. The process will be faster than for XVID, because large parts of new code are already there (just the licenses might be a problem). > Please note that both approaches have very different objectives. > The Java implementation has no performance issues in mind, just to be > useful as a learning/testing tool. High codec quality is also a > objective. The C/ASM implementation will focus more on > rate/distortion/performance issues. > > Now i'm far more interested in the clean/safe approach. I have > been working in a Java model of the codec that could be used as a > starting point. > > What does the community thing about all this? 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. Christoph -- Christoph H. Lampert chl@math,uni-bonn,de | Diese Signature ist maschinell Beringstr. 6, Zi. 15, 53115 Bonn, Germany | erstellt und auch ohne Unter- Tel. (0228) 73-4708 Fax. +49 228 73-7916 | schrift wirksam. AZ 27B/6 ------------------------------------------------------- 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