[FFmpeg-devel] VP8 decoder optimization status

Stefan Gehrer stefan.gehrer
Thu Jul 1 00:06:29 CEST 2010


On 06/30/2010 11:49 PM, M?ns Rullg?rd wrote:
> 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.

Applied without the #if.




More information about the ffmpeg-devel mailing list