Skip to content

Middleware in IPTV OTT

In the old analogue terrestrial television, users had to configure all required channels themselves: the first channel to the 1st button, the second channel to the 2nd button. While there were less than 10 channels, everyone was happy. There was no access control or detailed accounting for viewing various content.

After adopting the IPTV technology, the setup was not much different: a playlist was added to the set-top box firmware, i.e., a list of channels with their multicast UDP addresses. Access control was performed either via encryption (CAS), or using network-based methods, such as authorization of IGMP requests, which is possible only in a simple local area network.

With that, all functions are implemented on the set-top box. For example, a service such as PVR (personal video recorder) is implemented on the set-top box: the user pre-orders the recording of the broadcast, and at the right moment, the set-top box itself starts your hard drive to record the right gear.

With the development of IPTV, users were offered new services such as:

  • EPG (Electronic Programme Guide), i.e., the broadcasting schedule.
  • Organization of channels into paid packages.
  • Cataloging channels (by genre).
  • Parent control (avoid showing adult content to children).
  • Viewing recorded broadcasts.
  • Related services, like a weather forecast, or currency exchange rates.
  • Subscription to a paid package from a remote control.
  • Providing VOD, i.e., viewing movies.

It is important to understand that most solutions in IPTV were developed with constant thought about how to implement it in terms of satellite broadcasting, i.e., when the set-top boxes cannot communicate with the central server. Therefore, the transport protocols used in television have many details of business logics that were necessary before, but are not very relevant today.

With the development of diversity in IPTV services, an understanding came that developing services by complicating the set-top boxes is not convenient, or is not feasible, since when the software part of the service is implemented on a set-top box, updating and maintenance require unsafe procedures of updating the firmware on the set-top box.

In order to simplify the introduction of new services, and to control them, as well as to implement services that would be impossible in classic television, a part called Middleware appeared in IPTV.

This frightful term means a regular website (returning a HTML, a JavaScript, or answering to HTTP API requests) that is visited by the set-top boxes using either a standard web browser, or some exotic one, like
an SVG browser. The set-top box contains a modified web browser (usually Opera or webkit), which can play all versions of the video available to the set-top box (desktop browsers usually do not have even 5% of the video capabilities of the set-top boxes) and can work with a remote control by turning button presses into JavaScript event.

An important point is that Java is not used in set-top boxes (with the exception of Android-based set-top boxes, which, for a number of reasons, are very unpopular). Usually people confuse Java and JavaScript, don't do that.

Experts still argue, which is better: a web browser or a dedicated application on the device. This choice is quite similar to the choice of technology in mobile devices: writing an HTML application or coding in C.

Many modern middlewares offer both options to cover the maximum number of devices. So, for example, for Amino set-up boxes (with the Opera browser), Mag250, tvip, etc. (with a webkit-cased browser), HTML with an interface will be returned.

Usually a middleware almost does not interact with the video stream, since it only provides URLs to set-top boxes for watching channels and movies: either multicast, or unicast URLs. Sometimes a middleware has a mechanism for channel monitoring, in order not to show the channel, or to explicitly announce that the channel cannot be watched due to a malfunction.

Below we will see how integration of Flussonic Media Server and Middleware improves user QoS.

User authorization

In IPTV, restricted access to videos is used to:

  • manage channel packages. If you have not subscribed for football, watch whatever is available
  • complicate the task of stealing content by unauthorized users
  • complicate the task of unauthorized recording of the broadcasts

Here we can see a combination of two systems: CAS and DRM. CAS (conditional access system) is a mechanism of technical restricting the access to the content. DRM is a mechanism for confusing the user, so that he would never get to the decoded video.

CAS systems work well and properly. DRM systems are unreliable and buggy in their essence, and create a lot of problems to everyone, except vendors.

In Flussonic, a CAS is implemented with authorization of access to streams and files.

