Étiquette : streaming

Catégories
Gstreamer Hardware Open-source Planet-libre Video

Streaming depuis la Raspberry Camera

Après une rapide présentation de la Raspberry Camera 5M (voir ce précédant billet), entrons dans le vif du sujet avec une utilisation pratique: le streaming « live » du flux vidéo vers une autre machine de votre réseau. Les applications peuvent aller d’un « baby video phone » à  un « interphone vidéo » pour votre maison en passant par toutes les autres choses qui vous passent par la tête !

Actuellement, la camera dispose d’un logiciel spécifique Raspivid (dont les sources sont disponibles sur Github), pour capturer et encoder en H.264 la vidéo dans un fichier ou bien sur le flux standard de sortie (stdout). C’est cette dernière particularité que nous allons exploiter afin de rediriger le flux vidéo vers une pipeline GStreamer qui va s’occuper du streaming vers notre machine cible (celle ou l’on souhaite voir la vidéo).

Installation des composants GStreamer

On commence par installer GStreamer sur notre Raspberry PI. Pour cela on saisi la commande suivante:

sudo apt-get install gstreamer-tools gstreamer0.10-plugins-base gstreamer0.10-plugins-good gstreamer0.10-plugins-bad gstreamer0.10-plugins-ugly

L’installation va prendre un certain temps. Passiensa !

Pour vérifier que les composants ont été correctement installé, saisir la commande suivante:

gst-inspect

Qui devrait afficher les chiffres suivants (qui peuvent varier légèrement selon votre configuration):

Total count: 233 plugins, 695 features

Lancement de la diffusion (streaming) sur le Raspberry

On utilise la pipeline suivante:

raspivid -t 0 -w 1280 -h 720 -fps 25 -b 2500000 -p 0,0,640,480 -o - | gst-launch -v fdsrc ! h264parse ! rtph264pay config-interval=1 pt=96 ! gdppay ! tcpserversink host=192.168.0.9 port 5000

Détaillons un peu cette ligne de commande. La première partie est dédiée à Raspvid et s’occupe de l’encodage H.264. Les paramètres sont très importants pour avoir une qualité vidéo conforme à vos besoins. Ainsi, dans mon exemple, je n’y suis pas allé avec le dos de la cuillère car j’ai opté pour une résolution HD 720p (-w 1280 -h 720) à 25 images par seconde (-fps 25) pendant un temps infini (-t -1).

Pour le streaming, le paramètre de débit (bitrate, -b 2500000) est primordial car il va fixer le débit sortant de la vidéo (à 2.5 Mbps dans mon exemple).

Ce débit est à adapté selon votre résolution. Après quelques tests, voici une table indicative des débits à utiliser:

  • SD Low: -w 480 -h 260 -fps 25 -b  800000
  • SD Medium: -w 640 -h 360 -fps 25 -b  1200000
  • SD High: -w 960 -h 540 -fps 25 -b  1800000
  • HD Ready: -w 1280 -h 720 -fps 25 -b  2500000
  • Full HD: -w 1920 -h 1080 -fps 25 -b  5000000

Note: attention au dimensionnement de votre réseau si vous utilisez des débits élevés, en effet même avec des bornes Wifi ressentes, il est difficile de garder un débit constant de 5 Mbps (Full HD).

Note 2: sur le Raspberry, je conseille d’utiliser l’interface Ethernet et pas un dongle Wifi, surtout avec des résolutions importantes.

La commande passe ensuite la main à GStreamer qui va encapsuler le flux H.264 dans un conteneur RTP puis créer le serveur TCP en écoute des clients (il faudra penser à remplacer l’adresse IP par celle de votre Raspberry Pi).

Lecture de la vidéo depuis une autre machine

J’ai fait le test depuis mon portable Ubuntu 13.04 en saisissant la ligne de commande suivante pour récupérer et afficher la vidéo:

gst-launch-1.0 -v tcpclientsrc host=192.168.0.9 port=5000  ! gdpdepay ! rtph264depay ! avdec_h264 ! videoconvert ! autovideosink sync=false

La qualité de la vidéo est très bonne, fluide. On note quelques retard quand on sollicite le réseau en parallèle mais cela semble normal vu les débits utilisés.

Lecture streaming Raspberry Pi Camera 720p

