Re: [Dvd-devel] Forking of libdvdread

Wed May 07 2003, Michael Roitzsch wrote:
> 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.
> 
Glad that I'm not alone on this.


> > 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.
> 
I simply said that _I_ would not be making those changes.  I have
no problem with patches making libdvdread more portable, though 
this would again break the ABI.

More specifically to 'getbits()', I feel that that should not be
necessary, the IFO and NAV structures are almost exlucivly byte /
short / word length data and at fixed offsets from some point that can
be computed.  So I'd think it would be better to make it byte based,
and only in those few cases where there are bit based fileds handle
those with a bits based macro/function.  Though this is just details.


> > > 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.
> 
Oh well.. I still feel that mingwin could be used instead
(if that isn't broken too).


> > > 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.
> 
Sure, though from what I've seen in the web cvs, there have been lots 
of (IMHO) pointless and/or wrong changes to the files which will make 
merging harder (some of the win32 changes).  Perhaps the types/reader
files are in better shape, I've yet to look at those.

-- 
Håkan Hjort