We have restored card payments since September 13, 2024.

Please write to sales@flashphoner.com or Skype flashphoner.com with any questions regarding payments and subscription renewals.

Due to technical reasons, we are temporarily unable to accept card payments.

For direct payments via Wire-Transfer or USDT, please contact us at:

sales@flashphoner.com

Sorry for the inconvenience.

We will inform you as soon as payments are operational. Stay tuned for updates on our website.

Let’s imagine a situation: Oleg is a full-stack developer working with Windows and his new task is to develop a client-server application for streaming… For catching the RTSP cameras, to be exact. Of course, he can use a cloud server but then a debug of problems with the channel is added to the debug of possible problems with the client code or server settings, so testing on a local network is more convenient, in particular because it’s free. Or he can use Docker but here are the other problems come up: due to network problems, Docker on Windows is unusable, and the workaround – running Docker in a virtual machine – complicates the work too much.

What should he do in this case? The best option is to use WSL, but exactly how, we will tell you (and show) using the example of a Web Call Server (WCS), which will help to convert RTSP streams to WebRTC.

Docker containers are, without a doubt, a quick, easy, and convenient solution for your testing environment. But what about deploying a more loaded system using containers? How well will it run? Can Docker really be used in production?

We see video surveillance systems in various places — shops, malls, banks, hotels, office buildings, cottages and apartments, parking lots and busy intersections — it is difficult to name all possible options for installing cameras. There is also a great variety of different hardware and software solutions for organizing video surveillance: analog cameras and hardware video recorders of all kinds and colors, software solutions, cloud solutions, IP cameras that work both offline and with server or software solutions etc. Of all options, we are interested in those that provide video streams via RTSP.

It’s hard to imagine video streaming without recording. Recording video streams is one of the most demanded functions that can be used in various work scenarios, for example, video messages, video surveillance archive, recording interviews, video shooting outdoors and many others.

In our blog, we have been recently looking at all kinds of stress tests. In one of the previous articles we tested one of the common server operation scenarios — “One stream, many viewers.” In this scenario, one WebRTC video stream is published on the server and a large number of viewers connect to view this stream. This is how, for example, the competition broadcast works: the broadcast is on, and the users are watching. But quite often you need to implement another approach — “Many streams, many viewers” — when many WebRTC streams are published on the server at the same time and each published stream has one viewer. This option can be used to organize a simple one-on-one video chat without using a mixer or MCU.

In this article, we will analyze the method in detail and conduct a stress test to simulate the connection of 200 users, each of whom simultaneously publishes and views WebRTC streams.

Mixing is a rather popular tool among streamers.

Mixers can be found under the hood of many products, most common of which are chats, video conferencing systems, and basic surveillance systems.

In a previous article we already discussed how to load test and choose the right server depending on the tasks and budget.

The testing turned out to be a “spherical chicken in vacuum.” We published a stream on one WCS, which we then retrieved a number of times with a second WCS, and, based on the results of these tests, drew conclusions about the hardware efficiency.

Such a test of one server with another of the same kind is not a completely independent test. In this case, the stream subscription procedure is somewhat simplified for the server under test, compared to the browser in which the end user will watch the stream. Therefore, the test results will be somewhat different from the real picture.

The simplest and most logical way to test is to perform a manual test – open the browser, open the tab with the player, specify the stream name and click “Play.” Repeat 1000 times.

And that’s where this all falls apart. First, you have to run the player 1000 times. I doubt it will be easy! Secondly, you need to prepare a cluster of several powerful servers to run the browser with a thousand tabs on which the video will be played. Thirdly, the manual test under these conditions will take quite a long time. For these reasons, the manual test should not be considered as one of the load testing methods.

In this article we’ll review another way of testing — using a Нeadless-browser and compare the results of such testing with testing based on stream capture.

John was happy. He’d just turned in a commission and he was enjoying a relaxing evening. Hours upon hours of development, optimization, testing, changes and approvals were left behind.

And just as he was contemplating picking up a nice cold beer, his phone rang.

“Only half the viewers could connect to the stream!” — said the voice on the other side of the line.

With a resigned sigh, John opened up his laptop and started pouring through logs.

Unfortunately, in all of those many tests, he never considered that a big number of viewers would mean great strains for the server infrastructure and the network itself.