• Le Livre de Packet Filter vient de sortir en version FR
• 14 effets de visualisation pour iTunes
• Comment redimensionner des lots d'images dans Gnome directement depuis Nautilus...
• 20 thèmes Wordpress beaux et gratuits...
• 35 photos macro de toute beauté...

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

• Un assureur en ligne avec un site très Web 2.0 (merci tux-planet...)

• Script shell pour ne plus avoir les erreurs PUBKEY de dépôts PPA.

• Thèmes zgegblog pour GNU/Linux Ubuntu

• NConf, enfin une couche Web acceptable pour Nagios (à essayer...)

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...

• Compilation du kernel Linux sous Ubuntu

• Un fil de discussion très intéressant sur le comment de la sécurisation d'un système FreeBSD.

• Comment libérer un peu d'espace disque sur son Mac...

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 !