[FFmpeg-soc] Status of the Dirac codec
mgerards at xs4all.nl
Wed Sep 5 17:07:13 CEST 2007
Michael Niedermayer <michaelni at gmx.at> writes:
> 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
>> 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
More information about the FFmpeg-soc