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

[Michael Niedermayer]

On Tue, Jul 14, 2020 at 11:14:19PM +0200, Andreas Rheinhardt wrote:
> 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?

Is it a problem when 32-34 (which are invalid) are mapped to 31 ?

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200715/06d9d77f/attachment.sig>