Ce qui est très impressionnant au niveau du Raspberry, c’est la faible consommation CPU. En effet, Raspivid ne dépasse pas les 2% (merci le GPU) et GStreamer les 25%. On peut sans aucun problème laisser tourner le tout sans risque de surchauffe.

Conclusion

J’espère que cette rapide introduction sur le streaming vidéo depuis le Raspberry vous a donné des idées que vous aller vous empresser de nous faire partager dans les commentaires ci-dessous !

Retrouvez mes articles sur l’écosystème Raspberry Pi en cliquant ici.

Catégories
Gstreamer Musique Open-source Planet-libre

Streaming audio haute qualité avec AAC

Le codec AAC (Advanced Audio Coding dont les fichiers portent souvent l’extension. MP4) est devenu au moins aussi populaire que le bon vieux MP3. Le fait que ce soit le codec audio utilisé par iTunes, le leader mondial de la vente en ligne, n’y est surement pas étranger.

Nous allons dans ce billet voir que l’on peut également utiliser ce codec lors de streaming. Je ne suis pas le premier à avoir cette idée car l’AAC est déjà utilisé pour la diffusion de la radio numérique Japonaise.

On ne change pas une équipe qui gagne, nous allons utiliser le framework GStreamer pour faire ce petit test de streaming audio entre deux machines. Pour ceux qui ne sont pas habitués à la notion de pipeline GStreamer, je vous conseille la lecture de ce billet.

Que cherche t’on à faire ?

Nous allons essayer de diffuser (« streamer ») un flux audio (par exemple un .WAV non compressé pour être sûr d’avoir une source de bonne qualité) depuis une machine A vers une machine B (reliées par un réseau IP) en utilisant un encodage AAC-LC et une encapsulation MPEG-4 / RTP.

Création de la pipeline d’émission

Si vous avez bien suivi, la commande suivante doit être saisie sur la machine A:

gst-launch -tv \

gstrtpbin name=rtpbin latency=0 buffer-mode=0 \

filesrc location=\ »samples/test.wav\ » ! decodebin ! audioconvert \

! queue ! faac bitrate=128000 ! rtpmp4apay \

! rtpbin.send_rtp_sink_1 \

rtpbin.send_rtp_src_1 ! udpsink port=6969 host=$IP_B

Bien que fait cette commande:

  1. elle lance GStreamer (gst-launch)
  2. Elle produit un flux réseau RTP (gstrtpbin)
  3. La source audio du flux réseau RTP sera un fichier WAV (filesrc), qui sera décodé (decodebin)
  4. On encode en AAC en utilisant le plugin faac (basée sur FAAC l’implémentation libre du codec AAC) en fixant un débit réseau cible de 128Kbps (128000 bits). On utilisera ainsi un streaming de type CBR (constant bitrate), c’est à dire que l’on fixe le débit et que le codec s’arrange pour adapter la qualité
  5. On encapsule le résultat dans une trame RTP MP4 Audio (rtpmp4apay)
  6. On stream en UDP (udpsink) vers la machine $IP_B  (à remplacer par l’adresse IP de la machine B) et sur le port 6969

Création de la pipeline de réception

A saisir sur la machine… B (bravo vous avez gagné une partie gratuite):

gst-launch -tv \

udpsrc port=6969 caps= »application/x-rtp, media=(string)audio, clock-rate=(int)16000, encoding-name=(string)MP4A-LATM, cpresent=(string)0, payload=(int)96, config=(string)40002810″ \

! gstrtpjitterbuffer latency=200 drop-on-latency=true ! rtpmp4adepay ! faad \

! audioconvert ! audioresample ! autoaudiosink

Que fait cette commande:

  1. Elle lance GStreamer (gst-launch)
  2. Elle écoute sur le port UDP port 6969 en filtrant les paquets RTP MP4A (udpsrc). La valeur a mettre dans la string config varie selon la fréquence d’échantillonnage de votre source. Elle est affichée lors du lancement de la pipeline A.
  3. Elle bufferise les paquets dans un buffer qui aura une taille maximale de 200ms (à adapter selon la qualité de votre réseau entre A et B). Si les paquets sortes de ce buffer avec plus de 200ms, ils seront dropés (donc perte de paquets, perte d’information, perte de son…).
  4. On décode le paquet RTP (rtpmp4adepay)
  5. On décode le flux audio AAC (faad)
  6. On joue le son sur le périphérique de sorti audio standard (autoaudiosink)

Résultat des tests

Après avoir fait mumuse avec des sources différentes (musique, voix…) et des débits plus ou moins importants (de 8 à 320 Kbps). On arrive à des résultats très intéressants.

Par exemple pour de la voix (« Pierre si tu m’entends 🙂 »), on arrive à une qualité tout à fait acceptable en réglant un bitrate de 16bps pour un flux à 16KHz.

Pour la musique, point de salut en dessous de 128 Kbps (à moins de se contenter d’une qualité vraiment médiocre). A 256 Kbps, on a une qualité qui correspond à une écoute depuis un fichier .MP4 téléchargé sous iTunes Store. Au dessus de 256 Kbps, je n’ai pas noté d’amélioration (mais je n’avais pas un périphérique de sorti de très grande qualité).

Catégories
Gstreamer Open-source Planet-libre Video Web

Un serveur RTSP basé sur GStreamer

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 640×360 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 !

Catégories
Gstreamer Open-source Planet-libre Video

Streaming live MPEG-4 entre Windows et Linux avec GStreamer

Nous allons dans ce billet aborder un sujet plutôt inhabituel pour ce blog: Windows 🙂 !

Le but étant de récupérer un flux vidéo live (venant par exemple d’une caméra) à partir  d’une machine sous Windaube (Xp, Se7en ou autres trucs dans le genre) vers une autre machine (Linux mais aussi Mac ou Windows). Pour cela, nous allons utiliser le framework open-source GStreamer qui va permettre d’unifier tout ce beau monde.

Avant de commencer

Pour illustrer cet article nous allons faire un streaming live depuis une machine Windows Xp vers une machine GNU/Linux Fedora 14 connecté sur le même réseau LAN.

On commence donc par installer GStreamer sur la machine Windows en récupérant et installant la dernière version à partir du site WinBuilds. Je parts sur le principe ou votre Gstreamer est installé dans le répertoire C:\Program Files\OSSBuild\GStreamer\v0.10.6 (si ce n’est pas le cas, il suffit d’adapter le script .BAT, variable GSTPATH, en conséquence).

Ensuite on installe Gstreamer sur son PC GNU/Linux (procédure ici pour Fedora et là pour Ubuntu).

Ok, on a donc le framework GStreamer installé sur les deux machines que nous allons utilisé pour faire nos tests.

Streaming depuis Windows

On commence par éditer un fichier texte (Notepad est ton ami) que l’on va nommer client.bat contenant:

REM

REM Streaming from WebCam + MPEG4-ISO encoding + RTP + UDP

REM

 

set GSTPATH= »C:\Program Files\OSSBuild\GStreamer\v0.10.6″

set CAPS= »video/x-raw-yuv,width=(int)640,height=(int)480,framerate=(fraction)10/1″

set STREAMTO= »192.168.0.10″

set STREAMPORT=5000

 

%GSTPATH%\bin\gst-launch.exe -tv –gst-plugin-path=%GSTPATH%\lib ^

gstrtpbin name=rtpbin latency=0 buffer-mode=0 ^

autovideosrc ! ffmpegcolorspace ^

! queue ! videoscale method=1 ! videorate ! %CAPS% ^

! timeoverlay ^

! queue ! ffenc_mpeg4 pass=0 bitrate=256000 rc-buffer-aggressivity=99 trellis=0 ^

! tee name= »display » ^

! rtpmp4vpay send-config=true ^

! rtpbin.send_rtp_sink_0 ^

rtpbin.send_rtp_src_0 ! udpsink port=%STREAMPORT% host=%STREAMTO% ^

display. ^

! queue ! decodebin ! ffmpegcolorspace ! autovideosink

 

pause

Il faut adapter les deux lignes set à votre configuration sachant que STREAMTO doit être associé à l’adresse IP de votre machine cible (la machine Fedora 14 dans mon cas) et que la résolution de votre Webcam doit être compatible avec les valeur de CAPS.

On exécute ensuite le fichier .bat (une fenêtre CMD va s’ouvrir et afficher les éventuels message d’erreurs).

La ligne de commande qui va s’occuper de l’encodage MPEG-4 est la suivante:

ffenc_mpeg4 pass=0 bitrate=256000 rc-buffer-aggressivity=99 trellis=0

