Beispielhaftes Streamen von Medien aus HTML-Seiten

12

Ich bin also ein Software-Ingenieur, der versucht, einige Details über die Funktionsweise von Streaming Media zu verstehen. Ich habe den Löwenanteil des Tages damit verbracht, die verschiedenen Codecs, Containerformate und Streaming-Protokolle zu verstehen, die für meine Anwendung relevant sind. Soweit ist hier mein Verständnis, wie es funktioniert, was sehr gut irregeführt werden könnte:

  • Streaming-Medien beschränken sich auf das Containerformat und das Streaming-Protokoll :
    • Alle Audiodaten werden (über den Audio-Codec) in einen Audio-Bitstream codiert
    • Alle Videodaten werden (wiederum über einen Codec) in einen Videobitstream codiert
    • Die beiden Streams werden zu einem Container zusammengeführt ( gemultiplext? ) , Der letztendlich zu einer Datei (wie z. B. MP4 usw.) wird.
    • Ein spezieller Medienserver stellt diesen Container (MP4-Datei oder ein anderes Format) einem Client (möglicherweise einem HTML5-Videoplayer, der in einem anderen Browser ausgeführt wird) über ein Standard-Streaming-Protokoll wie RTSP zur Verfügung
      • Im Fall eines Browser-Clients gehe ich davon aus, dass der Browser selbst einen RTSP-Client hat, den er dann dem HTML5-Video-Player des Benutzers irgendwie präsentiert
  • Ich könnte eine MP4-Datei von einem Webserver wie nginx oder httpd hosten, aber da diese Server keine RTSP-Server sind, wäre ich nur in der Lage, Anforderungen für MP4 als Download-Anforderungen zu behandeln , und wäre daher nicht in der Lage, die zu streamen Media-Dateien
    • Ebenso, wenn ich curlzum Abrufen der Dateien von einem Nginx-Server verwenden curlwürde, würde es als Dateidownload behandelt , da weder Nginx noch RTSP sprechen
  • Wenn ich jedoch eine MP4-Datei von einem Streaming Media-Server (VideoLAN, Red5, Wowza usw.) hoste und einen RTSP-Client (oder einen unterstützten Streaming Media-Client) verwende, um einen Stream von diesem Server anzufordern , dann und nur Tritt dann ein tatsächliches Streaming auf ?
    • Obwohl YouTube- oder Vimeo-"Videos" auf HTML-Seiten gehostet werden, die über HTTP (S) von HTTP-Servern bereitgestellt werden, gehe ich davon aus, dass die eingebetteten Videoplayer auf diesen Seiten (auf denen die Videos tatsächlich abgespielt werden) tatsächlich eine Sekunde beginnen , anschließende Verbindung zu einem Streaming-Server und das Streaming erfolgt über RTSP oder ein anderes Nicht-HTTP-Protokoll

Das ist mein Verständnis, und ich denke, ich würde zuerst fragen, ob etwas, das ich oben angegeben habe, falsch ist. Bitte korrigieren Sie mich zuerst! Vorausgesetzt, ich habe mehr oder weniger recht:

Wie stellen Streaming-Media-Player, die in HTML-Seiten ausgeführt und von HTML-Servern bereitgestellt werden, Streaming-Verbindungen (RTSP usw.) mit Streaming-Media-Servern her (die RTSP-Anforderungen bereitstellen)?

smeeb
quelle
4
Warum die Gegenstimme? Dies ist kein Betrug, ist zum Thema, zeigt definitiv Forschung und ist eine SSCCE .
Smeeb
Warum wäre Streaming über HTTP seltsam? Streaming ist im Grunde genommen nur "Play as you download" (Wiedergabe beim Herunterladen), wobei die Daten anschließend (mit optionaler Pufferung) verworfen werden, anstatt auf den Abschluss des Downloads zu warten. Dieser Begriff wird auch für andere Arten der Stream-Verarbeitung in der Programmierung verwendet.
Daniel B
Nun, nachdem ich die Kommentare zu der gelöschten Antwort gelesen habe, glaube ich endlich festgestellt zu haben, was Sie fragen: „Wie funktioniert das Suchen überhaupt mit HTTP-Streaming? Sie können einen Zeitstempel nicht in eine Byte-Position innerhalb der Datei übersetzen! “Vielleicht sollten Sie die Frage dazu klären.
Daniel B

