Re: new release status

On Sat, Jan 21, 2006 at 02:30:35AM +0100, Bj|rn Englund wrote:
> 
> About your patches:
> The asm patch will probably not go in. Nothing in libdvdread is so
> time critical to need it so I'd rather not have any asm in there.

Maybe this is worth benchmarking.  Byteswapping can happen quite often.
I don't see a bit of ASM as a problem, it's just a few lines...

> The audio/subp_control is a bit problematic. 
> At the moment you have access to the data but only as a uint16_t
> that you have to pick out the bits from yourself.
> The patch would mean breaking source compatibility.
> 
> An alternative would be to create macros to get at the bits instead,
> but maybe not as nice.
> 
> A third alt is to define just the audio/subp_control_t types in the .h file
> and cast the uint16_t to the new types when you want to use the
> bitfields.
> 
> Or make a #define before including dvdread.h with something like
> #define DVDREAD_NEW_CONTROL_INTERFACE if you want the new bitfields,
> this alternative is probably just ugly.

The comments in the source indicate that a new type was desirable, now
you have it...

> Any comments on this. Is it worth breaking source compatibility for
> just these bitfields in this release?

What about the next release? :)

> Are you sure the control/mapping field should always be decoded the
> same way so we don't have to change the bitfields later on?
> Using macros would help in that case.

No, it's not my patch.  Shall I try contacting the patch sender?

Diego