Actuellement, je pousse un flux RTMP vers nginx 1.15.3 fonctionnant sous Ubuntu 18.04 LTS à partir d'une caméra framboise pi 3 (qui semble bien fonctionner seul, je peux extraire le flux sans problème sur VLC et vérifier qu'il fonctionne ) avec le pi en utilisant cette commande:
raspivid -w 640 -h 480 -fps 5 -t 0 -b 1800000 -o - | ffmpeg -y -framerate 5 -f h264 -i - -c:v copy -map 0:0 -f flv -rtmp_buffer 100 -rtmp_live live rtmp://10.2.10.149/cam01/test
Si je définissais l'argument fps sur raspivid à 25 et éliminais ensuite l'argument ffmpeg framerate, cela le traduirait parfaitement en un flux HLS avec cette commande exécutée sur le serveur nginx:
ffmpeg -i rtmp://10.2.10.149/cam01/test -vcodec libx264 -vprofile baseline -acodec h264 -strict -2 -f flv rtmp://10.2.10.149/show1/stream1
Cependant, j'en ai besoin à la fréquence d'images inférieure et il semble que tenter de le faire bouleverse ffmpeg, car il entraînera un déséquilibre important du flux. Je soupçonne que cela a quelque chose à voir avec ffmpeg ayant un framerate par défaut de 25 ou quelque chose, parce que dans le flux RTMP, si je devais essayer de définir uniquement l'argument fps dans raspivid à 5 et de ne pas inclure l'argument framerate dans ffmpeg, alors attachez la vidéo pendant quelques secondes, puis exécutez-la cinq fois plus vite que ffmpeg, car ffmpeg semble toujours vouloir lancer une vidéo à 25 ips.
Mettre l'argument du nombre d'images par seconde dans la commande de conversion ffmpeg semble aggraver les choses et je ne comprends pas pourquoi cela ne fonctionne pas, car il semble bien fonctionner pour beaucoup d'autres personnes. J'ai principalement utilisé ce guide pour essayer de m'aider à configurer nginx et autres choses encore: https://docs.peer5.com/guides/setting-up-hls-live-streaming-server-using-nginx/#4 -pushing-live-stream-to-nginx-using-rtmp
Je vais également mettre mon nginx.conf ici pour que tout le monde puisse le voir, et notez que je rencontre ce problème chaque fois que j'essaie d'extraire la vidéo via une page Web ou que VLC reçoit directement le flux de réseau:
worker_processes auto;
events {
worker_connections 1024;
}
# RTMP configuration
rtmp {
server {
listen 1935; # Listen on standard RTMP port
chunk_size 4096;
application show1 {
live on;
# Turn on HLS
hls on;
hls_path /mnt/hls1/;
hls_fragment 3;
hls_playlist_length 60;
}
application show2 {
live on;
# Turn on HLS
hls on;
hls_path /mnt/hls2/;
hls_fragment 3;
hls_playlist_length 60;
}
application show3 {
live on;
# Turn on HLS
hls on;
hls_path /mnt/hls3/;
hls_fragment 3;
hls_playlist_length 60;
}
application show4 {
live on;
# Turn on HLS
hls on;
hls_path /mnt/hls4/;
hls_fragment 3;
hls_playlist_length 60;
}
application show5 {
live on;
# Turn on HLS
hls on;
hls_path /mnt/hls5/;
hls_fragment 3;
hls_playlist_length 60;
}
application show6 {
live on;
# Turn on HLS
hls on;
hls_path /mnt/hls6/;
hls_fragment 3;
hls_playlist_length 60;
}
application show7 {
live on;
# Turn on HLS
hls on;
hls_path /mnt/hls7/;
hls_fragment 3;
hls_playlist_length 60;
}
application cam01 {
live on;
record off;
}
application cam02 {
live on;
record off;
}
application cam03 {
live on;
record off;
}
application cam04 {
live on;
record off;
}
application cam05 {
live on;
record off;
}
application cam06 {
live on;
record off;
}
application cam07 {
live on;
record off;
}
}
}
http {
sendfile off;
tcp_nopush on;
default_type application/octet-stream;
server {
listen 80;
server_name localhost;
location / {
# Disable cache
add_header 'Cache-Control' 'no-cache';
# CORS setup
add_header 'Access-Control-Allow-Origin' '*' always;
add_header 'Access-Control-Expose-Headers' 'Content-Length';
# allow CORS preflight requests
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Max-Age' 1728000;
add_header 'Content-Type' 'text/plain charset=UTF-8';
add_header 'Content-Length' 0;
return 204;
}
types {
application/dash+xml mpd;
application/vnd.apple.mpegurl m3u8;
video/mp2t ts;
}
root /mnt/;
location /index.html {
default_type "text/html";
}
location /testing.html {
default_type "text/html";
}
location /test.html {
default_type "text/html";
}
location /cam01.html {
default_type "text/html";
}
location /cam02.html {
default_type "text/html";
}
location /cam03.html {
default_type "text/html";
}
location /cam04.html {
default_type "text/html";
}
location /cam05.html {
default_type "text/html";
}
location /cam06.html {
default_type "text/html";
}
location /cam07.html {
default_type "text/html";
}
}
}
}
Si j'ai besoin d'inclure plus de détails, n'hésitez pas à me le faire savoir, je dois juste que cela fonctionne correctement au lieu de tous les problèmes que je viens d'expliquer, toute aide sera appréciée, merci.
Edit 1: Je remarque également qu'au-dessus des accrochages et des coupures du flux utilisant la deuxième commande, comme décrit précédemment, il semble parfois rester "bloqué" sur une certaine image, ne sachant pas si cela est plus utile ou non. , je voulais juste m'assurer que j'ai toutes les informations que je peux ici.
Edit 2: Je commence à croire que c’est davantage un problème avec nginx car lorsque je pointe la première commande sur l’emplacement / show1 / stream1 qui convertit le rtmp en hls sans exécuter la deuxième commande que j’ai jugée tout à fait nécessaire, Je reçois exactement le même problème de la même manière. Je ne connais pas grand chose à nginx et rien de ce que je trouve en ligne ne m'aide beaucoup. J'apprécierais beaucoup la perspicacité, je sais que son aura toujours un grand retard et que ce n'est pas ce que je demande à réparer, je demande à réparer les découpes et l'attelage.
Edit 3: J'ai peut-être un peu craqué cela, j'ai remarqué sur la commande raspivid, que régler le débit plus élevé semblait atténuer ce problème, cependant, même si je fixais le débit à un taux absurde ou même pas si absurde, mais excessif , il est toujours possible de découper quelques images au hasard toutes les deux minutes et je ne sais pas trop pourquoi. J'apprécierais toute idée.