Le but de ce billet est d'installer un serveur de de virtualisation Xen (Wiki) sur un système GNU/Linux Debian. Ce dernier pourra héberger de manière virtuelle (c'est à dire sur la même machine physique)

Installation du serveur Xen

J'ai choisi d'héberger mon serveur de virtualisation Xen (on appelle cette machine le dom0 pour "domaine 0" dans le jargon Xen) sur la machine suivante:

HP Proliant DL145
AMD Optron 64
2 Go RAM
2 disques durs de 80 Go en RAID 1 (LVM)
Système d'exploitation: GNU/Linux Debian Lenny 5

J'ai effectué une installation standard à partir du CD d'installation de la Debian 5.0 en appelant ma machine virt1 et en installant comme seul et unique service le daemon OpenSSH (pour un accès à distance).

Ensuite, il faut procéder à l'installation de Xen et de ses utilitaires:

aptitude install xen-hypervisor-i386 xen-linux-system-2.6.26-2-xen-686 xen-utils xen-tools xen-shell xenwatch xenstore-utils

On configure ensuite le réseau de la manière à transformer notre machine dom0 en bridge. Pour cela, on édite le fichier /etc/xen/xend-config.sxp et on remplace la ligne:

(network-script network-dummy)
par
(network-script network-bridge)

On reboot notre système pour prendre en compte le noyau supportant Xen:

reboot

Configuration du serveur Xen

Nous allons utiliser xen-tools pour administrer nos serveurs virtuels. Pour cela il faut éditer le fichier de configuration (/etc/xen-tools/xen-tools.conf) de la manière suivante (en gras les options à adapter selon votre configuration):

dir = /xen
install-method = debootstrap
size   = 4Gb      # Disk image size.
memory = 128Mb    # Memory size
swap   = 128Mb    # Swap size
fs     = ext3     # use the EXT3 filesystem for the disk image.
dist   = etch     # Default distribution to install.
image  = sparse   # Specify sparse vs. full disk images.
gateway   = 192.168.29.1
netmask   = 255.255.255.0
passwd = 1
kernel      = /boot/vmlinuz-`uname -r`
initrd      = /boot/initrd.img-`uname -r`
mirror = http://ftp.lip6.fr/pub/linux/distributions/debian/
ext3_options   = noatime,nodiratime,errors=remount-ro
ext2_options   = noatime,nodiratime,errors=remount-ro
xfs_options    = defaults
reiser_options = defaults
serial_device = hvc0
disk_device = xvda

On pense également à créer le répertoire qui contiendra les domaines hôtes (/xen dans ma configuration):

mkdir /xen

Installation d'un serveur virtuel

