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 _______________________________________________ FFmpeg-soc mailing list [email protected] http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
