[FFmpeg-devel] VP8 decoder optimization status

[Måns Rullgård]

Stefan Gehrer <stefan.gehrer at gmx.de> writes:

> On 06/30/2010 10:54 PM, Jason Garrett-Glaser wrote:
>> 2010/6/30 M?ns Rullg?rd<mans at mansr.com>:
>>> Jason Garrett-Glaser<darkshikari at gmail.com>  writes:
>>>
>>>> On Wed, Jun 30, 2010 at 1:19 PM, Stefan Gehrer<stefan.gehrer at gmx.de>  wrote:
>>>>> On 06/30/2010 10:15 PM, Stefan Gehrer wrote:
>>>>>>
>>>>>> On 06/30/2010 08:54 PM, Jason Garrett-Glaser wrote:
>>>>>>>
>>>>>>> On Wed, Jun 30, 2010 at 8:55 AM, Stefan Gehrer<stefan.gehrer at gmx.de>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On 06/29/2010 04:09 AM, Jason Garrett-Glaser wrote:
>>>>>>>>>
>>>>>>>>> Here's a rough guide to what's done and what needs to be done before
>>>>>>>>> ffmpeg's VP8 decoder is as fast as a politician running away from an
>>>>>>>>> ethics committee.
>>>>>>>>
>>>>>>>> [...]
>>>>>>>>
>>>>>>>>> C:
>>>>>>>>>
>>>>>>>>> Fully convert vp5/6/7/8 arithmetic coder to bytestream: eliminate the
>>>>>>>>> looped renormalization.
>>>>>>>>
>>>>>>>> Like attached?
>>>>>>>
>>>>>>> We should try to reuse the h264 table if possible, IMO.
>>>>>>
>>>>>> If we are talking about the same table (ff_h264_norm_shift*),
>>>>>> it can not be used as is,
>>>>>> I think these are the options:
>>>>>>
>>>>>> 1. shift = 7 - av_log2_16bit(c->high);
>>>>>>
>>>>>> 2. shift = 7 - ff_log2_tab[c->high];
>>>>>>
>>>>>> 3. shift = ff_h264_norm_shift_old[c->high] + !!c->high;
>>>>>
>>>>> 3. shift = ff_h264_norm_shift_old[c->high] + 1;
>>>>>
>>>>> as c->high should never become zero.
>>>>
>>>> This sounds like the best option: 1) is 3 ops on x86 minimum, as is
>>>> 2).  3) is at most two ops.
>>>
>>> But a clz is often faster than a memory load.  Also don't forget you
>>> have to load the base address of the table from somewhere on
>>> everything but x86 (and there too with PIC).
>>
>> Then we should do an ifdef of some sort to get optimal behavior in all
>> situations.
>
> New patch, I realised that ff_h264_norm_shift_old is actually not in
> use in H.264 but only ff_h264_norm_shift.
> And I added a debatable #if
> Stefan
>
> +#if HAVE_FAST_CLZ
> +    shift = 7 - av_log2(c->high);
> +#else
> +    shift = ff_h264_norm_shift[c->high] - 1;
> +#endif

Remove this #if for now.  We'll make it even better later.

-- 
M?ns Rullg?rd
mans at mansr.com