From tz@execpc.com Fri, 03 Dec 1999 23:20:09 -0500 Date: Fri, 03 Dec 1999 23:20:09 -0500 From: tz tz@execpc.com Subject: [Livid-dev] Matrix problems... Matrix, the DVD, that is. 1. I have a K6-II, so this might have an impact. I am using 586 instead of 686 in the config, but I might need something more. 2. After the WB logo after the opening sky fades to black, if I have a/v sync, it will stop and not restart. 3. The audio starts saying "Invalid Mantissa" and eventually "Invalid Exponent" with an exit at the point where the girl first hits the cop. It doesn't resume. This is with the CVS versions of everything. AC3 did the same thing as mpeg2player.
From katzj@linuxpower.org Fri, 3 Dec 1999 21:03:10 -0800 Date: Fri, 3 Dec 1999 21:03:10 -0800 From: Jeremy Katz katzj@linuxpower.org Subject: [Livid-dev] Matrix problems... On Fri, 03 Dec 1999, tz wrote: > Matrix, the DVD, that is. It's out there.... :) > 1. I have a K6-II, so this might have an impact. I am using 586 instead > of 686 in the config, but I might need something more. Depending on compiler you might want to set your architecture to actually be k6, but I don't think 586 should cause any problems (I don't have a K6 -- someone correct me if I'm wrong :) > 2. After the WB logo after the opening sky fades to black, if I have a/v > sync, it will stop and not restart. Hmm... odd. I think I saw this at one point, but it's been fixed for a few weeks AFAIK.... > 3. The audio starts saying "Invalid Mantissa" and eventually "Invalid > Exponent" with an exit at the point where the girl first hits the cop. > It doesn't resume. The invalid mantissas are due to different angles being used in the DVD. In a lot of ways, the Matrix is not the ideal to test with, since it uses a lot of IFO-related stuff, which css-cat and mpeg2player don't cope with yet. Cheers, Jeremy -- Jeremy Katz http://linuxpower.org Personal: katzj@linuxpower.org School: jlkatz@unity.ncsu.edu QOTD: Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work.
From dent@cosy.sbg.ac.at Fri, 3 Dec 1999 22:58:06 +0100 (CET) Date: Fri, 3 Dec 1999 22:58:06 +0100 (CET) From: Thomas 'Dent' Mirlacher dent@cosy.sbg.ac.at Subject: [Livid-dev] Matrix problems... hi, people out there ... --snip/snip > > 2. After the WB logo after the opening sky fades to black, if I have a/v > > sync, it will stop and not restart. > > Hmm... odd. I think I saw this at one point, but it's been fixed for a > few weeks AFAIK.... problem of the players. - see bleow. > > 3. The audio starts saying "Invalid Mantissa" and eventually "Invalid > > Exponent" with an exit at the point where the girl first hits the cop. > > It doesn't resume. > > The invalid mantissas are due to different angles being used in the DVD. > In a lot of ways, the Matrix is not the ideal to test with, since it > uses a lot of IFO-related stuff, which css-cat and mpeg2player don't > cope with yet. right the IFO information needed to playback this movie IS the answer. so, i've a question here: people keep on posting, that 'the matrix' is an multiangle DVD - i've never seen that (nor using winblows players, and i also didn't see it when parsing the ifo files) - i'm just getting ILVU which are "interleaved video units" ... but thats all (ok, i don't get it any more, because they're filtered out ... but i GOT it ;) ... as far as i'm concerned: css-cat and mpeg2player should not have ifo support in the future. cheers ++dent -- Linux is no REVOLUTION - it's EVOLUTION at operating system level ;)
From adamp+@andrew.cmu.edu 4 Dec 1999 11:12:47 -0500 Date: 4 Dec 1999 11:12:47 -0500 From: Adam Pennington adamp+@andrew.cmu.edu Subject: [Livid-dev] Matrix problems... > right the IFO information needed to playback this movie IS the answer. > so, i've a question here: people keep on posting, that 'the matrix' is > an multiangle DVD - i've never seen that (nor using winblows players, and > i also didn't see it when parsing the ifo files) - i'm just getting > ILVU which are "interleaved video units" ... but thats all (ok, i don't > get it any more, because they're filtered out ... but i GOT it ;) > > ... as far as i'm concerned: css-cat and mpeg2player should not have ifo > support in the future. I have the matrix right here... Yeah, it isn't multiangle. As far as mpeg2player goes, the current direction seems like the right one. Have it take flags for every DVD option imaginable, and realize that it is probably going to be hard for anything but an ifo parser to actually use most of them. It seemed like everyone was agreed a few months ago that NIST should be ported to C, since alot of people are avoiding it's C++ness. I put some time into trying the demux portion... I gave up due to not having the necessary time. The current code is quite dependent on classes, and functions within classes. Do people still feel that getting this into C is a worthwhile persuit? adam
From aaronw@home.com Sat, 04 Dec 1999 13:08:43 -0800 Date: Sat, 04 Dec 1999 13:08:43 -0800 From: Aaron Williams aaronw@home.com Subject: [Livid-dev] Matrix problems... After playing around with the NIST code (and making a few optimizations here and there) I think it might be a step backwards to move back to C. There's nothing wrong with C++, even for performance critical code, if it is written properly. As far as C++ code goes, NIST is very clean. Adam Pennington wrote: > > > It seemed like everyone was agreed a few months ago that NIST should > be ported to C, since alot of people are avoiding it's C++ness. I put > some time into trying the demux portion... I gave up due to not having > the necessary time. The current code is quite dependent on classes, > and functions within classes. > > Do people still feel that getting this into C is a worthwhile persuit? > > adam
From insomnia@core.binghamton.edu Sat, 4 Dec 1999 17:48:17 -0500 (EST) Date: Sat, 4 Dec 1999 17:48:17 -0500 (EST) From: Stea Greene insomnia@core.binghamton.edu Subject: [Livid-dev] C/C++ (WAS: Matrix problems...)a On Sat, 4 Dec 1999, Aaron Williams wrote: > After playing around with the NIST code (and making a few optimizations > here and there) I think it might be a step backwards to move back to C. > There's nothing wrong with C++, even for performance critical code, if > it is written properly. > This is definitely true. C++ can be written exactly like C and get the same exact assembly result. Plus the ability to use classes and other syntactic conveniences makes C++ significantly more readable, reusable and modifyable. The problems come about with the fact that C++ compilers are not as standard as C compilers, many more things can be implied in C++ code that can be implemented many different ways by the compiler, and many simple things in C++ code are not simple in the final binary. As long as you know what your doing, C++ can be better than C in almost every respect, but when you start using virtual functions, templates, dynamic variable creation, etc... it can become the slow mess it has been rumored to be. ...I'll get off my soap-box now.... --Insomnia (Stea Greene)
From aholtzma@ess4.engr.UVic.CA Sat, 4 Dec 1999 15:00:50 -0800 Date: Sat, 4 Dec 1999 15:00:50 -0800 From: Aaron Holtzman aholtzma@ess4.engr.UVic.CA Subject: [Livid-dev] Matrix problems... It would seem that Aaron Williams (aaronw@home.com) said: > After playing around with the NIST code (and making a few optimizations > here and there) I think it might be a step backwards to move back to C. > There's nothing wrong with C++, even for performance critical code, if > it is written properly. As far as C++ code goes, NIST is very clean. > Except for the fact that there is absolutely no reason for a video codec to be written in an object oriented style. Reminds me of the time the sound guys decided to write the sound driver in C++. Blech. C++ isn't that good of an object oriented language anyways. This is all a moot point anyways. My new video backend is threatening to release itself onto the unsuspecting masses and we won't have to worry about re-writing NIST into C/Smalltalk/assembly/whatever. cheers, aaron
From alan@lxorguk.ukuu.org.uk Sat, 4 Dec 1999 23:06:40 +0000 (GMT) Date: Sat, 4 Dec 1999 23:06:40 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [Livid-dev] Matrix problems... > After playing around with the NIST code (and making a few optimizations > here and there) I think it might be a step backwards to move back to C. > There's nothing wrong with C++, even for performance critical code, if > it is written properly. As far as C++ code goes, NIST is very clean. Do you plan to post the optimisations ? I started looking at NIST and thinking "C++ overhead". It actually has very little C++ caused overhead. There are some obvious candidates for inlining and removal of code - only allowing stdin not network mode, inlining the getbits function etc. All the real problems in NIST are language independant ones - its too slow handling heavy motion compensation, the audio/video sync model is broken (its also buggy but even if that is fixed its misconceived) and has thread overheads we don't need. I'm tempted to turn it into unthreaded C but that is because I'm happier in C than C++, not for any justifiable performance reason. Alan
From dent@cosy.sbg.ac.at Sat, 4 Dec 1999 18:20:26 +0100 (CET) Date: Sat, 4 Dec 1999 18:20:26 +0100 (CET) From: Thomas 'Dent' Mirlacher dent@cosy.sbg.ac.at Subject: [Livid-dev] Matrix problems... On Sat, 4 Dec 1999, Alan Cox wrote: --snip/snip > I made the same mistake with the Zorro DVD. Its also ILVU's according to your > dvdplay stuff (and with dvdplay 0.2 sort of works - lots of 'wrong number > of macroblocks' and no audio). It is however obviously following the > English language set properly not showing interleaving etc. great to hear that ... i implemted your patches into the new code (well, just the navigator patch) ... decause the decapsulation (and demuxing) should be done by dvdplay) ... but i cleaned the mallocl/memcpy way, and now it should be at least somewhat efficient. (the problem for decapsulation is: i'd also like to use the code for DVB playback - just replacing the DVD code with another .so) ... v0.0.3pre1 will be ready today, so if you're interrested, let me know cheers, and thanks for your help ++dent -- Thomas Mirlacher Student of ComputerScience, University of Salzburg dent@cosy.sbg.ac.at http://www.cosy.sbg.ac.at/~dent
From alan@lxorguk.ukuu.org.uk Sun, 5 Dec 1999 13:01:24 +0000 (GMT) Date: Sun, 5 Dec 1999 13:01:24 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [Livid-dev] Matrix problems... > great to hear that ... i implemted your patches into the new code (well, > just the navigator patch) ... decause the decapsulation (and demuxing) > should be done by dvdplay) ... but i cleaned the mallocl/memcpy way, I still think the demuxing should be done as part of the mpeg parsing. With my current code I don't even have dvdplay as a seperate program. The gui creates the navigator thread and that becomes the top thread of the mpeg2player (ie the demux thread). The network read callback from that calls the code that was DVDLoop directly and the DVD drops buffers directly into the 128K buffer the player uses > (the problem for decapsulation is: i'd also like to use the code for > DVB playback - just replacing the DVD code with another .so) Ok. VideoCD is also on my list, although the really interesting stuff is the new chinese video cd system using VBR MpegII
From dent@cosy.sbg.ac.at Sat, 4 Dec 1999 22:46:21 +0100 (CET) Date: Sat, 4 Dec 1999 22:46:21 +0100 (CET) From: Thomas 'Dent' Mirlacher dent@cosy.sbg.ac.at Subject: [Livid-dev] Matrix problems... On Sun, 5 Dec 1999, Alan Cox wrote: > > great to hear that ... i implemted your patches into the new code (well, > > just the navigator patch) ... decause the decapsulation (and demuxing) > > should be done by dvdplay) ... but i cleaned the mallocl/memcpy way, > > I still think the demuxing should be done as part of the mpeg parsing. With > my current code I don't even have dvdplay as a seperate program. The gui > creates the navigator thread and that becomes the top thread of the > mpeg2player (ie the demux thread). same here. > The network read callback from that calls > the code that was DVDLoop directly and the DVD drops buffers directly into > the 128K buffer the player uses ahm - which player do you use? the new version works like this: gui -> runs as the main thread, and starts nav -> the navigator, is the thread which reads data (in any format, but right now just PS), and drops the CSSdecrypted data into the buffer - probably change this to have encrypted data in buffer and let the decoder do the decryption - since most HW players can do CSS stuff doceder -> this thread reads from the buffer(s) and puts this data into the decoder (eigther hw, or multiple SW decoders, which run as different threads - otherwise i can't handle the load on my dual celeron 433 system) > > (the problem for decapsulation is: i'd also like to use the code for > > DVB playback - just replacing the DVD code with another .so) > > Ok. VideoCD is also on my list, although the really interesting stuff is > the new chinese video cd system using VBR MpegII agreed ... so i hope the decapsulation is flexible enough - or will be flexible enough in the near future to easily add addition decapsulation plugins cheers ++dent -- Thomas Mirlacher Student of ComputerScience, University of Salzburg dent@cosy.sbg.ac.at http://www.cosy.sbg.ac.at/~dent
From alan@lxorguk.ukuu.org.uk Sun, 5 Dec 1999 14:59:33 +0000 (GMT) Date: Sun, 5 Dec 1999 14:59:33 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [Livid-dev] Matrix problems... > > the code that was DVDLoop directly and the DVD drops buffers directly into > > the 128K buffer the player uses > > ahm - which player do you use? mpeg2player. I have it set up using mpeg2player as follows gui - main thread demux - mpeg2player demux calling the UDF/nav functions itself I'm beginning to think that the actual logic isnt quite right. Right now Im losing some stuff because the demuxing part of mpeg2player doesnt ask ahead. I can measure some stall due to the DVD disk fetches, athough its less than the cost of piping it through two processes. Probably the demux needs to fetch more buffers before it empties so that the video thread never stalls. What I am aiming for sounds very like your code otherwise I/O thread continually assures that data is already in the demux buffer. This could merge with the GUI I suspect. decoder thread tries to decode the audio and video directly from the demux ring buffer (no copy) into output ring buffers so that we even out the harder/easier decodes and other machine load playback thread plays video and audio buffers from the decoder ring using audio to clock the video output. It only does playing, no computation so can get accurate timing and could run hard R/T. I have a fair way to go yet. NIST is not architected the way I want 8) Alan
From derek@spider.com Sun, 5 Dec 1999 18:12:03 +0000 Date: Sun, 5 Dec 1999 18:12:03 +0000 From: Derek Fawcus derek@spider.com Subject: [Livid-dev] Matrix problems... On Sun, Dec 05, 1999 at 01:01:24PM +0000, Alan Cox wrote: > > Ok. VideoCD is also on my list, although the really interesting stuff is > the new chinese video cd system using VBR MpegII I had a go at that last weekend, I now have a simple vcd-cat program that can do the same sort of thing as css-cat. Luckily Video CD's are just linear. It'll let you choose a title/track to play from. I can currenly use it to view the three Video CDs I have, however there are some problems. The MPEG-1 system stream sometimes has errors in it - they occasionally pad packs with 0's at the end instead of doing proper pad streams or extra padding bytes (I've dealt with that). The resultant stream confuses mpeg2player - it should cope since MPEG-1 is a subset of MPEG-2, but it dies. I can only get this to work with my IDE CDROM/DVDROM drives. It doesn't work on the SCSI ones. This latter would seem to be a failing of the cdrom drivers. I could add code to simply send raw scsi commands to read the data, but for a quick hack it wasn't worth it. One funny I saw was the sector format. The initial part fo the disk is normal CDROM data (as expected), the later half (holding the video) is in a different sector format (also expected). What is funny is that the video sectors appear to be flagged as XA Mode 2 Form 2, but are laid out as XA Mode 2 Form 1! I've not done much with this since I hacked it together, as I've been working on the X driver instead. Anyway, if anyone wan't this I can post it tomorrow. DF -- Derek Fawcus derek@spider.com Spider Software Ltd. +44 (0) 131 475 7034 PGP/GnuPG Keys available
From jfbeam@bluetopia.net Sun, 5 Dec 1999 15:52:19 -0500 (EST) Date: Sun, 5 Dec 1999 15:52:19 -0500 (EST) From: Ricky Beam jfbeam@bluetopia.net Subject: [Livid-dev] C/C++ (WAS: Matrix problems...)a On Sat, 4 Dec 1999, Stea Greene wrote: >> ... I think it might be a step backwards to move back to C. >> There's nothing wrong with C++, even for performance critical code, if >> it is written properly. (And I'm sure you're convinced Java is just as fast as C or C++?) > This is definitely true. C++ can be written exactly like C and >get the same exact assembly result. Plus the ability to use classes and >other syntactic conveniences makes C++ significantly more readable, >reusable and modifyable. That's called compiling C code with a C++ compiler. Nothing in C++ makes it any more readable than C code. In fact, C++ classes (and inheritance) can render C++ code nearly impossible to follow -- even if you wrote every line of it. C++ doesn't make large code bases (millions of line of code) any easier to handle; it may ultimately reduce some code overlap, but it's still equally difficult to follow, far easier to introduce a bug, and magnitudes more difficult to track down an bug (is it in your code or in the compiler, or both) > The problems come about with the fact that C++ compilers are not >as standard as C compilers, many more things can be implied in C++ code >that can be implemented many different ways by the compiler, and many >simple things in C++ code are not simple in the final binary. No, the real problem is that C++ places most of the intelligence in the compiler instead of the coder. The people writing the compiler has to be 1000's or times more intelligent than the people using the compiler. Yes, C++ is a new thing relative to C. As such, all the functions of the standard are not implemented everywhere nor are the ones that are always correct. Compilers, being programs themselves, have bugs. > As long as you know what your doing, C++ can be better than C in >almost every respect, but when you start using virtual functions, >templates, dynamic variable creation, etc... it can become the slow mess >it has been rumored to be. Translation: as long as you write C code, it'll be just as good as C. If you don't use any of the functions that defines C++ as "better than C", then all you're writing is C code. The instant you start using the functionality of C++ your code becomes a slow, buggy, non-portable mess. (Portablity is very important to me.) --Ricky
From alan@lxorguk.ukuu.org.uk Sun, 5 Dec 1999 20:58:03 +0000 (GMT) Date: Sun, 5 Dec 1999 20:58:03 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [Livid-dev] Matrix problems... > I had a go at that last weekend, I now have a simple vcd-cat program > that can do the same sort of thing as css-cat. Luckily Video CD's are > just linear. It'll let you choose a title/track to play from. Thats VCD 1.0. VCD 2.0 has IFO file stuff, and limited control functions. They are written linear for back compatibility, which is terribly convenient 8). SuperVCD stuff adds mpeg2. > One funny I saw was the sector format. The initial part fo the disk is > normal CDROM data (as expected), the later half (holding the video) is > in a different sector format (also expected). What is funny is that > the video sectors appear to be flagged as XA Mode 2 Form 2, but are laid > out as XA Mode 2 Form 1! Yep. Fun isnt it 8) Alan
From insomnia@core.binghamton.edu Sun, 5 Dec 1999 16:10:25 -0500 (EST) Date: Sun, 5 Dec 1999 16:10:25 -0500 (EST) From: Stea Greene insomnia@core.binghamton.edu Subject: [Livid-dev] C/C++ (WAS: Matrix problems...)a I don't want to start a holy war here, so if you'd like to continue this conversation, please e-mail me privately. On Sun, 5 Dec 1999, Ricky Beam wrote: > That's called compiling C code with a C++ compiler. > Yes. But then you can add a bit more without losing any speed. > Nothing in C++ makes it any more readable than C code. > Except classes, expecially ADTs. Plus C++ typing can be easier to follow. > In fact, C++ classes (and inheritance) can render C++ code nearly > impossible to follow -- even if you wrote every line of it. > I can't argue with you there. Inheritance is a powerful tool for rapid development, and like all powerful tools, you can kill yourself with it too. However a simple class that is not inherited is not hard to follow and is in fact easier to maintain than an equivalent C code-base. > C++ doesn't make large code bases (millions of line of code) any > easier to handle; > Not true. C++ can make a million-line C codebase into a 100-thousand-line C++ codebase, which in-and-of itself makes it easier to follow and maintain. Plus modularity is much easier to keep and read in C++. > it may ultimately reduce some code overlap, but it's still equally > difficult to follow, far easier to introduce a bug, and magnitudes > more difficult to track down an bug (is it in your code or in the > compiler, or both) > This assumes that you are not familiar with C++. If you are equally familiar with C and C++, it is not any harder to find a bug in C++ than C. Inheritance can make things annoying, but the hardest bugs to find by far are pointer bugs, which are the same across the board between both languages (in fact may be harder than C). > No, the real problem is that C++ places most of the intelligence in the > compiler instead of the coder. The people writing the compiler has to > be 1000's or times more intelligent than the people using the compiler. > That's completely untrue. You're thinking of Java perhaps? The C++ compiler is almost as "dumb" as a C compiler. There are features that require more compiler intelligence (most of which I listed below as things to avoid), but for the most part C and C++ are equally implicit languages. > Yes, C++ is a new thing relative to C. As such, all the functions of the > standard are not implemented everywhere nor are the ones that are always > correct. Compilers, being programs themselves, have bugs. > The language for the most part is not overly more complex than C. The complexity (and new-ness) issues come about with the C++ libraries, which can be mostly avoided anyway by coding C++ in C style. Honestly anyone who thinks IOSTREAM is a good thing should be shot. > > As long as you know what your doing, C++ can be better than C in > >almost every respect, but when you start using virtual functions, > >templates, dynamic variable creation, etc... it can become the slow mess > >it has been rumored to be. > > Translation: as long as you write C code, it'll be just as good as C. > No. Translation: as long as you write C++ like a good C programmer, it'll be better than C. > If you don't use any of the functions that defines C++ as "better than C", > then all you're writing is C code. The instant you start using the > functionality of C++ your code becomes a slow, buggy, non-portable mess. > (Portablity is very important to me.) > I agree, but I have yet to find a machine that can compile C, but can't compile gcc. And if it can compile gcc, it can use all the C++ features I use. --Insomnia (Stea Greene)
From dent@cosy.sbg.ac.at Sun, 5 Dec 1999 06:00:38 +0100 (CET) Date: Sun, 5 Dec 1999 06:00:38 +0100 (CET) From: Thomas 'Dent' Mirlacher dent@cosy.sbg.ac.at Subject: [Livid-dev] there is no matrix problem - but a C/C++ war On Sun, 5 Dec 1999, Stea Greene wrote: > > I don't want to start a holy war here, so if you'd like to > continue this conversation, please e-mail me privately. PLEASE, guys ... the line above says it all ... stop the holy war here, go play in another corner, or just make some productive comments, or patches (no offense). everything said ++dent -- Thomas Mirlacher Student of ComputerScience, University of Salzburg dent@cosy.sbg.ac.at http://www.cosy.sbg.ac.at/~dent
From alan@lxorguk.ukuu.org.uk Sun, 5 Dec 1999 21:28:41 +0000 (GMT) Date: Sun, 5 Dec 1999 21:28:41 +0000 (GMT) From: Alan Cox alan@lxorguk.ukuu.org.uk Subject: [Livid-dev] Matrix problems... General comment here I think: If you want to get this stuff into C, do it. I know kernels, I know memory bandwidths, cache footprints but not video codecs. People turning the mpeg2video modules and the buffer module into C would really help me here Alan
From sct@redhat.com Tue, 7 Dec 1999 11:23:32 +0000 (GMT) Date: Tue, 7 Dec 1999 11:23:32 +0000 (GMT) From: Stephen C. Tweedie sct@redhat.com Subject: [Livid-dev] Matrix problems... Hi, On Sun, 5 Dec 1999 14:59:33 +0000 (GMT), Alan Cox < alan@lxorguk.ukuu.org.uk> said: > I'm beginning to think that the actual logic isnt quite right. Right now Im > losing some stuff because the demuxing part of mpeg2player doesnt ask ahead. > I can measure some stall due to the DVD disk fetches, athough its less than > the cost of piping it through two processes. Yep. If you're doing this over raw IO, then right now the only way to get real streaming performance is to do the read IOs in 64k blocks or less, and to use multiple threads to do the blocking IO so that you can achieve effective async readahead. --Stephen