Während die ersten Early Adopters unsere neuen Videokonferenzen (bis zu 100 Personen!) Anprobieren, sprechen wir in ihren Projekten weiterhin mit einem Browser über interessante Dinge aus der Welt der Sprach- und Videoübertragung. Wir werden auch über Videokonferenzen sprechen, aber später - wenn sich eine kritische Masse von Benutzern ansammelt und interessante Statistiken gesammelt werden. Und jetzt habe ich die Geschichte von Dr. Alex über den Ort verschiedener Protokolle bei der Übertragung von Videos mit geringer Latenz. Die Geschichte ist im Wesentlichen eine Antwort auf einen anderen Artikel, und der Autor weist zusammen mit der Geschichte auf die Fehler und Ungenauigkeiten hin, die seine Kollegen im Workshop gemacht haben.
Netzwerkdaten: Alarm separat, Video separat
Wenn Sie in modernen Systemen Videos in einem Browser sehen, werden der Videostream und der Alarm höchstwahrscheinlich von verschiedenen Servern verarbeitet. Wenn mit dem Video alles klar ist, bietet der „Alarmserver“ zwei Dinge: „Erkennung“ und „Handshake“. Die erste, "Entdeckung", ist die Wahl der Datenübertragungsmethode: IP-Adressen, ein Zwischenserver (falls erforderlich). „Handshake“ - über Verhandlungen zwischen Teilnehmern an Video- und Tonübertragung: Codecs, Auflösung, Bildrate, Qualität. Interessanterweise wurden im alten Flash Signalisierung und Medienübertragung nicht wie in VoxIP oder WebRTC getrennt und durch ein Protokoll bereitgestellt: RTMP.
Der Unterschied zwischen dem Signalisierungsprotokoll und dem Signalisierungstransport
Das Signalisierungsprotokoll definiert die Sprache, mit der sich der Browser und andere Teilnehmer an der Videoübertragung auf Erkennung und Handshake einigen. Es kann SIP für die Erkennung in VoIP oder WebRTC sein und es ist mit Angebot / Antwort für Handshake. Vor langer Zeit verwendete Flash
RTMP / AMF . Auf Wunsch können Sie für WebRTC nicht SIP, sondern ungewöhnliches JSEP verwenden.
Das Signalisierungstransportprotokoll vom selben Stapel, jedoch niedriger: Auf diese Weise werden die Signalisierungsprotokollpakete physisch übertragen. Traditionell wurde für Flash + SIP TCP oder UDP verwendet, aber jetzt im WebRTC + SIP-Bundle werden zunehmend WebSockets gefunden. Das WebSockets-Transportprotokoll belegt die TCP-Nische in Browsern, in denen Sie keine „reinen“ TCP- und UDP-Sockets verwenden können.
Ein vollständiger Signalisierungsstapel wird heute im Volksmund mit Ausdrücken wie "SIP über Web-Sockets", "JSEP über Web-Sockets", veraltetem "SIP über TCP / UDP" oder dem alten "Teil von RTMP" beschrieben.
Programmierer Anglizismus: Mediencodec
Die meisten Video-Streaming-Protokolle sind an einen oder mehrere Codecs gebunden. Das von der Kamera empfangene Video wird Frame für Frame verarbeitet. Netzwerkprobleme wie reduzierte Bandbreite, Paketverlust oder Verzögerung zwischen ihnen werden durch die Codec-Einstellungen für jeden Frame gelöst. Um Netzwerkprobleme rechtzeitig zu erkennen, verwenden wir Transportprotokollmechanismen (RTP / RTCP) und Bandbreitenschätzungsmechanismen (REMB, Transport-CC, TIMBR). Eines der grundlegenden Probleme bei Flash-Videos war, dass RTMP beides nicht konnte. Daher wurde das Video einfach nicht mehr abgespielt, wenn die Kanalbandbreite abnahm.
Ein weiterer Anglizismus: Media Streaming Protocol
Legt fest, wie der Videostream in kleine Pakete aufgeteilt wird, die vom Transportprotokoll über das Netzwerk gesendet werden. In der Regel bietet das Streaming-Protokoll weiterhin Mechanismen zur Behandlung von Netzwerkproblemen: Paketverlust und Verzögerung. Jitterpuffer, Neuübertragung (RTC), Redundanz (ROT) und Vorwärtsfehlerkorrektur (FEC).
Medienübertragungsprotokoll
Nachdem das von der Kamera empfangene Video in kleine Pakete aufgeteilt wurde, müssen diese über das Netzwerk übertragen werden. Das dafür verwendete Transportprotokoll ähnelt dem Signalisierungsprotokoll, aber da die „Nutzlast“ völlig anders ist, sind einige Protokolle besser als andere. Beispielsweise bietet TCP die Erreichbarkeit von Paketen, erhöht jedoch nicht den Wert des Stapels, da ähnliche Mechanismen (RTX / RED / FEC) bereits im Streaming-Protokoll enthalten sind. Verzögerungen beim erneuten Senden an TCP sind jedoch ein klarer Fehler, den UDP nicht aufweist. Es gibt jedoch die Praxis, UDP als "Protokoll für Torrents" zu blockieren.
Die Wahl der Protokoll- und Netzwerkports wurde früher durch „Hardcoding“ entschieden. Jetzt verwenden wir Protokolle wie ICE in WebRTC, mit denen wir uns auf Ports und Transport in jeder spezifischen Verbindung einigen können. In naher Zukunft ist es möglich, das QUIC-Protokoll (abwärtskompatibel mit UDP) zu verwenden, das von der IETF aktiv diskutiert wird und Vorteile gegenüber TCP und UDP in Bezug auf Geschwindigkeit und Zuverlässigkeit aufweist. Schließlich können wir Medien-Streaming-Protokolle wie MPEG-DASH und HLS erwähnen, die HTTP als Transport verwenden und von der Einführung von HTTP / 2.0 profitieren werden.
Medienübertragungssicherheit
Einige Engines schützen Daten während der Übertragung über das Netzwerk: entweder den Medienstrom selbst oder die Pakete der Transportschicht. Der Prozess umfasst die Übertragung von Verschlüsselungsschlüsseln, für die separate Protokolle verwendet werden: SDES in VoIP und DTLS in WebRTC. Letzteres hat den Vorteil, dass es neben Daten auch die Übertragung von Verschlüsselungsschlüsseln schützt.
Was mich an all dem stört
Einige Entwickler, wie die Autoren
dieses Artikels , stellen die reinen WebSocket- und QUIC-Protokolle auf die gleiche Ebene wie WebRTC, Flash oder HLS. Für mich sieht eine solche Gruppierung seltsam aus, weil die letzten drei Protokolle eine Geschichte über Streaming-Medien sind. Die Codierung und Paketierung erfolgt vor der Verwendung von WebSocket oder QUIC. Googles Referenz-WebRTC-Implementierung (libwebrtc / chrome) und Microsofts ORTC verwenden QUIC als Transportprotokoll.
Ebenso überraschend ist die fehlende Erwähnung von HTTP / 2.0 als Optimierung für HTTP-basierte Protokolle wie HLS und MPEG-DASH. Und das erwähnte CMAF ist nichts anderes als ein Dateiformat für HLS und MPEG-DASH, aber überhaupt nicht deren Ersatz.
Schließlich ist SRT nur ein Transportprotokoll. Er fügt natürlich eine Reihe von Chips hinzu, die mit HLS- und MPEG-DASH-Dateien basieren, aber alle diese Chips befinden sich bereits auf einer anderen Stapelebene und sind in RTMP oder WebRTC implementiert. SRT teilt auch die Codierung des Medienstroms und der Statistiken, wodurch der Codec diese Informationen nicht so nah wie möglich beieinander halten kann. Eine solche Entscheidung kann sich nachteilig auf die Fähigkeit auswirken, das übertragene Video an die sich ändernde Netzwerkbandbreite anzupassen.
Dateibasierte Protokolle wie HLS codieren mehrere Streams und wählen diejenigen aus, die zur Anpassung an die Kanalbreite erforderlich sind. Mit WebRTC können Sie die Codierung jedes Frames in Echtzeit anpassen: Dies ist viel schneller als die Auswahl eines anderen Streams in HLS, für den bereits gesendete Daten bis zu 10 Sekunden gezählt werden müssen.