Antworten:

7

Wie stellen Streaming-Media-Player, die in HTML-Seiten ausgeführt und von HTML-Servern bereitgestellt werden, Streaming-Verbindungen (RTSP usw.) mit Streaming-Media-Servern her (die RTSP-Anforderungen bereitstellen)?

Allgemeine Anwendungen

RTSP scheint derzeit eher für Anwendungen / Geräte-Schnittstellen verwendet zu werden, die direkt Live-Streaming (z. B. IP-Kamera) oder Re-Streaming (wie eine Engine) ausführen, als für das Streaming gespeicherter Mediendateien von einem physischen Speicherort über eine HTTP-Web-Wiedergabeschnittstelle mit einem eingebetteter Player.

Es scheint, dass RTSP ein statusbehaftetes Protokoll ist und beim Streaming mehr UDP als TCP verwendet und eher als Servergerät (wie eine IP - Kamera) verwendet wird, das mit einem TCP / IP - Netzwerk verbunden ist und Streams über UDP usw. ausgibt Sie stellen dann eine Verbindung zu diesen Feeds (dem Server) als Client im selben Netzwerk her und können RTSP-Anforderungen ausgeben , um sie entsprechend zu nutzen.


Protokoll-Richtlinien

Obwohl RTSP in gewisser Weise ähnlich zu HTTP ist, definiert es Steuerungssequenzen, die zur Steuerung der Multimedia-Wiedergabe nützlich sind. Während HTTP zustandslos ist , hat RTSP den Status; Bei Bedarf wird ein Bezeichner verwendet, um gleichzeitige Sitzungen zu verfolgen. Wie HTTP verwendet RTSP TCP, um eine End-to-End-Verbindung aufrechtzuerhalten. Während die meisten RTSP-Steuermeldungen vom Client an den Server gesendet werden, laufen einige Befehle in die andere Richtung (dh von Server zu Client).

Hier werden die grundlegenden RTSP-Anforderungen dargestellt. Einige typische HTTP-Anfragen, wie die OPTIONS-Anfrage, sind ebenfalls verfügbar. Die Standardportnummer der Transportschicht ist 554 [3] für TCP und UDP, wobei letzteres selten für die Steuerungsanforderungen verwendet wird.

Quelle


Staatenlos

Ein zustandsloses Protokoll erfordert nicht, dass der Server Sitzungsinformationen oder den Status aller Kommunikationspartner für die Dauer mehrerer Anforderungen beibehält. Im Gegensatz dazu wird ein Protokoll, bei dem der interne Status auf dem Server beibehalten werden muss , als statusbehaftetes Protokoll bezeichnet.

Ein Nachteil der Staatenlosigkeit ist, dass möglicherweise zusätzliche Informationen in jede Anforderung aufgenommen werden müssen und diese zusätzlichen Informationen vom Server interpretiert werden müssen.

Quelle


Logischer Ablauf

Ich verstehe den Fluss von Streaming-Medien in dieser Form wie folgt:

  • Der Server, auf dem sich der Medieninhalt befindet, kapselt, komprimiert, codiert usw. den Video- / Audiodateninhalt in den richtigen Formaten und Segmenten für die Stream-Übermittlung
  • Der Webserver, der auf Verbindungen wartet, um auf die Streaming-Medien zuzugreifen, stellt alle Ressourcen bereit, die zum Streaming der Medien erforderlich sind
  • Der Client fordert die entsprechenden Ressourcen und Dateien an, lädt sie herunter und stellt sie fortlaufend zusammen, um sie über den URL-Zeiger wie konfiguriert und andere Parameter wiederzugeben. Die Wiedergabesoftware auf Client-Ebene setzt die übertragenen Pakete nacheinander zusammen, um eine ordnungsgemäße Wiedergabe des Inhalts zu ermöglichen.

