Overview

These two workflows can be built leveraging two configuration options both available as of version 1.195.0 of our API:

1. Segment naming obfuscation pattern (for preview)
2. The API endpoint RestLiveManifestTimeshift (for preview and Programme intervals)

Segment name obfuscation

This feature can be enabled by configuring the segmentNamingTemplate property of a given Muxing in our API.
Example Java code:

muxing.setSegmentNamingTemplate("segment_%number%_{segment_rand_chars:4}.ts");

• %number% is required for the sequence number of the segment
• {segment_rand_chars:4} is the placeholder for the random characters in the segment name. Each segment will have different random characters. 4 is the number of random characters inserted for the placeholder (the maximum and default is 32).

📘

Useful to know

The placeholder {rand_chars:4} is also possible, but it will assign the same random characters for all segments. This is useful to prevent overwritten segments when the same output folder is used.

Reset Live Manifest Timeshift

When issued, this option will removes older segments from live manifests. This resets or reduces the time-shift (DVR) window.
The residualPeriod value is configurable and will determines how many seconds will remain in the time-shift window.
The original time-shift window does not change. Newer segments will be added and not removed from the
manifest until the original time-shift duration is reached again.

❗️

Be informed

Currently, only HLS live manifests are supported.

Preview workflow

To implement a “Preview Feature” for the Live Encoder, you will need to use both options described above. This workflow allows the first section of a live event stream to be published to a small subset of an audience, this could be to perform a signal line up and ensure all video and audio signals are levelled correctly and free of error. In this workflow customers would not want the main audience to have access to the preview content.

Single Manifest Concept

With this approach it is possible to use the same manifest for both the preview and live event phases. To go live there is a new ResetLiveManifestTimeShift API call, that removes all the media segments from the manifest so that after sharing the manifest with viewers after the API call, the segments that are part of the preview phase are not present anymore.

Usually, segments are numbered and people can easily guess the URLs of segments in the preview phase (e.g.: segment_0.ts, segment_1.ts, .., segment_100.ts). To prevent this “guessing” of preview phase segments we added the segment namining obfuscation feature. Using this feature adds a random text as part of each segment name and it’s almost impossible to guess the segment URLs give a certain segment number. (e.g. seg_e466d03bce_0.ts, seg_bd5558d871_1.ts, .. seg_55d32aaec7_25.ts).

How to set-up the Live Encoding

First, make sure the Segment Naming Obfuscation template is used in the Live Encoding configuration.

The following sequence diagram illustrates the whole “Preview” workflow:

1. The Streamer starts ingesting RTMP, SRT, or Zixi into the Live Encoder
2. The “Preview Phase” starts and the Encoder starts uploading the manifest files and media segments
3. To “Go Live” the Streamer calls the ResetLiveManifestTimeShift endpoint
4. The Encoder removes all old segments from the HLS manifest files
5. The Streamer can share the manifest URL with the Viewers
6. The Viewers can start watching the manifest and don’t have access to the media segments that were part of the “Preview Phase”. Thanks to the segment naming obfuscation, the URLs cannot be guessed by looking at the segment sequence numbers.

Programme DVR Intervals

For a 24/7 live linear channel, you may wish to use the ResetLiveManifestTimeShift endpoint to ensure that viewers are only able to view a DVR that relates to the current live programme, with previous programmes perhaps not available for Catch Up or only available as VOD at a certain later moment in time.