Technology and Trends
 Linux Video & DVD Project Mailing List Archives
  
From hetz-home@cobol2java.com Fri, 01 Oct 1999 15:48:50 +0200
Date: Fri, 01 Oct 1999 15:48:50 +0200
From: Hetz Ben Hamo hetz-home@cobol2java.com
Subject: [Livid-dev] Time to help others?

Hi,

Recently (yesterday actully) I heard here about this guy who reversed
engineering the DXR2 board and the driver and he wants to write a Linux
driver..

That's good, BUT

How about this guy would just first release some sort of "documentation"
of how he reversed engineering the driver, and ofcourse if he wants to
help - the actual data about the card/registers/whatever...

We're Linux community here if you don't mind - SHARE is the KEY word
here. It's nice to see someone is going to write a driver, but what if
there is someone else who got exactly the same card, have also the
knowledge of programming and got MUCH more time and patience? some
collaboration could get us a good Linux support.

Also, isn't it time to start connecting the puzzle of DVD drivers/specs?
How about some sort of "skeleton" which will be a sort of "DVD player"
and for each card you'll have to add some files which are those
"drivers", and we'll have a 1 nice program which supports SEVERAL cards,
instead of 5-10 programs for DVD playback - but each one is only for 1
card..

Later ofcourse, someone can write some sort of Front End for KDE/GNOME
with all the features needed..

I think this "skeleton" should be start written NOW with the SOFTWARE
player that we have (nist and ac3dec). I know it's very slow - but hey,
it's a start. People really like to see SOMETHING is there and they'll
try to improve it.

What do you think?

-- 
Hetz Ben Hamo - Sys. Admin. - Intercomp
hetz@cobol2java.com
---------------------------------------
Redmond, you have a problem..

From holzt@multimediahaus.de Fri, 1 Oct 1999 16:11:54 +0200
Date: Fri, 1 Oct 1999 16:11:54 +0200
From: Michael Holzt holzt@multimediahaus.de
Subject: [Livid-dev] Time to help others?

On Fri, Oct 01, 1999 at 03:48:50PM +0200, Hetz Ben Hamo wrote:
> How about this guy would just first release some sort of "documentation"
> of how he reversed engineering the driver, and ofcourse if he wants to
> help - the actual data about the card/registers/whatever...
[...]
> some collaboration could get us a good Linux support.

Maybe, but don't forget the fact that the reverse engineering done was
likely against the law. I can't figure out how collabaration between
people who probably want to stay anonymous for legal reasons should work.


-- 
Michael Holzt

From pvolcko@concentric.net Fri, 1 Oct 1999 10:14:13 -0400 (EDT)
Date: Fri, 1 Oct 1999 10:14:13 -0400 (EDT)
From: pvolcko@concentric.net pvolcko@concentric.net
Subject: [Livid-dev] Time to help others?

> Recently (yesterday actully) I heard here about this guy who reversed
> engineering the DXR2 board and the driver and he wants to write a Linux
> driver..
> 
> That's good, BUT
> 
> How about this guy would just first release some sort of "documentation"
> of how he reversed engineering the driver, and ofcourse if he wants to
> help - the actual data about the card/registers/whatever...
> 
> We're Linux community here if you don't mind - SHARE is the KEY word
> here. It's nice to see someone is going to write a driver, but what if
> there is someone else who got exactly the same card, have also the
> knowledge of programming and got MUCH more time and patience? some
> collaboration could get us a good Linux support.
> 
> Also, isn't it time to start connecting the puzzle of DVD drivers/specs?
> How about some sort of "skeleton" which will be a sort of "DVD player"
> and for each card you'll have to add some files which are those
> "drivers", and we'll have a 1 nice program which supports SEVERAL cards,
> instead of 5-10 programs for DVD playback - but each one is only for 1
> card..
> 
> Later ofcourse, someone can write some sort of Front End for KDE/GNOME
> with all the features needed..
> 
> I think this "skeleton" should be start written NOW with the SOFTWARE
> player that we have (nist and ac3dec). I know it's very slow - but hey,
> it's a start. People really like to see SOMETHING is there and they'll
> try to improve it.
> 
> What do you think?

I think you are dead on right with this message. I was going to post
something like it yesterday when I saw the message about the drivers being
RE'd, but was side tracked and forgot about it. 

