Time-shifted viewing reference in AWS Elemental MediaPackage

Time-shifted viewing is available with live workflows in AWS Elemental MediaPackage.

Time-shifted viewing means that viewers can start watching a live stream at a time earlier than "now," permitting them to join from the beginning a show that's already in progress or to watch a show that's already completed. MediaPackage supports time-shifted viewing for content that's up to 336 hours (14 days) old. You can enable time-shifted viewing for some or all of this content by defining the startover window on the endpoint. Content that falls within that window is available for playback when playback requests include valid start and end parameters.

In the following steps, "now" is determined either by the program date time (PDT) present in the source content from the encoder or, if this PDT information is not included, by the MediaPackage ingest time of the most recent segment.

To enable time-shifted viewing

1. Enable time-shifted viewing by typing a value for Startover window on the MediaPackage endpoint object. You can do this through either the MediaPackage console or the MediaPackage API.

   When requests with start and end parameters that are within the startover window are sent to this endpoint, MediaPackage generates a manifest for the requested timeframe. If the start parameter is outside of the startover window, or if the end parameter is before the startover window, the playback request fails. If no start and end parameters are used, the service generates a standard manifest.

   Note

   You might notice that the manifest lags behind real time when you initially create a startover window on an endpoint. This is because MediaPackage starts filling the manifest from the start of the window, and works up to "now." So, if you have a 24-hour startover window, MediaPackage fills the manifest starting 24 hours ago and working up to "now."

2. Ensure that content requests contain start and end parameters as needed. MediaPackage accepts requests for up to 24 hours of content.

   For packager-specific rules about how you can notate the parameters, see Rules for start and end parameters.

   The start and end parameters determine the time boundaries of the manifest. These are the expected behaviors based on request start and end parameters:

   • If both start and end parameters are specified, the resulting manifest has a fixed start and end time that correspond to the specified start and end parameters.

     If the end time is in the future, the tags in the manifest are consistent with an event manifest. The manifest will continue to grow until it reaches the end time, at which point it will become a VOD manifest.

   • If a start parameter is specified without an end parameter, the resulting manifest will have a fixed start time corresponding to the specified start parameter, while the end of the manifest will grow as the live content progresses.

     Note

     For TS output, many playback devices start playback at the current time ("now"). To view the content from the actual start time of the playback window, viewers can seek back on the playback progress bar.

   • If no start time or end time parameters are specified, the service will generate a standard manifest.

Important

When using time-shifted viewing, we recommend using consistent playback windows across player sessions, rather than generating a unique start or end time for each viewer. This yields better caching at the CDN, and will avoid running into potential throttling related to those requests, on the MediaPackage level.

Time delay

You can specify a duration (in seconds) for MediaPackage to delay when content is available to players. The minimum time is 0 seconds. The following rules determine the maximum time:

• If startoverwindow is equal to 0, the maximum time is 86,400 seconds (24 hours).

• If startoverwindow is not equal to 0, the maximum time is the value of startoverwindow.

Use time_delay to redefine the live point and make content available at a time that equals "now" minus the delay specified. With a 60-second time_delay, content that MediaPackage receives at 12:20 isn't available until 12:21. Requests for playback at 12:20 will be served with content from 12:19. Likewise, if you're serving content across time zones, you can set a time_delay equal to the time zone difference to make content available at, for example, 8:00 local time.

When you use time_delay in conjunction with a startover window, the time delay duration must be less than the startover window duration.

Tip

Use a time_delay to help reduce buffering during input switching when you're using input redundancy with short output segments. Note that the delay can increase latency in content playback.

• Query parameter notation – time_delay parameters are included at the end of the request URL

  Example time_delay

  https://cf98fa7b2ee4450e.mediapackagev2.us-east-1.amazonaws.com/out/v1/reference-streams/reference-channel/CMAF-endpoint/index-llhls.m3u8?time_delay=901

Rules for start and end parameters

Start and end parameters denote the beginning and end of a time-shifted manifest. The playback device can append parameters to the end of a manifest request. Alternatively, the start and end parameters can be specified for the manifest through Filter Configuration parameters. For more information, see step 7 in Manifest fields.

In all cases, the date and time must be notated in one of the following formats:

• ISO 8601 dates, such as 2017-08-18T21:18:54+00:00. Where -08:00 is the timezone UTC -08:00.

• POSIX (or Epoch) time, such as 1503091134

The following topics describe the location rules by packager type.

DASH parameter rules

Start and end parameters in the URL request for DASH content can use standard parameter notation, or can be included as path elements in the URL.

• Query parameter notation – start and end parameters are included at the end of the request URL

  https://cf98fa7b2ee4450e.mediapackagev2.us-east-1.amazonaws.com/out/v1/997cbb27697d4863bb65488133bff26f/sports.mpd?start=1513717228&end=1513720828

• Path elements – start and end parameters are included in the path of the request URL

  https://cf98fa7b2ee4450e.mediapackagev2.us-east-1.amazonaws.com/out/v1/997cbb27697d4863bb65488133bff26f/start/2017-12-19T13:00:28-08:00/end/2017-12-19T14:00:28-08:00/sports.mpd

TS and CMAF parameter rules

Start and end parameters in the URL request for TS content can use standard parameter notation.

• Query parameter notation – start and end parameters are included at the end of the request URL

  Example TS

  https://cf98fa7b2ee4450e.mediapackagev2.us-east-1.amazonaws.com/out/v1/064134724fd74667ba294657a674ae72/comedy.m3u8?start=2017-12-19T13:00:28-08:00&end=2017-12-19T14:00:28-08:00

  Example CMAF

  https://cf98fa7b2ee4450e.mediapackagev2.us-east-1.amazonaws.com/out/v1/064134724fd74667ba294657a674ae72/manifest_id/news.m3u8?start=2018-04-04T01:14:00-08:00&end=2018-04-04T02:15:00-08:00