Why the growth of quality causes the growth of poor quality, or whether the main function

It is foolish to argue with the fact that analog video surveillance is a thing of the past: cheap IP cameras give a picture of comparable quality with expensive analog. In addition, IP cameras are not limited on top by anything other than recorder performance, while analog cameras require strict matching of the receiving card, matching the signal levels of transmitters / amplifiers / receivers and other shamanism.
Constructing a system based on IP cameras at any time, you can remove the camera and replace it with a better one - if you save the IP address and login password, you probably don’t even have to change the receiver settings - just a better picture will go to the archive.
On the other hand, it imposes restrictions on the registrar - it must be ready to work with any resolution, any bit rate, any codec and any protocol ... Well, or at least, work correctly with the stated one.

In the world of software, there are two ways - there is a linux-way: this is a set of small programs, each of which does one function, but very well; and there is a windows-way: these are huge food processors that can do everything, and a bit more. The main problem of the linux-way is the lack of an interface. To get all the benefits you have to smoke mana (or at least read - help), and experiment. As well as to figure out what to combine with and how. The main problem of windows-way is the loss of the main function. Very quickly, when fouling dopfunktsionalom tests of key functionality are lost, and over time, problems even begin with him. Moreover, the inertia of thinking begins: “this is the main function, it is tested most of all, there cannot be a bug, the user is doing something wrong”.

Now we turn to our sheep: now there is a constant increase in the quality of IP cameras. Anyone who has seen the difference of FullHD camera installed in the same place where even the ultra-tough 700TVL was standing before will no longer want to go back (especially since for the price now it’s about the same). Further development leads to the fact that cameras 3MP (2048x1536) and 5MP (2592x1944) are no longer a rarity. The only price for higher quality is rising storage and transfer costs. However, the price of a gigabyte on a hard drive has long been falling (and has fully recovered from the flood at the plant), and therefore is not a problem.

Literally today there was a small dispute with maxlapshin on whether the software manufacturer owes something to the user, after the sale, or not. Yes, any software is sold "as is" without any promises. Therefore, even paying whatever it may be, you are not the fact that you will receive even working software. That's only if the software does not work, and it is known - the flow of customers will dry up at one point. Although they are still buying, the obviousness of correcting errors (and even more so, the implementation of features) is a big question.
')
We will finish the introduction, and we will see a small, but very illustrative video (you can not even watch it - you can see everything on a still frame):


This is a textbook glitch that I see on almost all software intended for video recording. I saw it on VideoNet, I see it regularly on Axxon Next, as you see on the video - Trassir greeted me. The same canoe even in the native camera viewer. It would be possible to write off all the problems on the camera. You can write off the network. It is possible for a high load on the CPU. It is possible for electromagnetic interference. You can recommend to check the memory. You can reinstall the system. In general, methods instead of proceedings forcing a person to bring a toilet ...
That's just connecting to the same rtsp stream via vlc no artifacts and failures - no. On the same computer, I run a kneeled test script that reads the stream from the camera and writes to the disk - and there are no losses and no problems, and therefore only one method works - to reduce the camera resolution and lower the bitrate.

That is, despite the flexibility, the declared support of the heaps of cameras, the work on ONVIF and RTSP ... Anyway, you can not get any benefits from IP surveillance, since the receiving software was not ready for this.

The main reason for this behavior, oddly enough, is the IP network, codecs, and ... sewage .

So, for a start, a brief basic theory on the IP network. In the network, everything runs in the form of bags. Each packet has a maximum size (MTU, 1500 on regular links), the sender and the receiver. The bag is somehow sent there along the way and as a result has to reach the recipient. May not reach. May cut. A piece may come ... In general, options are possible. From these sachets, the transport protocols are wound on top: UDP and TCP (of those of interest to us). Nothing changes on UDP, only the port of the sender and the port of the receiver appear, so that packets can be divided between each other; and a bunch of logic wraps around TCP, which “guarantees delivery”. More precisely, it guarantees delivery or error generation if something cannot be delivered. Well, as guarantees ... promises (promise - does not mean to marry;) Any admin repeatedly saw "hung" connections, on the same mobile Internet, for example).

How does TCP guarantee delivery? And simply - each package should receive a confirmation. There is no confirmation for some time - the packet is lost - we will forward it. But if for each packet to wait for confirmation - the speed will drop monstrously, and the more, the higher the delay between the communicating points. Therefore, the concept of a “window” is introduced - we can send a maximum of N packets without confirmation, and only then wait for confirmation. But waiting for N confirmations is also a lot - the receiver will also receive and send confirmations not for everyone, but simply “maximum visible”. Then less evidence. And confirmation can be sent with the package sent, so as not to get up two times. In general, the logic of the sea, all aimed at fulfilling the promise of delivery, but with the maximum utilization of the channel. The window size is a variable value, and is selected by the system based on voodoo magic, settings, and weather on Mars. Plus, it changes in the process of work flow. This moment we touch a little later.

