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