At any rate, there is a severe lack of communication in this entire effort.
There are some people working on CSS and every once in a while there is an
update to the software, but almost never any discussion about the development
on this list. Same does for the people working on figuring out the IFO file
structure. I've seen maybe two or three messages on this list about it but I
have never seen any URL or anything published for where to get it. This part
is really important if there is going to be even a skeleton of a dvd player
written since without it, there really is no player (just a MPEG-2 and AC-3
decoder thrown together) which we have already. If we want to do anything
with encrypted DVDs then the people doing the CSS decryption development need
to get a bit more vocal.

I've gotten the impression that most of these small projects (expect for
MPEG-2 and AC-3) have been stagnate for a month or so now. While I can't
really complain since I haven't offered a single bit of code to any project, I
think it's alright to point out this problem. If I weren't involved with a
project already I'd be helping out with projects under the Livid umbrella, but
my time is already stretched pretty thin. 

This kind of brings up a last point, all of these "mini-projects" are
operating under the umbrella of Livid, right? So where is the Livid project
management? The web site and CVS have been in chaos for a long time now with
no word from anyone trying to fix it. I can only assume that there isn't
any one (or group) that is trying to pull together all of these mini-projects
and create the much sought after dvd player application. Isn't this what the
livid management should be doing? Isn't that what this list is all about?

Paul Volcko
LSDVD

From hetz-home@cobol2java.com Fri, 01 Oct 1999 16:16:21 +0200
Date: Fri, 01 Oct 1999 16:16:21 +0200
From: Hetz Ben Hamo hetz-home@cobol2java.com
Subject: [Livid-dev] Time to help others?

