Component Flussonic DVR
Table of contents
- DVR recorder
- On Storage Capacity, Configuration Variability, and Disk Space Saving
- IPTV OTT scenarios
- Catch up
- Lock or record on demand
- IPTV OTT. How to calculate the storage size of an archive
- Calculation of DVR
- The MBR profile of a TV channel calculation
- Calculation of disk space
- Instructions for the DVR calculator
- Squeeze more. Scale your OTT and IPTV services with Flussonic
- Live streaming + Video on Demand scenarios
- Rewind for online conferences
- Exporting the broadcasting as an mp4 file
- File storage and organizing views on demand
- CCTV. Eternal storage and instant search of events from thousands of surveillance cameras
- Real-time video recording and viewing with no archive size limit
- Storage of information with reference to timestamps (motion detector in the frame)
- How to store an archive of thousands of IP cameras
- In conclusion
- The full video path that Flussonic is working on consists of:
- Resource requirements in the context of DVR:
Save tens of thousands of dollars while scaling your business, get the broadcast recording online immediately after completion, instantly find events captured by thousands of video cameras.
Digital Video Recording is a recording of a broadcast on a digital storage medium for later use. In fact, this is what allows you to report the 9:00 P.M. national evening newscast for all time zones, pause the live broadcast of the Champions League semi-final on cable TV or instantly find an event of interest from thousands of surveillance cameras.
On Storage Capacity, Configuration Variability, and Disk Space Saving
DVR is an infinite tape where the broadcasting is recorded exactly the way it happens. “Exactly the same way” means that if the source stream consists of multiple video tracks (with different bit rates) and multiple audio tracks (with different languages), then all, as is, are added to the archive. Many people use DVRs for surveillance purposes and home entertainment needs.
Of course, an infinite tape cannot actually be infinite; we are limited by the copyright holder’s policy, memory size, and other resource restrictions. Therefore, the recorder has settings for the storage depth. For example, you can configure a log with a depth of 6 days. This means that all the saved video stream started 6 days ago. Streaming fragments that have been stored for more than 6 days will be deleted. This 6-day interval with the video stream and its metadata is called the DVR window.
It is also possible to record a stream with a limited amount of storage. Let’s say you have a 15 TB disk and you don’t want to write more than 10 TB of data to it. In this case, the Flussonic setting sets the recording depth to 10 TB. And everything that goes beyond these 10 TB, the system will erase (starting with the oldest records). Therefore, the disk space will have a constant value. But the depth of the archive will vary depending on the properties of the stream (from the bit rate).
Furthermore, it is possible to limit the recording within a daily window to separate time intervals. For example, it is important for a subscriber to record video surveillance cameras all day on weekends and on weekdays, only at night. In the settings, you just need to set the recording schedule. Saving, therefore, disk space.
Let’s consider the usage scenarios for Digital Video Recording technology:
IPTV OTT scenarios
Do you remember when you had to run in front of the television when you heard your favorite show start again? How to forget those quick trips to the bathroom during commercial breaks.
Now everything is different: you do not need to adjust your personal schedule to the schedule of the transmissions of your favorite series and programs. Were you late and couldn’t see the new episode of your favorite TV series? A football game is played at night, but do you need to get up early in the morning?
Catching up allows you to get back to your favorite show at a more convenient time.
The Catch Up service is provided on the basis of Digital Video Recording technology: from sometime in the past, the subscriber, upon request, gets access to part of the archive.
Timeshift is a time-shifted archive access technology and is used when subscribers are in different time zones.
Let’s say you have a grid for the region A. It is broadcast once. An hour later, the exact same thing is repeated from the archive for the next time zone (be region B). It turns out that subscribers in region A watch the broadcast live. Subscribers in region B: the same record, but with a one-hour shift, and so on. That is, the broadcasting was created once, recorded, and then distributed many times by Timeshift. At the same time, all the listed regions received exactly the live broadcast.
Lock or record on demand
Some providers offer subscribers an on-demand recording service (nPVR service option) for extra money. What does that mean? That a person can record a movie (or a show, game, etc.), keep it in the archive (say, for 2-3 months), and then review it. This functionality in Flussonic is called Lock. Let’s take a closer look at it.
Suppose the window during which the provider stores streams is 6 days. What Lock does is that, on demand, it “freezes” a certain fragment on the DVR from this window, not allowing it to be removed. The selected fragment (movie, etc.) will be stored as long as the subscriber has an active plan with the telecommunications operator.
This way, the provider has a constantly updated tape. And can use Lock: for a fee to “freeze” part of this feed for an individual viewer. (It is possible to save a fragment even for all subscribers at the same time).
IPTV OTT. How to calculate the storage size of an archive
Let’s start with the main thing: the size of the storage will largely depend on the failover you need to implement. Considering the Flussonic cross-replication model, by duplicating storage, we can recover lost data if one of the servers fails. When restoring this one, the system copies to it those parts of the archive that were lost while offline. At the same time, the other one was online and all this time provided replay and recording of streams.
So cross-replication allows you to get a pretty good failover system. And this must be taken into account in the calculations.
Calculation of DVR
To calculate the storage size, you will need to:
- Calculate how much disk space is needed to store one second of the transmission of a TV channel prepared for playback on different devices (mbr profile)
- Calculate how much disk space is needed to store cable or antenna TV channels of the same type for the entire depth of the archive.
- Add the data of all available television channels.
Let’s take a closer look.
The MBR profile of a TV channel calculation
The MBR profile is a characteristic of the output stream that you are going to write to the archive. Each television channel is determined (in the context of the calculation) by the parameter values of all the video and audio tracks.
Video track parameters: resolution and bit rate. Audio track parameter: bit rate.
If the value of the input parameter is the bit rate it is, say, 3000 kbps; then, to record this track, 3000 kbit will be needed for every second of the video. The sum of the bit rate of the audio and video tracks of a TV channel in the output stream will be exactly the amount of disk space required to store 1 second of the broadcast of the TV channel.
Calculation of disk space to store TV channels of the same type for the entire depth of the archive.
Now, the amount of bit rate obtained above is multiplied by the depth of the archive (in seconds). That is, 3000 kbps for, say, 8 days (or 691200 seconds). If there are only say 10 channels with this MBR profile, then the disk space to store these 10 TV channels with a depth of 8 days will be 691200 * 10 * 3000/8/1024/1024/1024 ≈ 2.41 TB.
Instructions for the DVR calculator
To calculate the storage size, you can use the calculator below.
- Fill in the TV Shows column with the current values for the number of shows on the service.
- Complete the transcoding profiles for each type of TV show.
- Insert the values into the Depth column.
|Input||TV Programs||Output, MBR||Profiles per input||Archive depth, days||Archive inbound, Mbps||Archive, write on disk, MB/s||Archive diskspace, TB|
Squeeze more. Scale your OTT and IPTV services with Flussonic
What happens to the “infinite” feed during the transmission? It records new video segments. At the same time, it needs to delete the old segments. And simultaneously it gets a ton of requests to see completely different segments in different places in this feed.
Therefore, as soon as the demand for TV services increases, providers inevitably get into the DVR “bottleneck”. Also, the total number of subscribers may not increase; it will be enough to increase the proportion of those who use the catch up scenario for example. The existing server will no longer support such a load, and you can forget about providing high-quality service without the screen freezing.
There are 3 server configuration options (Flussonic can support all of them).
A server without caching
Receives broadcast → Records it to HDD → Plays for subscribers
If the operator’s services are used by 500 subscribers, this option is suitable. If the operator provides a large-scale service, it is inevitable that the hard drives will be overloaded due to the heavy load on the disk subsystem (as HDDs are slow by default). The result: users pick up the file very slowly and there is braking and interference on the screen.
Server with caching
Receives → Records to HDD → Caches hot segments to SSD → Plays cold segments from HDD and hot segments from SSD to subscribers
Fast SSD drives gather popular archive segments. Therefore, these popular segments are delivered to subscribers from cache, and the load is distributed across the disk subsystem. (Note that we are talking about individual segments; the cache does not store, say, an entire day’s log. Why this is important, we will discuss below).
However, when scaling the service with a cached infrastructure, the provider may need 1 or more new servers, each costing around $ 10,000. (Also, don’t forget that you will have to purchase additional disk systems for the cache servers.)
For those who really do not want to spend twenty thousand dollars of the budget, we recommend option 3.
One server for cold content + one server for hot content
Scheme 1 (parallel):
Cold content server (8 days):
Receives stream → Saves it to hard drive → Plays cold content to subscribers
Hot content server (1 day):
Receives stream → Records it on SSD → Plays current content to subscribers
Scheme 2 (sequentially):
Cold content server (8 days):
Receives broadcast → Records it to HDD → Plays live broadcast and cold content on active content server Hot content server (1 day):
Receives the stream → Records it to the SSD → Plays hot content from the local SSD and cold content from the cold content server to subscribers
According to statistics, the popularity of the archive is about 20%. That is the number of users, out of the total number of views, that access it. Of these, 50 percent fall into the depth of the first day. In simple terms, people mostly go back to yesterday’s broadcast.
Therefore, the recordings with the depth of the last day with hot and popular content can be stored on the SSD (it is 10 times faster, respectively, it can serve 10 times more users). And the cold content is on the hard drive. It is watched by a smaller number of people (respectively, there is less load), so it can be delivered from slow discs. Ultimately, the overall load is optimized.
In fact, the most interesting economic effect of using Flussonic technology in option 3.2 is achieved due to uneven load distribution within the day. People watch more television in the afternoon and at night. During a period from 5:00 P.M. to 11:00 P.M., it represents up to 60% of the daily load. It turns out that you can write to an additional server for just 5 hours, instead of 24.
Speaking of numbers, we calculated and experimentally compared the egress rate by scaling with caching (option 2) and scaling using different servers for hot and cold content (option 3.2). The egress rate increased from 1.2 to 3.4. That is, almost 3 times!
The Digital Video Recording in Flussonic is specially designed to work with large amounts of streaming data. Patented RAID-0 recording technology cleverly distributes the load across the disk subsystem. Thanks to this, the Flussonic DVR easily receives, records, deletes and at the same time sends thousands of different video streams.
Live streaming + Video on Demand scenarios
Live Streaming and VoD are two coupled scenarios that transition between them. In the context of this scenario, Flussonic allows you to broadcast the event online and be guaranteed to receive a recording immediately after it ends.
First, we show the event live, recording it to the archive (live streaming). As soon as it is finished, the archive with the recorded video is exported to MP4 (this is the transition). After that, the file can be processed and viewed on demand (video on demand).
Note: Video on Demand is a video access system that works on the principle of delivering content on demand.
Rewind for online conferences
Offline does not allow us to quickly go back and see the start of the event that we were a little late for. However, online changes everything.
The rewind scenario allows you to rewind a live event to the point in the past when it started. Let’s think about the live broadcasts on YouTube: these videos always open at the “now” point. From this point “now” we have the opportunity to go back to any depth to the point of the beginning of this live video.
Let’s imagine that a certain broadcast (for example, a free one-hour online webinar) starts at 9:00 AM. It is now 10:00 AM. And the webinar is not over yet (in other words, it is still streamed live). When we open the webinar, it opens at the “now” moment, that is, at 10:00 A.M. Within this window (from 9:00 AM to 10:00 AM), we have the opportunity to fast forward, pause and review as many times as we want.
In short, a live stream is recorded with no limit on the depth of the archive (since all live events are quite short). The rewind scenario allows the user to access the archive of the video segments until the live broadcast ends.
Exporting the broadcasting as an mp4 file
Let’s go back to the YouTube example. The live stream is over and we still want people to find and watch the video. As discussed earlier, during the online conference itself, the live recordings are stored on the DVR and the “rewind” scenario is available to the viewer. It would be possible to continue, after the end of the live, organizing the views from the there. But it’s not exactly convenient, and here’s why.
It is a single “infinite” tape. It is not possible to work on a separate fragment within it. You cannot change it (for example add a solid line or logo), transcode to multiple qualities, or move it. To do any post-processing, Flussonic first loads the “infinite tape” into mp4 – to get files that have a beginning and an end.
Digital Video Recording in Flussonic is designed in such a way that, unlike other technologies, the export is done in a few minutes, without the use of additional tools. No need to “manually” download the entire feed, find the desired segment, cut it, and download it. In the timeline, simply select the desired segment and the program will place it as a VoD file in the specified location.
File storage and organizing views on demand
After uploading, the processed files are sent to local or cloud storage: S3, ftp, http, Swift, etc. With Flussonic, you can configure VoD streaming from any storage, after which the video will be available at any time for an unlimited number of users.
Flussonic has a wide range of features: multi-catalog distribution, multi-language streaming, subtitle enablement, adaptive streaming (to ensure comfortable viewing for Internet-connected users at different speeds), file playback using HLS, HDS protocols, RTMP, MSS. And with the full built-in file manager, it’s convenient to set up streaming, download, and view files.
CCTV. Eternal storage and instant search of events from thousands of surveillance cameras
Digital Video Recording in video surveillance was used before it became popular. This is exactly the area where long-term storage technology for video recordings was first used.
Transmitting a large number of frames per second, as in OTT, is not so interesting in this case. Especially if we rent a parking lot at night. (Here, on the other hand, it is more convenient to set the camera settings to record 3 frames per second, instead of 25, and save disk space up to almost ten times.) What is really important in the video surveillance service is the recording of a large number of sources and the instant access to video data about events and traffic markers.
Real-time video recording and viewing with no archive size limit
Today, there are two models of video surveillance in the context of Digital Video Recording. The first is the rapid response model. It involves working with live video in real time. A person observes what is happening on the monitor and presses the SWAT call button, depending on what is happening in the frame. This function can also be performed by a video analysis system that recognizes sabotage, fire, flood, theft, etc.
Storage of information with reference to timestamps (motion detector in the frame)
Consider the second event response model. Its key feature is the storage on a separate track of information about what is happening in the frame. Here in the DVR, everything is recorded from the cameras and the storage depth can go up to several months.
Let’s go back to the parking lot example. The owner left the car in the parking lot and went on vacation. When he returned after 3 weeks, he did not find the car. It is clear that in this case he would like to see a recording of the moment when his car was stolen.
Thanks to Digital Video Recording technology, it’s possible to store the following information: movement in the frame, license plates (if there is recognition of numbers), faces (the recognized faces are linked to databases with names, addresses, etc.). This can be useful when setting up a security system.
Flussonic recognizes what’s in the frame, binds the timestamps to the events, and records all of this as additional information labels.
The search is carried out precisely on these labels and their data. In just a matter of a couple of seconds, the car owner finds a moment in the past when the car with the desired state number (or a fragment of himself) passed through the barrier and left the premises.
Where else can such a video surveillance model be used? From criminal law incident investigations to domestic video surveillance. If the user, for example, wants to see all the moments when someone walked through the door, he can do it almost instantly from a mobile phone.
How to store an archive of thousands of IP cameras
Storing recordings from a thousand surveillance cameras is not the same as storing a couple of hundred television channels. Also, in this case, you need to store it for a long time. In some countries, in general, the law requires that you store certain videos for at least 3 years. And in the United States, for example, court records are stored for about 10 years.
In the context of video surveillance, don’t use S3-type cloud storage, because it’s just too expensive. Video surveillance logs are stored on a physical server.
However, hard drive storage has an obvious drawback: in the event of a disk failure, all data will be lost. Therefore, we developed the Flussonic RAID technology, which is a mechanism for combining disks in an array. The key feature that distinguishes Flussonic RAID from other similar solutions is that the entire archive will not be lost by the operator if one of the drives fails. Also, you don’t need to buy a hardware RAID controller which can get quite expensive. Flussonic itself monitors the health of the disks and distributes the data evenly between them.
The full video path that Flussonic is working on consists of:
- Transcode (including input protocol unpacking)
- Recording to archive (here only, we save the streams to the DVR ready for broadcasting. In fact, we can deliver the video directly from there to the audience over the Internet, but don’t forget about the “bottleneck”)
- Deliver (players and streamers adapted to a large number of reproductions for any number of viewers)
Resource requirements in the context of DVR:
- CPU (load tends to zero, as when using the Flussonic technology, no complex system calculations are required)
- Network bandwidth (you need to receive live signals during the live broadcast and should immediately give it to the viewer)
- Disk I/O (disk systems required to increase the power of EDGE servers). According to the strategy we recommend (option 3.2 of server configuration), to scale the TV service 2 times, it is enough to buy disk systems. This will cost about a quarter of the price of the archive. (Recall that with the caching way of scaling, the provider will pay 2 prices at a time, instead of ¼).