Skip to content
This repository has been archived by the owner on Jun 6, 2024. It is now read-only.

Home

Jump to bottom
Torbjörn Einarsson edited this page Aug 13, 2018 · 10 revisions

Purpose

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.

Time-synced content

The main test content is a 1-hour long VoD test sequence [http://livesim.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://livesim.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, Windows 10), Edge 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).

General features

  • 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

Options

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)

Links and usage

The DASH-IF server is in the Amazon cloud at livesim.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://livesim.dashif.org/livesim/testpic_2s/Manifest.mpd][testpic_2s_base]
  • [http://livesim.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.

Events and other time-limited content

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 minimumUpdatePeriodby 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.

Dynamic MPD with static URLs

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

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.

Ad insertion

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.

UTCTiming

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. The following UTC timing information are supported:

  • utc_head
  • utc_direct
  • utc_ntp
  • utc_sntp

Multiplexed Content

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.

How it works

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
Clone this wiki locally