Ist der progressive HTTP-Download eine praktikable Alternative zu HLS / DASH / RTMP für die Bereitstellung von Live-Videos?

Ich arbeite an einer Website, die Live-Videos für Benutzer streamen muss, und als solche musste ich mich mit dem traurigen Zustand der aktuellen browserbasierten Video-Streaming-Technologie auseinandersetzen. Die derzeit beliebtesten Lösungen für das Live-Streaming weisen Kompatibilitätsprobleme auf. RTMP erfordert Flash, HLS wird nur von Safari und Chrome für Android nativ unterstützt , DASH wird nirgendwo nativ unterstützt, und für die Verwendung von dash.js sind Media Source Extensions erforderlich , die noch nicht in großem Umfang unterstützt werden.

Dies führt zu einer für mich offensichtlichen Frage: Ist es möglich, einfachen progressiven Download als Alternative zu Protokollen wie HLS, RTMP und DASH zu verwenden, für die entweder Browserunterstützung oder Plugins erforderlich sind?

Die Idee, progressive Downloads zum Streamen von Live-Medien zu verwenden, ist nicht unerreicht. Leute machen es schon für Audio. Mit Tools wie liveCaster können Sie Live-MP3-Audio über eine einzige progressive HTTP-Antwort streamen, ohne eine zuvor aufgezeichnete MP3-Datei zu benötigen. Bibliotheken wie AmplitudeJS haben sich alle Mühe gegeben, Funktionen für diese Art von Live-Audio-Streaming hinzuzufügen .

Ich habe jedoch keine Beispiele für diese Technik gesehen, die in der Natur für Videos verwendet wurde, und ich kann nicht sagen, warum. Es sieht so aus, als würde es eine Schicht von unordentlichen und schwierigen Kompatibilitätsproblemen auf der Browserseite für relativ wenig Kompromiss beseitigen. (Und die Kompatibilität ist immer noch ein großes Problem beim Live-Streaming, selbst wenn die Profis es tun. Wenn ich versuche, ein Live-Video auf dem iPlayer von BBC in Firefox anzusehen, erhalte ich nur eine Fehlermeldung, in der ich aufgefordert werde, Flash zu installieren.) Diese Technik, und ich habe noch nie jemanden gesehen, der diese Idee außer mir erwähnte .

Warum? Gibt es eine grundlegende Einschränkung, die es unmöglich macht, eine Videodatei wie eine MP4-Datei beim Generieren über einen progressiven Download zu streamen und beim Herunterladen in einem <video>Element abzuspielen ?

Ihre Frage ist gültig und theoretisch ich glaube , Sie können verwenden Progressive Downloads für Live - Video - Streaming. Tatsächlich verwenden viele Online-Streaming-Videos wie YouTube usw. bereits HTTP. Ich gehe davon aus, dass Sie ausschließlich über LIVE- Streaming und nicht nur über Streaming sprechen .

Sie müssen die Live-Streaming-Anwendungsfälle jedoch selbst implementieren! Was sonst die Streaming-Protokolle (RTMP etc.) selbst machen. Hier sind einige Gründe, diese Protokolle und Architekturen zu bevorzugen:

1. Variable Bitrate

Die meisten Live-Streaming-Videos sind in VBR codiert und Ihr Video muss sich schnell an die sich ändernde Netzwerküberlastung Ihres Clients anpassen. So kann Ihr Video in sehr kurzer Zeit mehrere Auflösungen wechseln, je nachdem, wie schnell oder langsam die Client-Verbindung ist.

Laut Wikipedia

Dabei werden die Bandbreite und die CPU-Kapazität eines Benutzers in Echtzeit ermittelt und die Qualität eines Videostreams entsprechend angepasst

2. Live-Inhalte

Der wichtigste Punkt ist, dass Live-Streaming Live- Inhalte bedeutet . Im Gegensatz zum progressiven HTTP-Download können Sie zu keinem Zeitpunkt puffern. Der Benutzer muss den neuesten Frame sehen, der für die ganze Welt bestimmt ist, und darf nicht zurückbleiben.

3. Suche deaktivieren

Ein kleines Problem, aber das Protokoll sollte dem Benutzer ausdrücklich nicht erlauben, rückwärts (und offensichtlich vorwärts) zu suchen. Dies sollte nicht nur auf Video-Player-Ebene, sondern auch auf Netzwerkebene gesteuert werden.

4. Häufige Unterbrechungen / unzuverlässiges Netzwerk

Ich bin mir über diesen Punkt ein wenig unklar, aber ich weiß, dass es einige Zeit dauern kann, bis ein weiterer Handshake hergestellt wird, sobald der eingehende HTTP-Download getrennt wird (auch mit keep-alive). Live-Protokolle lassen sich aufgrund des nächsten Punkts viel schneller verbinden und trennen ->

5. Latenz

HTTP läuft von Natur aus über TCP, was eine garantierte Zustellung von Paketen gewährleistet. Vergleichen Sie dies mit UDP, das in vielen Protokollen (insbesondere Live-Multiplayer-Spielen) verwendet wird, bei denen Geschwindigkeit Vorrang vor Garantien hat.

Weitere Informationen finden Sie hier -> https://en.wikipedia.org/wiki/Streaming_media#Protocols

6. Kopieren von Inhalten

Die meisten Live-Stream-Server reagieren nur auf den Inhalt der aktuellen Uhrzeit. Obwohl es immer noch möglich ist, Inhalte von Live-Streams zu kopieren, muss auf Screenshots usw. zurückgegriffen werden. Wenn ein HTTP-Progressiv-Download durchgeführt wird, ist das Kopieren von Inhalten ziemlich trivial (daher gibt es so viele YouTube-Downloader).

Jetzt kann HTTP so modelliert werden , dass die meisten der oben genannten Funktionen zur Verfügung stehen.

Das von Ihnen erwähnte HTTP Live Streaming (HLS) von Apple kommt dem, was Sie erreichen möchten , am nächsten.

Und in diesem Bereich wird aktiv geforscht, wie hier angegeben -> http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=65749&PageNum=2

Ich bin auf der Suche nach weiteren Informationen und werde diese Antwort aktualisieren.