Multimedia Operating Systems ●File System Paradigms ●File Replacement ●Caching ●Disk

Traditional File Systems Accessing Files –A process issues an “open” system call –The caller receives a Token Unix: File Descriptor Windows: handle –The process issues a “read” call Providing the buffer address and byte count as parameters –The operating system returns the requested data This Paradigm will not work for Multimedia File Systems

Multimedia File Systems Real-Time behavior –Unplanned Requests –Resource Allocation VCR Paradigm – A multimedia file server will act like a traditional VCR –Steps A user process issues a “start” system call specifying the file to be read Then the server sends out frames in blocks – 2 Server Types Push Server Pull Server

–The user pulls data from the server one block at a time –A block is not sent until there is a request for one; and there is no request until the current block is finished sending. Push Server –The server pushes data to the user –The user must handle at the received rate

Controlling Multimedia Most video servers implement basic VCR controls –Pause : When the server receives a pause message, it simply stops the video at the current frame, and will resume the video at that frame when it receives a message to play. – True Rewind : The server will set the next frame to be “0” – Fast Forward and Fast Backward (Rewind) Theoretically simple – To run at K speed, display every K-th frame until normal speed is resumed Compression Issues

Compression Camcorders/ DV Tapes –Each frame is independently compressed Depending on the content in that frame –Images, text, audio –Frame Indexing In order to Fast Forward; an indexed list of each frame must be kept because each frame will be a different size MPEG –MPEG works with I, P, and B frames The video can only be started at an I Frame Need separate file for Fast Forward or Backwarding

Near Video on Demand Video on Demand –Private Stream –VCR Controls Near Video on Demand –Public Stream –No VCR controls Near VOD with VCR Controls –Switching from public streams to private stream with VCR controls

Near Video on Demand

Near VOD with VCR Functions

File Placement Placing Files on a Single Disk Two Alternative File Organization Strategies Placing Files for Near Video on Demand Placing Multiple Files on a Single Disk Placing Files on Multiple Disks

Placing a File on a Single Disk Data should be streamed to a network or output device at required speed & without jitter Thus, multiple seeks are undesirable Contiguous files are a handy fix. Usually an issue, on a video server that is preloaded with set movies it can work.

Simultaneous audio, text, and vidoe can be an issue. The fix is to link the components to contiguous single frames Random access is impossible, but if it is not needed loss is not serious. The benefits of this are lost on a video server with multiple concurrent outputs Not useful when movies are being written as well as being read.

Alternative File Org. Strategies Small Block - A data structure where each frame points to the start of a frame. Each frame holds all the video, audio, and text tracks as a contiguous run of disk blocks. Reading frame k consists of indexing into the frame index to find the k-th entry and reading the entire frame in one disk operation The frame size is needed in the frame index, but with 1-KB disk blocks, an 8-bit field can handle a frame up to 255KB

cont. Large Block- Large disk blocks put multiple frames in each block. Index is now of blocks instead of frames Each block can be left empty when the next frame does not fit the remaining space in the block, or split over two blocks. The first eliminates the need to seek in the middle of a frame. Having seeks in the middle of a frame can hurt performance, but save on disk space by eliminating internal fragmentation.

Trade-offs of the Three 1.Frame Index: Heavier RAM usage while movie is player; little disk wastage. 2.Block Index(no splitting frames): Low RAM usage; major disk wastage. 3.Block Index(splitting frames): Low RAM usage; no disk wastage; extra seeks.

Placing Files for Near VoD Optimal Frame Placement for near VoD Frame sets of 24 frames are concatenated and written to disk as a single record. Satisfies all 24 streams with only one seek (to frame zero)

Placing Multiple Files on a Single Disk To solve for multiple videos on the same server, we use Zipf’s Law. Video.

With Zipf’s Law it becomes easier to model the performance of a server and create strategies to place files. Organ Pipe Algorithm. Most frequent in center, lesser frequencies branching off. Works best if each movie is a contiguous file. This way the disk head will remain in the cylinder allocated to top movies most of the time.

Placing Files on Multiple Disks For higher performance, video servers have many disks that can run in parallel. Is easy to implement however if one disk fails, all movies on it become unavailable. How do the movies get placed on disks?

Striping No Striping (a): Popular disks would see more usage than others, system isn’t fully utilized. Same Striping (b): Balances all films across the available disks, but they all start on the first disk, so the load may not be balanced. Staggered Striping (c): Spreads the load much better than previous solutions Random Striping (d): As above. This system can now issue requests for multiple blocks at once for the same movie. These requests can proceed in parallel. Once complete, it can transmit to the user. Wide and narrow striping. Wide balances well, but risks every movie going down. Narrow doesn’t have that issue, as it spreads movies across a few disks instead of all of them.

Caching with Multimedia

Traditional Caching ? Traditional caching doesn’t make sense with multimedia User unlikely to rewind the video clip

Utilizing Caching Differently Exploit the predictability of multimedia Only cache video that has multiple viewers - ex: Two people watching the same movie, but one viewer is two seconds behind. Cache the first viewers video for the second viewer

Alternative Technique Instead of just caching the video, you can merge the streams to be in sync Slow down the first users frame rate Speed up the second users frame rate Users should not even notice that anything is happening

File Caching Cache the first few minutes of popular videos When a user accesses a movie, retrieve the rest of the movie from the disk while they are watching the cached portion

Disk Scheduling for Multimedia Static disk scheduling Rounds Double Buffering Dynamic Disk Scheduling Scan-EDF algorithm

Static Disk Scheduling Main property is that it utilizes predictability Does this through read ahead for each open file Divides time into rounds

Rounds A round is the frame time 33.3 msec for NTSC 40 msec for PAL One disk request is generated for each user at the start of each round. Requests sorted and processed in optimal order.

Double Buffering To keep data flowing smoothly double buffering is required in the server. One set of buffers is used during round 1 When this round is finished, the output is unblocked and frame 1 is transmitted. Simultaneously as requests for frame 2 come in, a second set of buffers processes this request as the first set is in use. When the request for round 3 comes in, the 1st is now free and can process this request.

Dynamic Disk Scheduling Not all stream output at the same resolution and framerate. Therefore it is not possible to have a fixed “1 round every 33.3 msec and have 1:1 frame to stream. Dynamic Disk Scheduling is useful when requests come in at random

How it Works When the system starts, no requests are pending. The first request is serviced immediately Further pending requests are selected by two factors deadlines cylinders These are taken into consideration and combined to make the scan-EDF algorithm

Scan-EDF algorithm Groups requests whose deadlines are close and processes them in cylinder order. See diagram

Scan EDF

Scan EDF combines the advantages of the scan algorithm (seek optimization) with EDF (real time) Requests with earlier deadlines are served first Requests with the same deadline are served by their track location

Issue When multiple streams have multiple data rates a problem arises. There are basically 2 ways to calculate if the data is allowed. Assume each stream needs a certain amount of resources and check if there's enough left for another. Check the specific stream against the data rate. If the server has enough capacity then it is allowed.