Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!nimbus3!djs
From: djs@nimbus3.uucp (Doug)
Newsgroups: comp.graphics
Subject: Re: Request info on DCT based compresseion/decompression
Message-ID: <1990Aug17.210410.28762@nimbus3.uucp>
Date: 17 Aug 90 21:04:10 GMT
References: <1233@swan.ulowell.edu>
Reply-To: djs@nimbus3.UUCP (Doug)
Organization: AGS Information Services, Inc.
Lines: 23

In article <1233@swan.ulowell.edu> ksakotai@hawk.ulowell.edu (Krishnan "krish" Sakotai) writes:
>
>I have been following the discussions on the net reg JPEG standard for data
>compression/decompression. 

I have also been following the discussion and have a few questions (I did
try to look up the article in IEEE without success).

My understanding is that the JPEG compression algorithm is for still pictures
and that the motion-picture compression algorithm was being developed by
MPEG but would not be available for a year or two.  Yet the chip from C-cube
says that they achieve 40 fold compression on frame to frame.  If this is
true, what algorithm are they using for the frame to frame compression?

Second, if much of the compression is from frame to frame redundancy, what
happens in multi-media applications that want to jump around to various
points in time?  Does that mean that after it first jumps to a new time
point the display will be blury because it doesn't have the previous 
information or do they jump to some time before the desired point to
get the previous information?

-- 
Doug Scofea   Email: nimbus3!djs@cis.ohio-state.edu    Phone:+1 614 459-1889