HTTP ingest requirements
Configure your encoder to stream media over the HTTP protocol.
You can ingest your content using the HyperText Transfer Protocol (HTTP) ingest formats HLS, HDS, DASH, and CMAF. Click the associated link to learn more about the requirements and recommendations for each format. To use MSL HTTP ingest, ensure that your encoder meets these requirements.
Ingest Rate Limiting
When you publish MSL 4 streams to the shared infrastructure, your encoder needs to adhere to these rate limit guidelines. If you exceed these limitations, an error response will be sent to the encoder. To prevent disruption to stream delivery for your viewers, configure your encoder according to the Ingest limits.
Warning
To prevent overloading the shared infrastructure, there are limits to the number of events allowed per
streamID
. The.m3u8
file and the video segment are counted individually as events, therefore every request for a video would be the equivalent of two events. When you have a master variant playlist, that also adds to the event count. To avoid exceeding the event threshold limit, create a newstreamID
for each channel that serves your streaming media content.
Tip
In accordance with industry standards, a media segment duration should range between 2 and 10 seconds. Longer media segments are less nimble, resulting in slower transfer times and delayed bitrate switching.
Bitrate and playlist
Confirm that the first line of the bitrate playlist files is #EXTM3U
.
Check that the bitrate playlist files contain the #EXT-X-TARGETDURATION
and #EXT-X-MEDIA-SEQUENCE
tags. Ensure that the tag EXT_X_MEDIA_SEQUENCE
is consistent across playlists.
DNS lookups, upload retries, and timeouts
Encoders must perform DNS lookups whenever an error occurs. Any time there is an upload error, server abort, connection timeout, or HTTP timeout, encoders should perform a DNS lookup to ensure that they continue to be connected with the appropriate server. If the entry point sends a Connection=close header in the response, then the encoder needs to re-resolve the domain (for all formats including RTMP).
This table summarizes how failure conditions are handled.
Error Condition | Object Type | Handling |
---|---|---|
-TCP connection attempt timeout -Abort midstream -TCP send or receive timeout | Manifest | Re-resolve DNS on each retry and retry indefinitely. |
-TCP connection attempt timeout -Response timeout -TCP send or receive timeout | Data (media, timed text) | Re-resolve DNS on each retry and continue uploading until n seconds, where n is the value of segment duration. After it reaches the segment duration value, drop the current data and continue with the next segment data. If segment duration is low (such as 2s or 1s), uploading might exceed the segment duration time and the encoder will back up. |
HTTP 403, 400 | Any | Do not retry - display error reason. |
HTTP 5xx | Data (media, timed text) | Re-resolve DNS on each retry and continue uploading until n seconds, where n is the value of segment duration. After it reaches the segment duration value, drop the current data and continue with the next segment data. If segment duration is low (such as 2s or 1s), uploading might exceed the segment duration time and the encoder will back up. |
HTTP 5xx | Manifest | Re-resolve DNS on each retry and retry indefinitely. |
Extensions and mime types
Extension | Mime type |
---|---|
.f4m | application/f4m |
Content (fragment) files and .bootstrap file | video/f4f |
IDR frame alignment
Stream encoders should produce IDR frame alignment across bitrates for the duration of the targeted segment. For example, if an encoder is generating maximum supported 10-second segments, then every 10 seconds there must be timestamp-aligned IDR frames across streams. There must be an IDR frame at the beginning of the segment; otherwise, the audio and video might deviate and drop out of synchronization. IDR frames must be at the very beginning of the segment, not in the middle or end of the segment.
Industry compliance
If you are using | Your encoder must be compliant with |
---|---|
HLS | HTTP Live Streaming specification |
HDS | Adobe HTTP Dynamic Streaming specification |
DASH | DASH Industry Forum guidelines |
CMAF | HTTP Live Streaming specification and DASH Industry Forum guidelines |
Marking playlists complete
At the end of a list stream, encoders should mark the stream (for HLS format) as complete by inserting the EXT-X-ENDLIST
tag into the .m3u8 playlist file. This ensures that the device behaves appropriately when it comes to the end of the stream. The EXT-X-ENDLIST tag prevents unexpected playback issues when the device comes to the end of the stream. This tag ensures that viewers have a consistent and high-quality playback experience. It is also required for Live-to-VoD generation.
Publish URL format
Encoders should be capable of using a POST URL with the entrypoint hostnames and pathnames in this format:
Stream Type | Hostname |
---|---|
Primary | p-ep{stream_id}.i.akamaientrypoint.net |
Backup | b-ep{stream_id}.i.akamaientrypoint.net |
Get details for each protocol in these topics:
PUT or POST request
Encoders should be capable of uploading generated content, video segments, and playlist/manifest files using multiple PUT or POST requests. Each segment should be uploaded in a separate request. Use a persistent connection for these requests.
Encoders should not send DELETE requests.
Flexible segment numbering
All previous restrictions requiring sequential segment numbers have been lifted. However, 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.
The path and segment number are treated as one entity. Archived data gets corrupted when the encoder restarts and attempts to use the previous sequence number and path.
https://p-ep{stream_id}.i.akamaientrypoint.net/<stream_id>/<uniquesourcename>/<sessionID>/<bitrateID>/<OPTIONAL_PATH>/<somename>_<sequence#>.ts
The segment number must be extractable from the upload URL using regex. Ensure that you separate the string and the numbers of a segment. Segment names can contain alphanumeric characters and the hyphen (-) as delimiters. Other special characters are not supported. You cannot use symbols, special characters, or alphabets.
The encoder must not introduce any other changing parameters such as frequently changing time stamps in the URL path. For example, if the URL path format was: eventname/sessionID/bitrateID/post-timestamp_sequence#.ts
Introducing the post-timestamp parameter creates another set of directories for each .ts
file — a condition that would cause excess directories and possible timeouts over long periods of time.
Ideally, the path would appear as follows: eventname/sessionID/bitrateID/somename-starttime-sequence#.ts
In this case, only the sequence#
changes, which is the desired behavior.
User-Agent string
Encoders must include a User-Agent header (which provides information about brand name, version number, and build number in a readable format) in all posts. For example, Vendor Model Version#
.
URL configurability
Encoders should allow specification of a POST server address, also known as a POST URL, upload URL, or ingress URL. It's also recommended that encoders allow the specification of a playback address, also known as a playback URL or retrieval link. For details, see Primary and backup HLS stream URLs.
Use Live-to-VoD
The Live-to-VoD feature enables you to convert live streams to video-on-demand assets.
For Live-to-VOD to properly function with HLS, the encoder must insert an #EXT-X-PROGRAM-DATE-TIME tag after a discontinuity event.
For example: #EXT-X-PROGRAM-DATE-TIME:2017-01-19T08:04:00.624Z
The EXTINF
tag is also mandatory for Live-to-VOD.
For DASH, Live-to-VoD is supported only for sequential segment indexing and not for time-base indexing.
Updated 5 months ago