Close
About
FAQ
Home
Collections
Login
USC Login
Register
0
Selected
Invert selection
Deselect all
Deselect all
Click here to refresh results
Click here to refresh results
USC
/
Digital Library
/
Computer Science Technical Report Archive
/
USC Computer Science Technical Reports, no. 659 (1997)
(USC DC Other)
USC Computer Science Technical Reports, no. 659 (1997)
PDF
Download
Share
Open document
Flip pages
Contact Us
Contact Us
Copy asset link
Request this asset
Transcript (if available)
Content
Scalable Video Bro wsing T ec hniques for In tranet Video Serv ers Shahram Ghandeharizadeh Roger Zimmermann Jab er AlMarri W eifeng Shi Seon Ho Kim Computer Science Departmen t Univ ersit y of Southern California Los Angeles California Jan uary Abstract Serv ers that emplo y scalable tec hniques prev en t the formation of b ottlenec ks in order to allo w the system to supp ort a higher n um ber of clien ts as function of additional hardw are They are desirable b ecause they enable a gro wing organization to satisfy the increased demand imp osed on its hardw are platform b y increasing its size instead of replacing it with a new one whic h is almost alw a ys more exp ensiv e Sto This study presen ts the design implemen tation and ev aluation of scalable tec hniques in supp ort of video bro wsing ie V CR functions suc h as fastforw ard and fastrewind In tro duction With the con v ergence of computers and consumer electronic go o ds eg digital cameras and camcorders digital video has b ecome as p erv asiveas an y other data t yp e suc h as text records ob jects etc An In tranet video serv er pro vides for storage deliv ery and distribution of video These serv ers migh t con tain training video for the emplo y ees of an organization arc hiv e broadcasted sp eec hes video conferences b et w een sev eral p eople collab orating on a pro ject etc In order to be eectiv e these serv ers m ust supp ort bro wsing tec hniques for video Both fastforw ard and fastrewind with scan are t w o suc h tec hniques T o illustrate This researchw as supp orted in part b y the National Science F oundation under gran ts IRI NYI a w ard and ER C gran t EEC and a HewlettP ac k ard unrestricted cashequipmen tgift VCR Functions online processing offline processing (single file) (multiple files) Extra I/O bandwidth required Extra storage space required Sub-sampling at Segment skipping at server side) full Random Access Point (RAP) index to client side full Random Access Point (RAP) index at server side Random Access Point (RAP) index within streams Proposed Methodology the client side (data retrieval speed-up at server side) Sub-sampling at the server side (frame extraction Transmitting Maintaining Interleaving of (at server and client side) [DSSJT94] [CKLV95, SV95] [CKY94, ORS96] [And96] . . Figure T axonom y of metho ds to implementV CR functions in video serv ers once a video conference is arc hiv ed one of the participan ts ma y w an t to bro wse the stored clip to recall a sp ecic demonstration or discussion This is realized using a fastforw ard displayof a clip to the p oin t of in terest In addition using this functionalit y the user ma y construct mark ed indexes for future recall Ev en with these mark ed indexes bro wsing con tin ues to be useful b ecause it enables a user to study a segmen t carefully bymo ving bac k and forth in that segmen t This study in v estigates the design and implemen tation of scalable tec hniques in supp ort of fastforw ard FF and fast rewind FR By scalable w e imply that there are no inheren t b ottlenec ks and the n um ber of activ e displa ys that can in v ok e FFFR increases as a linear function of the a v ailable bandwidth These designs minimize the amoun t of memory and pro cessing o v erhead incurred at b oth the clien t and the serv er the comm unications o v erhead bet w een the clien t and the serv er and the dela y incurred when V CR functions are in v ok ed W e start with a taxonom y of dieren t approac hes to implemen t V CR functions in order to compare our w ork with the previous literature Subsequen tlyw e detail our design Figure distinguishes t w o basic paradigms to pro vide V CR functions from a video serv er either W e do not consider ne ar V oD systems for this taxonom y b ecause they usually do not pro vide full V CR functionalit y BHH a single normalsp eed mo vie is pro cessed accordingly in realtime during pla ybacktime this paradigm is termed online pro cessing or a clip is prepro cessed b y the con ten t pro vider with separate les for FF and FR viewing termed oine pro cessing The tradeo bet w een these t w o paradigms is IO pro cessing v ersus storage space While online tec hniques require extra bandwidth disk net w ork oine tec hniques require additional disk storage Eac h metho d has other adv an tages and disadv an tages that mightmakeit more appropriate for a sp ecic application W e describ e eac h metho d in turn Related W ork Online Pro cessing Subsampling at the clien t side DSSJT allo cates n times the pla ybac k bandwidth for n times fast viewing This approac h is asso ciated with statistical qualit yofservice QoS guaran tees With a lo w system load its probabilit y of pro viding immediate access to fullresolution FF and FR is high When bandwidth is scarce due to a high system load service is either dela y ed or pro vided b y sacricing resolution This approac h is conceptually simple but ma y need a complex deco der for high sp eed decompression or realtime frame reduction Moreo v er it mayw aste net w ork and disk bandwidth Subsampling at the serv er side is conceptually similar to subsampling at the clien t side except that the realtime frame reduction is p erformed at the serv er side This approac h do es not increase the net w ork bandwidth ho w ev er it do es w aste disk bandwidth More sophisticated v ariations of this metho d can reduce this o v erhead see CKL V SV Segmen t skipping CKY ORS skips a xed n um ber of blo c ks to ac hiev e the desired pla ybackrate bycon trolling the placementofbloc ks on disk driv es F or example to pro vide v e times fast forw ard this The pro cessing ma y b e done at the serv er side the clien t side or b oth metho d displa ys one blo c k out of v e consecutiv e blo c ks The adv an tage of this approac h is its scalabilit y b ecause it requires no extra net w ork and disk bandwidth to supp ort v arious fast rates Ho w ev er it results in un usual previewing b ecause it skips blo c ks not frames Oine Pro cessing And prop osed a metho d to implemen t separate fastforw ard and fastrewind les b y selecting and prepro cessing frames either b efore or after compression F or example to create av e times fastforw ard le ev ery fth frame is selected from the original mo vie b efore compression This collection of frames is enco ded in the regular manner eg using MPEG and stored in a separate le Crossreferences among the dieren t les are main tained to enable a user to switchbet w een v ersions This metho d requires neither additional net w ork nor extra disk bandwidth Moreo v er video qualit y is not degraded Ho w ev er it requires extra storage space for additional les In Section w e detail our design and state our con tributions The rest of this pap er is organized as follo ws In Section w e in tro duce the design of our tec hnique whic h is then detailed for Motion JPEG compressed videos in Section Section extends our approac h for MPEG compressed videos The p erformance of the prop osed sc heme is describ ed in Section W e conclude with the future researc h directions in Section Design Ov erview The design presen ted here is based on an oine approac h ie it implemen ts the fast forw ard and fast rewind functionalities b y main taining separate prepro cessed v ersions of the normalsp eed clip Figure sho ws the terminology that is used throughout the rest of this pap er A pr esentation consists of one normal clip and sev eral eXPR esS XPRS clips Eac h XPRS clip corresp onds to a sp ecic sp eedup factor and direction forw ard or rev erse If a user in v ok es fastforw ard during an activ e displa y the system Normal Clip FF Clip FR Clip FF Clip Presentation XPRS Clips 5X 5X 10X Speed-up Factor Batman N Batman FF 5X Batman FR 5X Batman FF 10X Figure T erminology and notation sho wn with the example of mo vie Batman switc hes from the normal clip to the corresp onding XPRS clip to pro vide the eect of ondemand fast forw ard F or example a presen tation sa y Batman migh t ha v e a fastforw ard v ersion with v e times sp eed Batman FF X a fastforw ard v ersion with ten times sp eed Batman FF X and a fastrewind v ersion with v e times sp eed Batman FR X as sho wn in Figure In order to switc h bet w een the dieren t clips of a presen tation based on user activities a metho d of jumping to the appropriate lo cation in eac h clip m ust be pro vided These lo cations are referred to as Random Access P oin ts RAPs And Their crossreferences whic hmap bet w een the frames of dieren t clips m ust b e main tained In the example of Figure four mappings are necessary One maps the frames of Batman N to those of Batman FF X Batman FF X and Batman FR X This enables a user to switchto an y one of the a v ailable FF or FR v ersions during normal displa y The remaining three map the frames of eac h XPRS clip to one another and the normal clip An example use of these mappings is to enable a user to switc h to fastrewind directly from fastforw ard The fo cus of this study is ho w a Presen tation Manager PM whic hcon trols the displa y at the clien t side eg an extended TV settop b o x or a PCTV gains access to RAPs Previous designs ha v e suggested to main tain RAP index les presumably at the serv er side And There are sev eral disadv an tages to this approac h First the serv er m ust main tain a separate database of RAP index les that can b e accessed v ery quic kly eg a realtime or main memory database This resource could b ecome a b ottlenec k and limit the scalabilit y of a serv er Second b ecause of clien t buering and net w orking dela ys the serv er ma y not kno w exactly whic h frame the clien t is displa ying at the v ery instanta V CR function is in v ok ed Therefore the transition to the new clip ma y not b e v ery smo oth Our design and implemen tation tec hniques enable a serv er to scale to thousands of streams bya v oiding the formation of b ottlenec ks The t w o k ey ideas that facilitate scalabilityare as follo ws First the RAP mappings are not main tained cen trally eg at the serv er Instead they are in terlea v ed b et w een frames of clips in supp ort of distributed pro cessing The mappings are organized suc h that the relev an t information is a v ailable when the user in v ok es aV CR functionalit y The existence of these mappings do es not impact a hardw are deco der eg MPEG MJPEG to displa y a presen tation eg with an MPEG deco der that utilizes the standard the in terlea v ed records can be represen ted as user data whic h is ignored b y the deco der Alternativ ely a simple pro cess either hardw are or soft w are based can lter these mappings from the data stream and redirect them to the V CR functions circuits thereb ya v oiding their transmission to the deco der This means that the system reads mappings on b ehalf of a displayev en though the user migh t not in v okea V CR functionalit y The w asted bandwidth and storage space attributed to retrieving this mapping information is negligible less than in our protot yp e implemen tation see T able b The second k ey idea is as follo ws A PM in terprets the in terlea v ed mappings on demand when a user in v ok es a V CR function This oloads the pro cessing of mappings to the PMs in order to a v oid the formation of b ottlenec ks at the serv er F urthermore the transition bet w een dieren t clips will be precise b ecause the clien t can determine precisely the last deco ded frame when a V CR function is in v ok ed In essence with our tec hnique a small fraction of the mapping information is staged at the righ t place a PM at the righ t time when the user in v ok es a V CR functionalit y to facilitate This problem maybea v oided byencoding frame n um bers in to eac h stream or coun ting the frames at the clientsideand submitting this information together with a V CRcommand to the serv er distributed information pro cessing to realize a scalable serv er Metho dology with Motion JPEG The design describ ed in Section dep ends to some exten t on the data format assumed to enco de a digital video clip In this section w e will rst outline our design and implemen tation based on a Motion JPEG data format In Section w e will subsequen tly outline our tec hnique for the p opular MPEG standard MJPEG Data F ormat The Motion JPEG MJPEG format as implemen ted b y the P arallax XVideo TM system supp orts digital video based on the Join t Photographic Exp erts Group JPEG image compression standard Eac h frame is enco ded based on the JPEG algorithm with no in terframe dep endencies A MJPEG mo vie le starts with a xed length header data structure that describ es critical attributes of the mo vie suc h as heigh t and width of video frames qualit y factor of the JPEG images desired pla ybac k rate audio sp ecications etc A linear sequence of frames follo ws the header data Eac h individual frame is structured as sho wn in Figure Image data is preceded b y a eld that sp ecies its length A LO AD JPEG delimiter indicates the start of the image data while a LO AD A UDIO delimiter precedes the xedsize audio slice Both audio and video comp onen ts ma y b e presen t or optionally one of them ma y b e omitted A frame alw a ys ends with an END FRAME tag The length of the image data v aries dep ending on its complexit y and the compression factor attained b y JPEG The v ariable data length in com bination with a xed n um ber of frames displa y ed as a function of time explains the v ariable bit rate requiremen t of MJPEG Assuming a presen tation consists of x frames the last frame of a clip is follo w ed bya F rame Oset Arra yF O A that Motion JPEG is not as w ell standardized as MPEG W e base our discussion on the format sp ecied b yP arallax Graphics Inc P ar HEADER F0 F1 F2 F3 F4 FOA ... F5 Fixed length (128 Bytes) LOAD_JPEG END_FRAME LOAD_AUDIO VIDEO_SIZE JPEG VIDEO DATA AUDIO DATA 1 Byte (0xEC) 4 Bytes 1 Byte (0xE5) 1 Byte (0xED) Variable length Fixed length (int) (b) Frame Format Fn-1 (a) Movie Format Figure P arallax MJPEG mo vie format consists of x elemen ts Eac h elemen t i of F O A con tains the oset of frame i relativ e to the b eginning of the le The oset of the F O A itself is stored in the header data structure T o displayan MJPEG video the clien t application m ust read the header data and set up the video displaywindo w according to the sp ecied attribute v alues Next it reads and pla ys the frames in sequence at the frame rate sp ecied in the header In terlea v ed RAP Mappings In our approac h the RAP mapping information is represen ted as r e c or ds Eac h record consists of a set of poin ters to its corresp onding RAPs W e in terlea v e records bet w een the frames of clips to enable the system to switchbet w een clips of the same presen tation This section sp ecies the structure con ten t and lo cation of these records Assume that a con ten t pro vider desires to oer a presen tation sa y Batman with n dieren t V CR Pass 1 Pass 2 Batman RAP Offsets Mapping Formulas (see Table 2) N FF FF FR 5X 10X 5X ... ... ... Number of FF/FR versions and their speed-ups (e.g., ) n = 3, y = 10 max (Create clips while inserting empty records; save RAP offsets) (Determine frame mapping; fill in content of records) (Original movie) N FF FF FR 5X 10X 5X FOA Figure Tw o pass algorithm for inserting RAP mappings functionalities sa y FF X FF X and FR X n Our algorithm to construct the clips and in terlea v e records b et w een the frames op erates in t w o passes Figure illustrates the pro cess During the rst pass the desired frames from the original MJPEG clip are selected to construct a normal clip termed N for short and the XPRS clips that con tain in terlea v ed records with empt y elds During the second pass the elds are up dated to con tain the prop er con ten ts ie RAP p oin ters to pro vide the crossreference mappings The rst pass is as follo ws The algorithm determines the maxim um scan sp eed y max y max in our example due to FF X among n sp eeds Then the original MJPEG le is scanned sequen tially and n clips with empt y in terlea v ed records are generated one XPRS clip for eac h of the n scan functionalities Batman FF X Batman FF X and Batman FR X and one clip for normal displa yBatman N The size of RAP records is xed to hold n RAP p oin ters eg n in tegers or n b ytes assuming a bit arc hitecture F or the normal clip Batman N eac hpoin ter corresp onds to one of the scan functionalities The order of the p oin ters within a record is hPtr FF aX Ptr FF bX Ptr FR cX Ptr FR dX i with a b and c d F or example in Figure the p oin ter order is as follo ws the rst p oin ter maps to FF X the second to FF X and the third to FR X see the arcs lab eled and This order is imp ortan t File sizes are not sho wn to scale AFF X v ersion of a clip w ould b e appro ximately the size of the N v ersion or less if the audio p ortion is remo v ed HEADER R E C 0 F0 F1 ... F9 R E C 1 F10 ... FOA Batman HEADER R E C 0 F0 F1 ... FOA Batman R E C 1 HEADER R E C 0 F0 F1 ... FOA Batman R E C 1 HEADER E C 0 F0 Fn-1 ... FOA Batman E C n-1 R R REC0 3 2 REC0 1 5 6 4 FF FF FR N 5X 10X 5X Figure File la y out for dieren tv ersions of an MJPEG presen tation and m ust b e main tained b y the system for example in the FileVersions relation whic h will b e detailed in Section F or a giv en XPRS v ersion the p oin ter eld that w ould normally map to its o wn clip is instead used to refer bac k to a frame in the normal sp eed v ersion N Eac h of the other poin ters is as b efore F or example with Batman FF X the second and third poin ter of eac h record con tin ue to be osets to Batman FF X and Batman FR X resp ectiv ely Ho w ev er the rst p oin ter is an oset to Batman N see arcs and in Figure Similarly for Batman FF X the second poin ter is an oset in to Batman N while the other t w o are osets in to Batman FF X and Batman FR X resp ectiv ely Note that a record precedes eac h frame in an XPRS clip In the normal clip Batman N a record precedes the rst frame and a record is inserted after ev ery y th max frame ten th in our example The detailed construction of eac h of the n clips of a presen tation is as follo ws A new header is generated follo w ed b y the rst RAP record In addition to the information listed in Section the header is extended to main tain the size of eac h record and the n um ber of frames that app ear bet w een t w o consecutiv e records The algorithm retriev es eac h frame i of the original MJPEG mo vie and inserts it in to the normal clip After ev ery y max frames it inserts a record in to the normal clip that corresp onds to the next sequence of y max frames F or eac h of the n XPRS clips corresp onding to a scan functionalit y with sp eed z it inserts frame i only if i mo dulo z equals zero A record is inserted before eac h suc h frame F or the fastrewind XPRS les the frames and records are stored in rev erse order In our example scenario the size of eac h record for Batman N Batman FF X Batman FF X and Batman FR X is t w elveb ytes long A record app ears after ev ery ten frames in Batman N F or the remaining three XPRS les one frame separates t w o adjacen t records While Batman FF X con tains one out of ev ery fth frame Batman FF X con tains one out of ev ery ten th frame One out of ev ery fth frame is inserted in rev erse order in to Batman FR X W e eliminate the audio p ortion of eac h frame for XPRS les b ecause its displa yis noncon tin uous and w ould translate in to a collection of incomprehensible noises This optimization sa v es disk space disk and net w ork bandwidth and memory at the Presen tation Manager PM side when the user in v ok es a scan functionalit y The rst pass is complete when the last frame of the normal clip has b een pro cessed A t this p oin t an F O A with mo died osets is app ended to the end of eac h of the n clips Recall that the F O A con tains the oset of eac h frame in a clip and b ecause n umerous RAP records ha v e been inserted during the pro cessing of pass one the osets of frames ha v e c hanged F or frames that are preceded b y a RAP record the oset of the b eginning of the record is used see Figure The second pass consists of t w o stages During stage one the algorithm lls up the con ten ts of the records in terlea v ed in the normal clip eg Batman N This pro cessing is as follo ws F or eac h frame X in Batman N its corresp onding frame n um bers within the XPRS clips are computed using the equations of T able These frame n um b ers denoted Y in T able are then con v erted to osets ie RAP p oin ter P arameter Denition X F rame n um b er for the currentv ersion Y F rame n um b er for the new v ersion S X Sp eed of the currentv ersion S Y Sp eed of the new v ersion F N Num b er of frames in the normal clip F Y bF N S Y c F I Num ber of frames bet w een t w o records in the normal clip T able P arameters and their Denitions Mapping Equation from normal clip to FF clip Y bX S Y c from FF clip to normal clip Y bX S X F I c F I from normal clip to FR clip Y F Y b X S Y c from FR clip to normal clip Y b F N X S X F I c F I bet w een t w o similar a XPRS clips Y bX S X S Y c bet w een t w o dissimilar b XPRS clips Y F Y b X S X S Y c a Similar XPRS clips ha v e the same t yp e but dieren t sp eeds eg FF X and FF X b Dieren t XPRS clips ha v e dieren tt yp es eg FF X and FR X T able Mapping equations b et w een frames among dieren t clips v alues b y lo oking up eac h elemen t Y in the F O A of its clip Example Assume Batman N consists of frames with frames bet w een t w o records Giv en frame in Batman N its corresp onding frame n um ber in Batman FF X is Y bXS Y c b c in Batman FF X it is Y bXS Y c b c and in Batman FR X it is Y F Y b XS Y c b c b c The oset of a frame eg in Batman FF X is determined b y lo oking up its elementie n um ber in the F OAofBatman FF X A t the end of stage one the records in terlea v ed in Batman N con tain the appropriate osets in to XPRS clips During the second stage the algorithm visits eac h XPRS clip and computes the con ten ts for the empt y poin ters of its records one at a time Sp ecically for eac h frame X in an XPRS clip sa y Batman FF X the algorithm determines the corresp onding frames in the other clips Batman N Batman FF X and Batman FR X using the equations of T able By fetc hing the osets from the F O As of the clips the con ten t of a record in the clip is completed Example With the assumption made for Example frame in Batman FF X no w corresp onds to frame in Batman N frame in Batman FF X and frame in Batman FR X resp ectiv ely By fetc hing the th oset in the F O A of Batman N th oset in the F O A of Batman FF X and th oset in the F O A of Batman FR X the algorithm determines the prop er osets for frame in Batman FF X Note that framein Batman N is referenced b y frame in Batman FF X not as deriv ed from This is b ecause wew an t to jump to a frame that is prexed with a record The ab o v e pro cedure is rep eated for all the frames in a XPRS clip and subsequen tially for all the XPRS clips A t the end of stage t w o construction of all the clips is complete Record Placemen t Arecordm ust b e placed in fron t of a frame that wew anttoha v e direct access to F or example if a record precedes ev ery frame in a clip then w e can p oten tially jump from and to ev ery frame in that clip If on the other hand records exist only ev ery th framethenw e can only access ev ery th frame directly and an y access that w ould fall in b et w een w ould need to b e rounded up or do wn to the closest indexed frame More generally the tradeo is access gran ularityvs w asted disk space and bandwidth Access gran ularit y translates in to time accuracy in our applications When in terlea v ed records are used to switchbet w een dieren tv ersions of a presen tation the follo wing lo w er b ound can b e put on the in terlea ving factor in the normal clip insert a record only ev ery y th frame where y is the smallest sp eedup factor of an y of the XPRS v ersions wew an t to supp ort for this presen tation The reasoning b ehind this lo w er b ound is as follo ws When switc hing from the normal to the y times fast ClipName MediaName StartingDisk FileOrg: FileVersions: ClipName No. of Versions Type 1 Speed 1 Field-Id 1 Type N Speed N Field-Id N ... Version 1 Version N MediaTypes: MediaName BlockSize Figure Serv er catalog structure in Mitra three relations v ersion the frame n um ber m ust be rounded suc h that it is divisible b y y since only those frames exist in the y times fast v ersion Similarly when switc hing from the y times fast to the normal v ersion the curren t frame n um ber m ust be m ultiplied b y y to nd the correct normal sp eed frame n um b er In either case switc hing information is only needed b efore ev ery y th frame in the normal v ersion and inserting more records w ould not impro v e the switc hing accuracy When a presen tation supp orts m ultiple XPRS sp eeds there are v arious w a ys to c ho ose the in terlea ving factor in the normal and the XPRS v ersions Again the tradeo is b et w een switc hing accuracy and space bandwidth o v erhead In our implemen tation w e c hose to insert a record b efore ev ery frame in all the XPRS v ersions and b efore ev ery max y y y n th frame in the normal v ersion where y i is the sp eedup factor of the i th XPRS clip Because frame n um b ers sometimes need to be rounded w e ha v e a c hoice of rounding up or do wn F rom an algorithmic p oin t of view either w aywill w ork ne Ev en visually there will not b e an y noticeable dierence in most cases Only when the rounding in v olv es sev eral ten th of frames the c hoice migh t b ecome imp ortan t In this study w e are alw a ys using the o or function ie rounding do wn to simplify the discussion A Multidisk Serv er and its Presen tation Managers This section outlines ho w the metho dology of in terlea v ed RAP records can be supp orted b y an actual implemen tation of a video serv er This will be done in the con text of Mitra GZS a video serv er protot yp e that w as dev elop ed at the database lab oratory of the Univ ersit y of Southern California Los Angeles The functionalities needed at b oth the PM and the serv er sides will b e discussed A Mitra serv er supp orts three relations to main tain the iden tit y of dieren t presen tations and their clips FileVersions FileOrg and MediaTypes see Figure FileVersions is partially cac hed at a Presen tation Manager PM in supp ort of both V CR functionalities and to enable a user to iden tify the a v ailable titles W e start with a description of these relations Subsequen tly w e describ e the PM the serv er and ho wthey in teract FileVersions main tains eac h presen tation kno wn to Mitra and its corresp onding clips Eachen try in this relation is of v ariable length consisting of the presen tation name the n um ber of scanfunctionalities supp orted for this presen tation and for eac h functionalit y a triple consisting of type speed and fieldid V alid t yp es are N normal FF fastforw ard and FR fastrewind The speed eld sp ecies the sp eed up factor for a giv en FF or FR functionalit y Speed is one for t yp e N Finally fieldid corresp onds to a sp ecic eld of the record inserted bet w een the frames of the clips It iden ties whic h eld of this record osets in to the other clips corresp onding to this V CR functionalit y In our Batman exam ple with three scan functionalities the en try for this presen tation in FileVersions w ould be as follo ws BatmanNFFF F F R The MediaTypes relation con tains a listing of all the media t yp es kno wn to the system F or eac h media t yp e this relation main tains its blo c k size ie at what gran ularit y a clip of this media t yp e should Note that except for FileVersions these relations are necessary for the normal op eration of a Mitra con tin uous media serv er ev en without the FFFR supp ort The Most Recent Record Current Frame FileVersions Relation Corresponding Frame F i F j ... F j+1 F j-1 F i+1 F i-1 ... ... Version Switching Request (e.g., N to FF ) Normal Clip (Batman ) XPRS Clip (FF ) a FF c d FF FR FF N REC i REC j+1 REC j REC j-1 5X 5X 5X 10X 5X 5X b (Batman,4,N,1,-,FF,5,1,FF,10,2,FR,5,3) field-id = 1 525000 ... ... 1 2 3 field-id Figure Example of v ersion switc hing normal to FF X b e retriev ed A t the serv er eac h clip b oth normal and XPRS clips is represen ted as a unique le The name of a le is a concatenation of its presen tationname t yp e and sp eed The four les that represen t Batman and its XPRS clips are named BatmanN BatmanFF BatmanFF and BatmanFR With a m ultidisk serv er that consists of D disks a clip is partitioned in to xsized blo c ks The size of eac h blo c k is determined b y the clips media t yp e The blo c ks of a clip are assigned to the disks in a roundrobin manner starting with an arbitrary disk to distribute the load of a displa yev enly across the disks FileOrg main tains the name of eac h presen tation its media t yp e to determine its blo c k size and the disk that con tains its rst blo c k Section details ho w this information is used JPEG Decode Accelerator Audio Interface Hardware User Interface Play Logic Buffer Manager Data Connection to Mitra Current Frame Video Data Audio Data Offset to FF version Offset to FF version Offset to FR version Current RAP Offsets Control Connection to Mitra <PLAY clipname, offset> Record Data 5X 10X 5X Figure Presen tation Manager structure of Mitra Presen tation Manager The Presen tation Manager PM represen ts the displa y station of a user connected to Mitra Through the PM the user can request audio and video clips from the Mitra serv er When the serv er starts to stream the data to the user w orkstation the PM is resp onsible for deco ding and displa ying the data Other V CRlik e functions pro vided b y the PM include pausing and resuming fastforw arding fastrewinding and stopping a stream W e will fo cus on ho w the V CR functions are supp orted Figure sho ws the in ternal structure of a PM pro cess A t the b eginning of a session the PM will retrievea list of the a v ailable program material ie presen tations from the serv er Sp ecically the PM cac hes a p ortion of the FileVersions relation whichcon tains vital information ab out the a v ailable titles When a user requests the displa y of a presen tation sa y Batman the PM enables the fastforw ard andor fastrewind buttons of the user in terface based on the v ersion typ es applicable for this clip A pull do wn men u is congured to enable a user to c ho ose bet w een the a v ailable fastforw ard and fast rewind sp e e ds a v ailable Nextacon trol message with the follo wing format PLA Y BatmanN is dispatc hed to the serv er The third eld iden ties the oset within the clip that the displa y should start with The serv er sends the blo c ks of BatmanN to the PM starting with the blo c k that con tains oset the computation of the blo c kn um b er is a function of the oset and describ ed in Section Up on the arriv al of this blo c k the PM extracts the header to compute the windo w size the rate at whic h the frames should be displa y ed length of the records in terlea v ed bet w een the frames b ytes in our example and the n um ber of frames bet w een t w o records in our example This information is the con text for the activ e displa y This con text remains v alid un til the user in v ok es the Stop button or the displa y terminates The PM retains the RAP record that precedes eac h sequence of frames that are displa y ed step a in Figure In our example the PM cac hes the rst RAP record of BatmanN when displa ying its rst ten frames This record is replaced with the next record that precedes the displa y of the next ten frames With no man ual in terv en tion this pro cess rep eats un til all frames of the clip ha v e b een displa y ed Ho w ev er when the user in v ok es fastforw ard sa y FF X the curren t displayis terminated and the PM issues a new pla y command suc h as PLA Y BatmanFF The serv er extracts the second eld and in terprets it as the name of the XPRS clip that is required b y the displa y The third eld sp ecies that the displa y of the XPRS le should start at oset in this example It is determined b y the PM as follo ws First the en try corresp onding to the activ e clip in the cac hed FileVersions relation is emplo y ed to compute the fieldid f of the record in terlea v ed b et w een ev ery ten frames that w ould oset in to the frame of the needed XPRS le fieldid for Batman FF X step b in Figure Next using the record that corresp onds to the sequence of frames curren tly b eing displa y ed the PM lo oks up the f th eld within this record to retriev e the b yteoset of step c in Figure After the PM sends the PLA Y BatmanFF command the serv er will resp ond b y transmitting the blo c k that con tains b yteoset of the Batman FF X clip step d in Figure The details of the serv erside computation are outlined in Section The PM is a w are of the transmission blo c k size used for the new clip and can therefore determine the correct starting oset within the rst data blo c k F or example with a blo c k size of Kb ytes the oset of the record just b efore the rst frame to be displa y ed is mo d Serv er Op eration With an y PLA Y command the serv er receiv es the name of the le represen ting that clip and the oset of the frame at whic h the displa y should start Using this information the serv er go es through the follo wing steps to start the new displa y F rom the FileOrg relation it determines the media t yp e of the referenced clip and the disk that con tains its rst blo c k termed d star t Using the MediaTypes relation the serv er determines the size of the blo c ks for this clip termed bl ock siz e The blo c k denoted b j that con tains the oset and therefore the frame referenced b y the displa y command is computed as b j offset bl ock siz e The disk d i that con tains this blo c k is iden tied b y d i b j d star t mod D where D denotes the total n um ber of disks of the serv er Once the correct starting blo c k b j has b een lo cated on the correct disk d i the serv er streams the data to the PM step d in Figure A con trol message precedes the transmission of this blo c k to inform the PM of the size of eac h blo c k Using this information and the oset the PM can determine the starting address of the frame that should initiate the displa y T o illustrate consider a simple example Assume D offset d star t and bl ock siz e Kb ytes It follo ws that blo c k b j j k con tains the required frame This blo c k resides on disk d i mod Subsequentbloc ks are retriev ed in the usual roundrobin manner Online Creation of Normal and FF V ersions The normal clip of a presen tation and its corresp onding fastforw ard XPRS clips can b e constructed online while it is recorded This is b ecause at the time a record needs to b e in terlea v ed in all v ersions the system has the necessary information that should b e stored in the in terlea v ed records b oth the normal clip and its XPRS clips F or example since the addresses of the rst frames in all the v ersions are kno wn b efore recording the rst record of all v ersions can b e constructed Because the records in the normal v ersion are in terlea v ed according to the fastest FF v ersion this guaran tees the a v ailabilityof next addresses that are needed to build the next record of all fastforw ard XPRS clips F or ob vious reasons online construction of FR v ersions is imp ossible Extension to MPEG Our approac h can be adapted to other video formats suc h as MPEG Motion Picture Exp erts Group When compared with MJPEG MPEG pro vides for b oth in terframe and in traframe compression MPEGs in terframe compression results in sev eral dieren t frame t yp es in the compressed domain Iframes P frames and Bframes for details see ISO Andersen And prop osed to use only the Iframe t yp e in the XPRS les Our approac h allo ws the system to use all t yp es of frames when compressing XPRS les This results in great reduction in the size of XPRS les since Iframes t ypically con tain ab out times as man y bits as Pframes and ab out times as man y bits as Bframes Also it results in a lo wnet w ork bandwidth requiremen t due to the smaller sizes of XPRS les Ho w ev er it restricts access to a group of pictures GOP GOP denotes a concept in the MPEG syn tax that denotes a sequence of pictures that con tains exactly one Iframe whic h m ust also be the rst frame of this sequence Switc hing Strategies Iframes are the only indep enden tly enco ded frames that allo w random access to the compressed les Hence when the system switc hes from one le to another it m ust start from an Iframe in the target le Since a GOP con tains a single Iframe whic h is also the rst frame our tec hnique essen tially maps from one GOP to another Tw o strategies are prop osed to handle the mapping from one le to another GOP and Skip see Figure They are explained in turn (b) Skip Strategy ...IBBPBBPBBPBBPBBI..., GOP size = 15 Target Frame (a) GOP Strategy ...IBBPBBPBBPBBPBBI..., GOP size = 15 Target Frame Figure Switc hing pro cess with GOP and Skip strategies GOP Strategy In this strategy whenev er a user switc hes from normal displa y to XPRS clips or vice v ersa the system m ust b egin from an Iframe and displaythe next frames sequen tially as sho wn in Figure a When the system switc hes from one le to another the target frame migh t b e a Pframe or a Bframe In this case the system m ust start from the Iframe that precedes the target frame As a result this strategy ma y suer from an accuracy problem in the switc hing pro cess to the target frame This accuracy problem on the a v erage migh t lead to a delayof GOP Size fps seconds b efore displa ying the target frame where fps is the n um b er of frames that get displa y ed p er second The GOP size refers to the total n um b er of pictures that are con tained in a GOP If the GOP size is and the fps is then the a v erage dela y time b efore displa ying the target frame is appro ximately second One w a y to minimize the a v erage dela y is to decrease the GOP size Skip Strategy This strategy is similar to the GOP strategy Ho w ev er with this strategy the system attempts to reduce the a v erage dela y time b y only displa ying the reference frames un til it reac hes the target frame then it displa ys the frames sequen tially as depicted in Figure b A reference frame is either an Iframe or Pframe This enables the system to eliminate the o v erhead time required to displa y Bframes that arriv e prior to the target frame With this strategy the a v erage dela y time due to displa ying the reference frames is Num ber of Reference F rames in GOP fps seconds If the GOP size is as sho wn in Figure b and fps is then the a v erage dela y time is second The system can minimize the a v erage dela y time b y minimizing the n um b er of the reference frames in a GOP Mapping of F rames Assume that a user in v ok es FF while displa ying a clip The system m ust b e able to compute whic h frame is b eing displa y ed from the normal pla ybac k and nd its corresp onding frame in the FF le and vice v ersa T o enable the system to compute a mapping of frames from one le to another w e deriv e the equations of T able T able denes the parameters used in these equations The sp eed of a le refers to its sp eed up rate compared to the normal pla ybac k le F or instance a ten times FF le displa ys the presen tation at a rate that is ten times faster than that of normal previewing Note that since w e are taking the ceiling for Y whic h is the target frame within a GOP it migh t b e equal to L whic h is the GOP size of the target le If this happ ens then the v alue of Y should b e reset to zero and J should b e incremen ted b y one When Y Mapping Equation from normal le to FF le J b X S Y L c Y d X mo d S Y L S Y e from FF le to normal le J b X S X L c Y X S Xmod L from normal le to FR le J b T Y S Y X S Y L c Y d T Y S Y X mo d S Y L S Y e from FR le to normal le J b T X S X X S X L c Y T X S X X S X mo d L from FF le to FF le J b X S X S Y L c Y d X S X mo d S Y L S Y e from FR le to FR le J b T Y S Y T X S X X S X S Y L c Y d f T Y S Y T X S X X S X g mo d S Y L S Y e from FF le to FR le J b T Y S Y X S X S Y L c Y d T Y S Y X S X mo d S Y L S Y e from FR le to FF le J b T X S X X S X S Y L c Y d T X S X X S X mo d S Y L S Y e T able Mapping equations b et w een frames among dieren t MPEG les is equal to zero it means that the system alw a ys starts from the Iframe p oin ted to b y J Figure sho ws an example of ho w to use the equations to map from one le to another Placemen t of In terlea v ed Records The placemen t of in terlea v ed records dep ends on the sp eed up rates and the GOP sizes of the les Consequen tly w e can select the sp eed up rates and the GOP sizes to eliminate redundan t information Eac h in terlea v ed record con tains elds and eac h eld con tains an oset to a le A new record ma y be added to a le whenev er one of its elds is c hanged The equation F requency of Changed Field F CF L S Y S X can b e used to detect ho w often a eld gets c hanged The denition of the parameters of this equation can be foundinT able The result of this equation mightbe zero b ecause it is using the o or function In IBBPBBPBBPBBPBBIBBPBBPBBPBBPBBI 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 2 Normal Playback File: FRV 5X : IBBPBBI 0 1 2 3 4 5 6 0 1 2 3 4 5 1 IBBPBBI 0 1 2 3 4 5 6 0 1 2 3 4 5 1 I 5 2 Frame Number GOP Number (J) P 3 6 Frame Number Frame Number Within a GOP (Y) B 31 7 Frame Number Frame Number Within a GOP (Y) Source File Target File X J Y Target Frame Number(J*GOP size + Y) Normal FRV 5X 505 5 Normal 11 0 3 3 Normal 3 1 0 15 FRV 5X Normal 3 1 0 15 FRV 5X 303 3 FRV 5X 204 4 , GOP size = 15 , GOP size = 6 FFV 5X : FFV 5X FFV 5X FFV 5X FFV 5X Figure An example of le mappings this case the v alue of F CF is adjusted to one b ecause zero is an in v alid result This equation pro vides the n um b er of frames after whic h a particular eld in a record is mo died F or a particular le w emayha v e dieren tF CFs for the dieren t elds in a record Redundancy can be minimized if these F CFs are m ultiples of eac h other There m ust alw a ys be a record in fron t of eac h Iframe Otherwise if the system switc hes to an Iframe that do es not ha v e a record and it is immediately required to switc h to a dieren t le then the system will fail to honor that request Consequen tly a record m ust b e put in frontofeac h Iframe ev en if this results in a redundancy In this case redundancy can b e minimized if one of the F CFs is a m ultiple of the GOP size of the le T o clarify the use of the equation an example is pro vided in Figure Ev en though this example sho ws ho w to calculate F CFs for only normal le and FF les FR les can be computed in the same manner After all FR les are the same as FF les except that they are ordered con v ersely N FCF = (15 * 5) / 1 = 75 frame(f) N FCF = (15 * 10) / 1 = 150 frame . . . Normal File: 75f 75f 75f N FCF = (15 * 1) / 5 = 3 frame FCF = (15 * 10) / 5 = 30 frame . . . FFV File: 3f 3f 3f 3f 3f 3f 3f 3f 3f 3f 3f N FCF = (15 * 1) / 10 = 1 frame FCF = (15 * 5) / 10 = 7 frame . . . FFV File: 1f 1f 1f 1f 1f 1f 1f 1f Interleaved Record GOP Size of all Files = 15 N: Normal File FFV 5X FFV 10X FFV 5X FFV 5X FFV 10X 10X FFV 10X FFV 10X FFV 5X 5X Changed Fields: N & FFV N N & FFV 5X 5X Changed Fields: FFV & FFV FFV FFV & FFV FFV 5X 10X 5X 5X 10X 5X Changed Fields: N & FFV N N & FFV 10X 10X Figure An example for the placementof in terlea v ed records P erformance Ev aluation T o ev aluate the p erformance ie the switc hing time bet w een dieren t clip v ersions of our design for V CR functionalities w e implemen ted the necessary concepts in the Mitra serv er GZS and its PM clien ts W e then pro ceeded to imp ose a load on the system while at the same time exercising the V CR functions The exp erimen tal design w as as follo ws The system setup included one serv er consisting of t w o w orkstations with eigh t magnetic disks driv es A syn thetic w orkload w as imp osed on the serv er with the arriv al rates of user requests follo wing a P oisson distribution F our exp erimen ts w ere conducted with system loads of and APMw as mo died to automatically generate requests for V CR functions Sp ecically the PM alternated b et w een normal pla y and fastforw ard of a clip un til it reac hed Presen tation Normal Pla ybac k Size FF X FF X min of video Size of Normal Size of Normal Disney MB MB MB T op Gun MB MB MB Hawaii MB MB MB a Storage space allo cated for dieren t clip v ersions V ersion Presen tation Disney T op Gun Hawaii Normal FF XFR X FF XFR X Switc hing Time System Load sec Minim um Maxim um Av erage b W asted storage space and net w ork bandwidth attributed to RAP mapping information c Clip switc hing time for dieren t system loads T able P erformance ev aluation results of the length of this clip A t that poin t it started to alternate bet w een normal pla y and fastrewind un til it w as bac k at of the clips length The normal pla y time w as randomly c hosen bet w een and seconds and the FFFR time b et w een and seconds The ab o v e sequence of v ersion switc hes w as rep eated for t w o hours for eac h exp erimen t to measure the switc hing time The upp er b ound on the pla y times w as delib erately c hosen to b e quite small to generate a signican tn um b er of switc hes T able b summarizes the results of our tests As exp ected the switc hing time increases with higher system loads The minim um latency is appro ximately seconds The a v erage dela y exp erienced b y a user is appro ximately seconds under a hea vy load of on the serv er Other than quan titativ e p erformance dieren t designs for V CRlik e functions also exhibit dieren t qualitativ e adv an tages and disadv an tages Because the frames in the XPRS clips are a subset of the normal v ersion of a presen tation the digital FF and FR op erations do not suer from the artifacts that analog V CRs exhibit streaks increased picture noise Moreo v er the presen ted design results in a v ery smo oth pla ybac k as compared with designs that skip whole blo c ks since exactly ev ery y th frame is displa y ed A system manager ma y also c ho ose dieren t sp eedup factors dep ending on the con ten t of a mo vie F or example a FF X v ersion ma y be appropriate for a fast paced mo vie suc h as T op Gun whereas a FF X clip ma y b e b etter for a do cumen tary Compared to designs that increase the pro duction rate at the serv er side to implemen t fastforw ard or fast rewind our approac h do es not increase the system load and hiccups due to load uctuations are therefore a v oided Conclusion and F uture Researc h Directions This study presen ted the design and implemen tation of scalable bro wsing tec hniques for In tranet video serv ers in supp ort of high qualitypla ybackwith lo w pro cessing o v erhead Using a protot yp e implemen tation of these tec hniques in Mitra GZS w ev alidated the feasibilit y of our metho d as w ell as its p erformance In the near future w ein tend to implemen t our tec hnique for MPEG References And D Andersen A Prop osed Metho d for Creating V CR Functions Using MPEG Streams In Pr o c e e dings of the th International Confer enc e on Data Engine eringF eb BHH Rob ert O Bank er Jerey B Hupp ertz Mic hael T Ha y ashi Da vid B Lett V o ytek E Go dlewski and Mic hael W Raley Metho d of pro viding video on demand with V CR lik e functions Octob er US P aten t No CKL V HJ Chen A Krishnam urth y TDC Little and D V enk atesh A Scalable VideoonDemand Service for the Pro vision of V CRLik e Functions In Pr o c e e dings of the nd Intl Confer enc e on Multime dia Computing and Systems pages W ashington DC Ma y CKY M Chen DD Kandlur and P S Y u Supp ort for Fully In teractivePla y out in a DiskArra yBased Video Serv er In Pr o c e e dings of the A CM Multime dia Oct DSSJT JK DeySircar JD Salehi JFKurose and D T o wsley Pro viding VCR Capabilities in LargeScale Video Serv ers In Pr o c e e dings of the A CM Multime dia Oct GZS S Ghandeharizadeh R Zimmermann W Shi R Rejaie D Ierardi and TW Li Mitra A Scalable Con tin uous Media Serv er Kluwer Multime dia T o ols and Applic ations July ISO ISO Co ding of moving pictur es and asso ciate d audio for digital stor age mediaatup toab out Mbits ISO Standard IS ORS B Ozden R Rastogi and A Silb ersc hatz The Storage and Retriev al of Con tin uous Media Data In VS Subrahmanian and S Ja jo dia editors Multime dia datab ase systems Springer P ar P arallax Graphics Vide o Development Envir onment TM R efer enc e Guide for Sun Solaris HPUX and IBM AIX Sto M R Stonebrak er The case for SharedNothing In Pr o c e e dings of the nd International Confer enceon Data Engine ering SV P J Sheno y and H M Vin Ecien t supp ort for scan op erations in video serv ers In Pr o c e e dings of the A CM Multime diaNo v em b er
Linked assets
Computer Science Technical Report Archive
Conceptually similar
PDF
USC Computer Science Technical Reports, no. 627 (1996)
PDF
USC Computer Science Technical Reports, no. 628 (1996)
PDF
USC Computer Science Technical Reports, no. 623 (1995)
PDF
USC Computer Science Technical Reports, no. 650 (1997)
PDF
USC Computer Science Technical Reports, no. 653 (1997)
PDF
USC Computer Science Technical Reports, no. 666 (1998)
PDF
USC Computer Science Technical Reports, no. 615 (1995)
PDF
USC Computer Science Technical Reports, no. 610 (1995)
PDF
USC Computer Science Technical Reports, no. 590 (1994)
PDF
USC Computer Science Technical Reports, no. 634 (1996)
PDF
USC Computer Science Technical Reports, no. 592 (1994)
PDF
USC Computer Science Technical Reports, no. 625 (1996)
PDF
USC Computer Science Technical Reports, no. 685 (1998)
PDF
USC Computer Science Technical Reports, no. 911 (2009)
PDF
USC Computer Science Technical Reports, no. 766 (2002)
PDF
USC Computer Science Technical Reports, no. 598 (1994)
PDF
USC Computer Science Technical Reports, no. 748 (2001)
PDF
USC Computer Science Technical Reports, no. 912 (2009)
PDF
USC Computer Science Technical Reports, no. 964 (2016)
PDF
USC Computer Science Technical Reports, no. 619 (1995)
Description
Shahram Ghandeharizadeh, Roger Zimmermann, Jaber Al-Marri, Weifeng Shi, Seon Ho Kim. "Scalable video browsing techniques for intranet video servers ." Computer Science Technical Reports (Los Angeles, California, USA: University of Southern California. Department of Computer Science) no. 659 (1997).
Asset Metadata
Creator
Al-Marri, Jaber
(author),
Ghandeharizadeh, Shahram
(author),
Kim, Seon Ho
(author),
Shi, Weifeng
(author),
Zimmermann, Roger
(author)
Core Title
USC Computer Science Technical Reports, no. 659 (1997)
Alternative Title
Scalable video browsing techniques for intranet video servers (
title
)
Publisher
Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA
(publisher)
Tag
OAI-PMH Harvest
Format
27 pages
(extent),
technical reports
(aat)
Language
English
Unique identifier
UC16271026
Identifier
97-659 Scalable Video Browsing Techniques for Intranet Video Servers (filename)
Legacy Identifier
usc-cstr-97-659
Format
27 pages (extent),technical reports (aat)
Rights
Department of Computer Science (University of Southern California) and the author(s).
Internet Media Type
application/pdf
Copyright
In copyright - Non-commercial use permitted (https://rightsstatements.org/vocab/InC-NC/1.0/
Source
20180426-rozan-cstechreports-shoaf
(batch),
Computer Science Technical Report Archive
(collection),
University of Southern California. Department of Computer Science. Technical Reports
(series)
Access Conditions
The author(s) retain rights to their work according to U.S. copyright law. Electronic access is being provided by the USC Libraries, but does not grant the reader permission to use the work if the desired use is covered by copyright. It is the author, as rights holder, who must provide use permission if such use is covered by copyright.
Repository Name
USC Viterbi School of Engineering Department of Computer Science
Repository Location
Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089
Repository Email
csdept@usc.edu
Inherited Values
Title
Computer Science Technical Report Archive
Description
Archive of computer science technical reports published by the USC Department of Computer Science from 1991 - 2017.
Coverage Temporal
1991/2017
Repository Email
csdept@usc.edu
Repository Name
USC Viterbi School of Engineering Department of Computer Science
Repository Location
Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089
Publisher
Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA
(publisher)
Copyright
In copyright - Non-commercial use permitted (https://rightsstatements.org/vocab/InC-NC/1.0/