May I remind you that IF this person have NOT using ANY Creative
documents (or the chip maker's document) then THIS IS LEGAL? Ask AMD for
example.

Hetz


Michael Holzt wrote:
> 
> On Fri, Oct 01, 1999 at 03:48:50PM +0200, Hetz Ben Hamo wrote:
> > How about this guy would just first release some sort of "documentation"
> > of how he reversed engineering the driver, and ofcourse if he wants to
> > help - the actual data about the card/registers/whatever...
> [...]
> > some collaboration could get us a good Linux support.
> 
> Maybe, but don't forget the fact that the reverse engineering done was
> likely against the law. I can't figure out how collabaration between
> people who probably want to stay anonymous for legal reasons should work.
> 
> --
> Michael Holzt

-- 
Hetz Ben Hamo - Sys. Admin. - Intercomp
hetz@cobol2java.com
---------------------------------------
Redmond, you have a problem.

From holzt@multimediahaus.de Fri, 1 Oct 1999 16:20:13 +0200
Date: Fri, 1 Oct 1999 16:20:13 +0200
From: Michael Holzt holzt@multimediahaus.de
Subject: [Livid-dev] Time to help others?

On Fri, Oct 01, 1999 at 04:16:21PM +0200, Hetz Ben Hamo wrote:
> May I remind you that IF this person have NOT using ANY Creative
> documents (or the chip maker's document) then THIS IS LEGAL? Ask AMD for
> example.

Crap. This is illegal in most countries including the complete European
Union. You are under some circumstances allowed to reverse-engineer software
for compability issues, but reverse-engineering a complete driver can hardly
be explained with compatibility issues.

This whole threat was already discussed some time ago, please check the
list archives.

Excuse my strong words, but if you don't know what you are talking about,
please don't post.

-- 
Michael Holzt

From pvolcko@concentric.net Fri, 1 Oct 1999 10:56:00 -0400 (EDT)
Date: Fri, 1 Oct 1999 10:56:00 -0400 (EDT)
From: pvolcko@concentric.net pvolcko@concentric.net
Subject: [Livid-dev] Time to help others?

> > May I remind you that IF this person have NOT using ANY Creative
> > documents (or the chip maker's document) then THIS IS LEGAL? Ask AMD for
> > example.
> 
> Crap. This is illegal in most countries including the complete European
> Union. You are under some circumstances allowed to reverse-engineer software
> for compability issues, but reverse-engineering a complete driver can hardly
> be explained with compatibility issues.
> 
> This whole threat was already discussed some time ago, please check the
> list archives.
> 
> Excuse my strong words, but if you don't know what you are talking about,
> please don't post.

The RE laws of various countries seem to be a large grey area. Most software
and I would suspect even hardware vendors seem to use contract law as a way to
get around the REing grey area. Either way it seems to me that there is some
need to come up with a way for people working "in secret" to be able to at
least communicate to the list what is being worked on currently, whats been
done already, and what still needs doing. Collaberation is the next step
beyond that. It would seem to me that encryption coupled with an anonymous
remailer would be the way to go here. First, whoever is working on something
that requires identity to be hidden should create a GnuPG/PGP keypair and mail
the public key to the list via encrypted anonymous remailer. Then that
person can send email to the list with signed code snippets or whatever of
what they are doing. In this way the person's identity is concealed for as
long as they want, the anonymous person can claim bragging rights (if wanted)
since the material submitted is signed, and we a development community
participants will know what is going on and can even collaberate (nothing
stopping anyone else from using the same encrypted anonymous remailer method)
using the list as the collaberation point (assuming that the people working in
secret also have access to this list and it's postings).

It's a hassle and I'm not sure if there are even encrypted anonymous remailers
still around anymore (been a few years since I played with them), but it would
get the job done and make everyone happy I think.

Paul Volcko
LSDVD

From derek@spider.com Fri, 1 Oct 1999 17:31:14 +0100
Date: Fri, 1 Oct 1999 17:31:14 +0100
From: Derek Fawcus derek@spider.com
Subject: [Livid-dev] Time to help others?

On Fri, Oct 01, 1999 at 10:14:13AM -0400, pvolcko@concentric.net wrote:
> 
> There are some people working on CSS and every once in a while there is an
> update to the software, but almost never any discussion about the development
> on this list.

Well I've not done any changes to the CSS authentication code for a while.
Is the CVS archive usable again. If so I'll check back in the version that
was there when it vanished. I've still to try this myself under 2.2.12,
but as far as I'm concerned this is a completed task (modulo any bugs people
find).

As to CSS decryption. I've had a couple of people send me what they claim
is the algorith for this (in C/asm). I've yet to try this out. I may have
a crack at this at the weekend. See below.

> Same does for the people working on figuring out the IFO file structure.

I've actually been playing at this lately. I know there was someone who
posted an initial IFO dump program. There was also someone who posted a
VOB dumper who said he had an IFO dumper that he'd try to find. However
I've not seen anything subsequently on the list, and wonder if maybe he
hasn't found it or can't post it (maybe he had access to the specs?).

> If we want to do anything with encrypted DVDs then the people doing the
> CSS decryption development need to get a bit more vocal.

My reason for not getting very far with this at the moment is due to a
unknown under Linux. I've need to do some more investigation. OK - here's
the problem:

To get the keys for decryption one has to use the CSS authentication
algorithm with the LBA of the file you want the key for (the files are
stored contiguously). (I don't know if the key is constant for a title
or may change within a title - but that's not to important).

Now I think the kernel already has support for this - there is an ioctl
(FIBMAP) which returns the output of the kernel bmap() function. As I
understand it this should give the LBA for a given offset in a file. I
think it takes the file relative block number and returns the device
LBA. But my test program doesn't work at the moment - it gives inconsistent
result, probably a silly bug. Once that goes I'll use if to allow me
to extract the keys, and thus decrypt the files.

I think I should use:

long block;
ioctl(fd, FIBMAP, &block);

As I stated in an earlier post, my only concern with posting this info
just now is that it _may_ damage the DVD market. However given that the
cat is out of the bag in the form of a DVD ripping program, I guess it
doesn't really matter at the moment.

As a test I was hoping to be able to simply write a filter program that
would send the decrypted output to stdout then do:

dvd-decrypt /cd/video_ts/vts_01_1.vob | NIST-player -vob -f -

But the player doesn't seem to like taking stdin as it's vob source, and
I can't be bothered to figure out the C++, so has anyone got a quick patch?

If I get this going over the weekend, I'll probably put the code up for
consumption on Monday.

My personal opinion is that the CSS decryption is less important at the
moment than the IFO/VOB file data interpretation. But then I do have a
unencrypted DVD which I can use for testing. I don't know if others have
the same luxury.

DF
-- 
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034

From hetz-home@cobol2java.com Sat, 02 Oct 1999 02:53:45 +0200
Date: Sat, 02 Oct 1999 02:53:45 +0200
From: Hetz Ben Hamo hetz-home@cobol2java.com
Subject: [Livid-dev] wrong

Hi,

You wrote:

Crap. This is illegal in most countries including the complete European
Union. You are under some circumstances allowed to reverse-engineer
software
for compability issues, but reverse-engineering a complete driver can
hardly
be explained with compatibility issues.

This whole threat was already discussed some time ago, please check the
list archives.

Excuse my strong words, but if you don't know what you are talking
about,
please don't post.

And here is my Answer: STOP USING Linux... Now I'll explain :)

Maybe you didn't know - but OVER HALF of Linux drivers are ACTUALLY A
REVERSE ENGINEERING (look at some BTTV drivers, ZIP driver, USB drivers,
some Networks drivers, Joysticks etc).. So if those companies where
suing those driver writers - then Linux wouldn't even work with some
PC's (not mentioning Apple, Amiga, Sparc etc..)

Now lets leave for a moment the law world and look at the real world...

Why companies do not want to give documents and if they give they want u
to sign NDA? because the last thing they want is to prevent someone from
making clone cards from their product - or worse - using their products
as a base to their competitor better products.

In a hardware DVD decoding - we don't need to do that. I'm sure that if
someone is cracking his DVD decoder card in order to build a driver for
Linux or any other OS WITHOUT touching the Microcode - then they won't
sue (but as soon as the driver is finished - their PR department will
add "supported by Linux" like some companies did. If you publish their
microcode then they'll sue you for you last penny.

But we don't need to use the microcode. After all - we program some
memory addresses/registers, and send the command to the controller which
does the job. We don't need to fiddle with the MPEG2 decoding cause it's
all been taken care of by the card - and also the AC3 decoding (Software
DVD is totally another issue).

At worst if we need to put the microcode in the source code, we could do
like the GLX dev. people did with Matrox - a big INCLUDE (0x0h, 0x20,
etc) at the main file (sorry for errors - me not programming), which
DOES NOT reveal the actual disassembly of Microcode..

So I say we GO for it and start doing this. People have done this before
(as I said - look at the mentioned drivers and see for yourself if they
ever been sued).

Thanks
-- 
Hetz Ben Hamo - Sys. Admin. - Intercomp
hetz@cobol2java.com
---------------------------------------
Redmond, you have a problem..

From eric@brouhaha.com 2 Oct 1999 02:15:07 -0000
Date: 2 Oct 1999 02:15:07 -0000
From: Eric Smith eric@brouhaha.com
Subject: [Livid-dev] Time to help others?

On Fri, Oct 01, 1999 at 04:16:21PM +0200, Hetz Ben Hamo wrote:
> May I remind you that IF this person have NOT using ANY Creative
> documents (or the chip maker's document) then THIS IS LEGAL? Ask AMD for
> example.

Michael Holzt <holzt@multimediahaus.de> wrote:
> Crap. This is illegal in most countries including the complete European
> Union. You are under some circumstances allowed to reverse-engineer software
> for compability issues, but reverse-engineering a complete driver can hardly
> be explained with compatibility issues.
> 
> This whole threat was already discussed some time ago, please check the
> list archives.

In the US, reverse-engineering in general is legal, but recently (in
the Digital Millenium Copyright Act) reverse-engineering of copy protection
schemes became illegal except for compatability purposes.

IANAL, but IMNSHO if getting DVDs to work on Linux doesn't involve
compatability issues, I don't know what does.

In the US, AFAIK there is *no* legal precedent yet with regard to this
new law. However, the appeals court in Sega vs. Accolade (before the
DMCA was passed) ruled that Accolade *could* reverse-engineer the copy
protection system of the Sega Genesis, and use the information thereby
gained in order to produce their own cartridges for that system. There
were several other interesting points to that ruling that I don't want
to bore everyone here with, but it makes very interesting reading.

The specific issue WRT the CSS code is that the x86 code was apparently
simply ripped out of a working commercial implementation (which was
presumably copyrighted), and translated literally into C code. There
are definitely problems with this approach, which probably does not
legally qualify as reverse-engineering. But that doesn't have any
bearing on whether proper reverse-engineering is legal.

> Excuse my strong words, but if you don't know what you are talking about,
> please don't post.

Unless you are a lawyer AND can cite legal precedent that clearly
proves Mr. Hamo's statement (which actually, if you look at it, is a
question) false, I think you've gone a bit overboard.

It could be argued that legal issues should perhaps be discussed in
a different forum; then again, they do seem quite relevant here. But
I don't think that there's any need here to accuse anyone of not
knowing what they're talking about, especially when they're asking
questions.

Cheers,
Eric

From derek@spider.com Sat, 2 Oct 1999 19:04:01 +0100
Date: Sat, 2 Oct 1999 19:04:01 +0100
From: Derek Fawcus derek@spider.com
Subject: [Livid-dev] Time to help others?

On Sat, Oct 02, 1999 at 02:15:07AM -0000, Eric Smith wrote:
> 
> The specific issue WRT the CSS code is that the x86 code was apparently
> simply ripped out of a working commercial implementation (which was
> presumably copyrighted),

Well I guess it might have been, but I don't _know_ that.

> and translated literally into C code.

Speaking as the person who wrote the C version of the css authentication
code, this is not correct. I worked to understand the algorithm underlying
the x86 code, and from there wrote a new implementation of the same
algorithm.
It is not a literal translation of x86 assembler to C. This should be
obvious from the fact that there are comments explaining what is going on.
Also the x86 version did some stupid (inefficient) things, the C version
is somewhat more optimal - i.e. generating data in a format ready for use
instead of constantly having to bit reverse some values.

DF
-- 
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034

From derek@spider.com Sat, 2 Oct 1999 19:18:26 +0100
Date: Sat, 2 Oct 1999 19:18:26 +0100
From: Derek Fawcus derek@spider.com
Subject: [Livid-dev] Time to help others?

On Fri, Oct 01, 1999 at 05:31:14PM +0100, Derek Fawcus wrote:
> 
> As to CSS decryption. I've had a couple of people send me what they claim
> is the algorith for this (in C/asm). I've yet to try this out. I may have
> a crack at this at the weekend. See below.

Well it works. I can now decrypt stuff.

DF
-- 
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034

From dent@cosy.sbg.ac.at Sun, 3 Oct 1999 16:49:37 +0200 (CEST)
Date: Sun, 3 Oct 1999 16:49:37 +0200 (CEST)
From: Thomas 'Dent' Mirlacher dent@cosy.sbg.ac.at
Subject: [Livid-dev] Time to help others?

--snip/snip

> Same does for the people working on figuring out the IFO file
> structure.
> I've seen maybe two or three messages on this list about it but I
> have never seen any URL or anything published for where to get it.

ok guys. you're right. the code can just display things right now, and there's
no part there allowing to really USE them but i'll drop it onto my homepage
and let you know by tomorrow.

> This part
> is really important if there is going to be even a skeleton of a dvd player
> written since without it, there really is no player (just a MPEG-2 and AC-3
> decoder thrown together) which we have already.

the IFO stuff is on the way getting close for beeing used by the decoder.

> If we want to do anything
> with encrypted DVDs then the people doing the CSS decryption development need
> to get a bit more vocal.

right - and in addition to the efforts hacking the things together we HAVE to
make a clean design, which allows us to build and combine things as they have
been indeneded to be combined.

> I've gotten the impression that most of these small projects (expect for
> MPEG-2 and AC-3) have been stagnate for a month or so now. While I can't
> really complain since I haven't offered a single bit of code to any project, I
> think it's alright to point out this problem.

IMHO most of the projects are going on, there has been just an empty-ness
within this mailinglist.

> If I weren't involved with a
> project already I'd be helping out with projects under the Livid umbrella, but
> my time is already stretched pretty thin. 

paul, i know you're working hard - but you CAN help (i think i remember you
mentioning some kind of API-design, you could contribute that? or just drop
in some ideas, cause we NEED an API right NOW)

> This kind of brings up a last point, all of these "mini-projects" are
> operating under the umbrella of Livid, right? So where is the Livid project
> management?

hmm, sorry for having to say that, but i've never seen one.

> The web site and CVS have been in chaos for a long time now with
> no word from anyone trying to fix it. I can only assume that there isn't
> any one (or group) that is trying to pull together all of these mini-projects
> and create the much sought after dvd player application. Isn't this what the
> livid management should be doing? Isn't that what this list is all about?

RIGHT. - so who has enough insight in all this projects and who is able
to manage all of this, who has got enough time?

++dent
-- 
Linux is no REVOLUTION - it's EVOLUTION at operating system level ;)

From dent@cosy.sbg.ac.at Sun, 3 Oct 1999 16:53:40 +0200 (CEST)
Date: Sun, 3 Oct 1999 16:53:40 +0200 (CEST)
From: Thomas 'Dent' Mirlacher dent@cosy.sbg.ac.at
Subject: [Livid-dev] Time to help others?

--snip/snip

> My personal opinion is that the CSS decryption is less important at the
> moment than the IFO/VOB file data interpretation. But then I do have a
> unencrypted DVD which I can use for testing. I don't know if others have
> the same luxury.

one important patch which is needed in th VOB player is beeing able to 
play specified blocks of data (for menues, program chains ...), which is 
in development according to joachim.

cheers

++dent

-- 
Linux is no REVOLUTION - it's EVOLUTION at operating system level ;)

From kju@flummi.de Sun, 3 Oct 1999 16:22:17 +0200
Date: Sun, 3 Oct 1999 16:22:17 +0200
From: Michael Holzt kju@flummi.de
Subject: Modularized player system (was: Re: [Livid-dev] Time to help others?)

On Sun, Oct 03, 1999 at 04:53:40PM +0200, Thomas 'Dent' Mirlacher wrote:
> one important patch which is needed in th VOB player is beeing able to 
> play specified blocks of data (for menues, program chains ...), which is 
> in development according to joachim.

Sounds good. How about adding some type of GPL'd navigation control
language? If we cannot decode the .IFO-Files yet, we may use a
own system for describing the navigation. Volunteers may build 
navigation control files for specific DVDs and made them available
in the Internet. So we can just emulate the navigation of the original
DVD...

I suggest we should try to develop and fully modularized playing
system like the Media player done in Windows. Microsoft is often
technically bad but their module system for the media player is
very good. We should do this too, but a bit deeper modularized.
I think a player could use:

- a datareading module. Could decode CSS and read the data.

- a demuxing module. This module should decode the file/data
and parse the different stream. Their should be some interface
over which the module can report what type of streams
(eg. video, audio, subtitle etc.) to the higher levels

- a audio-decoding module
- a video-decoding module
- a navigation-control module

and 

- a whole-system module. This module should know about playing
types (as 'MPEG stream', 'DVD' etc.). For example a DVD playing
module must be able to understand the filesystem of the DVD
and map accesses to the right VTS_* file etc.

From pvolcko@concentric.net Sun, 3 Oct 1999 11:10:24 -0400 (EDT)
Date: Sun, 3 Oct 1999 11:10:24 -0400 (EDT)
From: pvolcko@concentric.net pvolcko@concentric.net
Subject: [Livid-dev] Time to help others?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> > If I weren't involved with a
> > project already I'd be helping out with projects under the Livid umbrella, but
> > my time is already stretched pretty thin. 
> 
> paul, i know you're working hard - but you CAN help (i think i remember you
> mentioning some kind of API-design, you could contribute that? or just drop
> in some ideas, cause we NEED an API right NOW)

Well I just read a message from Mr. Holtz with a highly modularized player
design. That is essentially the idea I've been pushing the last three
months. He added on interesting part, having the "whole system" module.
While I'm not sure how that really can be modularized outside of the
applicaiton level logic (controls the demux, codecs, etc), I'm not against the
idea. More modularized the better I say. 

There is a comcern though especially for those making commercial codec and/or
players. Specifically if a commercial entity want to make a DVD player "by
the books" so to speak while offering up their modules to work with the
API/player design that we make up here then we need to make sure that the CSS
decryption is handled inside the codec. We also need to offer some very basic
CSS authorization channel paths between codec and the file handling modules.
If we want to support commercial interests then we need to be careful just how
much we modularize.

We also need to allow and compile time modules to be binary only. From a
commercial aspect some parts simply can not be open sourced (NAv API for
example) due to outside licensing terms from the DVD Forum. Those parts need
to be able to be binary objects to be linked in.

As far as the Nav API goes I see no reason not to embrace the Convergence
DVDPlayer.h API definition as the stadard. There really isn't a lot of room
for changing the minimum API needed and they have put a lot of time into it
already... While we probably won't have the API module until they release
their card, we can write any software to use that API definition so we are
ready to do some quick debugging when the module becomes available.

Finally, the codec modules should be able to be normal software codecs. We
also need a mechanism for supporting hardware decoders in the same framework.
Hardware decoders are an interesting problem because they tend to combine the
DEMUX, several codecs, and many of the functions of the "system module." If
these funcitons aren't handled in hardware then they are often tied into the
driver code for the card so it still looks like the hardware is doing the work
to a user space program. This part needs some work. I've had some ideas and
heard some others but nothing really seems to effectively address the issue.
To complicate issues many hardware vendors will not be willing or able to
seperate their drivers into modules. For example, say Sigma was going to
support the Hollywood+ under this player. That card have AC-3, DEMUX, and CSS
in software and MPEG-2 and display handled in hardware. They can't really
take the AC-3 or CSS and put it into seperate modules for this player since
they will be breaking their agreements and licensing restrictions. So in
order to get that card and other like it supported we would need to make sure
that the framework for this player would be able to use:

1) INdividual modules for the case of a module software playback system or
perhaps using individual hardware pieces for the codecs (AC-3 board, MPEG-2
board, etc).

2) A way to go around all the codecs and demux and all adn simply toss data
into a combination module hardware device.

There is another option which is a bit less attractive from the module
perspective but better from the commercial friendliness and performance
standpoint... for DVD playback only support combination codecs. So in the
case of software decoding one would need to have a single codec that provided
it's own demux, CSS, and mpeg-2 and AC-3 decoding... all in one codec module.
In this way we get around the issues of the differences in hardware and
. We also get a performance
boost since all of the decoding is handled in a single logical module.
Syncronization of auto and video is much easier too.

That was a lot... but thats the set of ideas that I've come up with and others
have come up with as far as I can remember them. Ideas, comments, flames, etc
welcome. :)

> > This kind of brings up a last point, all of these "mini-projects" are
> > operating under the umbrella of Livid, right? So where is the Livid project
> > management?
> 
> hmm, sorry for having to say that, but i've never seen one.

Well I can't say I've every realy seen an organized "livid" project either...
just a mish-mash of smaller individual projects. It's been fine up until this
point because without something fromt he smaller individaul projects the
whole livid project really didn't have anything to work with, but I think it
is reaching the point where a more organized top level is needed.

> > The web site and CVS have been in chaos for a long time now with
> > no word from anyone trying to fix it. I can only assume that there isn't
> > any one (or group) that is trying to pull together all of these mini-projects
> > and create the much sought after dvd player application. Isn't this what the
> > livid management should be doing? Isn't that what this list is all about?
> 
> RIGHT. - so who has enough insight in all this projects and who is able
> to manage all of this, who has got enough time?

