From Pvolcko@concentric.net Tue, 15 Jun 1999 13:02:39 -0400 (EDT)
Date: Tue, 15 Jun 1999 13:02:39 -0400 (EDT)
From: Paul Volcko Pvolcko@concentric.net
Subject: [LinuxDVD] Linux DVD API
In some of my recent discussions with Andreas Bogk he made a suggestion
that an independent consortium of sorts be formed to work on a DVD API
(principally for Linux, but hopefully extensible to other OSes as well).
This consortium would design and build an API that would make programming
applications that use DVD Video possible without having to get the DVD
spec and go through the problems involved with current DVD Video
programming.
I like the idea and would like to explore it some here on the list.
Hopefully there is a good number of people here so we can hash through
this pretty good fairly quickly.
The benefits of such a project are somewhat obvious:
1) no more having to pay $5,000 to get a set of the DVD Video specs
2) A common interface for accessing DVD related hardware and software
decoders.
3) An easy way to use program chaining data off a DVD Video disc and not
program a parser and handler for every project.
4) Updates to the DVD Video spec would require a change in the API and a
recompile of the projects using it, not a change in every project (some
simple, some hard) and a recompile.
And many more, I'm sure.
But, as always the potential problems:
1) The DVD Consortium would be more than slightly miffed at the release of
such a tool and would more than likely drag the creators/distributors
through a costly legal battle. Remember we would be making it pretty much
pointless to buy the DVD Video Specs from them.
2) In order to code it, a license from the DVD consortium would be needed
to be purchased (ie at least $5,000).
3) Unless you welcome the possibility of #1, then this would not be
open-sourceable unless it was reverse engineered. Releasing such a tool
would piss certain power huingry people off enough, releasing how it was
done and how it works would really grab their attention. :)
there's probably more but those are the highlights of what I can think of
right now.
So, what do people think? Any Laywers here that might be abel to shed
some light on the concerns mentioned in here? Anyone want to help tackle
actually doing this?
Another idea is to get some driver and board manufacturers involved,
namely Sigma Designs and Creative Labs. ATI and MAtrox might be some good
candidates too. This would be becasue they stand something to gain from
the availability of this kind of API and may actually have efforts of
their own in doing this exact thing.
Paul Volcko
From cdavis@thepentagon.com Wed, 16 Jun 1999 22:07:50 -0400
Date: Wed, 16 Jun 1999 22:07:50 -0400
From: Colin Davis cdavis@thepentagon.com
Subject: [LinuxDVD] Linux DVD API
Paul Volcko wrote:
There hasn't been any discussion on this, so I think I'll jump in ;)
>
> In some of my recent discussions with Andreas Bogk he made a suggestion
> that an independent consortium of sorts be formed to work on a DVD API
> (principally for Linux, but hopefully extensible to other OSes as well).
> This consortium would design and build an API that would make programming
> applications that use DVD Video possible without having to get the DVD
> spec and go through the problems involved with current DVD Video
> programming.
>
I think this is a wonderfull idea. This is the type of thing that would
be usefull to the entire community.
Do you have any ideas for who would be on it?
> I like the idea and would like to explore it some here on the list.
> Hopefully there is a good number of people here so we can hash through
> this pretty good fairly quickly.
>
> The benefits of such a project are somewhat obvious:
> 1) no more having to pay $5,000 to get a set of the DVD Video specs
Very useful. If the API was minimal enough, it would be up to the
indivdual DVD player writers to make the actual application, which would
allow for more feature-rich players (as one group would not do
everything)
> 2) A common interface for accessing DVD related hardware and software
> decoders.
Again very usefull. Write once, run anywhere. We don't want the
Creative-only player, etc.
> 3) An easy way to use program chaining data off a DVD Video disc and not
> program a parser and handler for every project.
> 4) Updates to the DVD Video spec would require a change in the API and a
> recompile of the projects using it, not a change in every project (some
> simple, some hard) and a recompile.
True.
>
> And many more, I'm sure.
>
> But, as always the potential problems:
> 1) The DVD Consortium would be more than slightly miffed at the release of
> such a tool and would more than likely drag the creators/distributors
> through a costly legal battle. Remember we would be making it pretty much
> pointless to buy the DVD Video Specs from them.
I believe we would be within out legal rights to do this however. Does
anyone have a copy of their license?
We should read it very carefully to be sure ;)
> 2) In order to code it, a license from the DVD consortium would be needed
> to be purchased (ie at least $5,000).
this is not a large sum of money for a major company. If we could gain
acceptance, we could raise this from many Linux distros, as they hve a
vested interest in Linux. Corel may be more willing than others to help,
as it is positioning it's self as an alternative to win9x. If win9x can
play movies, but corel Linux Can't, they have a problem... Does anyone
have any contacts?
> 3) Unless you welcome the possibility of #1, then this would not be
> open-sourceable unless it was reverse engineered. Releasing such a tool
> would piss certain power huingry people off enough, releasing how it was
> done and how it works would really grab their attention. :)
Again we would need to review the specs, but I agree it would be
difficult. I think that this would be a good first step, and then, later
down the line, we (or another group) could consider writing a COMPATIBLE
open sourced API. You could choose what ever one you want. Any project
member must know that they will not be allowed to work on an open source
DVD API, as they would have prior knowledge of the spec.
>
> there's probably more but those are the highlights of what I can think of
> right now.
>
> So, what do people think? Any Laywers here that might be abel to shed
> some light on the concerns mentioned in here? Anyone want to help tackle
> actually doing this?
>
> Another idea is to get some driver and board manufacturers involved,
> namely Sigma Designs and Creative Labs. ATI and MAtrox might be some good
> candidates too. This would be becasue they stand something to gain from
> the availability of this kind of API and may actually have efforts of
> their own in doing this exact thing.
>
Agreed. We also may wish to speak to Nvidia, as (I believe) their cards
have a DVD chip in them. They also have linux support, so it is also in
their interest. If we can get together enough support, we could make
this happen.
> Paul Volcko
--
Colin Davis
From pvolcko@concentric.net Wed, 16 Jun 1999 22:14:44 -0400 (EDT)
Date: Wed, 16 Jun 1999 22:14:44 -0400 (EDT)
From: Paul Volcko pvolcko@concentric.net
Subject: [LinuxDVD] Linux DVD API
> > In some of my recent discussions with Andreas Bogk he made a suggestion
> > that an independent consortium of sorts be formed to work on a DVD API
> > (principally for Linux, but hopefully extensible to other OSes as well).
> > This consortium would design and build an API that would make programming
> > applications that use DVD Video possible without having to get the DVD
> > spec and go through the problems involved with current DVD Video
> > programming.
> >
>
> I think this is a wonderfull idea. This is the type of thing that would
> be usefull to the entire community.
> Do you have any ideas for who would be on it?
I'm not sure who would be on it, at least specifically. I can think of
those who should be on it in general:
1) One representative from each current active DVD project, software or
hardware.
2) One rep from as many companies that we can get involved as possible.
3) People who have had prior experience creating an API that are
interested in the course of DVD development.
4) People who have knowledge of or have created drivers under linux and
other OSes that pretain to this projects goals (video, sound, and software
codecs, etc)
Andreas suggested that I head up the effort. I'll take it on if there is
no one else who comes forward wanting the job. While I have a vested
interest in the goals of this endeavor, I could see that there would be
people more "qualified" to act as the lead of this "consortium." At the
same time, I'm not likely to be willing to let just anyone come in and say
"I want to be lead on this." It's important enough that it gets done
right, as such I would expect anyone wanting to lead this thing would be
willing to give some reasoning and "credentials." I'll provide these
for myself in another message once some more discussion has occurred on
this idea.
> > I like the idea and would like to explore it some here on the list.
> I believe we would be within out legal rights to do this however. Does
> anyone have a copy of their license?
> We should read it very carefully to be sure ;)
Well, I'll have to see about getting a copy of the NDA signed for the
specs my project is using. If someone else has one of these pretty sheets
of paper please give it a good read through and give us some information
if you can.
> > 2) In order to code it, a license from the DVD consortium would be needed
> > to be purchased (ie at least $5,000).
>
> this is not a large sum of money for a major company. If we could gain
> acceptance, we could raise this from many Linux distros, as they hve a
> vested interest in Linux. Corel may be more willing than others to help,
> as it is positioning it's self as an alternative to win9x. If win9x can
> play movies, but corel Linux Can't, they have a problem... Does anyone
> have any contacts?
No, it isn't a lot for a company. But if a single company buys said specs
for the effort, then they would need to be clear on the fact that they
aren't buying any kind of extra "vote" or pull within the group. It'll be
tricky.
> > 3) Unless you welcome the possibility of #1, then this would not be
> > open-sourceable unless it was reverse engineered. Releasing such a tool
> > would piss certain power huingry people off enough, releasing how it was
> > done and how it works would really grab their attention. :)
>
> Again we would need to review the specs, but I agree it would be
> difficult. I think that this would be a good first step, and then, later
> down the line, we (or another group) could consider writing a COMPATIBLE
> open sourced API. You could choose what ever one you want. Any project
> member must know that they will not be allowed to work on an open source
> DVD API, as they would have prior knowledge of the spec.
Well, from what I've seen of the specs (skimmed through all of them and am
quite familiar with portions of them) they would be bordering on
impossible to fully reverse engineer.
> > there's probably more but those are the highlights of what I can think of
> > right now.
> >
> > So, what do people think? Any Laywers here that might be abel to shed
> > some light on the concerns mentioned in here? Anyone want to help tackle
> > actually doing this?
> >
> > Another idea is to get some driver and board manufacturers involved,
> > namely Sigma Designs and Creative Labs. ATI and MAtrox might be some good
> > candidates too. This would be becasue they stand something to gain from
> > the availability of this kind of API and may actually have efforts of
> > their own in doing this exact thing.
> >
>
> Agreed. We also may wish to speak to Nvidia, as (I believe) their cards
> have a DVD chip in them. They also have linux support, so it is also in
> their interest. If we can get together enough support, we could make
> this happen.
Is there a list anywhere of card manufacturers or of existing DVD software
solutions? Might be a good idea to compile such a list and start gettign
aocntact list formed.
Anyone else have input on this? It's a non-trivial idea and would need
widespread support withing the DVD development community and programming
community at large to work.
Paul
From derek@spider.com Thu, 17 Jun 1999 08:04:10 +0100
Date: Thu, 17 Jun 1999 08:04:10 +0100
From: Derek Fawcus derek@spider.com
Subject: [LinuxDVD] Re: Linux DVD API
On Wed, Jun 16, 1999 at 10:14:44PM -0400, Paul Volcko wrote:
> > Agreed. We also may wish to speak to Nvidia, as (I believe) their cards
> > have a DVD chip in them. They also have linux support, so it is also in
> > their interest. If we can get together enough support, we could make
> > this happen.
>
> Is there a list anywhere of card manufacturers or of existing DVD software
> solutions? Might be a good idea to compile such a list and start gettign
> aocntact list formed.
Well in terms of video cards there are a number of chip sets that include
h/w support for MPEG playback (real support including IDCT and motion
compensation). Those that I can name off the top of my head are the
ATI Rage Pro 128, PVRSG, S3's Savage 3/4 (no IDCT) and some of the SiS
chipsets.
For the SiS chipsets the documentation is freeely available and from
memory simply takes a slightly massaged MPEG 2 stream.
If one was to try and support the above then theoretically unencrypted
DVD's could be played back, but given that the CSS would have to be in
software, normal encrypted ones would be a problem.
DF
--
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034
From god@yinyang.hjsoft.com Thu, 17 Jun 1999 09:07:19 -0400 (EDT)
Date: Thu, 17 Jun 1999 09:07:19 -0400 (EDT)
From: Shannon Aldinger god@yinyang.hjsoft.com
Subject: [LinuxDVD] Re: LinuxDVD digest, Vol 1 #8 - 8 msgs
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
You may want to talk to Alan Cox to see if this could be added somewhat
seemlessly into the Video4Linux API. Although I don't know his feelings on
binary modules. It would have to be a module to comply with GPL of the
kernel. This would also have the benefit of allowing completely
open-sourced dvd-players which use your API, since CSS would be handled by
the binary-only kernel module or modules.
The only issue I can think of with regard to CSS is the encryption across
the bus. You may be able to leave the kernel do CSS, then have some other
encryption across the bus, so individual players don't need to get CSS
license and DVD specs. I haven't seen DVD specs but this is what I
understand from reading a few FAQs of the web for it.
If any of my conceptions of DVD are wrong let me know...
Mental Recursion: Out of Memory: Personality Dumped.
____________________________________ ____________________________
/ Systems Analyst __/\ /_ Primary Email Address: /\
/Analytical Design Solutions, Inc./_ \/\ __/ saldinger@adsi-cni.com / /\
/___________________________________/\ /___________________________/ /
\___________________________________\/ \___________________________\/
\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.7 (GNU/Linux)
Comment: Made with PGP4Pine
iD8DBQE3aPMWRWaw1Na2tZ4RAsvCAKCLjH+TdqMHRFZFmo67DPZ0szA6DwCgsmyg
hJ1+wDYkcOYlNWiEjiHztdg=
=UjGd
-----END PGP SIGNATURE-----
From pvolcko@concentric.net Thu, 17 Jun 1999 09:17:04 -0400 (EDT)
Date: Thu, 17 Jun 1999 09:17:04 -0400 (EDT)
From: Paul Volcko pvolcko@concentric.net
Subject: [LinuxDVD] Re: Linux DVD API
> > Is there a list anywhere of card manufacturers or of existing DVD software
> > solutions? Might be a good idea to compile such a list and start gettign
> > aocntact list formed.
>
> Well in terms of video cards there are a number of chip sets that include
> h/w support for MPEG playback (real support including IDCT and motion
> compensation). Those that I can name off the top of my head are the
> ATI Rage Pro 128, PVRSG, S3's Savage 3/4 (no IDCT) and some of the SiS
> chipsets.
>
> For the SiS chipsets the documentation is freeely available and from
> memory simply takes a slightly massaged MPEG 2 stream.
>
> If one was to try and support the above then theoretically unencrypted
> DVD's could be played back, but given that the CSS would have to be in
> software, normal encrypted ones would be a problem.
I have to do some research into the current Video 4 Linux and V4L2
projects, but it would seem that work for mpeg2 decoding on those cards
would fall under their umbrella of concern (the DVD API would simply
provide links into V4L as well as include support for DVD decoder card
specifically).
Keep in mind, this API isn't going to do any kind of decoding by itself.
It will simply provide a common interface layer to drivers for hardware
and software decoders. The only "Decoding" that this API may end up doing
would be CSS descrambling (it would have to be totally hidden from the
user in terms of method and protocol) and decoding (actually just
filtering and parsing) of the vob and ifo files on the DVD discs. It
wouldn't have any mpeg decoding code or AC-3 decoding/mixdown code in the
API (although such modules might be distributed/bundled with the API).
I know of one project that is currently planning to get stuff put into the
V4L2 project to support their application. I have to do some more
research into the V4L2 api and what it's intent is and what it's
distribution method is (binary only or source/binary). It may turn out
that all this can go into that API (if it's owner is willing to include it
all).
Is anyone here familiar with the V4L2 project? Would this DVD API be able
to be included? Does the ideas presented for this so far jive with the
intent and schedule for the V4L2 project?
Paul
From pvolcko@concentric.net Thu, 17 Jun 1999 10:22:47 -0400 (EDT)
Date: Thu, 17 Jun 1999 10:22:47 -0400 (EDT)
From: Paul Volcko pvolcko@concentric.net
Subject: [LinuxDVD] Re: LinuxDVD digest, Vol 1 #8 - 8 msgs
On Thu, 17 Jun 1999, Shannon Aldinger wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> You may want to talk to Alan Cox to see if this could be added somewhat
> seemlessly into the Video4Linux API. Although I don't know his feelings on
> binary modules. It would have to be a module to comply with GPL of the
> kernel. This would also have the benefit of allowing completely
> open-sourced dvd-players which use your API, since CSS would be handled by
> the binary-only kernel module or modules.
>
> The only issue I can think of with regard to CSS is the encryption across
> the bus. You may be able to leave the kernel do CSS, then have some other
> encryption across the bus, so individual players don't need to get CSS
> license and DVD specs. I haven't seen DVD specs but this is what I
> understand from reading a few FAQs of the web for it.
>
> If any of my conceptions of DVD are wrong let me know...
>
> Mental Recursion: Out of Memory: Personality Dumped.
> ____________________________________ ____________________________
> / Systems Analyst __/\ /_ Primary Email Address: /\
> /Analytical Design Solutions, Inc./_ \/\ __/ saldinger@adsi-cni.com / /\
> /___________________________________/\ /___________________________/ /
> \___________________________________\/ \___________________________\/
> \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v0.9.7 (GNU/Linux)
> Comment: Made with PGP4Pine
>
> iD8DBQE3aPMWRWaw1Na2tZ4RAsvCAKCLjH+TdqMHRFZFmo67DPZ0szA6DwCgsmyg
> hJ1+wDYkcOYlNWiEjiHztdg=
> =UjGd
> -----END PGP SIGNATURE-----
I'm assuming you are talking about having unscrambled data moving across
the system bus. While this used to be a concern in previous licensing
agreements for CSS, I think the restrictions have been reduced in regard
to this. Otherwise there would be no CSS unscrambling in software, only
in hardware before piping into a hardware MPEG-2 and AC-3 decoder and them
output in analog (which then gets Macrovision treatment). This is
obviously no tthe case though as the Hollywood+ card and Dxr3 both perform
CSS descrambling in software.
For our purposes, assuming we can get CSS licensing for this, we would
have to have all CSS functionality totally encapsulated in the API.
Either through ioctls modification or through direct communication with
the drive from within the API, the CSS session would be negotiated. Then
the data would have to be fed into the API or read in by the API and then
descrambled... all without use intervention or access to the unscrambled
information. This last part is important because it means that no one
would be able to use the API to perform CSS descrambling and then take
that unscrambled data and actually direct it anywhere. The APi would need
to be instructed where to send it. In the case of both hardware and
software destinations, though, there would be the chance of spoofing the
API into thinking the destination was an output or linked to an output
device, when in fact it is simply dumping the unscrambled data to a file
(which can be used for re-coding into a unscrambled version of the
original). I'm not sure what the CSS licensing provisions are for
software decoders. Without some way of verifiying that the device or
software decoder is trustworthy and actually performing the data decoding
and output... well you get the idea I'm sure.
My current project group will be contacting the CSS licensing group fairly
soon. I'll let everyone know what kinds of restrictions will be placed on
this API when and if I can.
Something interesting would be to know how any of the current software
only DVD player applications (no hardware decoding whatsoever) work. Do
they have to have their own MPEG-2/AC-3 decoding included or can they use
other decoder modules/codecs? Do they only work with a specific output
device (such as only working with a certain video card) or do they go
through the windows video API enabling any video card in windows to be an
output device (which would make current windows implementations
susceptible to the idea presented above)?
Paul Volcko
LSDVD Project
From andreas@andreas.org 17 Jun 1999 16:47:03 +0200
Date: 17 Jun 1999 16:47:03 +0200
From: Andreas Bogk andreas@andreas.org
Subject: [LinuxDVD] Re: Linux DVD API
Paul Volcko <pvolcko@concentric.net> writes:
> Is anyone here familiar with the V4L2 project? Would this DVD API be able
> to be included? Does the ideas presented for this so far jive with the
> intent and schedule for the V4L2 project?
There's a driver for an MPEG2 decoder card (without CSS) on
http://mpeg.openprojects.net. The V4L2 API would be suited for decoder
hardware, but we would have to specify the appropriate stream types.
Andreas
--
Reality is two's complement. See:
ftp://ftp.netcom.com/pub/hb/hbaker/hakmem/hacks.html#item154
From pvolcko@concentric.net Thu, 17 Jun 1999 12:04:27 -0400 (EDT)
Date: Thu, 17 Jun 1999 12:04:27 -0400 (EDT)
From: Paul Volcko pvolcko@concentric.net
Subject: [LinuxDVD] Re: Linux DVD API
On 17 Jun 1999, Andreas Bogk wrote:
> Paul Volcko <pvolcko@concentric.net> writes:
>
> > Is anyone here familiar with the V4L2 project? Would this DVD API be able
> > to be included? Does the ideas presented for this so far jive with the
> > intent and schedule for the V4L2 project?
>
> There's a driver for an MPEG2 decoder card (without CSS) on
> http://mpeg.openprojects.net. The V4L2 API would be suited for decoder
> hardware, but we would have to specify the appropriate stream types.
>
Yeah I saw that yesterday. I didn't see any other decoders supported
though. I could see making the API have the ability to use V4L/V4L2
devices, but the V4L/V4L2 project would seem to be concentrating on video
only (hence the name). Since we would need to do audio decoding support
as well, I think that it would be reasonable to have the APi directly
interface with the various devices. V4L cards could be supported through
that API, though an additional layer would be added to working with them
from a user standpoint (or the DVD API). Also, V4L is for linux only.
While the main thrust of the implementation of this DVD API would be linux
based, it makes sense to keep it as general and portable as possible so
dependence on V4L would be a mistake, I think.