Étiquette : gstreamer

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
Blog Musique Open-source Planet-libre Video

Mise à jour de la présentation de GStreamer

Il y a quelques mois, j’avais publié une présentation (au format « Powerpoint ») du framework multimédia GStreamer.

A l’occasion d’une présentation de cette technologie à la commission open-source de la Telecom Valley, j’ai mis à jour cette présentation en l’illustrant avec des exemples de pipelines que je lançais au fur et à mesure de mon exposé.

La nouvelle version (1.2) de cette présentation est disponible au téléchargement aux formats PDF et ODP. Elle est diffusé sous licence Creative Common BY v3.0 comme la totalité des billets de ce blog. Vous pouvez également télécharger les scripts shells contenant les pipelines utilisés lors de la présentation.


La présentation (PDF) / La présentation (ODP) / Les scripts shells d’illustration

Note: l’archive des scripts shells contient également une musique (Carl Phaser – « Domination » sous licence CC BY-NC-SA) et une vidéo (Justin Cone – « Building on the Past » sous licence CC BY-NC 1.0) que j’utilise dans ces pipelines.

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

Vidéo embarquée depuis un véhicule grâce à GStreamer


Ce billet invité a été rédigé par Damien Archenault et Clément Brunel. Merci à eux de nous faire partager leur expérience passionnante de l’utilisation de GStreamer !  (Nicolargo)

Au cours de la dernière année scolaire, deux jeunes étudiants de l’Ecole Supérieure des Sciences et des Technologies de L’Ingénieur de Nancy (ESSTIN), ont élaboré une vidéo embarquée fonctionnant avec GStreamer. Ils ont réalisé ce projet pour leur nouveau véhicule participant au Shell Eco-marathon.

Q’est ce que le Shell Eco-marathon ?

Il s’agit d’une compétition qui depuis 27 ans réunit diverses écoles d’ingénieurs, universités et établissements de l’enseignement supérieur européen pour une course à l’économie d’énergie. Depuis 12 ans, l’ESSTIN, par le biais de l’Eco Motion Team by ESSTIN (qui est le nom de l’équipe de l’école), y engage des véhicules fonctionnant avec différentes énergies.

Le principe de la compétition du Shell Eco-marathon est de parcourir un certain nombre de kilomètres en un temps limité, le tout en consommant le moins d’énergie possible.

L’équipe (composée de 20 élèves de 3ème année, 7 de 4ème année et 2 de 5ème année, encadrés par 7 tuteurs) a participé cette année à la 28ème édition de la course qui s’est déroulée du 26 au 28 mai 2011, sur le circuit de l’EuroSpeedway à Lausitz en Allemagne.

Elle y a fait concourir son tout nouveau prototype Vir’Volt intégrant toutes ses innovations technologiques, dont la vidéo embarquée que vous pouvez voir sur le sommet du véhicule:

Ce projet de vidéo embarquée est en effet tout nouveau, il a été réalisé cette année par Damien Archenault et Clément Brunel qui sont membres de l’équipe, pour répondre à la demande des médias et des sponsors d’avoir des images embarquées en temps réel. Ce qui a pu être réalisé en rediffusant les images sur internet.

Matériel utilisé

Nous avons travaillé cette année avec la société Eukrea qui nous a fournis une carte de développement GNU/Linux embarqué fonctionnant avec un processeur IMX27 et fonctionnant avec une version de linux allégée et OpenEmbedded qui permet de configurer la distribution.

GStreamer et RTSP

Nous avons d’abord essayé d’utiliser un serveur RTSP qui correspondait parfaitement à l’utilisation que nous voulions faire, à savoir diffuser un flux en streaming et profiter des options de lecture standards (lire, pause, stop, déplacement temporel).

Nous allons donc expliquer son installation.On ne peut pas utiliser le gestionnaire de paquet comme sur un système GNU/Linux standard. Il est nécessaire de cross-compiler les fichiers pour qu’ils soient valides pour l’architecture de la carte.

Pour y parvenir, nous utilisons OpenEmbedded qui facilite grandement les choses en proposant lui aussi une liste des paquets disponibles une fois l’environnement de développement correctement installé.

Pour se faire, utilisez la commande:

bitbake gst-rtsp

Un fichier .ipk sera créé et devra être transféré (par tftp et minicom) puis installé via les commandes:

tftp -gr « nom du fichier à télécharger sur la carte » « ip de l’ordinateur cible »

opkg install nomdupaquet.ipk

Une fois installé, vous pouvez utiliser votre serveur en configurant le fichier comme sur ce précédent article du blog et en l’adaptant aux modules spécifiques de l’embarqué. (Utilisez un gst-inspect sur la carte pour les découvrir !).

Vous verrez que mfw_v4lsrc, mfw_vpuencoder font leur apparition et servent à récupérer le flux de la caméra et à l’encoder de façon « plus économe » en ressource pour le « petit » processeur de la carte.

Je ne détaillerai pas plus pour le serveur RTSP, car nous n’avons malheureusement jamais réussi à le faire fonctionner, une erreur survenant lorsqu’un client venait se connecter au serveur.

Passage en GStreamer UDP

Nous nous sommes donc rabattu sur le protocole UDP (avec une couche RTP) pour transférer notre flux vidéo, qui a au moins pour avantage d’optimiser la bande passante, car moins d’informations de sécurité et de contrôle sont envoyées. De plus, en cas de perte de paquet, ou d’arrivée dans un mauvais ordre, les perturbations pour le visiteur sont souvent minimes grâce à la persistance rétinienne.

Pour faire fonctionner le protocole UDP qui est un protocole de la couche réseau (voir modèle OSI) et non de la couche session comme RTSP, nous avons besoin des paquets gst-plugin-rtp, gst-plugin-udp, libgstnetbuffer et gst-plugin-videoscale à installer via opkg install comme précédemment.

Au niveau de l’implantation de ce protocole, il y a donc deux pipelines Gstreamer, une sur la carte (véhicule) et une autre sur le PC client qui va recevoir et afficher le flux vidéo.

Celui de la carte :

La première ligne, pointe vers le client où nous voulons envoyer les images. Dans cet exemple, sur un serveur Dyndns dont nous verrons l’utilité un peu plus loin.

La deuxième commande, la plus complexe, est celle de l’initialisation du flux :

gst-launch-0.10 mfw_v4lsrc capture-width=320 capture-height=240 ! mfw_vpuencoder width=320 height=240 codec-type=std_mpeg4 framerate=13 bitrate=250 gopsize=8 ! rtpmp4vpay send-config=true ! udpsink host=$HOST port=5000

Voici le détail:

  • gst-launch-0.10 : c’est la commande de base, à laquelle on va ajouter des paramètres. (ajouter –v) pour voir le détail de la commande qui s’exécute et avoir la « config » pour le client
  • mfw_v4lsrc : elle permet de sélectionner la caméra comme source du flux
  • — capture-width=320 : Largeur de la fenêtre capturée
  • — capture-height=240 : Hauteur de la fenêtre capturée
  • mfw_vpuencoder : C’est ce plugin qui va nous permettre d’encoder le flux
  • — width=320 : largeur de la fenêtre encodée
  • — height=240 : hauteur de la fenêtre encodée
  • — codec-type=std_mpeg4 : le codec utilisé est le codec mpeg4, ce n’est pas le meilleur codec de compression qui est h264, mais nous avions des erreurs avec ce dernier quand le client venait à se connecter.
  • — framerate=13 : Nombre d’image par seconde transmise
  • — bitrate=250 : quantité de donnée transmises. Il doit être en adéquation avec le type de réseau utilisé : réseau local filaire, réseau wifi, réseau mobile (EDGE, 3G et 3G+ ayant un débit très différent les uns des autres).
  • — gopsize=8 ! (group of picture) représente le nombre d’image envoyé simultanément sur le réseau, ce nom est proche de la moitié du framerate, et favorise la compression.
  • rtpmp4vpay : regroupe les données dans des paquets RTP
  • — send-config=true : envoie la configuration du canal au client. Utile pour récupérer la clé pour synchroniser le client (voir page suivante)
  • udpsink host=$HOST : adresse à laquelle on veut envoyer les données
  • — port=5000 : le port de la liaison entre les deux hôtes.

Celui du client :

Cette commande à l’air compliqué, mais elle est en fait plus simple que la commande de la carte.

gst-launch-0.10 -v –gst-debug=2 udpsrc port=5000 caps= »application/x-rtp, media=(string)video,clock-rate=(int)90000, encoding-name=(string)MP4V-ES, profile-level-id=(string)4, config=(string)000001b004000001b59113000001000000012000c888800f514043c14103, payload=(int)96,ssrc=(uint)1960725087, clock-base=(uint)849638580, seqnum-base=(uint)55554″ ! gstrtpjitterbuffer latency=3000 ! rtpmp4vdepay ! ffdec_mpeg4 ! autovideosink

Détail:

  • gst-launch-0.10 -v –gst-debug=2 : on lance la commande en debug, pour avoir toutes les infos en cas de dysfonctionnement.
  • udpsrc port=5000 port sur lequel on reçoit les données, il doit correspondre à celui de la commande de la carte.
  • — caps= »application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)MP4V-ES, profile-level-id=(string)4, config=(string)000001b004000001b59113000001000000012000c888800f514043c14103, payload=(int)96, ssrc=(uint)1960725087, clock-base=(uint)849638580, seqnum-base=(uint)55554″ : il s’agit ici de la clé qui caractérise complètement le flux entrant. On la trouve en appliquant le –v sur la commande de la carte, puis en faisant un copier coller de la dernière ligne notée « caps »
  • gstrtpjitterbuffer latency=3000 : il s’agit d’un buffer de 3secondes, non obligatoire, mais améliorant fortement la qualité et les aléas de connexion.
  • rtpmp4vdepay : extraire les données des paquets RTP
  • ffdec_mpeg4 : décode les données qui sont en mpeg4
  • autovideosink : affiche le flux sur l’écran.

Une fois ces deux pipelines initialisés correctement (le serveur puis le client) on peut ensuite récupérer l’ordinateur sur un ordinateur quelconque et cela grâce à l’utilisation d’un serveur DNS comme Dyndns.

L’ordinateur chargé de récupérer les images doit juste être synchronisé avec le serveur DNS à l’aide d’un client comme inadyn ou ddclient, dont le fichier de configuration est le suivant :

## ddclient configuration file temps entre chaque rafraichissement de l’ip

daemon=60

# check every 60 seconds

syslog=yes

# log update msgs to syslog

mail-failure=########### #

pid=/var/run/ddclient.pid

# record PID in file.

## Detect IP with our CheckIP server

use=web, web=checkip.dyndns.com/, web-skip=’IP Address’

## DynDNS username and password here

login=#####

password=#######

## Default options

protocol=dyndns2

server=members.dyndns.org

## Dynamic DNS hosts

NOMDEVOTREDNS.dyndns.org

Diffusion du flux sur Internet

Enfin, pour rediffuser en direct sur internet, nous avons utilisé deux outils formidables que sont webcamstudio qui permet de transformer un flux distant en un flux webcam et le site livestream.com qui permet justement de diffuser au monde entier les images d’une webcam, ou dans notre cas de notre vidéo embarquée.

Voici le résultat tel que les Internautes pouvaient le voir:

Conclusion

Le développement d’un tel projet prend beaucoup de temps car est malheureusement assez peu documenté, mais vous partez déjà avec une bonne piste grâce à cet article.

Merci pour votre lecture, et merci à Nicolargo (NDLR: mais c’est avec plaisir !) qui nous permet de publier via son blog.

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

Présentation « powerpoint » du framework GStreamer

Comme vous avez pu le remarquer, depuis quelques mois la fréquence des billets sur le blog est en chute libre. La « faute » à mon boulot (celui qui paye les factures) pour lequel je suis pas ma en déplacement. J’ai pu juger comme il était difficile de bloguer loin de ses terres. J’ai donc vite renoncer à écrire des articles depuis les chambres d’hôtels et j’ai préféré visiter les belles villes de Rennes et de Paris.

Cependant ces fameuses mission m’ont permis de poser sur quelques planches « powerpoint » (c’est votre chef qui va être heureux) une introduction au framework GStreamer que j’aborde souvent dans mon blog (voir la page dédiée ici).  Cette présentation est bien évidemment distribuée sous licence CC BY v3.  L’idéal si vous avez à l’utiliser est de la faire tourner sur PC sous GNU/Linux avec l’ensemble des plugins GStreamer installés. puis à chaque planche ou il y a un exemple de faire un copier/coller de ce dernier dans un terminal (effet démo garanti).

Pour d’évidentes raisons de compatibilité, je diffuse la présentation au format PDF (il suffit de cliquer sur l’image ci-dessous pour lancer le téléchargement). Pour les personnes voulant modifier cette présentation, vous pouvez également la télécharger au format ODP.

Je vous rappelle, que l’ensemble des billets sur GStreamer est regroupé sur cette page. Si vous voulez être tenu au courant des nouveaux articles sur le sujet, je vous conseille de vous abonner au flux RSS du blog, à mon compte Twitter ou à partir de Facebook.

Enfin pour finir, si vous utilisez cette présentation merci de laisser un petit commentaire sur cette page…

Catégories
Gstreamer Open-source Planet-libre Video

Transcoder facilement ses vidéos avec Arista

Arista est un projet développé en parallèle de Transmageddon qui a pour objectif d’avoir une solution logicielle libre et simple pour transformer une vidéo en un beau fichier compressé et compatible avec vos périphériques de lectures. Le logiciel se base sur le merveilleux framework GStreamer.

Nous allons donc voir dans ce billet comment installer puis utiliser ce logiciel sur une distribution Ubuntu 10.10 (vous pouvez bien-sur utiliser ce logiciel sur d’autre distribution, seule la procédure d’installation sera à changer).

Installation de Arista

C’est très simple sous Ubuntu:

sudo aptitude install arista nautilus-arista

Lancement de Arista

On passe par le menu principal > Son et vidéo > Arista Transcoder:

Transcodage pas à pas

1) Sélection de la source

On commence par sélectionner la source vidéo parmi:

  • un disque DVD (à insérer dans votre lecteur)
  • un fichier vidéo quelconque
  • une caméra / une webcam

2) Sélection du périphérique cible

On doit choisir le périphérique sur lequel on voudra lire la vidéo transcodé. On a le choix entre (cette liste évolue automatiquement selon les changement de version et des mises à jour spécifiques):

  • Android
  • Apple iPad
  • Apple iPod/iPhone
  • Ordinateur (Linux)
  • Lecteur DVD
  • Nokia N
  • Sony PSP
  • Sony PS3
  • Web (navigateur)

3) Sélection du format de pré réglage

Ce dernier choix dépend du périphérique cible. Par exemple pour une lecture sur un ordinateur, on a le choix entre H.264, WebM (VP8) ou Theora.

4) Sélection du fichier de la vidéo transcodé

On sélectionne enfin le nom du fichier de destination en cliquant sur le bouton « + Ajouter à la file« :

Puis on entre le nom du fichier.

Attention, le transcodage commence tout de suite, avec un aperçu en « live ».

Et voilà le résultat:

  • Fichier source (RAW): football_cif.y4m de 38 Mo
  • Fichier transcodé (VP8): football_cif.webm de 1.5 Mo

Conclusion

Arista est un transcoder simple à utiliser dans la pure tradition des logiciels Unix, une tache, un logiciel. Le fait que la liste des périphériques se mette automatiquement à jour est vraiment un plus non négligeable. Et hop un logiciel de plus dans mon script de post installation d’Ubuntu !

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 Systeme Video

Installation complète de GStreamer sous Fedora 14

Gstreamer est un framework multimedia très puissant que j’aborde régulièrement sur mon blog (voir la liste des articles ici). Il fonctionne avec un système de « plugins » lui permettant d’apporter de nouvelles fonctions sans toucher au coeur du framework.

Comme toutes les distributions GNU/Linux, Fedora est installée par défaut avec GStreamer et un certain nombre de plugins (environ 180 sur ma toute fraîche Fedora 14).   Nous allons donc voir dans ce billet comment installer « la totale » (c’est à dire la liste complète des plugins pour GStreamer).

Installation des dépôts

J’utilise les depôts RPMFusion qui contienne les dernières versions stable de GStreamer et des plugins:

