project extension proposal

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

    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...) that
must be reused.  The clean implementation should use code from both RS and other
codecs and be refactored in best way is believed.

    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?

    /AITOR