Was ist RTSP und warum ist es notwendig?

April 14, 2022

10Minuten lesen

RTSP protocol

Roboter-Kuriere, Drohnen, unbemannte Autos und andere Errungenschaften der modernen Wissenschaft und Technik scheinen nicht mehr wie etwas aus einer Fantasiewelt. Sie sind für uns ein alltägliches Phänomen geworden (oder fast). Dank integrierter IP-Kameras können sie “sehen”, was passiert, und wir können die Welt durch ihre “Augen” sehen. Aber was wäre, wenn wir Ihnen sagen würden, dass die Vision (IP-Kameras) dieser Hightech-Kreaturen auf einer Technologie basiert, die über 20 Jahre alt ist?

Können Sie das glauben? Lehnen Sie sich zurück und lassen Sie sich überraschen.

In diesem Artikel verraten wir Ihnen, wie Technologie aus den 90er Jahren auch heute noch erfolgreich eingesetzt wird, warum es nichts Besseres gibt und warum Sie mehr darüber wissen sollten.

Spoiler: Der Name dieses Veteranen ist RTSP.

In diesem Text werden wir über RTSP, RTP, RTCP sprechen, wie sie in den heutigen IP-Kameras, die HEVC (H.265) unterstützen, mit Computer Vision und Analysetechnologie existieren, und wie sie bis heute überlebt haben. Was ist also so gut und erfolgreich an RTSP und warum wird es nicht im Fernsehen eingesetzt?

Inhaltsangabe:

  1. Was ist RTSP und warum ist es notwendig?
  2. Die Beziehung zwischen RTSP und HTTP RTP (RTCP)
  3. Beziehung zwischen RTSP, RTP, RTCP und SDP
  4. Die grundlegenden Methoden des RTSP-Protokolls: SIP und RTSP
  5. RTSP Was war/ist
  6. RTSP und RTMP
  7. Flussonic und RTSP

Was ist RTSP und warum ist es notwendig?

Was ist RTSP

RTSP (Real-Time Streaming Protocol) ist ein Protokoll der Anwendungsschicht, das für Telekommunikations- und Unterhaltungssysteme entwickelt wurde, um die Übertragung von Multimedia-Daten zu steuern. RTSP ist ein Signalisierungsprotokoll und steuert die Datenübertragungssitzung.

RTSP war ursprünglich für die Übertragung von Unterhaltungsfernsehen gedacht. Und das war es für den Moment auch. Dann entschied ein böses Schicksal anders: RTSP wurde aus dem Fernsehen getilgt und ist jetzt nur noch auf IP-Kameras zu finden.

Die in RTSP etablierten Prinzipien finden sich im modernen WebRTC-Standard wieder.

RTSP kann mit einer TV-Fernbedienung verglichen werden. Mit ihr kann das Video auf dem Fernsehgerät, dem Medienserver, gestartet, angehalten, pausiert usw. werden. Die Steuerung erfolgt nicht über Infrarot, sondern über das Internet. Die Menschheit hat noch nicht gelernt, den Inhalt selbst über die TV-Fernbedienung zu übertragen (auch wenn es unsere Jahre sind), aber es ist mehr als genug, um es zu steuern.

Moment, RTSP verwaltet also nur die Inhalte, aber wie werden die Inhalte selbst übertragen?

Auf der Transportschicht wird RTP (Real-Time Protocol) verwendet, um den Stream in Echtzeit zu übertragen. Die RTSP-Funktion ist gleichbedeutend mit der Fernsteuerung eines Streaming-Media-Servers. IP-Kameras können sowohl TCP als auch UDP für die Übertragung von Streaming-Inhalten verwenden. Es ist jedoch zu beachten, dass UDP für diese Aufgabe keinen praktischen Sinn macht.

Warum nicht UDP?

Aufgrund des Mangels an modernen Verlustausgleichsmechanismen. So gehen die Daten einfach irgendwo auf dem Weg verloren. In unserer Praxis halten wir uns an TCP, wo Daten und Datenmanagement in einem symbiotischen Fluss koexistieren. Es sollte angemerkt werden, dass alles gut funktioniert.

Wir haben das Konzept, wir haben auch den Zweck im allgemeinen Sinne. Aber wie sieht es in der Praxis aus?

Nehmen wir ein Beispiel: Nehmen wir an, Sie haben auf Ihrem Grundstück eine Videoüberwachung installiert und befürchten, dass Ihr Videorekorder und alle darauf befindlichen Daten gestohlen werden, ohne dass man die Gesichter der Diebe sehen kann. Was ist in diesem Fall zu tun? Den Videorekorder in einen Safe legen? Sie können eine Videoaufzeichnung direkt in der Cloud einrichten. Mithilfe des RTSP-Protokolls können Sie die Informationen an einen entfernten Cloud-Dienst senden. Wenn Sie die Datei aus der Ferne vom DVR betrachten möchten, erfolgt die Kommunikation mit diesem ebenfalls über RTSP, allerdings nur, wenn das Gerät das RTSP-Protokoll unterstützt.

RTSP wird für das Webstreaming als solches nicht mehr verwendet, es wurde von jüngeren Vertretern der Streaming-Technologie verdrängt und ersetzt: HLS und DASH, so dass wir nicht einmal die Chance haben, uns gegen den Wandel zu wehren.

Die Beziehung zwischen RTSP und HTTP RTP (RTCP)

Ähnlichkeiten:

  • Beide verwenden Klartext zum Senden von Nachrichten, und die Syntax des RTSP-Protokolls ist ähnlich wie die von HTTP.
  • RTSP wurde ursprünglich entwickelt, um mit dem zuvor geschriebenen HTTP-Protokollparsing-Code kompatibel zu sein.

Unterschiede:

  • RTSP speichert den Status. RTSP-Befehle müssen wissen, in welchem Zustand sie sich gerade befinden. Mit anderen Worten: RTSP-Befehle werden immer der Reihe nach gesendet, wobei jeder nächste Befehl auf den vorherigen folgt. RTSP bricht die Verbindung nicht ab, unabhängig davon, in welchem Zustand sie sich befindet. HTTP hingegen speichert den Zustand nicht. Nachdem das Protokoll einen Befehl gesendet hat, wird die Verbindung unterbrochen, und es besteht keine Abhängigkeit zwischen den Befehlen.

  • RTSP verwendet Port 554, während HTTP Port 80 verwendet.

  • Im Gegensatz zu RTSP werden bei HTTP die Anfragen vom Client gesendet und der Server antwortet. Bei RTSP können sowohl der Client als auch der Server Anfragen senden, was bedeutet, dass RTSP bidirektional sein kann.

Beziehung zwischen RTSP, RTP, RTCP und SDP

Lassen Sie uns zusammenfassen, wie RTSP, RTP, RTCP und SDP zusammenhängen:

  • RTP (Real Time Protocol).

Ein Echtzeit-Streaming-Protokoll. RTP stellt Zeitstempel, Seriennummern und andere Methoden zur Verfügung, um die Verarbeitungszeit bei Echtzeit-Datenübertragungen zu gewährleisten.

  • RTCP (Real-Time Transport Control Protocol)

Ein Protokoll zur Gewährleistung der Dienstqualität und Kontrolle der Teilnehmer. RTP und RTCP werden gemeinsam verwendet.

  • RTSP (Real-Time Streaming Protocol).

Ein Protokoll zur Kontrolle der Datenübermittlung.

  • SDP (Session Description Protocol).

Ein Protokoll zur Beschreibung einer Streaming-Datensitzung.

Die grundlegenden Methoden des RTSP-Protokolls. SIP und RTSP

An dieser Stelle möchten wir auch SIP (Session Initiation Protocol) erwähnen, um die Merkmale von RTSP hervorzuheben und es mit SIP zu vergleichen.

SIP (Session Initiation Protocol) ähnelt RTSP zwar optisch, seine Logik ist jedoch sehr unterschiedlich. So ist RTSP beispielsweise häufig durch eine einzige TCP-Sitzung gekennzeichnet, während SIP ein Anti-Muster darstellt.

Lassen Sie uns einen Vergleich auf der Grundlage von SDP anstellen. RTSP (heute SDP) wird ausschließlich zur Beschreibung des Inhalts verwendet. In SIP sowie in WebRTC (einer Erweiterung von SIP) wird SDP zur Konfiguration von Ports und Netzwerkkommunikation verwendet.

Die wichtigsten RTSP-Methoden sind im Folgenden aufgeführt:

Methoden Beschreibung
DESCRIBE Abfrage eines DeepL Inhalts, z.B. im SDP-Format
OPTIONS Abfrage unterstützter Methoden
PLAY Anforderung, mit der Übertragung von Inhalten zu beginnen
PAUSE Anforderung eines vorübergehenden Stoppsĸ und der Ausstrahlung
RECORD Anforderung zum Schreiben von Inhalten auf den Server
REDIRECT Anforderung, auf andere Inhalte umzuleiten
SETUP Anforderung eines Transportmechanismus für den Inhalt
ANNOUNCE Anforderung zur Aktualisierung von DeepL Inhaltsdaten
TEARDOWN Anforderung, den Fluss zu stoppen und Ressourcen freizugeben

