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

Tue Jul 23 2002, Olaf Beck wrote:
> Hello Hakan,
> 
> First thanks for all the information you gave me!
> 
Sure thing.

> On Tuesday 23 July 2002 10:25, H}kan Hjort wrote:
> [snip]
> > > DVD-9 to two DVD-5:
> > > Lets say that I just ignore all other titles sets on the DVD and I
> > > just deal with the main feature film. Merging the VTS_XX_0.IFO with
> >
> > If you just want the 'main feature film' you could just concentrate
> > on the Titel Track for that, that will mostlikely be just one singel
> > PGC in one of the VTS (Video Title Sets).  Not much difference though.
> >
> > > some plain vanilla IFO or just edit the one I have. Anyways my
> > > question is what to do when I encounter problems like the "tricky
> > > part" above. This could very well be a part of the end of the main
> > > feature referencing back to a cell in the very beginning.
> >
> > Well if you don't want to shuffle the video parts around to avoid
> > recalcutalting lots if tables and sector offsets you'll have to keep
> > all of the VTS_XX_[123456789].VOB files as they are.
> 
> Hmm easier said than done if e.g. the last cell is belonging to VTS_XX_1.VOB 
> while "the rest of the end" is belonging to VTS_XX_9.VOB. Note: I taking 
> about the cases where the main film is not fitting into one DVD-5.
> 
Well, if the cell is not an ILVU, then just 'moving it' and changing
all the offsets that point to it will be ok.  If it is an ILVU you might
eiher need to find the whole ILVU pack and move that (and in so update all
the offsets for every cell in that ILVU), or extract the one angle from
the ILVU and just move that.  The last option would remove any (if there are
to begin with) angle selection, and might need some more complicated updating
in the NAV packets.

Three cases:
a) 0x800 - 0xe00 is one, and only one continious cell
b) 0x800 - 0xe00 is part of an ILVU, 0x700 to 0xf00
c) 0x800 - 0xe00 is part of an ILVU, 0x700 to 0xf00 which is an angle block

(at least I belive this are the only three possibilities)
The 'a' case is the normal one.  The 'b' happens for example on 'The
Matrix'.  The 'c' case might be in a movie that has several
alternative versions, I've seen a few music videos like this, also I
gather that some movies have used it to have credits and other 'on
screen text' appear in different languages.

Case 'a', the cell might be referenced from several PGC's, if you 'copy'
the whole IFO remember to update them all (this really appliles to all
the cases). 
Case 'b' the different cells that are part of the 0x700-0xf00 ILVU are
normaly found in different PGC's, the Titel Track / VTS title track
for the two versions are not the same.  This just uses the Interleaved
allocation to get seamless playback of the diferent versions with out
having to encoded and stor all of it twice.
Case 'c', here the most common use of ILUV, the angle mode.  All(?) the
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). 

-snip-
> > > Hence I stole and wrote some new code in order to subsitute
> > > functions that I needed from libdvdread. I hope I haven't stepped on
> > > anyones toes doing this.
> >
> > As long as it's GPL, it's fine.  There shouldn't be much code needed
> > to get at the parts you need.  Though it would be better, in my mind,
> > if libdvdread was patched to _be_ portable instead (or also).
> 
> It sure is GPL, and yes it would be better to make libdvdread more portable. 
> Trust me if I had the time before Joergs deadline I would have. Although is 
> main argument agains libdvdread was the use of dlopen and I don't think you 
> would have sacrificed that one to please Joerg.
> 
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.

> > > Maybe a positive side effect of this is that the bsswap.h macros now
> > > have a new more portable implementation. It can be worth taking a
> > > look at it.
> >
> > Ok, can you send us this?
> 
> The easiest is probably to download it from 
> ftp://ftp.fokus.gmd.de/pub/unix/cdrecord/alpha/cdrtools-1.11a27.tar.gz 
> and take a look at bswap.h in the mkisofs directory.
> 
Thanks for the link.
 
> 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.

> (Hmm, yes been taking about patches. They will come sorry for the delay
>  simply over worked doing the DVD-Video support and a DVD backup program.)
> 
No worries, haven't had that much spare time myself.

> > Is the SPOSIX standard ready yet?
> I actually don't know if it is. 
> 
Just a small joke, Jörg seems to name everything s-something, smake star..
and always go on about how things are not POSIX...

-- 
Håkan Hjort