Well, the right answer might actually be to look to framework projects already
out there... GMF (Gnome Media Framework) is interesting and very young. The
individual parts fo livid fit well into what it is trying to do (essentially
make a Microsoft DirectShow and Micorsoft Media Player like clone, which has
been hailed on this list as being an actually decent thing from Microsoft).
Check out the Gnome web site for links to GMF for more info. 

That might be down the road though... right now it would probably be better to
have a livid player made up and all the pieces developed to a usable state.
Then look into GMF. Since the sentiment seems to be modular is right and
good, integration into GMF should be an easy thing to do after the fact.

Paul Volcko
LSDVD
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: PGPEnvelope - http://www.bigfoot.com/~ftobin/resources.html

iD8DBQE393HlOzc/wrhmP6URAjEHAKCy/MZecZjSAkBEEe5BIFOjvQ2O9QCeIHoO
M5b6b9B9T2lHeKjr1g6AA4c=
=qsdw
-----END PGP SIGNATURE-----

From derek@spider.com Sun, 3 Oct 1999 22:13:15 +0100
Date: Sun, 3 Oct 1999 22:13:15 +0100
From: Derek Fawcus derek@spider.com
Subject: Modularized player system (was: Re: [Livid-dev] Time to help others?)

On Sun, Oct 03, 1999 at 04:22:17PM +0200, Michael Holzt wrote:
> On Sun, Oct 03, 1999 at 04:53:40PM +0200, Thomas 'Dent' Mirlacher wrote:
> > one important patch which is needed in th VOB player is beeing able to 
> > play specified blocks of data (for menues, program chains ...), which is 
> > in development according to joachim.
> 
> Sounds good. How about adding some type of GPL'd navigation control
> language? If we cannot decode the .IFO-Files yet, we may use a
> own system for describing the navigation. Volunteers may build 
> navigation control files for specific DVDs and made them available
> in the Internet. So we can just emulate the navigation of the original
> DVD...
> 
> I suggest we should try to develop and fully modularized playing
> system like the Media player done in Windows. Microsoft is often
> technically bad but their module system for the media player is
> very good. We should do this too, but a bit deeper modularized.
> I think a player could use:
> 
> - a datareading module. Could decode CSS and read the data.
> 
> - a demuxing module. This module should decode the file/data
> and parse the different stream. Their should be some interface
> over which the module can report what type of streams
> (eg. video, audio, subtitle etc.) to the higher levels
> 
> - a audio-decoding module
> - a video-decoding module
> - a navigation-control module