RTSP Was war/ist?

History of RTSP

Let’s start with a bit of history.

RTP wurde zusammen mit RTCP im Jahr 1996 entwickelt und in den Standard RFC 1889 aufgenommen. SDP wurde im April 1998 in RFC 2327 veröffentlicht. RTSP wurde ebenfalls im April 1998 von der Internet Engineering Task Force (IETF) entwickelt und ist im Standard RFC 2326 enthalten. Es wurde sofort sehr populär, da es die direkte Wiedergabe von Video- und Audioinhalten über das Internet ermöglichte, ohne dass Inhalte auf ein Client-Gerät heruntergeladen werden mussten. Die Leute waren begeistert von der Zeit- und Ressourcenersparnis, die damit möglich war!

RTSP kommt aus Netzen, in denen Verzögerungen und Verluste bei der Übertragung gering und stabil sind, d. h. aus lokalen Netzen. Von dort kommen auch viele andere Lösungen.

RTSP wurde erdacht und entwickelt, als die Aufgabe, die Übermittlung an den Client zu kontrollieren, dem Server anvertraut werden sollte. Der Server kümmerte sich also um die gesamte Logik: was, wann und an wen gesendet werden sollte. Wir können sagen, dass der Server so komplex wie möglich und der Client so einfach und unkompliziert wie möglich sein musste. Als wir zu den HLS- und DASH-Protokollen wechselten, war die Situation genau umgekehrt. Der Client war nun komplizierter und der Server primitiver. Es stellte sich jedoch heraus, dass die Funktionen der intelligenten Kontrolle über die Auslieferung des RTSP-Servers bis heute nicht überlebt haben und in Vergessenheit geraten sind.

Bei den heutigen RTSP-Servern handelt es sich meist um IP-Kameras, die keine Ahnung von all den RTSP-Funktionen haben, die vor Jahrzehnten konzipiert wurden. Das bedeutet, dass es nicht wirklich wichtig ist, ob es Kundenkommentare gibt. Wenn der Kunde die Daten erhält, großartig, wenn nicht, nun ja, dann gibt es Probleme.

Beachten Sie, dass RTSP zusammen mit der Telefonie entwickelt wurde. Es basierte auf sehr erfolgreichen Lösungen, die bereits auf dem Markt existierten, aber wir haben sie ein wenig verändert: RTP für die Datenübertragung, RTCP für die Signalisierung der Qualität der Datenübertragung (QoS) und SDP für die Übertragung von Inhaltsinformationen. Um Ihnen eine Vorstellung vom Erfolg dieser Lösungen zu geben: RTP und RTCP, die vor etwa 25 Jahren entwickelt wurden, werden heute in gleicher Weise im WeRTC-Standard verwendet, dem De-facto-Standard für Echtzeitkommunikation. Sie hatten also schon damals alles, was sie brauchten, um sich bis heute über Wasser zu halten!

Einst war RTSP die führende Technologie für das Streaming von Video und Audio. Doch im Laufe der Zeit wurden RTSP und RTMP von HTTP-basierten Technologien, die einen adaptiven Bitratenalgorithmus verwenden, verdrängt. Trotzdem wird RTSP auch heute noch aktiv in der Videoüberwachung eingesetzt, um das Feed von IP-Kameras zu erfassen.

Es ist wichtig zu wissen, dass RTSP für IP-Kameras und für das Fernsehen zwei völlig unterschiedliche Protokolle sind. Das gleiche RTSP für das Fernsehen ist nur bei älteren Systemen zu finden, die noch funktionieren.

Da wir bereits über RTSP gesprochen haben, müssen wir auch RTMP erwähnen.

RTSP vs RTMP

RTMP (Real-Time Messaging Protocol) wurde als Protokoll für die Übertragung von Funktionen, Remote Code Management, eine Art RPC-Protokoll, wie zuvor CORBA oder jetzt gRPC, geschaffen. RTMP war an sich schon recht komplex. So unhöflich es auch klingen mag, RTMP ist nur deshalb noch am Leben, weil CDNs es rechtzeitig zu unterstützen begannen. Heute bietet fast jedes CDN die Möglichkeit, Videos über RTMP zu streamen, nicht aber, sie abzuspielen. Heute ist RTMP nur ein Veröffentlichungsprotokoll, aber kein Wiedergabeprotokoll, da es keine Vorteile gegenüber HLS, CMAF usw. bietet.

Früher arbeiteten IP-Kameras im Wesentlichen mit dem Codec MPEG-4 Part 2 und das Fernsehen hatte alle Vorteile von MPEG-2. Dann sind sie alle zu MPEG-4 Part 10 übergegangen, auch bekannt als H.264 oder AVC. Das ist richtig, es gibt keinen Grund, still zu sitzen, es ist Zeit, sich weiterzuentwickeln.

