[FFmpeg-soc] Status of the Dirac codec

[Marco Gerards]

Hi,

Summer of code has officially ended, but my work on the Dirac
implementation hasn't :-).  In this email I try to explain what the
problems (as I see them) are with the current code, missing features,
possible enhancements and the status of Dirac itself.  This is mainly
an extended version of my TODO, but just the most interesting things.

First the worst part of this email, things I do not really like about
my code:

- The frame decoding (dirac_decode_frame and decode_frame) is a bit
  messy, especially with those dprintfs.
- I need to clean up DiracContext and store things like width, height
  etc. properly in an array instead of luma_width and chroma_width,
  etc.
- I still have to interleave the lifting steps in the I(DWT).

Feel free to extend this list for me.  I am a perfectionist and want
to have good code.

Missing features:

- The low delay syntax is not yet supported.  This is a special that
  is used when arithmetic coding was disabled.  Although I do not
  think it is the most interesting part of Dirac (at least not for
  me), but it will not be hard to support this.
- Interleaving.  I just have to learn more about interleaving, if
  FFmpeg supports this well, it should not be too hard I hope?
- Global Motion Estimation is not supported yet.  The reference
  implementations do not support it either, that is the main reason it
  is still missing, it is impossible to test.
- Some wavelets need to be added to be fully compatible with the
  specification.  However, the default ones are implemented, I do not
  think the others will be often used.  But to be 100% compatible this has
  to be done.
- The encoder can not encode inter frames yet and it doesn't do
  quantization.  Otherwise it works (thus you will get intra frames).

Possible optimizations:

- Write arithmetic (de)coding in assembler or so.  The people from BBC
  research thinks arithmetic (de)coding causes the most significant
  slowdown.  So focussing on this might speed up both the decoder and
  encoder.  By not using GetBitContext/PutBitContext this can also be
  speed up, but I am not sure how... I will have to use bit operations
  anyways I think?
- The (I)DWTs can be improved by interleaving and in place reordering
  of the coefficients.
- Frames should be padded so have a width that is a multiple of 16, so
  algorithms can be implemented using SIMD instructions.
- The spatial weighting matrices for the border can be precalculated
  as well.  They can be merged with the weights for the frames to save
  yet another multiplication.

Dirac itself is almost ready.  Something that is missing in the
reference implementations is Global Motion Compensation.  The most
important thing for me that is missing is the text on profiles and
levels.  According to the website it is something they are working on
ATM, so I expect this soon and perhaps that will mean version 1 will
be released.

Michael had some comments on the 10taps filter they use for
interpolation.  I brought this up on their public forum and the Dirac
developers reacted on this with a lot of explaination:

http://sourceforge.net/forum/message.php?msg_id=4499441


Now I will first focus on the encoder, especially writing out the
bitstream.  That way I will know how to split up the huge dirac.c file
into the decoder and encoder.  I am not sure how long we should wait
to put this into SVN.  Perhaps we should wait until the Dirac codec is
released?  Having Dirac support now is useless anyways I think.  In
the meanwhile I can keep working at this without disturbing anyone in
any way.  I wonder if I keep working in the same way I am used to when
Dirac makes it into SVN or should I go through the devel list with
patches or so?

--
Marco