Re: DVD authoring,copy,edit questions + misc :)

Wed Jul 24 2002, Olaf Beck wrote:
> Hello Hakan,
> 
> [snip]
> > cells that are part of the ILVU are in the cell playpack table of the
> > PGC.  The setting of the Angle register determinesd which one 
> > is played.
> > If permitted the user can switch angle during the playback too.
> > 
> > Easies is probably to try to find out if the cell you want to 
> > relocate is part of an ILVU and if so relocate the whole ILVU.
> > (i.e all offsets that fall in the range 0x700-0xf00 in the example
> > above, one also has the VOB / Cell id's to help as you noticed).
> 
> Thanks for all the info it definitely helped me a lot.
> May I ask if there is any easy way to get a table of
> all ILVU's in a title set.  
> 
Not that I know of.

> > Well that is only used if available, and only needed from VOB files.
> > (Or to read things of a device that is a dvd drive with a css
> > protected disc, since it needs to be authenticated first) Just using
> > an external library though is trouble of sorts.
> 
> Well he didn't want to use the call at all - i.e
> remove it from dvdread. He also didn't like the GCC
> deps in dvdread etc.. the list was long. I kind of
> realized that it would be very difficult to please
> Joerg without hacking dvdread to pieces.
> 
Well well, the dlopen is there because we want to leave the choice of
using libdvdcss (and with that the CSS code) to the users.
Still enabling a binarie distibution.   It's not pretty and I'd like
to remove it but... 

It's dependent on GCC in that it assumes stuff about how the structs
will be layedout in memmory.  This could be fixed by solwing it down,
ie. adding code to copy it by pices from a in buffer to the actual c
structurs.  This would indeed make it much more portable.  Many of
the structurs are alredy touched today for little endian systems becuase
the IFO file format contains all data in big endian format.

If would though mean _a lot_ of new code on the form 

a->foo = NEXT_16(buffer);
a->bar = NEXT_8(buffer);
a->baz = NEXT_32(buffer);

that would be both tedious and error prone to write.

Except for one pair of 24bit (really 2,10,2,10) bitfields that 
gccc indeed packs into 6bytes but Sun cc (Forte) packs as 8 bytes.
It does work for other compilers that support the #pragma pack()
directiv.

> [snip]
> 
> 
> > > It can be worth noticing that Joerg has made macros for the  different
> > > Uint16 etc. types used my dvdread. According to him his way is more
> > > portable. This was one of those things that I thought be a  good thing to
> > > use in dvdread if you could take a look at it I could  actually do some
> > > patches for libdvdread.
> > 
> > Like not using uint16_t?  or just defining then instead of using
> > inttypes.h?  It's a standard type, or will be.  Better to use them and
> > supply a definition if it's missing that to make up yet another name
> > for it, IMHO.
> 
> Yes, I wouldn't like to make a new type but it would
> as you said be a good thing to redefine or define the
> type if it was either not available or buggy.
> 
I've borrowed an autoconf macro written by Michel Lespinasse (found in
libmpeg2) that generates a stub for inttypes.h if it's missing on
the system.

If the definitions in the system headers are wrong I'm _not_ going along
with that as a reason to not use then (did that sentens make sense?).

All software shoulf not be written as some monolitic selfcontaind pice
of code that does not even rely on the OS / libc heards for types and
functions.

-- 
Håkan Hjort