Solving the problem of online broadcasting from an IP camera, generally speaking, does not require the use of WebRTC. The camera itself is a server, has an IP address and can be connected directly to the router to distribute video content. So why use WebRTC technology?

There are at least two reasons for this:

1. As the number of viewers of an Ethernet broadcast increases, first the lack of channel thickness will be felt, and then the resources of the camera itself.

2. As mentioned above, the IP camera is a server. But what protocols can it use to send video to the desktop browser? Mobile device? Most likely this will be HTTP streaming, where video frames or JPEG images are transmitted via HTTP. HTTP streaming, as you know, is not entirely suitable for real-time video streaming, although it has proven itself well in on-Demand video, where stream interactivity and latency are not particularly important. In fact, if you're watching a movie, a delay of a few seconds won't make it any worse unless you're watching the movie at the same time as someone else. "Oh no! Jack killed her! - Alice writes a spoiler in the chat to Bob 10 seconds before the tragic ending.”

Or it will be RTSP/RTP and H.264, in which case a video player plugin such as VLC or QuickTime must be installed in the browser. Such a plugin will capture and play video, just like the player itself. But we need real browser-based streaming without installing additional crutches/plugins.

First, let’s take a snapshot of the IP camera to find out what exactly this device is sending towards the browser. The test subject will be the D-Link DCS 7010L camera:

You can read more about installing and configuring the camera below, but here we’ll just look at what it uses for video streaming. When entering the camera admin panel via the web interface, we see something like this (sorry for the landscape):

The picture opens in all browsers and freezes evenly, about once a second. Considering that both the camera and the laptop on which we are watching the stream are connected to the same router, everything should be smooth and beautiful, but this is not the case. Looks like HTTP. Let's launch Wireshark to confirm our guesses:

Here we see a sequence of TCP fragments 1514 bytes long

And a final HTTP 200 OK with the length of the received JPEG:

We don't need this kind of streaming. Not smooth, jerks HTTP requests. How many such requests per second can the camera handle? There is reason to believe that at 10 spectators or earlier the camera will safely bend or begin to glitch terribly and produce slides.

If you look at the HTML page of the camera admin panel, you will see this interesting code:

