We stream the video stream from the IP camera using WebRTC

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 in order to distribute video content. So why use WebRTC?

image



There are at least two reasons for this:

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

2. As mentioned above, the IP camera is a server. But by what protocols will she be able to give the video to the desktop browser? Mobile device? Most likely it 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 streaming video, although it has proven itself in on-Demand video, where stream interactivity and delay are not particularly important. In fact, if you watch a movie, a delay of a few seconds will not make it worse, unless you watch this movie at the same time as someone else. "Oh no! Jack killed her! - Alice writes in a chat to Bob spoiler 10 seconds before the tragic outcome. ”

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

First, sniff the IP camera to find out what exactly sends this device to the browser. The D-Link DCS 7010L camera will be an experimental one:

image

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

image

The image opens in all browsers and evenly falters, about once per second. Considering that both the camera and the laptop on which we watch the stream are connected to one router, everything should be smooth and beautiful, but this is not so. It looks like HTTP. We launch Wireshark to confirm our guesses:

image

Here we see a sequence of TCP fragments 1514 bytes long

image

and the final HTTP 200 OK with the received JPEG length:

image

Next, go to Chrome / Developer Tools / Network and see in real time how GET flickers. Requests and pictures transmitted via HTTP:

image

We do not need such streaming. Not smooth, pulling HTTP requests. How many such requests per second will the camera withstand? There is reason to believe that at 10 viewers and earlier, the camera will safely bend or start to terribly glitch and give out slides.

If you look into the HTML pages of the camera admin panel, we’ll see such an 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 not support rtsp.
		var host = g_netip;
	else
		var host = g_host;
  o+='';
  o+='';
  o+='';
  o+='';
  o+='';
  //alert(o);
  DW(o);
}


RTSP / RTP is just what you need for proper video playback. But will this work in the browser? - Not. But if you install the QuickTime plugin, everything will work. But we are doing pure browser-based streaming.

Here you can also mention Flash Player, which can receive an RTMP stream converted from RTSP, RTP, H.264 through a suitable Wowza-type server. 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 without any additional browser plug-ins and other crutches will be used as a losing device. We will set up a relay server that will pick up the stream from the IP camera and send it to the Internet to an arbitrary number of users using WebRTC-enabled browsers.

IP camera connection


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, because it is through it that our server will pick up the video stream from the camera.

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

We open the specified IP address in the browser 192.168.1.34 to get into the web interface of the camera administrator. There is no password by default.

image

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

Camera setup


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

There we check the value of the RTSP protocol port, by default it is 554. The format of the video being sent 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. If necessary, you can change the settings in the Setup - Audio and Video section .

image

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

image

Well, everything works, how and should. The camera regularly plays the video stream in the player through the RTSP protocol.

image

By the way, the stream plays quite smoothly and without artifacts. We are waiting for the same from WebRTC.

Server installation


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

We hammer the appropriate settings into the router ...

image

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

telnet 178.51.142.223 554

After making sure that the answer is 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 .
In order not to have performance problems, we chose the m3.medium instance with one VCPU:

image

Yes, yes, there is also Linode and DigitalOcean, but in this case I wanted to amaze.
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 rules should have something similar for incoming traffic:

image

With DigitalOcean, by the way, everything will be simpler, just open these ports on the firewall or drown out the latter. According to the latest experience in operating DO instances, they still give out a static IP address and do not bother with NATs, which means that port forwarding, as in the case of Amazon, is not needed.

As the server software relaying the RTSP / RTP stream to WebRTC, we will use WebRTC Media & Broadcasting Server fromFlashphoner . The streaming server is very similar to Wowza , which can send RTSP / RTP stream to Flash. The only difference is that this stream will be sent to WebRTC, not to Flash. Those. honest DTLS will take place between the browser and the server, the SRTP session will be established and the stream encoded in VP8 will go to the viewer.

For installation, we need SSH access.

