HTTP ingest recommendations

Audio encoding

For audio encoding, encoders must be capable of encoding a minimum of 64 kbps. The .aac extension is for audio only streams.

To provide a seamless audio experience, use encoders capable of encoding the audio track of all renditions to 64 kbps. This avoids audible clips or other distortions when the device switches from one rendition to another.

To provide higher quality audio, use encoders that can encode audio tracks at higher bitrates than the 64 kbps required for the lowest rendition. By encoding at higher bitrates, the user should experience higher fidelity audio but may experience audible clips or other distortions when the device switches from one rendition to another. Before initiating a live event, ensure that any quality issues experienced when switching between the required 64 kbps audio-only stream and higher quality streams are acceptable.

Entire event playlist or index upload

When possible, encoders should be able to upload a single .m3u8 playlist file that includes a list of all .ts segments generated after the event completes. This is helpful for video on demand playback after the live event. To use this, encoders should implement the end of stream tag (EXT-X-ENDLIST) in the final manifest.

Events broadcast using encoders that are incapable of uploading a complete playlist file upon event completion might only have a limited playback window available after playback, based on the contents of the final playlist uploaded during the event.

Logging and reporting

To improve troubleshooting, set up encoders to log errors and report them. Encoder issues are easier to be resolved and avoided in the future if logs are available for review.

Parallel uploads

To improve throughput, set up the encoder to upload multiple bitrates in parallel using multiple sockets. Encoders that cannot use multiple sockets to upload in parallel might experience poor performance because of bandwidth contention.

Security

Akamai recommends that encoders encrypt segments using the AES-128 encryption algorithm in compliance with the Apple HTTP live streaming protocol. For encrypted content with rotating keys, the key name should have a monotonically increasing integer component that can be reset if the event or directory component changes. Encoders that are unable to provide this level of security should not be used for protected content. Unsecured content delivered on the Apple HTTP live streaming protocol can be easily recompiled and distributed.

Segment configurability

Encoders should be capable of configuring the number of segments per playlist, the number of segments per folder, and the duration of each segment. While not required, this level of flexibility is helpful for situations that require changing these attributes.

Encoders that cannot configure these attributes will not be flexible enough to satisfy specific requirements of certain situations. Common reasons to change the duration are to lower the amount of hand-wave latency or lower the number of segment files being created for caching or hardware performance reasons.

Segment numbering

The encoder should maintain unique segment numbering across restarts for example, by implementing a time-based segment numbering system. Viewers may be served stale content during an event if segment numbers are reused. Fragment numbers must not repeat when an encoder restarts. To prevent this, derive fragment numbers from current epoch time. This results in always increasing fragment numbers and prevents overwriting data in the storage system.

Encoders shouldn’t reuse segment numbers after a restart. If the encoder restarts or recovers from an outage, it should create segments starting at the next available sequential increase or at a timestamp that has not yet been used.

📘

If you’re using flexible segment numbering, unique segment renumbering isn't necessary after a restart. However, encoders shouldn't reuse segment names, as they need to be unique.

TLS Compliance

To improve security and reduce potential vulnerabilities, Akamai supports TLS 1.2 and above in accordance with Internet Engineering Task Force recommendations.

Video encoding (HLS)

Akamai tests support any valid codec regardless of the profile.

HTTP digest authentication

MSL 4 supports HTTP digest authentication as an option, and encoder vendors that want to support it need to adhere to the RFC 7616 specification.

MSL 4 supports these hash algorithms:

• SHA-256. The Secure Hash Algorithm SHA-256 is a type of cryptographic hash function that generates a 256-bit (32-byte) hash. A cryptographic hash is like signature for a text or a data file.

• SHA-512. A cryptographic hash function that when applied to the provided input results in a 128-digit hexadecimal number that is highly unlikely to match the value produced for a different input.

• MD5. The MD5 message-digest algorithm is a widely used hash function producing a 128-bit hash value.

If you want to use HTTP digest authentication, ensure that your encoder provides a way to select one of the hash algorithms and fields to enter the user name and password. The encoder should support user names that have a minimum of 4 and a maximum of 50 characters. The encoder should support passwords that have an uppercase letter, a number, and a special character, a minimum of 4 and a maximum of 50 characters.

You'll set this up when you Create your Media Services Live streams.

🚧

You cannot enable Ingest Acceleration and HTTP digest authentication at the same time.

Ingest acceleration

Media Services Live 4 provides the optional Ingest Acceleration feature. It resolves encoder to Akamai ingest issues and provides more stability and reliability over the first mile of ingest. To use the Ingest Acceleration feature, you need to install the proprietary Akamai software. The target system needs to meet these requirements:

• The system needs to be running Linux.

  We no longer offer support for IAS on Windows.

• Allocate at least two (2) GB memory for each IP address and port.
• You can manipulate the hostname and path on the encoder.
• You can specify the port number within a POST or PUT operation on the encoder.
• For best performance, IAS should be installed on the same system acting as the encoder. The local host is more reliable than other network computers.

If you can't install third-party software on your encoder, then install IAS on a separate computer that resides as close to the encoder as possible.

Learn more about how to Configure ingest acceleration (IAS).

Chunked transfer encoding

With chunked transfer encoding (CTE), the encoder sends data to the player in a series of chunks instead of waiting until the complete segment is available. CTE is available in HTTP 1.1. In CTE, each chunk is preceded by its size in bytes. The transmission ends when a zero-length chunk is received. To upload files more efficiently use HTTP chunked transfer encoding.

This example shows data encoded using CTE. Note the Transfer-Encoding: chunked header.

The Content-Length header is omitted in CTE and at the beginning of each chunk, you should add the current chunk length in hexadecimal format, followed by \r\n and the chunk, followed by another \r\n. The terminating chunk is a regular chunk with zero length. It is followed by the trailer, which may be empty or consists of a sequence of entity header fields.

A standard CMAF media segment is encoded with a single moof and mdat atom. The mdat holds a single IDR (instantaneous decoder refresh) frame, which is required to begin every segment. This figure shows chunk encoding of a CMAF segment.

To achieve low latency streaming:

• Include HTTP 1.1 chunked transfer encoding in the header for each POST.
• Your encoder should be compliant with RFC 2616.
• You cannot define the content length in the header.
• Chunks should be uploaded immediately once available, not throttled at the beginning of the upload.
• There should be a moof box for every chunk.

Learn more about Low latency for DASH streams.

📘

To enable better monitoring, the encoder can optionally insert AKAM-ENC-CONTENT-CAP-TIME in the HTTP header, which is passed to the ingest server and included in Akamai-Path-Timestamp. The ingest server does not add the encoder timestamp, if the encoder does not set AKAM-ENC-CONTENT-CAP-TIME.