Le paramètre bitrate (256 Kbps) va fixer le débit cible du streaming. Cette valeur est bien sur à adapter selon la résolution et la fréquence (fps) de votre source vidéo.

L’encapsultation dans une trame RTP est faite grâce à la commande:

rtpmp4vpay send-config=true

L’option send-config (=true)  permet à Gstreamer d’envoyer régulièrement sur le réseau (trame RTP) des informations sur les caractéristiques du stream au lieu de les envoyer seulement au début de la session.

Réception du stream depuis GNU/Linux

C’est (un peu) plus simple, on va créer un shell script server.sh:

#!/bin/sh

 

CAPS= »application/x-rtp,media=\(string\)video,clock-rate=\(int\)90000,encoding-name=\(string\)MP4V-ES,payload=\(int\)96″

PORT=5000

 

gst-launch -tv gstrtpbin name=rtpbin latency=0 buffer-mode=0 \

udpsrc caps=$CAPS port=$PORT do-timestamp=true \

! rtpbin.recv_rtp_sink_0 \

rtpbin. ! rtpmp4vdepay ! ffdec_mpeg4 ! autovideosink

Une fois le script édité, il faut le rendre exécutable:

chmod a+x server.sh

Puis executer le script pour recevoir le stream venant du PC Window

./server.sh

Et si on veut ajouter du son ?

Il suffit d’adapter les pipelines ! A tittre d’exemple, vous pouvez consulter les scripts suivants:

J’ai également essayé d’utiliser le codec X.264 (x264enc + x264dec) succés pour l’instant (qualité très mauvaise).

Catégories
Gstreamer Open-source Video Web

Configuration pas à pas d’un serveur de streaming Flumotion

Flumotion est un projet de serveur de streaming vidéo open-source distribué sous licence GPL. Développé en Python et basé sur les frameworks Twisted et GStreamer, il permet de diffuser sur un réseau des vidéos venant de sources lives (caméra, tv…) ou stockées dans des fichiers (on parle alors de VoD pour Video à la demande) en proposant un interface utilisateur de type Web (vous pouvez voir une démo ici).

Lire la suite « Configuration pas à pas d’un serveur de streaming Flumotion »

Catégories
Gstreamer Open-source Reseau Video

Streaming vidéo SD avec Gstreamer

Nous allons dans ce billet essayer d’optimiser le streaming d’un flux SD sur un réseau local (LAN de 100 Mbps) en utilisant le framework GStreamer.

Environnement des tests

Deux PC Ubuntu connectés sur un même switch (100 Mbps full-duplex).

  • PC serveur: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz / 2 Go RAM
  • PC client: Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz / 1 Go RAM

GStreamer version 0.10.25.

Vidéo source: Big Buck Bunny 480p

Tests avec le codec X.264

Ligne de commande sur la machine générant le streaming (serveur):

serveur> gst-launch -v \ filesrc location= »../Vidéos/big_buck_bunny_480p_stereo.ogg » \ ! queue ! decodebin \ ! queue ! videoscale method=1 ! video/x-raw-yuv,width=854,height=480 \ ! queue ! videorate ! video/x-raw-yuv,framerate=\(fraction\)24/1 \ ! queue ! x264enc byte-stream=true bitrate=2000 bframes=4 ref=4 me=hex subme=4 weightb=true threads=0 \ ! queue ! rtph264pay \ ! queue ! udpsink port=5000 host=192.168.29.150 sync=false async=false

Ligne de commande sur la machine recevant le streaming (client):

client> gst-launch -v udpsrc caps= »application/x-rtp, media=\(string\)video, clock-rate=\(int\)90000, encoding-name=\(string\)H264, payload=\(int\)96″ port=5000 \
! queue ! rtph264depay \
! queue ! ffdec_h264 ! xvimagesink

Résultat:
Visuel: vidéo saccadé (environ 2 img/sec)
Bande passante mesurée: entre 2 et 3 Mbps
Resource serveur: %CPU=135 / %MEM=5
Resource client: %CPU=10 / %MEM=2

On ajoute un buffer juste avant le depay et le décodage (au niveau du client):

client> gst-launch -v udpsrc caps= »application/x-rtp, media=\(string\)video, clock-rate=\(int\)90000, encoding-name=\(string\)H264, payload=\(int\)96″ port=5000 \
! queue ! gstrtpjitterbuffer latency=3000 \
! queue ! rtph264depay \
! queue ! ffdec_h264 ! xvimagesink