I actually like the idea of a distributed system. i.e. some modules
can run on a different machine. At the moment I can run the CSS decrypter
and NIST player on different machines:

falcon> rsh kiwi 'cd dvd/titles/bugs/full; css-cat 05 /cd/video_ts/
vts_05_01.vob'|mpeg2player -na -ns -vob -f -

This is 'cause the DVD drive is in a slow machine (200Mhz Winchip 2), and
my main machine (300Mhz K6-2) is somewhat faster for the MPEG decode. The
winchip goes real slow when it's decrypting CSS and decoding MPEG.

I'd actually like to have a sort of preparser that could strip out the
uninteresting bits (unused languages, subtitles when not playing),
eventually alternate views, and only feed on what's required. Actually
it would I guess eventually handle the navigation with high level feedback
between it and the MPEG player.
This should allow me to split out the AC3 audio stream at an early stage
and feed it out to external h/w (or a third PC to s/w decode). Again there'd
have to be some timing sync/feedback stream.

DF
-- 
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034

From pvolcko@concentric.net Sun, 3 Oct 1999 18:16:57 -0400 (EDT)
Date: Sun, 3 Oct 1999 18:16:57 -0400 (EDT)
From: pvolcko@concentric.net pvolcko@concentric.net
Subject: Modularized player system (was: Re: [Livid-dev] Time to help
others?)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> I actually like the idea of a distributed system. i.e. some modules
> can run on a different machine. At the moment I can run the CSS decrypter
> and NIST player on different machines:
> 
> falcon> rsh kiwi 'cd dvd/titles/bugs/full; css-cat 05 /cd/video_ts/
vts_05_01.vob'|mpeg2player -na -ns -vob -f -
> 
> This is 'cause the DVD drive is in a slow machine (200Mhz Winchip 2), and
> my main machine (300Mhz K6-2) is somewhat faster for the MPEG decode. The
> winchip goes real slow when it's decrypting CSS and decoding MPEG.
> 
> I'd actually like to have a sort of preparser that could strip out the
> uninteresting bits (unused languages, subtitles when not playing),
> eventually alternate views, and only feed on what's required. Actually
> it would I guess eventually handle the navigation with high level feedback
> between it and the MPEG player.
> This should allow me to split out the AC3 audio stream at an early stage
> and feed it out to external h/w (or a third PC to s/w decode). Again there'd
> have to be some timing sync/feedback stream.
> 

