Home
The purpose of the DASH live simulator is to provide adjustable live time-synced content for testing. It uses VoD DASH content as start and transforms it into live source content. It can be run as an infinite 24/7 service, a time-limited service, a multi-period service etc dependent on the URL.
The main test content is a 1-hour long VoD test sequence [http://vm2.dashif.org/dash/vod/testpic_2s/Manifest.mpd][testpic_2s_vod]. When transformed to live, the VoD content is synchronized with the wall-clock modulo 1hour, so that the minutes and seconds show the source time. The live source is available in different configurations, but the main 24/7 live service is [http://vm2.dashif.org/livesim/testpic_2s/Manifest.mpd][testpic_2s_base]. You can test it directly with Chrome (version>=38), Safari 8, IE 11 (on Windows 8.1) using the the [DASH-IF reference player][dashif_player].
The content wraps every hour, and is synchronized with the server clock, so that the content for a specific time is made available when the end the corresponding segment has passed.
For example, the segment containing the data for 2min to 2min and 2s passed a full hour, is available at 2min and 2s after the hour.
By watching the screen and noting the time and comparing it to a synchronized clock, it is possible to measure the delay in the transport and rendering system. It is typically longer for longer segments. This can be seen by using the 6s segment version of the same content (replace 2s with 6s in the URLs).
- Live content simulation by providing segments from VoD content in a looped fashion
- Synchronization with wall-clock, so that a particular media segment is made available at a specific time. This can be used for e2e delay estimation, see below.
- Full control over the bitrate and duration of the segments, since these are preproduced. There are thus no surprises due to network problems in the live content stream towards the segmenter.
- Compliance with DASH264 Interoperability Guidelines
- Feedback on too early or too late segment fetching attempts by explicit text in HTTP 404 return messages
The test server offers the following features where some are turned on by modifying the URL path to the MPD
- Support for time-limited services and updated MPD which is configured in the URL
- Support for configuration of minimumUpdatePeriod, timeShiftBufferDepth
- Support for periodic services which repeat every 10min or similar.
- Support for multiple periods and one period that started later that the session.
- Disabling of all timing checks of segments by specifying the
all_1
modifier. - Insertion of SCTE-35 ad signaling as emsg messages following the DASH-IF guidelines.
- Support for client-server time-sync using UTCTiming (head and direct methods). This reduces dash.js startup time.
- On the fly multiplexing of audio and video (for eMBMS testing, rather than DASH-IF)
The DASH-IF server is in the Amazon cloud at vm2.dashif.org.
There is currently only one test sequence, which is 1 hour long and provides a clock.
It is available with 2s segments in DASH live profile, and also in a 6s variant.
The content is available as http://[serveraddress]/livesim/[contentName]/[Manifest].mpd
and, in particular, the 2s and 6s versions are available as
- [http://vm2.dashif.org/livesim/testpic_2s/Manifest.mpd][testpic_2s_base]
- [http://vm2.dashif.org/livesim/testpic_6s/Manifest.mpd][testpic_6s_base]
There are multiple modifiers that can be used. They need to be placed before /testpic_2s
and are all of the form /option_n
.
To control availabilityStartTime (AST) and availabilityEndTime (AET), one can add extra parts to the URL after pdash.
http://<server>/<proxy>/start_ut/... will set the AST to the UNIX time ut (clipped to a multiple of duration)
http://<server>/<proxy>/dur_dt/... will set the AET as well (ut+dt)
http://<server>/<proxy>/dur_dt1/dur_dt2/ will set the AET and then updated it 2*minimumUpdatePeriod before the first has duration has been reached
The minimumUpdatePeriod is set to 1min by default in this mode.
One can also make the initialization segments available earlier than AST, by specifying init_ot where ot is an offset time in seconds.
An example
http://<server>/<proxy>/start_1370809900/dur_1800/dur_300/init_10800/testpic_2s/Manifest.mpd
will set the availabilityStartTime to 2013-06-09T20:31:40 (UTC)
, and set the availabilityEndTime to
013-06-09T21:01:40
, and the update it to 2013-06-09T21:06:40
. The initialization segments are set to be available 3 hours in advance.
The last media segments in a timelimited session, (with duration) will have the lmsg
compatibility brand set,
to signal that they are last and that there are no more segments to fetch.
Note that one can influence the
minimumUpdatePeriod
by the parameter mup_x
in the path and timeShiftBufferDepth
by the parameter tsbd_x
. Here x
is the value in seconds.
To facilitate the creation of URLs for timelimited content, there is an online link generator urlgen.html. There is also a command-line tool written in Python generate_dashif_url.py.
To allow for testing of dynamic MPD updates without the need to construct a time-specific MPD, the following scheme is supported:
http://<server>/<proxy>/modulo_x/<content>/<mpd>
Here, modulo_x
denotes that the content is available module x
minutes,
the availabilityStartTime
and the mediaPresentationDuration
vary in an x
-minute periodic pattern.
The number x
must be a divisor of 60, i.e. on of 1, 2, 3, 4, 5, 6, 10, 12, 15, 20, 30, 60.
For example, if x=10
, the following happens (mpd = mediaPresentationDuration, mup=minimumUpdatePeriod):
hh:00:00-hh:00:59 ast = hh:00:00 mpd = 120s mup = 30s
hh:01:00-hh:02:59 ast = hh:00:00 mpd = 240s
hh:03:00-hh:04:59 ast = hh:00:00 mpd = 360s
hh:05:00-hh:08:59 ast = hh:00:00 mpd = 480s
hh:09:00-hh:10:59 ast = hh:10:00 mpd = 120s
In other words:
mup = 5% of the interval
0-10% of the interval, the mpd=20% of interval
10-30% of the interval, the mpd=40% of the interval
30-50% of the interval, the mpd=60% of the interval
50-90% of the interval, the mpd=80% of the interval
90-100% of the interval, the mpd=20% of the next interval
Thus, beyond the media session getting longer and longer during the first 50% of the session, from 80-90% of the interval, the MPD will describe an expired session, and from 90-100% of the interval, the MPD will describe a future session.
Multiple periods are generated by specifying periods_n
which results in the following:
- n = 0 One period but it starts 1000h after AST, so Period@start and presentatimeOffset are non-zero
- n > 0 n periods per hour (n = 1, 2, 3, 4, 5, 6, 10, 12, 15, 20, 30, 60) and
minimumUpdatePeriod
adjusted to be 5s less than half the period duration. The number of previous periods presented
depends on the timeShiftBufferDepth
The presentationTimeOffset
is signalled in the SegmentTemplate
. By specifying the option /peroff_1
,
the PTO
is instead signaled in a SegmentBase
element in top level of the Period
.
For testing of App-based ad-insertion, the server can add SCTE35 Splice Insert signals for one-three 10s ad insertions per minute. Turn this on by specifying scte35_ where is 1,2, or 3 in the path before the content. The ad timing is the following
- 1 ad per minute, start 10s past full minute
- 2 ads per minute, start at 10s and 40s past full minute
- 3 ads per minute, start at 10s, 36s, and 46s past full minute
The presence of such an event-stream is indicated in the manifest.
By specifying utc_head, utc_direct or a combination like utc_direct-head extra information will be added in the MPD to provide the timing information. This is used by the dash.js to get a shorter startup time.
For eMBMS, better robustness can be achieved by multiplexing audio and video segments.
This can be done automatically by the server. It happens if the path to a segment has two underscores in the
next to last path component, like .../V1__A1/123.m4s
. In this case the two segments V1/123.m4s
and V2/123.m4s
are fetched and multiplexed.
The corresponding thing happens for the init segments. For this to work, the MPD must be manually changed to have
a multiplexed representation.
The module is stateless, and uses the URL to find out what content to serve. The content must have an MPD with extension .mpd, initialization segments with extension .mp4 and media segments with extension .m4s. Depending on the extension, the server will deliver read the corresponding data from the VoD content and modify it. The modifications to the various data server are:
MPD file:
@MPD level
set type dynamic
set publishTime /* Configurable in code */
set timeShiftBufferDepth
set availabilityStartTime
set minimumUpdatePeriod
set maxSegmentDuration
set mediaPresentationDuration if time-limited
set availabilityEndTime if time-limited
@Period level
set start
set periodname
@BaseURL
adding BaseURL if not present, or modifying if present
@SegmentTemplate level
set startNumber
set presentationTimeOffset if needed
Initialization segments:
No change
Media segments:
Mapped from live number to VoD number and multiplexed if needed
sequenceNumber updated to be continuous (and identical to sequenceNumber)
tfdt is changed to be continuously grown with start at epoch.
Our basic service is a 24/7 service with no updates to the MPD. To facilitate calculations we have chosen the epoch time to be the the anchor for calculations. Our default is:
startNumber = 0
availabilityStartTime = epochStart (Jan. 1 1970)
minimumUpdatePeriod = 100Y
period start = PT0s
presentationTimeOffset = 0
The availabilityStartTime tells when the initialization segments are available. The first segments should be available one segmentDuration later.
The latest available segment number can be then be calculated as
latestSegmentNumber = (now - availabilityStartTime - duration)/duration + startNumber
The server makes sure that segments are only available from their startTime and for a period corresponding to the timeShiftBufferDepth (the default is 5 min).
The media timeline shall be synchronized with the MPD. Thus, at the start of a period, the offset of the presentationTime in the media segments should be equal to the period start time or rather
MediaTimeAtPeriodStart = AST + Period@Start - presentationTimeOffset
We fulfill this by having Period@start = 0 and presentationTimeOffset = 0, and relating the media timeline to AST. However, when periods do not start at AST, we must adjust the presentationTimeOffset to be equal to the Period@start.
Some examples of this are the modifiers:
/periods_0 - one period that starts 1000hours after AST
/periods_n - multiple periods (n per hour)
/periods_0/peroff_1 - one period but presentationTimeOffset signaled in SegmentBase at Period level
/periods_n/peroff_1 - similar to /periods_n but SegmentBase used for presentationTimeOffset