So verstehen Sie das HTTP-FLV-Live-Broadcast-Modul nginx-http-flv-module, das auf dem nginx-rtmp-module-Modul basiert

Der Inhalt dieses Artikels befasst sich mit dem Verständnis des HTTP-FLV-Live-Broadcast-Moduls nginx-http-flv-module basierend auf dem nginx-rtmp-module-Modul. Es hat einen bestimmten Referenzwert und Freunde in Not können sich darauf beziehen . Ich hoffe, es hilft dir.

Derzeit bereiten viele Einzelpersonen und Hersteller die Kommerzialisierung dieses Moduls vor. Laut Rückmeldungen von Internetnutzern gibt es im Ausland bereits Live-Übertragungswebsites, die dieses Modul verwenden. Der bekannteste Hersteller, der sich auf den kommerziellen Einsatz vorbereitet, ist Huawei. Internetnutzer und Hersteller haben viele Fehler gemeldet. Nach der Reparatur ist die Funktion immer stabiler geworden.

04.06.2018: Ein CDN-Hersteller hat das nginx-http-flv-Modul offiziell gestartet, den RTMP-Modus verwendet und die gop_cache-Konfiguration aktiviert (Interleave-Konfiguration deaktivieren, es kommt zu Verzögerungen oder Beim Öffnen ist kein Ton zu hören. Derzeit wissen wir nicht, wie wir das Problem beheben können. Zu ihren Kunden gehören Inke und Weihou.

28.06.2018: Ein Online-Videohersteller hat das nginx-http-flv-Modul offiziell mit der HTTP-FLV-Methode gestartet, ohne die gop_cache-Konfiguration zu aktivieren. Es wurde noch nicht vollständig aktiviert. Warten. Stabilität beachten.

28.07.2018: Als Reaktion auf die Bedürfnisse einiger Internetnutzer wurden RPM-Installationspakete für RHEL6 (CentOS 6) und RHEL7 (CentOS 7) bereitgestellt, siehe nginx-http -flv-module -packages.

Funktionsvergleich zwischen nginx-http-flv-module und nginx-rtmp-module:

Funktion

nginx-http-flv-module

nginx-rtmp-module

Bemerkungen

HTTP-FLV

√

×

nginx-http-flv-module unterstützt HTTPS-FLV

GOP-Cache

√

×

vhost

√

×

Listen-Konfiguration weglassen

√

x

功能	nginx-http-flv-module	nginx-rtmp-module	备注
HTTP-FLV	√	×	nginx-http-flv-module支持HTTPS-FLV
GOP缓存	√	×
vhost	√	×
省略listen配置	√	x
JSON风格的stat	√	x
RTMP 302	Beta	×	nginx-http-flv-module作为服务器或者客户端

JSON-Stilstatistik

√

x

RTMP 302

Beta

×

nginx-http-flv-module als Server oder Client

Aktualisiert am 09.03.2018:

Kürzlich wurde die Stabilität des Moduls auf verschiedenen Plattformen getestet. Aufgrund der Bedingungen wurde kein Problem festgestellt getestet, mit Ausnahme der FreeBSD-Plattform. Sowohl Debian 7.x als auch macOS Sierra wurden getestet, da Nginx Windows offiziell nicht sehr gut unterstützt und nicht die leistungsstärkste IOCP-Schnittstelle auf der Windows-Plattform verwendet. Die Betriebseffizienz auf der Windows-Plattform ist nicht sehr hoch, was sich in einer langen Push-Wartezeit von 3 Sekunden und mehr äußert. Die erste Bildschirmzeit ist sehr lang und beträgt 4 Sekunden und die Anzahl der Clients wird durch die Auswahl selbst begrenzt. Das Gerät mit der kürzesten Push-Streaming-Wartezeit und der kürzesten ersten Bildschirmzeit ist macOS Sierra. Beim Test auf diesem Computer wurde es im Grunde innerhalb von Sekunden gepusht und geöffnet. Beim Kompilieren unter macOS Sierra habe ich darauf geachtet, dass sowohl SO_REUSEPORT als auch TCP_FASTOPEN unterstützt werden und dass jeder Unterprozess von Nginx eine eigene Annahmewarteschlange hat, wodurch der Donnerherdeneffekt behoben wird wird bereits übertragen, wenn SYN initiiert wird, anstatt die tatsächlichen Daten nach Abschluss des Handshakes zu übertragen. Das Drücken und Öffnen in Sekundenschnelle kann mit diesen beiden Optionen zusammenhängen. Allerdings unterstützt macOS Sierra das Binden eines Prozesses an eine CPU nicht, daher kann es beim Prozesskontextwechsel zu Overhead kommen und die Effizienz ist möglicherweise nicht so gut wie bei Linux, wenn die Systemlast hoch ist. Da es sich bei macOS Sierra um einen Firmenrechner handelt, wurde kein Stresstest durchgeführt. Auf meinem Laptop ist Debian 7.x installiert. Da die Kernel-Version niedriger ist, werden die beiden unter macOS Sierra unterstützten Optionen nicht unterstützt. Während des Tests lagen die Push-Wartezeit und die erste Bildschirmzeit zwischen Windows 7 und macOS Sierra. Beim Test auf dem Server (System CentOS 6.4, unterstützt SO_REUSEPORT, aber nicht TCP_FASTOPEN) war es ähnlich wie unter macOS Sierra, jedoch unter Berücksichtigung der Server CPU Die Leistung ist viel leistungsstärker, daher schneidet macOS Sierra am besten ab, wenn die Last nicht hoch ist. Da macOS Sierra ein Update von Mac OS X ist und die unterste Ebene von Mac OS

Außerdem habe ich kürzlich versucht, die Funktion zur Konvertierung der RTMP 302-Umleitung in die HTTP 302-Umleitung hinzuzufügen. Da viele Player die RTMP 302-Umleitung nicht unterstützen, ist die Funktion zur Unterstützung der HTTP 302-Umleitung grundsätzlich Standard wird unterstützt. Derzeit ist die Funktion grundsätzlich abgeschlossen. Der problematische Teil besteht jedoch darin, dass bei Verwendung der Sendeschnittstelle des HTTP-Frameworks die verknüpfte Liste nach längerem Abspielen eine Schleife bildet, sodass der Fortschritt nicht fortgesetzt werden kann und dies auch nicht der Fall war auf Github aktualisiert. Das Folgende ist der Haupt-RTMP-Konfigurationsausschnitt von Nginx und der Screenshot der HTTP 302-Umleitung während der VLC-Wiedergabe: Der Push-Stream wird an die Anwendung namens hls gepusht (FFmpeg unterstützt keine RTMP 302-Umleitung, daher kann er nur an hls gepusht werden).

application myapp {

rewrite '^/myapp/(.*)' '/hsl/$1';

}

1.HTTP 302 Kurzes Diagramm der Umleitungspaketerfassung

2. Detailliertes Diagramm zur HTTP 302-Umleitungspaketerfassung

Aktualisierung 2018-03 15:

Einige Internetnutzer haben berichtet, dass der Befehl on_play nach dem Debuggen nicht verwendet werden kann, weil es ein Problem mit der Reihenfolge des hinzugefügten ngx_http_flv_live-Moduls gibt. Es wurde nun geändert, um es durch einige Statusänderungen zu umgehen Ändern Sie die Reihenfolge der Module und rufen Sie dann einige dieser Funktionen später auf, um sicherzustellen, dass die Funktionen mit dem ursprünglichen nginx-rtmp-Modul konsistent sind.

Aktualisierung vom 16.03.2018:

Die von einigen Internetnutzern vorgeschlagene CORS-Funktion (domänenübergreifend) ist jetzt nicht mehr für HTTP-FLV-Antwortdaten verfügbar, sondern verwendet einen Teil davon HTTP Der Framework-Code wurde neu geschrieben. Darüber hinaus besteht ein Problem mit der Funktion on_connect, die vorübergehend nicht verfügbar ist und auf eine Reparatur wartet.

Update vom 18.03.2018:

on_connect-Problem wurde behoben.

Aktualisiert am 20.03.2018:

Der Fehler, dass das entsprechende on_connect und on_play nicht gefunden werden konnte, weil sich die zu durchsuchende Anwendung nicht im ersten Serverblock befand, wurde behoben. Es lag daran, dass es keine Übereinstimmung mit der richtigen Serverkonfiguration gab, behoben.

Aktualisiert am 22.03.2018:

Vor langer Zeit schlugen einige Internetnutzer vor, dass HTTP-FLV zum Abspielen von Pull verwendet wird, wenn „idle_streams“ auf „off“ gesetzt ist (die Standardeinstellung ist „on“) fehlgeschlagen. Dies wurde behoben.

Aktualisierung vom 25.03.2018:

Einige Internetnutzer verwendeten flv.js, um den von nginx-http-flv-module gezogenen Live-Stream abzuspielen, und fanden einen Fehler: wenn (1) die Nginx Die verwendete Version ist 1.13.9, (2) der Player ist flv.js, (3) beim Abspielen des Pull-Streams wird er nicht abgespielt, weil flv.js den HTTP-Header „Verbindung:“ sendet. keep-alive: Wenn nginx-http-flv-module eine Anfrage an den Upstream initiiert, kehrt die Downstream-Anfrage normalerweise zurück, bevor die Upstream-Anfrage zurückgekehrt ist. Allerdings hat Nginx seit Version 1.13.1 ein r->blockiertes Urteil gelöscht. und „Verbindung: keep-alive“ führt dazu, dass ngx_http_finalize_request ngx_http_set_keepalive aufruft. Diese Funktion ruft die registrierte Bereinigungsfunktion auf, um die Downstream-Anforderung zu schließen, was dazu führt, dass die Wiedergabe fehlschlägt. Bereits behoben. Während des Debuggens dieses Fehlers stellte ich fest, dass sich flv.js von anderen Mainstream-Playern (z. B vlc), die erste Bildschirmzeit ist am schnellsten, fast ohne Verzögerung. Die verwendete Pull-Quelle ist die Live-Übertragungsquelle von Hong Kong Satellite TV: rtmp://live.hkstv.hk.lxdns.com/live/hks.

Aktualisiert am 27.03.2018:

Ich habe gerade etwas Code geändert und es gab einen Fehler, der wirklich ärgerlich ist. Als Reaktion auf die Anfrage einiger Internetnutzer nach der Funktion zum Hinzufügen benutzerdefinierter HTTP-Header wurde die Sendefunktion kürzlich erneut versucht, die Filterschnittstelle des HTTP-Frameworks von Nginx einzuführen, aber es scheiterte immer noch, also habe ich einfach und grob herausgesucht Das letzte Filtermodul und das header_filter-Modul wurden viel ungenutzten Code entfernt. Die offizielle stabile Version von Nginx, nginx-1.12.2, wird für die Kompilierung auf Github verwendet. Infolgedessen berichteten einige Internetnutzer heute, dass die Kompilierung nicht möglich war. Nach der Überprüfung kam es vor, dass diese nicht gefundenen Makros zu nginx-1.11.10 hinzugefügt wurden, das ich seit der Änderung des nginx-rtmp-Moduls verwende , und die von Internetnutzern verwendete Version war niedriger. Sie kann einfach nicht kompiliert werden, sie wurde behoben.

Aktualisierung vom 29.03.2018:

Vor ein paar Tagen berichteten einige Internetnutzer, dass flv Wird verwendet, um den Pull-Stream nicht abzuspielen. Das Problem wurde auch behoben Fehler, der leicht behoben werden kann. Die neueste Version von Nginx und eine etwas ältere Version (nginx-1.11.10) wurden getestet.

Datensatz vom 05.04.2018:

Dieses Mal handelt es sich nicht um ein Update:) Gestern berichteten einige Internetnutzer, dass sie bei Verwendung von flv.js zum Abspielen von Push-Streams nicht abgespielt werden konnten Dachte, nginx-http-flv – Das Modul hat wieder ein Problem. Ich habe es selbst getestet und mit der neuesten Version von nginx-1.13.10 kompiliert. Es gibt kein Problem beim Abspielen von Push- und Pull-Streams nginx-1.12.2 und es gibt immer noch kein Problem, als ich mich darauf vorbereitete, zu sehen, was am Abend schief gelaufen ist, berichtete ein Internetnutzer, dass der Browser laut dem Test die Anzahl der flv.js begrenzt habe. Ein einzelner Browser konnte heute Mittag nur Firefox testen, das gleiche Problem trat auf. Dann konnte ich VLC nicht abspielen Daraus kann ich schließen, dass es sich nicht um ein Problem mit dem nginx-http-flv-Modul handelt. Dies ist jedoch eine sehr wichtige Information. Die Anzahl der Browser, die die Wiedergabe von flv.js unterstützen, ist auf 6 begrenzt. Andere Browser wurden nicht getestet.

