Étude et mise en œuvre d'un serveur de streaming sur ARM et DSP

Transcription

1 Projet Avancé SE Étude et mise en œuvre d'un serveur de streaming sur ARM et DSP SALAH Mohamed Aziz GUIRAUD Mathieu PELAGE Arnaud ROVIS Michaël Intervenant : AUBRY Willy

2 Table des matières Introduction Spécifications du projet Cahier des charges et spécifications : Stratégies choisies Mise en œuvre Utilisation des scripts VideoLAN Programmation du démon Compilation croisée sur ARM AT Objectif de la compilation croisée Configuration et compilation de VLC pour la carte pour le processeur ARM AT Implémentation du circuit sur la carte pour le processeur ARM AT Problèmes survenus lors de la compilation croisée sur ARM AT Installation de µclinux sur DSP BF Présentation du DSP BF Présentation de µclinux uclibc Toolchain pour compiler Linux sur la Blackfin Installation de la toolchain Compilation de µclinux Problèmes rencontrés pour la compilation : Compilation du VLC sur la carte Blackfin Méthode 1 : Cross-compilation de VLC en même temps que celle de µclinux Méthode 2 : Cross-compilation de VLC tout seul Travail effectué Conclusion Bibliographie Rapport Projet Avancé SE 2009/2010 Page 2 sur 26

3 Introduction Le streaming se développe de plus en plus, d'abord sur les ordinateurs personnels mais aussi sur les systèmes embarqués comme les téléphones mobiles. En effet, l'avantage du streaming est la possibilité de lire le média en direct sans besoin de stockage du fichier entier. Il convient d'étudier la mise en œuvre d'un serveur de flux vidéo par streaming. L'idée est de mettre en place sur des plateformes ARM et DSP un serveur d'adaptation à la volée de flux multimédia. Pour cela, nous travaillerons sur des processeurs pour l'embarqué, les cartes ARM AT91 et DSP Blackfin BF537. La distribution utilisée dans ce projet est µclinux. Ici, nous pouvons voir un schéma représentant le projet d'un point du vue global. Fig 1 Architecture générale du projet Le serveur vidéo sera un ordinateur qui diffusera un flux vidéo en allant chercher soit : - Un flux sur internet, par exemple sur le site Dailymotion - Un fichier vidéo sur son disque dur Comme le montre le schéma, dans sa finalité, le client sera multiple puisqu'il pourra être aussi bien un PC qu'un téléphone mobile. En fait, le client pourra être n'importe quel appareil ayant la possibilité d'afficher de la vidéo et la capacité de se connecter sur un réseau. Mais le point sur lequel nous allons concentrer notre travail durant ce projet est le système permettant de réaliser l'adaptation du flux vidéo en provenance du serveur pour le transmettre au client en fonction de sa demande. L'idée est d'éviter que l'appareil client est à faire l'adaptation, de la vidéo, ce qui peut demander des ressources importantes (tant en mémoire qu'en consommation) et aussi de fournir une vidéo avec un format qui sied au système client. Rapport Projet Avancé SE 2009/2010 Page 3 sur 26

