HTTP ingest recommendations
Recommendations for encoders delivering streams over the HTTP protocol in Media Services Live.
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
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.
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.
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.
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 after restart
Encoders shouldn’t reuse segment numbers after a restart. 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.
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.
Video encoding (HLS)
Akamai tests support any valid codec regardless of the profile.