Skip to content

Accessing DVR Archives via Various Protocols

Basic ways of accessing DVR

On this page you will find the URLs for different scenarios of accessing DVR for each supported protocol, with the links to detailed descriptions and corresponding methods in our Streaming API.

Access to archives is based on Unix timestamps, which are in the UTC time zone. This approach may be inconvenient if you use only one time zone, but it's the only really good way to deal with things such as daylight saving time.

On this page:

Scenarios for accessing DVR

You can access DVR archives using the following main usage scenarios:

  • DVR Catchup. Playing a specified DVR window. For example, you can play a telecast if you know its beginning and end from EPG.
  • Event playback. Playing a current event with ability to rewind back to a specified time in seconds.
  • Rewinding. Rewinding streams and pausing them for hours.
  • Timeshift. Accessing an archive as regular source but with a time shift.

DVR Catchup

When your stream is already recorded on a server with our DVR, you can play video via HLS or DASH if you know the beginning and ending time of telecast, for example, from EPG.

Example for HLS:


This playlist will deliver a list of segments starting from UTC 1652249647 (11 May 2022 06:14:07 GMT) and for one hour forward.

Event playback

This feature works for HLS and DASH. It allows to get live with ability to rewind back to a specified time in seconds. Event playback is useful when you want to allow the user to seek to any point within the event, e.g., webinar, concert, current TV show.

Example for HLS:


1652249647 is a UNIX timestamp in the UTC time zone.


Flussonic Media Server has a special playlist with a wide sliding window that allows to rewind and pause HLS streams for many hours. This is a nice combination of live and DVR HLS playlists.

Example for HLS:


7200 is a duration of a HLS manifest in seconds, so your clients will be able to pause the stream up to two hours or rewind to the start of TV show without accessing catchup URLs.

In OSMF player rewinding looks as follows:

dvr timeshift


If your stream is being recorded on the server with DVR, you can play the recorded stream with a delay. This can be useful, for example, for TV broadcasting in different time zones, so that people in a different time zone watch morning broadcasts in the morning, and not late at night.

Relative timeshift

You can access an archive as regular source but with a specified time shift.

Example for HLS:


It's important to note that it's better to use special source type "timeshift", that is described further.

Absolute timeshift

You can play the recorded stream by HLS starting at a specified moment of time. You can use this feature for old STBs or viewing recorded shows with the EPG.

In this case, a part of an archive can be obtained not in one fragment, but in streaming mode, as if watching live.

Example for MPEG-TS stream starting at 1652249647:


Timeshift with a constant delay

You can run a stream which lags behind the real time for a constant time interval. Configure it as follows:

stream channel {
  input fake://fake;
  dvr /storage;
stream channel-1hour {
  input timeshift://channel/3600;

A new stream appears in the system, which will lag for 1 hour behind channel. If there will be any gaps in the recording, the lagging will still be for 1 hour.

Repeated requests to the same timeshift URL

It's a frequently asked question: Every time I use the same URL with timeshift_abs to get an HLS playlist (with the same parameters) I get different results. Why?

When you request HLS URL on a specific channel, Flussonic starts a new session.
If you use a timeshift URL, any additional requests use the same existing session. All video requests runs relative to this existing session.

So if you use the same time in timeshift_abs for multiple requests, actually it's not pure "absolute" time, it's still related to the current session.
Therefore every time you request the same time, you get a different video chunk.
It's normal behavior and it's the only good way to implement HLS timeshift.

You can work around this behavior by changing the token in every new request. That will start a new sessions.

Like this:
and so on.

Protocols for accessing DVR

Below you can find URLs for all supported scenarios of accessing DVR for various protocols with the links to detailed description with examples. Additionally, the link to OpenAPI specification is provided for each protocol.


HLS supports all scenarios of accessing DVR:

  • DVR catchup: http://FLUSSONIC-IP:PORT/STREAM_NAME/archive-{from}-{depth}.m3u8

    See DVR catchup playback.

  • Event playback: http://FLUSSONIC-IP:PORT/STREAM_NAME/archive-{from}-now.m3u8

    See HLS Event playlist.

  • Rewind: http://FLUSSONIC-IP:PORT/STREAM_NAME/rewind-{ago}.m3u8

    See Rewinding a playlist.

  • Absolute timeshift: http://FLUSSONIC-IP:PORT/STREAM_NAME/timeshift_abs-{from}.m3u8

    See DVR timeshift playback.

  • Relative timeshift: http://FLUSSONIC-IP:PORT/STREAM_NAME/timeshift_rel-{ago}.m3u8

    See DVR timeshift playback.

The complete OpenAPI specification: Streaming API.


DASH supports the following scenarios of accessing DVR:

The complete OpenAPI specification: Streaming API.


HTTP MPEG-TS supports only playing DVR with timeshift.

  • Absolute timeshift: http://FLUSSONIC-IP:PORT/STREAM_NAME/timeshift_abs-{from}.ts

  • Relative timeshift: http://FLUSSONIC-IP:PORT/STREAM_NAME/timeshift_rel-{ago}.ts


The complete OpenAPI specification: Streaming API.


MSS supports all scenarios of accessing DVR:

  • DVR catchup: http://FLUSSONIC-IP:PORT/STREAM_NAME(archive={from}-{depth}).isml/manifest

  • Event playback: http://FLUSSONIC-IP:PORT/STREAM_NAME(archive={from}-now).isml/manifest

  • Rewind: http://FLUSSONIC-IP:PORT/STREAM_NAME(rewind={ago}).isml/manifest

  • Absolute timeshift: http://FLUSSONIC-IP:PORT/STREAM_NAME/(timeshift_abs={from}).isml/manifest

  • Relative timeshift: http://FLUSSONIC-IP:PORT/STREAM_NAME(timeshift_rel={ago}).isml/manifest

See MSS Playback.

The complete OpenAPI specification: Streaming API.