Résultat:
Visuel: vidéo beaucoup plus fluide mais variation de la gigue (accéleration de la video par moment). On a par contre un décalage de 3 secondes, donc inutilisable pour des flux lives.
Bande passante mesurée: entre 2 et 3 Mbps
Resource serveur: %CPU=140 / %MEM=6
Resource client: %CPU=14 / %MEM=2

On modifie ensuite les paramètres d’encodage X.264 (au niveau du serveur):

serveur> gst-launch -v –gst-debug-level=2 \
filesrc location= »../Vidéos/big_buck_bunny_480p_stereo.ogg » \
! queue ! decodebin \
! queue ! videoscale method=1 ! video/x-raw-yuv,width=720,height=480 \
! queue ! videorate ! video/x-raw-yuv,framerate=\(fraction\)24/1 \
! queue ! x264enc vbv-buf-capacity=3000 byte-stream=true bitrate=900 subme=4 ref=2 bframes=1 b-pyramid=true weightb=true \
! queue ! rtph264pay \
! queue ! udpsink port=5000 host=192.168.29.150 sync=false async=false

Résultat:
Visuel: Presque plus de sacade ni de variation de gigue. On a par contre un décalage de 3 secondes, donc inutilisable pour des flux lives.
Bande passante mesurée: entre 2 et 3 Mbps
Resource serveur: %CPU=120 / %MEM=4
Resource client: %CPU=10 / %MEM=2

Catégories
Gstreamer Open-source

J’ai streamé avec GStreamer

Après une introduction à GStreamer qui vous, je l’espère, donné l’eau à la bouche, nous allons poursuivre la découverte de ce superbe framework en nous focalisant sur les fonctions de streaming audio et vidéo.

Avant de commencer à jouer, il faut installer GStreamer et ses composants sur votre machine. Je vous conseille d’installer GStreamer en suivant ce tutoriel. Vous disposerez ainsi des dernières versions des codecs.

Premier streaming vidéo: Theora et UDP

Nous allons dans ce premier exemple diffuser un flux vidéo (venant d’une Webcam) en utilisant le protocole UDP. Nous utiliserons le codec libre Theora (wiki) pour compresser la vidéo.

Sur la machine cliente (celle qui va recevoir et afficher le flux vidéo), il faut saisir la ligne suivante:

# gst-launch -v udpsrc port=1234 ! theoradec ! autovideosink

En clair, GStreamer va écouter le flux vidéo sur le port UDP/1234 (avec udpsrc) puis décompressé le flux Theora (theoradec) et enfin l’afficher sur l’écran (autovideosink).

Sur le serveur (la machine sur laquelle la Webcam est connectée et accessible par /dev/video1), nous allons saisir:

# gst-launch -v v4l2src device=/dev/video1 ! ffmpegcolorspace \
! videoscale method=1 ! video/x-raw-yuv,width=320,height=240,framerate=\(fraction\)15/1 \
! theoraenc bitrate=150 ! udpsink host=127.0.0.1 port=1234

Plusieurs remarques sur cette ligne de commande. On utilise la fonction videoscale pour redimensionner le format d’entrée de la vidéo (en taille et en nombre d’images par seconde) afin de limiter la bande passante. Je force ainsi dans ce cas le codec Theora à 150 Kbps. Enfin, la fonction udpsink permet de diffuser en UDP sur le réseau (port 1234 et adresse destination 127.0.0.1 – celle du client).

Remarque importante: il faut que le client soit lancé avant le serveur.

Streaming vidéo: Theora et TCP

Nous allons modifier légèrement notre premier exemple pour utiliser le protocole TCP en lieu et place du protocole UDP.

Le framework au niveau du client (le poste qui va recevoir le flux vidéo) est:

gst-launch -v tcpserversrc host=127.0.0.1 port=1234 ! decodebin ! autovideosink

GStreamer lance un serveur TCP (en écoute sur le port 1234 de l’adresse 127.0.0.1) et affiche le résultat (on peut utiliser decodebin à la place de theoradec) sur l’écran.

Sur le serveur (la machine avec la WebCam) on lance la commande:

gst-launch -v v4l2src device=/dev/video1 ! ffmpegcolorspace \
! video/x-raw-yuv,width=320,height=240,framerate=\(fraction\)10/1 \
! theoraenc bitrate=200 ! oggmux \
! tcpclientsink host=127.0.0.1 port=1234

On utilise la fonction
videoscale pour redimensionner le format d’entrée de la vidéo (en
taille et en nombre d’images par seconde) afin de limiter la bande
passante. Je force ainsi dans ce cas le codec Theora à 150 Kbps. Enfin,
la fonction tcpclientsink permet de diffuser en TCP sur le réseau (port 1234 et adresse destination 127.0.0.1 – celle du client).

Remarque importante: il faut que le client soit lancé avant le serveur.

Streaming vidéo: Theora et RTP/RTCP

On va compliquer encore un peu plus notre système de streaming en utilisant les protocoles RTP (pour les données) et RTCP (pour les flux de contrôle de ces données).

Contrairement aux deux premiers exemples, il faut lancer le client après le serveur. En effet, il est nécessaire de renseigner, au niveau du client, une chaine de configuration (caps) généré par le serveur.

gst-launch -v  v4l2src \
! videoscale method=1 ! video/x-raw-yuv,width=320,height=240,framerate=\(fraction\)15/2 \
! theoraenc ! rtptheorapay \
! .send_rtp_sink gstrtpsession name=session .send_rtp_src ! udpsink port=5000 host=127.0.0.1  \
session.send_rtcp_src ! udpsink port=5001 host=127.0.0.1

Le serveur va encoder le flux vidéo avec le codec Theora, ajouter les entêtes RTP Theora (rtptheorapay) puis diffuser le flux en UDP (RTP/UDP sur le port 5000) grâce aux plugins gstrtpsession et udpsink. En parallèle, un serveur RTCP (RTCP/UDP) est lancé. Il envoie les information RTCP vers le port 5001 de la machine cliente (127.0.0.1).

Notez le paramètre -v passé à gst-launch. Il est nécessaire pour l’obtention de la chaine de configuration (caps).

Lors du lancement de cette commande, un grand nombre de messages va s’afficher. Il faut récupérer la dernière occurence du type:

caps = application/x-rtp, media=(string) video … seqnum-base=(guint)39194

Nous pouvons alors lancer notre client:

gst-launch udpsrc port=5000 caps= »application/x-rtp, media=(string) video … seqnum-base=(guint)39194 » \
! .recv_rtp_sink gstrtpsession name=session .recv_rtp_src \
! rtptheoradepay !  theoradec ! xvimagesink \
udpsrc port=5001 caps= »application/x-rtcp » ! session.recv_rtcp_sink

Le client écoute le flux de donnée vidéo sur le port UDP/5000. Grâce aux informations fournies dans le champs caps, il peut décoder le flux. On enlève l’entête RTP (rtptheoradepay) puis on décode le flux théora (theoradec) et on affiche. En parallèle, on écoute les flux de contrôle de ces données (RTCP) sur le port 5001 et on les injectent dans le gestionnaire RTP (gstrtpsession).

Streaming vidéo: H.264 et RTP/RTCP

Nous allons modifier l’exemple précedant en remplacant le codec H.264 au lieu de Theora. Pour celà, nous allons utiliser le plugins X.264 (développé par l’équipe VideoLAN).

Contrairement au codec Theora, il n’est pas nécessaire de passer la chaine de configuration « caps » du serveur vers le client.

On a donc la configuration suivante au niveau du serveur (à lancer en premier). Vous pouvez récupérer le script shell correspondant à ici:

WEBCAM_DEV= »/dev/video0″
WEBCAM_WIDTH=352
WEBCAM_HEIGHT=288
WEBCAM_FPS=24
SERVER_IP=$1
SEND_RTP_PORT=5000
SEND_BUFFER=0
X264_BITRATE=600
X264_PARAM= »byte-stream=true bframes=4 ref=4 me=hex subme=4 weightb=true threads=0 sliced-threads=1 vbv-buf-capacity=300″
# With RTCP
SEND_RTCP_PORT=5001
RECV_RTCP_PORT=5002
gst-launch -v  gstrtpbin name=rtpbin \
v4l2src device=$WEBCAM_DEV \
! queue ! videoscale method=1 ! video/x-raw-yuv,width=\(int\)$WEBCAM_WIDTH,height=\(int\)$WEBCAM_HEIGHT \
! queue ! videorate ! video/x-raw-yuv,framerate=\(fraction\)$WEBCAM_FPS/1 \
! queue ! x264enc bitrate=$X264_BITRATE $X264_PARAM ! rtph264pay \
! rtpbin.send_rtp_sink_0 \
rtpbin.send_rtp_src_0 ! udpsink port=$SEND_RTP_PORT host=$SERVER_IP \
rtpbin.send_rtcp_src_0 ! udpsink port=$SEND_RTCP_PORT host=$SERVER_IP sync=false async=false \
udpsrc port=$RECV_RTCP_PORT ! rtpbin.recv_rtcp_sink_0

La seule différence avec l’exemple du chapitre précedant est l’utilisation de l’encodeur X.264 (x264enc qui génére un flux H.264). Pour une description des nombreux paramètres de ce plugin, je vous conseille la lecture de la documentation:

gst-inspect x264enc

La ligne de commande du client est la suivante (la encore vous pouvez récupérer le script shell ici):


RECV_RTP_PORT=5000
RECV_BUFFER=300
CLIENT_IP=$1
RECV_RTCP_PORT=5001
SEND_RTCP_PORT=5002
gst-launch -tv gstrtpbin name=rtpbin latency=$RECV_BUFFER \
udpsrc caps= »application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96″ port=$RECV_RTP_PORT \
! rtpbin.recv_rtp_sink_0 \
rtpbin. ! rtph264depay ! ffdec_h264 ! ffmpegcolorspace ! autovideosink \
udpsrc port=$RECV_RTCP_PORT ! rtpbin.recv_rtcp_sink_0 \
rtpbin.send_rtcp_src_0 ! udpsink port=$SEND_RTCP_PORT host=$CLIENT_IP sync=false async=false

gst-launch -tv gstrtpbin name=rtpbin latency=$RECV_BUFFER \ udpsrc caps= »application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96″ port=$RECV_RTP_PORT \ ! rtpbin.recv_rtp_sink_0 \ rtpbin. ! rtph264depay ! ffdec_h264 ! ffmpegcolorspace ! autovideosink \ udpsrc port=$RECV_RTCP_PORT ! rtpbin.recv_rtcp_sink_0 \ rtpbin.send_rtcp_src_0 ! udpsink port=$SEND_RTCP_PORT host=$CLIENT_IP sync=false async=false


On utilise le décodeur H.264 fourni par FFMpeg (ffdec_h264).

Streaming audio et vidéo: H.264, Speex et RTP/RTCP

Dernier exemple de ce billet qui va streamer un flux vidéo et un flux audio (venant du périphérique de capture standard de votre système). La vidéo sera encodé en H.264 et la vidéo en Speex. Le tout en utilisant le protocole RTP/RTCP.

Le serveur (à lancer en premier). Il faut récupérer la chaine « caps » pour la partie audio Speex.

gst-launch -v  gstrtpbin name=rtpbin \
v4l2src ! videoscale method=1 ! video/x-raw-yuv,width=640,height=480,framerate=\(fraction\)15/2 \
! queue ! x264enc byte-stream=true bitrate=300 vbv-buf-capacity=300 me=0 subme=3 ! rtph264pay \
! rtpbin.send_rtp_sink_0 \
rtpbin.send_rtp_src_0 ! udpsink port=5000 host=127.0.0.1 \
rtpbin.send_rtcp_src_0 ! udpsink port=5001 host=127.0.0.1 sync=false async=false \
udpsrc port=5002 ! rtpbin.recv_rtcp_sink_0 \
alsasrc \
! queue ! speexenc ! rtpspeexpay \
! rtpbin.send_rtp_sink_1 \
rtpbin.send_rtp_src_1 ! udpsink port=5003 host=127.0.0.1 \
rtpbin.send_rtcp_src_1 ! udpsink port=5004 host=127.0.0.1 sync=false async=false \
udpsrc port=5005 ! rtpbin.recv_rtcp_sink_1

Et le client:

