[FFmpeg-devel] [PATCH 3/7] avcodec/golomb, h264*: Fix get_ue_golomb_31()

[Andreas Rheinhardt]

Michael Niedermayer:
> On Tue, Jul 14, 2020 at 10:43:51PM +0200, Andreas Rheinhardt wrote:
>> Michael Niedermayer:
>>> On Tue, Jul 14, 2020 at 05:34:50PM +0200, Andreas Rheinhardt wrote:
>>>> get_ue_golomb_31() uses a LUT of 512 entries; therefore it can be used
>>>> to parse exp-golomb codes of length <= 9, i.e. those codes with at most
>>>> four leading bits that have five effective bits; this implies a range of
>>>> 0..30 and not 31. In particular, this function must not be used to parse
>>>> e.g. the H.264 SPS id.
>>>
>>> hmm, are you sure ?
>>>
>>
>> Yes.
>>
>>> 1           0
>>> 01X         1-2
>>> 001XX       3-6
>>> 0001XXX     7-14
>>> 00001XXXX   15-30
>>> 000001..... 31
>>>
>>> we need to read 9 bits for this, we do not need to read the bits marked with
>>> a "." because the code is already determined at this point.
>>>
>> The code is only determined at the point if one already presumes that it
>> can't be anything >31. 
> 
> yes, that is the idea of get_ue_golomb_31() its only used when the biggest
> valid code is 31.
> 
But then we still have to rely on the code being valid as we have no way
to distinguish 31 from 32-34. Is this considered acceptable for the
speed gain?

> 
>> Without this assumption, one needs to look at all
>> the five "." in order to distinguish it from 32..62. By looking at only
>> 9 digits one can not rule out 32-34.
>> And if you take a look at ff_ue_golomb_vlc_code, you will see that it
>> does not even contain 31 at all. It returns the values 0-30 for the
>> codes with length <= 9 and returns 32 for the rest.
> 
> const uint8_t ff_ue_golomb_vlc_code[512]={
> 32,32,32,32,32,32,32,32,31,32,32,32,32,32,32,32,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,
>                         ^^

Indeed, how could I overlook this. Must have been blind. Sorry for that.

- Andreas