Skip to content

Warning

This page is not finished.

Flussonic implementation guideline for IPTV/OTT providers

If you are starting an IPTV/OTT service or investigating the possibility of implementing an IPTV/OTT service/platform, then this guideline is for you. This guideline will introduce you to the IPTV/OTT service and its implementation with Flussonic Media Server.

"Solution overview" gives a brief description of the IPTV/OTT basic structure. In "Solution architecture", we discuss the basic architecture of the IPTV/OTT service, its components, and communication between them in more detail. A real-life project will be examined in "Plan and deploy".

Table of contents

  1. Solution overview
  2. Plan and deploy
    1. Prerequisites
      1. Define a list of TV programmes to be redistributed
      2. Select last mile type, Players, STB, and Middleware vendor and define requirements for integration
      3. Select DRM vendor/provider and define requirements for integration
      4. Define requirements for TV service and QoE: subscribers/consumers profiles
      5. Define requirements for monitoring
    2. Implementation plan: technical requirements
      1. How to define requirements for the network?
      2. How to define requirements for the transcoder?
  3. Solution architecture
    1. Components
      1. Headend
      2. Transcoder
      3. DVR
      4. Restreamer
      5. Media players and STBs
    2. IPTV/OTT solution example. Server communication flows
      1. Headend -> Flussonic Transcoder
      2. Flussonic Transcoder -> Flussonic DVR
      3. Flussonic DVR -> Flussonic Restreamer
      4. Integration: Flussonic Restreamer <-> DRM
      5. Integration: Flussonic Restreamer <-> Authorization backend
      6. Flussonic Restreamer <-> Players
    3. Scalability and failover
      1. Flussonic Transcoder and DVR Cluster
      2. Flussonic Restreamer HA Cluster

In recent years the IPTV/OTT service market has experienced unprecedented growth. Research conducted by Allied Market Research indicates that the worth of the IPTV/OTT market is estimated to be $121.61 billion in 2019, and it will reach $1.039 trillion by the year 2027. The amount of subscribers of streaming platforms and services has risen significantly due to the pandemic in 2020. People now spend more time watching TV shows, movies and, live events than before.

Nowadays, people tend to watch their favorite TV shows, movies, and live events on the go, whenever and wherever it suits them. You have probably seen a person in headphones, sitting on the subway train and watching their favorite episode of the TV show or a live show. IPTV/OTT allows its subscribers to manage their viewing schedules to fit their lifestyle and rhythm of life. Watching the content on any device, anywhere, any time, sharing multiple devices is a feature of IPTV/OTT service.

What is IPTV/OTT?

Solution overview

IPTV/OTT is a method of providing film and television content over the Internet.

There is no difference for Flussonic what technology to implement: IPTV or OTT. What matters is the means of stream transmission used to deliver the content to the end-user (that is why we write it using a forward slash "/"). So we in Flussonic do not distinguish these two terms but rather see it as an opportunity to help our clients create a well-functioning and high-quality service or a platform that will provide its users with the best user experience.

Basic components of the IPTV/OTT architecture are:

  • Signal source (satellite, cable, terrestrial),

  • Headend,

  • Transcoder,

  • DVR (optional),

  • Restreamer (+ local archive is optional),

  • Media Player or STB.

Note

The set of components may vary, depending on the content delivery transmission scheme. For instance, if you are willing to do live broadcasting, there is no need in the DVR archive whatsoever.

Now we will see how content delivery is performed.

Video streams are captured by a headend in different digital TV broadcast standards: DVB, ATSC, or ISDB. Then headend's output streams are transmitted over the private IP network to the ingest server. Streams get transferred afterward to the transcoder, where they get transformed to be played on different devices with different internet bandwidths. Transcoder sends the streams over the private IP network to the DVR afterward, where copies of those streams are made and stored in the archive for future use (this step is optional and depends on whether you need DVR at all). Later on, DVR's output is transferred via the same private IP network to the restreamer. In this stage, DRM and authentication are enabled if necessary. Then on viewer's demand restreamer delivers the requested channel via an open-access network — the Internet.

One of IPTV/OTT's many advantages and also key features is that it is suitable for playback on various devices (Smart TV, STB, PC, smartphone, laptop, tablet, etc.) and it adjusts to the provided Internet connection speed. It is achieved through multi-bitrate and a variety of video codecs. This way you can provide continuous playback for the users.

For more detailed information, see: IPTV/OTT.

Plan and deploy

First step in launching your own IPTV/OTT project is to create a plan. Planning is everything, right?

Prerequisites

The first thing to do when starting your IPTV/OTT service/platform is to develop the requirements or prerequisites. You should answer the questions like: "What do you expect from your project? What services do you want to offer to your subscribers? What technical equipments is available for you?" and so on.

Answering these questions will influence your choice of supplier, method of content delivery, the architecture of the network, system requirements, etc. So there are several things to consider, but you have to identify your target audience first. It is essential to identify your target audience, their content preference, and how they prefer to consume it. Now we are moving to the first topic of our discussion — TV programmes list.

There are a multitude of requirements to consider. First you must express in a great detail what type of service you want to provide obviously. A thorough request for proposal is crucial for making sure that you choose the right supplier, and that you end up with a service/platform that suits your customers.

Define a list of TV programmes to be redistributed

So to define a list of TV programmes for your project you have to analyze the target audience. What do they prefer to watch? When, how, and where? Do they prefer live broadcasts or VoD?

You should also choose a content provider for your service and the type of source, such as terrestrial, satellite, or cable. It is possible to use multiple sources of different types to fulfill the needs of your audience in the content variety.

Flussonic can capture all three types of sources so you do not have to choose only one of them.

Select last mile type, Players, STB, and Middleware vendor and define requirements for integration