su –

yum -y localinstall –nogpgcheck http://fr2.rpmfind.net/linux/rpmfusion/free/fedora/rpmfusion-free-release-stable.noarch.rpm http://fr2.rpmfind.net/linux/rpmfusion/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm

yum update

Installation de GStreamer et de tous les composants

Cette installation devrait occuper environ 160 Mo sur votre disque dur.

LISTE=`yum -q list available ‘*gstreamer*’ | awk ‘{print $1 }’ | grep gstreamer | xargs -eol` ; yum -y install $LISTE

A la fin de cette installation, on peut demander le nombre de plugins avec la commande suivantes:

gst-inspect | tail -1

Nombre total :229 greffons (2 éléments de liste noire not shown), 1125 fonctionnalités

Et voili, on a donc un gain de 49 plugins 🙂 !

Catégories
Gstreamer Open-source Systeme

Installation de tous les composants GStreamer sous Ubuntu

Voici un petit script maison permettant d’installer la totalité des plugins GStreamer sur votre distribution Ubuntu.

On télécharge, le script, puis on le lance:

wget https://raw.github.com/nicolargo/ubuntupostinstall/master/gstreamerinstall.sh

chmod a+x ./gstreamerinstall.sh

sudo ./gstreamerinstall.sh

rm ./gstreamerinstall.sh

Vous devriez vous retrouver avec environ 233 plugins dont les fameux webmmux et vp8enc pour encoder vos vidéo au format WebM 🙂

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

Encodage de vidéo WebM en ligne de commande

Le format multimédia WebM fait beaucoup parler de lui ces derniers temps. Sous l’impulsion de Google, il a pour objectif de devenir le standard libre pour la diffusion de fichier vidéo sur Internet. Sans entrer dans les polémiques de qualité et des problèmes de licence, nous allons dans ce billet voir comment encoder un vidéo dans un format WebM en ligne de commande en utilisant le framework GStreamer, fourni en standard sous GNU/Linux.

WebM, c’est quoi donc ?

En fait WebM est un conteneur multimédia, une enveloppe au même titre que OGG, MP4  ou AVI. Quand on parle de fichiers au « format WebM », cela sous entant l’utilisation des codecs audio Vorbis et vidéo VP8 (racheté il y a quelques mois par Google à la societé On2).

Avant de tester l’encodage d’un fichier WebM sur votre distribution GNU/Linux. Sous Ubuntu, il faut d’abord vérifier que vous disposez de la dernière version PPA de GStreamer:

sudo add-apt-repository ppa:gstreamer-developers

sudo aptitude update

sudo aptitude upgrade

sudo aptitude install gstreamer0.10-x gstreamer-tools gstreamer0.10-plugins-base gstreamer0.10-plugins-good gstreamer0.10-plugins-bad gstreamer0.10-plugins-bad-multiverse gstreamer0.10-plugins-ugly gstreamer0.10-plugins-ugly-multiverse gstreamer0.10-ffmpeg gstreamer0.10-alsa gstreamer0.10-sdl

Enfin on vérifie que l’on a les bons plugins:

# gst-inspect | grep webmmux

matroska: webmmux: WebM muxer

 

# gst-inspect | grep vp8enc

vp8: vp8enc: On2 VP8 Encoder

 

gst-inspect | grep vorbisenc

vorbis: vorbisenc: Vorbis audio encoder

Passons maintenant aux choses sérieurses…

Encodage au format WebM

Pour mes test j’ai utilisé une bande annonce du film « Prince of persia » en qualité HD 1080p récupérée sur le site HDTrailers.

J’utilise ensuite la pipeline (ligne de commande) suivante pour effectuer l’encodage:

gst-launch -t filesrc location=pp_rltA_1080.mov ! progressreport \

! decodebin name=decoder decoder. \

! queue ! audioconvert ! vorbisenc quality=0.5 \

! queue ! webmmux name=muxer decoder. \

! queue ! ffmpegcolorspace ! vp8enc quality=5 speed=2 \

! queue ! muxer. muxer. ! queue ! filesink location=pp_rltA_1080-Q5.webm

