Recording Broadcasts (Catchup TV)

We have implemented and have in several years debugged an excellent mechanism for recording video to the archive in Flussonic. This article will explain how to make use of all capabilities of the archive in the middleware.

The Concept of the Archive

In most middleware recording of broadcasts is arranged according to the principle of the old good VCR. At the required time according to the schedule, recording starts, then it stops after a while.

Such an approach features many problems, and the main problem is the fact that the schedule is usually inaccurate, i.e., the beginning of a recording will contain the "tail" of the previous broadcast, and the final part of the needed broadcast is omitted. Attempts are made to solve this problem by expanding the time-frame of the broadcast recording, which results in creating overlapping recordings on the disk.

In Flussonic, we found a different solution. Flussonic writes all videos to the archive in its proprietary format, and provides access to it, as if it were an endless tape. Each frame has its own address — its real time of population in the archive. When one wishes to view the archive, you need to tell in what time frame the video is required.

Players and protocols are not used to such an approach, so Flussonic is able to adapt to various variants of usage and present the archive in a various forms. For example, you can request Flussonic by URL http://flussonic-ip/ort/index-1429829884-3600.m3u8 and obtain an hour-long HLS playlist from moment 1429829884, which will look like a file. I.e. the player will never even be aware that it is an endless archive, and will just show the limits.

Variants are also possible, where the playback starts with a certain moment in a stream.

Implementation in middleware

In order to provide access to an already recorded broadcast, the middleware should form the URL to the archive and send this URL to the player for playing back. The URL will look like http://flussonic-ip/ort/index-1429829884-3600.m3u8

The time for the URL should be taken from the EPG оr the broadcast schedule that can be found in each middleware. It is important to pay attention to the fact that Flussonic requires time to be specified in UTC, i.e. GMT.

The player will receive the URL, understand that it is a file and show standard controls for playback. The broadcast playback can be easily rewound, paused and continued.

A very important point is pausing: the fact is that pausing a stream is a very complicated operation which is not available in all protocols. It is much easier to slow the playback down.

Viewing current broadcast

Everything becomes more complicated with unfinished broadcasts. Some players, such as iOS, Android or StrobeMediaPlayback are able to work with the so-called Event playlists. This is a way of providing content where the player knows that the server is now displaying some local event. With that, the player provides the possibility to rewind to the start, and to return to live broadcasting.

To do so, a URL should be formed that would look like http://flussonic-ip/ort/index-1429829884-now.m3u8

Be careful, if you request an URL for 24 hours, Flussonic will return a huge playlist. We saw a case where a client blocked a 100 megabit channel by a request to the same event playlist repeating several times per second. In this case, Flussonic returned a huge playlist of a few hundred kilobytes without much load due to well-tuned implementation of the archive.

However, such an URL will not work for many set-top boxes, since the set-top box will only show live broadcast without the possibility to rewind. For such devices, a JS code should be written, which would catch rewinding, and send the client to another URL:

http://flussonic-ip/ort/timeshift_abs-1429829884.m3u8, where 1429829884 is the time of starting broadcast playback. timeshift_abs HLS URLs present a great difficulty caused by the nature of the HLS Protocol. The fact is that Flussonic can only probabilistically join separate HTTP requests into the same session. Flussonic believes that the session is the same, if for two queries, client IP address, channel name, query protocol and the token match. In case of several consecutive timeshift_abs requests, Flussonic will decide that it's the same session, in the end, it may distort viewing. To avoid this, a new token should be passed in the timeshift_abs request.

A simpler variant is requesting an HTTP-MPEGTS http://flussonic-ip/ort/timeshift_abs-1429829884.ts. However, the HTTP MPEGTS option denies access to multi-bitrate.

Multilanguage

Traditionally, the MPEG-TS protocol provides a standardized mechanism for selecting the language tracks and subtitles in the same video bitrate.

The HLS protocol that is based on MPEG-TS rejects packing multiple audio tracks into the same stream and proposes to place alternative audio tracks in separate segments, which then should be mixed in the player. This is how the iOS player works, but it is not how most players in STB work.

To make the user see several languages, in streaming videos via HLS to such STB, such as Mag, Dune, Eltex, the URL: http://flussonic-ip/ort/video.m3u8, http://flussonic-ip/ort/video-1429829884-3600.m3u8, http://flussonic-ip/ort/timeshift_abs_video-1429829884.m3u8 should be used.

When you request such URLs, Flussonic packs tracks in a different way, and makes it possible for players that do not support the HLS standard completely to reach various audio options.

Record status

A more advanced middleware can check with Flussonic whether the broadcast has been recorded or not. To do so, the request should be sent via HTTP API:

http://flussonic-ip/ort/recording_status.json?from=1429960179&to=1429963716

The "from" and "to" fields define the limits of the broadcast.

JSON similar to the following will be returned:

[{
  "stream":"ort",
  "ranges":[{"from":1429960179,"duration":3542}],
  "motion_log":[]
}]

The ranges field contains an array of objects that signify the areas of continuous recording. If there are gaps in the recording, the array will contain more than one object. If no recording was made during the specified time interval, the array will be empty.