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

Mon Jul 22 2002, Olaf Beck wrote:
> Hello Folks,
> 
> Some of you might be aware I'm currently developing some DVD-Video
> copy, edit, create programs. The DVD-Video code to create DVD-Video
> images in mkisofs are now a integrated part of cdrtools as of
> version 1.11a27.
>
> Anyways I now have my eyes and hacking fingers on more elaborate
> tasks such as chapter extraction, DVD-9 split to two DVD-5,
> etc.. and I have some questions in regards to this.
> 
> Chapter extraction:
> It's not hard to figure out start cell and end cell of a
> chapter. However when I started to analyze the cell information in
> the "cell playback information table entry" I came to a halt. The
> cells start and endcells simply doesn't match.
> 
> No I don't want to just extract a certain playback sequence I simply
> want to have a chunk of data from sector Y to sector X.
> 
> Cell:   2
> Start sector: 00002387
> End   sector: 0001ecdd
> 
> Cell:   3
> Start sector: 0000273c
> End   sector: 0001f09e
> 
This is an example of two cells that have interleaved allocation
(they are ILVU's).  So not every block between 0x2387 and 0x1ecdd
belong to Cell 2, but all blocks of Cell 2 are located in that range.

> Here it's relatively easy just extract the data between sector
> 00002387 and sector 0001f09e - I'm assuming the sector is relative
> to the VTS_XX_1.VOB start sector, please correct me if I wrong.
> 
That is correct (they beeing relative to the VTS_XX_1.VOB start sector).

> The tricky part is when it looks like this:
> Cell:   1 
>         Start sector: 0036d4d7  
>         End   sector: 0036d4db  
> Cell:   2 
>         Start sector: 002db177  
>         End   sector: 002dec78  
> Cell:   3 
>         Start sector: 0036d4dc  
>         End   sector: 0036d4e0  
> 
> What should I do?  Extract 002db177  to 002dec78  and then 0036d4d7  to 
> 0036d4e0?
> 
Well these won't be played seamlessly I'd think.  To get whole PGC in
this case you'd have to get both ranges yes.

> 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.

> As for a general question in splitting a title_set, I would like to
> know if you guys and girls has some bright algos where it should be
> done. E.g. is there a easy way to detect where the second layer
> beginns.
> 
Well there is some info in one of the structs that can be gotten
from the drive.  Can't rember which one rigt now, look in SFF-8090.

> I also assume that I have to update all sector references in PCI and
> DSI packets in the title sets I split. 

Yes, it's mostly the 'current address' i.e the first word in the PCI and the
second in the DSI that will need changing.
 
> However is it also necessary to update VOB id - must I start at VOB
> ID 1 or can I simply start at VOB id 6 for example.
> 
Not sure on that point.

> Misc Notes in regards to mkisofs and DVD-Video:
> 
> In order to get DVD-Video support integrated in mkisofs I had to
> make a very cut down version of libdvdread. Joerg the maintainer of
> cdrtools simply didn't want to depend on dvdread since it is not
> portable in his view.
> 
Not much is (or perhaps better but, nothing not written by Jörg is ;-)

> 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 woould be better, in my mind,
if libdvdread was patched to _be_ portable instead (or also). 

> 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?

> Ohh, Joerg can sound a bit harsh in his portability comments - but
> he is actually quite nice to work with after the ice has metled. I
> assume that he just want to make every one regardless of OS benefit
> from improvements in mkisofs - hence he holds portability very
> dearly.
> 
Is the SPOSIX standard ready yet?

-- 
Håkan Hjort