HLS requirements

Review these specifications for live stream encoders compatible with Media Services Live for HLS.

This table shows the MIME types for HTTP Live Streaming.

File Extension

MIME Type

Description

.m3u8

application/vnd.apple.mpegurl

playlist file that contains a path to a media file or directory of media files and meta information about the playlist

.ts

video/mp2t

video stream file

.m4s

video/iso.segment or video/mp4

fragmented media segment

.m4a

audio/mp4

audio file encoded with advanced audio coding

.m4v

video/mp4

video container format

.mp4

video/mp4

video segment or media initialization segment

Refer to the Apple Developers page for additional details on HLS playback on iOS-based devices.

📘

Media Services Live for HLS does not honor live encoders’ HTTP DELETE requests. While Media Services servers will return a 200 HTTP status code, the content is not actually deleted as requested.

Master playlists

A master playlist contains a list of sub playlists. Sub playlists contain extra tags for stream duration, cacheability, etc.

The file names index.m3u8, playlist.m3u8, and master.m3u8 are treated as master playlists by the edge network. Akamai makes special provisions in the configuration metadata to post the playlists directly to persistent storage.

Apart from these default names, you can create a distinct name for the master variant playlist using these guidelines:

  • Enter one filename per line.
  • File names can contain any of the following characters: a-z,A-Z,0-9,_, and -. They should have the extension .m3u8.
  • The characters * and ? are treated as wildcards.
  • File names are case-sensitive.

Primary and backup HLS stream URLs

You set the publishing hostname and path for a stream in your encoder. You can publish with a relative path as well as an absolute path. Publish the same HLS streaming content simultaneously to primary and backup paths to ensure stream availability.

Refer to Publish HLS streams for syntax.

The playback information is embedded in the variant .m3u8 file.

Upload order

In accordance with the HLS recommendation, encoders must upload all required files for a specific bit rate and segment before proceeding to the next segment. The encoder should only move to the next segment after the previous segment has been successfully uploaded or after the segment duration time has elapsed.

With low latency streaming, the encoder uploads fragment chunks and the manifest simultaneously, so the player can start rendering the fragments before the complete segment is uploaded. For additional information, refer to Chunked transfer encoding.

Upload the files and segments for HLS in this order:

  1. Upload .ts, .mp4, .m4s, .m4a, or .m4v.
  2. Upload key file. This is optional.

    Once your key file is published, it is cached for 24 hours. If you need to upload a new key, use a different file name. If you fail to do this, your stream viewers may experience temporary playback failures.

  3. Upload .m3u8.

🚧

Important

Do not proceed to Step 3 until Step 1 succeeds.

HLS qualification checklist

Akamai uses the test cases described in this table to qualify HLS ingest.

Test

Description

Basic streams test

Verify if the first line of the bit rate playlist files is #EXTM3U. Check if bit rate playlist files have the tags #EXT-X-TARGETDURATION, #EXT-X-MEDIA-SEQUENCE.

Verify that the number of streams received is the same as the number of streams expected.

Bit rate playlist alignment.

Verify if the tag EXT_X_MEDIA_SEQUENCE is consistent across playlists (optional).

Bit rate playlist upload interval

Verify that the bit rate playlist upload interval is almost equal to the segment upload interval.

Directory rollover

Verify if directory rollover happens at consistent intervals.

ENDLIST tag when the stream stops

Verify if the EXT-X-ENDLIST is present in the playlist when publishing stops.

Error recovery test (failover to a different entry point – DNS lookup test)

Check if the transition to the secondary entry point is seamless.

Error recovery test (streams reconnect to same entry point)

Verify the .ts segment IDs on reconnect.

HTTP request type

Verify that the HTTP request type for the ts segments is either PUT or POST.

Long duration publish

Verify playback and analyze the stream publish after 48 hours of publish.

Master playlist upload interval

Verify that the master playlist file does not get uploaded too frequently.

Playback

Verify playback on QuickTime, Safari, and iPad. Refer to Primary and backup HLS stream URLs

Segment numbering

Check that the segment numbering is not close to (2^32)-1.

Segment retry on 5xx error and verify the retry interval

Trigger a 5xx response to the encoder by modifying the delivery-hostname for the stream-id.
Trigger a 5xx response by modifying the forward target host and verify encoder behavior.

Segment upload interval

Verify if the segment upload interval is almost equal to the advertised values.

Session ID verification.

Verify that the master playlist file does not have session IDs mentioned in the bit rate URLs.
Verify that the session IDs are same across all bit rates.

ts segments and bit rate URL

Verify that the segment numbers are sequentially increasing.

Verify is response received is 200 by requesting random ts segments (first one, last one, and a middle one).

Verify that EXT-X-MEDIA-SEQUENCE corresponds to first segment in the bit rate playlist.

Verify if any of the #EXTINF has negative values in the bit rate .m3u8 files.

User-Agent string

Verify if the encoder is sending a valid User-Agent string.

Verify if the session ID and directory path is unique during republish.

When an encoder stops the publish and starts another one, the path must be unique.

For details, refer to HLS requirements.


Did this page help you?