Flussonic Media Server documentation

Accessing DVR Archives via Various Protocols

Basic ways of accessing DVR

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:

HLS playback

HLS can be played on a computer or STB, but it is especially required for video playback on mobile devices (iOS, Android).

An URL for HLS playback should be like this: http://flussonic:8080/channel/archive-1350274200-4200.m3u8

This URL means that Flussonic should play 4200 second, starting from 1350274200 second, as a file accessed by HLS. 1350274200 is a UNIX time in the UTC time zone.

If an original stream contains multiple audio or video tracks, this URL will produce a so-called HLS variant playlist (Apple's standard), which alows Apple iOS devices (iPhone, iPad) to select a language and bitrate. Segments will be produced with less tracks in this case. If you use any other device (non-Apple), try to use special URLs.

This mode is very good for a planned shows: you can use this URL in a middleware web interface, based on EPG, and you will not need to waste a disk space for single shows.

In OSMF player it looks like this:

dvr file

Multi-language HLS and mono-language HLS

For STBs that do not fully support HLS, you may use special video-URLs.
The difference in that this URLs produce video segments with all available audio tracks.
It is violation of HLS standard, but most STBs can operate in this mode only.

Here is the list of supported URLs:

  • fixed time period: http://flussonic:8080/channel/video-1350274200-4200.m3u8
  • absoulte timeshift: http://flussonic:8080/channel/video-timeshift_abs-1350274200.m3u8
  • rewinding: http://flussonic:8080/channel/video-1350274200-now.m3u8
Timeshift and rewinding are described there.

HDS playback

HDS URL should be like this: http://flussonic:8080/ORT/archive-1350274200-4200.f4m

In the past HDS URL was: http://flussonic:8080/channel/archive/1350274200/4200/manifest.f4m - it is still supported but will be deleted in newer releases.

This URL means that Flussonic should play 4200 second, starting from 1350274200 second, as a file accessed by HDS. 1350274200 is a UNIX time in the UTC time zone.

HDS is necessary to use it with flash-players.
You can't play it on Apple iOS devices (iPhone, iPad).

HTTP MPEG-TS playback

A fragment of an archive can be retrieved not on the full speed, but in the streaming mode, over a time equal to the length of the fragment.
You can use a URL like this: http://flussonic:8080/channel/timeshift_abs-1350274200.ts.

DASH playback

You can request a fragment of archive as a file by using the following URL:


With this URL, Flussonic Media Server will transmit a range of 4200 seconds starting from Unix timestamp 1350274200.

DASH manifests for playing back archives of live streams

Note. This information is useful if you need a static manifest for playing DVR over DASH of a currently live stream.


  • 1350274200 — the start time of a requested chunk in DVR archive.
  • 4200 — how many seconds to play back.

Live stream playback from DVR via DASH

Imagine you have streams that are broadcasted live and recorded to DVR. For playing them back from the archive, the requested fragment might end in the future where no broadcast exists yet.

Flussonic allows you to choose the type of manifest (playlist) to send to clients when playing back DVR of such live streams over DASH. A DASH manifest can be static or dynamic (updatable).

By default, Flussonic updates the manifest along with live broadcast progress, which means the manifest is dynamic. When the real time reaches the specified moment when the archive fragment must end, the manifest automatically becomes static because all info about the stream is received and there is no need to update the manifest any longer. In some cases it might be better to use a static manifest.

To specify the type of a manifest, use the dynamic parameter:

  • dynamic=false. Flussonic Media Server will generate a static manifest. In a player, an archive will be played the same way as a file. The manifest will contain information about the requested time range and will not be updated during playback.


  • dynamic=auto. This is the default behavior, so this parameter can be omitted. First, Flussonic creates a dynamic manifest (and updates it while a live broadcast is going in parallel with DVR playback). Then Flussonic changes the manifest to static – it happens when the live broadcast reaches the end time of the requested DVR fragment.


MSS playback

Here is the list of supported URLs:

  • You can request a fragment of archive as a file by using the following URL: http://flussonic:8080/channel(archive=1568988189-120).isml/manifest
  • absoulte timeshift: http://flussonic:8080/channel(timeshift_abs=1568988189).isml/manifest
  • relative timeshift: http://flussonic:8080/channel(timeshift_rel=600).isml/manifest
  • Playlist with a wide sliding window that allows you to rewind MSS streams and pause them for many hours: http://flussonic:8080/channel(rewind=7200).isml/manifest

RTMP playback

Flussonic can play an archive via RTMP. You may use the following arguments:

var flashvars = {
    file: 'ort?from=1398267588&to=1398268588',
    autostart: true
  swfobject.embedSWF('/flu/jwplayer.swf',element,'640','480','10.3','false', flashvars,

So you need to put a name of the stream, and add a query string with required "from" parameter and optional "to" parameter.

Also you can use parameter speed=2, speed=4 or speed=8 so Flussonic will play an archive in the accelerated mode (without a sound).

RTSP playback

Flussonic can play an archive via RTSP. You should use URL like this:

So you need to put a name of the stream, and add a query string with required "from" parameter and optional "to" parameter.


Relative timeshift

You can access an archive as regular source but with a time shift.
A special URL exists for every protocol:

  • MPEG-TS: http://flussonic:8080/channel/timeshift_rel/3600
  • HLS: http://flussonic:8080/channel/rel-timeshift_rel-3600.m3u8
  • mono HLS://flussonic:8080/channel/mono-timeshift_rel-3600.m3u8

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

Absolute timeshift

This URL: http://flussonic:8080/channel/timeshift_abs-1350274200.ts is for a MPEG-TS stream starting at 1350274200.
Eg you can use it for old STBs or viewing recorded shows with EPG.


This feature forks for HDS, HLS and DASH. It allows to get live with ability to rewind back to a specified time in seconds.

  • For HDS URL is: http://flussonic:8080/ORT/archive-1350274200-now.f4m (in the past http://flussonic:8080/channel/archive/1350274200/now/manifest.f4m).
  • For HLS there's two different URLs:
    http://flussonic:8080/channel/archive/1350274200/now/index.m3u8 works only for Apple devices. http://flussonic:8080/channel/index-1350274200-now.m3u8 works everywhere (recommended).
  • For DASH: http://flussonic:8080/channel/archive-From-now.mpd

1350274200 is a UNIX time in the UTC time zone.

In OSMF rewinding looks like this:

dvr timeshift

Timeshift with a constant delay

You can run a stream which lags behind real time on a constant time. Configure it like this:

stream channel {
  url tshttp://vlc:9090;
  dvr /storage 10080;
stream channel-1hour {
  url timeshift://channel/3600;

A new stream appears in the system, it will lag on 1 hour. If there will be any gaps in the recording, 1 hour will not change.

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 a 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, really 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 new sessions.

Like this:
and so on.