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? <g>  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 <kdarling@catt.ncsu.edu>

  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.                  |
+-----------------------------------------------------------------------------+