Aktualisiert am 06.04.2018:

Frühere Statistiken enthielten nicht die akzeptierte Anzahl und Ausgabe von http-flv-Liveübertragungen und wurden jetzt hinzugefügt. Nachdem die Unterstützung für flv.js nun stabil ist, ist das Folgende ein Screenshot der Verwendung von flv.js zum Abspielen:

Ein kommerzieller Hersteller hat dies gemeldet, wenn die Videoquelle ist Reines Video, egal welche Wiedergabemethode verwendet wird. Es gibt kein Problem mit der Wiedergabeverbindung, aber die Videodaten wurden nicht empfangen. Nach dem Debuggen wurde festgestellt, dass es einen Fehler in der Logik zur Beurteilung von reinem Audio gab, der Nginx verursachte -http-flv-Modul zur Endlosschleife in der Schnittstelle zum Senden von Audio- und Videodaten. Jetzt ist es repariert.

Aktualisiert am 14.04.2018:

Einige Internetnutzer berichteten gestern, dass Push-Streaming zu Speicherlecks führt, wenn die gop-Cache-Modulzuordnung aktiviert ist wird nicht freigegeben, wenn der Push-Flow ausgeschaltet ist. Verursacht durch den Speicher, behoben. Darüber hinaus gibt es laut Rückmeldung von Internetnutzern ein Problem mit den Befehlen on_connect und on_play im Multiprozessmodus. Bitte verwenden Sie diese beiden Befehle vorerst nicht im Multiprozessmodus und warten Sie auf eine Reparatur.