gst-launch-0.10 -v gstrtpbin name=rtpbin latency=200 \
udpsrc caps= »application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, profile-level-id=(string)4d4033, sprop-parameter-sets=(string)Z01AM6tAUB7YCIAAAAMBAAADAA9HjBlQ, ssrc=(guint)614294178, payload=(int)96, clock-base=(guint)3718899905, seqnum-base=(guint)59615″ port=5000 \
! rtpbin.recv_rtp_sink_0 \
rtpbin. ! rtph264depay ! ffdec_h264 ! xvimagesink \
udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 \
rtpbin.send_rtcp_src_0 ! udpsink port=5002 host=127.0.0.1 sync=false async=false \
udpsrc caps= »application/x-rtp, media=(string)audio, clock-rate=(int)44100, encoding-name=(string)SPEEX, encoding-params=(string)1, ssrc=(guint)419764010, payload=(int)110, clock-base=(guint)3478167082, seqnum-base=(guint)57894″ port=5003 \
! rtpbin.recv_rtp_sink_1 \
rtpbin. ! rtpspeexdepay ! decodebin ! alsasink \
udpsrc port=5004 ! rtpbin.recv_rtcp_sink_1 \
rtpbin.send_rtcp_src_1 ! udpsink port=5005 host=127.0.0.1 sync=false async=false

Bon stream à vous !

Catégories
Open-source

SwarmPlayer, le streaming P2P libre

SwarpPlayer est un logiciel open-source permettant de streamer des vidéos sur une réseau P2P (bittorent pour ne pas le nommer).

Le but de ce logiciel est de combiner les fonctions suivantes:

  • télécharger une vidéo pour la regarder plus tard (p2p)
  • regarder la vidéo pendant le téléchargement (streaming)
  • regarder une vidéo pendant qu’elle est généré, par exemple depuis une Webcam (live)

Les développeurs (P2P-NeXt consortium) sont en phase de test et demande l’aide de la communauté afin de tester la monté en charge de leur solution.

Donc acte…

Installation de SwarmPlayer

Cette procédure est donnée pour une Ubuntu Hardy. Il existe également une version Windows de SwarmPlayer téléchargeable ici.

cd /usr/src
sudo wget http://ubuntu.p2p-next.org/dists/hardy/main/binary-i386/swarmplayer_1.0.1-1ubuntu1_all.deb
sudo apt-get install python-m2crypto python-wxgtk2.8
sudo apt-get -f install
sudo dpkg -i swarmplayer_1.0.1-1ubuntu1_all.deb

L’installation semble prévu pour une version Anglaise d’Ubuntu, si comme moi votre Ubuntu est en Francais, il faut également changer les droits d’un répertoire (remplacer user par votre login):

cd ~
sudo chown -R user:user Desktop/

Utilisation de SwarmPlayer

Comme pour bittorent a besoin d’un fichier « .bittorrent », SwarmPlayer utilise un fichier « .tstream ». Vous pouvez en deux exemples sur le site:

test de la vidéo à la demande

test de la vidéo live (depuis une caméra)

Une fois ces fichiers téléchargés sur votre disque, il suffit de lancer SwarmPlayer et d’ouvrir un des deux fichiers de test.

/usr/bin/swarmplayer

SwarmPlayer va alors commencer à télécharger la vidéo en P2P:

dés que possible (c’est à dire dès que les buffers sont assez remplis), la vidéo va s’afficher dans votre lecteur vidéo par défaut (VLC dans mon cas):

Comme pour le P2P, plus le nombre d’utilisateurs sera important, plus la qualité vidéo / rapidité de transfert pourra être élévée.

Il est possible, dans les options de définir un débit maximum à ne pas dépasser (histoire de ne pas saturer votre bande passante avec ce flux P2P).

Conclusion

Un nouveau logiciel open-source intéressant, à suivre dans les prochaine version. La version testé (v1.0.1-1) était relativement stable sur mon système et la qualité vidéo assez bonne.

Catégories
Open-source

Flumotion, le streaming libre

Flumotion est un serveur de streaming vidéo et audio libre sous licence GPL. Il a comme principal avantage par rapport à la concurrence d’utiliser le gstreamer, ce qui lui permet d’être multiformats (Ogg, Vorbis, Thetra, MP3 mais aussi Windows Media Player ou Flash). On peut voir une démonstration des capacité de Flumotion sur leur site de démonstration.

On peut « streamer » (diffuser sur le réseau) depuis une source qui peut être une webcam, une caméra vidéo ou Firewire (LIVE) ou bien un fichier (VOD).

Dans ce billet, nous allons détailler l’installation et configurer Flumotion sur un OS GNU/Linux (Ubuntu dans mon cas).

Lire la suite « Flumotion, le streaming libre »