Im folgenden Abschnitt über Streaming-Technologien finden Sie einen allgemeinen Vergleich von HTTP und RTSP.


Außerdem

In den folgenden 10 Gründen, warum Sie niemals Ihre eigenen Videos hosten sollten, habe ich die Teile zitiert, die auf den Punkt kommen, um Ihnen zu helfen, Ihre Frage "allgemein" zu beantworten, ohne zu spezifisch zu sein.

Im Wesentlichen heißt es, dass die Website mit den eingebetteten Media Player-Steuerelementen:

  • (1) Erkennen der Einstellungen des Client-Webbrowsers bei "Verbindung und Anforderung" vom Client und
  • (2) Dadurch werden der Codec und alle anderen clientseitigen Erkennungseinstellungen auf die entsprechenden Parameterwerte gesetzt
  • (3) Das Video wird direkt von dem Streaming-Server gestreamt, auf dem Sie die Video- und Audiodateien hosten, basierend auf weiterem Code in Ihren eingebetteten Media Player-Konfigurationen, der auf die URL der Mediendatei auf dem gehosteten Server verweist.

Streaming-Technologien

Der Client-Browser muss die Daten vom Server empfangen und zur Verarbeitung an die Streaming-Anwendung übergeben. Die Streaming-Anwendung konvertiert die Daten in Bilder und Töne. Ein wichtiger Faktor für den Erfolg dieses Prozesses ist die Fähigkeit des Clients, Daten schneller zu empfangen, als die Anwendung die Informationen anzeigen kann. Überschüssige Daten werden in einem Puffer gespeichert - einem Speicherbereich, der für die Datenspeicherung in der Anwendung reserviert ist. Wenn sich die Datenübertragung zwischen den beiden Systemen verzögert, leert sich der Puffer und die Präsentation des Materials ist nicht reibungslos.

HTTP-Protokoll

Das HTTP ist die vorherrschende Art und Weise, wie Dokumente im Internet verlinkt werden. Der Client stellt eine Verbindung zu dem Server her, der die zu streamende Datei enthält, die Datei wird abgerufen und die Verbindung geschlossen. Der HTTP-Server teilt dem Browser den Typ der zu übertragenden Datei mit.

Vorteile mit HTTP

Beim Streaming einer Datei über HTTP ist kein spezieller Streaming-Server erforderlich. Solange Ihr Browser MIME-Typen versteht, kann er eine Streaming-Datei von einem HTTP-Server empfangen. Einer der entscheidenden Vorteile des Streaming von Dateien mithilfe von HTTP besteht darin, dass es Firewalls passieren und Proxyserver verwenden kann.

Einige Nachteile

HTTP-Streaming verwendet TCP / IP (Transmission Control Protocol und Internet Protocol), um eine zuverlässige Übermittlung der Dateien zu gewährleisten. Dieser Prozess sucht nach fehlenden Paketen und fordert sie zur erneuten Übertragung auf. Dies wird im Streaming-Szenario problematisch, wenn Sie möchten, dass die Daten ignoriert werden, wenn sie bei der Übermittlung verloren gehen, sodass dynamische Dateien weiter abgespielt werden. HTTP kann die Modemgeschwindigkeit nicht erkennen, sodass Serveradministratoren gezielt Dateien mit unterschiedlichen Komprimierungsraten für Serverbenutzer mit unterschiedlichen Verbindungstypen erstellen müssen. Das Streamen von Dateien von HTTP-Servern wird für Situationen mit hohen Anforderungen nicht empfohlen.

RTSP-Protokoll

RTSP ist das Standardprotokoll, das von den meisten Anbietern von Streaming-Servern verwendet wird. RTSP-Server verwenden UDP (User Datagram Protocol) zum Übertragen von Mediendateien. UDP überprüft nicht ständig, ob Dateien an ihrem Ziel angekommen sind. Dies ist ein Vorteil für Streaming-Anwendungen, da die Dateiübertragung unterbrochen werden kann, solange die Verzögerung nicht zu groß ist. Das Ergebnis dieser Methode ist, dass es manchmal zu Datenverlusten kommt, die Wiedergabe der Dateien jedoch fortgesetzt wird, wenn die Verzögerung gering ist.