Under the spoiler - a detailed description of the executed commands
1. Download the server’s installation archive:
$ wget flashphoner.com/downloads/builds/WCS/3.0/x8664/wcs3_video_vp8/FlashphonerMediaServerWebRTC-3.0/FlashphonerMediaServerWebRTC-3.0.868.tar.gz
2. Deployed
Flash_Teron.erxerxeron 3.0 tarxer terfer 3. 868.tar.gz
3. Installed:
$ cd FlashphonerMediaServerWebRTC-3.0.868
$. / Install.sh
During the installation, they entered the external IP address of the server: 54.186.112.111 and the internal 172.31.20.65 (the one that has Private IP).
4. Started the server:
$ service webcallserver start
5. Checked the logs:
$ tail - f /usr/local/FlashphonerWebCallServer/logs/server_logs/flashphoner.log
6. Check that the server has started and is ready to work:
$ ps aux | grep Flashphoner
7. Install and run apache:
$ yum install httpd
$ service httpd start
8. Download the web files and place 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. Enter the IP address of the server in the flashphoner.xml config:
10. Stop 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, they decided to simply disable the firewall.

Server Tuning


Recall that the structure of our WebRTC broadcast is as follows:

image

We have already set up the basic elements of this diagram, it remains to establish the “arrows” of interactions.

The connection between the browser and the WebRTC server is provided by the web client, which is on the github :. A set of JS, CSS and HTML files is simply thrown into / var / www / html at the installation stage (see paragraph 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 IP address of the server so that the web client can connect to the WebRTC server using HTML5 Websockets (item 9 above).

Server setup ends here, you can check its operation:

We open the index.html web client page in a browser (for this, Apache was installed on the same Amazon server using the yum -y install httpd command ): Here webrtc-ipcam.ddns.net is a free domain obtained through the dynamic DNS server noip.com which refers to our external IP address. We told the router to redirect RTSP requests to 192.168.1.34 in accordance with the rules for translating network NAT addresses (also see above). The id = rtsp: //webrtc-ipcam.ddns.net/live1.sdp parameter specifies the URL of the stream to play. The WebRTC server will request streams from the camera, process them, and give it to the browser for playback via WebRTC. Perhaps your router supports DDNS. If not, then the IP camera itself has such support:

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




image

And so, DDNS support looks in the router itself:

image

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.

image

At this time, the browser connects to the server via web sockets, then the server requests an IP camera via RTSP, receives an H.264 stream via RTP and transcodes it to VP8 / SRTP - which ultimately plays back the WebRTC browser.

image

Further, after a short wait, an already familiar picture is displayed.

image

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

We make sure that this is really WebRTC.


Suddenly we were deceived, and the video from the IP camera again goes over HTTP? We will not idly see the picture, but we will check what kind of traffic we actually get. Of course, run Wireshark and the debug console in Chrome again. In the Chrome console of the browser, we can observe the following:

image

This time nothing flickers and no pictures transmitted over HTTP are visible. All that we see this time is Websocket frames and most of them are ping / pong types to support a Websocket session. Interesting frames: connect, prepareRtspSession and onReadyToPlay - this is how the connection to the server is established: first, connect via Websocket, and then request the stream to play.

And here is what chrome: // webrtc-internals shows

image

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

Now let's look at Wireshark, UDP traffic from the server IP address is clearly visible there. The picture below shows 1468 byte packets. This is WebRTC. More precisely, SRTP packets carrying VP8 video frames that we can watch on the browser screen. In addition, STUN requests (the lowest packet in the picture) skip - this WebRTC ICE carefully checks the connection.

image

It is also worth noting the relatively small delay (ping to the data center was about 250 ms) of video playback. WebRTC works on SRTP / UDP, which is the fastest way to deliver packets, whatever the HTTP, RTMP and other TCP-like streaming methods. Those. the delay seen by the eye should be RTT + the time of buffering, decoding and playback by the browser. Visually in this case it is - 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 dull a little. When you open the 11th window on another computer, playback remained smooth.

About WebRTC on mobile devices


As you know, WebRTC supports Chrome and Firefox browsers on the Android platform.
We’ll check whether our broadcast will be displayed there:

image

The picture on the HTC phone, in the Firefox browser, video from the camera is displayed. There are no differences in the smoothness of playback from the desktop.

Conclusion


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

Broadcast quality was acceptable, and playback lag was invisible to the eye.

Summing up, 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 a browser.

Why do not we see the widespread adoption of WebRTC?


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

In second place, not full support in browsers. C 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 win streams from various devices directly.

Also popular now: