1 / 6

Models for adaptive -streaming-aware CDNI - File Management and Content Collections draft -brandenburg-cdni-has- 01

Models for adaptive -streaming-aware CDNI - File Management and Content Collections draft -brandenburg-cdni-has- 01, section 3.1. CDNI Extended Design Team Meeting Virtual Meeting May 29, 2012 Ray van Brandenburg (ray.vanbrandenburg@tno.nl). Key Considerations regarding File Management.

farhani
Download Presentation

Models for adaptive -streaming-aware CDNI - File Management and Content Collections draft -brandenburg-cdni-has- 01

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Models for adaptive-streaming-aware CDNI-File Management and Content Collectionsdraft-brandenburg-cdni-has-01, section 3.1 CDNI Extended Design Team Meeting Virtual Meeting May 29, 2012 Ray van Brandenburg (ray.vanbrandenburg@tno.nl)

  2. Key Considerations regarding File Management • Content Collection may consists of very large number of files (e.g. 100s to 1000s) • Large numbers of files increases file management overhead in CDN • Fragments are allowed to be stored as individual files or as part of a single file (e.g. Fragmented MP4) • Some CDNs might prefer one method, while others prefer the other

  3. Option 1.1: “Do-Nothing” Approach - 1 • Assumes no HAS awareness in uCDN/dCDN and no additions to CDNI Interfaces • Result: dCDN is not explicitely made aware of the relationship between chunks (unaware of which files make up Content Collection) • Means that dCDN will have to store individual files and can’t ‘bundle’ files in any way • (Possible exception: in case content is fragmented and manifest file contains byte range requests)

  4. Option 1.1: “Do-Nothing” Approach - 2 Effect on CDNI Interfaces: • None Advantages/Drawbacks: + No changes to CDNI Interfaces necessary - dCDN is forced to store all chunks as individual files

  5. Option 1.2: “Allow single file storage of fragmented content” - 1 • dCDN might prefer to store fragmented content as single file on surrogates • Reduces file management overhead • Two options: • Acquire content as part of single file (see section on Content Acquisition) • Merge the different chunks together and place them in the same container (e.g. fragmented MP4) • Requires dCDN to be fully HAS aware • Type of HAS used • Name and type of manifest file etc.

  6. Option 1.2: “Allow single file storage of fragmented content” - 2 Effect on CDNI Interfaces: • CDNI Metadata Interface: Add fields for indicating the particular type of HAS (e.g. MPEG DASH or HLS) that is used and whether segments or fragments are used • CDNI Metadata Interface: Add field for indicating the name and type of the manifest file(s) Advantages/Drawbacks: + Allows dCDN to store fragmented content as a single file, reducing file management overhead - Complex operation, requiring dCDN to be fully HAS aware

More Related