[FFmpeg-devel] LIBMPEG2_BITSTREAM_READER vs. golomb.h

[Måns Rullgård]

Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:

> On Monday 14 July 2008, M?ns Rullg?rd wrote:
>> I just spent some time bug-hunting, only to discover that the
>> exp-golomb functions in golomb.h do not work with
>> LIBMPEG2_BITSTREAM_READER.  This is because they rely on more than the
>> promised 17 bits to be available after an UPDATE_CACHE() call.
>>
>> To avoid future mishaps, I was thinking of adding a preprocessor check
>> to golomb.h (I'm too lazy to try to make it work).  What exactly is
>> the requirement here?  The code seems to assume 32 bits are available,
>> even though ALT_BITSTREAM_READER only promises 25 bits.  Clearly,
>> those 25 bits are sufficient for actual data.  Briefly looking at the
>> H.264 spec, I can't find any mention of a maximum length for
>> exp-golomb codes.  Did I miss something, or is there really no limit?
>>
>> This is all annoying because LIBMPEG2_BITSTREAM_READER is slightly
>> faster on ARM.
>
> What about just using ALT_BITSTREAM_READER for ARMv6 and newer (cores that
> support unaligned memory accesses)?

I tried enabling HAVE_FAST_UNALIGNED, and it didn't make any
significant difference.

> It could be the fastest bitstream reader when implementing unaligned
> 32-bit bigendian load as:
>
> setend be
> ldr ...
> setend le

ldr; rev is only two instructions.

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