4 1. Spécifications du projet 1.1. Cahier des charges et spécifications : Pour comprendre comment fonctionne le projet, nous allons d'abord nous intéresser au cahier des charges de ce dernier. Le cahier des charges se présente sous la forme de spécifications pour chacune des trois parties du projet - Le client, - La boîte adaptatrice de flux vidéo, que nous appellerons Set-top box, - La partie serveur vidéo. Client : - Ne pas réaliser de logiciel client - Demande de vidéo - Paramètres du système client Set-top box : - Processeur ARM ou DSP, en fonction des performances - Traitement des informations client - Choisir un logiciel de traitement vidéo, ou programmer le traitement - Réaliser le traitement du flux vidéo (transcodage) en fonction des paramètres client - Diffuser le flux vidéo par le réseau Serveur de vidéo : - Diffuse la vidéo provenant réseau serveur 1.2. Stratégies choisies Dans notre projet, nous ne nous intéressons pas au côté client, c'est-à-dire que nous n'avons pas à réaliser le logiciel client qui gère les demandes et la réception du flux. Cependant pour simuler ce logiciel, nous utilisons un PC dit client qui effectue la demande de vidéo. Cette requête sera entrée manuellement au moyen d'un script. Pour nous aider dans notre projet, nous avions la possibilité d'utiliser FFmpeg ou VLC. FFmpeg est une collection de logiciels libres dédiés au traitement de flux audio ou vidéo (enregistrement, lecture ou conversion d'un format à un autre). VLC est un lecteur multimédia libre issu du projet VideoLAN. Ce logiciel est multiplateformes (Windows, GNU/Linux, BSD, Mac OS X, Pocket PC). Il est distribué sous licence GNU/GPL. Un des grands atouts de VLC est qu'il intègre les codecs nécessaires à la lecture de la plupart des formats audio et vidéo. De plus, le lecteur est capable de lire un grand nombre de flux réseaux. Nous avons choisi d'utiliser VLC pour quatre raisons : - Il est multiplateformes (nous pouvons l'utiliser pour la partie client) - Il supporte tous les codecs et tous les formats de fichier supportés par FFmpeg Rapport Projet Avancé SE 2009/2010 Page 4 sur 26

5 - C'est un logiciel qui permet de lire et de diffuser des flux réseaux (logiciel Client/Serveur) - Il fonctionne aussi avec un langage de script. À l'aide d'un script VLC nous effectuons manuellement la demande client en choisissant divers paramètres, tels que la taille de la vidéo, le transcodage à appliquer, ou encore l'adresse IP du client. Le serveur de vidéo est un PC qui diffusera un flux vidéo provenant : - D'une vidéo de test de son disque dur : video_test.mpg - D'internet à l'adresse ci-dessous : Pour la Set-top box, nous devons choisir entre deux processeurs ARM ou DSP, ce choix se fera en fonction des performances obtenues lors de l'adaptation du flux vidéo. Cependant nous verrons par la suite que tout ne s'est pas déroulé comme prévu. La Set-top box Bloc est constituée de 2 blocs, un démon et un logiciel VLC. La carte communiquera par le réseau ethernet avec le client et avec le serveur de vidéo. VLC comporte beaucoup de modules, notamment un GUI qui nous sera d'aucune utilité, ainsi, une amélioration possible serait d'alléger VLC de ses éléments non nécessaires et non utilisés. Avant d'expliquer le fonctionnement de la Set-top box voyons d'abord le schéma de l'architecture choisie pour la réalisation du projet Fig 2 Architecture détaillée du projet Rapport Projet Avancé SE 2009/2010 Page 5 sur 26

6 Il faut considérer que le client, possède un VLC client et que la Set-top box possède un VLC serveur. Explication du fonctionnement de l'architecture : 1/ Le client envoie à la Set-top box par réseau ethernet les paramètres de sa requête : - Adresse IP client - Port à utiliser - Identifiant de la vidéo (nom) - Dimensions souhaitée de la vidéo (largeur, hauteur, échelle) - Protocole réseau à utiliser (rtp, rtsp, http) 2/ La Set-top box est constituée de 2 entités, un démon et le logiciel VLC (qui dans le cas idéal sera allégé de son interface graphique). Le démon récupère les informations clients et contrôle VLC grâce un script permettant de chercher le flux vidéo demandé. 3/ Le serveur vidéo envoie le flux demandé. 4/ Lorsque VLC serveur reçoit le flux vidéo, le démon envoie un message au PC client. Dans ce message sont contenus l'adresse du serveur, son port et un signal signifiant que le VLC serveur a commencé la diffusion. Le codec à utiliser est choisie par le démon dans la Set-top box en fonction du flux à adapter. 5/ Le VLC client sur le PC client est exécuté par un script client qui contient l'adresse du serveur et son port ainsi que le protocole utilisé. Rapport Projet Avancé SE 2009/2010 Page 6 sur 26

7 2. Mise en œuvre 2.1. Utilisation des scripts VideoLAN Nous avons choisi le logiciel Client/Serveur VideoLAN pour les raisons évoquées précédemment. VLC est utilisable en mode graphique mais aussi à l'aide de script et nous allons voir plus en détail comme fonctionnent ces scripts. Nous avons réussi à utiliser VLC en tant que client et serveur (en ouvrant 2 sessions de VLC) des façons suivantes : - En local, sur un même PC on ouvre un VLC client et un VLC serveur o Flux http o Video_test.mpeg - Sur 2 PC distants o Flux http o Video_test.mpeg Nous avons utilisé les protocoles suivant : http, rtp et rtsp. La diffusion par RTSP est possible, attention à ne pas confondre avec le protocole Secure Real-time Transport Protocol (ou SRTP) qui définit un profil de RTP (Real-time Transport Protocol), qui a pour but d'apporter le chiffrement, l'authentification et l'intégrité des messages, et la protection contre le replay de données RTP en unicast et multicast. On rappelle ce qu'est le protocole RTSP. RTSP ou Real Time Streaming Protocol (protocole de streaming temps-réel) est un protocole de communication destiné aux systèmes de streaming média. Il permet de contrôler un serveur de média à distance, offrant des fonctionnalités typiques d'un lecteur vidéo telles que "lecture" et "pause", et permettant un accès en fonction de la position temporelle. Nous allons détailler les scripts utilisés. Il y a 2 types de scripts différents : les scripts clients et les scripts serveurs. Chaque fois, nous donnerons les scripts qui fonctionnent ensemble. En local : Client : VLCportable rtsp://localhost/channel1 VLCportable rtsp://localhost/ test.sdp Serveur: VLCportable -vvv video_test.mpg --repeat --sout "#transcode{vcodec=h264,vb=400,scale=1}:duplicate{dst=display,dst=rtp{dst= ,port=1200,sdp= rtsp://localhost/channel1}} VLCportable -vvv video_test.mpg --repeat --sout #transcode{vcodec=h264,width=100}:rtp{dst= ,port=1200,sdp=rtsp://localhost/channel1}} VLCportable -vvv -- repeat --sout "#transcode{vcodec=mp4v,vb=400,scale=0.5}:rtp{dst= ,port=1200,sdp=rtsp://localhost/test.sdp} Commentaires : Rapport Projet Avancé SE 2009/2010 Page 7 sur 26

8 Dans notre exemple, VLCportable est le nom donné au logiciel utilisé, d'ailleurs nous remarquons qu'il n'y a pas de chemin d'accès, ceci vient du fait que scripts et exécutables étaient dans le même dossier. L'option vvv permet d'obtenir des messages d'erreurs de façon très verbeuse. video_test.mpg et le nom du fichier vidéo que nous diffusons. L'option --repeat permet de diffuser le flux en boucle. L'option --sout permet de diffuser le flux en boucle. Dans cet exemple, nous avons choisi de réaliser l'adaptation du flux vidéo en utilisant le module transcode{ }. Nous remarquons que c'est dans ce module, que nus avons la possibilité d'ajouter les options d'adaptation du flux, telles que le codec utilisé, l'échelle de la vidéo, etc vb= Cette option permet de régler le débit flux video transcodé en kbit/s scale= Cette option permet de donner le ratio dans lequel doit être redimensionnée la vidéo pendant le transcodage. Cette option peut être particulièrement utile pour aider à réduire le débit d un flux. width= Cette option permet de donner la largeur de la vidéo transcodée en pixels. Height= Cette option permet de donner la hauteur de la vidéo transcodée en pixels. Attention, ces options sont valables dans le module transcode. rtp Ce module peut être utilisé pour envoyer un flux en utilisant le protocole RTP (Real Time Protocol). dst= Cette option vous permet de donner l adresse UDP de destination. Cela peut être l adresse d un hôte ou d un groupe multicast. Cette option doit être renseignée, à moins que l option sdp=rtsp:// le soit (voir plus bas). Dans le dernier cas, le flux sera envoyé à l hôte faisant la requête RTSP. port= Cette option permet de régler le port UDP utilisé pour envoyer le premier flux élémentaire. Ce port doit être fourni. Les autres flux seront en utilisant les ports impairs juste au dessus. sdp= Cette option vous permet de choisir la manière dont le fichier SDP (Session Description Protocol) correspondant au flux doit être disponible. Les options sont : file://<chemin vers le fichier>, pour exporter le contenu SDP en tant que fichier local. locale IP:port/chemin>, pour rendre le fichier disponible en utilisant le serveur HTTP intégré au VLC. rtsp://<interface locale IP:port/chemin>, pour rendre le fichier SDP disponible en utilisant le protocole RTSP Attention, ces options sont valables dans le module rtp. duplicate Ce module peut être utilisé pour dupliquer le flux, et ainsi procéder à travers différentes chaines. Rapport Projet Avancé SE 2009/2010 Page 8 sur 26

9 dst= Cette option permet de fixer la chaine à travers laquelle le flux dupliqué doit être traité. Pour plus d'information sur les modules et options utilisées, nous vous invitons à consulter la documentation fournie sur le site de VLC : En réseau : Client : VLC rtsp://[serverip]:[serverport]/test.sdp Serveur : VLC -vvv --repeat -- sout "#transcode{vcodec=h264,vb=400,scale=0.5}:duplicate{dst=display,dst=rtp{dst=[clientip], port=[clientport], sdp=rtsp://[serverip]:[serverport]/test.sdp}} VLC -vvv video.mpeg --repeat --sout #transcode{vcodec=h264, scale=0.5}:rtp{dst=[clientip], port=[clientport], sdp=rtsp://[serverip]:[serverport]/test.sdp} 2.2. Programmation du démon La programmation du démon reste encore abstraite, cependant nous avons effectué de nombreuses recherches en vue d'écrire notre propre démon. Nous allons voir dans cette partie le résultat de ces recherches. Ce programme a été trouvé sur le Site du Zéro et constitue une base intéressante. void daemonize( void ) { pid_t pid, sid; /* données qui peut recevoir l'identifiant d'un processus (ce que l'on appelle le pid: process identifier) et qui sont par définition des entiers */ pid = fork(); /* création d'un processus appelé processus fils qui fonctionne en parallèle du premier processus appelé processus père */ if( pid < 0) exit( EXIT_FAILURE ); else if( pid > 0) exit( EXIT_SUCCESS ); /* fork ne renvoit pas la même chose au deux processus. > pour le fils il renvois 0 > pour le père il renvois le pid du fils dans mon cas on arrête le programme pour le père */ umask(0); /* donne les droit par défaut 0777 */ Rapport Projet Avancé SE 2009/2010 Page 9 sur 26

10 sid = setsid(); /* setsid obtient pour valeur le pid du processus fils mais échoue dans certains cas comme par exemple celui ou le processus fils à le même pid qu'un processus déjà existant */ if( sid < 0 ) { perror( "daemonize::sid" ); exit( EXIT_FAILURE ); } /* en cas d'échec de setsid on a sid < 0 et alors on interrompt la procedure */ if( chdir("/") < 0 ) { perror( "daemonize::chdir" ); exit( EXIT_FAILURE ); } fils) } chdir( "/home/serge/osiris/source" ); /* changement du dossier ou s'execute le processus courant (ici le je le met dans le même dossier que mon code source */ close( STDIN_FILENO ); close( STDOUT_FILENO ); close( STDERR_FILENO ); /* le fils partage les descripteurs de fichier du père sauf si on les ferme et dans ce cas ceux du père ne seront pas fermés */ int main( void ) { daemonize(); while( 1 ) { /* debut programme */ /* fin programme */ } return( EXIT_SUCCESS ); } Attention, ce programme n'a pas été testé, et il est fort probable qu'il ne fonctionne pas sur la distribution µclinux. En effet, le programme présenté ci-dessus est écrit pour une distribution courante de Linux, or d'après des informations trouvées sur la page de M. Kadionik concernant la distribution µclinux, il y a des limitations d'usage à respecter. L absence de MMU impose quelques limitations d usage par rapport à l environnement Linux : - La mémoire virtuelle n existe pas. - L appel système fork() n'est pas supporté. Il faudra utiliser alors une implémentation de l appel système vfork() d UNIX BSD (le processus parent est suspendu jusqu à ce que le processus fils appelle exec() ou exit() ). - L appel système exec() ne peut pas charger actuellement une image binaire supérieure à 256 Ko. - La taille de la pile est fixe pour chaque processus Rapport Projet Avancé SE 2009/2010 Page 10 sur 26

