[FFmpeg-devel] Dirac Golomb decoder [PATCH]

[Marco Gerards]

Michael Niedermayer <michaelni at gmx.at> writes:

Hi,

> On Tue, Aug 14, 2007 at 11:54:04PM +0200, Marco Gerards wrote:
> [...]
>> > could you check if svq3_get_ue_golomb() does the same as 
>> > dirac_get_ue_golomb()?
>> > if no please check if its maybe just that svq3 code currently doenst support
>> > more than 32bit codewords
>> > if they do the same, a benchmark (with actual video data) of both would be
>> > interresting
>> 
>> This code is quite hard to change.  If I make it more generic, I am
>> afraid I will slow it down and make the benchmark useless.
>> 
>> Can you propose a way to fix this without slowing it down too much?  I
>> can benchmark it in that case.
>
> hmm, i think just putting your code into the else of svq3_get_ue_golomb()
> should do, the current code for the else{} path doesnt look very efficient
> anyway

Ok, I did so now.

Unfortunately this was not possible for svq3_get_se_golomb().  It
seems they deal differently with signed ints.  For example 0011xxxx
would be -1 for Dirac.  When I look this up in the table for svq3,
this is 1.  I did change this code after I sent in the last patch.

> [...]
>> >> +        LAST_SKIP_BITS(re, gb, FFMIN(ff_interleaved_dirac_golomb_vlc_len[buf], 8));
>> >> +
>> >> +        ret <<= (ff_interleaved_dirac_golomb_vlc_len[buf] - 1) >> 1;
>> >> +        ret |= ff_interleaved_dirac_golomb_vlc_code[buf];
>> >> +        if (ff_interleaved_dirac_golomb_vlc_len[buf] != 9)
>> >> +            break;
>> >
>> > this can be done more efficiently (see svq3_get_ue_golomb())
>> > also small values should be much more common than large ones so the
>> > loop would most of the time do just 1 iteration ...
>> 
>> Do you mean I should make a special condition for the case the loop
>> should not be entered and just return the value?  
>
> yes

I did this.

>> And in case more
>> than 8 bits should be read use the code I have now?
>
> yes
> which makes the code identical to the svq3 code with the suggested change
> above

Yes, so I removed my function and made the change in the svq3 code.

>> Or is there something with the code above?  In that case I do not get
>> it.  This works very different from svq3 so I will not be able to do
>> the same.
>
> indeed it seems i need some sleep ...
> one obvious optimization though is:
>
> if (ff_interleaved_dirac_golomb_vlc_len[buf] != 9){
>     ret <<= (ff_interleaved_dirac_golomb_vlc_len[buf] - 1) >> 1;
>     ret |= ff_interleaved_dirac_golomb_vlc_code[buf];
>     break;
> }
> ret= (ret<<4) | ff_interleaved_dirac_golomb_vlc_code[buf];

Great suggestion, I made this change.

Hopefully the new patch is ok.  I stopped using SHOW_UBITS, because it
would be called after GET_CACHE in that case.  So now I just shift the
buf and update the cache at the end of the while loop.  Would that be
ok?

--
Marco

-------------- next part --------------
A non-text attachment was scrubbed...
Name: golomb.diff
Type: text/x-diff
Size: 4132 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070815/c79025a6/attachment.diff>