Rtsp protocol for ip cameras. Broadcasting a video stream from an IP camera using WebRTC

If you are having difficulty setting up or using your product, please see our FAQs and FAQs.

How to get REVISOR VMS gift license?

Follow the instructions to get Revisor VMS gift license. Download instructions.

I have a 1.3 MP RedLine IP camera. I'm trying to install ActiveX, but I get an "HTTP 404 - Not Found" error, what should I do?

ActiveX module is not built-in in 1.3 megapixel video cameras, it must be installed from the disk that comes with the kit or download from the link

For 4MP cameras:

rtsp://admin:123456@IP-address:554/ch01/0 - main thread

rtsp://admin:123456@IP-address:554/ch01/1 - additional stream

rtsp://admin:123456@IP-address:554/streaming/mjpeg - mjpeg stream

For 1.3MP and 2MP cameras

rtsp://admin:123456@IP-address:554/streaming/video0 - main stream

rtsp://admin:123456@IP-address:554/streaming/video1 - additional stream

What software is suitable for mobile devices?

What ports are required to work through the network?

80 - web interface

554-rtsp (video) stream

4900 - mob. port

9988 - For client connections to 4MP IP cameras

What should I do if the sound does not work on the recorder or in third-party software?

To transmit sound, you need to activate audio transmission in the settings in the NETWORK tab - RTSP stream.

The amount of space occupied depends on the selected recording quality and the frequency of motion (when recording by detection). To calculate the archive, you can use the Disk calculator software.

How to find an IP camera on a local network?

Install the software and run as administrator. In the window that appears, you will see a list of equipment connected to the local network.

To change the network settings, select the equipment in the upper field and specify the network settings (IP address, mask, gateway) in the lower field, enter the username, password, and click the Modify button. In the future, you must use the specified IP to connect.

.

For 1.3MP and 2MP IP cameras recommended to use

How to add 1.3 MP IP camera to CVMS?

If the camera is in the local network, then in the view mode, in the Devices menu (on the left), right-click and select "Quick search", then select the desired camera and specify the password.

If the connection will be made via the Internet, then in the view mode, in the Devices menu (on the left), right-click and select "Add device" and enter data for connection, MUST SPECIFY TCP PORT (default 1115)

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 required 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 camcorder to the cloud server;
• to set up the transmission of video information to the website;
• to play video in the player stream on different devices - mobile phone, laptop or tablet.

What is the RTSP protocol for?

The name of the RTSP protocol translates to online control. 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 with virtual storage;
• add a video camera to mobile applications based on Android or iOS.

At the same time, it is not very easy and rather difficult for many users of video surveillance systems to open an RTSP stream.

Find out the RTSP address of a surveillance camera

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

A large number of IP cameras sold in Russia include Chinese XMEye elements. These components can be seen even in domestic manufacturers of cameras such as Vesta, HiQ, SVplus and the like. The camera of such 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 such components as:

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

In the event that other components are present in the IP video camera, 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 surveillance camera, you need to contact the manufacturer or supplier of this device. Upon request, they will be able to provide the format of the desired 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 when a non-owner of the video surveillance system does not have the ability or desire to request the address of the RTSP stream from the provider. Then you can do it yourself with the help of 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 not be any difficulties when using the software. An important nuance - for proper operation, you must connect a laptop or computer where the program will be installed, as well as the IP device itself, to the same local network.

On the web, you can find entire lists containing the addresses of RTSP streams, since this data depends on which brand produces the video surveillance camera.

How to open an RTSP stream in a camcorder?

When the address of the RTSP stream 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 perform the following list of steps:

• set a permanent IP address for the camcorder and order it from an Internet provider;
• transfer 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 ISP and ask them to provide a permanent IP address as an additional option. After that, you need to set up forwarding and forward ports to the RTSP port from the local ports of the video camera. Then you can move on to checking the flow.

To understand if the RTSP link is working, you can open the VLC player and check it there. To do this, in the main menu of the player, you need to click on the "Media" category and select the "Open URL" item. Next, you need to go to the "Network" tab of the "Source" window and specify your link.

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 a router in order 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, there will be an increasing shortage of channel thickness first, 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 pictures are transmitted via HTTP. HTTP streaming is notoriously not well-suited for real-time video streaming, although it works well in on-demand video where stream interactivity and latency are not particularly important. In fact, if you're watching a movie, delaying the video by a few seconds won't make it worse, unless you're watching the movie at the same time as someone else. "Oh no! Jack killed her! - Alice writes a spoiler in chat to Bob 10 seconds before the tragic denouement.

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 pick up and play the video, just like the player itself. But we really need a real browser-based streaming without installing additional crutches / plugins.

First, let's sniff the IP camera to find out what exactly this device sends towards the browser. As a test subject there will be a D-Link DCS 7010L camera:

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