11 Rapport Projet Avancé SE 2009/2010 Page 11 sur 26

12 3. Compilation croisée sur ARM AT Objectif de la compilation croisée Un de nos objectifs dans ce projet est de lancer VLC depuis une de nos deux cartes. Nous avons décidé d utiliser un programme déjà existant, VLC mais il faut pour l utiliser le compiler pour nos circuits. Seulement, on ne peut compiler directement sur la carte puisque comme tout système embarquées les cartes on peu de ressources. On ne peut donc pas charger toutes les sources de VLC sur la carte et compiler sur le système. Il ne nous reste plus qu une seule alternative, compiler pour le microprocesseur du circuit ARM ou DSP, sur un ordinateur extérieur : la Forge. C est la compilation croisée. Cette étape doit être réalisée avec soin pour que le code compilé puisse être utilisé de manière optimale par la machine. Il faut donc le compilateur adapté au CPU cible Configuration et compilation de VLC pour la carte pour le processeur ARM AT91 On va profiter de l étape de configuration pour préciser certaines choses pour préparer la compilation. Mais tout d abord on va préparer l environnement pour que le compilateur puisse-t-être reconnu et trouvé. On se place donc dans le répertoire CPUAT91 qui contient toutes les informations sur l ARM. On lance alors la commande :./setup_env.sh On se place maintenant dans le répertoire de travail : /home/forge/vlc On définit ensuite des variables pour faire des distinctions sur les compilateurs : export CC=arm-linux-gcc export CXX=arm-linux-g++ export AR=arm-linux-ar export RANLIB=arm-linux-ranlib export LD=arm-linux-ld export STRIP=arm-linux-strip export NM=arm-linux-nm Avant de lancer la configuration, on peut lire sur le site de VideoLan qu il faut exécuter un bootstrap :./bootstrap Depuis la forge, on exécute le configure avec les bonnes options :./configure --target=arm-linux --prefix=/home/forge/cpuapt91/arm-linux --disable-mad -- disable-avcodec --disable-avformat --disable-swscale --disable-postproc --disable-a52 --disableqt4 --disable-skins2 Rapport Projet Avancé SE 2009/2010 Page 12 sur 26

13 Premièrement on précise le circuit cible, --target=arm-linux, puis le préfixe, -- prefix=/home/forge/cpuapt91/arm-linux, afin que le bon compilateur soit choisit. Enfin on enlève les bibliothèques superflues. Maintenant on peut lancer la compilation en elle-même avec la commande make Implémentation du circuit sur la carte pour le processeur ARM AT91 Ensuite, on récupère l exécutable cross-compilé afin de l implanter sur la carte. Il pourra lancer VLC qui se trouvera sur un poste serveur grâce au réseau. Pour cette étape, on a relié le circuit à la Forge avec un câble Ethernet pour être raccordé au réseau mais aussi avec la liaison série RS 232 pour tout ce qui est configuration de la carte pour la communication. Ces branchements sont décrits dans le schéma suivant : On peut voir 5 ports séries pour RS 232 mais celui sélectionné est l entrée Debug. Une fois le circuit branché à la Forge, il est tant d établir une communication avec le circuit. Le schéma suivant illustre le protocole utilisé : Rapport Projet Avancé SE 2009/2010 Page 13 sur 26

14 On peut voir sur ce schéma que grâce à la liaison série, on communique tout d abord avec la carte avec Minicom. En effet, au départ, le circuit n est pas relié de manière logicielle à la Forge. On configure tty0 pour que Minicom puisse se lancer. Ensuite, on règle le baud rate pour avoir la main. On peut à ce stade atteindre la carte et lancer des commandes depuis la carte. On peut alors réaliser notre objectif qui est de copier l exécutable de VLC sur la carte. On peut maintenant utiliser le réseau pour faire le transfert. On a placé au préalable vlc.exe dans tftpboot. Avec Minicom, on se place dans /tmp de la carte par exemple et on lance la commande tftp suivante : tftp -g -r vlc On demande d aller chercher le fichier vlc dans le tftpboot du poste dont l adresse IP est : et de le copier par le réseau c est-à-dire le câble Ethernet Problèmes survenus lors de la compilation croisée sur ARM AT91 Lors des premières tentatives, nous avons rencontré des désagréments car jamais nous ne désélectionnant pas assez de librairies. Une fois cet écueil passé, nous pensions avoir réussi mais malheureusement le fichier exécutable l était toujours pour X86. En fait, c est l instant où nous nous sommes rendu compte qu il fallait définir l environnement pour le compilateur avec un./setup_env.sh. Mais là en fait, après avoir recommencé le processus de nouvelles erreurs se sont révélées. Elles étaient liées à la librairie HAL. Bien que celle-ci soit installée sur la forge, lors de l exécution de la commande make, le processus n arrive pas à faire le lien. En fait, la première solution pourrait être de recompiler toutes les bibliothèques pour l ARM. Le compilateur pourrait faire le lien. Mais les différentes recherches sur les forums sur les questions de crosscompilation montrent que de nombreux problèmes se posent quand on décide de cross-compiler VLC pour ARM. Sans doutes que le code de VLC se prête difficilement à la cross-compilation pour ARM. En tout cas, nous n avons pas pu clôturer le projet en ayant réussi cette étape. Rapport Projet Avancé SE 2009/2010 Page 14 sur 26

15 4. Installation de µclinux sur DSP BF Présentation du DSP BF537 Le Blackfin 537 est un DSP (Digital Signal Processor) 32 bits utilisé pour les applications embarquées audio, vidéo ou de communication. Le BF537 est le plus performant de la série Blackfin avec notamment plus de mémoire embarquée. Le BF537 possède les caractéristiques suivantes: - mono-processeur - peut travailler jusqu à une fréquence de 600 MHz. - possède un jeu d instructions 32 bits basé sur le RISC. - a une architecture SIMD (Simple Instruction Multiple Datas). - possède 132 Ko de RAM on-chip. - a une connectivité Ethernet intégrée. - possède une MPU (Memory Protection Unit). Sur la figure ci-contre, on voit l architecture de la carte : Le prix du BF537 est de 350$ US (~247 ). Rapport Projet Avancé SE 2009/2010 Page 15 sur 26

16 4.2. Présentation de µclinux µclinux est le versant embarqué du système d exploitation libre Linux. Cet OS (Operating System) est basé sur les noyaux 2.0.x, 2.4.x et 2.6.x. Cet OS n inclut pas de management de la MMU (Memory Management Unit). Ainsi, il peut tourner sur les processeurs qui n en ont pas, ce qui est un avantage vu que ces processeurs sont moins chers que ceux utilisant une MMU (plus gros). La MMU est le composant matériel qui gère la mémoire virtuelle d un système. Il a pour fonctions la conversion des adresses virtuelles en adresses physiques, la protection des adresses, le contrôle de cache et l arbitrage du bus. La MMU n est pas nécessaire dans de nombreuses applications embarquées. µclinux est supporté par une large gamme d architectures telles que H8, SH, MIPS, x86, i960, ARM ou m68k. µclinux a une faible empreinte mémoire. En effet, il peut peser jusqu à moins de 300 Ko dans le cas où il est basé sur le noyau 2.6.x. Ce qui est un avantage considérable en milieu embarqué où les ressources matérielles sont limitées. µclinux peut utiliser XIP (Execute In Place). Le principe de XIP est que le noyau stocké dans la Flash n a besoin d être ni chargé, ni décompressé en RAM pour être exécuté. Ceci a 2 avantages : Le premier est que le temps de boot de µclinux en est réduit puisqu il n y a plus d opérations de chargement à mener, le deuxième est qu on a donc besoin de moins de RAM puisque seules les données dynamiques du noyau seront chargées dans celle-ci. Mais on a quand même 2 inconvénients : Le premier est qu on a besoin de plus de Flash car le noyau doit être stocké dans celle-ci à l état décompressé, le deuxième est que le temps d accès de la Flash est plus grand que celui de la RAM donc µclinux tournerait moins vite avec XIP que sans. XIP est à utiliser avec le système de fichiers romfs qui stocke les données de façon continue. Avec µclinux, l utilisateur a un accès complet au matériel, y compris les registres de périphériques. µclinux utilise l API Linux complète ce qui veut dire que l on peut utiliser les appels système de Linux à quelques exceptions près. µclinux offre une connectivité Internet complète. Rapport Projet Avancé SE 2009/2010 Page 16 sur 26