So, now let's get to our sheep - H264 over RTSP. (Actually, it is practically unimportant - what a codec and what a transport protocol. Do not think that if you use any of your ingenious protocol, which is many times simpler than RTSP, that this does not concern you). A stream consists of a periodically repeating keyframe, and a stream of changes relative to the current state. Connecting to the video, you need to wait for the keyframe, after which we take it for the current state, and then we take the diffs, which we impose and show. What does it mean? This means that every X seconds there is a lot of data coming in - a full frame. And the more, the higher the resolution of the camera and the higher the bit rate (although, to be honest, the bit rate has little effect on the size of the keyframe). So, here we have time point 0 - the beginning of the keyframe, at which the full frame arrives right away (let's say the camera has all 3 megapixels - it is 2048x1536 = 3145728 pixels. After compression, it is a measly ~ 360 kilobytes). We have a total of 8 megabytes = 1 megabyte, keyframe every 5 seconds, and FPS = 18. Then we will have something like 360k, then 52k every 1/18 seconds, after 5 seconds, again 360k, then again 52k.

Now back to UDP and TCP. A bag that arrives on the network card is added to the network card's buffer, and the processor is flagged (or an interrupt is triggered) that there is data. The processor suspends the execution of everything useful, pulls a packet out of the card, and starts lifting and stripping it over the TCP / IP stack. This process is carried out at the highest priority (for work with iron). But we still have Windows or Linux, or neither is RTOS, so there are no guarantees when the application will be able to get to this package. And therefore, as soon as the system has figured out what the packet is, to which connection it belongs, the packet tries to fit the buffer.
On UDP: if there is no space in the buffer, the packet is discarded.
On TCP: if there is no space in the buffer, the flow control algorithm is turned on - an overflow signal is sent to the sender, saying shut up until I get a little free here. As soon as the application takes part of the data from the buffer, the system sends “OK, drove on” to the sender, communication resumes.

Now let's add everything, and write down how the data from the camera is received. To begin with - a simple case on UDP. The camera reads the next frame, sticks it into the compressor, extracts the compressed data from the compressor, cuts it onto packets, adds headers and sends it to the receiver. The recipient first receives 260 UDP packets, then a pause, another 40 packets, a pause, another 40 packets, and so on. The first 260 UDP packets arrive instantly — in about 30 milliseconds; and already at the 55th millisecond the next 40 (for another 4 milliseconds) arrive. Suppose we have a buffer of 128 kilobytes. Then, they will score in 10 milliseconds. And if during this time the application does not empty the buffer in a single reading all impulse (but in fact read one packet at a time ...), we will lose the rest of the key frame. Given that we do not have RTOS, and the application can forcibly “fall asleep” for any of the reasons (for example, while the OS flushes the buffer to the disk) for the same second, the only way not to lose anything is to have a network buffer larger than we can sleep. That is, ideally, the OS buffer should be set to ~ 2 seconds of flow, in this case, 2 megabytes. Otherwise losses are guaranteed.

OK, but we have TCP! Which guarantees delivery, and asks to wait for the sender if that! Let's switch to TCP, and look at the same picture. An additional overhead projector can be neglected, just let's see what happens. So, we have 360 ​​kilobytes of data. They are sent on a 100 Mbps channel for about 30 milliseconds. Somewhere on the 10th millisecond, the receiver buffer overflowed, and the camera was asked to shut up. Suppose, after another 20ms, the application read the entire available buffer (and in fact, read 4 bytes, then 1400, then 4 more, 1,400 more ...), and the OS asked the camera to continue. the camera sent another third of the keyframe and shut up again. After another 20ms went further - but the camera produced more data that went to the buffer of the camera itself. And here we come to a slippery moment - and what is the size of the TCP buffer in the camera? In addition, because of the constant “shut up” - “keep on” the effective network bandwidth drops dramatically - instead of 100 Mbps, we have 128kbytes at 30ms = 32 megabytes maximum. In Windows Server, the default quantum is a fixed 120ms . At 120ms we have a maximum speed of 8.5mbits. That is, on a server OS using a 128kbyte buffer, it will be not only difficult to receive a 8-bit stream, but rather complicated. On the desktop OS is easier, but still the problems will be with any sneeze. If the buffer is larger, it gets better, but anyway, for any instability in reading, problems begin, which in the simplest case lead to jerky movements, in some cases, to a flow failure or a bug similar to this, if the TCP buffer overflows inside the camera.

From where you can make only one conclusion - the buffer should ideally be with a margin of about 2 seconds of stream, in this case 2 megabytes. Otherwise, problems are likely.

Maybe I'm wrong, but if the application whose task it is to receive and save the stream from the cameras cannot do this is a bug. And this bug should be repaired, and not offered to reduce the problem to an already solved, reducing the quality to an analog camera. Dixi.