A 3DO application has to work within the limitations of available memory and maximum data rate. Therefore, it is important to analyze data and to set clear goals early to have smooth playback later on. For example, for background music during an introduction, you'll want to use CD-quality stereo, while sound files that consist only of people talking can be highly compressed and lower quality. Data preparation can proceed once those decisions are made.
Note: Be sure to analyze your data carefully and set your priorities. Some developers have processed all data twice because they made a wrong decision about optimal delivery early in their development cycle.
This section first looks at the limitations of the hardware, then at some trade-offs you have to make when designing your application.
System resource limitations
Consider the availability of system resources when preparing a stream file.
I/O bandwidth-What percentage of available I/O bandwidth does your stream consume? In the case of the 3DO double-speed CD-ROM drive, a stream can never exceed an average data rate of 300 kilobytes per second.
Other resources-Availability of DSP (digital signal processing) resources for sound and CPU cycles for image and video decompression can constrain playback.
An application using streaming must live by the following rule: The sum of the data rates of each of the elements of the stream cannot exceed the data rate of the input device.
As you approach the limits for bandwidth and other system resources of the device from which data is being acquired, creating a working stream becomes a balancing act.
For example, in a typical audio/video playback application, video playback might run at 220 KB/s. Audio playback might run at 44 KB/s. Therefore, the total bandwidth required is at least 264 KB/s. Consequently, processing and overhead cannot exceed 36 KB/s (300-264 KB/s). All the filler and chunk information, plus disc seek times, must be processed within this 36 KB/s window.
This section discusses issues you need to consider when preparing video and audio for your 3DO application.
Audio
Audio compression-To stream CD-quality audio, you need 176 KB/ s. Using mono instead of stereo halves the data you need to stream, 2:1 compression halves again. See "Compressing data" for more information.
Video
Size of video-It's not possible to deliver full-screen software-compressed video with CD-quality audio at full frame rate. You can use a lower frame rate or a smaller frame size. Note that the video may still look full-screen on many monitors if you reduce it. Reduce frame size to 288 x 216 to still be title safe, that is, have video that does not show borders on any NTSC monitor.
Compression and delivery- To get high-quality software-compressed video, you have to devote as much processing power as possible to the video, since it has to be read and decompressed.
If the size of your video elements is small and/or their visual quality is a priority, use streamed cels. If streamed cels seem a good choice but the size is not small enough, you can still achieve high visual quality at the cost of a lower frame rate.
Starting with Toolkit 1.5, more than one software compression algorithm will be available. Hardware compression is also expected in the near future. See the 3DO Release Notes for more information.
Branching- If you allow user interaction:
Make sure you have key frames at branching points. To find out where key frames are located, look by at the output of the dumpstream utility.
If you need to branch frequently, use smaller buffers, at the cost of a lower rate of throughput. Buffer size should be between 32 KB and 128 KB and must be a multiple of 2 KB. Larger buffers result in a lower amount of filler.
Buffer allocation-You can't read new data until each chunk in a stream block has been used. If you have data you need to use over a long period, this can cause problems. For example, you may have cels that change rarely on top of a video that changes frequently. If you interleave the video with the cel, you can't reuse the video until the cel is no longer in use. The way around this is using the Join subscriber to pull data out of the stream buffer or to assign a large number of buffers.
Data rate issues-To achieve smooth streaming, look at the data rate for each chunk before weaving. If you add up the rates and they don't exceed
300 KB/s, weave the stream and look at the data rate again. To look at the stream file, use dumpstream or the ChunkMatcher tool in the Attic folder.
Note that it may be acceptable to have a rate slightly above 300 KB/s for brief periods of time. The DataStreamer can usually compensate for such a data rate spike. Having a data rate that's consistently higher than 300 KB/s will, however, cause problems.