Faible latence DASH Nginx RTMP

J’utilise arut nginxrtmp-module ( https://github.com/arut/nginx-rtmp-module ) sur le serveur multimédia, puis j’ai essayé de diffuser en utilisant FFmpeg dans l’application de dash , puis je teste le stream en le lisant en utilisant VLC.

Et il attend environ 30 secondes pour commencer à jouer, et il joue depuis le début, pas l’horodatage actuel.

Ceci est ma configuration actuelle sur le bloc RTMP

 rtmp { server { listen 1935; application live { live on; exec ffmpeg -re -i rtmp://localhost:1935/live/$name -c:a libfdk_aac -b:a 32k -c:v libx264 -b:v 128K -f flv rtmp://localhost:1935/hls/$name_low -c:a libfdk_aac -b:a 64k -c:v libx264 -b:v 256k -f flv rtmp://localhost:1935/hls/$name_mid -c:a libfdk_aac -b:a 128k -c:v libx264 -b:v 512K -f flv rtmp://localhost:1935/hls/$name_hi -c:a libfdk_aac -b:a 128k -c:v libx264 -b:v 512K -f flv rtmp://localhost:1935/dash/$name_dash; } application hls { live on; hls on; hls_path /tmp/hls; hls_nested on; hls_variant _low BANDWIDTH=160000; hls_variant _mid BANDWIDTH=320000; hls_variant _hi BANDWIDTH=640000; } application dash { live on; dash on; dash_path /tmp/dash; dash_nested on; } } } 

C’est la commande que j’utilise pour le streaming

 ffmpeg -re -i 2014\ SPRING.mp4 -c copy -f flv rtmp://52.221.221.163:1935/dash/spring 

Comment puis-je réduire le délai et le faire jouer du même horodatage que le streamer?

Puis-je atteindre une latence inférieure à 5 s?

METTRE À JOUR

Essayé de changer la longueur de la liste de lecture et la longueur du fragment, en utilisant cette directive

 dash_playlist_length 10s; dash_fragment 2s; 

Mais il y a toujours un problème de latence, parfois plus petit qu’avant, parfois même

Puis-je atteindre une latence inférieure à 5 s?

Non. DASH est un protocole segmenté, ce qui signifie que votre média est découpé en gros morceaux. Le joueur doit télécharger des morceaux avant de pouvoir les lire. Votre encodeur doit télécharger des morceaux entiers avant que ces blocs n’apparaissent dans le manifeste. Ceci est le mauvais outil pour le travail, et toute tentative de réduire la latence en augmentant la taille du bloc ajoute énormément de temps à votre projet. Vous utilisez le mauvais outil pour le travail si la latence est importante pour vous .

Comment puis-je réduire le délai et le faire jouer du même horodatage que le streamer?

Vous ne pouvez pas. La physique! Il est impossible pour vous de jouer la même chose exactement au même moment qu’en cours d’encodage. Vous envoyez des données sur un réseau à commutation de paquets, avec de nombreuses étapes de codage / décodage, qui nécessitent toutes un tampon lorsqu’elles fonctionnent par blocs. Le seul moyen de lire simultanément ce qui arrive est de passer en mode analogique … au moins, votre seul retard est la vitesse de la lumière.

Le mieux que vous puissiez faire est de passer à un protocole conçu pour une faible latence, comme WebRTC. Assurez-vous de bien comprendre les compromis. Vos codecs seront optimisés pour la latence, pas pour la qualité… votre qualité en souffrira. WebRTC sur UDP (facultatif mais commun) signifie que certains paquets seront perdus, ce qui affectera votre expérience de visualisation. Lorsque vous vous souciez de la latence, cela n’a pas d’importance si vous perdez un morceau ici ou là, ce qui compte, c’est que vous continuiez. Vous pouvez utiliser WebRTC sur TCP et conserver votre fiabilité avec une légère augmentation de la latence.

Décidez ce qui compte vraiment pour vous. Dans presque tous les cas, la latence n’est pas faible. Vous ne pouvez pas tout avoir. Il y a des compromis à chaque approche. Vous devez décider ce qui convient le mieux à votre situation spécifique.

J’ai également le même problème avec le lecteur multimédia VLC. La plupart du temps de latence est dû au lecteur client, vous pouvez utiliser le lecteur sans tampon pour le vérifier.

 ffplay -fflags nobuffer rtmp://192.168.1.66/myapp/live 

Les résultats de la mienne,

  • latence de VLC: 6 ~ 7s
  • latence de ffplay: 500ms

Pour plus de détails, reportez-vous au commentaire de narlex sur la façon de réduire la latence sur github

Vous devrez peut-être modifier la taille du GOP dans la commande ffmpeg. La taille par défaut de GOP pour ffmpeg est 250, ce qui signifie qu’il y aura une image clé toutes les 250 images. Si votre sortie est de 25 images par seconde, vous aurez une image clé toutes les 10 secondes dans le pire des cas (si la détection de découpe de scène est activée, vous pouvez avoir un intervalle plus court).

Pour HLS et DASH, les segments doivent commencer par une image clé. Donc, vous aurez beaucoup de segments avec une durée de 10 secondes. Vous devez réduire la durée du segment (la taille du GOP) afin de réduire la latence.

Essayez de modifier votre commande ffmpeg comme suit pour voir si cela vous aide

 exec ffmpeg -re -i rtmp://localhost:1935/live/$name -c:a libfdk_aac -b:a 32k -c:v libx264 -g 50 -b:v 128K -f flv rtmp://localhost:1935/hls/$name_low -c:a libfdk_aac -b:a 64k -c:v libx264 -g 50 -b:v 256k -f flv rtmp://localhost:1935/hls/$name_mid -c:a libfdk_aac -b:a 128k -c:v libx264 -g 50 -b:v 512K -f flv rtmp://localhost:1935/hls/$name_hi -c:a libfdk_aac -b:a 128k -c:v libx264 -g 50 -b:v 512K -f flv rtmp://localhost:1935/dash/$name_dash;