Xref: utzoo rec.video:13792 comp.misc:9698 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!pacbell.com!decwrl!bacchus.pa.dec.com!granite.pa.dec.com!mwm From: mwm@raven.pa.dec.com (Mike (Real Amigas have keyboard garages) Meyer) Newsgroups: rec.video,comp.misc Subject: Re: Video and computer memory Message-ID: Date: 31 Jul 90 22:25:26 GMT References: <29@meme.stanford.edu> <1990Jul31.204803.25358@eng.umd.edu> Sender: news@wrl.dec.com (News) Organization: Missionaria Phonibalonica Lines: 34 In-Reply-To: naiming@eng.umd.edu's message of 31 Jul 90 20:48:03 GMT In article <1990Jul31.204803.25358@eng.umd.edu> naiming@eng.umd.edu (Naiming Shen) writes: You even have trouble to put one second of video into memory. the X is about 300-600 and Y is 525. Assume you digitize it with 8 bits per pixel. You have: 400*525 X 30 = 6.3 M Bytes per second. The referenced article is no longer around, and the relevant information wasn't quoted. However, for the purpose of playing video back, you don't store animations raw like that (not if you know what you're doing, anyway). You store full frames only on "scene" changes, and delta lists for the frames between those shots. You double buffer things, so you can build the next image while the user is viewing the current one (that's a _long_ 1/30th of a second). With display hardware that makes changing buffers a matter of updating a pointer, even something as slow as a 68020 at 16Mhz can run 30 frames a second (methinks a 68000 @ 8MHz can do the same, but I'm not positive). If you do things right, you only need memory for two full screens (<.5Meg for both) plus deltas (variable size, but normally small for each frame) plus software (depends). The net result is that a relatively old personal computer with 2 to 4 meg of RAM can handle a seconds worth of video, and then some.