Ok, die Codecs wurden geändert, aber was ist mit RTSP und RTMP? Was halten sie aus? Nun, es führt kein Weg daran vorbei.

Erinnern Sie sich, dass RTSP aus bereits erfolgreichen Lösungen entstanden ist: RTP, RTCP, SDP? Nun, IP-Kameras sind dank der Flexibilität von SDP nahtlos auf H.264 umgestiegen. Auf dieselbe Weise sind IP-Kameras zu H.265 oder HEVC übergegangen.

Bei RTMP hingegen war ein solcher Übergang nicht so einfach möglich. Der Grund dafür ist, dass RTMP nicht in der Lage ist, neue Codecs hinzuzufügen, d. h. zu erweitern.

Wie das Sprichwort sagt, überlebt der Stärkste.

Flussonic und RTSP

Bei IT-Produkten, die in Eile und nicht auf die beste Art und Weise geschrieben wurden, war der Übergang von UDP zu TCP schwierig. Es gelang ihnen nicht, das asynchrone Programmiermodell qualitativ zu beherrschen. In der Praxis drückt sich das in der Übersetzung des TCP-Sockets in den “non-blocking”-Modus aus, in dem Daten verloren gehen können, d.h. die Versuche der Software, Daten in den Socket zu schreiben, scheinen vergeblich zu sein, weil der Socket blockiert ist. locked. Dies hat zur Folge, dass das Betriebssystem selbst die Daten nicht annimmt. Es stellt sich heraus, dass die Kamerasoftware die Daten einfach “wegwirft”, und als Ergebnis haben wir ein Chaos.

Gibt es eine Möglichkeit, dieses Problem zu lösen?

Sicher, indem man die IP-Kamera mit einem Kabel direkt an den Server anschließt. Obwohl dies ein offizieller Weg ist, um Kameras zu installieren (sie wurden eigentlich nicht für die Übertragung von Daten über das Internet entwickelt), scheint es in der heutigen Realität eine lächerliche und leichtfertige Lösung zu sein.

In Flussonic gibt es Modi zur Wiederherstellung der Synchronisation. Wenn zum Beispiel die chinesische Kamera die Synchronisation und die Daten verliert, gibt es in Flussonic spezielle Mechanismen, um verlorene Informationsbytes wiederherzustellen, so dass der Datenstrom wiederhergestellt werden kann. Wie cool ist das denn?

Was brauchen Sie, um Videos von der IP-Kamera in Flussonic abzurufen?

Erstens, die IP-Adresse der Kamera. Zweitens: Die IP-Adresse der Kamera allein reicht nicht aus, um Videos von ihr zu erhalten. Sie müssen immer einen weiteren Pfad angeben. Dies ist nicht immer in der Dokumentation enthalten, so dass Sie sich möglicherweise an den Hersteller der Kamera wenden müssen.

So sehen RTSP-Links aus:

  • rtsp://hostname/path - Syntax;
  • rtsp://user:password@ip/path - Autorisierungs-URL;
  • rtsp2://hostname/path - ermöglicht die Audiotranscodierung in AAC.
  • rtsp://192.168.0.100/h264 - Beispiel für einen echten Link.

In Flussonic können Sie unter anderem die Option tracks=1 verwenden, um nur die Videospur zu erfassen. Im Folgenden ein Beispiel für die Konfiguration:

stream fake { 
    input fake://fake; 
} 
stream input_rtsp { 
    input rtsp://localhost/fake tracks=1; 
} 

Mit Flussonic Media Server können Sie Streams über RTSP und viele andere andere Protokolle empfangen.

Wie man eine IP-Kamera zu Flussonic hinzufügt und Videos an die Website sendet, finden Sie in der [Dokumentation].

Sie können auch über diese und viele andere Flussonic-Funktionen in der Dokumentation auf unserer Website lesen.

Schlüsselwörter:
Codecs Media Server

Flussonic Media Server trial

Mit dem Absenden Ihrer Anfrage erklären Sie sich mit unserer terms and conditions

Our experts will contact you shortly, offer tech advice and consultation, and send you a trial license..

Füllen Sie das Formular aus, um einen kostenlosen Flussonic Media Server Testschlüssel zu erhalten.

Wenn Sie innerhalb einer Stunde keine E-Mail von uns erhalten, überprüfen Sie bitte Ihren Spam-Ordner und fügen Sie Flussonic zu Ihrer Liste der vertrauenswürdigen Kontakte hinzu.

Email: support@flussonic.com Phone: +3 (228) 08-23-37