General

• 1: CCMI URLs
• 2: ESF Format
• 2.1: Introduction

1 - CCMI URLs

Edgeware’s origin URL format is called CCMI URLs and is the format that StreamBuilder understands. A typical URL looks like:

http://<server>/__cl/<cl>/__c/<content>/__op/<op>/__f/<pres><ext>

where the different parts are indicated by prefixes starting with two underscores, and where the file extension <ext> starts with a period if present.

The most important StreamBuilder fields are:

__cl : content location with parts prefix:name
       + cg:<live> stands for channel group <live> and denote a group
         of live channels configured with the name <live>
       + s:<vod> stands for a storage path for vod assets
__c  : the actual content or asset path (can contain slashes)
__op : output profile `<op>`, defining the encryption/DRM system or segment addressing
       Segments with different output profiles are not compatible
__f : the file path but also the way to choose a presentation.
      A presentation is a manifest variation, for example exluding some variants.
      The segments can be the same between presentation.
      The extensions ".m3u8" maps to HLS, ".mpd" maps to DASH and "Manifest" or
      ".ism/Manifest" map to MSS

The <pres> part is matched to a presentation configured in repackager. The <live>, <vod>, <op> are also defined in the repackager configuration.

For segments, the URLs are further enhanced with a config_id (for live/catchup), a variant, and a segment number (for HLS and DASH with $Number$)

__f/<cfg_id>/<variant>/<nr>.cmfv
__f/<cfg_id>/<variant>/<nr>.ts

or with a time (for DASH and MSS)

__f/<cfg_id>/<variant>/D<time>.cmfv
__f/<cfg_id>/QualityLevels({bitrate})/Fragments(video={start time})

In addition, there are other possible parts like

__dci : DRM Content ID - an id used to lookup the key from license server
__account : Account to distinguish different tenants

Finally, there are query parameters for time intervals

?startTime=
?stopTime=

and query parameters for variant flags mask

?p=<variant_flags_mask>

In addition, there may also be a part ?pre=1 that triggers ESB3020 - ew-manip.

2 - ESF Format

2.1 - Introduction

ESF is Edgeware’s CMAF-based storage format for both live and VoD content. It saves media data in CMAF tracks, and has additional metadata files. It supports H.264/AVC and HEVC/H.265 video, AAC and AC-3 audio, and wvtt subtitles.

Asset media data

The media data is stored as CMAF tracks in files with extensions “.cmfv”, “.cmfa”, and “.cmft”, for video, audio, and subtitles, respectively. The subtitle format is “wvtt” which is much more storage-efficient than “stpp”.

Asset metadata

The metadata for the assets are stored in two places:

1. a single content_info.json file describing the tracks
2. segment info (.dat) files describing the segments, one per track

Content info

Content info is stored in a file named content_info.json inside the asset directory. It is a JSON file containing enough information about the tracks of the assets, to be able to fill in all information about media tracks in HLS, DASH, or MSS manifests. This includes codecs, languages, time scales, bitrates etc. However, it does not contain information about individual segments. Such information is stored in segment info files.

Segment info

Metadata about the segments are stored in segment info files with extension .dat. There is exactly one such file for each media file.

These files describe the data of the individual segments of the CMAF tracks with a 32-byte entry for each segment:

For VoD assets, an init segment is stored at the start of the file. Its size is given by the Offset of the first media segment in the segment info file.

Commonalities with DASH OnDemand format

DASH OnDemand stores media data in the same type of CMAF tracks as ESF. However, the metadata is stored in other structures.

To describe the asset and its variants, there is a manifest called Media Presentation Description (MPD) which is an XML file with file extension .mpd.

It is similar to the ESF content_info.json file. It has explicit switching groups called Adaptation Sets, but is lacking some other information compared to ESF like video parameter sets which are needed to generate MSS manifests.

Similar to ESF, there is a second structure that contains the information about the segments. In the case of DASH OnDemand, this information is stored in a sidx box inside the CMAF track itself. Its position is at the beginning of the media file right after the init segment, and before the actual media data.

By generating a DASH MPD file, and inserting a sidx box in the media tracks, it is possible to make VoD assets which are both compatible with DASH OnDemand and the ESF format. The new ESB3031 ew-vodingest tool generates such combined ingested files. For DASH OnDemand, a complete WebVTT file is used instead of wvtt segments. That complete WebVTT file is generated by extracting and concatenating all subtitle cues from the wvtt subtitle tracks used in the ESF format.

Live storage using ESF

The main reason to use ESF instead of DASH OnDemand, is that the latter does not support live content, but requires a static structure. In fact, since the sidx box must be placed before the media, it is not even possible to concatenate media segments and write a sidx box at the end. With ESF we can have the same format for both VoD and live.

The SegmentInfo files are separated from the media files and use 32 bytes per segment. These are therefore easy to seek and also to grow, by just adding another 32 bytes for each segment. In the ESB3003 catchup buffer, we store live content in one-minute files.