Aktualisiert am 15.04.2018:

Ein kommerzieller Hersteller berichtete, dass der Speicher während des zufälligen Flash-Tests weiter wachsen würde und dass während des nächtlichen Debuggens ein Speicherleck vermutet wurde Es wurde bestätigt, dass es tatsächlich einen Speicherverlust gab, und dieser lag daran, dass der Speicherpool in der ngx_http_request_t-Struktur nicht freigegeben wurde, was behoben wurde.

Aktualisierung vom 21.04.2018:

Einige Internetnutzer berichteten, dass im Multiprozessmodus on_play für Authentifizierungsvorgänge verwendet wird, beim Pushen jedoch das lokale Relay (Unterprozess, der die akzeptiert push (Drücken des Streams an andere untergeordnete Prozesse) führt auch eine on_play-Authentifizierung durch, was unzumutbar (aber eigentlich kein Fehler) ist, da die Authentifizierung bereits zuvor durchgeführt wurde. Jetzt wurde der on_play-Vorgang des lokalen Relays entfernt. Dem nginx-http-flv-Modul ist es egal, wofür on_play verwendet wird. Da das lokale Relay jedoch keine on_play-Vorgänge mehr ausführen sollte, ist der geänderte Code relativ einfach und die Wiederherstellung ist relativ einfach einfach, also ändern Sie es vorübergehend so. Darüber hinaus wurde das von Netizen @qqzzzx gemeldete Stresstest-Absturzproblem teilweise behoben. Das verbleibende Problem besteht darin, dass nach dem Trennen der Stresstestgruppe ein Speicherverlust auftritt.

Aktualisierung vom 25.04.2018:

Das Absturzproblem beim Stresstest wurde behoben und das mögliche Problem einer übermäßigen CPU-Auslastung wurde behoben. Der Stresstest dauert mehr als eine Stunde (srs -Benchs eigenes Testvideo, 500 HTTP-FLV und 200 RTMP), es wurden noch keine Probleme gefunden, gerne können Fehler gemeldet werden.

Aktualisiert am 12.05.2018:

Einige Internetnutzer berichteten, dass das Aktivieren der Option gop_cache in einigen Fällen dazu führen würde, dass Stresstests viel Speicher verbrauchen. Es ist nicht sicher, ob ein Speicherverlust vorliegt. Der Stresstest lässt sich nicht oft reproduzieren. Netizens wiesen darauf hin, dass es einfacher sei, das Stresstest-Tool und den Server zu reproduzieren, wenn sie sich nicht auf demselben Host befinden. Es ist tatsächlich einfacher, den Stresstest auf diese Weise zu reproduzieren. Wenn der Speicherverbrauch jedoch relativ groß ist, wird der Stresstest nicht wiederholt, und die Anzahl der Parallelitätsvorgänge bleibt unverändert dass es sich nicht um ein Speicherverlustproblem handelt. Nachdem ich den Quellcode wiederholt überprüft hatte, vermutete ich, dass beim Senden der GOP die GOP-Daten sofort in das sendende Ring-Array eingefügt wurden. Da Nginx asynchron und nicht blockierend ist, sendet Nginx die Daten möglicherweise nicht tatsächlich vom Ring-Array an das Netzwerk (Wenn beispielsweise die Netzwerkbandbreite zwischen Server und Client nicht ausreicht), kann der zugewiesene Speicher nicht sofort wiederverwendet werden, und nachdem die GOP tatsächlich gesendet wurde, wird der zugewiesene Speicher nicht mehr freigegeben (im Speicherpool und damit). hat nichts mit der Verbindung zu tun, sondern nur mit der Konfigurationsstruktur). Die anschließende Datenübertragung ähnelt nicht den GOP-Daten, die alle auf einmal gesendet werden, sodass der recycelte Speicher nicht vollständig genutzt werden kann und ein großer Teil im Leerlauf ist. Ändern Sie nun das Gop-Cache-Modul so, dass es einen eigenen unabhängigen Speicherpool verwendet, und geben Sie diesen Speicherpool frei, nachdem die GOP gesendet wurde.

