Re: QuickTime GS movie of jet fighter uploaded to ground

[CUTjefbla@bconnex.net (Jeff Blakeney)]

On 27 Mar 1998 19:43 -0500, spec@vax2.concordia.ca (Mitchell Spector)
wrote:

>    Writing a program to separate QT/AVI frames and convert
>them into APF and then into PaintWorks format (either in 1
>or 2 steps) should be doable. The only catch how large just
>the movie alone becomes (nevermind sound). I suppose you
>could also write a PaintWorks $C2 player that could play
>the frames as it reads it, but you'd need a very fast SCSI
>interface and hardrive to keep it from getting choppy.

Well, if I remember correctly, a Paintworks animation just saves the
changes to a screen for each frame and not the entire screen of each
frame.  This would mean that you would be loading less that 32k per
frame which would make things happier.  If you were to cache the video
data things would improve but I'm not sure exactly how someone would
do this.

I don't think even an Apple High Speed SCSI card could handle viewing
from disk if full screens are saved for each frame.  This would
require moving 960 kb of data each second for 30 frames per second
video.  You still need to display the 30 frames during all this disk
access as well which includes changing colour palettes if you need to.

If you were to drop to 20 - 24 frames per second, which is the maximum
that the human eye can see, you would drop the size of the data to be
transfered to 640 kb - 768 kb per second which gives a little more
room to play with.

If you only had to update the changed portions of the screen, you
would end up having to transfer less data than the figures stated
above which would give another speed boost.  If the data could be
compressed on disk and decompressed quickly enough, which would
probably require a math co-processor, it would help a great deal as
well.

Another way to save loads of data is to reduce the size of the video
to use less than a screen.  If you take a 320x200 animation and reduce
it to 160x100 then you just reduced the size of the data for each
frame by 75%.  This means you would only need to transfer
approximately 240 kb per second at 30 frames per second and only 120
kb per second at 15 frames per second.

A conversion program could allow setting the output frame size to
whatever was desired which would allow reducing large videos, like
640x480, to a smaller resolution as well as enlarging small videos,
like 160x120 to a larger resolution.  This could also help fix aspect
ratios and such by changing the resolution of a 320x240 video, which
won't fit nicely on a 320x200 SHR screen, to a resolution of 266x200.

So far, this does not include any sound but a mono, 8 bit sound takes
up about 86 kb per second so we could probably squeeze it in if we use
the lower frame rates.

So it would seem that it would be possible but would take a fast
machine with a fast SCSI card and hard drive to handle it.  Mind you,
I have seen a lot of video clips on the net that only use 15 frames
per second to reduce file size and these would only require 480 kb of
video plus the 86 kb of audio which could be handled by more machines.
The 30 frame per second videos could even be converted to lower frame
rates by a conversion program.

By the way, the Apple video demonstration using the Apple High Speed
SCSI card used some special feature of the card or read the raw data
sequentially from the hard drive to achieve its 31 frame per second
rate using gray scale images.

Oh, and Mitchel, if you want convert QuickTime movies using your
current method, you should be able to find a program that will convert
QuickTime, and possibly other video formats, to AVI so that you can
use that program you found to convert them to GIFs.

=== I've had enough SPAM.  Cut the obvious from my address to email me. ===