Encoder requirements for OTT

Over-the-top (OTT) is the term used for the delivery of film and TV content through the Internet, without requiring users to subscribe to a traditional cable or satellite pay-TV service. OTT delivery of sports, news, entertainment and more has become a global phenomenon. OTT enables you to provide a reliable, scalable, and high quality viewing experience. Qualify your encoder for Akamai Over-the-top (OTT) streaming.

Akamai supports only Apple HLS as the ingest format for an OTT stream. However, this does not limit Akamai’s ability to transcode and package stream content in other supported formats such as DASH.

Mandatory features

These are the mandatory features for Akamai OTT qualified encoders:

Translate SCTE-104 to SCTE-35 in TS: Encoders translate SCTE-104 messages into SCTE-35 in TS segments, and also extracts the SCTE-35 data in the EXT-X-DATERANGE tag format.
Support SCTE-35 TS to HLS/DASH/Adobe Primetime: SCTE-35 TS to HLS/DASH/Adobe Primetime (SCTE 67, Roger Pantos, Adobe Primetime specification) compliant cue tags and messages as per SCTE 67, HLS specification (Roger Pantos version 19 for EXT-X-DATERANGE).
NTP synchronized: The NTP daemon must be configured for dynamic polling interval as per RFC 5905 to maintain a maximum clock drift up to 1 PPM (0.0864 seconds or 86.4 ms or 3 frames in a 30 fps video). The NTP daemon must be configured to an NTP server chain in public stratum with a node value of 4 or lower.
Support HTTP headers with 64-bit UTC time: As part of the enhanced reporting for HTTP ingest formats, encoders should include HTTP headers that consist of a 64-bit UTC time (GMT) at the start of each media segment.
Support HTTP chunk encoding: Encoders also support HTTP chunk encoded output in addition to normal HTTP posts.
Support editable fields: In order to use beacons, encoders must provide these editable fields to use beacons:
- A field to enter the post host name for the beacons.
- A field to enter the update frequency for each streaming beacon. The recommended value is 30s through 300s.
- A field to enter a unique encoder ID that Akamai generates, when you enable the BOSS/BOCC (Broadcast Operations and Support System/Broadcast Operations Control Center) feature on Control Center.

Optional features

These are the optional features for Akamai OTT qualified encoders:

Support one-second segment duration: The encoder specifically supports segments of sizes as short as 1 second in duration, typically supporting {> 10s, 10s, 8s, 6s, 5s, 4s, 3s, 2s,1s}.
Support I-frame playlists: An I-Frame only playlist is almost identical to a regular playlist. The only difference is that I-Frame playlists do not have an intrinsic duration. Instead, they represent an instant in time. In an I-frame only playlist with the EXT-X-I-FRAMES-ONLY tag, the EXTINF tag duration actually refers to the "span" of the I-frame. This is the time between the presentation time of the I-frame in the media segment and the presentation time of the next I-frame in the playlist (or the end of the presentation if it is the last I-frame in the playlist).

Publish time stamp

Encoders should publish the acquired source time stamp in the HTTP header format at the beginning of every segment. The capture and publish time-stamp should be relevant for the first frame of the segment. All segments should start with an IDR frame (key frame).

📘
HTTP headers are in epoch time and not in milliseconds.

HTTP header	Description
`AKAM-ENC-CONTENT-CAP-TIME`	Encoders publish source time-stamp associated with the acquired content in this HTTP header.
`AKAM-ENC-CONTENT-PUB-TIME`	Encoders publish the time-stamp associated with the publishing content in this HTTP header. This is the time when the HTTP segment upload is initiated by the encoder application. This time-stamp is refreshed for all retries done by the encode application. The receiving system uses this time-stamp to verify NTP synchronization status.
`AKAM-ENC-EXPECTED-PIPE-DELAY`	Encoders publish the typical fixed end-to-end delay time of the encoding system in this HTTP header.

This system of time stamps are needed to flag any timing issues due to NTP synchronization failures. For example: Delta (AKAM-ENC-EXPECTED-PIPE-DELAY - (AKAM-ENC-CONTENT-PUB-TIME - AKAM-ENC-CONTENT-CAP-TIME)) can indicate if the upload is a long retry or the first attempt.