Nous allons commencer par ajouter un nouveau serveur virtuel (que l'on appelle domU pour "domaine Users" dans le jargon Xen) à notre configuration. Cette action se fait de manière très simple grâce à la commande suivante (attendre quelques minutes):

# xen-create-image --hostname=servvirt1.mondomaine.com --size=10Gb --swap=512Mb --ip=192.168.29.171 --memory=256Mb --arch=i386 --role=udev
General Information
--------------------
Hostname       :  servvirt1.mondomaine.com
Distribution   :  etch
Partitions     :  swap            512Mb (swap)
                  /               10Gb  (ext3)
Image type     :  sparse
Memory size    :  256Mb
Kernel path    :  /boot/vmlinuz-2.6.26-2-xen-686
Initrd path    :  /boot/initrd.img-2.6.26-2-xen-686

Networking Information
----------------------
IP Address 1   : 192.168.29.171 [MAC: 00:16:3E:8B:F0:9E]
Netmask        : 255.255.255.0
Gateway        : 192.168.29.1

Xen va alors créer un serveur virtuel disposant d'un disque de 10 Go, d'un taille de swap de 512 Mo et d'une mémoire de 256 Mb. L'adresse IP de ce nouveau serveur virtuel sera 192.168.29.171. Le mot de passe root du système vous sera demandé en fin d'installation.

Un fichier de configuration dédié a ce nouveau serveur a été généré: /etc/xen/servvirt1.mondomaine.com.cfg

Gestion du serveur virtuel

Démarrage du serveur virtuel

Pour lancer le serveur virtuel préalablement créé, il faut saisir la commande:

xm create /etc/xen/servvirt1.mondomaine.com.cfg

Vous pouvez alors vous connecte dessus en SSH:

ssh root@servvirt1.mondomaine.com

Pour automatiser le démarrage de ce serveur virtuel (domU) au lancement de votre serveur hôte (dom0), il faut créer le lien suivant:

ln -s /etc/xen/servvirt1.mondomaine.com.cfg /etc/xen/auto/host1.cfg

Cette commande permet de séquencer le lancement des serveurs domU dans un certain ordre. Cela peut être utile si le service hébérgé sur un serveur virtuel dépend d'un autre...

Autres commandes utiles à l'administration de vos serveurs virtuels

Pour arrêter un serveur virtuel:

xm shutdown servvirt1.mondomaine.com

Pour voir la liste des serveurs virtuelles lancées:

# xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  1765     2     r-----    106.7
servvirt1.mondomaine.com       1   256     1     -b----      2.6

Liste des serveurs virtuels créés:

# xen-list-images
Name: servvirt1.mondomaine.com
Memory: 256
IP: 192.168.29.171

Occupation des ressources en temps réel:

xentop

Pour rendre prioritaire un serveur virtuel par rapport à un autre, nous allons utiliser les options du gestionnaire d'allocation des ressources ("Credit scheduler", par défaut dans la version Xen 3.0).
Par exemple, si nous avons deux serveurs virtuels servvirt1 et servvirt2 (domU) hébérgés sur notre serveur hôte (dom0) et que nous souhaitons donner deux fois plus de temps CPU à servvirt2, il suffit de saisir la commande suivante:

xm sched-credit -d servvirt2.mondomaine.com -w 512

PS: par défaut, un serveur virtuel à un poids de 256.

La liste des poids des serveurs virtuels peut être obtenue grâce à la commande:

# xm sched-credit
Name                                ID Weight  Cap
Domain-0                             0    256    0
servvirt1.mondomaine.com                1    256    0
servvirt2.mondomaine.com                1    512    0

Les commandes xm sched-credit sont à lancer (par exemple dans un script shell) au démarrage du serveur hôte.

Conclusion

Xen et la virtualisation en général est un très bon moyen, dans cette période de crise, d'optimiser au mieux les ressources hardware disponibles. Il est bien sûr possible de créer autant de serveurs virtuels que possible sur notre serveur hôte (dans les limites de performances souhaités au niveau des domU).

Quelques sources utiles à la rédaction de ce billet:

• http://www.cl.cam.ac.uk/
• http://www.howtoforge.com/
• http://www.eecs.iu-bremen.de/
• http://www.d7031.de/
• http://www.unixgarden.com/
  

Pas de nouveauté mais juste le correctif pour un gros bug de la version 3.1.1 qui mettait votre CPU KO...
Il est donc temps de mettre à jour son serveur en suivant cette procédure.

Je ne vais pas rentrer dans le détail des fonctions que propose ce logiciel, il suffit de se rendre sur cette page pour avoir ces informations. Par contre, nous allons dans ce billet nous pencher sur l'installation de la "bête" sur notre bonne vieille distribution GNUL/Linux Ubuntu. Il va falloir un tout petit peu bidouiller car cette dernière version n'est pas encore dans les repos officiels.

On commence par récupérer Songbird à l'adresse suivante: http://getsongbird.com/download/

On va obtenir un fichier au format (extension) .tar.gz

Il faut ensuite ouvrir un terminal et ce rendre dans le répertoire ou le fichier a été télé-chargé (/home/nicolargo/Bureau dans mon exemple):

cd /home/nicolargo/Bureau

Ensuite on décompresse l'archive:

tar zxvf Songbird_1.2.0-1146_linux-i686.tar.gz

On va obtenir un répertoire Songbird.

Il ne reste plus qu'a dés-installer (si nécessaire) les versions précédentes:

sudo apt-get remove songbird

Puis à copier la nouvelle version dans notre système:

sudo mv Songbird /opt/

sudo chown -R root:root /opt/Songbird

sudo chmod -R 755 /opt/Songbird

Enfin, on créé un nouveau lanceur d'application personnalisé dans le tableau de bord:

• click droit sur la barre de menu, puis click sur "Editer les menus"
• click sur le menu Applications / Son et vidéo
• click sur "Nouvel élément"

• click sur Valider

Et voili, il ne reste plus qu'à aller dans le menu Applications / Son et vidéo et cliquer sur Songbird pour lancer l'application !

Bonne écoute

Nous allons dans ce billet tester la version 1.2.5 de NConf sur un serveur Nagios 3.1. Je pars sur l'hypothèse ou le serveur Nagios a été installé en suivant mes deux premiers tutos (1 et 2).

Installation de NConf

On commence par récupérer la dernière version disponible de NConf (la 1.2.5 au moment de l'écriture de ce billet).

wget http://puzzle.dl.sourceforge.net/sourceforge/nconf/nconf-1.2.5-0.tgz

On décompresse l'archive:

tar zxvf nconf-1.2.5-0.tgz

Puis on copie le répertoire nconf à la racine de son serveur Web et on change les droits:

sudo mv nconf /usr/local
sudo chown -R www-data:www-data /usr/local/nconf

Notes: les sous-répertoires suivants doivent avoir les droits en écriture pour l'utilisateur www-data:
./config
 ./output
 ./static_cfg
 ./temp

Création de la base de donnée

La prochaine étape consiste à créer une base de données dédiée ) NConf. Pour créer un base de donnée nommée nconf avec les droits pour l'utilisateur nconfuser (mot de passe: nconfpassword), il faut saisir les commandes suivantes sur son serveur MySQL:

# mysqladmin --user=root -p create nconf

# mysql --user=root -p mysql

mysql> GRANT ALL ON nconf.* TO nconfuser@localhost IDENTIFIED BY 'nconfpassword';

mysql> flush privileges;

Configuration du serveur Web

Pour rendre accessible le répertoire /usr/local/nconf à partir de votre serveur Web, il faut ajouter le fichier de configuration /etc/apache2/conf.d/nconf.conf dans votre configuration Apache:

Alias /nconf /usr/local/nconf/
<Directory "/usr/local/nconf">
    Options Indexes
    AllowOverride AuthConfig Options
    Order allow,deny
    Allow from all
</Directory>

Puis relancer Apache:

apache2ctl restart

Configuration de NConf

La fin de l'installation se fait via une interface Web. Il faut donc saisir l'URL suivante dans un navigateur:

Ce qui devrait afficher:

On clique sur le bouton Next.

On doit saisir les paramètres de la base de donnée préalablement créées:

On clique sur le bouton Next.

Le test de la BD doit être OK:

On clique sur le bouton Next.

On fixe les répertoires de Nconf et de Nagios (/usr/local/nagios/bin). Attention dans le champs NAGIOS BIN, il faut saisir le chemin complet vers le binaire de Nagios (/usr/local/nagios/bin/nagios) et pas seulement le répertoire comme je l'ai fait dans un premier temps dans cette capture d'écran...

On clique sur le bouton Next.

On fixe un mot de passe (adminpassword) pour l'accès à NConf:

On clique sur le bouton Next.

Le programme d'installation va vérifier la configuration (tout doit être OK):

On clique sur le bouton Finish.

On efface les fichier suivant:

sudo rm -r /usr/local/nconf/INSTALL /usr/local/nconf/INSTALL.php /usr/local/nconf/UPDATE /usr/local/nconf/UPDATE.php

Mise en place de la synchronisation avec Nagios

Comme NConf peut être hébergé sur une machine différente du serveur Nagios, l'importation de la configuration NCOnf vers Nagios doit se faire à la main ou par un script shell. Je préfére bien entendu cette deuxième méthode.

Avant tout, il faut vérifier que le répertoire Nagios à les bon droits en lecture et écriture pour être modifié par l'utilisateur www-data (utilisateur avec lequel le serveur Apache est lancé). Le plus simple est d'ajouter www-data au groupe nagiosgrp:

# vigr
nagiosgrp:x:1002:nagios,www-data

puis de mettre les bons droits au répertoire etc:

chown -R nagios:nagiosgrp /usr/local/nagios/etc
chmod 770 /usr/local/nagios/etc

J'ai ensuite modifié le script ADD-ONS/deploy-local.sh de la manière suivante:

#!/bin/bash
OUTPUT_DIR="/usr/local/nconf/output/"
NAGIOS_DIR="/usr/local/nagios/etc/"
TEMP_DIR=${NAGIOS_DIR}"import/"
CONF_ARCHIVE="NagiosConfig.tgz"
if [ ! -e ${TEMP_DIR} ] ; then
mkdir -p ${TEMP_DIR}
fi
if [ ${OUTPUT_DIR}${CONF_ARCHIVE} -nt ${TEMP_DIR}${CONF_ARCHIVE} ] ; then
cp -p ${OUTPUT_DIR}${CONF_ARCHIVE} ${TEMP_DIR}${CONF_ARCHIVE}
tar -xf ${TEMP_DIR}${CONF_ARCHIVE} -C ${NAGIOS_DIR}
/etc/init.d/nagios reload
fi
exit

Il ne reste plus qu'a l'éxecuter de manière automatique (par exemple toutes les 5 minutes) via un crontab root:

# crontab -e
*/5 * * * * /bin/bash /usr/local/nconf/ADD-ONS/deploy_local.sh 2>&1 > /dev/null

Utilisation de NConf

La première chose à faire est de se connecter à l'interface Web et de s'authentifier (admin/adminpassword). La page suivante devrait s'afficher:

On va tester notre nouvelle interface en ajoutant un nouvel host dans Nagios. Pour cela on clique sur le menu "Hosts Add" de NConf:

On clique ensuite sur Submit.

On peut alors choisir les services à superviser (il est bien sûr possible d'ajouter des services via NConf):

On clique ensuite sur Submit.

Une dernière page s'affiche avec le résumé:

On clique sur Finish.

NConf vient ainsi d'ajouter ce nouvel host dans sa base de donnée. En cliquant maintenant sur le lien "Generate Nagios config", on va générer les fichiers de configuration de Nagios dans un NagiosConfig.tgz se trouvant dans le répertoire  /usr/local/nconf/output.

Il ne reste plus qu'a attendre le prochain lancement du script deploy-local.sh (dans les 5 minutes via crontab) pour que le host apparaisse dans Nagios:

Conclusion

Bien qu'en développement, NConf est très prometteur et comble le vide laissé par Nagios pour l'administration via une interface Web. L'idéal serait maintenant d'intégrer cette interface dans celle de Nagios (le hack ne doit pas être très difficile à faire) afin de ne pas avoir deux interfaces (NConf et Nagios).

A vous de tester maintenant...

C'est une très bonne introduction à Nagios, plutôt dédiée aux personnes débutant dans le domaine de la supervision réseau mais ayant quand même de bonne base en système et réseau.

Le livre est seulement disponible en Anglais (pas de traduction prévue pour le moment). Si vous êtes allergique à la langue de Shakespeare, je vous conseille encore une fois le très bon livre d'Olivier Jan: "Nagios et la supervision open source".

Ce support comprend l'accès à des équipes d'experts dédiés disponible un peu partout sur la planète (pas de problème de décalage horaire), un accès à un gestionnaire de tickets pour saisir et suivre vos appels. Une base de connaissance publique (documentation, FAQ) est également disponible.

Le prix annuel pour l'accès à ce support commence à  $2495 (soit environ 1766 Euros). Comme quoi il est possible d'associer business et open-source...

A la recherche des "bons" paramètres

On commence par  créer un fichier vidéo de référence. Ce dernier est à adapter à votre besoin. Pour mes tests, j'ai enregistré une séquence d'une dizaine de secondes devant ma Webcam:

gst-launch v4l2src device="/dev/video1" ! queue ! videoscale method=1 ! video/x-raw-yuv,width=320,height=240 ! avimux ! filesink location=webcam.avi

Ensuite on génère un fichier encodé en H.264 (c'est à dire sans paramètre, avec un encodage à 2 Mbps). Il servira de référence pour la comparaison qualitative:

gst-launch filesrc location=webcam.avi ! decodebin ! queue ! ffmpegcolorspace ! x264enc ! avimux ! filesink location=webcam-x264-10.avi

On peut comparer les deux:

Original vs X.264 (defaut)

On va maintenant jouer avec les paramètres disponibles pour le codec X.264. La liste de ces paramètres est longue et le paramétrage très pointu. Je vous conseille la lecture de ce document et de ce forum.

Nous allons dans un premier temps fixer le débit de compression à 200 Kbps (paramètre bitrate) puis mettre des valeurs moyennes au niveau des paramètres ref et subme. Cela devrait assurer un bon compromis entre vitesse de compression et qualité d'image.

gst-launch filesrc location=webcam.avi ! decodebin ! queue ! x264enc byte-stream=true bitrate=200 ! gst-launch filesrc location=webcam.avi ! decodebin ! queue ! ffmpegcolorspace ! x264enc byte-stream=true bitrate=200 bframes=4 ref=4 me=hex subme=4 weightb=true threads=0 ! avimux ! filesink location=webcam-x264-11.avi

On compare le résultat:

X.264 (defaut) vs X.264 test 11
(byte-stream=true bitrate=200 bframes=4 ref=4 me=hex subme=4 weightb=true threads=0)

Comme on peut le voir la qualité est moins bonne (surtout quand il y a des mouvements) mais l'on passe d'un débit de 2089 Kbps à 203 Kbps (soit un facteur 10).

En choisissant des options qui permettent une compression plus rapide (ce qui peut être utile pour une utilisation interactive de type videoconference), on perd encore en qualité:

gst-launch filesrc location=webcam.avi ! decodebin ! queue ! ffmpegcolorspace ! x264enc byte-stream=true bitrate=200 bframes=4 ref=1 me=dia subme=1 weightb=true threads=0 ! avimux ! filesink location=webcam-x264-12.avi

On compare le résultat par rapport aux paramètres précédant:

La consommation de bande passante entre les deux tests est la même (203 Kbps). Seul le temps d'encodage diffère (gain de 25%).

Enfin on paramètre X.264 pour améliorer la qualité (donc au détriment du temps d'encodage):

gst-launch filesrc location=webcam.avi ! decodebin ! queue ! ffmpegcolorspace ! x264enc byte-stream=true bitrate=200 bframes=4 ref=8 me=umh subme=6 weightb=true threads=0 ! avimux ! filesink location=webcam-x264-13.avi

On compare le résultat par rapport aux paramètres du test 11:

La qualité est légèrement meilleure (difficile à voir sur cette image), le débit identique, par contre le délais d'encodage bondit de plus de 100%.

Pour résumé, les paramètres suivant sont ceux qui offre le meilleur résultat pour mon besoin:

byte-stream=true bitrate=200 bframes=4 ref=4 me=hex subme=4 weightb=true threads=0

Ratio qualité/bande passante

Maintenant que nous avons identifié les "bons" paramètres pour notre besoin. Il faut jouer sur les paramètres externes pour trouver le bon ratio entre la qualité de l'image et la bande passante consommé lors du streaming de notre Webcam.

Les paramètres sur lesquels on a des leviers sont les suivants:

• taille de l'image (résolution)
• nombre d'images par seconde (fps)
• débit cible au niveau du codec X.264 (bitrate)

Comme je n'aime pas faire des choses répétitives (non non, ce n'est pas de la fainéantise...),  j'ai développé un petit script shell qui prend en entrée un fichier vidéo de référence, une liste de résolution (au format GStreamer), une liste de fps et une liste de débit. Le script va générer automatiquement les vidéos encodés avec ces différents paramètres.

Voici le script en question:

#!/bin/sh

# Je génére le fichier de référence avec la commande:
# sudo gst-launch v4l2src device="/dev/video1" ! queue ! videoscale method=1 ! video/x-raw-yuv,width=704,height=576 ! avimux ! filesink location=videotest.avi

videosrc="./videotest.avi"
reslist="width=704,height=576 width=352,height=288 width=176,height=144 width=128,height=96"
fpslist="24 12 6 3"
bitratelist="400 300 200 100 50"

for res in `echo $reslist`
do
 resname=`echo $res | sed "s/width=//" | sed "s/height=//" | sed "s/,/x/"`
 for fps in `echo $fpslist`
 do
  for bitrate in `echo $bitratelist`
  do
   echo videotest-${resname}-${fps}fps-${bitrate}kbps.avi
   gst-launch filesrc location=$videosrc ! decodebin ! ffmpegcolorspace ! queue ! cairotextoverlay text="${resname} ${fps}fps ${bitrate}kbps" shaded-background=true ! queue ! videorate ! video/x-raw-yuv,framerate=$fps/1 ! queue ! videoscale method=1 !  video/x-raw-yuv,$res ! queue ! ffmpegcolorspace ! x264enc byte-stream=true bitrate=$bitrate bframes=4 ref=4 me=hex subme=4 weightb=true threads=0 ! avimux ! filesink location=videotest-${resname}-${bitrate}kbps-${fps}fps.avi
  done
 done
done

J'obtient les résultats suivants:

videotest-704x576-50kbps-6fps.avi donne un débit moyen de 41 kb/s
videotest-352x288-50kbps-3fps.avi donne un débit moyen de 42 kb/s
videotest-352x288-50kbps-6fps.avi donne un débit moyen de 42 kb/s
videotest-704x576-50kbps-3fps.avi donne un débit moyen de 43 kb/s
videotest-176x144-50kbps-3fps.avi donne un débit moyen de 44 kb/s
videotest-128x96-50kbps-3fps.avi donne un débit moyen de 45 kb/s
videotest-176x144-50kbps-6fps.avi donne un débit moyen de 46 kb/s
videotest-128x96-50kbps-6fps.avi donne un débit moyen de 47 kb/s
videotest-352x288-50kbps-12fps.avi donne un débit moyen de 47 kb/s
videotest-704x576-50kbps-12fps.avi donne un débit moyen de 47 kb/s
videotest-176x144-50kbps-12fps.avi donne un débit moyen de 51 kb/s
videotest-128x96-50kbps-12fps.avi donne un débit moyen de 52 kb/s
videotest-352x288-50kbps-24fps.avi donne un débit moyen de 53 kb/s
videotest-704x576-50kbps-24fps.avi donne un débit moyen de 53 kb/s
videotest-176x144-50kbps-24fps.avi donne un débit moyen de 54 kb/s
videotest-128x96-50kbps-24fps.avi donne un débit moyen de 56 kb/s
videotest-128x96-100kbps-3fps.avi donne un débit moyen de 73 kb/s
videotest-704x576-100kbps-6fps.avi donne un débit moyen de 76 kb/s
videotest-352x288-100kbps-3fps.avi donne un débit moyen de 81 kb/s
videotest-352x288-100kbps-6fps.avi donne un débit moyen de 81 kb/s
videotest-704x576-100kbps-3fps.avi donne un débit moyen de 84 kb/s
videotest-176x144-100kbps-3fps.avi donne un débit moyen de 86 kb/s
videotest-128x96-200kbps-3fps.avi donne un débit moyen de 87 kb/s
videotest-128x96-300kbps-3fps.avi donne un débit moyen de 87 kb/s
videotest-128x96-400kbps-3fps.avi donne un débit moyen de 87 kb/s
videotest-128x96-100kbps-6fps.avi donne un débit moyen de 88 kb/s
videotest-704x576-100kbps-12fps.avi donne un débit moyen de 89 kb/s
videotest-352x288-100kbps-12fps.avi donne un débit moyen de 91 kb/s
videotest-704x576-100kbps-24fps.avi donne un débit moyen de 93 kb/s
videotest-176x144-100kbps-6fps.avi donne un débit moyen de 94 kb/s
videotest-176x144-100kbps-12fps.avi donne un débit moyen de 99 kb/s
videotest-352x288-100kbps-24fps.avi donne un débit moyen de 99 kb/s
videotest-128x96-100kbps-12fps.avi donne un débit moyen de 101 kb/s
videotest-176x144-100kbps-24fps.avi donne un débit moyen de 103 kb/s
videotest-128x96-100kbps-24fps.avi donne un débit moyen de 104 kb/s
videotest-128x96-200kbps-6fps.avi donne un débit moyen de 125 kb/s
videotest-128x96-300kbps-6fps.avi donne un débit moyen de 130 kb/s
videotest-128x96-400kbps-6fps.avi donne un débit moyen de 131 kb/s
videotest-176x144-200kbps-3fps.avi donne un débit moyen de 136 kb/s
videotest-704x576-200kbps-6fps.avi donne un débit moyen de 150 kb/s
videotest-176x144-300kbps-3fps.avi donne un débit moyen de 151 kb/s
videotest-176x144-400kbps-3fps.avi donne un débit moyen de 152 kb/s
videotest-352x288-200kbps-6fps.avi donne un débit moyen de 161 kb/s
videotest-352x288-200kbps-3fps.avi donne un débit moyen de 162 kb/s
videotest-704x576-200kbps-3fps.avi donne un débit moyen de 165 kb/s
videotest-176x144-200kbps-6fps.avi donne un débit moyen de 170 kb/s
videotest-128x96-200kbps-12fps.avi donne un débit moyen de 174 kb/s
videotest-352x288-200kbps-12fps.avi donne un débit moyen de 174 kb/s
videotest-704x576-200kbps-12fps.avi donne un débit moyen de 174 kb/s
videotest-704x576-200kbps-24fps.avi donne un débit moyen de 187 kb/s
videotest-128x96-300kbps-12fps.avi donne un débit moyen de 188 kb/s
videotest-128x96-400kbps-12fps.avi donne un débit moyen de 188 kb/s
videotest-128x96-200kbps-24fps.avi donne un débit moyen de 191 kb/s
videotest-352x288-200kbps-24fps.avi donne un débit moyen de 192 kb/s
videotest-176x144-200kbps-12fps.avi donne un débit moyen de 193 kb/s
videotest-176x144-200kbps-24fps.avi donne un débit moyen de 199 kb/s
videotest-176x144-300kbps-6fps.avi donne un débit moyen de 202 kb/s
videotest-128x96-300kbps-24fps.avi donne un débit moyen de 211 kb/s
videotest-128x96-400kbps-24fps.avi donne un débit moyen de 215 kb/s
videotest-176x144-400kbps-6fps.avi donne un débit moyen de 216 kb/s
videotest-704x576-300kbps-6fps.avi donne un débit moyen de 220 kb/s
videotest-352x288-300kbps-3fps.avi donne un débit moyen de 235 kb/s
videotest-704x576-300kbps-3fps.avi donne un débit moyen de 245 kb/s
videotest-352x288-300kbps-6fps.avi donne un débit moyen de 249 kb/s
videotest-704x576-300kbps-12fps.avi donne un débit moyen de 262 kb/s
videotest-352x288-300kbps-12fps.avi donne un débit moyen de 265 kb/s
videotest-176x144-300kbps-12fps.avi donne un débit moyen de 272 kb/s
videotest-704x576-300kbps-24fps.avi donne un débit moyen de 278 kb/s
videotest-176x144-300kbps-24fps.avi donne un débit moyen de 289 kb/s
videotest-352x288-300kbps-24fps.avi donne un débit moyen de 293 kb/s
videotest-704x576-400kbps-6fps.avi donne un débit moyen de 297 kb/s
videotest-352x288-400kbps-3fps.avi donne un débit moyen de 298 kb/s
videotest-176x144-400kbps-12fps.avi donne un débit moyen de 301 kb/s
videotest-704x576-400kbps-3fps.avi donne un débit moyen de 318 kb/s
videotest-352x288-400kbps-6fps.avi donne un débit moyen de 336 kb/s
videotest-176x144-400kbps-24fps.avi donne un débit moyen de 339 kb/s
videotest-704x576-400kbps-12fps.avi donne un débit moyen de 346 kb/s
videotest-352x288-400kbps-12fps.avi donne un débit moyen de 355 kb/s
videotest-704x576-400kbps-24fps.avi donne un débit moyen de 373 kb/s
videotest-352x288-400kbps-24fps.avi donne un débit moyen de 385 kb/s

Si on se focalise sur un nombre d'images par seconde de 12 et une résolution CIF (ce qui est suffisant pour une besoin de type vidéoconférence), on obtient les qualités suivantes:

Dévit cible: 50 Kbps / Débit mesuré: 47 Kbps

Dévit cible: 100 Kbps / Débit mesuré: 91 Kbps

Dévit cible: 200 Kbps / Débit mesuré: 174 Kbps

Dévit cible: 300 Kbps / Débit mesuré: 265 Kbps

Dévit cible: 400 Kbps / Débit mesuré: 355 Kbps

On peut voir que la qualité augmente moins à partir d'un débit cible de 200 Kbps.

On teste enfin le streaming

Pas la peine de réinventer la roue, j'avais déjà écrit un billet sur le sujet. Si l'on souhaite faire un streaming RTP entre deux machines en prenant en compte l'optimisation X.264 décrite dans les chapitres précédant, il faut saisir les commandes suivantes:

Sur le serveur (192.168.1.1):

gst-launch -v  gstrtpbin name=rtpbin \
v4l2src \
! queue ! videoscale method=1 ! video/x-raw-yuv,width=352,height=288 \
! queue ! videorate ! video/x-raw-yuv,framerate=\(fraction\)12/1 \
! queue ! x264enc byte-stream=true bitrate=200 bframes=4 ref=4 me=hex subme=4 weightb=true threads=0 ! rtph264pay \
! rtpbin.send_rtp_sink_0 \
rtpbin.send_rtp_src_0 ! udpsink port=5000 host=192.168.1.2 \
rtpbin.send_rtcp_src_0 ! udpsink port=5001 host=192.168.1.2 sync=false async=false \
udpsrc port=5002 ! rtpbin.recv_rtcp_sink_0

Puis sur le client (192.168.1.2):

gst-launch -v gstrtpbin name=rtpbin latency=200 \
udpsrc caps="application/x-rtp, media=(string)video,
clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96" 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=192.168.0.1 sync=false async=false

Conclusion

Comme toujours dans ce genre d'exercice, le paramétrage des codecs vidéos dépend de votre source (on n'encode pas de la même manière le flux CIF venant d'une Webcam ou un fichier vidéo HD...). On a ici trouvé un bon compromis entre qualité d'affichage et bande passante consommée sur le réseau. Etant loin d'être un spécialiste sur le sujet, il y a surement des optimisations à faire. Les commentaires sont fait pour ça !

GStreamer étant un framework, il se base sur de nombreuses librairies externes. Pour nous simplifier la tache, nous allons utiliser les dépôts pour l'installation de ces librairies:

sudo aptitude build-dep gstreamer0.10-ffmpeg gstreamer0.10-plugins-bad gstreamer0.10-plugins-bad-multiverse gstreamer0.10-plugins-base gstreamer0.10-plugins-good gstreamer0.10-plugins-ugly gstreamer0.10-plugins-ugly-multiverse bison flex

Ensuite on récupère les dernières versions disponibles de GStreamer et de ses plugins:

mkdir ~/src
cd ~/src
wget http://gstreamer.freedesktop.org/src/gstreamer/gstreamer-0.10.23.tar.gz
wget http://gstreamer.freedesktop.org/src/gst-plugins-bad/gst-plugins-bad-0.10.12.tar.gz
wget http://gstreamer.freedesktop.org/src/gst-plugins-base/gst-plugins-base-0.10.23.tar.gz
wget http://gstreamer.freedesktop.org/src/gst-plugins-good/gst-plugins-good-0.10.15.tar.gz
wget http://gstreamer.freedesktop.org/src/gst-plugins-ugly/gst-plugins-ugly-0.10.11.tar.gz

On commence par la compilation de GStreamer (core). L'installation se fera dans le répertoire /opt/gstreamer/gstreamer-0.10.23:

tar zxvf gstreamer-0.10.23.tar.gz
cd gstreamer-0.10.23
./configure --prefix=/opt/gstreamer/gstreamer-0.10.23
make
sudo make install
cd ..

... puis les plugins "base":

tar zxvf gst-plugins-base-0.10.23.tar.gz
cd gst-plugins-base-0.10.23
PKG_CONFIG_PATH=/opt/gstreamer/gstreamer-0.10.23/lib/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig ./configure --prefix=/opt/gstreamer/gstreamer-0.10.23
make
sudo make install
cd ..

... puis les plugins "good":

tar zxvf gst-plugins-good-0.10.15.tar.gz
cd gst-plugins-good-0.10.15
PKG_CONFIG_PATH=/opt/gstreamer/gstreamer-0.10.23/lib/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig ./configure --prefix=/opt/gstreamer/gstreamer-0.10.23
make
sudo make install
cd ..

... puis les plugins "bad":

tar zxvf gst-plugins-bad-0.10.12.tar.gz
cd gst-plugins-bad-0.10.12
PKG_CONFIG_PATH=/opt/gstreamer/gstreamer-0.10.23/lib/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig ./configure --prefix=/opt/gstreamer/gstreamer-0.10.23
make
sudo make install
cd ..

... et enfin les plugins "ugly":

tar zxvf gst-plugins-ugly-0.10.11.tar.gz
cd gst-plugins-ugly-0.10.11
PKG_CONFIG_PATH=/opt/gstreamer/gstreamer-0.10.23/lib/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig ./configure --prefix=/opt/gstreamer/gstreamer-0.10.23
make
sudo make install
cd ..

Puis on créé un lien symbolique entre le répertoire /opt/gstreamer/current et /opt/gstreamer/gstreamer-0.10.23. Ce lien nous permet d'avoir plusieur version de GStreamer sur notre système.

sudo ln -s /opt/gstreamer/gstreamer-0.10.23 /opt/gstreamer/current

On commence par l'installer (par exemple à partir des dépôts sous Ubuntu):

sudo apt-get install drapes

On lance ensuite l'application via le menu Système / Préférences / Desktop Drapes, un nouvel icône va s'afficher dans la barre de menu. Un clic droit dessus pour accéder aux préférences:

Et voilà le travail, un nouveau fond d'écran toutes les 2 heures...

Mise en place du test

Pour tester ce codec, j'utilise le framework GStreamer et deux scripts shell tournant sur deux machines différentes. Le script rtpserver.sh prend comme source le microphone par défaut de votre machine, encode le flux en Speex, puis le diffuse en RTP/UDP vers la seconde machine. Le script rtpclient.sh récupére le flux RTP/UDP venant de la première machine, le décode et le diffuse sur la sortie son par défaut.

Le script rtpserver.sh:

#!/bin/sh

SEND_TO_ADDR=192.168.29.111
SEND_TO_RTP_PORT=5003
SEND_TO_RTCP_PORT=5004
RECV_FROM_RTCP_PORT=5005

ENCODER=speexenc
PAYLOADER=rtpspeexpay

SPEEX_PARAMS="quality=4 vad=true dtx=true"
SPEEX_CAPS="audio/x-raw-int,rate=16000"

ENCODER_PARAMS=${SPEEX_PARAMS}
RTP_PARAMS="latency=200"
AUDIO_CAPS=${SPEEX_CAPS}

gst-launch -v  gstrtpbin name=rtpbin ${RTP_PARAMS} \
alsasrc \
! queue ! audioresample ! ${AUDIO_CAPS} ! ${ENCODER} ${ENCODER_PARAMS} ! ${PAYLOADER} \
! rtpbin.send_rtp_sink_1 \
rtpbin.send_rtp_src_1 ! udpsink port=${SEND_TO_RTP_PORT} host=${SEND_TO_ADDR} \
rtpbin.send_rtcp_src_1 ! udpsink port=${SEND_TO_RTCP_PORT} host=${SEND_TO_ADDR} sync=false async=false \
udpsrc port=${RECV_FROM_RTCP_PORT} ! rtpbin.recv_rtcp_sink_1

Le script rtpclient.sh:

#!/bin/sh

SEND_TO_RTCP_PORT=5005
RECV_FROM_ADDR=192.168.29.146
RECV_FROM_RTP_PORT=5003
RECV_FROM_RTCP_PORT=5004
AUDIORATE=16000

gst-launch-0.10 -v gstrtpbin name=rtpbin latency=200 \
udpsrc caps="application/x-rtp, media=(string)audio, clock-rate=(int)${AUDIORATE}, encoding-name=(string)SPEEX, encoding-params=(string)1, ssrc=(guint)419764010, payload=(int)110, clock-base=(guint)3478167082, seqnum-base=(guint)57894" port=${RECV_FROM_RTP_PORT} \
! rtpbin.recv_rtp_sink_1 \
rtpbin. ! rtpspeexdepay ! decodebin ! alsasink \
udpsrc port=${RECV_FROM_RTCP_PORT} ! rtpbin.recv_rtcp_sink_1 \
rtpbin.send_rtcp_src_1 ! udpsink port=${SEND_TO_RTCP_PORT} host=${RECV_FROM_ADDR} sync=false async=false

Attention, il faut lancer le script rtpclient.sh avant le rtpserver.sh . Les variables suivantes sont modifiables dans les scripts:

Script rtpserver.sh:
SEND_TO_ADDR: Adresse IP du client
SEND_TO_RTP_PORT: Numéro de port sur lequel les paquets RTP seront envoyés
SEND_TO_RTCP_PORT: Numéro de port sur lequel les paquets RTCP seront envoyés
RECV_FROM_RTCP_PORT: Numéro de port sur lequel les paquets RTCP seront reçus
SPEEX_PARAMS: Paramètres du plugin d'encodage Speexenc
SPEEX_CAPS: Caps du flux audio (audio rate)

Script rtpclient.sh:
SEND_TO_RTCP_PORT: Numéro de port sur lequel les paquets RTCP seront envoyés
RECV_FROM_ADDR:  Adresse IP du serveur
RECV_FROM_RTP_PORT: Numéro de port sur lequel les paquets RTP seront reçus
RECV_FROM_RTCP_PORT: Numéro de port sur lequel les paquets RTCP seront reçus
AUDIORATE: Audio rate, mettre la même valeur que celle dans le caps du serveur

Résultats des tests

Le premier test a été effectué avec un audio rate de 44000 (bref un taux d'échantillonnage proche de celui d'un CD audio).

Paramètres:
rate=44000 / vad=false / dtx=false
Tests:
En jouant sur l'option quality, on obtient
quality=10 -> bande passante de 80 Kbps
quality=8 -> bande passante de 60 Kbps
quality=6 -> bande passante de 50 Kbps
quality=4 -> bande passante de 40 Kbps
quality=3 -> bande passante de 36 Kbps
quality=2 -> bande passante de 35 Kbps
Conclusion:
On obtient une dégradation de la qualité de réception de la voix en dessous d'une valeur de quality de 4. Il est clairement dit dans la documentation que la qualité > 4 son a réserver pour les sources audio plus complexes que la voix humaine (musique, film...). Par contre la consommation de CPU est plus importante (rapport de 5 contre 1 entre quality=10 et quality=1).
La bande passante est constante (à quelques Kbps) que l'on parle ou que l'on ne parle pas.

Paramètres:
En jouant sur les paramètres vad et dtx, on va essayer d'optimiser la bande passante en gardant la même qualité.
VAD (dixit Wiki): "Quand cette option est activé, le VAD détecte quand l'audio encodé est du dialogue ou du silence/bruit de fond. VAD est toujours implicitement activé en encodage VBR, donc cette option est utile uniquement en mode non VBR. Dans ce cas Speex détecte les périodes sans dialogue et les encode avec le strict minimum de bits pour reproduire le bruit de fond. Cette fonction est appelée Comfort Noise Generation (CNG)."
DTX (dixit Wiki): "la transmission discontinue est une fonctionnalité qui s'ajoute aux
opérations de VAD et de VBR, qui permet de couper la transmission
complètement quand le bruit de fond est stationnaire. Dans un fichier,
5 bits sont utilisés pour chaque frame manquante (correspondant à 250 bits/s)"
Tests:
On ajoute les paramètres vad=true et dtx=true au niveau du serveur (SPEEX_PARAMS)
La bande passante reste la même (40 Kbps) quand on parle, par contre elle passe à 23 Kbps quand on ne parle pas.
Conclusion:
Les algorithmes VAD et DTX fonctionnent très bien. Ils permettent de gagner de la bande passante quand l'activité au niveau sonore est faible (ce qui est le cas dans une conversation ou, normalement, une seule personne parle à un instant t).

En conservant les paramètres du premier test (quality=4, vad=true, dtx=true), on change seulement l'audio rate (au niveau du serveur et du client).

Paramètres:
rate=16000
Tests:
Bande passante de 28 Kbps lorsque l'on parle, 17 Kbps pendant les silences.
Conclusion:
La qualité reste excellente. Sur une conversation (voix humaine), on ne voit pas la différence avec un rate de 44000 (44 KHz).

Paramètres:
rate=8000
Tests:

Bande passante de 23 Kbps lorsque l'on parle, 16 Kbps pendant les silences.

Conclusion:
La qualité est dégradée mais la conversation reste compréhensible. On gagne seulement 5 Kbps par rapport au test précédant.

Pour conclure

D'après les tests effectués, le meilleur compromis bande passante qualité est:

• audio rate = 16000 (16 Khz)
• quality = 4
• vad = true
• dtx = true