Update vom 14.05.2018:

Ein im Update vom 12.05.2018 eingeführter Speicherleckfehler wurde behoben. Der Code war lange Zeit unverständlich, und dann traten sofort Probleme auf es wurde geändert. Beheben Sie den Fehler, dass das Hochversions-GCC-Kompilierungsprojekt fehlgeschlagen ist (ich habe online nachgesehen, gcc-7.x.x prüft, ob beim Hinzufügen bestimmter Kompilierungsoptionen ein Durchbruch im Switch-Fall vorliegt), aber ich habe keine sehr hohe Version Version von gcc vorliegt, daher kann es sein, dass es noch einige unentdeckte Kompilierungsfehler gibt, und wir warten derzeit auf Antworten von Internetnutzern.

Aktualisiert am 16.05.2018:

Ich habe gcc-7.2.0 im Laufe des Tages kompiliert und installiert und dabei festgestellt, dass alle Kompilierungswarnungen durchgefallen sind (die in den Nginx-Kompilierungsoptionen als Fehler gelten). ), Fehler behoben.

Datensatz vom 18.05.2018:

Dieses Mal handelt es sich nicht um ein Update. Im Update vom 12.05.2018 wurde vermutlich die Option gop_cache während des Stresstests aktiviert ist srs-bench) wird ein besonderer Grund für den Speicherverbrauch sein. Nachdem ich heute Abend das Protokoll überprüft habe, stellte ich fest, dass die vorherige Vermutung nicht der Hauptgrund war. Aus dem Protokoll geht hervor, dass Nginx immer 128 Byte Daten empfängt. Wenn das Konfigurationselement chunk_size nicht in der Konfiguration angegeben ist, beträgt der Standardwert 4096 Byte. Das heißt, nachdem der Server die Protokollsteuernachricht „Set Chunk Size“ gesendet hat , der Client Der Client hat nicht auf die Protokollsteuerungsnachricht „Set Chunk Size“ geantwortet, sodass der Server weiterhin die vorherigen 128 Bytes verwendet. Im schlimmsten Fall führt dies dazu, dass das Nginx-http-flv-Modul Speicher zum Verpacken zuweist Daten nach dem Empfang der Daten. Wenn Sie (4096 + maximale RTMP-Headergröße) so viele Bytes Speicherplatz zum Packen von 128 Bytes Daten verwenden, werden 32-mal mehr Daten verschwendet. Verwenden Sie ffmpeg für Vergleichstests. ffmpeg reagiert auf die Protokollsteuerungsnachricht „Set Chunk Size“, sodass keine Speicherverschwendung entsteht. Dem Autor von SRS (Simple-RTMP-Server) wurde ein Problem gemeldet. Ich werde die Behandlung dieser Ausnahme durch nginx-http-flv-module aktualisieren, wenn ich Zeit habe.