The expectations are high for IPTV/OTT service or a platform these days. Viewers have become very picky about the content variety, streaming quality, quick loading, provided service range, etc. They expect watching accessibility from anywhere, anytime, and on any device. That makes things more complicated and challenging for IPTV/OTT providers as they have to catch up with the standards that consumers dictate to them to survive on the market.

Last mile types

Now let's consider the so-called last mile type. Last mile is a phrase used in the telecommunication industry to describe the final leg of the physical network that connects to the end-user.

This last stage that brings the consumer and the IPTV/OTT provider together describes a physical way of connecting the two sides. Last mile common infrastructure technologies are divided into two main categories: wired (for example, LAN) and wireless (Wi-Fi).

It is claimed that wired connection is more reliable, secure, and faster than wireless. However, it is a debatable topic. Wireless network technologies have been substantially improving, and now it is a big question if there is a chasm in security and speed between wired and wireless network technologies.

Wired connection technologies use cables to deliver the streams to the client. It is known for a fact, that this type of network connection is faster than wireless. But not by a substantial margin. However, it is indeed more reliable than wireless connection. Interfering with wireless network is easier than with wired. But there are ways to secure your network, that we will discuss later on in this guide.
It is not always convenient or possible to run a cable as there are places where you simply cannot use a cable or you may not have the rights to do so. The main stumbling block of a wired network is that client's device is tethered to a router. It means that one side is connected at one end to an Ethernet port and at the other end to a PC, STB, gaming console or Smart TV. It should be noted, that you cannot connect a mobile device through a wired cable. Here is another bottleneck of the wired network — lack of multiplatformity.

Wireless technologies do not require any wires to connect to the network. So devices may be distanced from a router, but stay connected to the network. It is more convenient for the users as they are not dependent on location as in wired technologies. Nevertheless, it imposes constraints on the reliability of such a network. Wireless connection is easier to set up, and it is also multiplatform.

Overall, the type of the last mile delivery is influenced by a number of factors: a number of supported platforms, required connection speed, reliability level, setting up difficulty, etc. It is up to you to decide what technology to use. So, you just have to consider what is a suitable option for your network.

Media players and STBs

To play the content, you need media player and STB.

Media player is a key point for a content playback.

It receives the stream, performs the decoding, and then displays the content to the viewer.

There are plenty of media players for different platforms, such as Windows OS, Linux OS, Mac OS, Android, etc. To name a few: Kodi, OTT Player, VLC, Ott-play (by Alex), Telebreeze. All of the mentioned media players are cross-platform.

Here are some examples of media players and their supported protocols for playback:

Players Protocols
Kodi AirPlay/AirTunes, UPnP, SMB/SAMBA/CIFS, AFP, Zeroconf/Avahi/Bonjour, NFS, HTTP, HTTPS, FTP, RTSP (RTSPU, RTSPT), MMS (MMSU, MMST), TCP, UDP, SFTP, RTP and RTMP (including RTMP, RTMPT, RTMPE, RTMPTE, RTMPS), DHCP, NTP, WebDAV
OTT Player HLS, RTSP, TS by UDP, RTMP
VLC HLS, RTMP, DASH, MPEG-TS, RTP/RTSP, ISMA/3GPP PSS, MMS
Ott-play (by Alex) HLS, HTTP, RTMP
Telebreeze UDP, TCP, RTP, HLS, HTTP, RTMP (MPEG-TS)

Flussonic has its open-source player — MSE Player that provides low latency video playback. In Flussonic it is also possible to forbid playback for some protocols.

For more information about Flussonic MSE PLayer, see MSE PLayer.

Your choice of media player depends on the codecs and protocols of the input streams.

There are native players for the platforms that you have to take into account while creating your product. For instance, if you develop a mobile app, you should consider a set of protocols supported by some mobile browsers. Have a look at the following table:

MPEG-4 (H.264 format) HEVC/H.265 HLS MPEG-DASH RTSP (and RTMP)
Safari + + + -
Chrome for Android + - + -
Samsung Internet + - + -
UC Browser for Android ~ (partial support) - + -
Android Browser + - + -

It shows the players and their supported codecs and protocols. So if you plan to create a mobile app for Apple-users only, then you should explore what codecs and protocols are supported by this system.

What devices can be used for the IPTV/OTT playback?

  • Smart TV;

  • STB;

  • Tablet;

  • Smartphone;

  • Desktop;

  • Gaming console;

Basically every device that can have a media player installed.

Note

All STB's and other devices deployed must also support the necessary protocols to use them.

Flussonic can deliver the streams over MPEG-TS, HLS, MSS, RTMP, RTSP, SRT, WebRTC, and DASH protocols. You can also narrow down a set of protocols for a playback. For more information, see: Video Playback.

Middleware

Next step is to explore the Middleware options.

Middleware coordinates the workflow among various systems necessary for the functioning of the IPTV/OTT platform and resides between them, allowing them to exchange the data. The transmission logic, the interface and a wide set of other services are established by the Middleware.

What Middleware to choose depends on the range of services you are willing to offer to your subscribers. For instance, if you broadcast Live TV only, you hardly need a VOD.

Middleware offers a wide range of services, such as:

  • Linear TV.

  • EPG (Electronic Program Guide), i.e. the broadcasting schedule.

  • Cataloging channels (by genre, interest).

  • Parent control (TV-PG, TV-14, TV-MA, PG-13, R, NC-17).

  • Catch up TV (watching recorded broadcasts).

  • VOD (Video On Demand), i.e. movies and TV series.

  • Timeshift (the ability to rewind live broadcast).

  • Pay-TV and Pay-TV packages.

  • Billing system integration.

  • Information services (weather forecast, currency exchange rates) and advertisements.

  • User Access.

  • DRM integration.

