[FFmpeg-devel] [RFC] mixed-endian get_bits

Måns Rullgård mans
Thu Sep 30 22:49:53 CEST 2010


Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:

> On Thu, Sep 30, 2010 at 08:40:41PM +0100, M?ns Rullg?rd wrote:
>> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
>> > this patch would, when ALT_BITSTREAM_READER is defined, provide an
>> > alternative get_bits_le that behaves as the get_bits when
>> > ALT_BITSTREAM_READER_LE is defined.
>> > This is a hack that is due to the fact the GSM 06.10 and the MS
>> > variant use different bitstream layouts.
>> > The best idea I had without bloating neither code nor binary size
>> > involes using this as in attached patch.
>> > There are a lot of other ways to do this of course (manually parsing
>> > the bitstream like other GSM decoders do certainly is not one I'd
>> > consider good though).
>> 
>> Why not simply split out the parts needing two versions and compile
>> twice with different existing bitstream readers?
>
> Well, that would be a call overhead of 9 calls per 33 decoded bytes.

I meant whatever you templated with different get_bits functions in
your patch could be moved to a separate file.  Maybe it's still too
much, I didn't read it carefully.

> Not really a big deal for this codec, and one of the many other
> possibilities I thought about.
> I mostly picked this one because it was
> 1) really quick to implement
> 2) most interesting (whether that's good or bad I leave up to you :-) ).
>
> I always very much disliked that with get_bits you had to decide on
> one bitstream format and that would be the only one you could use
> throughout the whole file.

I can't say I admire it either.  I do however think any change should
be done cleanly, not by bolting on yet another hack.

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



More information about the ffmpeg-devel mailing list