Aktualisiert am 20.05.2018:

Das Problem des in einigen Fällen besonders hohen Speicherverbrauchs wurde behoben. Wenn die Auslastung immer noch sehr hoch ist, kann dies auf den genannten sekundären Grund zurückzuführen sein oben verursacht.

Update vom 14.06.2018:

Ein von Internetnutzern gemeldetes Problem wurde behoben, nachdem der Parameter „ngx_stat_active“ eine Zeit lang ausgeführt wurde wiederholte Subtraktionsoperationen und wurde behoben, hat keinen Einfluss auf die normale Funktionsnutzung.

2018-06-19 Update:

Mehrere Fehlerkorrekturen in Pull-Requests von nginx-rtmp-module wurden synchronisiert. Es gibt keine größeren Änderungen. Darüber hinaus wurde dem nginx-http-flv-Modul die Funktion zum direkten Pushen von fmp4 hinzugefügt. Sie wurde implementiert, um reines Video-fmp4 direkt an Browser zu pushen, die MSE (Media Source Extensions) unterstützen, derzeit nicht von Safari auf iOS unterstützt ). Spielen Sie ab und der Ton wird später hinzugefügt.

Aktualisierung vom 25.06.2018:

Die Grundfunktion des Pushens von fmp4 wurde im Wesentlichen abgeschlossen. Einige Internetnutzer haben eine PR veröffentlicht, die Statistiken im JSON-Format unterstützt. Ich habe es ausprobiert und fand es auch sehr gut.

Update vom 29.06.2018:

Ändern Sie die ursprünglichen RTMP-Informationen in stat in http-flv, da zwei Hersteller RTMP (gop_cache aktivieren) und HTTP offiziell kommerzialisiert haben -FLV. (ohne aktivierten gop_cache), Meilensteinversion 1.2.4 wurde veröffentlicht.

Aktualisiert am 09.07.2018:

3 kleine Fehler behoben: Beim Einschalten der DASH-Funktion kann es zu einer Endlosschleife kommen, da die aus der Datei gelesenen Daten 0 sind xml-Methode Das Problem, dass die Versionsnummer des nginx-http-flv-Moduls nicht in der Statistik angezeigt werden kann (PR eines Internetnutzers); Behebung des Fehlers der Rückgabe von 405 (Methode nicht zulässig), wenn die HEAD-Anfrage keine flv_live-Standorte konfiguriert

Das obige ist der detaillierte Inhalt vonSo verstehen Sie das HTTP-FLV-Live-Broadcast-Modul nginx-http-flv-module, das auf dem nginx-rtmp-module-Modul basiert. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!