You can setup Flussonic with almost every Middleware. For instance, Stalker (see: Middleware Stalker and Flussonic), iptvportal (Flussonic Media Server входит в состав пакета), CloudWare, Telebreeze

Integration with other Middlewares is available at your request. To do that, you should check the compatibility of Flussonic Media Server with the Middleware of your choice by yourself.

For more information about Middleware and its integration with Flussonic see: Middleware.

Select DRM vendor/provider and define requirements for integration

To leverage on built IPTV/OTT platform you should make sure that safety measures are applied to avoid unauthorized access to the content. It is achieved with the use of the DRM system.

DRM (Digital Rights Management) is a system or a set of technical measures to protect copyrights for digital media. It is used to limit the copying and illegal distribution of the content.

What is crucial when choosing the DRM system? What should be taken into account?

Compatibility with Middleware is required. Otherwise, communication between the client and the DRM system will not be possible.

DRM system has the following functionality:

  • Copy control (restricts users from copying, saving and sharing the content).

  • Cloning detection (restricts users from watching the content on multiple devices simultaneously using the same ID.

  • Screenshots and/or screen recording restriction.

  • Access expiration date (limits the time or the number of times a user can watch the content).

  • IP address, location, or device access-list configuration.

  • Watermarking.

Flussonic supports the following DRM systems: EzDRM, DRM Conax, DRM Conax для Nagra, BuyDRM (KeyOS), Widevine, PallyCon, Irdeto, PlayReady DRM, GS DRM, Solocoo.

For more information about DRM and its setup with Flussonic, see: Content Protection with DRM.

Define requirements for TV service and QoE: subscribers/consumers profiles

Define requirements for monitoring

How can you measure the quality of your service/platform performance? How do you know you have enough resources to maintain your service? How to detect performance issues and prevent your server from going down?

The answer for these and other such questions is monitoring. Monitoring is a process of observing the server and look for its performance issues and track the usage of its system resources. Some of these resources include CPU and RAM usage, network traffic (in/out) and bandwidth (in/out), disk I/O, and so on. Here are few parameters that are used to measure performance of a server for IPTV/OTT service:

  • CPU usage
  • RAM usage
  • network bandwidth (in/out)
  • network traffic (in/out)
  • disk I/O
  • number of streams/channels (active, with errors)
  • number of viewers (active, highest peak viewers) and so on.

Monitoring is used for:

  • Prompt response to changes in the system performance: to quickly respond to system's outages.
  • Retrospective analysis of system load and performance: to observe the server's performance over time and figure out if certain components failed spontaneously or were slowly building over time.
  • Overview of the current state of system parameters and metrics: to check if any problems impact your server.
  • Checking server availability: if server is up and running.
  • Measuring server responsiveness: measuring response time helps you ensure server responds fast enough to keep customers happy.
  • Error detection and alert/notification: it allows you not only to detect error or any potential issues but also notify you about them.
  • Capacity planning and load balancing: it allows you to plan system resources usage and see whether your server can handle growing user load in the future.

Media server performance monitoring is crucial for your business. According to a 2020 survey on enterprise server downtime, the average downtime cost per hour is between $301,000 and $400,000. Server monitoring allows to identify potential issues with streaming servers proactively.

To monitor the Flussonic Media Server performance you can use:

Flussonic collects the server performance data and displays it in the Statistics section of your account on my.flussonic.com/. You can use it to analyze the system load and performance in the past.

The current state of your system performance is displayed on the Pulse tab in the UI.

Prometheus is a systems monitoring and alerting toolkit. You can use it to set alerts and notifications via email, messenger or SMS.

  • Logging

Logging allows you to keep records of events happening to your server. Managing your collected logs can help you identify problems before they arise. See Events API to find more information about how to configure logging in Flussonic. To find a list of current events in Flussonic, refer to API Reference.

Implementation plan: technical requirements

After you define the organization of the network, it is time to move to the technical requirements. Where to start?

In this chapter we will look more into the technical requirements for the network, transcoder, DVR, and restreamer.

How to define requirements for the network?

To define the requirements for the network you have to consider the parameters like: type(s) of input signal(s) (terrestrial, cable, satellite), number of input streams, estimated number of viewers, type(s) of end-user devices you aimed at, type(s) of transport protocols and codecs, what type of content are you planning on streaming, and so on.

The table below provides video profiles and the corresponding bit rates for the streams:

Note

The bit rate value varies within a single profile and depends on many factors such as scene dynamics, the quality of compression, the FPS (Frames Per Second) value.

Profile Bitrate Resolution Video Codec Frames Per Second (FPS) Audio Codec Audio Bitrate
SD (Low) 400-600 Kbps 480x270p H.264, AVC 25 or 30 AAC 64 Kbps
SD (Medium) 600 Kbps-1.2 Mbps 640x360p H.264, AVC 25 or 30 AAC 96 Kbps
SD (High) 1-1.5 Mbps 854x480p H.264, AVC 25 or 30 AAC 96 Kbps
HD (720p) 2-4 Mbps 1280x720p H.264, AVC 25 or 30 AAC 128 Kbps
Full HD (1080p) 3-8 Mbps 1920x1080p H.264, AVC 25 or 30 AAC 192 Kbps
Ultra HD (4K) 8-15 Mbps 3840x2160p H.264, AVC 25 or 30 AAC 192 Kbps

How much input bandwidth do I need to ingest the content?

Suppose we want to capture 100 channels (60 Full HD (1080p) and 40 HD (720p)) over UDP, when one Full HD channel uses up to 6 Mbps and one HD channel uses up to 3 Mbps. Then the total value of the input bandwidth will be (6 Mbps * 60 channels) + (3 Mbps * 40 channels) = 480 Mpbs.

We want to transcode 60 Full HD (1080p) channels into 3 profiles:

  • Full HD (1080p), H.264, 4 Mbps
  • HD (720p), H.264, 2 Mbps
  • SD (480p), H.264, 1 Mbps

And 40 HD (720p) channels into 2 profiles:

  • HD (720p), H.264, 2 Mbps
  • SD (480p), H.264, 1 Mbps

Audio stream for every profile will be 128 Kbps, AAC.

In total it makes (4 Mbps + 2 Mbps + 1 Mbps + 0.128 Mbps) * 60 + (3 Mbps + 1 Mbps + 0.128 Mbps) * 40 ≈ 593 Mbps in the output after transcoding. 427.68

We will also need a DVR to archive the TV channels. We will calculate the approximate DVR storage capacity a little later.

Now let's see how much output bandwidth do we need for the playback.

Suppose we have 2,000 viewers watching Full HD (1080p) channels, 1,200 — HD (720p) channels, and 800 — SD (576p) channels. In total, it makes 4,000 viewers at a time. Full HD channel uses up to 6 Mbps, HD — up to 3 Mbps, and SD — up to 1 Mbps. The overall bandwidth value will be (6 Mbps * 2,000) + (3 Mbps * 1,200) + (1 Mbps * 800) = 16.4 Gbps. Therefore, the output bandwidth of our network should be at least 16.4 Gbps.

To learn about the system requirements you need to support your project, refer to System requirements page.

How to define requirements for the transcoder?

Transcoding is the most computationally expensive process in your video stream delivery pipeline, so let's focus on how to determine the requirements for servers with a transcoder. Details on what is transcoder in Flussonic are given below on this page.

It is almost impossible to develop a general formula that will tell you that a particular hardware configuration is right for you. Too many factors must be taken into account for such a calculation, for example your available resources, budget, characteristics of input and output streams, etc. Each case is unique. If you plan to purchase your own server, then we can only advise brute-force search: take a server for 5–20 channels and test it; if the result does not satisfy you, take another server. Repeat until you reach the desired performance.

But there is another way. You can consider our own transcoder, packager, and origin server Flussonic Coder. It's designed for maximum video performance, and we guarantee that you'll be able to trascode the number of channels as per the specification.

Let's calculate the number of Coders we would need in the above example where we made the network calculations.

Assume we create multibitrate streams from 60 Full HD (1080p) channels and 40 HD (720p) channels. The number of channels Flussonic Coder can transcode to three profiles is given in the specification (see "Broadcast multiscreen specification"). Divide one by another to find out the number of Coders. Let's compile a simple table:

Resolution Required Spec Qty. of Coders
Full HD 60 48 60/48 = 1.25 ≈ 2
HD 40 56 40/56 = 0.72 ≈ 1
Total 3

So we need only 3 Flussonic Coder devices for transcoding according to the specified scheme. However, we transcode HD channels into two profiles instead of three so some resources are spared, hence two coders may be enough for you.

We recommend that you load-test Flussonic Coder with your stream to accurately determine the appropriate configuration. Please fill in the form on our website, and we will help you choose the configuration and determine the required number of coders.

Solution architecture

Flussonic Media Server is a tool, that you tune to your own needs. It can act as a headend, transcoder, DVR, or restreamer, depending on the way you configure it. It all starts with the purpose or the aim of your project and what sevices you want it to provide to your subscribers.

Components

As we have already mentioned earlier, to implement IPTV/OTT technology you need:

  1. Headend

  2. Transcoder

  3. DVR (optional)

  4. Restreamer

  5. Media Players and STBs.

That's only the basic set of components of the architecture, but you also need to define some parameters that we will discuss further.

Headend

Headend is an essential component for capturing video streams from different sources, such as terrestrial, satellites or cables of one or multiple content providers. Thus, the input signals for the Flussonic headend may be received in following digital television broadcast standards: DVB and ISDB (-T (terrestrial), -S (satellite), -C (cable)), ATSC (terrestrial/cable). MPEG-2 is the transport protocol used for TV signal transmission.

What is the purpose of the headend? The headend is crucial for:

  1. Capturing video streams from various sources.

Received in DVB, ISDB or, ATSC standards. MPEG-2 (MPEG-TS, MPTS "Multiple Program Transport Stream") transport protocol is used.

  1. Descrambling video streams.

Most of the received channels are somehow encrypted. Encryption is used to control access to channels for the users: those who have paid for the next month to watch TV. The procedure of decrypting the channel is called descrambling, and the encrypted channel itself is called a scrambled channel.

For more information, see: Descrambling.

  1. Demultiplexing video streams.

As the streams are transmitted to the headend via MPTS, which carries multiple programs. It needs to be split or demultiplexed into its constituent streams to be sent over the private IP network. One program corresponds to one TV channel (for instance, Canal+, Viasat History, etc.)

For more information about MPTS, see: MPTS

  1. Sending streams via UDP multicast.

UDP multicast is used to transmit all of the SPTSs over the private IP network to the transcoder.

Therefore, the output of the headend is a number of SPTSs, where one UDP stream corresponds to one TV channel.

To sum up:

Inputs terrestrial, satellite, or cable of one or multiple content providers
Purpose 1. capture videostreams
2. descramble videostreams
3. demultiplex videostreams
4. send streams via UDP multicast
Outputs multiple SPTS (one UDP stream for each TV channel)

Transcoder

Transcoder performs several manipulations to the stream, such as transcoding and packetizing, or transmuxing. You might not even need the transcoder in your project. It all depends on the aim you are pursuing and the requirements your service/platform should meet. We will explore this topic further.

Transcoding is an extremely computationally expensive process in the whole video stream delivery pipeline. The question is: What is transcoding? What is meant by this term?

The term transcoding is sometimes misconceived so that almost every manipulation with the stream is understood to be transcoding, which is inappropriate and fundamentally wrong. Let's debunk the myths concerning transcoding and get to the bottom of what it means, when it is crucial and when you can do without it.

What is transcoding?

Before we come to an understanding of the term transcoding it is essential to remind you of encoding and decoding.

Encoding is a process of compressing raw uncompressed data (like SDI) according to a necessary codec (for instance, H.264). Decoding is the inverse process of encoding, i.e. it is a process of decompressing compressed data to a raw format.

So transcoding implies both decoding and then encoding. Now we can give a definition.

Transcoding is a process of decoding the data and then encoding it using codec. The content is decoded with codec, then the content is modified, and encoded with another codec or the same codec but with different settings. Simply put, transcoding involves making changes to the content itself.

Let's consider an example to make it clear. You are a student and your supervisor asked you to make some changes to the article you had sent earlier. The teacher sends it back to you in compressed .rar file format. So you have a compressed document (.docx). But you can not make changes to it straight away, you should decompress it first and then work with it. Same as decoding, right? So after you finish making all the necessary changes to the article you should send it back to your supervisor. In order to do that you should compress it again first and then transmit it over the Internet. Let's say you compress it to the .zip format and it is good to go. Looks quite similar to encoding. You can also compress it to the same .rar format or any other, there is no difference. The crucial thing here is that you have engaged with the content (the document).

Transcoding also covers a few more digital media tasks:

  • Transsizing

Changing the size of the video frame. For instance, downsizing from 1920×1080 (1080p) to 1280x720.

  • Transrating

Changing the bitrate of the stream without modifying the video content, profile, media container, or video codec. For example, 4K video stream can be transformed into one or more lower bitrate streams.

  • Overlaying watermarks and logos

  • Changing GOP size

Therefore, when you are referring to trancoding you might be indicating to any of these tasks or a combination of them.

Now let's move to another process that is often alleged to be a part of transcoding — transmuxing or packetizing.

How is transcoding different from transmuxing?

If transcoding implies that any modifications are made to the content itself, then transmuxing does not go that far.

Transmuxing is a process of repackaging the stream without changing the file itself. This way only container format gets modified. This way only container gets changed, not codec.

It is not transcoding and should not be confused with it.

When transcoding is crucial?

Transcoding is critical in case:

  • You plan to offer streaming to multiple devices that support different formats.

  • You want the exclude or reduce lagging, sudden video interruption, failures during sreaming by adjusting to the user's bandwidth.

  • You want to reduce the space usage of your customers when streaming.

If you want to broadcast let's say an ad on a loop for your customers using only STB for it, then there is no need in transoding whatsoever.

Flussonic Transcoder

So now we figured what transcoding is and how it is different from transmuxing. Now let's see how it is done in Flussonic.

Flussonic Transcoder's input is UDP multicast streams of the TV channels.

Transcoder performs the following steps:

  1. Decoding of the source streams into raw video data.

  2. Processing and encoding of the raw streams according to the specified parameters so that they are ready to be sent over the Internet.

To do that transcoder:

  1. Changes video parameters:

    • Codec

    For the video stream to be processed by various devices.

    • Bitrate

    To adjust to the Internet bandwidth and provide the best experience for the viewers. Depends on the quality of the input stream.

    • Input stream size

    To send it over to the next stage effectively with the least possible loss in quality.

  2. Creates a multi-bitrate stream.

When transmitting HD channels over the Internet, one has to compress the stream into several qualities: from HD with the best quality to standard SD to compensate for overloaded channels.

  1. Overlays a logo on top of a video stream.

For more information about transcoding and supported codecs and protocols, see: Transcoding, Supported protocols and codecs.

So this way there are multiple streams for one TV channel stream. Thus, the output of the Flussonic transcoder is the transcoded streams for each TV channel. We highly recommend using the Flussonic M4F transport protocol for streams transmission between Flussonic Media Servers to reach the best performance.

Summing up:

Inputs UDP multicast streams
Purpose 1. change video parameters (codec, bitrate, input stream size)
2. create a multi-bitrate stream
3. overlay logo
4. send streams via private IP network (M4F protocol highly recommended)
Outputs transcoded streams for each TV channel

DVR

With Flussonic Media Server you can record and store video streams and work with video archives. We call this feature DVR (Digital Video Recording).

DVR (Digital Video Recording) is a feature that allows a provider to record and store copies of video streams and for the viewer to work with video archives.

The input for the DVR is the output of the transcoder — transcoded streams for each TV-channel, as DVR follows transcoding step.

Flussonic Media Server provides a wide range of features to work with the archive, such as recording of TV programmes (for viewers), i. e. catch-up, broadcasting in different time zones (for providers), i. e. timeshift and etc.

For more information on DVR and its features, see: DVR, TV programmes recording (Catch-up TV), Broadcasting in different time zones (Timeshift).

Hence, the output of the Flussonic DVR is the transcoded streams for each TV channel for live viewers and copies of those streams for DVR users. DVR does not perform any conversion to the input streams.

In conclusion:

Inputs transcoded streams of TV channel
Purpose 1. record and store copies of input video streams
2. allow users to work with the archive and its functionality (catch-up, timeshift and etc.)
Outputs 1. transcoded streams for each TV channel for live consumers
2. copies of transcoded streams for each TV channel for DVR consumers

Restreamer

Flussonic Media Server as a restreamer can connect to another Flussonic Media Server (the source) to retrieve a list of running streams, streams available on-demand, and restream them locally. Flussonic also allows you to transparently access DVR on the source.

Flussonic Restreamer is an HTTP server optimized to play streams to thousands of viewers simultaneously on multiple devices in a secure way via various protocols. Flussonic Restreamer acts as an edge server since it performs local caching and functions as DVR (proxy server is not required anymore).

Flussonic Restreamer performs the following:

  • Viewer's authorization for the purpose of getting access to the stream (integration with Middleware is required).

  • Content protection with DRM (3rd party integration).

  • Caching and storing most watched streams locally (local DVR archive) to prevent Flussonic Transcoder and DVR from overloading.

  • Automatic archive replication.

Replication means that a DVR archive is stored on two (or more) Flussonic servers. After establishing a connection between a source and a secondary server, the secondary server will automatically use the missing stream from the source.

  • Сontent streaming via HLS, DASH, MSS and many other protocols.

  • Consumer's sessions data collection for further analysis.

  • Multicast (UDP) and unicast (TCP) data transmission.

For more information about restreaming and replication, see: Restreaming and Replication.

Then:

Inputs 1. transcoded streams for each TV channel for live consumers
2. copies of transcoded streams for each TV channel for DVR consumers
Purpose 1. streaming content to thousands of viewers
2. viewer's authorization for the purpose of getting access to the stream (integration with Middleware)
3. content protection with DRM (3rd party integration)
4. caching and storing most watched streams locally to prevent Flussonic Transcoder and DVR from overloading
5. content streaming via various protocols
6. consumer's sessions data collection for further analysis
Outputs streams in HLS, DASH, MSS, and many other protocols

Media players and STBs

Media player is an essential tool for consuming the content, it receives the streams and plays it.

STB is a small computer that has a built-in player, however, and it has more features than only playing video streams.

There are plenty of media players for different platforms, such as Windows OS, Linux OS, Mac OS, Apple TV, Android, etc. To name a few: Kodi, OTT Player, VLC, Ott-play (by Alex), Telebreeze. All of the mentioned media players are cross-platform.

Media Players and their supported protocols are listed below:

Players Protocols
Kodi AirPlay/AirTunes, UPnP, SMB/SAMBA/CIFS, AFP, Zeroconf/Avahi/Bonjour, NFS, HTTP, HTTPS, FTP, RTSP (RTSPU, RTSPT), MMS (MMSU, MMST), Podcasting, TCP, UDP, SFTP, RTP and RTMP (including RTMP, RTMPT, RTMPE, RTMPTE, RTMPS), DHCP, NTP, WebDAV
OTT Player HLS, RTSP, TS by UDP, RTMP
VLC HLS, RTMP, DASH, MPEG-TS, RTP/RTSP, ISMA/3GPP PSS, MMS
Ott-play (by Alex) HLS, HTTP, RTMP
Telebreeze UDP, TCP, RTP, HLS, HTTP, RTMP (MPEG-TS)

Flussonic has its own open-source player — MSE Player that provides low latency video playback. In Flussonic it is also possible to prohibit playback for some protocols.

For more information about Flussonic MSE PLayer, see MSE PLayer.

Your choice of media player depends on the codecs and protocols of the input streams.

There are native players for the platforms that you have to take into account while creating your product. For example, if you're creating a mobile app, then consider what protocols are supported by some mobile browsers. For example, have a look at the following table:

MPEG-4 (H.264 format) HEVC/H.265 HLS MPEG-DASH RTSP (and RTMP)
Safari + + + -
Chrome for Android + - + -
Samsung Internet + - + -
UC Browser for Android ~ (partial support) - + -
Android Browser + - + -

This way you can enable transmission via certain protocols to perform playback on mobile devices.

STB is a device that has a built-in player and also provides you with a wide range of other options for viewing management.

All in all:

Inputs streams in HLS, DASH, MSS and many other protocols
Purpose content playback
Outputs -

IPTV/OTT solution example. Server communication flows

In this section we will build an IPTV/OTT solution from scratch for a small hotel with 100 rooms using Flussonic Media Server and its wide range of functionality. We will also calculate the input and output traffic on every stage and estimate the bandwidth necessary for the best performance of this solution.

First of all, it is essential to set requirements for the IPTV/OTT service that you want to provide, what features you wish to use. From our IPTV/OTT solution example we expect the following:

1) 20 channels: 7 Full HD and 13 SD.