17 4.3. uclibc uclibc est la bibliothèque C légère pour les petits systèmes embarqués. Elle est plus petite que Glibc mais intègre la plupart des fonctionnalités de celle-ci. Elle a été développée au départ exclusivement pour µclinux, mais maintenant est un projet indépendant Toolchain pour compiler Linux sur la Blackfin Cette toolchain est utilisée pour compiler un code source et produire ainsi un fichier binaire qui doit être exécuté sur la Blackfin. Elle est composée de tous les utilitaires standards de compilation (gcc, ld ) et de la bibliothèque uclibc. Il existe 2 types de format pour les exécutables produits : le format plat ou BFLT (Binary FLat Format) et le format FDPIC ELF. Le BFLT est un format simple et léger basé sur le format a.out. Il est condensé, ne stockant que le code exécutable et les données, plus les replacements nécessaires pour charger l'exécutable à n'importe quel emplacement en mémoire. C est le format par défaut pour Linux embarqué. Le format ELF (Executable and Linking Format) est un format plus puissant et plus flexible que le BFLT. Cependant, il consomme plus de mémoire et est plus lent. Le format FDPIC ELF est pareil au format ELF sauf qu il a été modifié pour s exécuter sans MMU. On a donc les utilitaires suivants qui doivent être utilisés pour des tâches bien précises : bfin-uclinux : -Utilisé par défaut par µclinux. Rapport Projet Avancé SE 2009/2010 Page 17 sur 26

18 -Produit des fichiers exécutables au format Flat avec l option elf2flt. -Utilisé surtout pour compiler les bootloaders et les noyaux Linux. bfin-linux-uclibc : -Produit des exécutables au format FDPIC ELF. -Utilisé lorsqu on a besoin de bibliothèques partagées sous µclinux. -Utilisé plutôt pour les applications qui tourneront sous µclinux Installation de la toolchain Dans le cas où on utilise Ubuntu sur la machine hôte, on procède comme suit : Après cela, les utilitaires sont disponibles dans le répertoire /opt/uclinux/bfin-uclinux/bin et /opt/uclinux/bfin-linux-uclibc/bin. Rapport Projet Avancé SE 2009/2010 Page 18 sur 26

