To implement a codec that supports VCR-like interactive features, the codec needs a cache manager that is able to buffer large amount of data and supplies data to the decoder in real-time. A naive approach is buying a lot of memory. However, since the memory requirement can be huge (described shortly), this main-memory-only buffering approach may be cost prohibitive. For instance, asking consumer to pay $1,000 to buy a set-up box can be a tough sell.
The alternative is using a memory-disk integrated cache (MEDIC). Since the per-byte disk cost is about one hundredth of the per-byte memory cost, MEDIC is economically attractive. To examine the need for MEDIC, we address two questions:
The answer to the first question is fairly obvious: a client cache is needed as a cushion against variability in the data delivery rate, and against differences in delivery and consumption rates. If one assumes that the media server always pumps out the data at precisely the rate it will be consumed by the client, and one assumes a perfect network, which can deliver the data at this same rate, then one does not need a buffer at the client. However, the server and network may deliver data at a rate different from that at which data is consumed, and the rate may not be constant, due to network disturbances, traffic congestion, router failures, server glitches, and so on.
A large cache at the client site may enable an array of client applications. A cache can be made larger at low cost by adding disk storage, and hence the usefulness of a disk cache. A large cache gives clients the flexibility to receive much more data than it consumes. For instance, video panorama may require eight-channel data delivery at high rates but decodes, stitches, and displays only the frames that the user views. These applications can easily require gegabytes of buffering space. A large client cache also gives the server more delivery flexibility. For instance, the server can speed up data delivery when the channel is free, anticipating the peak hours are arriving. Also, when a VCR-like function. e.g., a pause or replay command, is initiated by the viewer, the client can continue receiving bits into its local disk without disrupting the server. Without client assistance, these operations either cannot be implemented (in the broadcast case) or prolong playback time and hence significantly decrease server throughput (in the point-to-point transmission case).
Special Help Needed from Milton: Need to be able to find out the starting/ending address of the decoder buffer and the next byte of data the decoder is going to read. Need to be able to write to the decoder buffer (I suppose this is already allowed.)
Hardware: PC/Pentium II and ATI 3D Rage Pro (DirectX).
Software: VC++, MFC, DirectDraw, etc.