2) Catch up TV.

3) Time Shifted TV.

4) Signal source: cable.

5) Multiple devices (TV, laptops, smartphones) support.

Now we will provide you with some background information for you to understand the process of signal transmission in Flussonic.
There are 4 types of video transmission with Flussonic Media Server (see Pic. 1):

Pic. 1. Types of video transmission with Flussonic Media Server

  • Ingest (from an external host)
    Flussonic is an initiator of a connection and a receiver of a video stream.

  • Publish
    Flussonic waits for a connection and receives a video stream.

  • Push (to another server)
    Flussonic is an initiator of a connection and is a source of a video stream.

  • Play
    Flussonic waits for a connection and is a source of a video stream.

For more information, see Types of video transmission with Flussonic Media Server.

Flussonic Media Server is a tool, that you tune to your own needs. It can be a headend, transcoder, or restreamer, depending on the way you configure it.

First of all, you should decide what TV signal you want to receive: cable, terrestrial, satellite, or a combination of those.

Stage 1: Receiving TV signal.

Our hotel will be providing a cable TV to its guests. Thus, we will use cable receiver to receive a TV signal through a coaxial cable. We will use one of Decklink capture cards for the headend. So as we receive MPTS that has 7 Full HD (2 Mbit/s) and 13 SD (1 Mbit/s) channels, the input and output traffic will be:

7 * 2 Mbit/s + 13 * 1 Mbit/s = 27 Mbit/s.

Flussonic supports ingesting from Decklink, Magewell, DekTec PCIe, Stream Labs, AJA.

Flussonic Restreamer is an HTTP server optimized to playback streams to thousands of viewers simultaneously on multiple devices in a secure way by using various protocols. Flussonic Restreamer plays a role of an edge server since it performs local caching and functions as DVR (proxy server is not required anymore).

Flussonic Restreamer performs the following:

  • Viewer's authorization for the purpose of getting access to the stream (integration with Middleware)

  • Content protection with DRM (3rd party integration)

  • Caching and storing most watched streams locally to prevent Flussonic Transcoder and DVR from overloading

  • Сontent streaming via HLS, DASH, MSS and many other protocols

  • Consumer's sessions data collection for further analysis

For more information, see: Restreaming.

Then:

Inputs transcoded streams of TV channel
Purpose 1. streaming content to thousands of viewers
2. viewer's authorization for the purpose of getting access to the stream (integration with Middleware)
3. content protection with DRM (3rd party integration)
4. caching and storing most watched streams locally to prevent Flussonic Transcoder and DVR from overloading
5. content streaming via various protocols
6. consumer's sessions data collection for further analysis
Outputs streams in HLS, DASH, MSS, and many other protocols