Integration with middleware is as follows:

  • When forming an HTML page or an answer to the API, middleware provides a link to HLS (or HTTP MPEG-TS) stream with a unique key.
  • The set-top box receives this unique URL for viewing, and sends it to Flussonic Media Server.
  • Upon the first request, Flussonic Media Server returns a question to the Middleware: is this set-top box allowed to watch the particular channel at particular URL?
  • Middleware checks whether this URL has been "peeped up" (checks the client's IP, user agent, protocol and time) and grants or denies permission.

If an attacker has peeped up the URL in the network, he will not be able to use it, since some parameter does not match, and the middleware tells the streamer not to provide the video.

Working with EPG

EPG, aka Electronic Program Guide, aka broadcast schedule. It is usually a real headache if one wishes to pick a broadcast exactly, since almost no one in the Russian market provides accurate broadcasting schedules.

TV channels don't pay much attention to the accuracy of the broadcast schedule (error up to 15-20 minutes), and do not advice the exact time of beginning and end of broadcasts.

The EPG can be obtained from the satellite in an MPEG-TS stream, but the information is rather limited, and can be picked up in the Internet from suppliers of the broadcast schedule, such as teleguide.info

A frequent file format for TV broadcast schedule is XMLTV.

Traditionally, set-top boxes replicate the functionality of ancient VCRs: the user orders the desired broadcast, and the set-top box records it. And in the same traditional way, due to errors in the broadcast schedule, the user records the "tail" of the previous commercial, 20 minutes of advertising, then the broadcast he wishes, which is cut off in the end because of inaccuracies in the schedule.

Flussonic Media Server offers a completely different approach to recording the broadcasts. There is no need to victimize the user and force him to remember about the broadcast in advance. The Middleware should make it possible for the user to watch already finished broadcasts and to form a correct link to Flussonic for watching already recorded broadcasts.

There are two mechanisms: retroactive watching and watching live broadcasts.

If the broadcast is already over, Middleware, basing on the EPG, generates a link for watching the archive (which also uses the authorization mechanism). The user gets the opportunity to watch the recorded broadcast as an ordinary file.

For example, if a broadcast started at 18:15, Moscow time (14:15 UTC) on August 27, and lasted one hour, the Middleware will create an URL like http://streamer/ort/index-1409148900-3600.m3u8, when the broadcast is selected in the list.

If the broadcast is live, Middleware can generate a special URL to the archive that will make it possible to rewind to the start of the broadcast. Unfortunately, this functionality is not supported by all devices and set-top boxes, but it still exists.

The URL for such an unfinished broadcast will look like http://streamer/ort/index-1409148900-now.m3u8

The important point here is that the information about recorded broadcasts and time thereof is stored in the Middleware, and Flussonic Media Server provides access to its archive as an endless tape.

The documentation describes [working with a DVR archive] in more detail (/doc/dvr)

Flussonic supports other variants of access to recorded programs, as well. These are:

  • archive playback over HTTP MPEG-TS from a certain point: http://streamer/ort/timeshift_abs-1409148900.ts
  • archive playback in the stream mode via HLS from a certain moment: http://streamer/ort/timeshift_abs-1409148900.m3u8

Middleware may also send a request from Flussonic Media Server to the API about the status of the stream recording, in order to show in the interface the broadcasts that can be viewed and cannot be recorded.

Timeshift

The term timeshift means two different functions: the ability to rewind live broadcast and constant shifting the broadcast into a different time zone.

This service is required when the video is captured in one time zone, and should be played back in another one, so that, e,g., users in the USA would watch a morning program at 9 a.m., instead of 1 a.m.

Flussonic Media Server offers two variants of timeshift: running a constant stream delayed by a fixed period from the live broadcast, and providing links for watching the archive in the stream mode.

The difference between them is in number of blocks read from the disk. If a channel is rarely requested, it is more logical to use the second option. If the channel is often watched with a timeshift, the constant stream should be started.

Here the task of Middleware is to know how the channel is configured, and provide links to either time-shifted channel or individual links to watching the archive:

  • http://streamer/ort/timeshift_rel/7200 — playing the archive back over HTTP MPEG-TS with a 2 hours lag
  • http://streamer/ort/timeshift_rel-7200.m3u8 — playing the archive back over HLS with a 2 hours lag

Flussonic integration with Middleware

As of today, Flussonic Media Server is supported by the following Middlewares:

Integration with other Middlewares is available on request.

On the Flussonic Media Server side, everything you need to integrate with Middleware is implemented. Ask your Middleware vendor to check compatibility with Flussonic Media Server by yourself. Also you can test the following Middleware: