Manière moderne de diffuser H.264 à partir de la Raspberry Cam

J'ai obtenu le Pi B + et la caméra Pi et j'essaie maintenant de trouver la configuration la plus efficace (faible processeur) et la latence la plus faible pour diffuser la vidéo encodée H.264 de la caméra vers mon serveur domestique.

J'ai lu ce qui suit:

(Tous les liens utilisent gstreamer-1.0 à partir de deb http://vontaene.de/raspbian-updates/ . main.)

Beaucoup a été fait à cet égard au cours des dernières années.

À l'origine, nous devions canaliser la sortie de raspividdans gst-launch-1.0(voir lien 1).

Puis (lien 2) le driver officiel V4L2 a été créé qui est maintenant standard, et il permet d'obtenir directement les données sans pipe, en utilisant juste gstreamer (voir notamment le post de towolf »sam. 07 déc. 2013 15h34 en lien 2):

Expéditeur (Pi): gst-launch-1.0 -e v4l2src do-timestamp=true ! video/x-h264,width=640,height=480,framerate=30/1 ! h264parse ! rtph264pay config-interval=1 ! gdppay ! udpsink host=192.168.178.20 port=5000

Destinataire: gst-launch-1.0 -v udpsrc port=5000 ! gdpdepay ! rtph264depay ! avdec_h264 ! fpsdisplaysink sync=false text-overlay=false

Si je comprends bien, les deux façons utilisent le GPU pour faire le décodage H264, mais ce dernier est un peu plus efficace car il n'a pas besoin de passer par le noyau une autre fois car il n'y a pas de canal entre les processus impliqués.

Maintenant, j'ai quelques questions à ce sujet.

Ce dernier est-il toujours le moyen le plus récent d'obtenir efficacement le H264 de la caméra? J'ai lu gst-omx, ce qui permet aux pipelines gstreamer comme ... video/x-raw ! omxh264enc ! .... Est-ce que cela fait quelque chose de différent que de simplement utiliser video/x-h264, ou pourrait-il même être plus efficace? Quelle est la différence?
Comment savoir quel plugin de codage gstreamer est réellement utilisé lorsque j'utilise le video/x-h264 ...pipeline? Cela semble simplement spécifier le format que je veux, par rapport aux autres parties du pipeline, où je nomme explicitement le composant (code) (comme h264parseou fpsdisplaysink).
Dans cette réponse au lien 1, Mikael Lepistö mentionne "J'ai supprimé une passe de filtre inutile du côté de la diffusion en continu" , ce qui signifie qu'il a supprimé le gdppayet gdpdepay. Que font-ils? Pourquoi sont-ils nécessaires? Puis-je vraiment les retirer?
Il mentionne également qu'en spécifiant des caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96"paramètres pour le udpsrccôté récepteur, il est capable de démarrer / reprendre le streaming au milieu du flux. Que permettent ces plafonds, pourquoi ces choix spécifiques, où puis-je en savoir plus à leur sujet?
Quand je fais ce qui est suggéré aux questions 3 et 4 (ajout de caps, chute gdppayet gdpdepay) alors ma latence vidéo devient bien pire (et semble s'accumuler, la latence augmente avec le temps, et après quelques minutes la vidéo s'arrête)! Pourquoi est-ce possible? Je voudrais obtenir la latence que j'ai obtenue avec la commande d'origine, mais j'ai également la possibilité de pouvoir rejoindre le flux à tout moment.
J'ai lu que RTSP + RTP utilise généralement une combinaison de TCP et UDP: TCP pour les messages de contrôle et d'autres choses qui ne doivent pas être perdus, et UDP pour la transmission de données vidéo réelle. Dans les configurations ci-dessus, est-ce que j'utilise réellement cela, ou est-ce que j'utilise seulement UDP uniquement? C'est un peu opaque pour moi que gstreamer s'en occupe ou non.

J'apprécierais toute réponse à une seule de ces questions!

camera streaming-video raspicam

— nh2
source

L'idée que l'utilisation d'un tuyau |crée un problème dans ce contexte est un morceau incroyable de BS Avez-vous essayé des raspivid | cvlcméthodes? Je n'ai pas eu l'appareil photo depuis très longtemps ou beaucoup de temps pour jouer avec, mais l'utiliser pour produire un flux http (visible sur linux à l'autre extrémité avec vlc) semble fonctionner correctement.

— goldilocks

@goldilocks Je ne dis pas que le tuyau est un "problème", juste qu'il n'est pas nécessaire et qu'il y a des frais généraux, tout comme cat file | grep ...au lieu de grep ... file. Le canal ajoute une autre couche de copie vers et depuis le noyau, qui est facilement mesurable, en particulier sur les périphériques à faible bande passante mémoire. Si gstreamer peut lire directement à partir du fichier du périphérique, pourquoi ne pas l'utiliser? Concernant votre raspivid | cvlcsuggestion: je l'utilisais avant de passer à la solution basée sur gstreamer, elle a jusqu'à 3 secondes de latence de plus que gstreamer (je ne sais pas pourquoi).

— nh2

Oui, il a définitivement une latence. WRT le tuyau, mon point sur le "contexte" est que cela ne peut pas être un goulot d'étranglement ici - les E / S réseau vont être plus lentes, etc. Vous avez raison, cependant, cela peut ajouter un peu au CPU temps. Je ne parierais pas grand-chose; le faire en pleine résolution, cvlcutilise ~ 45%, mais simplement courir dans un tuyau à ce débit de données (en gardant à l'esprit que le tuyau ne le ralentit pas ) déplacerait à peine l'aiguille, je pense. Comme <5%. Ce n'est pas totalement insignifiant si vous voulez le faire aussi efficacement que possible bien sûr ...

— goldilocks

... Je veux juste que personne d'autre ne lise ceci pour avoir l'impression que l'utilisation d'un canal ici pourrait être responsable de problèmes de latence ou d'autres problèmes. C'est un hareng rouge. Ou je peux me tromper;)

