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

[Reimar Döffinger]

On Thu, Sep 30, 2010 at 09:49:53PM +0100, M?ns Rullg?rd wrote:
> 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.

Yes, I meant exactly those functions I templated.
Another option would be to split the parsing completely out (into
separate files), and store the parsed values as uint8_t in the context.
That would be 76 bytes in the context and the same number of "useless"
stores and loads.
The advantage would be that this is IIRC also the format the test
vectors use.

> > 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.

I think I would try to find extra time if someone has suggestion
to do it cleanly or at least put it on the way.