Comparaison des solutions de vidéo-streaming sur Raspberry Pi 2

Description du contexte d'expérimentation

La plate-forme offrant un CPU quad-core, il est évident qu'une occupation à 25% (constaté à l'aide de la commande top par exemple) correspond à un des 4 coeurs monopolisé pour cela. Mais bien il en reste 3 pour faire tout le reste, ce qui laisse largement de marge. Donc plutôt que de focaliser uniquement sur l'occupation CPU, je me suis attaché à regarder les performances pour avoir le rendu avec le meilleur taux de rafraîchissement et avoir le moins de latence possible.

Contrairement aux tests réalisés sur Raspberry Pi 1, j'ai réalisé ceux-ci avec une résolution maximale (1920x1080) à 25 fps. Pour toutes les installations nécessaires, j'ai repris la même procédure que pour les tests précédents sur Raspberry Pi 1.

Installation de nouveaux outils pour réaliser le streaming vidéo avec d'autres protocoles

Tests

J'ai tout d'abord modifié la configuration par défaut /etc/uv4l/uv4l_raspicam.conf pour mettre les valeurs par défaut suivantes:

encoding = h264
width = 1920
height = 1080
framerate = 25

nopreview = yes

sudo service uv4l_raspicam restart

Après un redémarrage du service, j'ai réalisé les tests en modifiant le fichier monitor.sh en mettant une mesure toutes les secondes pendant 30 secondes.

J'ai ensuite analysé les performances de différentes méthodes de streaming vidéo en prenant la charge d'un enregistrement (sans streaming) de la vidéo dans un fichier. Ceci afin d'avoir une référence de comparaison pour les différentes solutions de streaming.

Enregistrement Live dans un fichier

sudo service uv4l_raspicam restart
dd if=/dev/video0 of=video.h264 bs=1M & pid=$! ; sleep 35; kill $pid

motion

width 1920
height 1072
framerate 25

LD_PRELOAD=/usr/lib/uv4l/uv4lext/armv6l/libuv4lext.so motion -c motion.conf

mjpeg-Streamer

LD_PRELOAD=/usr/lib/uv4l/uv4lext/armv6l/libuv4lext.so mjpg_streamer -i "/usr/local/lib/input_uvc.so -d /dev/video0 -r 1920x1080 -f 25" -o "/usr/local/lib/output_http.so -p 9000 -w /usr/local/www"

vlc et RTSP

LD_PRELOAD='' cvlc v4l2:///dev/video0 --v4l2-width 1920 --v4l2-height 1080 --v4l2-chroma h264 --sout '#rtp{sdp=rtsp://:8554/}'

uv4l et WebRTC

Après avoir testé plusieurs solutions avec uv4l, la visualisation dans un navigateur (Firefox en l'occurrence) permet de voir la vidéo, mais déclenche le téléchargement au bout de question secondes. Cela peut donc difficilement être considéré comme une solution pour notre problème. La solution retenue est WebRTC qui est un protocole compatible HTML5 et qui permet un streaming avec de très bonnes caractéristiques (faible temps de latence, très haute résolution, mais si cela consomme du CPU).

Pour installer uv4l, il est nécessaire d'ajouter une nouvelle source à votre fichier /etc/apt/sources.list

deb http://www.linux-projects.org/listing/uv4l_repo/raspbian/ wheezy main

Une fois cet ajout réalisé, il ne reste plus qu'à ajouter la clé de signature des nouveaux paquetages et à installer ceux-ci.

curl http://www.linux-projects.org/listing/uv4l_repo/lrkey.asc | sudo apt-key add -
sudo apt-get update
sudo apt-get install uv4l uv4l-raspicam uv4l-raspicam-extras uv4l-server uv4l-webrtc

Attention: ce dernier paquetage (uv4l-webrtc) n'est utilisable que sur une Raspberry Pi 2. Le paquetage uv4l-raspicam-extras permet la mise en place d'un service pour le démarrage, l'arrêt et la configuration par défaut de uv4l.

Après avoir modifié la configuration dans le fichier /etc/uv4l/uv4l.conf (???), nous pouvons relancer le service.

sudo service uv4l_raspicam restart

Il ne vous reste plus qu'à vous connecter sur votre Raspberry à l'adresse suivante pour tester la configuration de la caméra et lancer la visualisation à l'aide de WebRTC: http://rov.local:8080/.

Après test et vérification sur les forums, pour le moment, la résolution maximale avec WebRTC est 640x480. C'est vraiment dommage pour une caméra qui peut monter en full HD.

Résultats

Après avoir testé toutes les solutions décrites ci-dessus, les résultats sont donnés dans le graphique ci-dessous. J'ai fait un enregistrement à partir de la caméra directement sur la carte SD pour faire une référence de mesure. Cela montre que l'enregistrement en direct n'a pas de latence et consomme très peu de CPU. Les différentes autres solutions ont été comparées à cette capture vidéo, sans la partie streaming.