Autre article initialement écrit pour une mailing list...

Prérequis

Cet tutorial a été réalisé sur une machine FreeBSD et une machine OS X,
mais il devrait marcher sans grand soucis sur toute autre plateforme
Unix-Like récente.

Il est nécessaire d'avoir installé les utilitaires habituels :

• GCC + gmake
  
• automake + autoconf

Introduction

Le but de ce tutorial est réaliser un serveur de streaming vidéo optimisé
à base de VLC. Dans mon cas, le but était de pouvoir regarder certaines
chaînes du multiposte Free quand je n'étais pas chez moi (VH1 à tout
hasard ).

Il est possible d'utiliser la version pré-compilée mais cela induit deux
inconvénients :

• Il n'est pas forcément souhaitable d'installer X11, Gnome ou WXWindow
  sur un serveur
  
• La compression H264 est particulièrement lourde en temps CPU, tout gain
  de performance est la bienvenue (comprendre : avec la version
  pré-compilée, prévoyez du Core Duo 2GHz pour autre chose que 320x240)

Ce tutorial s'articule autour des points suivants :

• Compilation et installation de VLC
  
• Recompression d'un flux vidéo
  
• Intégration avec Apache et mod_proxy

Téléchargement

J'ai commencé par télécharger les fichiers suivants dans un dossier "src"
(qu'on appellera $SRC par la suite) :

• faac-1.26.tar.gz (pour la compression AAC)
  
• ffmpeg-export-snapshot.tar.bz2
  
• libdvbpsi5-0.1.6.tar.gz (gestion du conteneur TS)
  
• live555-latest.tar.gz (flux réseaux)
  
• mpeg2dec-0.4.1.tar.gz (décodage MPEG2)
  
• x264-snapshot-20080102-2245.tar.bz2
  
• vlc-0.8.6d.tar.gz

Compilation

Nous allons réaliser un binaire VLC statique, c'est-à-dire où tous les
codecs sont contenus directement dans le binaire (par contre, les libs
système seront linkées dynamiquement).

Environnement de compile :



FAAC :



(sur OS X, le make peut se terminer avec une erreur, mais ce n'est pas
gênant)

FFMpeg :



LibDVBPSI :



Live555 :



Mpeg2Dec :



X264 :



VLC :

C'est là où les choses peuvent se compliquer en fonction des besoins de
chacun.

Exemple de configuration très minimaliste :



Puis : make ou gmake

Ah mince, ça ne compile pas :



Corrigeons ce petit bug dans le code :


et on remplace p_sys->oc->pb = p_sys->io; par p_sys->oc->pb = &p_sys->io;

Et on relance le make. Cool ça passe cette fois.



Et pour finir : make install (après avoir fait un "su").


Utilisation

Maintenant que j'ai compilé et installé avec succès une version de VLC
adaptée à mes besoins, il est temps d'essayer une diffusion.

Le schéma suivant résume ce que je souhaite faire :

[ Free Multiposte ] -------> [ VLC ] --------> [ Diffusion ]
MPEG dans TS via RTSP Resize/Deinterlace H264/MP4a dans ASF via HTTP

Heureusement que VLC dispose d'un CLI puissant permettant de tout
paramétrer via un script.

Exemple d'utilisation :



Les paramètres sont relativement explicites, mais en gros il s'agit de
convertir du flux de la FreeBox vers un flux avec les caractéristiques
suivantes :

• Vidéo H264 en 128kbit (VBR) en 240x176 (attention ! en H264 les
  dimensions doivent être divisibles par 16)
  
• Son MP4A (AAC) en 32kbit, mono, 48000kHz
  
• Conteneur ASF (mais on pourrait aussi utiliser un conteneur TS par
  exemple*)
  
• Diffusion HTTP (unicast donc) sur port 8080

* Mais d'après mes expérimentations, le conteneur TS nécessitera qu'un
keyframe soit transmis au client avant l'apparition de l'image)


Intégration avec Apache

Un des avantages à utiliser une diffusion de type HTTP est qu'il est
possible d'héberger un ou plusieurs serveurs de diffusion derrière un
serveur Apache. En effet, en diffusion HTTP le client va faire banalement
une requête "GET" et va recevoir en réponse le flux ; il est donc possible
d'utiliser un proxy, comme mod_proxy.

Pour cela, il suffit d'activer et configurer mod_proxy dans sa
configuration Apache :




Conclusion

Grâce à des solutions logicielles flexibles comme VLC et des algos de
compression efficaces, il est possible aujourd'hui de diffuser du contenu
vidéo à relativement faible débit (200kbit/s), ouvrant ainsi les portes de
la diffusion personnelle.

J'espère que ce tuto vous a plu, et n'hésitez pas à faire part de vos
remarques !

Article que j'ai initialement écrit pour une mailing list, que je poste aussi, du coup...

A titre personnel, je gère quelques serveurs relativement modestes
hébergeant des sites Web à forte fréquentation. Je devais donc
concevoir une plate-forme à la fois performante, robuste et sécurisée
afin d'héberger des applicatifs PHP (mais on peut facilement
s'inspirer de cet article pour héberger d'autres langages).

