Re: [Dvd-devel] Forking of libdvdread

Hi Håkan,

James seems to be away, so I will tell you my opinion, since I will also 
be away until Monday.

> I'm sad to have to hear about this.

I did not like the idea either.

> Why do you feel it's necessary to fork this code?
>
> From the cvs commit:
> > Add files from libdvdread.
> > This is to provide better integration with libdvdnav.
> > Better error messages reported to the application etc.
>
> What do you feel is missing?  Adding better return codes and a
> structured error message system would be a good things in general and
> not just some thing that only libdvdnav would benefit from.

Heavily agreed.

> > We will modify libdvdread files to be portable across all
> > compilers. Currently, libdvdread only behaves with gcc.
>
> It behaves with many versions of gcc and Suns Forte C compiler.
> These are the two compilers I have access to and care for.
>
> If you want to make it more portable be my guest, I'll take those
> patches. No need to create a fork for that.  I just won't do this
> work my self because it already work on all platforms and compilers
> I have tested with.

From what James explained to me:
He thinks the bitfield structures are very insecure concerning 
portability, since compilers are known to "optimize" such packed data 
and align it in some way. I agree with that.
IIRC you already had such problems with some Sun compiler and fixed some 
in a rather hacky way by changing the order of one of the structures to 
one the compiler does handle.
James thinks that a portable way would be to use a getbits() method to 
read the data from the disc and store it in the structures. I think he 
is right here. He said he discussed that with the libdvdread team 
(you?), but they denied that need.

> > libdvdread does not like Microsoft Compilers.
>
> Yes, so why do you need to use them?  There are the mingwin and
> cygwin systems for Win32 platforms.  Granted I've not tested with
> them either.

That's not the point here. MSVC is not a very good compiler, but a very 
widely spread one. libdvdread should compile with it if open-source 
DVD-playback wants to conquer the Windows platform.

> > This portability modification will change libdvdread so much,
> > that I thought it best to finally combine libdvdnav and libdvdread
> > into one lib.
>
> Why would it need to do that?
> The types in ifo_types.h, nav_types.h would be simplified but not
> necessary change names or even break source compatibly.

That's right. The headers did not change dramatically. (some not at all)

> The functions in ifo_read.c and nav_read.c would have to be updated
> to match the new types but that would practically be that.

James has already done quite some work on the getbits(). It should be 
fairly easy to extract the patches out of cvs. Maybe you can have a 
look at them and see, if there is any way this could be merged back 
into libdvdread. If that would be so, I would definitely vote for 
throwing the code off libdvdnav again.

Michael

-- 
/* Am I fucking pedantic or what? */
	2.2.16 /usr/src/linux/drivers/scsi/qlogicpti.h