Newsgroups: comp.sys.amiga.advocacy Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!geech.gnu.ai.mit.edu!rjc From: rjc@geech.gnu.ai.mit.edu (Ray Cromwell) Subject: Re: CDTV, CD-I, DCTV, etc Message-ID: <1991Apr16.154153.11706@mintaka.lcs.mit.edu> Sender: news@mintaka.lcs.mit.edu Organization: The Internet References: <1991Apr16.071344.20589@ncsu.edu> Date: Tue, 16 Apr 91 15:41:53 GMT Lines: 100 In article <1991Apr16.071344.20589@ncsu.edu> kdarling@hobbes.catt.ncsu.edu (Kevin Darling) writes: >> DCTV will work with CDTV, however since Commodore hasn't licensed it >> for CDTV as default, it won't really be used much. > >Uh, then why bring it up? :-) No problem, I'll just bring up that Philips >promises to supply fullscreen/fullmotion adapters to all original CD-I players, >and you can tell me that it doesn't matter, either. Fair? Obviously both >players will be upgraded over time; but we're only talking base hardware here. I thought you already knew DCTV wasn't a part of CDTV. I brought it up to show that CD-I's "impressive" video isn't unique since both DCTV and The Toaster display NTSC composite images. DCTV uses the same encoding as CD-I. DCTV costs $495 list and comes with a digitizer. >Anyway, still looking for hard DCTV tech info. Any recent articles >in the magazines? Perhaps a technical BBS? Thanks! > >> One thing I don't understand is why CD-I chose RLE compression >> for their images. RLE isn't a very good compression technique. It works >> best on line art, not raw digitized picturres. > >You're confusing file storage with video hardware here. Regular video data >would be stored/compressed just like any computer. But you're right, RLE >is _best_ for such things as cartoons. Which is why realtime non-cpu-assisted >RLE display was included as one of many video modes in CD-I. It can give >an author some powerful animation playback and storage benefits. Why bring RLE up if it can only be used for line art animation? What would you rather have, 1/4 screen 15fps HAM or DYUV(DCTV) or full screen cartoons? What I want to know is, what is CD-I's playback rate for FULL COLOR FULL SCREEN digitized data? Assuming a CDROM drive can deliver 170k/sec reliably and the average compressed frame (RLE/vertical byte run, etc) is 30k (generous) it looks like 5-8 frames per second. I still can't believe they are getting 15-24fps full screen with only a 170k/s xfer rate. >Let's take the simplest example: a fullscreen American flag on a black field. >CD-I would only use a _few hundred bytes of memory_ to perfectly display it. >On a normal (read: Amiga) display, you will always need to take up & move at >least _16K_ because the video hardware demands each pixel be explicitly there! >(note to CBM hardware crew: please add this mode to your chip wishlist :-). Yes but on the normal Amiga you can move objects and draw lines and perform manipulations on the flag in real time. How do you render pixels into compressed RLE pics? Probably uncompress it, render, and recompress. CD-I is starting to look cheesy compared to CDTV. >Want to ripple the flag a bit? CDTV = intense cpu/blitter action, or costly >multiple screens already in memory. CD-I = flip display pointer to another >_tiny_ section of RLE memory data... under copper control alone if wished. >The memory and cpu savings can be almost beyond calculation. Yes, but the images must be _canned_ ahead of time on the disk. What about providing a nice windowed/gadget interface with animated video interacting to the user. Canned video is nice, but what a video paint program, or a multimedia authoring disc? Even a 14mhz 68000 can't handle the blitter's speed. So how does CD-I manipulate images with the programmer producing Canned images for all possibilities. >Think of the game/playback possibilities here, remembering also that the CD-I >dual playfield you so casually dismiss means that 128-color RLE animation can >go on top of a photographic background which _itself_ can be animated easily >since the cpu isn't involved in decoding one field's data in the first place. But games need to MOVE different display objects around the screen in response to user input. You can't just have precomputed images on the disk for every object position. With the method you suggest, the only kind of games you could produce are Dragon's Lair look alikes. >Am I explaining this badly, or ?? It's actually pretty simple and cool. > ready to help - kevin Yes. I don't understand how CD-I gets full screen full motion full color photographic quality video with just RLE compression and 170k/s xfer rate. Not all data can be compressed. With C-Cube's JPEG compression chip and a fairly fast HD you can do real time animation from a harddrive with 25:1 compression. Why didn't CD-I use this. I envision CD-I software consisting mainly of line-art data. If a programmer has to use photographic non compressible data, he will remove lots of data from the picture to make it smaller and more compressible. For CD-I to achieve atleast 15fps, it needs to compress frames down to 10k. For frame to frame compression on data that doesn't change too fast (a still picture with small object moving in the foreground) this might be possible, but I can imagine CD-I slowing down real quick on real world data. The CD-I consortium should have invested in improving CDROM technology and making it cheap, instead of trying to kludge I-TV on top of such a low bandwidth device. CD-I is not as technically superior to CDTV as you think. So as far as CD-I goes, I'll believe it when I see it. The claims of under $1000 full motion full screen video don't seem real. -- +-----------------------------------------------------------------------------+ | rjc@gnu.ai.mit.edu | // The opinions expressed here do not in any way | | uunet!tnc!m0023 | \X/ reflect the views of my self. | +-----------------------------------------------------------------------------+