La motivation de cet article vient de la constatation que la
configuration par défaut sur tous les systèmes Linux/BSD que j'ai pu
croiser était horriblement inadaptée à des besoins modernes
d'hébergement d'applications "web 2.0" à forte charge.


Choix d'un serveur Web

Un certain nombre d'administrateurs systèmes ont abandonné Apache au
profit Lighttpd pour des raisons de performances, mais la vérité est
que les deux peuvent convenir moyennant optimisation et configuration.
Pour ma part, je préfère utiliser Apache pour servir des pages Web, et
éventuellement ajouter un Lighttpd pour servir du contenu purement
statique (fichiers de style, JS, images...).

Quelques considérations quant à la configuration Apache :

• Mode prefork à éviter
  
• Enlever les modules inutilisés
  
• Ne plus configurer PHP en module

Depuis la version 2.0, Apache est multithreadé, ce qui veut dire qu'un
seul processus peut gérer plusieurs connexions, avec un gain de
mémoire impressionnant. Par ailleurs, il convient aussi de faire le
tri dans les modules Apache, ou mieux, compiler un Apache répondant au
mieux à ses besoins. Ca peut surprendre de vouloir encore compiler
alors qu'il existe des paquetages, mais un autre avantage c'est que
cela permet aussi de migrer de version avec zéro downtime : il suffit
de compiler la nouvelle version en modifiant le '--prefix', de copier
la config, de démarrer sur un autre port pour tester, et de modifier
un symlink quand c'est prêt.

Exemple de compilation Apache :



Pour en finir avec Apache, PHP n'est pas encore "thread safe" donc,
une utilisation en module est à éviter ; nous utiliserons alors le
mode CGI.


Choix d'un connecteur CGI

Bien qu'il soit tout à fait possible d'utiliser PHP comme CGI
directement, cette méthode présente l'inconvénient majeur de lancer le
binaire PHP à chaque accès à une page dynamique. Le coût CPU est donc
prohibitif sur un serveur à fréquentation importante.

Il convient alors d'utiliser un connecteur de type "FastCGI", et j'ai
une très nette préférence pour FCGID pour
plusieurs raisons :

• Efficacité : module maintenu et conçu pour Apache 2.x alors que
  FastCGI n'est plus maintenu
  
• Stabilité : FCGID dispose d'un watchdog pour surveiller l'état des
  workers
  
• Configuration : FCGID propose des options de configuration fines

Concrètement, le connecteur FastCGI maintient une pool de "workers"
PHP et transmet à un worker libre quand une requête arrive, tout en
recyclant les processus de manière à éviter qu'un processus reste trop
longtemps en service.


Optimisation PHP

Avant toute chose, il convient d'installer une version de PHP
compatible FastCGI, ou mieux : compiler sa propre version, ce qui
présente un avantage de taille, il est possible de mettre à jour PHP,
sans downtime, et sans même relancer Apache. En effet, FCGID va
recycler périodiquement les "workers" PHP, du coup, il suffit de faire
pointer le symlink vers la nouvelle version et au prochain recyclage,
la nouvelle version sera active.

Exemple de compilation PHP compatible FastCGI :



Pour ce qui est de l'optimisation PHP, outre la possibilité de
fouetter ses développeurs ( ), il convient d'installer un logiciel
de cache. Il en existe plusieurs (eAccelerator, Turck MMCache...), et
ils se présentent sous la forme d'une extension PHP.

Mon préféré à ce jour est Xcache parce
qu'il supporte parfaitement les environnements Linux/BSD que
j'utilise, est assez facile à configurer (quelques lignes dans
php.ini) et offre un excellent niveau de stabilité.


Gestion d'utilisateurs avec Suexec

Suexec est un peu le "sudo" du serveur Web : il permet d'exécuter des
applications CGI sous un autre utilisateur que l'utilisateur du
serveur Web (qui est souvent "www", "www-data" ou "apache").

Cela est surtout intéressant en hébergement mutualisé où il permet
d'isoler les utilisateurs (droits sur le disque, invisibilité de
processus, ainsi de suite), d'identifier rapidement un utilisateur qui
pose problème et d'éviter les casse-tête au niveau des droits.

Pour supporter cette fonctionnalité, Apache doit être compilé en
conséquence :



Ensuite, chaque utilisateur doit avoir son CGI dédié (ici le binaire
"php-cgi" compilé avec support FastCGI), dont il est propriétaire.
Attention : il faut réellement un binaire dédié, pas un symlink.

Par exemple :



Et pour finir, il suffit dans chaque virtual host de déclarer quel
binaire doit être chargé :




Exemple de configuration

Voici un exemple de configuration Apache sans Suexec. Pour la
configuration avec, il suffit de prendre les indications du paragraphe
précédent !




Conclusion

Ce petit article/howto avait comme objectif d'explorer les
améliorations suivantes en hébergement Web :

• Performances (processus légers, caches)
  
• Sécurité (Suexec)
  
• Stabilité (workers séparés avec surveillance)

J'espère qu'il vous a plu !