La qualité vidéo par défaut (option quality=5) n’est pas terrible, on obtient de meilleurs résultats en l’augmentent. Voici un tableau comparatif:

Format Codecs Taille Aperçu (clique pour agrandir)
Source HQ .mov Audio: AAC 48 Khz
Video: H.264		 126 Mo
WebM Audio: Vorbis 

Video: VP8 « Quality 5 »

 24 Mo
WebM Audio: Vorbis 

Video: VP8 « Quality 6 »

 30 Mo
WebM Audio: Vorbis 

Video: VP8 « Quality 7 »

 40 Mo
WebM Audio: Vorbis 

Video: VP8 « Quality 8 »

 61 Mo
WebM Audio: Vorbis 

Video: VP8 « Quality 9 »

 73 Mo
WebM Audio: Vorbis 

Video: VP8 « Quality 10 »

 92 Mo

Je trouve que la paramètre quality=7 est un bon compromis taille/qualité. Il faut noter que la source est d’un  qualité nettement supérieure (je ne connais pas les paramètre H.264 utilisés).

Comparaison avec les codecs Theora et H.264

Pour compléter ce petit test de WebM, nous allons comparer maintenant le résultat obtenu avec le paramètre quality=7 et les codecs Theora (avec une qualité égale à 7) et X.264 (avec une qualité de 23 équivalente).

Voici les lignes de commandes utilisées, pour l’encodage en WebM (VP8/Vorbis):

gst-launch -t filesrc location=pp_rltA_1080.mov ! progressreport \

! decodebin name=decoder decoder. \

! queue ! audioconvert ! vorbisenc quality=0.5 \

! queue ! webmmux name=muxer decoder. \

! queue ! ffmpegcolorspace ! vp8enc quality=7 speed=2 \

! queue ! muxer. muxer. ! queue ! filesink location=pp_rltA_1080-Q7.webm

puis en OGG (Theora/Vorbis):

ffmpeg2theora -v 7 –optimize pp_rltA_1080.mov -o pp_rltA-1080-Q7.ogg

et enfin en MP4 (X.264/FAAC):

x264 –tune animation –crf 23 -o pp_rltA-1080-Q7.mp4 pp_rltA_1080.mov

On obtient les résultats suivants:

Format Codecs Taille Aperçu (clique pour agrandir)
WebM Audio: Vorbis 

Video: VP8 « Quality 7 »

 40 Mo
OGG Audio: Vorbis 

Video: Theora « -v 7 »

 57 Mo
MP4 Audio: AAC 

Video: X.264 « CRF 23 »

 56 Mo

Que peut on en déduire ? Niveau qualité, le format H.264 garde une longueur d’avance (mais pour combien de temps). Theora est en dessous. Par contre le taux de compression est bien meilleur avec le codec VP8 mais encore faut il être sur que l’on peut comparer les paramètres utilisés…

A vous de vous faire une idée !

Conclusion

Bien que « jeune » ce format de fichier semble avoir un bel avenir. Surtout si Google arrive à l’imposer comme un « standard industriel » (sic). Avec des leviers comme YouTube et Google Chrome, j’ai peu de doute sur le résultat des courses qui ne se fera pas sur un plan technique mais sur la capacité de chacun de défendre son format.

Catégories
Gstreamer Open-source Video Web

MyScreenCast, comment faire du screencast avec GStreamer

Je ne sais pas vous mais je n’arrive pas à trouver LE logiciel de screencast libre ultime pour mon PC Linux. J’ai essayé Istanbul (le résultat est très mauvais sur ma distribution Ubuntu 10.04), XVidCap (pas d’enregistrement du son) et même VLC (un peu usine à gaz pour ce besoin)… Seul RecordMyDesktop sort du lot bien que son interface graphique d’administration (gtk-recordmydesktop) ne soit pas des plus ergonomique.

Ce billet est donc un appel à la communauté pour développer CE logiciel en question !

Nous allons dans un premier temps donner les bases techniques permettant de faire un screencast à partir du framework GStreamer (fourni en standard sous Linux). Puis donner dans les grandes largeurs les spécifications DU logiciel.

On commence par la fin: le résultat

Voici le screencast obtenu (format libre OGV – Theora/Vorbis – hébergé sur blip.tv): si votre navigateur est compatible…

