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: <1991Apr20.210243.22134@mintaka.lcs.mit.edu>
Sender: news@mintaka.lcs.mit.edu
Organization: The Internet
References: <1991Apr16.071344.20589@ncsu.edu> <1991Apr16.154153.11706@mintaka.lcs.mit.edu> <1991Apr20.131149.28247@ncsu.edu>
Date: Sat, 20 Apr 91 21:02:43 GMT
Lines: 99

In article <1991Apr20.131149.28247@ncsu.edu> kdarling@hobbes.catt.ncsu.edu (Kevin Darling) writes:
>[ Sorry for reply delay.  In the interest of reader sanity, I'll answer
>his message in two articles.  First, video modes:  Later, tech details. ]
>
>In <1991Apr16.154153.11706@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes:
>
>> 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 [invalid] or full screen cartoons?
>
>>>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. 
>
>One of the advantages of CDROM _is_ that many images can be on disc.  It's
>expected that both systems will try to take advantage of this when able to.

  Yes, I agree, but there are some times when image manipulation techniques
are still needed. Especially with games, you need to be able to move
lots of objects around the screen in different motion paths over who
knows how many backgrounds. Even dual playfields don't help.

>Given the RLE example, the cpu can easily be handling user interface details
>_while_ the animated data comes off disc, with minimal cpu time wasted on the
>animation.  With the CD-I dual video playfields, this is in fact should be
>incredibly easier to accomplish.
>
>But no, obviously you wouldn't use RLE in a video paint program (altho I can
>think of ways to do it... not much worse than doing the same in CDTV HAM).
>You'd use the 16 or 128 or 256 color modes instead, don't you agree?

   How are the non-RLE modes store on disk then?

>Those blitter assumptions will be handled in a later article.
>
>> 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.
>
>JPEG is meant for stills (altho some Apple/IBM types use it temporarily for
>motion).  MPEG is the one you meant, and is what will be used by players later
>(both players, we would assume).

(actually, I meant JPEG, for one reason. JPEG chips have already been
fabricated, I have no idea how long it will take for C-cube to design and
produce an MPEG chip.)

>BTW, neither CDTV nor CD-I are claiming fullscreen/motion video yet.  (Where
>_do_ you get your information?  Certainly not from any of my messages.)
>Sure, Philips had intended to include it in the first CD-I consumer players,
>but the MPEG standard wasn't finished until just this year (video in September,
>audio in December), and quantity chip output will take a while to come.

   I meantioned awhile ago 'I don't think CD-I has solved the
full motion full screen video problem yet.' and someone said 
'Wrong, CD-I now boasts full screen video.'

>> 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. 
>
>Uhh,  why do you think both players will be so affordable?  That's right:
>cheap and proven CDROM technology.  In addition, it was expected that MPEG
>would've been finished far sooner than it was.  Not their fault.

  Why has it taken 5 years for CD-I to finally come near release? Look
how fast C= threw CDTV together and got it to market. Actually before
I heard about CDTV, I wanted CD-I above anything else (especially
above Intel's DVI, or MPC) but I had assumed CD-I would eventually be
30fps TV quality video, then I heard about CD-I's problems with
full motion video and stopped following it. 

>I do agree with you that it would be nice to see faster CDROM drives/etc.
>Ummmm.  So then why did CBM bring out CDTV so prematurely?

  I don't know if C='s goals were the same as those originally announced
by the CD-I consortium. Also, bring out CDTV first gets them a head
start. Just imagine if CD-I came out first? CDTV wouldn't have a chance.

>PS: I'll ask a favor now, if you can take a deep breath and grant it <g>...
>stay away from blitter topics until I can finish and post an article on that
>subject.  I think that's fair.  thanks!  - kevin <kdarling@catt.ncsu.edu>

 Ok.


--
/ INET:rjc@gnu.ai.mit.edu     *   // The opinions expressed here do not      \
| INET:r_cromwe@upr2.clu.net  | \X/  in any way reflect the views of my self.|
\ UUCP:uunet!tnc!m0023        *                                              /