Thats kinda cool, but I would think a requirement of having the decoders on
the same machine would need to be put in place. Syncing the two would be a
bear over an otherwise latent ethernet connection. Maybe something a bit more
reliable timing wise, like a serial or parallel link between systems would
server as a good enough syncing stream transport.

CSS can happen anywhere in the data path before the decoders and isn't a
syncing issue so that can be done over a highly latent network connection,
just as long as it had a good enough (5Mbps) average available bandwidth and
the buffering was good enough to handle collisions and other delays in packet
delivery.

Would CORBA or some other distributed object standard work for this do you
think or would something more application specific need to be devised?

Paul Volcko
LSDVD
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: PGPEnvelope - http://www.bigfoot.com/~ftobin/resources.html

iD8DBQE399XdOzc/wrhmP6URAovmAKCoF9gpWMcVW5m0NtvmXpng83hIuwCfR4Q0
vfG1eElFIgfpO4SXIR3vZ94=
=/BHp
-----END PGP SIGNATURE-----

From derek@spider.com Mon, 4 Oct 1999 16:41:06 +0100
Date: Mon, 4 Oct 1999 16:41:06 +0100
From: Derek Fawcus derek@spider.com
Subject: Modularized player system (was: Re: [Livid-dev] Time to help others?)

On Sun, Oct 03, 1999 at 06:16:57PM -0400, pvolcko@concentric.net wrote:
> 
> Thats kinda cool, but I would think a requirement of having the decoders on
> the same machine would need to be put in place. Syncing the two would be a
> bear over an otherwise latent ethernet connection. Maybe something a bit more
> reliable timing wise, like a serial or parallel link between systems would
> server as a good enough syncing stream transport.