— goldilocks

Si c'est l'efficacité que vous recherchez, vous souhaiterez peut-être inclure l'utilisation totale du processeur observée pour diverses méthodes à des résolutions / fréquences d'images spécifiques. Le seul que j'ai essayé est celui- raspivid | cvlclà et c'est 40-50%. Les gens peuvent mieux répondre à une question qui les met au défi d'améliorer un chiffre spécifique. En ce moment, vous demandez beaucoup pourquoi, sans expliquer pourquoi chaque pourquoi est important.

— goldilocks

Réponses:

Les options:

raspivid -t 0 -o - | nc -k -l 1234
raspivid -t 0 -o - | cvlc stream:///dev/stdin --sout "#rtp{sdp=rtsp://:1234/}" :demux=h264
cvlc v4l2:///dev/video0 --v4l2-chroma h264 --sout '#rtp{sdp=rtsp://:8554/}'
raspivid -t 0 -o - | gst-launch-1.0 fdsrc ! h264parse ! rtph264pay config-interval=1 pt=96 ! gdppay ! tcpserversink host=SERVER_IP port=1234
gst-launch-1.0 -e v4l2src do-timestamp=true ! video/x-h264,width=640,height=480,framerate=30/1 ! h264parse ! rtph264pay config-interval=1 ! gdppay ! udpsink host=SERVER_IP port=1234
uv4l --driver raspicam
picam --alsadev hw:1,0

Choses à considérer

latence [ms] (avec et sans demander au client de vouloir plus de fps que le serveur)
CPU inactif [%] (mesuré par top -d 10)
Client CPU 1 [%]
RAM [Mo] (RES)
mêmes paramètres d'encodage
mêmes caractéristiques
- l'audio
- reconnecter
- Client indépendant du système d'exploitation (vlc, webrtc, etc.)