Flussonic Headend -> Flussonic Transcoder

Flussonic Headend captures the TV signal from the cable receiver, performs some signal conversion to send UDP multicast to Flussonic Transcoder. So when headend captures the stream it performs an ingest as headend initiates the connection and receives the signal.

For practical reasons it is better to use 2 headends: one as the main and the other as backup in case the first one stops working.

So Flussonic Headend with Decklink card in it receives 27 Mbit/s of MPTS and demultiplexes it, separating streams.

It is acknowledged that you cannot multicast on the public Internet as it works only within LAN. However, with the help of Flussonic you can receive multicast and unicast streams and transmit UDP multicast over the Internet.

The headend's output is sent to the transcoder as input over UDP multicast, so in this case, the headend initiates the connection and acts as a source of the stream. Thus, it is a push. Let's agree that all the transmission from the headend to restreamer is performed within LAN until stated otherwise.

Flussonic Transcoder -> Flussonic DVR

Flussonic Transcoder waits for the connection establishment and then receives the stream from the headend. It is a publish type of video transmission.

We want to convert our video streams into 4 video transcode profiles: 7 Full HD (720i) to 720p and 576p; 13 SD (576i) streams to 576p and 480p. This way the input equals to 27 Mbit/s and the output is calculated as follows:

7 * (2 Mbit/s + 1 Mbit/s) + 13 * (1 Mbit/s + 1 Mbit/s) = 47 Mbit/s