I'd have though that since AC3 is a fixec bit rate, using external h/w
to decode it (or a third machine) that can do full rate, would make the
sync issue easier. Assume that we have sufficient buffering in the
(multi machine) system to deal with network collisions. Then we simply run
the Audio at full rate, and sync the video to the audio. This will only
have to deal with the initial delta-t and any retransmitted frames.

I have to admin - I want to do this all over a network as that is how
I intend to use DVB. Note DVB will be a Transport (as opposed to Program)
Stream and thus could be carried in UDP. I'm not sure if I could get away
with running the DVD stream through UDP.

However - yes we will need a single machine system, I'm just advocating
architecting it as a distributed network system. In the single machine
environment it just happens to run in a smaller number of CPUs.

> CSS can happen anywhere in the data path before the decoders and isn't a
> syncing issue so that can be done over a highly latent network connection,
> just as long as it had a good enough (5Mbps) average available bandwidth and
> the buffering was good enough to handle collisions and other delays in packet
> delivery.

I'd suggest doing the CSS at the place the data is read. I don't know if
only Video packets are crypted, but if all packets can be, then by doing
some prefiltering we could (possibly) reduce the CSS load.

> Would CORBA or some other distributed object standard work for this do you
> think or would something more application specific need to be devised?

Overkill. I think simple pipes of data will do.

DF
-- 
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034