19 Il faut maintenant mettre à jour la variable d environnement PATH afin d inclure les répertoires précédents : Bien sûr, pour que la variable PATH soit mise à jour automatiquement au démarrage d une session, on peut ajouter la ligne ci-dessus dans le fichier ~/.profile ou ~/.bashrc Compilation de µclinux Il faut télécharger les sources de µclinux. Ici, nous avons choisi la version suivante : uclinuxdist.r tar.gz On décompresse le fichier.tar.gz en tapant la commande: tar xvjf uclinux-dist.r tar.gz Ensuite, on va dans le répertoire uclinux-dist.r et on tape make menuconfig. Une console graphique devrait apparaître comme ci-dessous : Rapport Projet Avancé SE 2009/2010 Page 19 sur 26

20 On choisit le constructeur et le processeur sur lequel va tourner µclinux : On choisit de configurer les paramètres de compilation : Affichage du menu Vendor/User Settings : Rapport Projet Avancé SE 2009/2010 Page 20 sur 26

21 On choisit le format FDPIC : Enfin, on quitte le menu de configuration en sauvegardant bien sûr les modifications apportées et on tape la commande make pour lancer la compilation de µclinux. Il est bon de noter que l installation d un bootloader sur la carte BF537 doit précéder celle de µclinux. Nous n avons pas développé cette étape car nous n y avons pas travaillé durant le projet. Toutefois, on pourra retrouver, dans les sources bibliographiques, l ensemble des liens qui expliquent les différentes étapes de l installation de U-Boot (bootloader Open Source). Une fois que µclinux a été compilé, on récupère l image binaire linux dans le répertoire images/ et on le copie dans le répertoire /tftpboot/ : Maintenant, on travaille sur la carte (au travers de Minicom). On configure l interface réseau de la carte en entrant l adresse du serveur (la machine hôte) et l adresse de la carte : On peut entrer la commande saveenv pour garder ces valeurs même après un reset. On télécharge le noyau sur la carte et on l exécute : On obtient sur Minicom une console qui devrait ressembler à ça : Rapport Projet Avancé SE 2009/2010 Page 21 sur 26

22 4.7. Problèmes rencontrés pour la compilation : Jusqu à présent nous n avons réussi à compiler µclinux qu avec les paramètres de compilation par défaut. A savoir, le format du binaire est le format ELF. Cela peut poser des problèmes quant à la capacité de µclinux à supporter des applications au format FDPIC ELF comme VLC. Cependant, nous n avons pas pu vérifier cette incompatibilité, puisque nous avons rencontré également des problèmes de compilation croisée pour VLC. Une solution à explorer serait d utiliser la toolchain elf2flt qui permet de convertir un fichier ELF en BFLT. On convertirait le format FDPIC ELF de VLC en BFLT. Rapport Projet Avancé SE 2009/2010 Page 22 sur 26

23 5. Compilation du VLC sur la carte Blackfin Dans cette partie, on va expliquer les méthodes qu on a mises en œuvre pour configurer la crosscompilation des sources du logiciel VLC et installer celui-ci sur la carte Blackfin DSP. On passe donc par trois parties à savoir la configuration, la cross-compilation et le téléchargement sur la carte. On connecte la carte blackfin au PC hôte par la liaison Ethernet (téléchargement d exécutables) et la liaison série RS232 (console). La toolchain de Blackfin doit être préalablement installée sur la machine hôte. Pour la réalisation de cette étape, on a mis en œuvre deux méthodes différentes. Ces deux méthodes sont présentées ci-dessous Méthode 1 : Cross-compilation de VLC en même temps que celle de µclinux Dans cette première méthode, on installe le noyau µclinux avec les bibliothèques de VLC et FFmpeg. Pour ce faire, on exécute la commande make menuconfig qui nous permet de choisir les différentes bibliothèques ainsi que l application VLC qu on veut installer. Pour rappel, il ne faut pas oublier de spécifier le format FDPIC dans le menu. La version de VLC disponible est la En effectuant cette méthode, on gagne beaucoup de temps en faisant les deux installations du noyau et du logiciel choisi, en même temps Méthode 2 : Cross-compilation de VLC tout seul Dans cette seconde méthode, on sépare l installation du noyau µclinux de la cross-compilation des sources du logiciel VLC. Cette étape peut être faite sur n importe quel PC hôte indépendamment du fait qu il soit connecté à la carte ou pas. La version de VLC utilisée ici est la Il est bon de noter que la politique des concepteurs de VLC en termes de compilation semble être de laisser à l utilisateur le soin de (cross) compiler certaines bibliothèques. VLC ne semble pas être un projet «stand alone» c est-à-dire ne nécessitant aucune action autre que la configuration et la compilation du projet lui-même. La cross-compilation doit donc contenir les étapes suivantes : Lorsque nécessaire, la cross-compilation des bibliothèques requises pour la bonne fonctionnalité de VLC comme libmad par exemple. L exécution du script de configuration configure (présent dans le répertoire vlc.x.x.x) en précisant le type de la cible à savoir Blackfin DSP. On n oublie pas de désactiver les bibliothèques comme qt4 et skins2 (bibliothèques graphiques), inutiles pour l application et la carte qui n a pas les ressources pour les utiliser : $./configure --arch=bfin-linux-uclibc CFLAGS=-std=c99 --disable-qt4 --disable-skins2 Une fois qu on a terminé ces étapes avec succès, on peut passer à la compilation. Rapport Projet Avancé SE 2009/2010 Page 23 sur 26