Then transcoder pushes this output to Flussonic DVR. We highly recommend using our internal segment-based M4S protocol to send the streams from Flussonic Transcoder to Flussonic DVR.

DVR waits for the connection and, eventually, receives the stream. Hence, it is publish.

Flussonic DVR -> Flussonic Restreamer

As we know, DVR makes copies of the streams and stores them in the archive. At this stage, you should decide for how long do you want copies of streams to be stored (in days). This value will be the depth of your archive.

Now we will proceed to calculate the archive disk space that you need to store the copies of the streams. We will use this formula:

archive_depth (in seconds) * number_of_streams (of one profile) * stream_input_bitrate

To simplify this process you can use our DVR calculator. It is easy to use and you don't have to calculate everything manually for every stream profile.

So the archive diskspace value, which is sufficient for our needs, equals 2.07 TB.

For more information about the DVR and its features, see DVR.

We highly recommend using our internal segment-based M4F protocol to transmit the streams from Flussonic DVR to Flussonic Restreamer. For more information, see: The M4F protocol.

Flussonic Restreamer initiates the connection by making a request for a necessary stream and receives it afterward as soon as the connection between the DVR and the restreamer is established. Therefore, it's an ingest.

Now is the time to think about content protection. There are various ways to do this. We will consider DRM protection and authorization backend further.

Integration: Flussonic Restreamer <-> DRM

DRM (Digital Rights Management) is an approach to copyright protection for digital media. It is designed to protect the rights of the content owner and prevent unauthorized content distribution or modification. The content is encrypted and decrypted by a pair of keys. The keys are generated by the DRM system's key server.

For more information about DRM and its configuration in Flussonic, see: DRM.

How does the communication between the Flussonic Restreamer and the DRM system is performed?

  1. When a viewer attempts to watch a TV channel, Flussonic requests an encryption key from a license server along with the URL of this key.

  2. User receives encrypted content and the URL of a decryption key from the Flussonic server.

  3. The license server receives a request from the user and then checks whether the user and device are authorized, before issuing a license response with a decryption key.

  4. The player can then decrypt and play the content back for the user.

Let's move on to the authorization backend.

Integration: Flussonic Restreamer <-> Authorization backend

Flussonic Media Server identifies users and tracks connections by using authorization backend.

For more information about its mechanism and the way to configure it in Flussonic, see: Authorization using a backend.

This way we can identify hotel guests and provide them access to the IPTV service. To do this we will request the following information that is also added to the hotel's database: their room number and surname.

Flussonic Restreamer <-> Players

In order for a player to televise a TV channel, it initiates the connection by making a request for a necessary stream from the restreamer. This is the example of play type of video transmission. As soon as the media player receives the stream, a viewer can enjoy the content. The stream transmission between the restreamer and the player is achieved over the Internet (Wi-Fi), not LAN. This way your customers have an opportunity to watch TV channels with the help of various devices, such as Smart TV or STB-box in the room, laptop, or smartphone anywhere else around the hotel (provided there is a stable Wi-Fi hotspot).

