CS 414 – Multimedia Systems Design Lecture 28 – Media Server (Part 4)AdministrativeAdministrativeSome FactsOutlineMultimedia File SystemsPlacement of Mapping TablesIndexing and FATConstant and Real-time Retrieval of MM DataFast Forward and Rewind (Implementation)Block Size Issues in File OrganizationBlock Size IssuesTradeoffsEfficient VOD Service TechniquesConclusionCS 414 - Spring 2011CS 414 – Multimedia Systems Design Lecture 28 – Media Server (Part 4) Klara NahrstedtSpring 2011AdministrativeMP3 has Two options of MP3Option 1 – 2-way video chat: Linux – Android (eligible for competition)Option 2 – 3-way video conference: Linux-LinuxYou should decide on one option (either option 1 or option 2)!!!April 29, 5-7pm, Google Competition for Option 1 solutionsCompetition with judges via demos in SC 216Finalists will demonstration to judges between 5-7pm, April 29Finalists will prepare 5 minutes power point presentation April 27, 7-9pm, Preview of the MP3 statusWednesday, April 27, 7-9pm via demos in SC 216 in front of Prof. Nahrstedt and TA ShuAll groups show their status Decision on which groups with option 1 will go towards Google competition CS 414 - Spring 2011Administrative MP3 has April 29, Demonstration of projects (except of finalists)Demos for grade between 2-4:30pm in SC 216 to Prof. Nahrstedt and TA Shu ShiSign-up sheet for demonstrations Provided in class during week of April 22. April 29, midnight, code submission via compass More details about competition, and others will be posted one week prior to competitionCS 414 - Spring 2011Some FactsFlickr – image and video hosting websiteIn September 2010, Fickr hosted more than 5 billion imagesDeveloped by Ludicorp, Vancouver, 2004, now owned by Yahoo!In August 2009, Flickr hosted 62 databases across 124 serversCS 414 - Spring 2011Outline Multimedia File System File allocation tables/Index tablesAdditional File System OperationsBlock sizesEfficient Video-on-Demand Service TechniquesCachingPatchingBatchingCS 414 - Spring 2011Multimedia File SystemsReal-time CharacteristicsRead operation must be executed before well-defined deadline with small jitterAdditional buffers smooth dataFile SizeCan be very large even those compressedFiles larger than 232 bytes Multiple Correlated Data StreamsRetrieval of a movie requires processing and synch of audio and video streams CS 414 - Spring 2011Placement of Mapping Tables Fundamental Issue: keep track of which disk blocks belong to each file (I-nodes in UNIX)For continuous files/contiguous placementdon’t need mapsFor scattered files Need maps Linked lists (inefficient for multimedia files)File allocation tables (FAT) CS 414 - Spring 2011Indexing and FATCS 414 - Spring 2011I FrameHigher Level Index TablePer FileP FrameB Frame P FrameBlock I1 Location PTRBlock I2 Location PTRBlock I3 Location PTRBlock P11 Location PTRBlock P12 Location PTRBlock B1 Location PTRBlock P21 Location PTRBlock P22 Location PTRFile Allocation Table………..…………..Constant and Real-time Retrieval of MM DataRetrieve index in real-timeRetrieve block information from FATRetrieve data from disk in real-time Real-time playback Implement linked listRandom seek (Fast Forward, Rewind) Implement indexingMM File Maps include metadata about MM objects: creator of video, sync infoCS 414 - Spring 2011Fast Forward and Rewind(Implementation) Play back media at higher rateNot practical solutionContinue playback at normal rate, but skip framesDefine skip steps, e.g. skip every 3rd, or 5th frameBe careful about interdependencies within MPEG framesApproaches for FF: Create a separate and highly compressed fileCategorize each frame as relevant or irrelevantIntelligent arrangement of blocks for FFCS 414 - Spring 2011Block Size Issues in File Organization Small Block Sizes Use smaller block sizes, smaller than average frame sizeOrganization Strategy: Constant Time LengthNeed Metadata structure, called Frame IndexFrame means a time frame within a movie Under the time frame read all blocks (audio, video, text) belonging to this time frameCS 414 - Spring 2011A VV TFrameindexMovieTimelineA VV T………VAVBlock Size IssuesLarge Block SizeUse large blocks (e.g., 256 KB) which include multiple audio/video/text framesOrganization Strategy: Constant Data LengthNeed Metadata structure, called Block IndexEach block contains multiple movie framesCS 414 - Spring 2011A VVVA AAVVVBlockIndexTradeoffsFrame index : needs large RAM usage while movie is playing, however little disk wastageBlock index (if frames are not split across blocks): need low RAM usage, but major disk wastage – internal disk fragmentationBlock index(if frames are split across blocks): need low Ram usage, no disk wastage, extra seek timesCS 414 - Spring 2011Efficient VOD Service TechniquesProblem: VOD service offers a large selection of videos from which customers can choose – want to offer low access latency for customersMain Challenge: How to handle large number of customers, maintain low cost of operation and at the same time provide acceptable access latencyCaching Source: Caching Techniques for Streaming Multimedia over the Internet, Markus Hofmann, Eugene Ng, Katherine Guo, Sanjoy Paul, Hui ZhangBatchingSource: Selecting among Replicated Batching VOD Servers, Meng Guo, Mustafa Ammar, E. ZeguraPatchingSource: Hierarchical Video Patching with Optimal Server Bandwidth, H. Hlavacs, S. BuchingerCS 414 - Spring 2011Conclusion Designers of VOD systems strive to achieve low access latency for customersChallenges: Handle large amount of customers (clients)Maintain low cost of operation Provide acceptable access latencyCS 414 - Spring
View Full Document
Unlocking...