24 On effectue à chaque compilation l exécution de la commande make clean pour effacer toute trace d une compilation précédente. On lance la compilation avec la commande make Travail effectué Travail effectué avec la méthode 1 : En exécutant la méthode 1 exposée en 5.1, on reçoit toujours des erreurs de compilation (liées au format FDPIC) ce qui nous a poussé à utilisé la deuxième méthode. Travail effectué avec la méthode 2 : Par souci de simplicité et pour que la cross-compilation de VLC pose le moins de problèmes, nous avons décidé d omettre lors de la configuration toutes les bibliothèques qui nécessitaient d être cross-compilées (--disable-<bibliothèque>). Cela ne garantissait pas une bonne fonctionnalité de VLC mais nous permettait de mieux identifier les éventuels problèmes de cross-compilation vraiment liés aux sources du logiciel. Une fois ces problèmes surmontés, nous aurions envisagé d intégrer la crosscompilation des bibliothèques. Une fois les bibliothèques omises et la configuration faite, nous avons lancé la compilation mais des erreurs liées au non-support du standard C99 sont apparues. Le compilateur gcc utilisé dans la toolchain bfin-linux-uclibc ne supportait pas ce standard et les développeurs de VLC l ont utilisé pour écrire les sources. Nous avons tenté d utiliser les autres versions de compilateurs gcc3.4 ou gcc4.1 de la même toolchain mais il semble que le script ne les reconnaisse pas ou qu ils ne soient tout simplement pas compilés. Nous avons essayé la méthode 2 sur des versions plus anciennes de VLC (0.3, 0.5 etc ) mais le résultat reste toujours le même : des erreurs de non support de standard C99. Rapport Projet Avancé SE 2009/2010 Page 24 sur 26

25 Conclusion Dans ce projet, nous avons essayé de mettre en œuvre un serveur de streaming qui permet de télécharger et d adapter des vidéos suivant des exigences précisées par un client qui peut être un ordinateur, un téléphone portable ou tout autre appareil. Pour cela, nous avons choisi d utiliser les sources du logiciel VLC qui permet d effectuer un streaming entre deux hôtes et aussi de faire la conversion de la vidéo sur un format choisi. Nous avons essayé ensuite de mettre ce logiciel sur deux processeurs différents pour pouvoir comparer les performances. Les deux processeurs sont ARM et Blackfin DSP. Nous avons réussi à installer le noyau µclinux sur la carte blackfin mais malheureusement la compilation en format FDPIC ainsi que la compilation des sources de VLC pour les deux cartes n a pas réussi. L utilisation de VLC est peut être à abandonner, trop incompatible avec la toolchain de Blackfin. Autrement, ce projet nous a permis de voir les problèmes de la cross-compilation et de gagner une bonne expérience dans le domaine des systèmes embarqués. Rapport Projet Avancé SE 2009/2010 Page 25 sur 26

26 Bibliographie Logiciel Client/Serveur: Démon : Site d Analog Devices pour Blackfin : Blackfin Koop, site entièrement dédié au portage de µclinux sur Blackfin : Installation de la toolchain bfin- : Compilation de µclinux pour la Blackfin : Installation de VLC sur la Blackfin avec µclinux : ARM : Sources de VLC : Rapport Projet Avancé SE 2009/2010 Page 26 sur 26