Warum führt eine Qualitätssteigerung zu einer Qualitätsverschlechterung oder sollte die Hauptfunktion funktionieren?

    Analoges VideoEs ist töricht zu behaupten, dass die analoge Videoüberwachung der Vergangenheit angehört: Billige IP-Kameras liefern ein Bild von vergleichbarer Qualität wie teure analoge. Darüber hinaus sind IP-Kameras nur durch die Leistung des Rekorders von oben beschränkt, während analoge Kameras eine genaue Anpassung der Empfangskarte, der Signalpegel von Sendern / Verstärkern / Empfängern und anderer Schamanen erfordern.
    Wenn Sie ein auf IP-Kameras basierendes System aufbauen, können Sie die Kamera jederzeit entfernen und durch eine bessere ersetzen. Wenn Sie die IP-Adresse und das Anmeldekennwort speichern, müssen Sie höchstwahrscheinlich nicht einmal die Empfängereinstellungen ändern. Nur ein besseres Bild wird in das Archiv verschoben.
    Auf der anderen Seite bedeutet dies Einschränkungen für den Registrar - er muss bereit sein, mit jeder Auflösung, jeder Bitrate, jedem Codec und jedem Protokoll zu arbeiten ... Nun, oder zumindest korrekt mit dem deklarierten Protokoll.

    ShivaIn der Welt der Software gibt es zwei Möglichkeiten - es gibt eine Linux-Möglichkeit: Es handelt sich um eine Reihe kleiner Programme, von denen jedes eine Funktion ausführt, aber sehr gut ist. und es gibt einen Fensterweg: Dies sind riesige Küchenmaschinen, die alles können und ein bisschen mehr. Das Hauptproblem unter Linux ist das Fehlen einer Schnittstelle. Um alle Vorteile zu nutzen, müssen Sie Mana rauchen (oder zumindest --help lesen) und experimentieren. Und auch herausfinden, was und womit Sie kombinieren können und wie. Das Hauptproblem bei Windows ist der Verlust der Hauptfunktion. Wenn zusätzliche Funktionen verschmutzt werden, gehen die Tests der Schlüsselfunktionen sehr schnell verloren, und mit der Zeit beginnen sogar Probleme damit. Gleichzeitig beginnt die Trägheit des Denkens: "Dies ist die Hauptfunktion, sie wird am meisten getestet, es kann keinen Fehler geben, der Benutzer macht etwas falsch."

    Jetzt wenden wir uns unseren Schafen zu: Jetzt nimmt die Qualität der IP-Kameras stetig zu. Wer den Unterschied zwischen einer FullHD-Kamera gesehen hat, die an der gleichen Stelle installiert war, an der zuvor sogar die ultracoole 700TVL gestanden hatte, wird nicht mehr zurückkehren wollen (zumal der Preis jetzt in etwa gleich ist). Die Weiterentwicklung führt dazu, dass 3MP (2048x1536) und 5MP (2592x1944) Kameras keine Seltenheit mehr sind. Der einzige Preis für eine höhere Qualität sind die steigenden Kosten für Lagerung und Transport. Der Preis für ein Gigabyte auf der Festplatte ist jedoch seit langem gesunken (und hat sich im Werk vollständig von der Flut erholt) und ist daher kein Problem.

    Gerade heute gab es einen kleinen Streit mit maxlapshinzum Thema, ob der Softwarehersteller nach dem Verkauf etwas für den Anwender haben soll oder nicht. Ja, jede Software wird "wie sie ist" ohne Versprechen verkauft. Selbst wenn Sie bezahlt haben, was immer es ist, ist es keine Tatsache, dass Sie überhaupt eine funktionierende Software erhalten. Das ist nur möglich, wenn die Software nicht funktioniert und dies bekannt ist - der Kundenstrom wird an einem Punkt versiegen. Obwohl sie noch kaufen, ist der Nachweis der Fehlerkorrektur (und vor allem die Implementierung von Funktionen) eine große Frage.

    Wir beenden die Einführung und sehen uns ein kleines, aber sehr aufschlussreiches Video an (Sie müssen es nicht einmal ansehen - alles ist auf dem Standbild sichtbar):


    Dies ist ein Fehler im Lehrbuch, den ich bei fast jeder Software beobachte, die für Videoaufnahmen entwickelt wurde. Ich habe es auf VideoNet gesehen, ich sehe es regelmäßig auf Axxon Next, wie Sie im Video sehen - Trassir begrüßte mich damit. Das gleiche Kanu auch im nativen Kamera-Viewer. Du könntest alle Probleme vor der Kamera abschreiben. Kann dem Netzwerk zugeordnet werden. Es ist möglich, dass die CPU stark belastet wird. Es können elektromagnetische Störungen auftreten. Es kann ratsam sein, den Speicher zu überprüfen. Sie können das System neu installieren. Im Allgemeinen, anstatt einer Probe, Wege, um eine Person zu veranlassen , eine Toilette zu bringen ...
    Hier werden nur über VLC keine Artefakte und Fehler mit dem gleichen RTSP-Stream verbunden - nein. Auf demselben Computer führe ich ein heißes Testskript aus, das einen Stream von der Kamera liest und auf die Festplatte schreibt. Es gibt keine Verluste und Probleme, und daher funktioniert nur eine Methode. Verringern Sie die Auflösung der Kamera und die Bitrate.

    Dies ist trotz der Flexibilität eine erklärte Unterstützung für eine Reihe von Kameras, die an ONVIF und RTSP arbeiten ... Auf jeden Fall können Sie keine Vorteile aus der IP-Überwachung ziehen, da die empfangende Software dafür nicht bereit war.

    Der Hauptgrund für dieses Verhalten ist seltsamerweise das IP-Netzwerk, Codecs und ... Abwasser .

    Zunächst eine kurze Grundtheorie zu IP-Netzwerken. Alles läuft im Netz in Form von Taschen. Jedes Paket hat eine maximale Größe (MTU, 1500 bei regulären Verbindungen), Sender und Empfänger. Auf dem Weg dorthin wird irgendwie ein Paket verschickt, das den Empfänger erreichen sollte. Kann nicht dort ankommen. Kann dich schneiden. Ein Stück kann kommen ... Im Allgemeinen sind Optionen möglich. Von diesen Paketen werden Transportprotokolle überlagert: UDP und TCP (von denen, an denen wir interessiert sind). Bei UDP ändert sich nichts, nur der Port des Absenders und der Port des Empfängers werden angezeigt, sodass die Pakete untereinander aufgeteilt werden können. und ein Haufen Logik ist auf TCP eingepackt, was "Zustellung garantiert". Genauer gesagt, es garantiert die Zustellung oder Fehlererzeugung, wenn etwas nicht zugestellt werden kann. Nun, als Garantie ... verspricht es (zu versprechen - bedeutet nicht zu heiraten;) Jeder Admin hat wiederholt "hängende" Verbindungen gesehen,

    Wie garantiert TCP die Zustellung? Aber einfach - jedes Paket sollte eine Bestätigung erhalten. Es gibt für einige Zeit keine Bestätigung - das Paket ist verloren - wir werden es erneut senden. Wenn Sie jedoch auf die Bestätigung jedes Pakets warten, sinkt die Geschwindigkeit enorm und je höher die Verzögerung zwischen den Kommunikationspunkten ist. Daher wird das Konzept des "Fensters" eingeführt - wir können maximal N Pakete ohne Bestätigung senden und erst dann auf die Bestätigung warten. Aber auf N Bestätigungen zu warten ist auch eine Menge - der Empfänger akzeptiert und sendet auch Bestätigungen nicht für jedermann, sondern einfach "maximal gesehen". Dann gibt es weniger Beweise. Sie können auch eine Bestätigung zusammen mit dem gesendeten Paket senden, damit Sie nicht zweimal aufstehen. Im Allgemeinen - die Logik des Meeres, alle darauf ausgerichtet, das Versprechen der Lieferung zu erfüllen, aber gleichzeitig die Nutzung des Kanals zu maximieren. Fenstergröße - variable Größe, und wird vom System basierend auf Voodoo-Magie, Einstellungen und Wetter auf dem Mars ausgewählt. Außerdem ändert es sich während des Arbeitsablaufs. Wir werden später darauf zurückkommen.

    Kommen wir nun zu unseren Schafen - H264 auf RTSP. (Tatsächlich ist es praktisch unwichtig - welche Art von Codec und welches Transportprotokoll. Denken Sie nicht, dass es Sie nicht betrifft, wenn Sie eines Ihrer ausgeklügelten Protokolle verwenden, das um ein Vielfaches einfacher als RTSP ist.) Ein Stream besteht aus einem sich periodisch wiederholenden Keyframe und einer Reihe von Änderungen in Bezug auf den aktuellen Status. Wenn Sie eine Verbindung zum Video herstellen, müssen Sie auf das Schlüsselbild warten. Anschließend wird der aktuelle Status ermittelt. Anschließend werden die überlagerten und angezeigten Unterschiede akzeptiert. Was bedeutet das? Dies bedeutet, dass alle X Sekunden VIELE Daten eintreffen - ein Vollbild. Und je höher die Auflösung der Kamera und je höher die Bitrate (obwohl Bitrate, um ehrlich zu sein, wenig Einfluss auf die Größe des Keyframes hat). Hier haben wir also die Zeit 0 - den Beginn des Keyframes. bei dem der Vollbildmodus sofort eintritt (wir haben zum Beispiel eine Kamera mit allen 3 Megapixeln - es sind 2048 x 1536 = 3145728 Pixel. Nach der Komprimierung sind dies pathetische ~ 360 Kilobyte). Insgesamt haben wir einen Stream von 8 Megabits = 1 Megabyte, alle 5 Sekunden einen Keyframe und FPS = 18. Dann haben wir so etwas wie 360k, dann 52k alle 1/18 Sekunde, nach 5 Sekunden wieder 360k, dann wieder 52k.

    Nun zurück zu UDP und TCP. Ein Paket, das auf einer Netzwerkkarte ankommt, wird zum Netzwerkkartenpuffer hinzugefügt, und ein Flag wird gesetzt (oder ein Interrupt wird aufgerufen), dass Daten vorhanden sind. Der Prozessor unterbricht die Ausführung aller nützlichen Vorgänge, nimmt das Paket von der Karte und beginnt, es auf dem TCP / IP-Stack anzuheben und auszuziehen. Dieser Vorgang wird mit höchster Priorität durchgeführt (für Arbeiten mit Eisen). Wir haben aber immer noch Windows oder Linux, von denen keines RTOS ist. Es gibt also keine Garantie, wann genau die Anwendung in der Lage sein wird, auf dieses Paket zuzugreifen. Sobald das System herausgefunden hat, um welche Art von Paket es sich handelt, zu welcher Verbindung es gehört, versucht das Paket, in den Puffer zu passen.
    Bei UDP: Wenn im Puffer kein Speicherplatz vorhanden ist, wird das Paket verworfen.
    Bei TCP: Wenn im Puffer kein Speicherplatz vorhanden ist, wird der Flusssteuerungsalgorithmus aktiviert. Es wird ein Überlaufsignal an den Absender gesendet. Der Sender sagt "Shut Up", bis ich ein bisschen frei bin. Sobald die Anwendung einen Teil der Daten aus dem Zwischenspeicher entnimmt, sendet das System einen Absender mit der Aufforderung "OK, weitergefahren", die Kommunikation wird fortgesetzt.

    Jetzt fassen wir alles zusammen und schreiben auf, wie die Daten von der Kamera empfangen werden. Zunächst einmal - ein einfacher Fall, bei UDP. Die Kamera liest das nächste Bild, legt es in den Kompressor ein, extrahiert die komprimierten Daten aus dem Kompressor, schneidet sie in Pakete, fügt Header hinzu und sendet sie an den Empfänger. Der Empfänger empfängt zuerst 260 UDP-Pakete, dann eine Pause, weitere 40 Pakete, eine Pause, weitere 40 Pakete usw. Die ersten 260 UDP-Pakete kommen sofort an - in ungefähr 30 Millisekunden. und schon bei der 55. Millisekunde treffen die nächsten 40 ein (für weitere 4 Millisekunden). Angenommen, wir haben einen Puffer von 128 Kilobyte. Dann verstopfen sie in 10 Millisekunden. Und wenn während dieser Zeit die Anwendung den Puffer nicht in einem einzigen Impuls leert, der alles liest (sondern tatsächlich jeweils ein Paket liest ...), verlieren wir den Rest des Schlüsselrahmens. Da wir kein RTOS haben, und die Anwendung kann aus irgendeinem Grund gewaltsam "einschlafen" (z. B. während das Betriebssystem Puffer auf die Festplatte leert). Die einzige Möglichkeit, nichts zu verlieren, besteht darin, einen Netzwerkpuffer zu haben, der größer ist, als wir schlafen können. Das heißt, der Betriebssystempuffer sollte idealerweise auf ~ 2 Sekunden des Streams eingestellt sein, in diesem Fall 2 Megabyte. Ansonsten sind Verluste garantiert.

    Okay, aber wir haben TCP! Dadurch wird die Zustellung garantiert, und Sie werden gebeten, in diesem Fall auf den Absender zu warten. Lassen Sie uns zu TCP wechseln und das gleiche Bild betrachten. Der zusätzliche Overhead kann vernachlässigt werden. Mal sehen, was passiert. Wir haben also 360 Kilobyte Daten, die herausfliegen. Sie werden etwa 30 Millisekunden lang auf einem 100-Mbit-Kanal gesendet. Irgendwann in der 10. Millisekunde war der Empfangspuffer voll und die Kamera wurde aufgefordert, den Mund zu halten. Angenommen, nach weiteren 20 ms hat die Anwendung den gesamten verfügbaren Puffer gelesen (aber tatsächlich - 4 Bytes, dann 1400, dann weitere 4, weitere 1400 ...), und das Betriebssystem hat die Kamera aufgefordert, fortzufahren. Die Kamera schickte ein weiteres Drittel des Keyframes und fuhr wieder hoch. Nach weiteren 20 ms gingen wir weiter - aber die Kamera produzierte mehr Daten, die in den Puffer der Kamera selbst gingen. Und hier kommen wir zu einem rutschigen Moment - und wie groß ist der TCP-Puffer in der Kamera? Außerdem,In Windows Server ist das Standardquantum fest 120 ms . Bei 120 ms liegt unsere maximale Geschwindigkeit bei 8,5 Mbit. Das heißt, auf einem Serverbetriebssystem mit einem 128-KByte-Puffer ist es nicht nur schwierig, einen 8-Bit-Stream zu empfangen, sondern auch äußerst schwierig. Unter Desktop-Betriebssystemen ist es einfacher, es treten jedoch Probleme mit dem Niesen auf. Wenn der Puffer größer ist, wird es besser, aber auf jeden Fall - bei jeder Instabilität der Subtraktion beginnen Probleme, die im einfachsten Fall zu ruckartigen Bewegungen führen, in einigen Fällen zu einem Stromausfall oder einem ähnlichen Fehler, wenn der TCP-Puffer in der Kamera überläuft.

    Woher nur eine Schlussfolgerung gezogen werden kann - der Puffer sollte idealerweise auch eine Toleranz von etwa 2 Sekunden Fluss haben, in diesem Fall 2 Megabyte. Ansonsten sind Probleme wahrscheinlich.

    Vielleicht irre ich mich, aber wenn eine Anwendung, deren Aufgabe es ist, einen Stream von Kameras zu akzeptieren und zu speichern, dies nicht kann, ist dies ein Fehler. Und dieser Fehler sollte behoben und nicht angeboten werden, um das Problem auf das bereits Gelöste zu reduzieren und die Qualität auf eine analoge Kamera zu reduzieren. Dixi

    Jetzt auch beliebt: