Autour de Linux

Il y a quelques semaines, un des abonnés de la mailing-list Ubuntu-fr demandait comment ajouter un routage de manière permanente. Voici ma solution.

Mon PC possède l’adresse 172.17.10.247 et l’accès à Internet se fait via un gateway ayant comme adresse IP 172.17.10.3. Un deuxième réseau est raccordé au premier et une passerelle permet d’y avoir accès depuis le premier réseau. L’adresse de la passerelle est 172.17.10.141.
La commande suivante permet de créer une route:

route add -net 172.17.250.0/24 gw 172.17.10.141 dev eth0

Cette commande crée une route qui permet l’accès au réseau 172.17.250.xx grâce à la passerelle 172.17.10.141. Cette route disparaîtra au prochain reboot. Pour la rendre permanente, il suffit de l’ajouter au fichier /etc/network/interfaces de cette façon:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

iface eth0 inet static
address 172.17.10.247
netmask 255.255.255.0
broadcast 172.17.10.255
gateway 172.17.10.3

# static route
up route add -net 172.17.250.0/24 gw 172.17.10.141 dev eth0

Il suffit ensuite de redémarrer le réseau:

/etc/init.d/networking restart

Il y a bien d’autres façons de faire mais je crois que celle-ci est la plus simple.

Il est possible en une seule ligne de coder un serveur web avec Python.

$ python -c 'import SimpleHTTPServer;SimpleHTTPServer.test()'

Ceci lance un serveur web accessible sur le port 8000. Tapez http://localhost:8000/ dans la barre d’adresse de votre browser pour qu’il affiche le fichier index.html contenu dans le répertoire depuis lequel vous lancer la commande.
Vu sur crashdump.fr

Lorsque l’on utilise sudo,gksudo ou gksu, on entre son mot de passe et on obtient un accès root à tout pendant 5 minutes. Ce n’est pas d’une sécurité à toute épreuve.
On peut modifier ce comportement en supprimant ou augmentant cette période pendant laquelle sudo (and friends) sont actifs. Pour cela, il faut éditer le fichier /etc/sudoers.

$ sudo visudo

Note: Vous pouvez utiliser gedit par exemple mais dans ce cas, cela se fera sans vérification de ce que vous tapez.
A la fin du document, ajoutez:

Defaults timestamp_timeout=0

La valeur par défaut est 5, c’est à dire 5 minutes avant que le timeout ne s’active. Ou donnez à la valeur que vous voulez sachant que c’est le nombre de minutes qui peuvent se passer avant que sudo ne redemande le mot de passe. Si vous mettez -1, le timeout sera infini, ce qui veut dire que plus jamais sudo ne demandera le mot de passe. Est-ce bien raisonable? La valeur 0 indique que le mot de passe sera demandé à chaque fois.

Initialement, l’intérêt du DivX, apparu en premier lieu était de pouvoir transcoder un DVD de façon à ce qu’il tienne sur un CD. La plupart des DVD sont des doubles couches permettant le stockage de +/- 9 GB maximum. Etant donné que sur un DVD, on a droit en général à des bonus, des bandes annonces, plusieurs langues, des sous-titres etc…, le film en lui même ne fait pas cette capacité maximum. A titre d’exemple, un DVD dont le film dure une heure et demi, codé en 8 Mbits/sec occupe une place de plus ou moins 5.5 GB. Pour arriver à réduire cette capacité à 700 MB maximum (taille d’un CD), il faut une compression sévère et des codecs de qualité. Ceci a été rendu possible par l’apparition du MPEG-4.

Note: Cet article est principalement basé sur la documentation de MPlayer/mencoder. Je suis conscient qu’il existe des frontend graphiques vous évitant de devoir utiliser la ligne de commande mais je reste persuadé que pour bien comprendre ce que l’on fait et comment faire pour avoir la qualité la meilleure, ceci reste très intéressant et riche d’enseignements.

Les Codecs

Le codec DivX utilise la compression MPEG-4. C’est une compression avec pertes. Ce codec tente d’allier qualité et taille de fichier.

Xvid est une version libre open source sous licence GNU qui utilise la compression MPEG-4 Part 2 – Advance Simple Profile (ASP). Les vidéos compressées en Xvid sont lisibles par un équipement DivX. Néanmoins, cela suppose que les caractéristiques avancées que permet le codage Xvid ne soient pas utilisées. Sous Linux, la plupart des programmes comme MPlayer ou VLC sont compatibles Xvid (grâce à la librairie libavcodec de FFmpeg par exemple).

H.264 Est un codec basé sur la compression MPEG-4 part 10 – Advance Video Coding (AVC).
x264 est la version libre sous licence GNU du codec H.264.

Quel codec choisir?

La question se pose bien évidemment mais la réponse est relativement simple.
Pour les utilisateurs de Linux, la version privilégiée sera bien sûr la version libre. On choisira donc plutôt Xvid d’autant plus qu’il est compatible avec DivX si on utilise pas de fonctions avancées.
Maintenant, si on tient compte de la qualité et qu’il n’y a pas de problèmes de compatibilité à respecter, on choisira x264. La qualité de la vidéo compressée est supérieure à celle du DivX et même du Xvid utilisé avec des fonctions avancées.

Simple passe ou passes multiples?

Lorsque l’on compresse la vidéo, on a le choix entre un encodage simple passe ou multiples passes. Cela revient à choisir entre un codage en CBR (Constant Bit Rate) pour le simple passe et le VBR (Variable Bit Rate) pour le codage en passes multiples.
Pour des raisons de qualité, on choisira systématiquement le codage VBR.

Et pour l’audio?

Le son étant très sensible aux encodages successifs, à moins qu’on ait une bonne raison de le faire, on choisira de ne pas y toucher.

Calcul du bitrate vidéo

Celui-ci dépend de la qualité envisagée. Plus le bitrate est élevé, plus la qualité vidéo résultante sera bonne mais ceci au détriment de la taille du fichier. On travaille donc souvent à l’envers. La taille maximum étant définie à 700 MB, on calcule le débit vidéo maximum possible:

bitrate vidéo = ((700 MB / taille du film)*8 - bitrate audio)

Ceci donne pour un film de deux heures avec un son encodé en 128kbits/sec:

bitrate vidéo = ((700 * 1024 * 1024 / (120 * 60))* 8 - (128 * 1024) = 684 kbits/sec

Les bandes noires

Souvent, la taille de l’image est réduite à des valeurs inférieures aux 720 pixels de résolution horizontale du DVD.
Il faut aussi toujours supprimer (cropping) les bandes noires en haut et en bas de l’image parce que les bandes noires ont un impact négatif sur l’encodage (transitions vives difficiles à encoder, elles utilisent de la bande passante,… ). Il faut aussi toujours tenir compte du fait que à cause des macroblocs du codage MPEG-4 qui ont une taille de 16×16, la taille de l’image doit toujours être un multiple de 16.

MPlayer a une fonction particulière qui aide à déterminer la taille des bandes noires. On utilise le filtre cropdetect dans une zone très claire du film:

$ mplayer dvd://1 -dvd-device /media/disk/DVD/ -vf cropdetect 
...
[CROP] Crop area: X: 2..717  Y: 57..518  (-vf crop=704:448:8:64).0 

Ensuite on rejoue le film avec le paramètre de cropping qu’on vient de déterminer au moyen du filtre crop. Ceci permet de se rendre compte d’une éventuelle erreur:

$ mplayer dvd://1 -vf crop=720:362:0:58

Si on tient compte du fait que la résolution horizontale et verticale doit être un multiple de 16, on prend la valeur juste inférieure et multiple de 16. On retire aussi une petite valeur en haut et en bas pour que le centre de l’image soit respecté. Cela donne:

$ mplayer dvd://1 -vf crop=720:352:0:62

Si malgré tout cela, la taille du fichier est encore trop grande ou que le bitrate calculé est trop faible pour avoir une qualité satisfaisante, on peut jouer sur la taille de l’image en utilsant le filtre scale de MPlayer/Mencoder. Attention: il faut toujours veiller à utiliser des multiples de 16:

$ mplayer dvd://1 -dvd-device /media/disk/DVD/ -vf scale=640:400

Ceci vous permet de voir la taille résultante en utilisant le filtre. Le même filtre peut être utilisé avec mencoder lors de l’encodage:

$ mencoder -ofps 25 -ovc xvid -xvidencopts bitrate=500 -aid 129 -oac copy -vf crop=704:448:8:64,scale=640:400 dvd://1 -dvd-device /media/disk/THE_BIBLE -o the_bible_xvid_1pass.avi

Caractéristiques du DVD

Il est souvent nécessaire de connaître les caractéristiques du DVD. Le nombre de titres, les langues existantes, les sous-titres éventuels… Qunad on lance MPlayer en ligne de commande, il affiche les caractéristiques du DVD:

$ mplayer dvd://1 -dvd-device /media/disk/DVD/
MPlayer 1.0rc2-4.3.2 (C) 2000-2007 MPlayer Team
CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (Family: 15, Model: 3, Stepping: 3)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled with runtime CPU detection.
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing dvd://1.
There are 3 titles on this DVD.
There are 15 chapters in this DVD title.
There are 1 angles in this DVD title.
audio stream: 0 format: ac3 (unknown) language: en aid: 128.
audio stream: 1 format: ac3 (stereo) language: fr aid: 129.
audio stream: 2 format: ac3 (stereo) language: it aid: 130.
number of audio channels on disk: 3.
subtitle ( sid ): 0 language: nl
subtitle ( sid ): 1 language: en
subtitle ( sid ): 2 language: fr
subtitle ( sid ): 3 language: el
subtitle ( sid ): 4 language: it
subtitle ( sid ): 5 language: fr
subtitle ( sid ): 6 language: it
number of subtitles on disk: 7
MPEG-PS file format detected.
VIDEO:  MPEG2  720x576  (aspect 3)  25.000 fps  7500.0 kbps (937.5 kbyte/s)
xscreensaver_disable: xscreensaver wid=31457384.
==========================================================================
Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough
VDec: vo config request - 720 x 576 (preferred colorspace: Mpeg PES)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
The selected video_out device is incompatible with this codec.
Try appending the scale filter to your filter list,
e.g. -vf spp,scale instead of -vf spp.
VDecoder init failed :(
Opening video decoder: [libmpeg2] MPEG 1/2 Video decoder libmpeg2-v0.4.0b
Selected video codec: [mpeg12] vfm: libmpeg2 (MPEG-1 or 2 (libmpeg2))
==========================================================================
==========================================================================
Forced audio codec: mad
Opening audio decoder: [liba52] AC3 decoding with liba52
Using SSE optimized IMDCT transform
Using MMX optimized resampler
AUDIO: 48000 Hz, 2 ch, s16le, 192.0 kbit/12.50% (ratio: 24000->192000)
Selected audio codec: [a52] afm: liba52 (AC3-liba52)
==========================================================================
AO: [pulse] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
VDec: vo config request - 720 x 576 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [xv] 720x576 => 1024x576 Planar YV12 

Cela permet de déterminer que l’audio ID (aid) est 129 pour le français, que le film a une résolution de 720 x 576 (ce qui est normal pour un DVD), que le son est codé en AAC à 192kb/s.
Tous ces renseignements seront utilisés dans la ligne de commande de transcodage.

Encodage

Ci-dessous, vous trouverez les lignes de commandes que j’ai utilisées pour faire mes essais. Vous devrez donc modifier certains des paramètres pour que cela corresponde à votre cas (device, aid,…)
Dans chaque cas, le son est copié tel quel sans transcodage.

encodage xvid en une passe:

$ mencoder -ofps 25 -ovc xvid -xvidencopts bitrate=800 -aid 129 -oac copy -vf scale=640:480 dvd://1 -dvd-device /media/disk/THE_BIBLE -o the_bible_xvid_1pass.avi

encodage deux passes en divx:

$ mencoder dvd://1 -dvd-device /media/disk/THE_BIBLE -ovc lavc -lavcopts vcodec=mpeg4:vpass=1:autoaspect -aid 129 -oac copy -o /dev/null
$ mencoder dvd://1 -dvd-device /media/disk/THE_BIBLE -ovc lavc -lavcopts vcodec=mpeg4:mbd=2:trell:vpass=2:autoaspect -aid 129 -oac copy -o the_bible_divx.avi

encodage en xvid en deux passes:

$ mencoder dvd://1 -dvd-device /media/disk/THE_BIBLE -mf fps=25 -ovc xvid -xvidencopts pass=1:bitrate=800 -alang fr -oac copy -o /dev/null
$ mencoder dvd://1 -dvd-device /media/disk/THE_BIBLE -mf fps=25 -ovc xvid -xvidencopts pass=2:bitrate=800 -alang fr -oac copy -o the_bible_xvid.avi

encodage deux passes en x264:

$ mencoder -aid 129 -oac copy -ovc x264 -x264encopts subq=5:8x8dct:me=umh:frameref=2:bframes=3:b_pyramid:weight_b:bitrate=800:pass=1 dvd://1 -dvd-device /media/disk/THE_BIBLE -o /dev/null
$ mencoder -aid 129 -oac copy -ovc x264 -x264encopts subq=5:8x8dct:me=umh:frameref=2:bframes=3:b_pyramid:weight_b:bitrate=800:pass=2 dvd://1 -dvd-device /media/disk/THE_BIBLE -o the_bible_x264.avi

Comparez les résultas obtenus. Pour cela, choisissez des scènes d’actions où l’ensemble de l’image est animée. Choisissez des images sombres et regardez le codage qui donne les images les moins bruitées. Observez s’il n’y a pas de pixelisation dans certaines scènes, signe d’un bitrate trop faible…

Lorsque l’on formate un disque en ext3, le système de fichiers réserve un certain nombre de blocs pour les process importants. Ceci assure que ces mêmes process importants continueront à fonctionner et à pouvoir écrire sur le disque même si le disque dur arrive à saturation. Ceci explique pourquoi, lorsque vous formatez un disque dur de grande capacité, la capacité réellement disponible est réduite de façon importante.
Par défaut, c’est 5% du disque qui est réservé. Sur un disque d’un Tera-octets, cela représente 50Gb! Ce n’est pas négligeable. Il est néanmoins possible de diminuer cette capacité réservée d’office:

$ sudo tune2fs -m 1 /dev/sda1

Le -m 1 indique le pourcentage de blocs réservés. Ici, on le fixe à 1%. N’oubliez pas de modifier le périphérique pour qu’il corresponde à votre disque.

D’ici quelques semaines, Ubuntu 9.04 sortira avec le support du tout nouveau système de fichier ext4. il ne sera pas utilisé par défaut mais vous pourrez le choisir lorsque vous formatterez vos partitions.
Ce nouveau file system a entre autres comme avantage de pouvoir travailler avec des volumes d’1 exaoctet c’est à dire 10¹⁸ octets et des fichiers juqu’à 16 teraoctets (10¹²), de minimiser la fragmentation et de permettre d’avoir plus de 32000 répertoires dans un répertoire. Il y a bien d’autres caractéristiques mais le but de cet article n’est pas de les énumérer. Celle qui justifie cet article et qui semble poser problème est que l’allocation est différée. On parle de allocate-on-flush. En bref, cela veut dire que l’allocation des blocs de données se fait au moment où on écrit sur le disque alors que les autres systèmes de fichiers le font bien plus tôt. Cette mesure permet de minimiser la fragmentation puisque la taille des blocs est déterminée en fonction de la taille réelle du fichier à écrire.

Le problème c’est que plusieurs utlisateurs, testant les versions alpha de Jaunty, ont rapporté des problèmes de perte de données, des fichiers de configuration dont la taille se retrouvait à zéro après un plantage de leur PC. Les programmes dont les fichiers de configuration on été tronqués étaient utilisés lors du plantage.

Avant d’écrire sur le disque, les données sont dans une cache en mémoire. Si vous ouvrez un fichier avec le mode truncate et si un plantage intervient entre le moment où le fichier est ouvert et le moment où les données sont réellement écrites sur le disque, vous perdez les données qui se trouvaient précédemment dans le fichier ainsi que les nouvelles données.

C’est un problème connu et expliqué comme en atteste le commentaire fait par Théodore Ts’o (développeur noyau) pour un rapport de bug.
La cause en est bien souvent des programmes pauvrement écrits. Il ne faut pas ouvrir un fichier en mode truncate puis écrire les données dedans mais créer un fichier temporaire, écrire les données dans ce fichier et finalement le renommer. Cette dernière opération est atomique c’est à dire qu’il ne peut rien arriver pendant l’opération, un lien vers le fichier pointe sur l’ancien ou le nouveau mais il n’y a pas d’état entre les deux. Donc si votre PC plante, sur le disque vous aurez soit l’ancien fichier, soit le nouveau mais en aucun cas un fichier vide.
Avec ext3, les données étaient écrites (flush) sur le disque dans un délai de 5 secondes. Avec ext4, ce délai est indéterminé. Si vous voulez être sûr que vos données sont bien écrites sur le disques il va falloir insérer un fsync() qui va forcer l’écriture sur le disque. La bonne façon de procéder devient donc:

open()    // ouvre un fichier temporaire
write()   // écriture dans le fichier temporaire
fsync()   // flush des données encore en attente
close()   // on ferme le fichier
rename()  // et on renomme le fichier

D’après Theodore Ts’o:

« Notez qu’un close() ne garantit pas que les données sont écrites sur le disque puisque le kernel diffère l’écriture sur le disque. Tous les systèmes de fichiers ne font pas un flush des buffers lorsque le stream est fermé (closed). Si vous devez être sûr que les données sont physiquement écrites sur le disque, utilisez fsync(). »

Si vous comprenez l’anglais, je vous suggère les liens suivant provenant du blog de Theodore Ts’o:

• http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero-length-file-problem/
• http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/

En conclusion, si vous voulez utiliser ext4, je vous conseille d’attendre un peu que les applications vraiment mal écrite aient été corrigées et puis, un patch est prévu pour le kernel 2.6.30 (ou déjà le 2.6.29 ?) qui devrait minimiser les risques de perte de données.