Sinon vous pouvez toujours consulter la vidéo en ligne sur Blip.tv ou sur Vimeo (codec H.264/AAC)

Les fichiers générés sont au format HD 720p et ont une taille d’environ 11 Mo pour le format M4V et 13 Mo pour le format OGV.

Screencast avec GStreamer en ligne de commande

On commence par vérifier que l’on dispose bien du plugin gstreamer istximagesrc:

[cc]

gst-inspect istximagesrc
…
version 0.2.2
…

[/cc]

Si ce n’est pas le cas, il suffit d’installer le package Istanbul qui inclue ce plugin:

[cc]

sudo aptitude install istanbul

[/cc]

Aller, une fois ces menus préparatifs passés,  on commence par lancer un capture vidéo de l’écran et sonore en utilisant la ligne de commande GStreamer (pipeline) suivante:

[cc]

gst-launch avimux name=mux ! filesink location=screencast.avi \
alsasink ! audioconvert ! queue ! mux. \
istximagesrc name=videosource use-damage=false ! video/x-raw-rgb,framerate=10/1 \
! ffmpegcolorspace ! queue ! videorate ! ffmpegcolorspace ! videoscale method=1 \
! video/x-raw-yuv,width=1152,height=720,framerate=10/1 ! mux.

[/cc]

Cette commande va capturer l’écran à 10 images par secondes (istximagesrc), le son (alsasink) et mixer le tout (sans compression mais avec une redimensionnement de la vidéo au format 720p) dans un fichier temporaire au format AVI. Ce fichier aura une taille très importante mais c’est juste une étape temporaire avant la compression.

Pour cette compression j’utilise deux pipelines permettant de générer des screencasts au format libre OGV (Theora/Vorbis) et propriétaire M4V (H.264/AAC), comme cela, tous les navigateurs sont heureux:

[cc]

gst-launch filesrc location=screencast.avi ! decodebin name= »decode » \
decode. ! videoparse format=1 width=1152 height=720 framerate=10/1 \
! queue ! ffmpegcolorspace ! theoraenc ! queue ! \
oggmux name=mux ! filesink location=screencast.ogv \
decode. ! queue ! audioconvert ! vorbisenc ! queue ! mux.

gst-launch filesrc location=screencast.avi ! decodebin name= »decode » \
decode. ! videoparse format=1 width=1152 height=720 framerate=10/1 \
! queue ! ffmpegcolorspace ! x264enc pass=4 quantizer=23 threads=0 ! queue ! \
ffmux_mp4 name=mux ! filesink location=screencast.m4v \
decode. ! queue ! audioconvert ! faac tns=true ! queue ! mux.

[/cc]

Un script qui fait tout…

Comme je suis un bon loulou, voici un script shell qui automatise

  1. le lancement de votre Webcam pour avoir une incrustation de votre image dans le screencast
  2. le lancement de la capture video de l’écran + capture audio (après un délais de 3 secondes histoire de refaire son nœud de cravate)
  3. (on arrête la capture en faisant un CTRL-C dans la fenêtre)
  4. la compression du screencast dans un fichier screencast-dateetheure.ogv (codec Theora/Vorbis)
  5. la compression du screencast dans un fichier screencast-dateetheure.m4v (codec H.264/AAC)
  6. la suppression du fichier temporaire

A télécharger ici: https://raw.github.com/nicolargo/myscreencast/master/myscreencast.sh

Vous pouvez éditer le fichier et notamment la configuration suivante:

[cc]

### Variables à ajuster selon votre configuration
AUDIODEVICE= »alsasrc »
WEBCAMDEVICE= »/dev/video0″
WEBCAMHEIGHT= »240″
OUTPUTHEIGHT= »720″
OUTPUTFPS= »10″
### Fin des variables à ajuster

[/cc]

… en attendant LE programme ultime

qui devra reprendre en gros les étapes de mon script mais en ajoutant:

  • une interface graphique
  • le choix d’une portion de l’écran à capturer
  • le choix d’une application (fenêtre) à capturer
  • le choix de la source audio (mixage possible avec la librairie Jack)
  • paramétrage fin des codecs audio et video