Quelle


10 Gründe, warum Sie niemals Ihre eigenen Videos hosten sollten

Wir sprechen über das Einbetten im Vergleich zu selbst gehosteten Videos

Zunächst laden Sie Ihre Videodatei zu einem Video-Hosting-Dienst eines Drittanbieters wie YouTube, Vimeo oder Wistia hoch.

Dann kopieren Sie ein kleines Stück Code, das sie Ihnen liefern, und fügen es in Ihren Beitrag oder Ihre Seite auf Ihrer eigenen WordPress-Site ein. Das Video wird auf Ihrer Site an der Stelle angezeigt, an der Sie den Einbettungscode eingefügt haben, aber das Video selbst wird von den Servern des Videohosts gestreamt, im Gegensatz zu Ihrem eigenen Webserver, auf dem Ihre WordPress-Site gehostet wird.

4. Kein Standard für das einzelne Dateiformat für Webvideos

Die aktuelle HTML5-Entwurfsspezifikation gibt nicht an, welche Videoformate von Browsern unterstützt werden sollen. Infolgedessen sind die gängigen Webbrowser unterschiedlich und unterstützen jeweils ein anderes Format. Internet Explorer und Safari können H.264 (MP4) -Videos wiedergeben, nicht jedoch WebM oder Ogg. Firefox spielt Ogg- oder WebM-Videos ab, jedoch nicht H.264. Zum Glück wird Chrome alle wichtigen Videoformate wiedergeben. Wenn Sie jedoch sicherstellen möchten, dass Ihr Video in allen wichtigen Webbrowsern wiedergegeben wird, müssen Sie Ihr Video in mehrere Formate konvertieren: .mp4, .ogv und .webm

5. Hoffe du konvertierst gerne Videos. Viel.

Die meisten Ihrer Zuschauer werden Ihre Videos wahrscheinlich von ihrem Desktop oder Laptop mit dem Vorteil einer Hochgeschwindigkeits-Internetverbindung ansehen. Für diese Leute möchten Sie eine große Datei in HD-Qualität bereitstellen, damit sie sie im Vollbildmodus anzeigen können, wenn sie dies wünschen. Im Allgemeinen bedeutet dies eine 1080p- oder 720p-Datei mit einer hohen Streaming-Bitrate (5000 - 8000 kbps).

Sie sollten jedoch auch eine kleinere Version mit niedrigerer Auflösung für die Übermittlung an mobile Geräte wie Telefone und Tablets sowie für die Übermittlung an Zuschauer mit langsameren Internetverbindungen codieren.

6. Video-Player

Ein Videoplayer ist eine kleine Web-Software, die Sie auf Ihrer Site installieren und die automatisch erkennt, welches Gerät Ihr Video anfordert, sowie die Verbindungsgeschwindigkeit und die entsprechende Version an diese Person übermittelt.

7. Umständlicher Code

Unabhängig davon, ob Sie ein Plugin eines Drittanbieters oder die integrierten Videofunktionen von WordPress verwenden, müssen Sie ein wenig Code erstellen, um dem Videoplayer mitzuteilen, welche Formate Sie erstellt haben und wo sie sich auf dem Server befinden. Es sieht ungefähr so ​​aus ...

<video poster="movie.jpg" controls>
<source src="movie.webm" type='video/webm; codecs="vp8.0, vorbis"'/>
<source src="movie.ogg" type='video/ogg; codecs="theora, vorbis"'/>
<source src="movie.mp4" type='video/mp4; codecs="avc1.4D401E, mp4a.40.2"'/>
<p>This is fallback content</p>
</video>

Was ist die beste Lösung, um Ihrer Website Videos hinzuzufügen?

Verwenden Sie einfach einen Video-Hosting-Dienst eines Drittanbieters und binden Sie Ihr Video in Ihren WordPress-Post oder Ihre WordPress-Seite ein.

Erster Schritt: Laden Sie Ihr Video zu einem der beliebten und etablierten Video-Hosting-Dienste wie Vimeo PRO hoch.