We chose Kodi as our player.
You should also take into account how many viewers can possibly watch a TV channel at the same time to figure out the necessary bandwidth. Suppose there is a FIFA World Cup and all guests of the hotel turn on the same Full HD (1080p) channel to watch the football match. Thus, there are 100 requests for playback of the same channel. Let's calculate the amount of Internet traffic, necessary for a consistent TV channel playback:

100 * 2 Mbit/s = 200 Mbit/s.

Overall, Internet bandwidth within the hotel should be at least 200 Mbit/s for the guests to follow the events of the football match.

One Wi-Fi hotspot will not be enough for a stable Internet connection. Then a few Wi-Fi hotspots should be placed around the hotel territory. This way a coverage area will be larger and the quality and connection speed will be more stable.

Scalability and failover

Imagine that you are developing a project for online broadcasts of major events: presentations of new car models or smartphones, international conferences and speeches with famous scientists and researchers, concerts with an audience of thousands, etc. Naturally, there may be thousands or tens of thousands of viewers, that will connect almost simultaneously, causing an overwhelming increase in traffic. As soon as the event comes to an end, they will disconnect almost all at once, which will lead to a fall in the amount of consumed traffic. So the diagram of used traffic will look like a rollercoaster. It means that the load on the server will behave in the same way. Your server will be swallowed up by such a load jump and crash instantly. Therefore, it is critical to anticipate such situations and take the necessary measures to avoid them, or at least reduce their impact.

With the growing number of users your service should be ready to manage an amount of requests or your service will collapse due to the overload. Thus, the system should be scalable to be able to handle an increasing demand and failovers.

Scalability*is an ability of a system to manage an increasing number of requests and adapt to its fluctuations.

Failover is an ability of a system to switch automatically and seamlessly to a reliable backup system in case a component or a primary system fails or shuts down.

To avoid system failure and unexpected crashes, you might want to set a backup. Backup implies using another server(s) to ensure that the system's performance is not affected if the primary system component stops working. That is why you might want to use a group of servers, i.e. a cluster.

Cluster is a set of interconnected servers used to work together as a single system to perform computationally intensive tasks.

Flussonic offers a number of ways to deal with scaling and failovers, such as Cluster ingest, Cluster DVR, DVR Cross Replication, Cluster restreaming, Load balancing.

Let's get to it.

Flussonic Cluster ingest

Let's consider the following case: you capture multiple streams from a source under one condition: one stream per server. Thus, you need a group of servers, i.e. a cluster, for ingesting. As it happens, one of the nodes in a cluster may shut down and fail due to some reason, which causes a stream being dead, unless you have a cluster ingest configured.

Cluster ingest is a group of servers (cluster) used to ingest the streams from a source.

How does it work and how can you benefit from it?

If one of the nodes in a cluster fails and stops capturing the stream, another server in a cluster automatically picks up that stream an starts it with the least possible damage to the network. Large number of such streams will be evenly distributed between the servers.

For more information on cluster ingest work and how to configure it in Flussonic, see: Cluster ingest.

Flussonic Transcoder and DVR Cluster

DVR offers a wide range of functionality to its users. It stores the copies of original streams. But what if this storage gets damaged? Worst case scenario is that you lose all of your data. So to secure your platform from this scenario you might want to use a DVR backup. It is typically used if one archive server fails, but the data is still available on the other server.

Flussonic offers several ways to backup the archive and provide a seamless switching to another server in case of any issues with the primary archive:

  • Cluster DVR

A group of DVR servers united in a cluster to optimize communication with the archive. Used in a distributed video delivery environment. It provides:

1. Safety and availability of an archive.
2. Load reduction on source servers and quicker access to an archive for the users.
3. Restores the data integrity of the archive on the secondary servers after a partial or complete data loss of the source server in a geo-distributed video delivery environment.
  • DVR Replication

DVR Replication is a way of media recovery by storing the archive data on two or more servers so that all the secondary servers pull the data from the primary archive. After establishing a connection between a primary and a secondary server, the secondary server automatically pulls the missing stream from the primary stream archive.

How can you benefit from the DVR Replication?

1. Auto recovery after failures and crashes, archive copying to other servers for reliability.
2. Time shifting, i. e. broadcasting with a time delay in another time zone to reflect a local time zone, providing secure delivery of a missing stream or streams.

For more information about DVR Replication in Flussonic, see: DVR Replication.

  • DVR Cross replication

DVR Cross Replication is a way of media recovery by storing the data on two or more servers so that both all the archives access the source of live streams and also retrieve the data from each other.

How can you benefit from the DVR Cross Replication?

It provides continuous access to DVR in case one of the servers becomes temporarily unavailable. If one of the archives becomes unavailable, another archive keeps storing the streams, accessing the source directly. After the recovering of the offline server, it automatically retrieves the missing data from the secondary server.

During replication only the primary server connects to the stream source, whereas the secondary server can only pick up the data from the primary archive. In cross-replication, both the primary and secondary servers can access the source.

For more information on DVR Cross replication in Flussonic, see: DVR Cross Replication

Flussonic Restreamer HA Cluster

Cluster restreaming

Cluster restreaming is a way of delivering the content to the end-users by setting up a cluster of restreamers.

Flussonic Restreamer connects to the Flussonic source, obtains the list of running streams and streams available on-demand, and restreams them locally.

This way you can configure several sources on Flussonic and build a robust available cluster configuration.

For more information about cluster restreaming, see: Cluster restreaming.

Load balancing

Load balancing — process of distributing client requests among servers in a cluster according to some particular algorithm.

For more information about the load balancing mechanism in Flussonic, see: Load balancing.