Recommended LIVE Settings¶
Table of Contents
Encoding audio/video for ABR (Adaptive Bitrate) delivery puts some constraints on the encoding process. Please read Encoding Requirements before you proceed.
The following sections provide a setup that gives the best user experience for the various playout formats. It is a setup that works across a wide range of devices and gives the best experience in varying network conditions.
Unified Origin servers can support millions of simultaneous streams using Content Delivery Networks (CDNs), as for instance Azure, Amazon Cloudfront, Level3, Limelight or Akamai.
The origin generates DASH MPDs and Media Segments consistent with the DASH-IF Implementation Guidelines.
To comply with the requirement described in paragraph 4.7.2 of version 4.0 of these guidelines, we add the UTCTiming element to the MPD when live streaming (as of release 1.7.27):
<UTCTiming schemeIdUri="urn:mpeg:dash:utc:http-iso:2014" value="https://time.akamai.com/?iso"/>
Also, content protection in the form of Common Encryption (CENC) is available.
H.264 Base, Main and High profile may be used. H.265 may also be used as video codec, but in both cases the ingest protocol is the fragmented MP4 Live Ingest protocol.
Mixing profiles is possible, but as outlined in previous link care must be taken so that the different GOPs of the ABR set align.
For audio AAC-LC, HE-AAC, DTS, Dolby Digital or Dolby Digital Plus may be used. See the Factsheet for an overview of supported codecs.
The key frame interval (GOP size) should be two seconds using a closed GOP.
A segment size of two seconds is the optimal size regarding fast bitrate adaptation and efficient encoding.
Two second segments also allow relatively low latency between encoder and player. However, the actual latency depends on how a player buffers and the network connection.
The fixed GOP size should be signaled explicitly, e.g.
|Frames per second||One second GOP||Two second GOP||Three second GOP|
When you create an ABR set and want to mix different AVC profiles you have to make sure that the PTS (Presentation Timestamp) of a GOP across the ABR set are equal.
Using B-frames introduces ‘composition-time-offsets’ and you may have to instruct your encoder to use negative ‘composition-time-offsets’.
The default settings follow the Pure LIVE setup, keeping an archive of sixty seconds with a DVR window of thirty seconds.
However, this may be configured differently. The ingest options are outlined under Options for LIVE ingest, with options allowing DVR window and archive length to be set as well as applying timeshift.
The encoder should insert Coordinated Universal Time (UTC) in order for the origin to use ‘realtime’ Segment addressing and Segment Timeline.
This will allow players to find the last available Media Segment with certainty, so a player can join the ‘live edge’ of a realtime stream without the risk of requesting Segments that are not yet available.
The DASH Live Profile is used as default. The Live profile has the best general coverage as well as allowing for the use of Segment Timeline, which we highly recommend (to understand why, please see the Segment Timeline Article).
However, it is possible to use a different profile with the
mpd.profile option, provided the profile is suitable for Live streaming
(e.g. the DASH On-Demand profile is not). The DVB-DASH and HbbTV profile may
be used but please note the player specifically needs to support these.
We strongly advise against using –mpd.profile. It will signal the use of a certain profile, even if the content isn’t compliant with the chosen profile.
MPD@type is set to ‘dynamic’, indicating the DASH ‘ISO Media Live profile’
(so the @profile is
MPD@availabilityStartTime defaults to unix epoch. The benefit of this becomes evident when Redundancy is required: when both encoders are setup to use Coordinated Universal Time (UTC) then they can start independent of each other, as the Unix epoch is always the same. Also, please make sure that the server is set to use UTC timing. If the server is not set to UTC, this might cause timestamp issues when the stream is started.
To configure your server to use UTC timing, please run the following command line and follow the instructions:
#!/bin/bash sudo dpkg-reconfigure tzdata
Adding for instance 10 seconds will offset the player’s live edge with that amount. An example:
MPD@minimumUpdatePeriod defaults to two seconds (aligned with the
recommended GOP/segment size sent by the encoder). This specifies the smallest
period between potential changes to the MPD, so matching the segment
length is the correct default. However, if needed it can be changed with
MPD@minimumBufferTime is set to ten seconds. This value is how much the client
should buffer, it it not the distance to the live edge.
The buffer time can be changed with
MPD@suggestedPresentationDelay by default is not present in the MPD (except when
you specify the use of the DVB-DASH MPD profile). It is a suggested delay of the
presentation compared to the Live edge. A reasonable value may be 2 to 4 times
the segment duration, but not smaller than 4 seconds in order for the client to
maintain some buffering. The delay can be defined with
If a different segment size is required (not two seconds) then the encoder must be configured to output the larger segment size. However, this will affect playout of other formats as well as concatenation of multiple GOPs into a single media segment as a multiple of two no longer will be possible.
minimum_fragment_length option should not be used with DASH
Live profile as it switches the MPD over to Segment Template using the
$number$ calculation instead of using
$time$, losing all the benefits
of Segment Timeline and generally speaking breaking playout. For more background
please read the following article: Segment Timeline Article.
Presentation Time Offset¶
Under certain circumstances, an encoder may use a different clock than the Dash
specified UTC clock, which introduces time shifts in the player. This can be
mitigated with a @presentationTimeOffset in all SegmentTemplates for the live
stream. This can be specified with
Whether it is an iPhone or iPad, a Smart TV or a connected Home Theater System (or for instance Apple’s tvOS) the best quality audio and video is delivered, together with subtitles and closed captions in multiple languages.
It is recommended that the AVC/H.264 profile used is the High profile rather than the Main profile. You can mix frame rates between variants and any of the typical frame rates can be used but none above 60 fps.
Bit rate variants table:
|Video average bit rate||Resolution||Frame rate|
|365||480 x 270||<= 30 fps|
|730||640 x 360||<= 30 fps|
|1100||768 x 432||<= 30 fps|
|2000||960 x 540||same as source|
|3000||1280 x 720||same as source|
|4500||same as source||same as source|
|6000||same as source||same as source|
|7800||same as source||same as source|
Audio should always be delivered in Stereo, and provided as an elementary stream. See below for a way in which to ensure this. Multi-channel should be provided in Dolby Digital (AC-3) or Dolby Digital Plus (E-AC-3), and in both if using Plus. Multi-channel audio can only be provided in one bit rate however.
Bit rate recommendations:
|Audio channels||Format||Total (kb/s)|
|2.0 (Stereo)||AAC-LC||32 to 160|
|2.0 (Stereo)||AAC-HE v1/v2||32 to 64|
|5.1 (Surround)||Dolby Digital||384|
|5.1 (Surround)||Dolby Digital Plus||192|
|7.1 (Surround)||Dolby Digital Plus||256|
When multiple languages are made available, all the audio profiles have to be present for each language.
When the Origin recognizes the use of UTC timestamps it adds the
EXT-X-PROGRAM-DATE-TIME tag to the HLS m3u8 playlists. A player can then
use this as a basis for its timeline presentation.
The date/time representation is ISO 8601 and always indicates the UTC timezone:
Captions & Subtitles¶
The recommended method for providing live subtitles is through an ISMT stream, which the origin converts to WebVTT for HLS clients. You gain the benefits of multiple language tracks and the ability to name and describe tracks.
The ISMT fragments should contain either WVTT (ISO/IEC 14496-30:2014 - Web Video Text Tracks) or TTML
(Timed Text Markup Language) formatted text, similar to the output of
mp4split. When TTML is
used, there is basic support for WebVTT styling as supported by most HLS players.
For more sophisticated cue styling and positioning, we recommend using WVTT.
For information about preparing VOD subtitles, please read the section on preparing subtitles.
For service failover use the following option to allow the encoder to reconnect:
Further details can be found in the Redundancy section.
A 2 hour DVR window.
--archiving=1 --archive_length=14400 --archive_segment_length=600 --dvr_window_length=720
This is the minimum version of the protocol that allows for multiple language support, WebVTT subtitles and separate delivery of the audio and video tracks.
When grouping the different variants the audio codec family is taken into account, so that the lower bitrate AAC audio streams are combined with the lower bitrate video streams. Both are scaled up to combine the higher quality streams with the higher quality video streams.
Separate variants are presented for video and multi-channel audio (AC-3 and E-AC-3).
No audio only variants¶
No variants in the master playlist are audio-only.
Use elementary audio streams¶
All the tracks (audio, video, subtitles) are delivered separately. The video tracks are formatted in MPEG-TS, the audio in its elementary forms (.aac, .ac3, .ec3) and the subtitles in WebVTT format. Closed captions may be embedded as SEI messages in the AVC video stream.
The media playlists should have a nominal target duration of 6 seconds, a value that is set with the minimum fragment length option. Since we are ingesting fixed GOP media segments we can combine those segments to attain the target duration. Therefore, the minimum fragment length should be an exact multiple of the GOP duration.
For trick play purposes it is best to have more than a single keyframe per media segment. Since the encoder is sending media fragments with a fixed GOP duration the keyframe playlists have a nominal duration of 2 seconds.
Trick play playlists are announced for every video resolution. When multiple tracks are encoded at the same resolution, only the lowest bitrate stream is announced.
Selecting the default video variant¶
By default all the variants are listed (in no particular order) and it is for the player to decide which variant to play.
You can however select the variants that are generated. This is useful when you want to force listing a specific variant at the top of the master playlist.
In this case we want to list the 2MBit variant at the top. This is the first set. The second set is to list all the other variants.
--variant_set='systemBitrate==2000000 || type!="video"' --variant_set='systemBitrate!=2000000 || type!="video"'
In order to create more efficiently sized manifests it is possible and preferable to employ a compression technique named gzip. The example below uses an Apache module called deflate to compress and serve HLS manifests with gzip compression enabled to the client.
# Serve playlists with gzip encoding <IfModule deflate_module> AddOutputFilterByType DEFLATE application/vnd.apple.mpegurl Header append Vary Accept-Encoding env=!dont-vary </IfModule>
Security and TLS¶
Some delivery platforms require manifests to be delivered over TLS (Transport Layer Security). If deployed in this manner it should be following best practices and not employ any known to be insecure cryptographic standards, e.g. RC4, SHA-1 and RSA key sizes should be 2048 bit. Setup of the server to support TLS is however beyond the scope of this document.
The complete list of options to use when creating the server manifest is the following:
--archiving=1 \ --archive_length=14400 \ --archive_segment_length=600 \ --dvr_window_length=7200 \ --restart_on_encoder_reconnect \ --hls.client_manifest_version=4 \ --hls.no_audio_only \ --hls.no_multiplex \ --hls.minimum_fragment_length=60060/10000 \ --fixed_gop=20020/10000 \ --variant_set 'systemBitrate==200000 || type!="video"' \ --variant_set 'systemBitrate!=200000 || type!="video"'
Apple’s MediaStreamValidator may be used to validate the stream, where the Media Stream Validator Tool Results Explained document will outline how to interpret the output.
However, not everything the MediaStreamValidator may output needs attention.
When the output would be a warning about
carefully needs to be compared to what the tvOS specification outlines,
in this case the following:
You SHOULD use the EXT-X-INDEPENDENT-SEGMENTS tag in the master playlist. If you do not, then you MUST use the EXT-X-INDEPENDENT-SEGMENTS tag in all video media playlists.
In short, not having
EXT-X-INDEPENDENT-SEGMENTS in the master playlist is
according to specification. This is inline with the EXT-X-INDEPENDENT-SEGMENTS
Captions and Subtitles are not supported with HDS.