CMAF requirements

Common Media Application Format (CMAF) is an MPEG specification that aims to provide a single encoding and packaging of segmented media objects for delivery and decoding on your devices in adaptive multimedia presentations.

Today, HLS specifies use of TS (transport stream) file containers, while DASH, although allowing TS, almost uniformly uses ISO Base Media File Format (ISOBMFF) in practice. To reach an HLS and DASH audience, content distributors must encode and store the same audio and video data twice - once wrapped in TS containers and again wrapped in ISOBMFF. The same files that have the same content, cost twice as much to package, twice as much to store on origin and compete on Akamai edge caches for space, thus reducing the delivery efficiency. CMAF solves this problem and promotes the use of the same media segments in both HLS and DASH.

This topic explains the recommended and required specifications for live stream encoders compatible with Media Services Live for Common Media Application Format (CMAF). Compatible encoders should be capable of successfully streaming a live event, but meeting these guidelines does not guarantee performance of any encoder on our network.

📘
Media Services Live for CMAF does not honor live encoder HTTP DELETE requests. Although Media Services servers return a 200 HTTP status code, the content is not actually deleted as requested.

Master manifest

The filenames index.m3u8, playlist.m3u8 and master.m3u8 are considered master playlist names and are hard-coded into the system. Use these filenames only for the master variant playlist. You can post these playlists only during the encoding session startup. Akamai makes special provisions in the configuration metadata to post the playlists directly to persistent storage.

Encoders can upload the .mpd file once, as per the standard, or at any arbitrary interval. The content of the file can change on each upload, but that is optional.

The URL syntax is:
https://{hostname}/{format}/{streamID}/{eventname}/{anyname}.mpd
https://{hostname}/{format}/{streamID}/{eventname}/{anyname}.m3u8

For example:
https://p-ep500002.i.akamaientrypoint.net/cmaf/500002/test79/manifest.mpd
https://p-ep500002.i.akamaientrypoint.net/cmaf/500002/test79/master.m3u8

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

Enter one filename per line.
Filenames can contain any of the following characters: a-z,A-Z,0-9,_,and -.
There should be two distinct manifests with .mpd and .m3u8 extensions respectively.
The characters * and ? are treated as wildcards.
Filenames are case-sensitive.

Publishing and playback URLs

Configure your encoder to generate playback URLs for CMAF.

URL Path Element	Description
`stream_id`	Unique identifier for the stream provided by Akamai. The stream ID must be identical between your primary and backup streams. You can find the stream ID in Control Center on the Manage Live Streams and Stream Details pages.
`uniquesourcename`	This is a nomenclature change of the current event name. This is the first URL path component following the `stream_id.` Use this name to identify the current media source from a set of sources ingesting into Akamai.
`sessionID`	This is needed to distinguish different encoder restart points and make sure that path duplications do not overwrite the media objects across the restart points. For example: for a 24x7 source, a good recommendation is to have a string with the date time string at the time of connection. `<stream_id>/<uniquesourcename>/20160628T18h22m10s/` or `<stream_id>/<uniquesourcename>/T1467082295/`
`bitrateID`	A unique path element to distinguish media segments specific to a bitrate. It is mandatory to have this path element. Bitrate in kilo bits of the corresponding media object should be extractable using a regular expression such as: `/rend4000K/`, `/master_3000K/`, `/bitrate3000K/`.
`OPTIONAL_PATH`	Other fixed pathnames for specific work flows that are not mandatory. For software releases prior to Media Services Live 4.0, this is the directory rollover pathname. Media Services Live 4.0 and above does not require directory rollover. You can upload all of the segment objects for a specific bitrate into the same URL path. However, to ensure compatibility the encoder should continue to support both directory rollover as well as non-rollover options in the short term. NOTE: When you are using directory rollover, set the rollover interval to a value between two and six hours. Your segment length and directory rollover settings must reflect this. For example, if your segment length is the maximum supported 10 seconds and your directory rollover setting is 2000 segments, your rollover will occur every 5.5 hours. If your segment length is 4 seconds and the rollover setting is 2000 segments, rollover will occur every 2.2 hours.

