Comment comprendre le module de diffusion en direct HTTP-FLV nginx-http-flv-module implémenté sur la base du module nginx-rtmp-module

Le contenu de cet article explique comment comprendre le module de diffusion en direct HTTP-FLV nginx-http-flv-module basé sur le module nginx-rtmp-module. Il a une certaine valeur de référence et les amis dans le besoin peuvent s'y référer. . J'espère que cela vous aidera.

Actuellement, de nombreux particuliers et constructeurs s'apprêtent à commercialiser ce module. D'après les retours des internautes, il existe déjà des sites de diffusion en direct utilisant ce module à l'étranger. Le fabricant le plus connu se préparant à une utilisation commerciale est Huawei. Les internautes et les fabricants ont signalé de nombreux bugs. Après réparation, la fonction est devenue de plus en plus stable. Je tiens à exprimer ma gratitude.

04/06/2018 : Un fabricant de CDN a officiellement lancé nginx-http-flv-module, en utilisant le mode RTMP et en activant la configuration gop_cache (désactivez la configuration entrelacée, il y aura du décalage ou pas de son à l'ouverture), actuellement nous ne savons pas comment y remédier), leurs clients incluent Inke et Weihou.

28/06/2018 : Un fabricant de vidéos en ligne a officiellement lancé le module nginx-http-flv, en utilisant la méthode HTTP-FLV sans activer la configuration gop_cache. Il n'a pas encore été entièrement activé. en attente. Observez la stabilité.

28/07/2018 : En réponse aux besoins de certains internautes, des packages d'installation RHEL6 (CentOS 6) et RHEL7 (CentOS 7) ont été fournis, voir nginx-http -flv-module-packages.

Comparaison des fonctions entre nginx-http-flv-module et nginx-rtmp-module :

Fonction

nginx-http-flv-module

nginx-rtmp-module

Remarques

HTTP-FLV

√

×

nginx-http-flv-module prend en charge HTTPS-FLV

Cache GOP

√

×

hôte virtuel

√

×

Omettre la configuration d'écoute

√

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作为服务器或者客户端

Statistiques de style JSON

√

x

RTMP 302

Bêta

×

nginx-http-flv-module en tant que serveur ou client

Mise à jour le 09/03/2018 :

Récemment, la stabilité du module a été testée sur différentes plates-formes. Actuellement, aucun problème n'a été trouvé lors de la lecture de cette partie. En raison des conditions, cela n'a pas été le cas. été testé sauf pour la plate-forme FreeBSD Windows 7. Debian 7.x et macOS Sierra ont été testés puisque Nginx ne prend officiellement pas très bien en charge Windows et n'utilise pas l'interface IOCP la plus puissante de la plate-forme Windows (select est utilisé). , l'efficacité de fonctionnement sur la plate-forme Windows n'est pas très élevée, se manifestant par un long temps d'attente de poussée, 3s+, le premier temps d'écran est très long, 4s+, la sélection elle-même limite le nombre de clients, la valeur par défaut est 1024. Celui avec le temps d'attente de streaming push et le temps de premier écran le plus court est macOS Sierra. Lorsqu'il a été testé sur cette machine, il a été poussé et ouvert en quelques secondes. J'ai prêté une attention particulière hier soir. Lors de la compilation sous macOS Sierra, SO_REUSEPORT et TCP_FASTOPEN sont pris en charge. Le premier permet à chaque sous-processus de Nginx d'écouter et dispose d'une file d'attente d'acceptation dédiée, ce qui résout l'effet de troupeau tonitruant. est déjà transporté lorsque SYN est lancé, au lieu de transmettre les données réelles une fois la prise de contact terminée. Pousser et ouvrir en quelques secondes peut être lié à ces deux options. Cependant, macOS Sierra ne prend pas en charge la liaison d'un processus à un processeur. Il peut donc y avoir une surcharge lors du changement de contexte de processus, et l'efficacité peut ne pas être aussi bonne que celle de Linux lorsque la charge du système est importante. Puisque macOS Sierra est un ordinateur d’entreprise, aucun test de résistance n’a été effectué. Mon ordinateur portable est installé avec Debian 7.x. La version du noyau étant inférieure, les deux options prises en charge sur macOS Sierra ne sont pas prises en charge. Lors du test, le temps d'attente push et le temps de premier écran se situaient entre Windows 7 et macOS Sierra. Lors du test sur le serveur (système CentOS 6.4, prenant en charge SO_REUSEPORT mais pas TCP_FASTOPEN), il était similaire à celui sur macOS Sierra, mais compte tenu du serveur. CPU Les performances sont beaucoup plus puissantes, donc macOS Sierra fonctionne mieux lorsque la charge n'est pas élevée. Étant donné que macOS Sierra est mis à jour à partir de Mac OS X et que la couche inférieure de Mac OS X a été initialement développée sur la base de FreeBSD, on suppose que les performances sur FreeBSD devraient également être bonnes.

De plus, j'ai récemment essayé d'ajouter la fonction de conversion de la redirection RTMP 302 en redirection HTTP 302 Étant donné que de nombreux lecteurs ne prennent pas en charge la redirection RTMP 302, la fonction de prise en charge de la redirection HTTP 302 est fondamentalement standard. est pris en charge. À l'heure actuelle, la fonction est pratiquement terminée, mais le problème est que lors de l'utilisation de l'interface d'envoi du framework HTTP, la liste chaînée formera une boucle après une longue lecture, de sorte que la progression ne peut pas être poursuivie et elle n'a pas été mis à jour vers github. Voici l'extrait de configuration principal rtmp de nginx et la capture d'écran de la redirection HTTP 302 pendant la lecture de VLC : le flux push est poussé sur l'application nommée hls (FFmpeg ne prend pas en charge la redirection RTMP 302, il ne peut donc être poussé que vers hls).

application monapp {

réécrire '^/myapp/(.*)' '/hsl/$1';

}

1.HTTP 302 Bref diagramme de capture de paquets de redirection

2. Diagramme détaillé de capture de paquets de redirection HTTP 302

2018-03 - Mise à jour 15 :

Certains internautes ont signalé que la commande on_play ne peut pas être utilisée. Après le débogage, c'est parce qu'il y a un problème avec l'ordre du module ngx_http_flv_live ajouté. Il est maintenant modifié pour le contourner via certaines modifications de statut. changer l'ordre des modules, puis appeler certaines de ces fonctions plus tard pour vous assurer que les fonctions sont cohérentes avec le module nginx-rtmp d'origine.

Mise à jour du 16/03/2018 :

La fonction CORS (cross-domain) proposée par certains internautes est désormais disponible. Les données de réponse HTTP-FLV n'utilisent plus de codage en dur, mais utilisent une partie de. HTTP Le code du framework a été réécrit. De plus, il y a un problème avec la fonction on_connect et elle est temporairement indisponible, en attente de réparation.

Mise à jour du 18/03/2018 :

Le problème on_connect a été résolu.

Mise à jour le 20/03/2018 :

Correction du bug selon lequel les on_connect et on_play correspondants ne pouvaient pas être trouvés car l'application à rechercher n'était pas dans le premier bloc du serveur. Après vérification, c'était parce qu'il n'y avait pas de correspondance avec la configuration correcte du serveur, corrigé.

Mise à jour le 22/03/2018 :

Il y a longtemps, certains internautes ont suggéré que lorsque ralenti_streams est désactivé (la valeur par défaut est activée), l'utilisation de HTTP-FLV pour lire pull sera échouer. Cela a été corrigé.

Mise à jour du 25/03/2018 :

Certains internautes ont utilisé flv.js pour lire le flux en direct extrait par nginx-http-flv-module et ont trouvé un bug : lorsque (1) le Nginx version utilisée Le numéro est 1.13.9, (2) le lecteur est flv.js, (3) lors de la lecture du pull stream, il ne sera pas lu après enquête, c'est parce que flv.js envoie l'en-tête HTTP "Connexion : keep-alive", lorsque nginx-http-flv-module lance une requête vers l'amont, la requête en aval revient généralement avant le retour de la requête en amont. Cependant, Nginx a supprimé un jugement r->bloqué depuis la version 1.13.1, et "Connexion : keep-alive" amène ngx_http_finalize_request à appeler ngx_http_set_keepalive. Cette fonction appellera la fonction de nettoyage enregistrée pour fermer la requête en aval, provoquant l'échec de la lecture. Déjà corrigé. C'est pendant le processus de débogage de ce bug que j'ai découvert que lorsque nginx-http-flv-module activait l'élément de configuration gop_cache, flv.js était différent des autres lecteurs grand public (tels que vlc ), le premier temps d'écran est le plus rapide, avec presque aucun délai. La source d'extraction utilisée est la source de diffusion en direct de Hong Kong Satellite TV : rtmp://live.hkstv.hk.lxdns.com/live/hks.

Mise à jour le 27/03/2018 :

Je viens de changer du code et il y a eu un bug, ce qui est vraiment ennuyeux. Récemment, en réponse aux demandes de certains internautes concernant la fonction d'ajout d'en-têtes HTTP personnalisés, la fonction d'envoi a été modifiée. J'ai réessayé d'introduire l'interface de filtre du framework HTTP de Nginx, mais cela a toujours échoué, j'ai donc simplement et grossièrement choisi le. dernier module de filtre et module header_filter Suppression de beaucoup de code inutilisé. La version stable officielle de Nginx, nginx-1.12.2, est utilisée pour la compilation sur github. En conséquence, certains internautes ont signalé aujourd'hui que la compilation n'était pas possible. Après vérification, il est arrivé que ces macros introuvables aient été ajoutées à nginx-1.11.10, que j'utilise depuis que j'ai modifié nginx-rtmp-module. , et la version utilisée par les internautes était inférieure. Elle ne peut tout simplement pas être compilée, elle a été corrigée.

Mise à jour du 29/03/2018 :

Il y a quelques jours, certains internautes ont signalé que lors de l'utilisation de nginx-1.13.1 et des versions supérieures pour compiler avec nginx-http-flv-module, flv est utilisé. js ne parviendra pas à lire le flux d'extraction. Voir la mise à jour du 25/03/2018. Il y a également un problème de transmission du flux en premier, puis d'utilisation de flv.js pour le lire. bug qui peut être facilement résolu. Le problème a été corrigé. La dernière version de Nginx et une version légèrement plus ancienne (nginx-1.11.10) ont été testées.

Enregistrement du 05/04/2018 :

Cette fois, ce n'est pas une mise à jour :) Hier, certains internautes ont signalé que lors de l'utilisation de flv.js pour lire des flux push, ils ne pouvaient pas être lus. J'ai pensé que nginx-http-flv -Le module a encore un problème. Je l'ai testé moi-même et je l'ai compilé avec la dernière version de nginx-1.13.10. Il n'y a aucun problème pour lire les flux push et pull. Je l'ai également compilé avec la version stable officielle. nginx-1.12.2 et il n'y a toujours pas de problème. , alors que je me préparais à voir ce qui n'allait pas dans la soirée, un internaute a signalé que le navigateur limitait le nombre de flv.js. D'après le test, un seul navigateur ne pouvait ouvrir que 6 flv.js. J'ai utilisé Firefox pour le tester à midi aujourd'hui, et le septième flv.js n'a pas pu être lu. il n'y a eu aucun problème. À partir de là, je peux confirmer que ce n'est pas un problème avec nginx-http-flv-module. Cependant, il s'agit d'informations très importantes. Le nombre de navigateurs prenant en charge la lecture de flv.js est limité à 6. Les autres navigateurs n'ont pas été testés.

Mise à jour le 06/04/2018 :

Les statistiques précédentes n'incluaient pas le nombre et la sortie acceptés de la diffusion en direct http-flv, et elles ont été ajoutées maintenant. Maintenant que la prise en charge de flv.js est stable, voici une capture d'écran de l'utilisation de flv.js pour jouer :

Un fabricant commercial a signalé que lorsque la source vidéo est vidéo pure, quelle que soit la méthode de lecture utilisée. Il n'y a aucun problème avec la connexion de lecture, mais les données vidéo n'ont pas été reçues. Après le débogage, il a été constaté qu'il y avait un bug dans la logique de jugement de l'audio pur, ce qui a causé nginx. -http-flv-module pour boucler à l'infini dans l'interface d'envoi de données audio et vidéo. Maintenant, c'est la réparation.

Mise à jour le 14/04/2018 :

Certains internautes ont signalé hier que lorsque l'option gop_cache est activée, le streaming push provoquerait des fuites de mémoire. Il a été constaté que l'allocation du module de cache gop. n'est pas libéré lorsque le flux de poussée est désactivé. Causé par la mémoire, corrigé. De plus, selon les retours des internautes, il y a un problème avec les commandes on_connect et on_play en mode multi-processus. Veuillez ne pas utiliser ces deux commandes en mode multi-processus pour le moment jusqu'à ce qu'elles soient corrigées.

Mise à jour le 15/04/2018 :

Un fabricant commercial a signalé que la mémoire continuerait de croître lors de tests flash aléatoires, et une fuite de mémoire a été suspectée lors du débogage nocturne. a confirmé qu'il y avait bien une fuite de mémoire, et cela était dû à la non-libération du pool de mémoire dans la structure ngx_http_request_t, qui a été corrigée.

Mise à jour du 21/04/2018 :

Certains internautes ont signalé qu'en mode multi-processus, on_play est utilisé pour les opérations d'authentification, mais lors du push, le relais local (sous-processus qui accepte le push) Pousser le flux vers d'autres processus enfants) effectuera également une authentification on_play, ce qui est déraisonnable (mais pas réellement un bug) car l'authentification a déjà été effectuée. Désormais, l'opération on_play du relais local a été supprimée. nginx-http-flv-module ne se soucie pas de l'utilisation de on_play, mais étant donné que le relais local ne doit plus effectuer d'opérations on_play, le code modifié est relativement simple et la récupération est possible. facile, alors modifiez-le comme ça temporairement. De plus, le problème de crash du test de stress signalé par l'internaute @qqzzzx a été partiellement résolu. Le problème restant est qu'il y aura une fuite de mémoire après la déconnexion du groupe de test de stress. Après le correctif, il sera mis à jour vers github.

Mise à jour du 25/04/2018 :

Le problème de crash du test de stress a été résolu et le problème éventuel d'utilisation excessive du processeur a été résolu. Le test de stress a duré plus d'une heure. (vidéo de test de srs -Bench, 500 HTTP-FLV et 200 RTMP), aucun problème n'a encore été trouvé, bienvenue pour signaler les bugs.

Mise à jour le 12/05/2018 :

Certains internautes ont signalé que l'activation de l'option gop_cache entraînerait une consommation importante de mémoire dans les tests de stress. Il n'est pas sûr qu'il y ait une fuite de mémoire. Le test de stress ne peut pas être reproduit plusieurs fois. Les internautes ont souligné qu'il est plus facile de reproduire l'outil de test de stress et le serveur s'ils ne sont pas sur le même hôte. Il est en effet plus facile de reproduire le stress test de cette manière. Cependant, si la consommation de mémoire est relativement importante, arrêtez le stress test, puis répétez le stress test et le nombre de concurrence reste inchangé, ce qui prouve. qu'il ne s'agit pas d'un problème de fuite de mémoire. Après avoir vérifié à plusieurs reprises le code source, j'ai deviné que lors de l'envoi du GOP, les données du GOP étaient immédiatement placées dans le réseau en anneau d'envoi. Étant donné que Nginx est asynchrone et non bloquant, Nginx ne peut pas réellement envoyer les données du réseau en anneau au réseau. (par exemple, lorsque la bande passante réseau entre le serveur et le client est insuffisante), la mémoire allouée ne peut pas être recyclée immédiatement, et une fois le GOP effectivement envoyé, la mémoire allouée n'est plus libérée (dans le pool mémoire, et avec elle n'a rien à voir avec la connexion, seulement la structure de configuration). La transmission ultérieure des données n'est pas comme les données GOP qui sont envoyées en une seule fois, de sorte que la mémoire recyclée ne peut pas être entièrement utilisée et qu'une grande partie est inactive. Modifiez maintenant le module de cache gop pour utiliser son propre pool de mémoire indépendant et libérez ce pool de mémoire après l'envoi du GOP.

Mise à jour du 14/05/2018 :

Correction d'un bug de fuite de mémoire introduit dans la mise à jour du 12/05/2018. Le code était longtemps incompréhensible, puis des problèmes survenaient aussitôt. ça a été changé. Situation. Corrigez le bug selon lequel le projet de compilation gcc haute version a échoué (j'ai vérifié en ligne, gcc-7.x.x vérifiera s'il y a une erreur dans le cas du commutateur lors de l'ajout de certaines options de compilation), mais je n'ai pas un problème très élevé. version de gcc à portée de main, il peut donc encore y avoir des erreurs de compilation non découvertes, et nous attendons actuellement les réponses des internautes.

Mise à jour le 16/05/2018 :

J'ai compilé et installé gcc-7.2.0 pendant la journée, et j'ai trouvé tous les avertissements de compilation (qui sont considérés comme des erreurs dans les options de compilation de Nginx ), Bug corrigé.

Enregistrement du 18/05/2018 :

Ceci n'est pas une mise à jour. Dans la mise à jour du 12/05/2018, je suppose qu'il sera spécial d'activer l'option gop_cache pendant le test de stress. (l'outil utilisé est srs-bench). La raison de la consommation de mémoire après avoir vérifié le journal ce soir, j'ai découvert que la supposition précédente n'était pas la raison principale. Le journal montre que Nginx reçoit toujours 128 octets de données. Si l'élément de configuration chunk_size n'est pas spécifié dans la configuration, la valeur par défaut est de 4 096 octets, c'est-à-dire après que le serveur a envoyé le message de contrôle du protocole Set Chunk Size. , le client Le client n'a pas répondu au message de contrôle du protocole Set Chunk Size, le serveur a donc continué à utiliser les 128 octets précédents. Dans le pire des cas, nginx-http-flv-module allouera de la mémoire pour empaqueter le. données après réception des données. L'utilisation (4096 + taille maximale de l'en-tête RTMP) d'autant d'octets d'espace pour emballer 128 octets de données gaspille 32 fois plus de données. Utilisez ffmpeg pour les tests de comparaison. ffmpeg répondra au message de contrôle du protocole Set Chunk Size, cela n'entraînera donc pas de gaspillage de mémoire. Un problème a été soumis à l'auteur de SRS (Simple-RTMP-Server). Je mettrai à jour la gestion de cette exception par nginx-http-flv-module lorsque j'en aurai le temps.

Mise à jour le 20/05/2018 :

Le problème de consommation de mémoire particulièrement importante dans certains cas a été corrigé. Si l'utilisation est encore très importante, cela peut être dû à la raison secondaire évoquée. ci-dessus.

Mise à jour du 14/06/2018 :

Correction d'un problème signalé par les internautes. La valeur du paramètre ngx_stat_active était incorrecte après une exécution pendant un certain temps. Il a été constaté que cela était dû à. Les opérations de soustraction répétées et ont été corrigées, n'affectent pas l'utilisation normale des fonctions.

Mise à jour du 19/06/2018 :

Synchronisation de plusieurs corrections de bugs dans les requêtes pull de nginx-rtmp-module. Fondamentalement, ce sont tous des bugs évidents. Aucune modification majeure. De plus, la fonction de pousser directement fmp4 a été ajoutée à nginx-http-flv-module. Ce soir, elle a été implémentée pour pousser directement la vidéo pure fmp4 vers les navigateurs prenant en charge MSE (Media Source Extensions, actuellement non pris en charge par Safari sur iOS. ). Jouez et l’audio sera ajouté plus tard.

Mise à jour du 25/06/2018 :

La fonction de base consistant à pousser fmp4 est pratiquement terminée. Certains internautes ont poussé un PR prenant en charge les statistiques au format JSON. Je l'ai essayé et je l'ai trouvé très bien. Un petit bug a également été corrigé.

Mise à jour du 29/06/2018 :

Modifier les informations rtmp d'origine dans stat en http-flv Compte tenu du fait que deux fabricants ont officiellement commercialisé RTMP (activer gop_cache) et HTTP. -FLV (sans gop_cache activé), la version 1.2.4 du jalon a été publiée.

Mise à jour le 09/07/2018 :

Correction de 3 petits bugs : lors de l'activation de la fonction DASH, cela peut provoquer une boucle infinie car les données lues dans le fichier sont 0, corrigez le ; méthode xml Le problème selon lequel le numéro de version de nginx-http-flv-module ne peut pas être affiché dans les statistiques (PR d'un internaute) ; correction du bug de retour de 405 (méthode non autorisée) lorsque la requête HEAD ne configure pas les emplacements flv_live

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!