[FFmpeg-soc] Status of the Dirac codec
mgerards at xs4all.nl
Tue Sep 4 17:33:41 CEST 2007
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
- 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,
- 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.
- 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).
- 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
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:
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?
More information about the FFmpeg-soc