Details

1. Prepare content

All content must be reasonably similar in order to be stitched into a continuous channel. For each channel a content template is used to define how the output linear channel will look when it comes to signaled tracks, codecs, languages, bitrate, variant names etc. The content template format is described in the Content Templates section.

For flexible content handling, the restrictions are rather loose and should be fulfilled by much content out there

1. Constant video GoP duration, such as 1.92s, 2s, or 2.002s
2. Constant sample duration (frame rate) in all input MP4 files
3. Compatible tracks in all ingested content that should go into one channel. The track matching is described in the Asset Track Matching section

These requirements are quite relaxed compared to the early restrictions (v0.6.x) that required that audio and video had exactly the same segment duration, and segments were built by combining these.

2. Store content as ESF VoD assets

To get content in ESF/CMAF format, one can either use a recording or ingest video using the Edgeware ESB3005 tool CMAF/ESF. One can also ingest using the new ESB3021 ew-vodingest tool.

However, it is beneficial that all VoD assets are very similar when it comes to resolutions, bit rates, SPS/PPS etc., so using a fixed encoding recipe is recommended.

To make it possible to combine sources with somewhat different video parameter sets, the parameter sets are extracted for each asset and signaled in band. This makes it possible for most players to handle possible changes in encoding parameters. Signaling-wise, this means that our output is compatible with inband parameter codec configurations corresponding to avc3 and hev1, respectively.

Alternatively, DASH OnDemand assets may be used.

3. Create channels as schedule playlists with ad periods

The live channels are defined by some fixed parameters and a schedule that may be dynamically updated via a REST API.

All entries in the schedule are specified in units of GoPs. The playlist supports arbitrary GoP intervals of an asset and will wrap if going beyond end of asset. One can also specify the full asset by giving length=0, or specify to start with the n last GoPs by specifying the negative offset -n.

A slate or filler asset of duration 1 GoP, may be set to length N and thereby repeat N times.

An important part is to be able to split and rebuild output segments from input GoPs. For example, one may have 4s segments with 2s GoPs as input and desire 6s segments as output. This is achieved by splitting the input segments into GoPs and build new segments from these GoPs. This is specified by the parameters for a channel: gopDurMS=2000 and nrGopsPerSegment=3. At an ad boundary, the actual duration of a segment will be changed so that an ad period always start and end at a combined segment boundary. For this to work, each ad asset and asset between ads must consist of at least nrGopsPerSegment GoPs.

An ad in the schedule is indicated by a non-zero scteEventID value. If two “programs” in a row have the same scteEventID, they are considered to be one ad “pod”, with a CUE-OUT at the start of the pod, and a CUE-IN at the end of the pod. When updating the schedule to remove ads, it is important that full pods are removed. If scteEventID is set to -1, a unique event ID corresponding to the GoP number where the ad break starts will be inserted in the output.

The assets referred to in the schedule need to be located and fetched. This done by creating a map that maps assetIDs to assetPaths. An initial mapping can be provided in config file, but more importantly, the asset paths can be updated using a REST API. The assetPaths supports can be mounted file systems, HTTP URLs, and S3 URLs. The metadata of the assets is loaded in an LRU cache as part of the scanning of the schedule of a schedule. Asset paths can be removed from the asset cache by sending a DELETE command via the REST API, but only if the assets are not included in any schedule.

4. CBM HTTP interface for repackager integration

The EW repackager gets upstream live channels via an HTTP interface towards CBM. The HTTP interface provides list of channels, content_info.json, segment_times.json and actual “live” segments. Since ew-vod2cbm provides the same interface as the CBM, no change is needed in the repackager to support ew-vod2cbm.

The CBM segment_times.json data should be enough for signaling ads. The emsg boxes in segments should not be needed and are not added to the segments.

5. Repackager configuration

An ingestServer needs to be configured in order for the repackager to know where to fetch the vod2live channel. That configuration is described in Configuration Repackager.

Finally, content should now be available from the repackager as

 https://<server>/__cl/cg:vod2live/__c/<channel>/__op/default/__f/index.m3u8

where the cg:vod2live is the channel group for the vod2live channel.

6. Schedule update of a channel

Once a channel is created, its top level parameters cannot be changed. However, it is possible to change the schedule of a channel, but replacing it. The replacement must be done in a careful way to achieve a manifest which are consistently changed over time. There are more details on how to do this in the Dynamic Channels How-To guide.