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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