If(browser_IE) DW(""); else ( if(mpMode == 1) var RTSPName = g_RTSPName1; else if(mpMode == 2) var RTSPName = g_RTSPName2; else if(mpMode == 3) var RTSPName = g_RTSPName3; var o=""; if (g_isIPv6) //because ipv6 does not support rtsp. var host = g_netip; else var host = g_host; o+=""; //alert(o); DW(o); )

RTSP/RTP is exactly what you need for proper video playback. But will this work in the browser? - No. But if you install the QuickTime plugin, everything will work. But we do purely browser-based streaming.

Here we can also mention Flash Player, which can, through a suitable server like Wowza, receive an RTMP stream converted from RTSP, RTP, H.264. But Flash Player, as you know, is also a browser plugin, although it is incomparably more popular than VLC or QuickTime.

In this case, we will test the same RTSP/RTP re-streaming, but a WebRTC-compatible browser will be used as a playing device without any additional browser plugins or other crutches. We will set up a relay server that will take the stream from the IP camera and send it to the Internet to an arbitrary number of users using browsers that support WebRTC.

Connecting an IP camera

As mentioned above, a simple D-Link DCS-7010L IP camera was chosen for testing. The key selection criterion here was the device’s support for the RTSP protocol, since it is through this that our server will receive the video stream from the camera.

We connect the camera to the router using the included patch cord. After turning on the power and connecting to the router, the camera took an IP address via DHCP, in our case it was 192.168.1.34 (If you go to the router settings, you will see that the DCS 7010L device is connected - that’s it). It's time to test the camera.

Open the specified IP address in the browser 192.168.1.34 to get to the camera administrator web interface. By default there is no password.

As you can see, the video from the camera is broadcast correctly in the admin panel. At the same time, periodic shaking is noticeable. This is what we will fix using WebRTC.

Camera setup

First, we disable authentication in the camera settings - as part of testing, we will give the stream to everyone who asks. To do this, go to the settings in the camera web interface Setup - Network and set the option value Authentication to Disable.

There we also check the value of the RTSP protocol port; by default it is 554. The format of the transmitted video is determined by the profile used. You can set up to three of them in the camera, we will use the first one, live1.sdp - by default it is configured to use H.264 for video and G.711 for audio. You can change the settings if necessary in the section Setup – Audio and Video.

Now you can check the camera's operation via RTSP. Open VLC Player (you can use any other player that supports RTSP - QuickTime, Windows Media Player, RealPlayer, etc.) and in the Open URL dialog set the RTSP address of the camera: rtsp://192.168.1.34/live1.sdp

Well, everything works as it should. The camera regularly reproduces the video stream in the player via the RTSP protocol.

By the way, the stream is played back quite smoothly and without artifacts. We expect the same from WebRTC.

Server installation

So, the camera is installed, tested with desktop players and ready for broadcasting via the server. Using whatismyip.com we determine the external IP address of the camera. In our case it was 178.51.142.223. All that remains is to tell the router that when accessing via RTSP on port 554, incoming requests will be transmitted to the IP camera.

Enter the appropriate settings into the router...

...and check the external IP address and RTSP port using telnet:

Telnet 178.51.142.223 554

Having made sure that there is a response on this port, we proceed to install the WebRTC server.

A virtual server on Centos 64 bit on Amazon EC2 will be responsible for hosting.
To avoid performance problems, we chose an m3.medium instance with one VCPU:

Yes, yes, there is also Linode and DigitalOcean, but in this case I wanted to try Amazon.
Looking ahead, I’ll write that in the Amazon EC2 control panel you need to add several rules (forward ports), without which the example will not work. These are ports for WebRTC (SRTP, RTCP, ICE) traffic and ports for RTSP/RTP traffic. If you try, Amazon's rules should have something similar for incoming traffic:

By the way, with DigitalOcean everything will be simpler, just open these ports on the firewall or turn off the latter. According to the latest experience in operating DO instances, they still issue a static IP address and don’t bother with NATs, which means port forwarding, as in the case of Amazon, is not needed.

We will use WebRTC Media & Broadcasting Server from Flashphoner as server software that relays the RTSP/RTP stream to WebRTC. The streaming server is very similar to Wowza, which can stream an RTSP/RTP stream to Flash. The only difference is that this stream will be sent to WebRTC, and not to Flash. Those. honest DTLS will pass between the browser and the server, an SRTP session will be established and the stream encoded in VP8 will go to the viewer.

For installation we will need SSH access.

Below the spoiler is a detailed description of the executed commands

1. Downloaded the server installation archive:
$wget flashphoner.com/downloads/builds/WCS/3.0/x8664/wcs3_video_vp8/FlashphonerMediaServerWebRTC-3.0/FlashphonerMediaServerWebRTC-3.0.868.tar.gz
2. Expanded:
$tar -xzf FlashphonerMediaServerWebRTC-3.0.868.tar.gz
3. Installed:
$cd FlashphonerMediaServerWebRTC-3.0.868
$./install.sh
During the installation process, we entered the external IP address of the server: 54.186.112.111 and internal 172.31.20.65 (the same as Private IP).
4. Started the server:
$service webcallserver start
5. Checked the logs:
$tail - f /usr/local/FlashphonerWebCallServer/logs/server_logs/flashphoner.log
6. Make sure that the server has started and is ready to work:
$ps aux | grep Flashphoner
7. Installed and launched apache:
$yum install httpd
$service httpd start
8. Downloaded the web files and placed them in the standard Apache folder /var/www/html
cd /var/www/html
$wget github.com/flashphoner/flashphoner_client/archive/wcs_media_client.zip
$unzip webrtc_media_client.zip
9. Entered the server’s IP address into the flashphoner.xml config:
10. Stopped the firewall.
$service iptables stop

In theory, instead of point 10, it would be correct to set all the necessary ports and firewall rules, but for testing purposes we decided to simply disable the firewall.

Server Tuning

Let us recall that the structure of our WebRTC broadcast is as follows:

We have already installed the main elements of this diagram; all that remains is to establish the “arrows” of interactions.

The connection between the browser and the WebRTC server is provided by the web client, which is available on Github:. A set of JS, CSS and HTML files is simply thrown into /var/www/html at the installation stage (see point 9 above under the spoiler).

The interaction between the browser and the server is configured in the XML configuration file flashphoner.xml. There you need to enter the server’s IP address so that the web client can connect to the WebRTC server via HTML5 Websockets (point 9 above).

The server setup ends here; you can check its operation:

Open the web client page index.html in the browser (for this, Apache was installed on the same Amazon server with the command yum -y install httpd):

54.186.112.111/wcs_media_client/?id=rtsp://webrtc-ipcam.ddns.net/live1.sdp

Here webrtc-ipcam.ddns.net is a free domain obtained through the dynamic DNS server noip.com, which links to our external IP address. We told the router to redirect RTSP requests to 192.168.1.34 in accordance with the NAT network address translation rules (also see above).
Parameter id=rtsp://webrtc-ipcam.ddns.net/live1.sdp specifies the URL of the stream to play. The WebRTC server will request streams from the camera, process them and send them to the browser for playback via WebRTC. Perhaps your router supports DDNS. If not, then the IP camera itself has such support:

And this is what DDNS support looks like in the router itself:

Now you can start testing and evaluate the results.

Testing

After opening the link in the browser, a connection is made to the WebRTC server, which sends a request to the IP camera to receive the video stream. The whole process takes a few seconds.

At this time, a connection is established between the browser and the server via websockets, then the server requests the IP camera via RTSP, receives the H.264 stream via RTP and transcodes it into VP8 / SRTP - which ultimately plays the WebRTC browser.

At the bottom of the video, the URL of the video stream is displayed, which can be copied and opened for viewing from another browser or tab.

We make sure that this is really WebRTC.

What if we were deceived, and the video from the IP camera is again transmitted via HTTP? Let's not idly look at the picture, but let's check what kind of traffic we actually receive. Of course, we launch Wireshark and the debugging console in Chrome again. In the Chrome browser console we can see the following:

This time nothing flashes and no images are visible transmitted via HTTP. All we see this time are Websocket frames and most of them are ping/pong types to maintain a Websocket session. Interesting frames: connect, prepareRtspSession and onReadyToPlay - this is the order in which a connection to the server is established: first a Websocket connection, and then a stream request for playback.

Here's what it shows chrome://webrtc-internals

According to the graphs, we have a bitrate from the IP camera of 1Mbps. There is also outgoing traffic, most likely these are RTCP and ICE packets. The RTT to the Amazon server is about 300 milliseconds.

Now let’s look into Wireshark, you can clearly see UDP traffic from the server’s IP address. In the picture below, the packets are 1468 bytes. This is WebRTC. More precisely, SRTP packets carrying VP8 video frames, which we can observe on the browser screen. In addition, STUN requests slip through (the lowest packet in the picture) - this is WebRTC ICE carefully checking the connection.

It is also worth noting the relatively low latency (ping to the data center was about 250 ms) for video playback. WebRTC works over SRTP/UDP, and this is, after all, the fastest way to deliver packets, unlike HTTP, RTMP and other TCP-like streaming methods. Those. The delay visible to the eye should be RTT + the time of buffering, decoding and playback by the browser. Visually, this is the case in this case - the eye almost does not see the delay, it is less than 500 milliseconds.

The next test is connecting other viewers. I managed to open 10 Chrome windows, and each of them showed a picture. At the same time, Chrome itself began to become a little dull. When opening the 11th window on another computer, playback remained smooth.

About WebRTC on mobile devices

As you know, WebRTC is supported by Chrome and Firefox browsers on the Android platform.
Let's check whether our broadcast will be displayed there:

The picture shows an HTC phone; the Firefox browser displays video from the camera. There are no differences in playback smoothness from the desktop.

Conclusion

As a result, we were able to launch a WebRTC online broadcast from an IP camera to several browsers with minimal effort. No dancing with a tambourine or rocket-science was required - only basic knowledge of Linux and the SSH console.

The quality of the broadcast was at an acceptable level, and the playback delay was invisible to the eye.

To summarize, we can say that browser-based WebRTC broadcasts have a right to exist, because in our case, WebRTC is no longer a crutch or a plugin, but a real platform for playing video in the browser.

Why don't we see widespread adoption of WebRTC?

The main obstacle is perhaps the lack of codecs. The WebRTC community and vendors should make an effort and introduce the H.264 codec into WebRTC. There's nothing to say against VP8, but why give up millions of compatible devices and software that work with H.264? Patents, such patents...

In second place is not full support in browsers. With IE and Safari, for example, the question remains open and there you will have to switch to another type of streaming or use a plugin like webrtc4all.

So in the future, we hope to see more interesting solutions in which transcoding and conversion of streams will not be needed and most browsers will be able to play streams from various devices directly.

RTSP (Real Time Streaming Protocol)– a real-time streaming protocol that contains a simple set of basic commands for controlling a video stream.

Connecting RTSP sources and IP cameras in video conferences

The RTSP protocol allows any TrueConf user to connect to IP video cameras and other media content sources broadcasting using this protocol to monitor remote objects. The user can also connect to such cameras to broadcast images during a video conference.

Thanks to RTSP protocol support, TrueConf Server users can not only connect to IP cameras, but also broadcast video conferences to RTSP players and media servers. Read more about RTSP broadcasts.

Benefits of using IP cameras with TrueConf software solutions

• By installing an IP camera in an office or industrial workshop and connecting to it at any convenient time, you will be able to control the production process of your company.
• You can monitor remote objects around the clock. For example, if you are going on vacation and do not want to leave your apartment unattended, simply install one or more IP cameras there. By making a call to one of these cameras from your PC with the TrueConf client application installed, you can connect to your apartment at any time and see in real time what is happening there.
• In TrueConf client applications for Windows, Linux and macOS, all users have access to the ability to record video conferences, thanks to which during video surveillance you can record any events and receive documentary evidence of them.

How to check the ability to broadcast an RTSP stream from an IP camera in various Web browsers

Let's check the display of an RTSP video stream in Chrome, Firefox, Safari browsers on desktops running Windows, Mac OS X, Linux and mobile devices running Android and iOS

Checking the RTSP stream in VLC

To quickly make sure that the RTSP stream is available and streams video, open it in VLC player. If the stream plays correctly, we move on to testing the web interface. You can get the RTSP URL in the IP camera control panel or use some publicly available RTSP video stream, for example this one: rtsp://b1.dnsdojo.com:1935/live/sys3.stream

Testing RTSP-WebRTC stream in Google Chrome and Mozilla Firefox browsers

We make sure that the same RTSP stream is played on a regular HTML page in the Chrome and Firefox browsers.

1. Load the demo interface at , menu ‘Demo / Streaming Min’. This is a minimal HTML5 web interface that uses WebRTC technology to display an RTSP video stream in Chrome and Firefox browsers.

2. Establish a connection to the Web Call Server

3. Enter the RTSP address of the camera and start playing the stream:

As a result, we successfully tested the playback of the RTSP stream in the Google Chrome browser. A similar test can be carried out with the Firefox and Opera browsers on those desktop and mobile platforms that support WebRTC technology in browsers.

Testing an RTSP-Websocket stream in the Safari browser under iOS and Mac OS X

Browsers on iOS devices do not support WebRTC technology. For this reason, a separate player ‘WS Player Min’ is used, which takes the stream via the Websocket protocol and plays it in the HTML5-Canvas element of the browser.

1. Just as in the case of Chrome, you need to open the demo interface page, but select a different menu item:

2. After this, establish a connection to the Web Call Server

3. Enter the previously known RTSP broadcast address and play the video stream:

Thus, the above demonstrates the ability to view RTSP traffic converted using Web Call Server on most common Web browsers, including the most popular mobile platforms.

The next step is to add an HTML5 RTSP player to your own website. The adding process is described in detail in the adjacent Implementation section.

Videos describing the testing process of RTSP-WebRTC and RTSP-Websocket player

RTSP-WebRTC player for Chrome and Firefox

RTSP-Websocket player for iOS Safari

Download Web Call Server 5

System requirements: Linux x86_64, 1 core CPU, 2 Gb RAM, Java

Installation:

1. wget https://site/download-wcs5.2-server.tar.gz
2. Unpack and install using the script "install.sh"
3. Start the server using the command "service webcallserver start"
4. Open the web interface https://host:8444 and activate your license

If you are using Amazon EC2 servers, there is no need to download anything.

The manual that comes with the CCTV camera may not always contain information about the RTSP protocol according to which the device operates. However, there are a large number of cases when it is necessary to use this protocol, so it becomes necessary to find out its address.

The owner of a video surveillance system may need to know the RTSP stream in various situations:

• to connect the video camera to the cloud server;
• to set up the transmission of video information to the website;
• to play videos in the player stream on different devices - mobile phone, laptop or tablet.

Why is the RTSP protocol needed?

The protocol name RTSP transfers control to online mode. Thus, Real Time Streaming Protocol helps to manage online video streaming. This protocol is very often used in IP video surveillance, since it contains a description of the necessary commands.

The RTSP protocol allows the owner of a security camera to solve several important functions:

• broadcast data using VLC;
• broadcast video to your resources and platforms;
• configure NVR video recorders;
• connect a video surveillance camera to virtual storage;
• add a video camera to mobile applications based on Android or iOS.

At the same time, opening an RTSP stream for many users of video surveillance systems is not very simple and quite difficult.

Find out the RTSP address of a CCTV camera

There are several options that allow you to find out the RTSP stream of a video camera when it is not indicated in the corresponding instructions.

A large number of IP video cameras that are sold in Russia contain Chinese XMEye elements. These components can be seen even from domestic manufacturers of cameras such as Vesta, HiQ, SVplus and the like. A camera of similar models will have the following RTSP stream format:

rtsp://192.168.132.32:554/user=admin&password=12345&channel=1&stream=0.cgi

This address contains the following components:

• 192.168.132.32 – direct IP address of the device;
• 554 – protocol port (by default it is numbered 554, but this parameter can be changed in the device settings);
• admin – CCTV camera login;
• 12355 – password for the user login.

In the case where the IP video camera contains other components, you will need to use one of the two options listed below.

The first option is the most simplified. To find out the RTSP stream from a CCTV camera, you need to contact the manufacturer or supplier of this device. Upon request, they will be able to provide the format of the required stream, and even Chinese sellers can provide this service - from factories in China or the AliExpress website.

The second option is to use specialized software. This method can help out in cases where the owner of the video surveillance system does not have the ability or desire to request an RTSP stream address from the supplier. Then you can do it yourself using software.

First, you will need to download a program called One Device Manager. After installation, this software will help you find out the RTSP address.

As a rule, most video cameras support the onvif protocol, so there should be no difficulties when using the software. An important nuance - for it to work correctly, you must connect the laptop or computer where the program will be installed, as well as the IP device itself, to the same local network.

You can find entire lists on the Internet that contain the addresses of RTSP streams, since this data depends on which brand of video surveillance camera is produced.

How to open an RTSP stream in a video camera?

When the RTSP stream address becomes known to the owner of the tracking system, he can receive video information from the IP camera. In order to open a streaming video broadcast, you will need to complete the following list of steps:

• set a permanent IP address for the video camera and order it from your Internet provider;
• forward local requests coming from the video camera to the RTSP port;
• pass a performance test.

A static address can be configured using the IP Hunter program, or you can contact your provider and ask them to provide a permanent IP address as an additional option. After this, you need to set up port forwarding and forward ports to the RTSP port from the local ports of the video camera. Then you can proceed to checking the flow.

To understand whether the RTSP link is functional, you can open VLC player and check there. To do this, in the main menu of the player you need to click on the “Media” category and select “Open URL”. Next, you will need to go to the “Network” tab of the “Source” window and specify your link.

The question often arises: How to connect an IP camera to an NVR if it is not on the compatibility list?

There are two options ONVIF and RTSP

Let's start with the ONVIF protocol (Open Network Video Interface Forum)

ONVIF is a generally accepted protocol for the joint operation of IP cameras, NVRs, software, in case all devices are from different manufacturers. ONVIF can be compared to the English language for international communication of people.

Make sure that the connected devices support ONVIF; on some devices ONVIF may be disabled by default.
Or ONVIF authorization may be disabled, which means that the login/password will always be by default
regardless of login/password for WEB

It's also worth noting that some devices useseparate port for operation via ONVIF protocol

In some cases, the ONVIF password may differ from the WEB access password.

What is available when connected via ONVIF?

Device discovery

Video transmission

Reception and transmission of audio data

PTZ camera control

Video analytics (such as motion detection)

These parameters depend on the compatibility of ONVIF protocol versions. In some cases, some parameters are not available or do not work correctly.

K and using ONVIF

In SNR and Dahua recorders, the ONVIF protocol is located on the Remote Device tab, Manufacturer line

Select the channel to which the device will be connected

From the Manufacturer tab, select ONVIF

Specify ip address devices

RTSP port remains default

Cameras use ONVIF port 8080
(since 2017, on new ONVIF models the port has been changed to 80 for the Alpha and Mira series)
OMNY cameras Base use ONVIF port 80, in the registrar it is indicated as an HTTP port

Name

Password according to device parameters

Remote channel default is 1. If the device is multi-channel, the channel number is indicated.

Decoder Buffer— buffering of the video stream indicating the time value

Server typehere there is a choice of TCP,UDP Schedule

TCP- establishes a connection between the sender and the recipient, ensures that all data reaches the recipient without changes and in the required sequence, and also regulates the transmission speed.

Unlike TCP, UDP does not establish a preliminary connection, but instead simply begins transmitting data. UDP does not monitor that data has been received, and does not duplicate it in case of loss or error.

UDP is less reliable than TCP. But on the other hand, it provides faster transmission of streams due to the absence of retransmission of lost packets

Schedule— automatic type detection.

This is what connected devices look like in Dahua

Green status means the recorder and camera are connected successfully

Red status means there are connection problems. For example, the connection port is incorrect.

The second connection method is RTSP(Real Time Streaming Protocol)

RTSPa real-time streaming protocol that describes commands for controlling a video stream.

Using these commands, the video stream is broadcast from the source to the recipient

for example from an IP camera to a DVR or server.

What is available when connecting via RTSP?

Video transmission

Reception and transmission of audio data

AdvantageThis transfer protocol is that it does not require version compatibility.

Today RTSP is supported by almost all IP cameras and NVRs

Flaws The protocol is that apart from the transmission of video and audio data, nothing else is available.

Let's look at an example of connecting a camera to and using RTSP

RTSP located on the Remote Device tab, Manufacturer line, in the SNR and Dahua recorder it is presented asGeneral

Select the channel to which the device will be connected

URL Addr- here we enter the query string for which the camera sends basic RTSP stream with high resolution.

Extra URL - Here enter the query string for which the camera sends additional RTSP stream with low resolution.

Example request:

rtsp://172.16.31.61/1 main stream

rtsp://172.16.31.61/2 additional stream

Why do you need an additional thread?

On a local monitor connected to the multi-picture recorder, the recorder uses an additional thread to save resources. For example, in small pictures with 16 windows, it is not at all necessary to decode Full HD resolution, D1 is enough. Well, if you have opened 1/4/8 windows, in this case the main stream is decoded with high resolution.

Nameaccording to device parameters

Password according to device parameters

Decoder Bufferbuffering of video stream indicating time value

Server type- TCP, UDP, Schedule (similar to ONVIF protocol)

This article answers the most common questions, such as:

Is the IP camera compatible with the NVR?

And if it is compatible, how to connect!?