The picture opens in all browsers and evenly podlagivaet, 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 it is not. Similar to HTTP. Run 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 streaming. Not smooth, pulls HTTP requests. How many such requests per second can the camera withstand? There is reason to believe that at 10 spectators and earlier the camera will safely be bent or it will start to glitch terribly and give out slides.

If we look into the HTML of the camera admin page, we will see the following 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+=""; //alert(o); DW(o); )

RTSP/RTP is just what you need for proper video playback. But will it work in a browser? - No. But if you install the QuickTime plugin - everything will work. But we are doing purely browser-based streaming.

Flash Player can also be mentioned here, which can receive an RTMP stream converted from RTSP, RTP, H.264 through a suitable server like Wowza. But Flash Player, as you know, is also a browser plug-in, 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 playback device without any additional browser plugins and 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 WebRTC-enabled browsers.

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 it that our server will take the video stream from the camera.

We connect the camera to the router with 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 - this is 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 broadcasting properly in the admin panel. At the same time, periodic jamming is noticeable. This is what we will fix using WebRTC.

Camera setup

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

In the same place, we 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 set 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 operation of the camera via RTSP. Open VLC Player (you can use any other one that supports RTSP - QuickTime, Windows Media Player, RealPlayer, etc.) and in the Open URL dialog set the camera's RTSP address: rtsp://192.168.1.34/live1.sdp

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

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

Server installation

So, the camera is installed, tested with desktop players and ready to broadcast via 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 on port 554, incoming requests are transmitted to the IP camera.

We hammer the appropriate settings into the router ...

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

Telnet 178.51.142.223 554

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

Yes, yes, there are also Linode and DigitalOcean, but in this case I wanted to 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:

With DigitalOcean, by the way, everything will be easier, just open these ports on the firewall or muffle 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.

We will use Flashphoner's WebRTC Media & Broadcasting Server as a server software that relays an RTSP/RTP stream to WebRTC. The streaming server is very similar to Wowza, which can stream RTSP/RTP to Flash. The only difference is that this stream will be given to WebRTC, not Flash. Those. an 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.

We need SSH access to install.

Under the spoiler - a detailed description of the executed commands

1. Download the installation archive of the server:
$wget flashphoner.com/downloads/builds/WCS/3.0/x8664/wcs3_video_vp8/FlashphonerMediaServerWebRTC-3.0/FlashphonerMediaServerWebRTC-3.0.868.tar.gz
2. Deployed:
$tar -xzf FlashphonerMediaServerWebRTC-3.0.868.tar.gz
3. Installed:
$cd FlashphonerMediaServerWebRTC-3.0.868
$./install.sh
During the installation process, the external IP address of the server was entered: 54.186.112.111 and internal 172.31.20.65 (the one that is Private IP).
4. Started the server:
$service webcallserver start
5. Checked the logs:
$tail - f /usr/local/FlashphonerWebCallServer/logs/server_logs/flashphoner.log
6. We made 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. Enter the server IP address in 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

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

We have already installed the main elements of this diagram, it remains to establish the "arrows" of interactions.

The connection between the browser and the WebRTC server is provided by a 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 paragraph 9 above under the spoiler).

The interaction between the browser and the server is configured in the configuration XML file flashphoner.xml. You need to enter the IP address of the server there 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:

We open the index.html web client page 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 refers to our external IP address. We told the router to redirect RTSP requests to 192.168.1.34 according to NAT rules (see also 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. Maybe your router supports DDNS. If not, then the IP camera itself has such support:

And this is how DDNS support looks 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 a video stream. The whole process takes a few seconds.

At this time, the browser connects to 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 is ultimately played by 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 are convinced that this is really WebRTC.

Suddenly, we were deceived, and the video from the IP camera is again sent via HTTP? Let's not idly look at the picture, but check what kind of traffic we actually get. Of course, we start Wireshark again and the debug console in Chrome. In the browser's Chrome console, we can observe the following:

This time there is no flickering and no HTTP images are visible. 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.

And 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. 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. In the picture below, packets of 1468 bytes. This is WebRTC. More precisely, SRTP packets carry VP8 video frames, which we can observe on the browser screen. In addition, STUN requests are skipping (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) of video playback. WebRTC works over SRTP/UDP, which is the fastest way to deliver packets, unlike HTTP, RTMP, and other TCP-like streaming methods. Those. latency as seen by the eye should be RTT + browser buffering, decoding and playback time. 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 was able to open 10 Chrome windows, and each of them showed a picture. At the same time, Chrome itself began to blunt a little. 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 if our broadcast will be displayed there:

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

Conclusion

As a result, we managed to launch a WebRTC live broadcast from an IP camera to several browsers with minimal effort. No tambourines or rocket-science were 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.

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

Why don't 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 to introduce the H.264 codec into WebRTC. There is 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, 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 that will not require transcoding and stream conversion, and most browsers will be able to play streams from various devices directly.