Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.
C’est alors la barrière de la prise en main qui fait peur, et pourtant...
Les logiciels libres
L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.
Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.
Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.
Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.
- Mars 2011 -
Dans le petit monde du streaming vidéo, RTSP est un protocole permettant à un client (lecteur multimédia) de contrôler un serveur (serveur de streaming) en lui envoyant des ordres simples: lire, pause, stop, déplacement temporel (pour avoir une liste des fonctions théoriquement disponibles, vous pouvez lire la RFC 2326). Il est important, pour comprendre la suite de ce billet que le protocole RTSP ne fait pas lui même le streaming vidéo (il utilise pour cela le protocole RTP). RTSP est juste une couche complémentaire permettant de contrôler ce streaming.
Nous allons dans ce billet étudier un serveur basé sur le framework GStreamer. Maintenu par Wim Taymans, un des développeurs de GStreamer, gst-rtsp se compose d'un ensemble de librairies permettant de concevoir simplement son propre serveur RTSP. Pour effectuer des tests, les développeurs fournissent quelques exemples de serveurs.
Installation de gst-rtsp
On commence par récupérer les sources puis à compiler:
mkdir ~/src
cd ~/src
wget http://gstreamer.freedesktop.org/src/gst-rtsp/gst-rtsp-0.10.8.tar.bz2
bzip2 -d gst-rtsp-0.10.8.tar.bz2
tar xvf gst-rtsp-0.10.8.tar
cd gst-rtsp-0.10.8/
./configure
make
Premier streaming RTSP: la mire
On commence par lancer le serveur de test qui va streamer une mire:
cd examples/
./test-readme
Le serveur est maintenant lancé, en écoute sur le port TCP/8554 et l'URL: rtsp://127.0.0.1:8554/test
Note: si vous lancer le client sur une autre machine il faut bien sur remplacer 127.0.0.1 par l'adresse IP (ou le nom d'hôte) de votre serveur.
Si on regarde le code C de ce premier serveur (./test-readme.c), on peut retrouver la pipeline GStreamer qui va s'occuper de diffuser le flux sur le réseau:
videotestsrc is-live=1 ! x264enc ! rtph264pay name=pay0 pt=96
On a donc la génération de la mire avec videotestsrc, puis un encodage H.264 avec x264enc puis enfant un streaming RTP avec rtph264pay.
Pour lire se genre de flux, on peut utiliser plusieurs logiciels. Le plus "populaire" est le très frenchie VLC. On lance donc le logiciel puis on va dans le menu Média / Ouvrir un flux réseau, puis on entre l'URL: rtsp://127.0.0.1:8554/test
Après quelques secondes, la vidéo devrait s'afficher:
On peut aussi utiliser FFplay (le player basée sur FFmpeg):
ffmplay rtsp://127.0.0.1:8554/test
Ou bien directement une pipeline GStreamer, ce qui ouvre la porte à des post traitements:
gst-launch -v rtspsrc location=rtsp://127.0.0.1:8554/test ! queue ! decodebin ! ffmpegcolorspace ! autovideosink
Il est bien sur possible de lancer plusieurs clients vers la même source RTSP (j'ai testé 3 clients en parallèle).
Une mire c'est bien, un fichier MPEG-4 c'est mieux
Les esprits chagrins vont me dire que pour tester les fonctions de seekink (déplacement temporel) avec une mire ce n'est pas terrible... Nous allons donc streamer une vidéo MPEG-4 (j'ai utilisé le logiciel Avidemux pour produire une vidéo de 640x360 en MPEG-4 ISO à partir d'une source Big Buck Bunny 720p AVI).
On va lancer le serveur avec les commandes suivantes (toujours dans le sous répertoires examples):
./test-mp4 ~/big_buck_bunny_360p_surround.mp4
Lecture à partir de VLC:
On a alors, pour cette vidéo, un flux réseau entre le serveur et le client variant entre 350 et 550 Kbps. Ceci est normal car la pipeline suivante que l'on peut trouver dans le fichier test-mp4.c ne fait en fait aucun transcodage. Comme la vidéo n'a pas été encodé en CBR (constant bit rate) on se retrouve avec des variations de débits:
filesrc location=%s ! qtdemux name=d d. ! queue ! rtph264pay pt=96 name=pay0 d. ! queue ! rtpmp4apay pt=97 name=pay1
Coté occupation CPU du coté client je suis à environ 25% sur un Core 2 à 1.8 Ghz.
Capture réseau
Pour les plus curieux d'entre vous, voici le résultat d'une capture réseau entre mon serveur RTSP (192.168.29.79) et un client (192.168.29.148).
On peut notamment y voir la négociation RTSP avec la liste des fonctions disponibles sur le serveur (OPTIONS, DESCRIBE, GET_PARAMETER, PAUSE, PLAY, SETUP, SET-PARAMETER, TEARDOWN) puis le début du streaming RTP.
Conclusion
Bien qu'en développement, ce projet de serveur RTSP basé sur GStreamer est très stable (je n'ai pas rencontré de plantage lors de mes tests) et facile à intégrer dans un développement en C. Si vous voulez faire mumuse et développer votre propre serveur, je vous conseille la lecture du fichier README qui se trouve dans le sous répertoire docs.
A vos serveurs !
Original post of Nicolargo.
Votez pour ce billet sur Planet Libre.
