[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