Refer to Publish CMAF streams for syntax.

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

PUT and POST requests

Encoders should be capable of uploading generated content, video segments, and playlist/manifest files using multiple PUT and POST requests. Each segment should be uploaded in its own request. It is preferable to use a persistent connection for these requests.

Upload order

Refer to these guidelines:

CMAF qualification checklist

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

Test	Description
Basic streams test (DASH)	Check that the `.mpd` file is downloadable. Verify that the `MPD@type` attribute is present and its value is `dynamic` (not static).
Basic streams test (HLS)	Verify if the first line of the bitrate playlist files is `#EXTM3U`. Check if bitrate 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 that the tag `EXT_X_MEDIA_SEQUENCE` is consistent across playlists.
CMAF supported segments or bitrate URL file	Check that the segment numbers are sequentially increasing. *Note that if you’re using flexible segment numbering, you can ignore the sequence of the segment numbers. However, you need to ensure the segment names are unique.* Verify if response received is 200 by requesting random `.ts` segments (first one, last one, middle one) from the playlist. Check that the `EXT-X-MEDIA-SEQUENCE` corresponds to first segment in the bitrate playlist. Verify whether any `#EXTINF` has negative values in the bitrate `.m3u8` files.
DASH spec conformance	Verify that the `@publishTime` and `@availabilityStartTime` attributes are present. According to the spec, for `@type=dynamic`, these attributes must be present. Check if the `@minimumUpdatePeriod` attribute is present. Refer to DASH requirements.
Error recovery test	Verify the `.ts` segment IDs after reconnect. The encoder must use the Testnet DNS. If it uses only a host file for resolution, it will not work and will fail.
Error recovery test (failover to a different entry point – DNS lookup test)	The transition to the secondary entry point should be seamless.
Error recovery test (failover to a different EP – DNS lookup test)	The transition to the secondary EP should be seamless.
Error recovery test (streams reconnect to same EP)	Verify if the streams reconnect successfully to the same EP.
HTTP request type	Check 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 publishing.
Master playlist upload interval	Verify that the master playlist file does not get uploaded too frequently. See Upload order for HLS and Upload order for DASH.
MPD@availabilityStartTime is constant	Verify that the value of the attribute `MPD@availabilityStartTime` does not change when you publish. The availability start time should not change during the course of publishing, unless restarted on purpose.
MPD file update interval	Check that the `.mpd` file is not uploaded too frequently or too late. An update interval of about 30 seconds is ideal. Failure in the test will usually trigger the team to evaluate more deeply and consider why the vendor is sending frequent MPD updates.
Playback	Verify playback URL syntax. Refer to Play HLS streams, Play DASH streams, and Play CMAF streams.
Segment names	Check that the segment names in the URL are according to the ones advertised in the `.mpd` file. If segments uploaded are not the same as advertised by the derived MPD calculation, this test will not pass.
Segment retry on 5xx error and verify retry interval	Check the retry behavior of the encoder after receiving a 5xx response code. Expect the encoder to retry the segment within the segment duration. Verify that the encoder re-tries a segment at least once when any other 5xx response is sent back.
Stream alignment	Check that the timestamps across representations / bitrates are aligned.
Unique path on republish	When an encoder stops the publish and starts another one, the path should be unique (not mandatory for MSL 4).
Upload interval check for bitrate playlists	Verify that the bit rate playlist upload interval is almost equal to the segment upload interval.
Upload interval check for segments	Verify that the segment upload interval is almost equal to the advertised values.
User-Agent string	Verify that the encoder is sending a valid `User-Agent` string. The `User-Agent` string format should be similar to Vendor Model version #.

For additional details, refer to HTTP ingest requirements.