Comparaison:

            1    2    3    4    5    6    7
latency     2000 5000 ?    ?    ?    ?    1300
CPU         ?    1.4  ?    ?    ?    ?    ?
CPU 1       ?    1.8  ?    ?    ?    ?    ?
RAM         ?    14   ?    ?    ?    ?    ?
encoding    ?    ?    ?    ?    ?    ?    ?
audio       n    ?    ?    ?    ?    y    ?
reconnect   y    y    ?    ?    ?    y    ?
any OS      n    y    ?    ?    ?    y    ?
latency fps ?    ?    ?    ?    ?    ?    ?

— utilisateur1133275
source

Pourquoi toutes les valeurs de ce tableau " ?"?

— larsks

@larsks parce que personne ne se soucie de tester et de remplir les données sur ce 'wiki communautaire'

— user1133275

La seule façon moderne de diffuser H264 vers un navigateur est avec UV4L : pas de latence, pas de configuration, avec audio en option, audio / vidéo bidirectionnel en option. Pas de sauce GStreamer magique, mais il est possible d'étendre son utilisation.

— prinxis
source

Étant donné que je souhaite diffuser sur mon serveur et potentiellement sur des smartphones, la diffusion sur un navigateur n'est pas une exigence. De plus, le navigateur peut lui imposer des restrictions supplémentaires (par exemple pas de RTSP, potentiellement pas de TCP sauf si vous utilisez WebRTC, mais c'est compliqué). Mais UV4L semble toujours prometteur. Pourriez-vous créer un lien vers un endroit où je peux lire comment l'utiliser / en extraire les données pour les diffuser sur le réseau?

— nh2

Sainte vache, je pense avoir trouvé la page d'exemple ... cette chose semble pouvoir tout faire ! RTMP, RTSP, streaming HTTPS, WebRTC, "Détection d'objets en temps réel et suivi d'objets + détection de visages" - qu'est-ce que l'enfer ?? Chacun avec quelques drapeaux de ligne de commande simples pour uv4l? Mon pipeline gstreamer semble assez obsolète maintenant! J'ai hâte de tester la latence!

— nh2

Oh non, c'est une source fermée :( Cela le disqualifie pour l'utilisation de la surveillance à domicile que j'avais en tête :(

— nh2

il prend en charge WebRTC, WebRTC bidirectionnel. la latence est ~ 200 ms audio / vidéo, audio moins probablement

— prinxis

@ nh2, le lien semble rompu, avez-vous un emplacement mis à jour pour cette page d'exemple?

— Punit Soni

1.) h264es en streaming sur le réseau (exemple uniquement)

sur le serveur:

raspivid -v -a 524 -a 4 -a "rpi-0 %Y-%m-%d %X" -fps 15 -n -md 2 -ih -t 0 -l -o tcp://0.0.0.0:5001

sur le client:

mplayer -nostop-xscreensaver -nolirc -fps 15 -vo xv -vf rotate=2,screenshot -xy 1200 -demuxer h264es ffmpeg://tcp://<rpi-ip-address>:5001

2.) streaming mjpeg sur le réseau (exemple uniquement)

sur le serveur:

/usr/local/bin/mjpg_streamer -o output_http.so -w ./www -i input_raspicam.so -x 1920 -y 1440 -fps 3

sur le client:

mplayer -nostop-xscreensaver -nolirc -fps 15 -vo xv -vf rotate=2,screenshot -xy 1200 -demuxer lavf http://<rpi-ip-address>:8080/?action=stream

tout cela fonctionne même sur un RPi Zero W (configuré comme serveur)

— sparkie
source

Hé, merci pour votre réponse, qu'est-ce que cela sample onlysignifie?

— nh2

Je voulais dire "ce n'est qu'un exemple". Vous pouvez l'adapter à vos besoins.

— sparkie