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