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