clean implementation

    I agree with the comments made by Luca, Char, shlezman and others.  A clean
implementation should be started.  My initial suggestion of a Java implementation
could not be a good idea as much of you said.  Main reasons are that people are
not mainly interested in a testing/research tool but want a real and practical
implementation.

    Starting a clean implementation in C/C++ is not going to be an easy task, and
as some said and i subscribe, much of us have other important dutties to do all over
the week.  I believe that what is need is an initial framework where start hacking
into.  Once that code critical mass has been surpassed everything should follow.

    I propose the following:

    -    language of choice: C++.  With this i mean different things.  I mean a real
OO implementation, not just a bunch of code packed in a single class.  I don't mean
a pure OO extremely fine grained implemenation where everything is a class.  We
want a clean implementation, but a real and efficient one also.  So nothing of creating
objects unnecessary.  A good OO architecture will allow further optimizations ( for
example, replacing/subclassing a "transform" class to use MMX/AltiVec).

    A nice starting milestone could be to get to a more or less full functional codec
that only makes use of intra pictures.  For this, the following things must be
implemented:

    -    intra predictor
    -    transform and quantize
    -    CAVLC
    -    bit stream parse/generation
    -    deblocking filter ( optional at the begining)

    Then, as shlezman stated, we could go for the following:

    -    P, B frames
    -    multiple reference frames
    -    CABAC
    -    rate-distortion optimization
    -    ...

    I already have been working on intra prediction and T/Q and could start contributing
in that aspect.  Well, i also have some ideas of what a clean and efficient OO framework
could be.

    /AITOR
  ----- Original Message ----- 
  From: [email protected] 
  To: [email protected] 
  Sent: Wednesday, March 26, 2003 9:27 AM
  Subject: RE: [Hdot264-devel] project extension proposal 


        Hi all,

        I'd like to enforce Luca's opinion. The H.264 decoder can deliver great performance (even without much assembly work) for as long as it has nothing to do with the RS and I strongly believe that this is correct for the encoder as well. Playing around with "working code" and optimizing bits here and there can last forever and never deliver the desired results.

        A new, simple, basic and generic design is required (even OO). Milestones must be defined, for example:

        Stage 1 - baseline profile encoder/decoder

        Stage 2 - Add B frames, improve motion estimation algorithms, and begin assembly work

        Stage 3 - add CABAC , RD optimizations

        Once these points are defined the "real" work can be started. As for clean code for algorithmic work, the RS is good enough for that purpose, maintaining three versions of the same code is really unnecessary. There's a jvt group that dose that thing exactly and delivers results.


       


------------------------------------------------------------------------------
  Walla! Mail, Get Your Private, Free E-mail from Walla! at:
  http://mail.walla.co.il