Schritt 2: Nachdem Ihr Video hochgeladen wurde und zum Anzeigen bereit ist, kopieren Sie die URL in Ihr Video. Kehren Sie zu Ihrer WordPress-Site zurück und fügen Sie die URL in Ihren Beitrag oder Ihre Seite ein, auf der das Video erscheinen soll.


Wenn Leute Ihre Seite anzeigen, wird das Video an der Stelle angezeigt, an der Sie die URL eingefügt haben. Die Videodatei selbst wird jedoch von den Servern des Videohosts gestreamt, im Gegensatz zu Ihrem eigenen Server, auf dem Ihre WordPress-Site gehostet wird.

Der eingebettete Videoplayer erkennt automatisch das Gerät, den Browser und die Geschwindigkeit der Internetverbindung des Benutzers und stellt ihnen dann die entsprechende Version der Videodatei zur Verfügung. Auf Ihrer Site muss nichts installiert werden. Keine Plugins, um auf dem neuesten Stand zu bleiben. Kein kniffliger Code.

Quelle

Pimp Juice IT
quelle
Dank @PIMP_JUICE_IT (+1) - ein paar Followup Fragen , wenn es Ihnen nichts ausmachen, von einer leichten Verwirrung über Ihre Verwendung des Ausdrucks "ergeben eingebetteten Video - Player ‚: Wenn Sie sagen , ‘ Im Wesentlichen heißt es , dass die Website , die die eingebettet video und audio player werden ... ", was meinst du mit embedded player ? Für mich kann Audio / Video entweder von einem Webserver (mit MPEG-DASH oder ähnlichem) oder einem Streaming-Server, der so etwas wie RTSP spricht , bereitgestellt werden . Und wieder ist ein Player für mich ein clientseitiges Konstrukt, das einem Menschen Audio / Video wiedergibt / präsentiert.
16.
Wenn Sie von einer Website (dem Server) mit einem Player sprechen , ist dies etwas verwirrend. Könntest Du das erläutern?
16.
4

Ich werde im Folgenden hauptsächlich Ihre Frage behandeln, was passiert, wenn ein Video im Browser angezeigt wird. Das Thema ist sehr umfangreich, daher werde ich nur auf die relevanten Punkte eingehen.

HTML5 hat das <VIDEO>Tag eingeführt, mit dem das Problem der Integration des angezeigten Videos in den Browser unter Verwendung von JavaScript und CSS behoben wurde. Das vorherige <OBJECT>Tag erforderte externe Software und war schlecht in die Seite integriert. Das neue Tag erforderte, dass der Browser auch ein Videoplayer wurde, obwohl keine Standards auferlegt wurden. Das Ergebnis war eine vollständige Fragmentierung der Standards. Die einzige Lösung besteht darin, dass der Videoserver mehrere Videoformate zur Verfügung stellt und dass alle diese alternativen Quellen in dem <VIDEO>Tag angegeben werden, aus dem der Browser die unterstützte auswählt.

Ein Beispiel für ein Tag mit mehreren Quellen:

<video width=320 height=240 controls poster=image.jpg>
   <source src="movie.mpd">
   <source src="movie.webm">
   Your browser does not support the video tag.
</video>

Das <VIDEO>Tag selbst ist protokollunabhängig und kann daher jedes vom Browser unterstützte Protokoll einschließlich RTSP verwenden. Die Unterstützung des MPEG-DASH-Protokolls (Dynamic Adaptive Streaming über HTTP) ist in letzter Zeit sehr umfangreich geworden. Daher wird es auf den meisten Geräten und Browsern nativ oder unter Verwendung von HTML5 wiedergegeben, sodass keine zusätzlichen Plugins erforderlich sind. Siehe diese Geräte- und Browserkompatibilitätstabelle . Lesen Sie auch diesen Mozilla-Artikel zur Vorbereitung Ihres Servers für die Bereitstellung von MPEG-DASH. DASH funktioniert über HTTP. Dies funktioniert also, solange Ihr HTTP-Server Bytebereichsanforderungen unterstützt und so eingerichtet ist, dass er MPD-Dateien mit unterstützt mimetype="application/dash+xml".

