Visualisation scientifique collaborative avec VLC et

Transcription

Visualisation scientifique collaborative avec VLC et
Visualisation scientifique collaborative avec VLC
et rendu distribué OpenGL sous Linux
Adrien Maglo
1
Introduction
Ce document s’interresse aux travaux que j’ai pu réaliser durant un stage au
laboratoire MAS ( Mathématiques appliqués aux systèmes ) pendant l’été 2008
dans le cadre du projet Cariocas. Le projet Cariocas est un projet qui vise à
déployer un réseau optique expérimental à 40Gbs entre 4 sites d’Ile de France
pour interconnecter les centres de calcul du CEA (saclay et Bruyere le Chatel,
EDF Clamart et l’Université d’Orsay). Le but est donc de former un réseau
entre les différents équipements de calcul de ces sites et d’ainsi permettre aux
scientifiques de travailler ensemble avec plus de facilité.
J’ai dû plus particulièrement m’interresser à des problèmatiques de visualisation scientifique et de collaboration. Le but était de réflechir à un système offrant
la possibilité à des scientifiques basés physiquement devant un mur d’image et
d’autres scientifiques basés à distance devant leur ordinateur personnel de participer à une même session de visualisation.
Ainsi j’ai donc été amené à développer des prototypes d’outils basés sur
l’interception de tampon d’affichage OpenGL et de la diffusion grâce au lecteur
multimédia open source VLC Media Player. Ces prototypes ne fonctionnent
qu’avec Linux.
2
2.1
Mur d’image
Définition
Un mur d’image ou tiled display en anglais est un ensemble de plusieurs
périphériques d’affichage collés afin de former un écran d’une taille et d’une
résolution importante. Dans le cas du CEA par exemple, les périphériques d’affichage sont des vidéoprojecteurs.
2.2
Architecture
En visualisation scientifique, on est souvent amené à afficher des rendus 3D
d’une forte complexité. Ainsi, vu la taille et la résolution d’un mur d’image, il
est nécessaire d’avoir plusieurs machines qui génèrent le rendu 3D. Cet ensemble
de machines est appelé le cluster graphique. Chacun de ces serveurs possède une
carte graphique qui est relié à un périphérique d’affichage et gère donc l’affichage
pour ce périphérique.
1
Derrière l’architecture physique, il éxiste ensuite plusieurs méthodes de rendu
pour répartir le travail entre les serveurs. Ce sont les méthodes dı̂tes sort-first
et sort-last. Pour plus d’informations, je vous renvoie au rapport de stage de fin
d’étude de Clément Courbet.
Afin de commander l’affichage sur le mur d’image, une machine avec une
interface utilisateur est dédiée à la commande du mur d’image. C’est grâce à
cette machine que l’on va pouvoir agir sur le rendu.
3
3.1
Interception et diffusion du rendu du mur d’image
Interception des images du rendu
Comme expliqué dans la partie consacrée aux murs d’images, chaque serveur graphique s’occupe d’une partie du mur en générant un rendu OpenGL.
C’est ce rendu nous récupérons en remplaçant certaines fonctions de la bibliothèque OpenGL par les notres grâce à la variable d’envirionnement du chargeur
de bibliothèques dynamique de Linux LD PRELOAD et notre bibliothèque
libGLa3.so.
Ainsi, nous surchargons la fonction glxswapbuffer. Cette fonction a pour but
de normalement commuter le buffer de rendu et le buffer d’affichage lorsque
le rendu a fini d’être calculé. Donc lorsque glxswapbuffer est appelée, nous en
profitons donc pour envoyer à un module d’entrée d’un VLC nommé glapp3 1
sur x pixels via un socket préalablement connecté au moment du chargement
de la bibliothèque puis d’ensuite appeler la verritable fonction glxswapbuffer
d’OpenGL.
Il est possible de parramètrer la bibliothèque libGLa3.so grâce à des variables
d’environnement qui lui sont propres. Ainsi :
IP SERVER=X permet de lui spécifier l’adresse IP du serveur sur lequel
tourne le VLC avec le module d’entrée glapp3.
NB LINES TO SKIP et NB COLS TO SKIP permettent de lui spécifier
que une ligne sur NB LINES TO SKIP + 1 et une ligne sur NB COLS TO SKIP
+ 1 constituent l’image transmise au serveur.
Si l’on souhaite reconstituer l’image produite par un mur d’image géré par
le logiciel Paraview, on pourra par exemple définir les varriables d’environnement nécessaires au bon fonctionnement de la bibliothèque de récupération des
tampons OpenGL dans le fichier .bashrc de l’utilisateur qui lancera le serveur
paraview. On lancera ensuite sur le noeud 0 du cluster graphique ce programme
avec la commande mpirun.
Voici ce que devrait contenir le fichier .bashrc :
# Réglage des variables d’environnement concernant libGLa3
IP SERVER = 127.0.0.1
NB LINES TO SKIP = 1
NB COLS TO SKIP = 1
# Le LD PRELOAD pour surcharger les fonctions OpenGL
LD PRELOAD = /path/to/libGLa3.so
2
3.2
Regroupement des images
Le module d’entrée glapp3 récupère donc les tampons d’affichage de chaque
écran et les rassemble pour former une image. Lorsqu’une image complète est
prête, il envoit un signal à la bibliothèque de surcharge d’OpenGL sur les serveurs de rendu leur disant qu’ils peuvent envoyer une nouvelle image et il fait
passer à la chaı̂ne d’encodage et d’envoi de VLC cette nouvelle image.
glapp3 peut être parramètré grâce aux arguments suivants :
glapp3-nb-col règle le nombre de colones d’affichages différents du mur d’image.
glapp3-nb-row règle le nombre de lignes d’affichages différents.
glapp3-server-file spécifie le chemin vers le fichier qui liste les serveurs de
rendu. Ce fichier permet de préciser au module d’entrée glapp3 quelle est
la position de l’image générée par chaque serveur. Chaque ligne de ce fichier
est relative à un serveur. Les parramètres sont séparés par des tirets. On
précise d’abbord le numéro de la colonne de l’image puis le numéro de la
ligne puis l’adresse ip du serveur.
Voici un exemple de server file :
0-0-192.168.42.12
0-1-192.168.42.13
1-0-192.168.42.14
1-1-192.168.42.15
3.3
Encodage et diffusion
On laisse les modules déjà présents dans VLC totalement s’en occuper.
C’était ici que se situait le principal avantage à intégrer nos développements
à l’intérieur de VLC. En effet, VLC Media Player possède déjà de nombreuses
fonctionnalités d’encodage et de streaming suivant différents formats. Actuelement l’encodage vidéo est effectué en MPeg4 et le streaming en UDP sur
l’adresse multicast ”udp ://@224.220.220.220 :1234”. Ces deux paramètres, fixés
dans une ligne de commande VLC, peuvent être facilement changés dans le code
source du module cariocas-server.
4
Interception et diffusion du rendu d’un seul
serveur de rendu
Avec grosso modo le même principe que pour un mur d’image, il est possible de récupérer, d’encoder et de diffuser les images d’un tampon OpenGL
généré par un seul serveur. La bilibothèque de surchage à utiliser pour celà est
libGLa2.so. Elle devra aussi être chargée grâce au LD PRELOAD et communiquera ses données au module d’entrée glapp2 de VLC grâce à une zone de
mémoire partagée entre ces programmes.
Voici une ligne de commande qui permet d’acquérir un tampon OpenGL par
cette méthode et de le diffuser sur l’adresse multicast ”udp ://@224.220.220.220 :1234”
en utilisant cette méthode.
3
./vlc --ignore-config -vvv -I dummy glapp2 :// --auto-adjust-ptsdelay --sout=”#transcode{vcodec=mp2v,vb=800,scale=1} :duplicate{dst=std{access=udp,dst=224.220.220.220
:1234}}” --glapp2caching=0 --sout-udp-caching=0 --use-stream-immediate --sout-muxcaching=0 --auto-pts-min-buffer-size=10
Pour plus d’information sur comment diffuser un flux avec VLC, je vous
renvois à la documentation du site de videolan.org ou du wiki.
5
5.1
Collaboration
Cariocas server
Pour permettre utiliser de manière aisée le module d’entreé glapp3 sur le serveur et gérer les fonctionnalités de collaboration, un module d’interface nommé
cariocas-server a été développé. Ce module est chargé du lancement du module
d’entrée glapp3 et de la gestion de la collaboration entre les clients de la session
de visualisation. Ainsi, il envoie par exemple l’URL du flux vidéo aux clients
lorsque ces derniers viennent de se connecter.
Pour lancer un VLC cariocas-server, on pourra utiliser la ligne de commande
suivante :
./vlc -I cariocas-server -vvv --ignore-config --glapp3-nb-col=1 --glapp3nb-row=1 --glapp3-server-file=/path/to/server file.txt
Attention, le module cariocas-server ne fonctionne qu’avec le module d’entrée glapp3 (mode mur d’image).
5.2
Cariocas client
Un module d’interface nommé cariocas-client a aussi été développé. Cette
interface est destinée a être lancée par chaque client. Son principal rôle est de
lancer le flux vidéo provenant du serveur avec les bonnes options, d’afficher
l’interface distance du PC de commande et de renvoyer vers le serveur les évennements X11 à appliquer à l’interface de commande.
cariocas-server-ip permet de spécifier l’adresse ip du serveur Cariocas.
Pour lancer un VLC cariocas-client, on pourra utiliser la ligne de commande
suivante :
./vlc -I cariocas-client -vvv --ignore-config --cariocas-server-ip=127.0.0.1
5.3
Interface streamer
Ce logiciel est chargé de transmettre l’interface de commande du mur d’image
au VLC cariocas-server. Il est aussi chargé de répercuter sur l’application de
commande les évennements X11 provenant des clients. Il est par conséquent
lancé sur le PC de commande.
La ligne de commande pour lancer ce programme doit être de la forme :
./intfStreamer ip du serveur X1 Y1 X2 Y2
X1, Y1, X2 et Y2 correspondent aux coordonnées des deux points définissant
la zone rectangulaire de l’écran du PC de commande à transmettre aux clients.
Elles sont définies avec comme origine le coin supérieur gauche de l’écran.
4
Attention : actuellement du fait que l’interface streamer transmette des XImages, il faut obligatoirement que les clients et le PC de commande du mur
d’image aie la même profondeur de couleur.
6
6.1
Compilation
intfStreamer, libGLa3.so et libGLa2.so (glHacks)
La compilation du streamer d’interface et des bilbiothèques de récupération
de tampons OpenGL se fait grâce à un makefile. Il suffit donc juste de se rendre
dans les dossiers du code source de ces programmes et taper la commande :
make
Il faut noter qu’il est possible que la dépendance libxtst-dev ne soit pas
installée par défaut sur le système de compilation.
6.2
VLC cariocas
Pour compiler un VLC avec les modules précédemment décrits, il suffit de
suivre les instructions du wiki de VideoLAN :
http ://wiki.videolan.org/UnixCompile
Les modules cariocas seront automatiquement compilés ; il n’y a pas d’option
particulière à ajouter au script de configuration.
Voici la liste des fichiers sources modifiés ou ajoutés à la branche source de
VLC :
– tout les fichiers du dossier modules/misc/cariocas,
– le fichier modules/access/glapp3.c ,
– le fichier modules/access/glapp2.c ,
– le ficher configure.ac ,
– le ficher src/input/decoder.c ,
– le ficher src/input/var.c ,
– le ficher src/stream output/stream output.c ,
– le ficher src/libvlc-module.c ,
– et le ficher src/input/input internal.c .
7
7.1
Travail sur la latence
Présentation
Utiliser VLC Media Player pour de telles applications n’est pas forcement
une chose évidente. En effet, en prenant VLC de base sans lui regler ses niveaux
de caches, on peut constater des temps de latence de 1,5 seconde, même pour une
boucle locale. Un travail pour réduire ces temps de latence à l’intérieur de VLC
a donc été effectué par Pierre d’Herbemont. De ce travail il est principalement
ressorti qu’en utilisant des options adéquates et en adustant dynamiquement
le pts (Presentation Time Stamp) de chaque image en fonction de la taille du
tampon en mémoire, on pouvait réduire significativement ces temps de latence.
5
7.2
Options à utiliser
observés Les options suivantes de VLC sont interressantes à utiliser. Beaucoup d’entre elles sont automatiquement utilisées par les interfaces cariocasclient et cariocas-server lors du streaming et lancement d’un media.
use-stream-immediate permet de ne pas mettre en tampon plus de données
que necessaire entre le demuxer et l’access.
auto-adjust-pts-delay ajuste dynamiquement le pts des images en sortie du
décodeur afin que chaque image soit affichée ou encodée au plus vite.
auto-pts-min-buffer-size règle la taille en terme de temps du tampon en
sortie du décodeur.
no-drop-late-frames permet au VLC de ne pas supprimer des images qu’il
croı̂t ( selon ses critères ) en retard.
sout-udp-caching règle le cache du module de sortie, en loccurence udp.
sout-mux-caching règle le cache du muxer.
glapp3-caching règle le cache du module d’entrée, en loccurence glapp3.
udp-caching règler le cache du module d’entrée, en loccurence udp.
8
Avertissement
Attention, tout le code source qui a été développé dans le cadre de ce projet
est expérimental. Sa qualité n’est pas garantie : il se peut qu’il contienne des
erreurs, des fuites ou des corruptions de mémoire... De plus, aucun échange par
socket n’est sécurisé ; il n’y a pas de cryptage.
Pour toute question ou correction de d’erreurs, vous pouvez me contacter à
l’adresse [email protected] .
6
7