Voici un petit billet sur l'installation de la dernière version stable d'Ubuntu (Karmic 9.10) sur un PC portable Lenovo T500.

Installation du système (Ubuntu Karmic 9.10) sans aucun problème à partir du CD d'installation.

Après redémarrage du PC, fonctionnement "out of the box" (sans configuration) pour:

• Clavier (bouton son + luminosité)
• Trackpad / Trackpoint
• Affichage en 16:10 (1280x800 / 60Hz) avec support 3D
• Réseau Ethernet Gigabits (eth0)
• Réseau Wifi (bouton d'activation/désactivation fonctionnel)
• USB (3 ports disponibles)
• Lecteur/graveur CD et DVD
• Son (lecture et enregistrement)
• Bluetooth (bouton d'activation/désactivation fonctionnel)
• Webcam

Non testé:

• Modem
• Firewire

Le fonctionnement de la machine est très agréable, rapide et l'affichage stable et lisible.

Attention: les opérations suivantes vont effacer le contenu de votre clés USB, pensez donc à faire un backup...

Partitionnement de la clés USB

On commence par partitionner la clés USB grâce au logiciel gparted disponible sur les distributions GNU/Linux. Pour l'installer sous Ubuntu, voici la commande:

sudo aptitude install gparted

Une fois le logiciel lancé (via le menu Système / Administration)et la clés USB connectée sur votre machine on sélectionne le device correspondant à votre clés USB (attention de ne pas sélectionner votre disque dur ), c'est /dev/sdb dans mon cas. On clique ensuite sur le menu Périphérique / Créer une table de partition:

On se retrouve avec une périphérique sans partition:

on créer la deuxième partition FAT32 qui hébergera les données (lisible sous GNU/Linux, FreeBSD, Windows et Mac OS X).

On clique sur l'espace non alloué clique puis sur Partition / Nouveau:

On applique en cliquant sur le menu Edition / Appliquer toutes les modifications. (PS: sur ma version de gParted il y a un bug si je n'applique pas les changement à chaque partition...)

Enfin on créer la première partition FAT32 qui hébergera le système Ubuntu live. On clique sur l'espace non alloué clique puis sur Partition / Nouveau:

On applique en cliquant sur le menu Edition / Appliquer toutes les modifications.

On finalise la configuration de la clés en rendant la partition de 5 Go bootable et invisible, pour cela il faut faire un click droit sur cette partition et cliquer sur le menu Gérer les drapeaux puis sélectionner les flags BOOT et HIDDEN.

Installation d'Ubuntu

On commence par télécharger une image d'Ubuntu que l'on souhaite installer (.ISO) ou (encore mieux) on personnalise sa version live. Ensuite on lance l'utilitaire usb-creator par le menu Système / Administration / Créateur de disque de démarrage USB. On sélectionne l'image ISO téléchargée puis la partition USBKEYSYSTEM et enfin on clique sur Créer un disque de démarrage, je vous conseille de réserver au moins 3 Go pour le stockage des données/conf (espace réservé supplémentaire):

Conclusion

La clés USB est maintenant utilisable sous GNU/Linux et Windows (vous disposer alors d'un espace disque de 25 Go) et d'un système live Ubuntu (il suffit de redémarrer votre PC avec la clés dans une des prise USB).

Avant de nous plonger dans le vif du sujet et si vous souhaitez faire ces tests chez vous, il faut au préhalable installer GStreamer sur votre système.

Ma configuration de test est la suivante:

Lors de la rédaction de ce billet, j'ai utilisé la caméra AXIS 213:

Affichage du flux vidéo

Cette caméra (comme toutes les caméras AXIS) permet la diffusion sur le réseau en utilisant deux formats:

• MJPEG sur HTTP
• MPEG-4 sur RTSP

Affichage du flux MJPEG/HTTP

On lance la commande suivante sur la machine PC1:

gst-launch gnomevfssrc location=http://cam01/axis-cgi/mjpg/video.cgi?resolution=CIF ! jpegdec ! ffmpegcolorspace ! autovideosink

Un rapide ntop sur notre machine PC1 nous indique que le fux est gourmand en bande passante (de l'ordre de 3.3 Mbps). L'occupation CPU varie entre 20% et 60%. La vidéo est fluide.

Affichage du flux MPEG4/RTSP

On lance la commande suivante sur la machine PC1:

gst-launch-0.10 rtspsrc location=rtsp://cam01:554/mpeg4/media.amp latency=0 ! decodebin ! ffmpegcolorspace ! autovideosink

La bande passante entre la caméra et le PC1 est alors de 1 Mbps en pics (moyenne de 400 Kbps quand il y a peu de mouvement devant la caméra). L'occupation CPU varie entre 5% et 15%. La vidéo est fluide.

Le paramètre latency (qui est par défaut à 3000, soit 3 secondes) permet de réduire la taille du buffer d'entrée. Si vous êtes sur un réseau LAN, vous pouvez sans problème mettre comme valeur 0 (comme je l'ai fait dans mon exemple). Par contre sur des réseaux moins performant (en terme de débit, de perte de paquets...), il vaut mieux conserver un buffer un peu plus élevé.

Encodage du flux vidéo dans un fichier

Nous allons continuer notre test en essayant d'encoder "à la volée" le flux vidéo venant de la caméra IP. Détaillons un peu notre pipeline:

• récupérer le flux MPEG4/RTSP de la caméra
• l'afficher sur l'écran
• réduire le nombre d'images par seconde (fps) à 1
• encoder le flux en MJPG
• sauvegarder dans un fichier AVI (output.avi)

La ligne de commande correspondante à lancer sur PC1 est:

gst-launch rtspsrc location=rtsp://cam01:554/mpeg4/media.amp latency=0 ! queue ! decodebin ! ffmpegcolorspace ! tee name=save ! queue ! autovideosink save. ! queue ! videorate ! capsfilter caps="video/x-raw-yuv,framerate=(fraction)1/1" ! queue ! jpegenc ! avimux ! filesink location=output.avi .save

Le fichier généré (output.avi) occupe un espace disque d'environ 15 Ko par seconde (soit 54 Mo/heure).

Afin d'optimiser cette taille, il est possible d'utiliser Theora (dans un fichier OGG), un codec vidéo libre et efficace. La commande devient alors:

gst-launch rtspsrc location=rtsp://cam01:554/mpeg4/media.amp latency=0 ! queue ! decodebin ! ffmpegcolorspace ! tee name=save ! queue ! autovideosink save. ! queue ! videorate ! capsfilter caps="video/x-raw-yuv,framerate=(fraction)1/1" ! queue ! theoraenc ! oggmux ! filesink location=output.ogg .save

On a alors une taille de fichier de sortie (output/ogg) d'environ 6 Ko par seconde (soit 21 Mo/heure).

Mixer plusieurs vidéos en une

Si vous disposé de plusieurs caméras, il peut être utile de mixer ces différentes sources dans une même image (un peu comme le mode PIN des télévisions).

Je vais dans l'exemple ci-dessous, prendre deux sources (Camera AXIS + Webcam USB) et les mixer:

La pipeline est la suivante:

gst-launch  v4l2src ! queue ! videoscale ! capsfilter caps="video/x-raw-yuv,width=64,height=48,framerate=(fraction)5/1" ! ffmpegcolorspace ! videobox border-alpha=0 alpha=1.0 top=-230 left=-278 ! videomixer name=mix ! ffmpegcolorspace ! autovideosink mix. rtspsrc location=rtsp://cam01:554/mpeg4/media.amp latency=0 ! queue ! decodebin ! queue ! videorate ! capsfilter caps="video/x-raw-yuv,width=352,height=288,framerate=(fraction)25/1" ! ffmpegcolorspace ! mix.

Attention de bien fixer les framerates (videorate ou videoscale + capsfilter), car videomixer (le plugin qui s'occupe de faire le mixage vidéo) semble assez sensible sur ce point.

Streaming vers une autre machine

Nous allons maintenant voir comment transcoder le flux vidéo d'une caméra IP pour le diffuser (streamer vers une autre machine).

La description du pipeline du PC1 est la suivante:

• récupérer le flux MPEG4/RTSP de la caméra
• réencodage en Theora (à 250 Kbps)
• diffusion en UDP vers le PC2

puis celle du PC2:

• récupérer de flux Theora/UDP venant du PC1
• décodage Theora
• affichage de la vidéo

et les commandes correspondantes, sur le PC2 (il faut lancer cette commande en premier):

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

puis sur le PC1:

gst-launch rtspsrc location=rtsp://cam01:554/mpeg4/media.amp latency=0 ! queue ! decodebin ! ffmpegcolorspace ! queue ! videorate ! capsfilter caps="video/x-raw-yuv,framerate=(fraction)25/1" ! queue ! theoraenc bitrate=250 ! queue ! udpsink host=pc2 port=1234

En moyenne, le débit observé entre PC1 et PC2 est de l'ordre de 250 Kbps (conforme donc a ce que l'on a configuré dans le plugin theoraenc), on observe cependant des pics à 250 Kps+30%. La consommation de CPU est de l'ordre de 25% sur PC1 et de 5% sur PC2. La vidéo est recue de manière fluide sur le PC2. Là encore, il ne faut pas oublier de fixer le nombre d'images par seconde avec videorate + capsfilter.

L'avantage avec GStreamer, c'est qu'il intégre une liste de plugins assez impressionnante, il est alors facile de les insérer dans notre pipeline. Par exemple, si l'on souhaite reprendre l'exemple ci-dessus et y ajouter un texte en sur-impression (overlay), il suffit d'utiliser le plugin cairotextoverlay.

La commande sur le PC1 devient alors:

gst-launch-0.10 rtspsrc location=rtsp://cam01:554/mpeg4/media.amp latency=0 ! queue ! decodebin ! ffmpegcolorspace ! queue ! cairotextoverlay text="Attention Tigrou !" shaded-background=true ! queue ! videorate ! capsfilter caps="video/x-raw-yuv,framerate=(fraction)25/1" ! queue ! theoraenc bitrate=250 ! queue ! udpsink host=pc2 port=1234

et le résultat sur PC2:

Pour conclure

Ce billet nous a permis de mettre le pied dans le monde passionnant du traitement des flux vidéo. Ce n'est qu'une introduction et la seule limite est votre imagination. Je vous rappelle que GStreamer peut être simplement intégré à vos applications grâce aux API disponibles. Si vous avez des questions et remarques sur le sujet, il existe une section spéciale dans le forum !

Petit rappel sur RAID 1

Le RAID 1 consiste à utiliser n disques redondants (n supérieur ou égal à 2). Chaque disque contient la même information.

Dans notre exemple, nous allons utiliser une configuration minimale pour du RAID 1: deux disques de taille et de caractéristiques équivalentes.

Préparation de l'installation

Il faut dans un premier temps identifier les disques sur lequel de RAID 1 va être installé. Pour celà la commande dmesg devrait vous aider:

# dmesg

ad4: 76319MB <WDC WD800AAJS-70TDA1 01.00A03> at ata2-master SATA150

ad6: 76319MB <WDC WD800AAJS-70TDA1 01.00A03> at ata3-master SATA150

Nous avons donc deux disques: ad4 et ad6.

Ensuite on regarde ou le système est installé:

# df

/dev/ad4s1a 71621288 1044946 64846640 2% /

FreeBSD est donc installé sur le disque ad4. Nous allons donc nous servir du disque ad6 pour créer le disque mirroir de ad4.

Configuration du RAID 1 sous FreeBSD

Nous allons utiliser l'utilitaire gmirror pour effectuer le "mirroring" de ad4 vers ad6.

La première chose à faire est de vérifier que votre version de FreeBSD supporte cette fonction.

# man gmirror

Si c'est le cas, le manuel de la commande devrait s'afficher.

On commence par préparer le disque "maître" (ad4 dans notre exemple):

# sysctl kern.geom.debugflags=17

# gmirror label -vb round-robin gm0 /dev/ad4

Le résultat de cette dernière commande devrait être:

Metadata value stored on /dev/ad4.

Done.

On charge ensuite le module gmirror dans le kernel.

# gmirror load

Si vous n'avez pas de message d'erreur vous pouvez automatiser le chargement du module au prochain démarrage du serveur en tapant la commande suivante:

# echo 'geom_mirror_load="YES"' >> /boot/loader.conf

On vient de créer un disque virtuel nommé gm0. Il faut donc remplacer, dans le fichier /etc/fstab, toutes les occurrences /dev/ad4 par /dev/mirror/gm0. Pour cela on utilise vi:

# cp /etc/fstab /etc/fstab.old

# vi /etc/fstab

:%s/ad4/mirror\/gm0/g

On redémarre ensuite le serveur:

# shutdown -r now

Une fois le serveur rebooté, il ne reste plus qu'a ajouter le disque ad6 (notre disque "esclave") dans le mirroir RAID 1 (gm0).

# gmirror insert gm0 /dev/ad6

Vérification de l'état du RAID 1

On peut utiliser la commande suivante:

# gmirror status

Durant l'initialisation du disque esclave, le résultat devrait ressembler à:

Name Status Components

mirror/gm0 DEGRADED ad4

ad6 (1%)

Ensuite, le message suivant devrait apparaître:

Name Status Components

mirror/gm0 COMPLETE ad4

ad6

Et si un de mes disques plantes ?

Imaginons que le disque primaire (ad4) rende l'âme. Il suffit:

• éteindre le serveur
• retirer le disque ad4
• le remplacer par un disque équivalent
• redémarrer le serveur
• Saisir les commande suivantes pour reconstruire le disque:

# gmirror forget gm0

# gmirror insert gm0 /dev/ad4

Il ne reste plus qu'a superviser votre RAID 1 avec votre serveur Nagios !

Le téléphone en question, FreeRuner de son petit nom, est basé sur OpenMoko, un système d'exploitation open-source.

Vivement que cela arrive en France !