Die normale Interaktion zwischen Client und Server sieht wie folgt aus. Bei HTML5 VIDEO ist der Browser auch der Player, obwohl möglicherweise eine neue Verbindung zum Abspielen geöffnet wird.

Bild

Die ursprüngliche Verbindung liefert die Metadaten, die der Client zur Anzeige des Videos verwendet. Wenn das RTSP-Protokoll zum Abrufen dieser Metadaten verwendet wurde, wird später eine RTP-Verbindung zum Übertragen der Video- und Audiodaten erstellt. Das RTCP-Protokoll wird verwendet, um zusätzliche Befehle an den Server zu übertragen.

RTP, RTCP und RTSP arbeiten alle an verschiedenen Ports. Wenn sich RTP auf Port N befindet, befindet sich RTCP normalerweise auf Port N + 1. Eine RTP-Sitzung kann mehrere Streams enthalten, die am Ende des Empfängers kombiniert werden müssen. Audio und Video können sich beispielsweise auf getrennten Kanälen befinden.

Damit niemand von Ihren Inhalten ausgeschlossen wird, sollten Sie sowohl lizenzfreie Codecs, webM oder Theora als auch H.264-Video sowie Vorbis- und MP3-Audio zur Verfügung stellen. (Einfach gesagt, schwer zu tun.)

Folgendes passiert im Detail für RTSP:

  1. Der Client stellt eine TCP-Verbindung zu den Servern her, normalerweise über den TCP-Port 554, den bekannten Port für RTSP.

  2. Der Client beginnt dann mit der Ausgabe einer Reihe von RTSP-Header-Befehlen, die ein HTTP-ähnliches Format aufweisen und vom Server jeweils bestätigt werden. In diesen RTSP-Befehlen beschreibt der Client dem Server Details zu den Sitzungsanforderungen, z. B. die unterstützte RTSP-Version, den für den Datenfluss zu verwendenden Transport und alle zugehörigen UDP- oder TCP-Portinformationen. Diese Informationen werden mit den Headern DESCRIBE und SETUP übergeben und auf der Serverantwort mit einer Sitzungs-ID ergänzt, die der Client und alle vorübergehenden Proxy-Geräte verwenden können, um den Stream in weiteren Austauschen zu identifizieren.

  3. Sobald die Aushandlung der Transportparameter abgeschlossen ist, gibt der Client einen PLAY-Befehl aus, um den Server anzuweisen, mit der Übermittlung des RTP-Datenstroms zu beginnen.

  4. Sobald der Client entscheidet, den Stream zu schließen, wird ein TEARDOWN-Befehl zusammen mit der Sitzungs-ID ausgegeben, der den Server anweist, die mit dieser ID verknüpfte RTP-Übermittlung zu beenden.

Weitere Lektüre:

Harrymc
quelle
1

Hier ist eine schnelle und schmutzige Antwort.

Es gibt einen Unterschied zwischen der Wiedergabe von Videos im Web und dem Streaming in Echtzeit.

Die Wiedergabe erfolgt mit einem Player, der auf der Webseite enthalten ist (möglicherweise mit Flash, JS oder einem HTML5-Videoobjekt). Der Client (Browser) lädt diesen Player herunter und führt ihn aus. Der Player ruft seinerseits das Video über eine einfache Download-URL ab. Selbst bei Youtube gibt es Programme, mit denen Sie direkt auf die gehosteten Videodateien zugreifen und sie herunterladen können, wie Sie es bei jeder anderen Datei tun würden. Da das System einen regulären alten Download-Link verwendet, sind keine komplexen Streaming-Protokolle wie RTSP erforderlich

Echtzeit-Streaming (etwa von einer Webcam) ist ... schwieriger. In Flash ist diese Funktionalität bereits integriert, sie sollte jedoch nicht mehr verwendet werden. HTML5-Video unterstützt kein Echtzeit-Streaming, aber die Leute konnten es "austricksen", indem der Datei-Hosting-Server die angebotene Videodatei ständig ändert.

Anton Liakhovitch
quelle