Flussonic video streamer features review
Over several years of programming, we have added a large number of different possibilities to Flussonic, so I want to tell a little about how Flussonic works and what it can.
First of all, let me remind you: Flussonic is a state of art video streaming server program that can take video from various sources, burn it to disk as needed and distribute to clients using various protocols. It can work on Intel, ARM, Tilera, etc. A distinctive feature is the special ease of configuration that does not require a single megabyte of XML for configuration and launch.
The internal structure and functionality can be divided into two large and important parts: working with video streams and working with video files (VOD).
VOD - video on demand. This marketing acronym arose from distant depths, when the very idea that a user can take and request video from a server when he wants, and not on a schedule, seemed unrealistically cool. At some stage in the development of computers and networks, it was really pretty cool (the networks are thin, the video is thick, there is not enough local language on everyone), although today it is already causing a slight smile: think about it, see the video from the Internet.
')
With files to tell less, so go ahead. Flussonic can read files in which mp4 (mov) or in the worst case of a flv container video and audio are recorded in h264, hevc (h265), aac, ac3, mp3 codecs and send this video to clients using rtmp, rtsp, HLS, HDS, DASH.
An important difference from ffmpeg is that Flussonic does so-called. segmentation on the fly. Some VOD streaming systems require preliminary preparation, for example, video segmentation (a bunch of mpegts of segments for HLS is made from an mp4 file) or video preprocessing to save alongside an index for rewinding.
Those. Flussonic works very conveniently for the administrator: put the files and they are available. Moreover, unlike the usual browser pseudo-streaming, there is no need to process files and move the mp4 file header (moov atom) to the beginning. We spent a tremendous amount of time and effort to make reading the headers in mp4 so fast that Flussonic can send many, many gigabytes per second from one server on the fly in this segmentation mode.
In highly loaded systems, where you have to collect a combined HDD + SSD configuration or traffic passes for 8-10 gigabits, Flussonic can use cache segments, but this is a topic for a separate story, as well as our separate queue mechanism for different disks. You can also configure several different paths to search for a file, when for some reason you do not want to collect several disks in a RAID.
When one server is not enough to store all (of course, legally mined) films, Flussonic can take HTTP video in pieces. Those. if the user came to the edge server with the desire to watch a 3-hour movie, the viewing will begin almost immediately, and not when the entire movie is copied to the server. You can pick up not only from a simple HTTP server, but also from Amazon S3 (and compatible) and various Swift (OpenStack Storage) storage options.
We have a VOD download manager that allows you to work with all file allocation options (including multi-paths). You can upload many files at once, create directories (including on Swift / S3) and upload files. Transcoding of downloaded files is questionable, this feature is temporarily disabled.
A file in which there are several audio tracks and subtitles, Flussonic will be able to give the main players so that they allow you to select the language and subtitles. If there are also several video tracks in the file, the user will get the possibility of adaptive multibitrate.
If your content provider twists you for a contract and requires content encryption, Flussonic can prepare a video for a Verimatrix or Conax client. But this is not the most fun topic, is it?
Working with video streams is a much more voluminous, problematic and rich part of our work than working with files.
The video stream is a large and fatty entity inside Flussonic that collects up to a dozen different Erlang processes under it, accepts video from the input, optionally transcodes (more on this below), writes to the disc, if necessary, and distributes it to different outputs.
For starters, you probably need to talk about the sources of video streams. Flussonic can act as an initiator of video transmission, or it can act as a passive waiting video. In the first case, we are talking about the availability of sources in the video stream, and in the second we are talking about publishing videos to the server. When a stream has sources, Flussonic can control when and to which source to go for the video and the algorithm of this control is very difficult. With the publication, you can simply allow or not allow to receive video.
In case Flussonic himself initiates the video transmission, the video source must be explicitly indicated in the configuration file. The stream may have several sources and the behavior will differ depending on the settings.
If the sources are specified as variants of the same video, but with a different bitrate, then a single multibitrate stream will be formed in which the client can choose the desired quality. For example, you can add multiple profiles from an IP camera as different qualities for a single stream and get multibitrate.
Broad protocol support: RTSP, MPEG-TS, RTMP, HLS (not only from flusonic, but from all servers, not everyone can do that), Shoutcast, managed server playlists, and even SDI capture cards.
In another case, Flussonic will switch from the first source to the second and further in the event of the first failure and return back after recovery. For example, you can specify the multicast from the head station as the first source, and add the http stream from the neighbor as an alternative source.
If no sources are left, you can specify a stub file as the source for the stream.
You can specify a stream as constantly running (and unlike some other servers, it will really be a constantly running 7/24 stream that you don’t need to follow), but you can configure it as a stream that starts at the user's request. For example, this happens when many cameras are configured, not all of which are always interesting.
Flussonic does a very delicate and fragile job of “stitching” several sources when switching. When the source is “blinking” or switching to another, time stamps in the stream go as if nothing happened.
In normal mode, Flussonic does not change the video itself, only changes the packaging and gives exactly what it received. Sometimes it is not good and you need to change the codec itself (or its parameters such as bit rate), then you need to run transcoding. This is an extremely resource-intensive procedure that reduces the number of threads on one server from, conditionally, thousands to ten.
Flussonic can transcode on a processor and will soon learn how to use Intel's Quicksync and Nvidia nvenc. Several Flussonic in a group can perform transcoding reservations, picking up streams when one of the servers crashes.
Most often, transcoding is used in IPTV for preparing video from a satellite for broadcasting to the Internet on set-top boxes and mobile devices, but sometimes it is also used for IP cameras.
This is really our premium feature. Suffice it to say that our archive uses to store annual video recordings and to broadcast 5,000 simultaneous users and it copes with it, while we can use for the archive both SSD / HDD and industrial (consider slow and fun) NAS, accessible via NFS. And there is something to tinker with!
Our archive implementation does not require any actions from the user such as tracking the recording depth or free disk space, no need to set up any databases, everything is done by us, carefully packed in the tested code and just works. Almost all supported codecs are written to the archive: h264, hevc, aac, mp3, pcma, pcmu. The video is available in the form of an endless tape that can be viewed from any moment.
For stories with IP cameras, we are able to store information about the operation of the motion detector. The archive is often used for broadcasting with a shift in time (relevant for broadcasting Eurasian TV channels in North America).
About the archive, we will write a few large detailed articles, so for now let's say that we have about 30 different ways to get to the archive, including cluster configurations, when the archive is written in one place, and is available from all servers.
As in the case of files, Flussonic segments the streams on the fly for the HLS, HDS, DASH protocols, and at the same time makes them available via the RTMP, RTSP, HTTP MPEG-TS protocols and at the same time is able to thrust multicast UDP MPEG-TS into the network.
Unlike some other servers, Flussonic stores all segments in memory. The alternative is to write to disk. If you do not configure tmpfs for temporary storage of segments, then the disk will have to be changed often and sadly. Flussonic keeps everything in memory and makes it possible to get to one stream from all server cores, allowing you to distribute one channel of 20 gigabits per second (this is based on the sessions, but more on that below).
We have invested a huge amount of power in the UDP MPEG-TS distribution mechanism, and as a result, this subsystem is able to output video to the network without any hops, which comes in 10-second HLS blocks.
For flow control, tuning, etc. we have a web interface with the ability to view stream logs, graphs, edit settings, etc.
We will talk in more detail about the features of Flussonic, making it a better choice compared to alternatives, but these are the topics of individual articles.
In addition to distributing videos, Flussonic has a number of other popular features.
We are regularly asked about the possibility of programming inside the server itself and it always turns out that this is not necessary and our HTTP API is sufficient. Flussonic provides the ability to manage and retrieve information via HTTP, as well as call external handlers in certain cases: either via HTTP or using the built-in lua interpreter.
Also, most of the functionality is available through the SQL API . Yes, our Flussonic knows how to pretend to be a Mysql server (oh, how much we did, what different ORMs would believe in being a Mysql) and give internal data in response to SQL queries. Through SQL, you can even manage threads in a whole cluster . This is much more convenient than making HTTP requests, for example, from Rails.
We have accounting sessions done in the best possible way, few can compare.
Customers ask us: how many users watch a video? When all users are connected via http mpegts or rtmp, there are no difficulties: just look at how many open sockets. Everything is complicated with the transition to HLS, and taking into account all the variability of those nice features that various customers bring with them. It is necessary to glue together consecutive HTTP requests in a session and this is not easy.
We'll tell you more about authorization, but now I want to boast such a cool opportunity as limiting the number of simultaneous views from one user_id, and this feature works when the user methodically scrolls through all the available 400 channels back and forth in search of interesting. It works for him, and the cunning ones, who decide to steal a package for restoring, will be left with nothing.
While we were making a system for storing graphs in Flussonic, we made our own ultra-compact storage for time series and it is used in every copy of our software.
Flussonic collects and writes a variety of metrics: general information on the network, CPU utilization, disks, number of users, and detailed metrics for each stream and file. All this information is available in the web interface either in the form of ready-made graphs, or in the form of an interface where you can build queries to the database of metrics using a special language.
Several Flussonic-s know how to cooperate to solve different problems. For example, you can set up several servers to capture a large group of threads in such a mode, when one of the servers drops, the others disassemble its streams until it returns to service.
You can also conveniently indicate the edge to the server a packet of sources, so that he himself decides which of them he can take the stream for which the user came. When the flow in the system is a couple thousand, it becomes very convenient.
Watcher is our separate product that runs on top of Flussonic. The fact is that in Flussonic there are no users. Login is the only one, and that administrator, a live person will not be allowed into the admin area - only the administrator.
Watcher is a system for managing users and their access rights to IP cameras. In it you can grant the rights to users to a group of cameras, add, delete people. There is a mechanism to quickly search for cameras (when they need to add 200 pieces, this is a very useful thing), you can turn the PTZ camera, etc.
We will also talk about him separately.
You can always take the key to the test on our website .
First of all, let me remind you: Flussonic is a state of art video streaming server program that can take video from various sources, burn it to disk as needed and distribute to clients using various protocols. It can work on Intel, ARM, Tilera, etc. A distinctive feature is the special ease of configuration that does not require a single megabyte of XML for configuration and launch.
The internal structure and functionality can be divided into two large and important parts: working with video streams and working with video files (VOD).
VOD
VOD - video on demand. This marketing acronym arose from distant depths, when the very idea that a user can take and request video from a server when he wants, and not on a schedule, seemed unrealistically cool. At some stage in the development of computers and networks, it was really pretty cool (the networks are thin, the video is thick, there is not enough local language on everyone), although today it is already causing a slight smile: think about it, see the video from the Internet.
')
With files to tell less, so go ahead. Flussonic can read files in which mp4 (mov) or in the worst case of a flv container video and audio are recorded in h264, hevc (h265), aac, ac3, mp3 codecs and send this video to clients using rtmp, rtsp, HLS, HDS, DASH.
An important difference from ffmpeg is that Flussonic does so-called. segmentation on the fly. Some VOD streaming systems require preliminary preparation, for example, video segmentation (a bunch of mpegts of segments for HLS is made from an mp4 file) or video preprocessing to save alongside an index for rewinding.
Those. Flussonic works very conveniently for the administrator: put the files and they are available. Moreover, unlike the usual browser pseudo-streaming, there is no need to process files and move the mp4 file header (moov atom) to the beginning. We spent a tremendous amount of time and effort to make reading the headers in mp4 so fast that Flussonic can send many, many gigabytes per second from one server on the fly in this segmentation mode.
In highly loaded systems, where you have to collect a combined HDD + SSD configuration or traffic passes for 8-10 gigabits, Flussonic can use cache segments, but this is a topic for a separate story, as well as our separate queue mechanism for different disks. You can also configure several different paths to search for a file, when for some reason you do not want to collect several disks in a RAID.
When one server is not enough to store all (of course, legally mined) films, Flussonic can take HTTP video in pieces. Those. if the user came to the edge server with the desire to watch a 3-hour movie, the viewing will begin almost immediately, and not when the entire movie is copied to the server. You can pick up not only from a simple HTTP server, but also from Amazon S3 (and compatible) and various Swift (OpenStack Storage) storage options.
We have a VOD download manager that allows you to work with all file allocation options (including multi-paths). You can upload many files at once, create directories (including on Swift / S3) and upload files. Transcoding of downloaded files is questionable, this feature is temporarily disabled.
A file in which there are several audio tracks and subtitles, Flussonic will be able to give the main players so that they allow you to select the language and subtitles. If there are also several video tracks in the file, the user will get the possibility of adaptive multibitrate.
If your content provider twists you for a contract and requires content encryption, Flussonic can prepare a video for a Verimatrix or Conax client. But this is not the most fun topic, is it?
Live streaming
Working with video streams is a much more voluminous, problematic and rich part of our work than working with files.
The video stream is a large and fatty entity inside Flussonic that collects up to a dozen different Erlang processes under it, accepts video from the input, optionally transcodes (more on this below), writes to the disc, if necessary, and distributes it to different outputs.
For starters, you probably need to talk about the sources of video streams. Flussonic can act as an initiator of video transmission, or it can act as a passive waiting video. In the first case, we are talking about the availability of sources in the video stream, and in the second we are talking about publishing videos to the server. When a stream has sources, Flussonic can control when and to which source to go for the video and the algorithm of this control is very difficult. With the publication, you can simply allow or not allow to receive video.
Source management
In case Flussonic himself initiates the video transmission, the video source must be explicitly indicated in the configuration file. The stream may have several sources and the behavior will differ depending on the settings.
If the sources are specified as variants of the same video, but with a different bitrate, then a single multibitrate stream will be formed in which the client can choose the desired quality. For example, you can add multiple profiles from an IP camera as different qualities for a single stream and get multibitrate.
Broad protocol support: RTSP, MPEG-TS, RTMP, HLS (not only from flusonic, but from all servers, not everyone can do that), Shoutcast, managed server playlists, and even SDI capture cards.
In another case, Flussonic will switch from the first source to the second and further in the event of the first failure and return back after recovery. For example, you can specify the multicast from the head station as the first source, and add the http stream from the neighbor as an alternative source.
If no sources are left, you can specify a stub file as the source for the stream.
You can specify a stream as constantly running (and unlike some other servers, it will really be a constantly running 7/24 stream that you don’t need to follow), but you can configure it as a stream that starts at the user's request. For example, this happens when many cameras are configured, not all of which are always interesting.
Flussonic does a very delicate and fragile job of “stitching” several sources when switching. When the source is “blinking” or switching to another, time stamps in the stream go as if nothing happened.
Transcoding
In normal mode, Flussonic does not change the video itself, only changes the packaging and gives exactly what it received. Sometimes it is not good and you need to change the codec itself (or its parameters such as bit rate), then you need to run transcoding. This is an extremely resource-intensive procedure that reduces the number of threads on one server from, conditionally, thousands to ten.
Flussonic can transcode on a processor and will soon learn how to use Intel's Quicksync and Nvidia nvenc. Several Flussonic in a group can perform transcoding reservations, picking up streams when one of the servers crashes.
Most often, transcoding is used in IPTV for preparing video from a satellite for broadcasting to the Internet on set-top boxes and mobile devices, but sometimes it is also used for IP cameras.
Record to archive
This is really our premium feature. Suffice it to say that our archive uses to store annual video recordings and to broadcast 5,000 simultaneous users and it copes with it, while we can use for the archive both SSD / HDD and industrial (consider slow and fun) NAS, accessible via NFS. And there is something to tinker with!
Our archive implementation does not require any actions from the user such as tracking the recording depth or free disk space, no need to set up any databases, everything is done by us, carefully packed in the tested code and just works. Almost all supported codecs are written to the archive: h264, hevc, aac, mp3, pcma, pcmu. The video is available in the form of an endless tape that can be viewed from any moment.
For stories with IP cameras, we are able to store information about the operation of the motion detector. The archive is often used for broadcasting with a shift in time (relevant for broadcasting Eurasian TV channels in North America).
About the archive, we will write a few large detailed articles, so for now let's say that we have about 30 different ways to get to the archive, including cluster configurations, when the archive is written in one place, and is available from all servers.
Video distribution
As in the case of files, Flussonic segments the streams on the fly for the HLS, HDS, DASH protocols, and at the same time makes them available via the RTMP, RTSP, HTTP MPEG-TS protocols and at the same time is able to thrust multicast UDP MPEG-TS into the network.
Unlike some other servers, Flussonic stores all segments in memory. The alternative is to write to disk. If you do not configure tmpfs for temporary storage of segments, then the disk will have to be changed often and sadly. Flussonic keeps everything in memory and makes it possible to get to one stream from all server cores, allowing you to distribute one channel of 20 gigabits per second (this is based on the sessions, but more on that below).
We have invested a huge amount of power in the UDP MPEG-TS distribution mechanism, and as a result, this subsystem is able to output video to the network without any hops, which comes in 10-second HLS blocks.
For flow control, tuning, etc. we have a web interface with the ability to view stream logs, graphs, edit settings, etc.
We will talk in more detail about the features of Flussonic, making it a better choice compared to alternatives, but these are the topics of individual articles.
Related features
In addition to distributing videos, Flussonic has a number of other popular features.
API & scripting
We are regularly asked about the possibility of programming inside the server itself and it always turns out that this is not necessary and our HTTP API is sufficient. Flussonic provides the ability to manage and retrieve information via HTTP, as well as call external handlers in certain cases: either via HTTP or using the built-in lua interpreter.
Also, most of the functionality is available through the SQL API . Yes, our Flussonic knows how to pretend to be a Mysql server (oh, how much we did, what different ORMs would believe in being a Mysql) and give internal data in response to SQL queries. Through SQL, you can even manage threads in a whole cluster . This is much more convenient than making HTTP requests, for example, from Rails.
Authorization and accounting sessions
We have accounting sessions done in the best possible way, few can compare.
Customers ask us: how many users watch a video? When all users are connected via http mpegts or rtmp, there are no difficulties: just look at how many open sockets. Everything is complicated with the transition to HLS, and taking into account all the variability of those nice features that various customers bring with them. It is necessary to glue together consecutive HTTP requests in a session and this is not easy.
We'll tell you more about authorization, but now I want to boast such a cool opportunity as limiting the number of simultaneous views from one user_id, and this feature works when the user methodically scrolls through all the available 400 channels back and forth in search of interesting. It works for him, and the cunning ones, who decide to steal a package for restoring, will be left with nothing.
Collection of statistics and graphics
While we were making a system for storing graphs in Flussonic, we made our own ultra-compact storage for time series and it is used in every copy of our software.
Flussonic collects and writes a variety of metrics: general information on the network, CPU utilization, disks, number of users, and detailed metrics for each stream and file. All this information is available in the web interface either in the form of ready-made graphs, or in the form of an interface where you can build queries to the database of metrics using a special language.
Clustering
Several Flussonic-s know how to cooperate to solve different problems. For example, you can set up several servers to capture a large group of threads in such a mode, when one of the servers drops, the others disassemble its streams until it returns to service.
You can also conveniently indicate the edge to the server a packet of sources, so that he himself decides which of them he can take the stream for which the user came. When the flow in the system is a couple thousand, it becomes very convenient.
Flussonic watcher
Watcher is our separate product that runs on top of Flussonic. The fact is that in Flussonic there are no users. Login is the only one, and that administrator, a live person will not be allowed into the admin area - only the administrator.
Watcher is a system for managing users and their access rights to IP cameras. In it you can grant the rights to users to a group of cameras, add, delete people. There is a mechanism to quickly search for cameras (when they need to add 200 pieces, this is a very useful thing), you can turn the PTZ camera, etc.
We will also talk about him separately.
You can always take the key to the test on our website .
Source: https://habr.com/ru/post/268311/
All Articles