From owner-freebsd-isp  Wed Nov 13 12:11:56 1996
Return-Path: owner-isp
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id MAA11536
          for isp-outgoing; Wed, 13 Nov 1996 12:11:56 -0800 (PST)
Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA11531
          for <isp@FreeBSD.ORG>; Wed, 13 Nov 1996 12:11:50 -0800 (PST)
Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id OAA23742; Wed, 13 Nov 1996 14:09:52 -0600
From: Joe Greco <jgreco@brasil.moneng.mei.com>
Message-Id: <199611132009.OAA23742@brasil.moneng.mei.com>
Subject: Re: bang bang bang bang - lame lame lame lame
To: jkh@time.cdrom.com (Jordan K. Hubbard)
Date: Wed, 13 Nov 1996 14:09:51 -0600 (CST)
Cc: jsuter@intrastar.net, isp@FreeBSD.ORG
In-Reply-To: <7306.847915087@time.cdrom.com> from "Jordan K. Hubbard" at Nov 13, 96 11:58:07 am
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: owner-isp@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > To decode it in real time, however, and display it, would probably
> > require a very very fast machine...
> 
> Naw, just some dedicated hardware.  My CD-I will do real-time MPEG
> decoding and it simply requires a module in the back which contains 2
> motorola DSPs.  Picture quality is excellent, *depending on how well
> the source was compressed*.  Apparently it costs a bit more to do it
> right and takes more computational time, but when that's the case the
> visual quality is (to my novice eyes, anyway) indistinguishable from
> an SVHS tape when played on my Sony 27" multisystem TV.  On some of my
> earlier CD-I movies you can occasionally see jaggies, but even so
> you've got to be looking for them.

Hi Jordan,

I must confess that I have not been following the technology that
closely, but I was wondering what the resolution is.

The last I heard, most "real time MPEG" stuff worked at standard TV
resolutions (or only mildly better) and was pricey as all heck.

Since computational time should be proportional to the resolution of the
display, it should be much easier to do a 320 * 200 display (64000 pixels,
and at 16 bit depth that's 128Kbytes of data) as opposed to a 1024 * 768
display (786432 pixels, and at 24 bit depth that's 2.4Mbytes of data).

Tossing the latter amount of data around a machine at a frame rate of 30
per second would require a pretty fast system...  and I am skeptical that
there is anything commercially available that is fast enough...  but I 
would certainly agree that the lower resolutions are probably "practical 
and affordable" these days.

I would be pleased to discover I am wrong  ;-)

... JG