As you know, YouTube doesn't have a feature for capturing an RTSP stream, but we would like to change this and help YouTube to make their viewers happy.

Virtual reality is on the rise these days. The equipment that was previously the exclusive preserve of crazy scientists geeks with big money from the Ministry of Defense back in the The Lawnmower Man days, is currently affordable for ordinary people; those whose pockets are empty, can assemble a VR headset from cardboard and a smartphone according to many recipes.

Publish and Play

There exist two main functions of WebRTC operation on the server side in the field of streaming video: publishing and playing. In the case of publishing, the video stream is captured from the web camera and moves from the browser to the server. In the case of playing, the stream moves in the opposite direction, from the server to the browser, is decoded and played in the browser’s HTML5 <video> element on the device’s screen.

RTSP is a simple signaling protocol which they cannot replace with anything for many years already, and it has to be admitted that they don't try really hard.

For example, we have an IP camera that supports RTSP. Anyone who has ever tested the traffic with a Sharkwire cable will tell you that first there comes DESCRIBE, then PLAY, and then the traffic begins to pour directly via RTP or wrapped in the TCP channel for instance.

Popular cloud hosting DigitalOcean has recently launched its new marketplace selling preconfigured images that can help to quickly deploy an application server. It’s much like AWS, but DO is for those already using this provider’s services. Let’s see how to deploy a simple server for WebRTC streaming with a DO account for a $10/month fee based on Flashphoner WebCallServer and how such a server can be of use.

In any project, a great deal of importance is placed on the selection of server hardware and WebRTC streaming is no exception. One of the key principles of such a selection is balance – the hardware should be powerful enough to handle the streams with no drops in quality, but not too powerful so as to waste resources. So, how does one choose the right server?

This article is a continuation of our series of write-ups about load tests for our server. We have already discussed how to compile metrics and how to use them to choose the equipment, and we also provided an overview of various load testing methods. Today we shall look at how the server handles stream mixing.

In the previous article we went over a load test whose data could be used to choose a load-appropriate server. In the course of the testing, we would publish a stream on one WCS, and we would pick up that stream several times using a second WCS. The acquired results could be used as a basis for decisions on server operability.

Some would (justly) have concerns regarding the possible biases in such a test — after all, one of our servers was used to test another one of our servers. Could it be that we were using a specially optimized code that skewed the results in our favor?

Monitoring systems are a vital tool for any system administrator, because they can be used to extract specific information from services, such that:

In the comment sections of our articles about our server there are often users who say: "Why would you jump through so many hoops, when you can do the same with a single line of code in FFmpeg!?"

A few weeks ago we wrote an article about Docker and WebRTC servers and talked about the intricacies of launching containers. Our readers (rightly) questioned whether Docker was a suitable tool for production, for the following reasons:

The developer or owner of a software product often faces the question of choosing a suitable location for hosting server capacity. As you know, software always meets hardware.

In the previous article we refreshed our memory of WebRTC CDN and the ways this technology helps to minimize latency for WebRTC streams. We also discussed why load balancing and autoscaling wouldn't be amiss in CDNs. Here are the main points from the article:

The modern browsers do not give users a choice between using WebRTC and not using it. And while you can playback streams using HLS or MSE, WebRTC remains the only tool for capturing camera feeds and publishing streams from a browser. The browser developers have accepted this "format" and integrated it into their products – just as they used to support the Flash Player as a plugin. The only difference is that WebRTC comes natively integrated into the browser — as code, not a plugin. If, in a few years, a new and better library for video streaming is introduced they will undoubtedly make a switch. But these days, Chrome maintains its dominance, so no contenders for WebRTC are in sight.

The vast majority of IT specialists in various fields strive to perform manually as few actions as possible. I won't be afraid of the loud words: what can be automatized, must be automatized!

Let's imagine a situation: you need to deploy a lot of servers of the same type and do it quickly. Quickly deploy, quickly undeploy. For example, to deploy test rigs for developers. When development is carried out in parallel, you may need to separate the developers, so they don't impede each other and possible errors of one of them don't block the work of the others.

There may be several ways to solve this problem:

Alice is an experienced full stack developer, who is capable of writing a SAAS project framework on her favorite framework using php in a week. As for frontend, she prefers Vue.js. 

A client contacts you via Telegram, asking you to develop website that will be the meeting place for the employer and the employee to conduct an in-person interview. In-person means face-to-face, a direct video contact in real time with video and voice. «Why not use Skype?» some may ask. It just so happened that serious projects – and each startup undoubtedly considers itself a serious project – are trying to offer an internal communications service for a variety of reasons, including:

George shut his laptop and rubbed his sleep-deprived red eyes. "Customers continue to complain about stream freezing; the new fix package did not help at all! What do I do with this (censored) HLS?" he said.

The browser is not only hypertext, but also a streamer

Browsers have had players for a long time, but the story is different with the video encoder and streaming. Now, in almost any browser of the latest version, we can find modules for encoding, streaming, decoding, and playback. These functions are available through the JavaScript API, and the implementation is called Web Real Time Communications or WebRTC. This library built into browsers can do quite a lot: capture video from a built-in, virtual or USB camera, compress it with H.264, VP8, and VP9 codecs, and send it to the network via SRTP protocol; i.e., it functions as a software streamer video encoder. As a result, we see a browser that has something similar to ffmpeg or gstreamer, compresses video well, streams on RTP, and plays video streams.

In the first part, we have deployed a simple dynamic CDN for broadcasting WebRTC streams to two continents and have proved on the example of a countdown timer that the latency in this type of CDN is actually low.

In the second part, we have incorporated dedicated servers into the CDN for performing the task of transcoding in order to provide good broadcast quality to our viewers based on the devices they use and the channel quality. In this manner, all published streams in our CDN are available to all the viewers.

Now, assume that a company is starting to introduce its monetization strategy where a number of streams should be available for free and the rest on a subscription basis. Or, for example, webinars for in-house staff training are broadcasted simultaneously, but each subsidiary has a separate stream, and disclosing the sales techniques used in Southeast Asia to the managers from CIS countries is undesirable.