[FFmpeg-soc] Status of the Dirac codec

[Marco Gerards]

Michael Niedermayer <michaelni at gmx.at> writes:

Hi,

> On Tue, Sep 04, 2007 at 05:33:41PM +0200, Marco Gerards wrote:
> [...]
>> - Interleaving.  I just have to learn more about interleaving, if
>>   FFmpeg supports this well, it should not be too hard I hope?
>
> did you mean interlacing?

Yes, I don't know what I was thinking when I typed this :-)

>> - 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.
>
> GME (on the encoder side) is _likely_ not very important, i wouldnt expect
> much gains from it. in mpeg4 allmost all of the (small) quality/bitrate gain
> GMC has is not due to global motion compensation itself but rather due to
> a change to the used motion vector for skiped blocks

Ok, good to know.

> [...]
>> 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?
>
> just curious, how much time is spend in arithmetic decoding in your codec?
> arithmetic decoding shouldnt eat 90% of the time ...

No, I was actually quite surprised by this.  The BBC even has a low
delay syntax because of this.

Here are the first lines of the gprof output.  I hope this provides a
good overview about how much time is spend for the arithmetic
decoding.  Perhaps because of inlining the arithmetic decoding cost is
added to the functions for unpacking coefficients/MC data.  If I
interpret this correctly, the aritmetic decoding takes up 5% of the
time.  However, this will increase when my code is further optimized
and vectorized, in that case arithmetic decoding costs might become
significant, I don't know enough about this yet to estimate this.  But
I do not expect drastic changes, that's for sure :-)

  %   cumulative   self              self     total           
 time   seconds   seconds    calls  ms/call  ms/call  name    
 47.56      1.46     1.46       50    29.20    58.84  dirac_decode_frame
 18.89      2.04     0.58   417867     0.00     0.00  motion_comp_block1ref
 13.36      2.45     0.41  8689089     0.00     0.00  coeff_unpack
  6.84      2.66     0.21      540     0.39     0.39  dirac_subband_idwt_53
  6.51      2.86     0.20  8707719     0.00     0.00  dirac_arith_read_uint
  1.95      2.92     0.06       60     1.00     1.00  dirac_subband_idwt_95
  1.30      2.96     0.04   646968     0.00     0.00  dirac_arith_read_int
  1.30      3.00     0.04       45     0.89     2.62  dirac_unpack_prediction_data
  0.98      3.03     0.03  1837327     0.00     0.00  dirac_arith_get_bit
  0.98      3.06     0.03      178     0.17     0.38  dirac_unpack_motion_vectors
  0.33      3.07     0.01                             dirac_arith_write_int
  0.00      3.07     0.00     2048     0.00     0.00  ff_ac3_parse_header
  0.00      3.07     0.00     2044     0.00     0.00  ff_mpa_decode_header
  0.00      3.07     0.00     1783     0.00     0.00  av_malloc
  0.00      3.07     0.00     1738     0.00     0.00  av_free
  0.00      3.07     0.00     1675     0.00     0.00  dirac_arith_flush
  0.00      3.07     0.00     1675     0.00     0.00  dirac_arith_init

>> 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.  
>
> personally i would prefer it to be moved to ffmpeg svn rather sooner than
> later it would get more testing thus bugs will be found quicker and it would
> also be more likely that other developers would contribute though i dont
> think many will but who knows ...

How about waiting until I cleaned up the things I do not like and
until I split up dirac.c, so I can work on the encoder separately?
This should not take too long, although I have classes to distract me
again :-/.

>> 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?
>
> no, just commit directly, patches would only be apropriate for code
> outside dirac* or change for which you would like some comments
> like maybe if you are unsure about some lavc API or whatever

Ok, great :-)

In my previous email I forgot to thank everyone.  Special thanks go to
Luca and Michael, both read all of my code and came with good and
constructive comments, explained a lot of things that were not clear
to me, etc.  But I would also like to thank Mike for making this
possible and all other people on this list for reviewing my patches.
I really appreciate your help, thanks guys :D

--
Marco