Le discours de Steve Jobs à Stanford en VOSTFR
Catégorie : Hardware
En début de semaine, j’ai été emmenée à donner un cours d’introduction aux technologies de Cloud Computing à l’école supérieure des ingénieurs de Luminy (ESIL à Marseille). Le sujet étant vaste pour les trois petites heures imparties, j’ai préféré axer mon cours sur certains aspects (notamment les architectures IAAS et l’utilisation de technologies ouvertes et libres).
Pour ceux que cela intéresse, voici (sous licence « CC By:« ):
- le support de présentation en téléchargement au format PDF
- le support de présentation de ce cours sur SlideShare
Au passage un grand merci à Philippe Scoffoni pour sa relecture et ses remarques.
La configuration de la résolution de l’écran ou d’un vidéo projecteur a toujours été un problème pour les « nons initiés », recherches des paramètres sur le Web, configuration de Xorg… Heureusement, l’arrivée des ports « numériques » (DVI / HDMI) permettent de ne plus se soucier de cette configuration car les paramètres optimaux sont négociés automatiquement entre l’écran et le système. Il existe néanmoins des cas ou un une configuration manuelle est encore nécessaire: utilisation d’un PC avec une interface RGB, écran non reconnu par le système (vidéo projecteur ou écran de télévision)… Nous allons donc dans ce billet voir comment utiliser des outils simples pour optimiser l’affichage de son système GNU/Linux sur n’importe quel écran.
xrandr est ton ami
xrandr est un projet de la fondation X.org. C’est à la fois un protocole et un logiciel permettant de paramétrer l’affichage de vos écrans: résolution, fréquence, rotation, multi-écran…
Détection des écrans
On commence par détecter les écran disponible avec la commande suivante:
[shell]
xrandr
Screen 0: minimum 320 x 200, current 1360 x 768, maximum 8192 x 8192
VGA1 connected 1360×768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
1360×768 59.8*
1024×768 60.0
800×600 60.3 56.2
848×480 60.0
640×480 59.9 59.9
xrandrScreen 0: minimum 320 x 200, current 1360 x 768, maximum 8192 x 8192VGA1 connected 1360×768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1360×768 59.8* 1024×768 60.0 800×600 60.3 56.2 848×480 60.0 640×480 59.9 59.9
[/shell]
On peut voir que le PC dispose d’une sortie VGA (nommée VGA1) avec un écran branché dessus (connected) à une résolution de 1360×768 (à 59.8 Hz). L’écran en question est en fait un HP LP2465 supportant une résolution full-hd de 1920×1200… il y a donc une coquille à résoudre…
Création d’une nouvelle configuration
On utilise pour cela un deuxième logiciel nommé gtf qui va permettre de générer pour vous une nouvelle configuration d’écran. gtf demande en paramètre la résolution et la fréquence souhaités (par exemple 1920×1200 à une résolution de 60 Hz):
[shell]
gtf 1920 1200 60
# 1920×1200 @ 60.00 Hz (GTF) hsync: 74.52 kHz; pclk: 193.16 MHz
Modeline "1920x1200_60.00" 193.16 1920 2048 2256 2592 1200 1201 1204 1242 -HSync +Vsync
[/shell]
Il faut mettre la ligne suivante de coté:
[shell]
"1920x1200_60.00" 193.16 1920 2048 2256 2592 1200 1201 1204 1242 -HSync +Vsync
[/shell]
Application de la nouvelle configuration
On utilise pour cela le logiciel xrandr, d’abord en créant la nouvelle configuration dans le système:
[shell]
xrandr –newmode "1920x1200_60.00" 193.16 1920 2048 2256 2592 1200 1201 1204 1242 -HSync +Vsync
[/shell]
On ajoute cette nouvelle configuration à l’interface VGA1:
[shell]
xrandr –addmode VGA1 1920x1200_60.00
[/shell]
Puis on force l’interface VGA1 à utiliser cette nouvelle configuration:
[shell]
xrandr –output VGA1 –mode 1920x1200_60.00
[/shell]
Si tout ce passe comme prévu, l’écran devrait passer dans la nouvelle résolution. On peut vérifier celà par la ligne de commande:
[shell]
xrandr
Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 8192 x 8192
VGA1 connected 1920×1200+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
1360×768 59.8
1024×768 60.0
800×600 60.3 56.2
848×480 60.0
640×480 59.9 59.9
1920x1200_60.00 60.0*
[/shell]
Sources
- Pour une configuration multi-écran: http://manual.sidux.com/fr/hw-dev-mon-fr.htm
- Article en Anglais: http://www.arunviswanathan.com/node/53
- La doc sur ubuntu-fr: http://doc.ubuntu-fr.org/xrandr
Je viens de recevoir un casque/micro Logitech ClearChat Pro USB. Spécialisé dans les applications chat (conversation, jeux vidéo…), il n´est pas fait pour les conversations téléphoniques (ce n´est pas un casque téléphonique sans fil, non plus), il peut cependant être utilisé pour écouter de la musique (bien qu’il existe de meilleur casque Hifi pour cette utilisation).
Sur la boîte, Logitech donne comme pré-requis l’utilisation d’un système d’exploitation de type Windaube ou MacOS X… Nous allons voir que ce casque fonctionne très bien sur une Ubuntu 10.04 et sans avoir à installer un quelconque driver.
Pour une vidéo de présentation du casque, vous pouvez regarder celle faite par OSGui:
Logitech ClearChat Pro USB Unboxing Review & Ubuntu Linux Tutorial
Voici le bloc note de l’installation de la dernière version d’Ubuntu « Server » (Lucid 10.04) sur un HP Proliant DL160 G6.
En route…
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 (1280×800 / 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.
Je viens de recevoir une clés USB de 32 Go (que l’on trouve sur le web pour moins de 100 Euros). Je souhaite y installer deux partitions: la première de 5 Go permettra d’y installer un système live Ubuntu, l’autre de 25 Go pour y stocker mes données au format FAT32 (pour rester compatible avec le monde Windaube and co).
Attention: les opérations suivantes vont effacer le contenu de votre clés USB, pensez donc à faire un backup…
Si vous lisez régulièrement ce blog, vous savez que je m’intéresse au FrameWork multimédia GStreamer (cliquez ici pour voir la liste des billets sur le sujet). Nous allons poursuivre la découverte de cette superbe trousse à outil multimédia en l’appliquant sur la récupération et l’exploitation de flux vidéo venant de caméras IP. Nous nous focaliserons ici sur les caméras IP AXIS, non pas que j’ai des actions dans cette société mais il faut avouer que leurs caméras sont de très bonne qualité et l’accès aux flux vidéos assez simple.
, non pas que j’ai des actions dans cette société mais il faut avouer que leurs caméras sont de très bonne qualité et l’accès aux flux vidéos assez simple.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:
La configuration de cette caméra (cam01) est la suivante:
Format CIF
Compression 50%
Frame rate: 25 images/s
Configuration du PC1:
Format CIF
Compression 50%
Frame rate: 25 images/s
Configuration du PC1:
OS: GNU/Linux Debian 5.0 + Gstreamer 0.10.19-3
Hardware: Pentium Quad core CPU 2.8 Ghz + 4 Go RAM
Configuration du PC2:
OS: GNU/Linux Ubuntu 8.10 + Gstreamer 0.10.21-4
Hardware: Pentium Dual core CPU 3.0 Ghz + 512 Mo RAM
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 !
Catégories
RAID 1 logiciel sous FreeBSD
Certains serveurs de votre réseau sont plus sensibles que d’autres: on peut citer par exemple les serveurs DNS, LDAP ou base de données. D’un autre coté les pannes matérielles survenant sur ces mêmes serveurs viennent souvent des disques durs. En partant de ces deux constats, je vous propose dans ce billet d’utiliser la fonction de RAID 1 logicielle de FreeBSD pour sécuriser ces serveurs.
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 !
dès aujourd’hui (mais seulement aux Etats-Unis) aux prix de $399 (soit environ 255 Euros)…
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 !