développement d’un lecteur multimédia sous windows mobile · (iso/cei 13818-3) et a été...

E.N.S.E.I.R.B

Développement d’un

lecteur multimédia sous

Windows Mobile Projet avancé de Systèmes Embarqués

Nicolas ROBIN, Jonathan GUILLOT, Romain MONTAGNE, Mathieu ALBRESPY

05/01/2009

Encadrants : Ismail Djama et Toufik Ahmed

L’objectif de ce projet est le développement d’un simple lecteur multimédia pour la plateforme Windows CE (Windows Mobile). Le logiciel devra supporter le format de codage AAC pour les flux audio et le format de codage H.264 pour les flux vidéo.

Projet SE : Développement d’un lecteur multimédia sous Windows CE

Document réalisé par Nicolas ROBIN, Jonathan GUILLOT, Romain MONTAGNE, Mathieu ALBRESPY

Sommaire I – Introduction ........................................................................................................................... 4

1 – Cahier des charges ......................................................................................................................... 4

2 – Les nomes H.264 et AAC ................................................................................................................ 4

A) La norme H.264 ........................................................................................................................... 4

B) La norme AAC .............................................................................................................................. 5

3 – L’environnement Windows Mobile ............................................................................................... 6

II – Etat de l’art ........................................................................................................................... 7

1 – Introduction à DirectShow ............................................................................................................ 7

A) Présentation ................................................................................................................................ 7

B) Principe de fonctionnement de DirectShow ................................................................................ 8

2 – Implémentation de DirectShow sur Windows Mobile .................................................................. 9

A) Filtres supportés .......................................................................................................................... 9

B) Formats audio supportés ............................................................................................................ 9

C) Formats vidéo supportés ............................................................................................................. 9

III – Construction d’une interface graphique ........................................................................... 10

1 – Création d’un projet Windows mobile sous Visual C++ .............................................................. 10

2 – Création d’un menu ..................................................................................................................... 12

3 – Création d’une boite de dialogue ................................................................................................ 13

4 – Interaction avec le menu ............................................................................................................. 14

5 – Lancement d’évènement lors d’un appui sur l’écran .................................................................. 16

6 – Interaction avec les éléments de l’interface Windows Mobile ................................................... 17

7 – Modification de la couleur de fond ............................................................................................. 18

IV – Construire un filtre DirectShow ........................................................................................ 19

1 – Introduction ................................................................................................................................. 19

2 – Ecrire un filtre de transformation ................................................................................................ 20

3 - Un filtre de transformation dédié au décodage AAC ................................................................... 21

V – Les solutions alternatives ................................................................................................... 25

1 – Mplayer ........................................................................................................................................ 25

2 – VLC ............................................................................................................................................... 25

3 – TCPMP ......................................................................................................................................... 25

VI – Conclusion ......................................................................................................................... 26



I – Introduction

1 – Cahier des charges

L’objectif de ce projet est le développement d’un simple lecteur multimédia pour la

plateforme Windows CE (Windows Mobile). Le logiciel devra supporter le format de codage AAC pour les flux audio et le format de codage H.264 pour les flux vidéo. Le développement du lecteur se base sur la plateforme multimédia DirectShow conçu par Microsoft pour ses plateformes Windows afin de faciliter la manipulation et la lecture de flux multimédia. Les outils de développement DirectShow sont distribués avec le Windows SDK dédié à la plateforme visée. La technologie DirectShow se base principalement sur le modèle d’objet composant (COM) de Windows qui lui permet d’offrir une interface commune pour la manipulation des flux multimédia à travers différents langages de programmation. L’utilisation de DirectShow facilitera le développement du lecteur tout en permettant son extension pour intégrer d’autres fonctionnalités.

L’équipe COMET dispose d’une plateforme IPTV pour la diffusion de flux DVB-T sur les réseaux Wifi 802.11 pour des terminaux mobiles et hétérogènes (PC portable, téléphone, PDA). L’objectif final de ce projet et de développer notre lecteur multimédia qui sera embarqué dans des terminaux mobiles fonctionnant avec Windows CE. Ce lecteur pourra par la suite être augmenté par plusieurs fonctionnalités intégrées à notre plateforme.

2 – Les nomes H.264 et AAC

A) La norme H.264

H.264, ou MPEG-4 AVC (Advanced Video Coding), est une norme de codage vidéo

développée conjointement par l'UIT-T Q.6/SG16 Video Coding Experts Group (VCEG) ainsi que l'ISO/CEI Moving Picture Experts Group (MPEG) et est le produit d'un effort de partenariat connu sous le nom Joint Video Team (JVT). La norme UIT-T H.264 et la norme ISO/CEI MPEG-4 Part 10 (ISO/CEI 14496-10) sont techniquement identiques, et la technologie employée est aussi connue sous le nom AVC, pour Advanced Video Coding. La première version de la norme a été approuvée en mai 2003 et la plus récente date de mars 2005.

Le nom H.264 provient de la famille de normes vidéo H.26x définies par l'UIT-T. Cependant, ce codec a été développé dans le cadre du MPEG, l'UIT-T se contentant de l'adopter ensuite et de l'éditer en son sein. Dans le cadre du MPEG, l'acronyme AVC (Advanced Video Coding) fut choisi par analogie avec le codec audio AAC MPEG-2 part 7 qui avait été nommé ainsi pour le différencier du codec audio MPEG-2 part 3 (le fameux MP3). La norme est habituellement appelée H.264/AVC (ou AVC/H.264, H.264/MPEG-4 AVC ou MPEG-4/H.264 AVC) pour souligner l'héritage commun. Le nom H.26L, rappelant son lien avec l'UIT-T est nettement moins commun mais toujours utilisé. De temps en temps, il est aussi appelé « le codec JVT », en référence à l'organisation JVT (Joint Video Team) qui l'a développé. Il existe un précédent dans l'élaboration d'une norme de codage vidéo commune entre le MPEG et l'UIT-T avec MPEG-2 et H.262 qui sont identiques.

À l'origine, l'UIT-T lança le projet H.26L en 1998 dans le but de créer une nouvelle architecture de codec ayant pour but un gain en efficacité de codage d'un rapport au moins égal à 2 par rapport aux standards existants (MPEG-2, H.263 et MPEG-4 Part 2). Un autre but était de créer une interface simple pour pouvoir adapter le codec aux différents protocoles de transport (commutation de paquets et de circuits). Le codec a été développé en s'assurant qu'il serait transposable sur plateformes à un coût raisonnable, c'est-à-dire en tenant compte des progrès réalisés par l'industrie des semi-conducteurs en matière de design et des procédés.

En 2001, le projet H.26L avait atteint ses objectifs en taux de compression comme le démontrèrent des tests subjectifs réalisés par… MPEG. C'est à ce moment que l'ITU-T et MPEG



décidèrent d'un commun accord de créer le Joint Video Team (JVT) dans le but de standardiser le codec ensemble et de l'adapter aux différents besoins de l'industrie (vidéophonie, streaming, télévision, mobile). En effet, les applications traditionnellement visées par l'ITU-T concernent les bas débits (vidéophonie, mobile), applications pour lesquelles H.26L était optimisé, alors que les membres de MPEG désiraient l'adapter à d'autres formats (télévision, HD). Des outils algorithmiques comme le support de l'entrelacé ont été ajoutés et une réduction de la complexité a été accomplie.

Le codec H.264/AVC est donc adapté à une très grande variété de réseaux et de systèmes (par exemple, pour la diffusion de la télévision, le stockage HD DVD et Blu-ray, le streaming RTP/IP, et des systèmes de téléphonie propre à l'ITU-T).

À la suite de la première version de la norme, le JVT a développé quelques extensions, connues sous le nom Fidelity Range Extensions (FRExt). Ces extensions ont pour but de prendre en charge une précision de quantification accrue (ajout des codages 10-bit et 12-bit) et une meilleure définition de la chrominance (ajout des structures de quantification YUV 4:2:2 et YUV 4:4:4) et visent des applications professionnelles (Studio). Plusieurs autres fonctionnalités ont aussi été adoptées pour améliorer la qualité subjective en haute définition (ajout d'une transformée 8×8 en plus de la transformée 4×4 existante, ajout de matrices de quantification) ou pour des besoins spécifiques (codage sans perte, support d'autres espaces de couleurs). Le travail de conception sur les Fidelity Range Extensions a été finalisé en juillet 2004, et figé en septembre 2004.

Depuis la fin du développement de la version originale de la norme en mai 2003, le JVT a fait publier 4 versions approuvées par l'UIT-T et MPEG, correspondant à l'ajout de FRExt et à des corrections.

B) La norme AAC

Advanced Audio Coding (AAC) est un algorithme de compression audio avec perte de

données ayant pour but d’offrir un meilleur rapport qualité/ débit binaire que le format plus ancien MPEG-1/2 Layer 3 (plus connu sous le nom de MP3). Pour cette raison, il a été choisi par différentes firmes comme Apple ou Real Networks.

Il a été conçu par le Fraunhofer Institut für integrierte Schaltungen en collaboration avec AT&T, Sony et Dolby pour remplacer le MP3. L’AAC, ISO/CEI 13818-7, est une extension du MPEG-2 (ISO/CEI 13818-3) et a été amélioré en MPEG-4, MPEG-4 Version 2 et MPEG-4 Version 3 (ISO/CEI 14496-3). Il a été déclaré standard international par le Moving Pictures Expert Group (MPEG) fin avril 1997.

Les améliorations apportées par l’AAC touchent notamment :

• les fréquences d’échantillonnage : de 8 kHz à 96 kHz (MP3 officiel : 16 à 48 kHz) ; • le nombre de canaux : jusqu’à 48 ; • une efficacité de codage améliorée pour les signaux stationnaires (la taille des blocs a été

portée de 576 à 1 024 échantillons) ; • une efficacité de codage améliorée pour les signaux de transition (la taille des blocs a été

réduite de 192 à 128 échantillons) ; • une meilleure gestion des fréquences au-delà de 16 kHz ; • une jonction stéréo (joint-stereo) plus souple (distincte pour chaque bande) ; • une compatibilité de gestion numérique des droits (DRM) pour contrôler l’utilisation des

fichiers dans ce format. Ces avancées techniques devant apporter à l’auditeur un message audio d’une qualité et d’une stabilité accrue par rapport au MP3 à fréquence d’échantillonnage équivalente ou inférieure.

L’AAC adopte une approche modulaire du codage : en fonction de la complexité du flux à coder, de la qualité visée et de la taille du fichier que l’on souhaite obtenir. L’utilisateur peut créer des profils afin de définir l’outil qu’il souhaite utiliser parmi le jeu de réglages prédéfinis.



3 – L’environnement Windows Mobile

Microsoft Windows Mobile (surnommé WiMo) est le nom générique donné à différentes versions de Microsoft Windows conçues pour des appareils mobiles tels que les Smartphones ou Pocket PC. La version utilisée lors de ce projet est Windows Mobile 5.0 sur un PDA DELL Axim X51.

Windows Mobile 5.0 répond au nom de code "Magneto" et fut lancée le 9 mai 2005. C'est l'évolution de Microsoft Pocket PC. Ce système d’exploitation est basé sur Windows CE 5.0 auquel il lui ajoute le framework Microsoft .NET.

La dernière version en date Windows Mobile 6.5 a été annoncée le 3 novembre 2008. La version 7, censé marquer une véritable rupture avec les anciennes versions devrait être dévoilé dans le courant de l’année 2009.

Pour développer pour Windows Mobile 5, différents outils sont nécessaires :

- Microsoft Visual Studio 2005 : Visual Studio est un ensemble complet d'outils de développement permettant de générer des applications Web ASP.NET, des Services Web XML, des applications bureautiques et des applications mobiles.

- Microsoft Mobile 5.0 SDK for Pocket PC : cette installation ajoute les fonctionnalités et les biblitohèques nécessaires pour développer une application à destination d’une plateforme Mobile 5.0.

- ActiveSync/MobileCenter : utilitaire pour la communication et synchronisation

entre l’ordinateur et le Pocket PC. ActiveSync est la version Windows XP tandis que MobileCenter est son équivalent pour Vista.

L’avantage de la suite Microsoft Mobile est son émulateur de Pocket PC qui permet aux

développeurs de tester directement la réaction de leur programme par le Pocket PC. Les options de Windows Mobile permettent de simuler le Pocket PC au niveau de l’ordinateur ou il est connecté, et ainsi avec l’outil ActiveSync/Mobile Center de venir interagir avec l’outil simulé.



II – Etat de l’art

1 – Introduction à DirectShow

A) Présentation

DirectShow est une librairie multimédia développée par Microsoft permettant la gestion de flux audio et vidéo.

Avec l’apparition de Windows 95, Microsoft initia un projet répondant au nom de Quartz. Celui-ci a été créé dans l’optique de fournir des APIs (Application Programming Interface) pour le support des vidéos MPEG dans un environnement 32 bits. Rapidement, en 1995, Quartz proposa un support complet pour le traitement audio et vidéo, devenant ainsi ActiveMovie, qui n’était alors qu’une composante du SDK de DirectX (package regroupant toutes les libraires pour le développement multimédia de Microsoft). Puis, en 1996, ActiveMovie devient DirectShow, afin de mettre en avant sa relation avec DirectX.

Dès 1998, DirectShow propose le support des DVDs, puis c’est finalement en 2000 que DirectShow devient une composante à part entière de DirectX, et est alors intégré à la version 8 de celui-ci. A partir de cette version, il est alors possible de faire du streaming ou de l’édition de vidéo. L’application Windows Movie Maker tire d’ailleurs partie de ces fonctionnalités. Actuellement la toute dernière version de DirectX est la 9.0c, dans laquelle il est désormais possible d’utiliser un flux vidéo en tant que texture sur on objet 3D créé avec Direct3D.

Il existe de nombreux logiciels utilisant l’API DirectShow sur les plateformes Win32. On peut citer parmi ceux-ci :

� Quick time Alternative � Windows Media Player � Adobe Premiere � Ulead Media Studio

Une implémentation quelque peu réduite de l’API DirectShow est aussi disponible sur les

plateformes Windows CE. Le nombre de fonctionnalités disponibles n’est par contre pas identique suivant que l’on développe pour Windows Embedded CE ou Windows Mobile. La suite de cette partie fera état des fonctionnalités supportée sur le système d’exploitation Windows Mobile 5.0.



B) Principe de fonctionnement de DirectShow

DirectShow est une API basé sur la construction de graphe permettant de traiter le flux

multimédia. Une tâche complexe de traitement est divisée en plusieurs étapes élémentaires consécutives (lire un fichier, décoder un flux …). Ces étapes sont réalisées par ce que l’on nomme les filtres DirectShow.

Il existe trois classes de filtre utile pour une application DirectShow :

- Les filtres sources, qui produisent des flux soit à partir d’un fichier se trouvant sur un espace de stockage (disque dur, mémoire Flash…), soit à partir de périphériques spécifiques tels qu’une webcam, un microphone, etc.

- Les filtres de transformation, qui reçoivent un flux d’entrée (généralement des filtres

sources) afin d’effectuer des opérations sur ces flux puis les transmettre à un autre filtre. Exemple d’application : codage en fichier ASF, décodage d’un AAC…

- Les filtres de rendu, qui traduisent les flux DirectShow pour les envoyer vers la sortie. Par

exemple, il est possible d’écrire un fichier directement sur le disque dur, ou encore vers le périphérique de rendu d’affichage (écran) ou de son (haut-parleurs).

Afin de réaliser une application DirectShow il suffit donc d’assembler plusieurs filtres dans le

but de réaliser une fonction bien définie. Un jeu de filtre ainsi associé se nomme un graphe de filtres.

L’application finale peut ne pas gérer individuellement chacun des blocs, il existe pour cela le « Filter Graph Manager », il permet de gérer le flux à travers le graphe de filtres. L’application utilise une API qui permet de faire passer le flux dans un filtre ou bien de la stopper. Si d’autres fonctions veulent être utilisées, il est possible d’accéder directement au filtre via l’interface COM.

Trois étapes élémentaires sont donc nécessaires à la création d’une application DirectShow :

- créer une instance de Filter Graph Manager - utiliser le Filter Graph Manager pour créer un graphe de filtre - contrôler le graphe de filtre et répondre aux évènements

Filtre

Graphe de

filtre



2 – Implémentation de DirectShow sur Windows Mobile

A) Filtres supportés

La liste exhaustive des filtres supportés en natif par Windows Mobile est donnée ci-dessous :

o ACM wrapper o AVI decompressor o AVI splitter o Buffering filter o Color space converter o DMO WMV encoder o DMO wrapper o File source o Image sink o MPEG-1 parser / splitter o MPEG-1 Layer 1 and 2 audio codec o MS RLE video codec o Smart tee o Waveform audio renderer o WAVE/AIFF/AU/SND file parser o WM ASF Writer Filter

B) Formats audio supportés

L’ensemble des filtres disponibles permet donc de supporter les formats audio suivants :

o AIFF o AU o G.711 o GSM 6.10 o MIDI o SND o Wave o ASF audio

C) Formats vidéo supportés

De même, les formats vidéo suivants sont utilisables nativement sur le système Windows

Mobile : o ASF video o AVI o MPEG-4 o MS RLE



III – Construction d’une interface graphique

Comme expliqué précédemment, en schématisant, on peut dire que le développement sous

Windows Mobile est un cas particulier de celui sous Windows Ce, lui inspiré du développement

d’application Win32 (Windows Standard). Par conséquent, la modalité de création d’interface

graphique est proche de celle Win32.

1 – Création d’un projet Windows mobile sous Visual C++

A la création d’un nouveau projet, il faut indiquer que l’on souhaite développer pour une

cible Windows Mobile 5. Pour cela, il faut choisir un projet de type « Smart Device ».

Un assistant s’ouvre permettant d’indiquer la plateforme SDK que l’on utilisera.



De cette manière, le projet créé contient tous les fichiers d’en-tête, fichiers de ressources et fichier de sources nécessaire pour compiler et lancer un projet Windows Mobile 5.

Dans un premier temps, les fichiers de ressources vont

particulièrement nous intéresser, puisque que c’est par leur intermédiaire que nous allons pouvoir réaliser le squelette de l’interface via un éditeur graphique propre à Visual C++. Pour cela, il suffit de double cliquer sur testppc.rc .



2 – Création d’un menu

Un fichier de ressource se décompose en images, boîtes de dialogue, icônes et menus.

Commençons par créer le menu. Pour cela il suffit de cliquer sur le menu IDM_MENU pour

l’éditer ou alors on peut en créer un nouveau. Pour ajouter une barre de menu, un élément ou un sous-élément, il suffit alors de cliquer sur « Tapez ici » et d’entrer une chaîne de caractère. A droite, dans la fenêtre de propriété, il faut vérifier et retenir les ID que possèdent chaque élément du menu. Ces noms d’ID sont utilisés afin de programmer les interactions souhaitées lors d’un appui sur cet élément.



3 – Création d’une boite de dialogue

Pour cela, il suffit de cliquer droit sur Dialog et de valider Insérer Dialog. Une boite vierge

s’affiche ainsi que l’éditeur de boite de dialogue.

L’éditeur permet d’insérer différents éléments comme des boutons, des cases à cocher, des zones de texte ou des images.

Dans notre cas, nous souhaitons ajouter une image à notre boîte en cliquant sur « Picture

Control ». Ensuite, il suffit d’ajouter une image au format bitmap du disque dur dans le dossier bitmap et d’indiquer le nom de cette image dans les propriétés de la zone de dessin que l’on vient d’ajouter.



4 – Interaction avec le menu

Les interactions avec les différents éléments du menu sont décrites dans la fonction du fichier principal :

LRESULT CALLBACK WndProc(HWND hWnd,UINT message,WPA RAM wParam,LPARAM lParam)

Dans la boucle : switch (wmId), nous listons les différents cas où l’on souhaite interagir à l’aide des ID des éléments concernés.

// Analyse les sélections de menu switch (wmId) { // Selection de fichier case ID_MENU_OPENFILE: video = new Video(hWnd); //PostQuitMessage(1); video->play(); //return DefWindowProc(hWnd, message, wParam, lPara m); break ; // Lancement d'une boîte de dialogue case ID_APROPOS_EXPLICATION: DialogBox(g_hInst,(LPCTSTR)IDD_POCKETPC_SQUAR E,hWnd,(DLGPROC)Help); break ; case ID_APROPOS_CREDIT: DialogBox(g_hInst, (LPCTSTR)IDD_CREDIT, hWnd, (DLG PROC)Help); break ; // Interaction avec d'autres elements de menu case ID_POPUP_PLEINECRAN: plein_ecran=1; fullscreen(hWnd,rc,cx,cy); break ; case ID_MENU_QUITTER: video->Clean(); delete video; PostQuitMessage(0); break ; default : return DefWindowProc(hWnd, message, wParam, lParam); }



Nous appelons les boites de dialogue crées par l’instruction suivante : DialogBox(g_hInst,(LPCTSTR) ID de la boite de dialogue,hWnd,(DLGPROC)Help);

Voici le rendu d’une des boites de dialogue développée pour le projet :

Le dimensionnement et l’affichage du bon de validation ne sont pas décrit dans le fichier de ressources. Ces paramétrages sont défini dans la fonction : BOOL CALLBACK Help(HWND hDlg, UINT Msg, WPARAM wParam, LPARAM lParam).



5 – Lancement d’évènement lors d’un appui sur l’écran

Dans la fonction :

LRESULT CALLBACK WndProc(HWND hWnd,UINT message,WPA RAM wParam,LPARAM lParam)

Le cas : « case WM_LBUTTONDOWN: » permet de gérer l’appui.

Nous souhaitons que lors d’un premier appui sur l’écran qu’un menu s’affiche proposant de passer en plein écran et lors d’un deuxième (lorsqu’on est en plein écran, on quitte le mode plein écran.

case WM_LBUTTONDOWN: // Si on est pas en mode plein écran if (plein_ecran==0) { // On intéragi avec le menu dynamique ID_POPUP_PLEI NECRAN GetClientRect(hWnd, (LPRECT)&rc); LONG2POINT(lParam, pt); if (PtInRect((LPRECT)&rc, pt)) { HandlePopupMenu(hWnd, pt); } } // Si on est en mode plein écran on le quitte else { plein_ecran=0; notfullscreen(hWnd,rc,cx,cy); } break ;



6 – Interaction avec les éléments de l’interface Windows Mobile

Par défaut, l’interface Windows mobile est constitué d’une barre menu inférieur (calendrier, contact) et supérieur (Démarrer), ainsi que quelque boutons SIP (ActiveSync, son, heure).

Dans notre cas, pour passer en plein écran, il faut rendre invisible ces éléments et redimensionner la fenêtre.

void fullscreen (HWND hWnd,RECT rc, static int cx, static int cy) { //Masquage des élèments DoSHFullScreen(hWnd, SHFS_HIDETASKBAR); DoSHFullScreen(hWnd, SHFS_HIDESIPBUTTON); ShowWindow(g_hwndCB, SW_HIDE); //Redimensionnement de la fenetre rc.left = 0; rc.top = 0; rc.right = cx; rc.bottom = cy; MoveWindow(hWnd, rc.left, rc.top, rc.right, rc.bot tom, TRUE); }

Les valeurs cx et cy représentent respectivement les valeurs maximales de l’écran en abscisse et en ordonnée. C’est valeurs sont récupérées grâce aux instructions :

HDC hdc = GetDC(hWnd); static int cx = GetDeviceCaps(hdc, HORZRES); static int cy = GetDeviceCaps(hdc, VERTRES);



7 – Modification de la couleur de fond

La couleur de fond par défaut est blanche. Dans le cas du lecteur vidéo, un fond noir est plus approprié.

Pour cela, il faut indiquer le « pinceau » que l’on souhaite utiliser lors de l’inscription de la classe fenêtre (ATOM MyRegisterClass(HINSTANCE hInstance, LPTSTR

szWindowClass )), avec la méthode hbrBackground.

Le plus simple est d’utiliser des pinceaux prédéfinis à partir de l’appel : GetStockObject().

Par conséquent, nous avons utilisé l’instruction suivante :

wc.hbrBackground = (HBRUSH) GetStockObject (BLACK_B RUSH);

Voici les pinceaux prédéfinis existant :

Valeur Description

BLACK_BRUSH Pinceau noir

DKGRAY_BRUSH Pinceau gris foncé.

GRAY_BRUSH Pinceau gris

HOLLOW_BRUSH ou NULL_BRUSH Pinceau « invisible »

LTGRAY_BRUSH Pinceau gris clair.

WHITE_BRUSH Pinceau blanc

Comme on peut le voir, il en existe peu. Cependant il est possible de créer ses propres pinceaux avec la fonction : CreateSolidBrush(RGB(« code RGB »)).



IV – Construire un filtre DirectShow

1 – Introduction

Comme décrit précédemment, l’implémentation de DirectShow sur la plateforme Windows

Mobile, n’offre nativement que peu de filtres. Par conséquent, les formats audio et vidéo supportés par tout lecteur multimédia utilisant DirectShow sont assez limités.

De plus, le développement de filtres pour Windows Mobile ne semble avoir eu jusqu’ici que peu d’engouement. Les filtres tiers disponibles sont très rares. On pourra cependant citer la solution commerciale Hantro - On2 Embedded proposant un ensemble de filtres DirectShow :

o Filtres source

� .MP4, .3GP � streaming .3GPP

o Filtres de transformation

� MPEG-4, H.263 � H.264 � AMR � AAC+

o Filtres de rendu

� Conversion de couleurs � Mise à l’échelle � Recadrage

Cette partie tâche donc d’exposer le principe de construction d’un filtre DirectShow et plus

précisément d’un filtre de transformation. Ce type de filtre est souvent utilisé afin de :

o compresser ou décompresser des données o séparer le contenu audio du contenu visuel o appliquer certains effets sur les données, comme du contraste ou autre

MP4 AAC Filtre de transformation Données brutes (PCM)



2 – Ecrire un filtre de transformation

Ecrire un filtre DirectShow consiste, et ce quelque soit la nature du filtre, à créer une librairie

dynamique (DLL) contenant la classe de ce filtre. Bien qu’un langage dit managé comme le C# peut être utilisé, le langage de prédilection dans cette opération reste le C++. La classe du filtre doit hériter de classes prédéfinies dépendant de la nature du filtre que l’on cherche à concevoir, et surcharger un certains nombre de méthodes.

Dans le cas d’un filtre de transformation, deux classes de bases peuvent être utilisées. La seule différence réside dans le nombre de méthodes qu’il faudra alors surcharger. Les classes de base sont donc : CTransformFilter et CTransInPlaceFilter. Dans le cas d’un développement sur Windows Mobile, le choix sera bien vite fait car seule la première de ces classes est implémentée.

Méthodes Description

Transform Implémente l’algorithme de transformation des données

CheckInputType Vérifie le type des données en entrée du filtre.

CheckTransform Vérifie que le filtre supporte la transformation (est uniquement utilisé pour les compilations en mode Debug)

GetMediaType Fixe le type de données présentes en sortie du filtre.

DirectShow utilise le mécanisme Component Object Model (COM), il est donc aussi

nécessaire d’ajouter à notre classe une méthode permettant d’instancier notre objet filtre, à savoir la méthode CreateInstance.

Enfin, le filtre est construit comme tout autre librairie dynamique sous Windows et doit donc intégrer les fonctions DLLRegisterServer et DLLUnregisterServer afin d’enregistrer notre filtre dans la base de registre du système. L’utilitaire Regsvr32 présent sur la plateforme Win32 trouve son équivalent mobile avec l’utilitaire nommé RegsvrCE. Celui-ci est capable de charger la librairie en mémoire, puis d’exécuter la fonction DLLRegisterServer ou DLLUnregisterServer afin d’enregistrer ou supprimer l’entrée correspondante dans la base de registre.



3 - Un filtre de transformation dédié au décodage AAC

Afin d’étendre les fonctionnalités du lecteur multimédia développé et à défaut de trouver les

filtres adaptés pour la plateforme Windows Mobile, il a été décidé de développer un filtre capable de décoder les données AAC.

Le développement de filtre DirectShow pour plateforme Win32 présentant quelques similarités avec celui sur mobile, le projet open source DirectShow-AAC-DecoderWrapper distribué sous GNU LGPL, a donc été un bon point de départ. Le projet propose un filtre de décodage des flux audio encodé au format AAC en utilisant une bibliothèque adaptée : FAAD1 (qui fait partie du projet Freeware Advanced Audio Coder). Les deux projets sont disponibles sur Sourceforge.net. Le but a donc été d’adapter ce filtre a la plateforme mobile de Microsoft, ainsi que d’utiliser une version plus récente de la bibliothèque FAAD, à savoir FAAD2. La compilation de cette bibliothèque est réalisable sur Windows Mobile. Un projet « Embedded Visual » est disponible dans les sources du projet mais il est aussi possible de choisir d’utiliser le projet Visual Studio fourni. Il suffit alors de définir la cible comme étant Windows Mobile, tout en ayant également bien pris soin de modifier quelques paramètres de configuration du projet.

La suite de cette partie donne un aperçu du code du filtre, à commencer par les surcharges

des méthodes Transform et CheckInputType.

HRESULT CAACDecoder::CheckInputType( const CMediaType *pmtIn) { if ((*pmtIn->Type() != MEDIATYPE_Audio) && (*pmtIn- >Subtype() != MEDIASUBTYPE_AAC) || (*pmtIn->Type() != MEDIATYPE_Audio) && (*pmtIn - >Subtype() != MEDIASUBTYPE_MP4A)) return VFW_E_TYPE_NOT_ACCEPTED; WAVEFORMATEX *pInputFormat = (WAVEFORMATEX *)pmtIn ->Format(); m_nSamplesPerSec = pInputFormat->nSamplesPerSec; m_nBitsPerSample = pInputFormat->wBitsPerSample; m_nChannels = pInputFormat->nChannels; m_nESConfigSize = pInputFormat->cbSize; if ((!m_pbESConfiguration) && m_nESConfigSize) { m_pbESConfiguration = new BYTE [m_nESConfigSize]; memcpy(m_pbESConfiguration,( char *) pInputFormat + sizeof (WAVEFORMATEX), m_nESConfigSize); } return S_OK; }



Dans l’API DirectShow, à chaque format de données multimédia est associé un identifiant unique pour le type dit majeur et pour le sous-type.

Il suffit alors de vérifier dans notre fonction CheckInputType si le format proposé en entrée correspond à ce que le filtre peut traiter. Si ce n’est pas le cas, l’erreur VFW_E_TYPE_NOT_ACCEPTED est renvoyée. Ici, notre filtre peut donc accepter les médias suivants :

o flux audio AAC o flux audio MP4-AAC

La suite de la fonction se charge uniquement de récupérer les valeurs importantes fournies

en entrée du filtre (nombre de canaux, etc…).

HRESULT CAACDecoder::Transform(IMediaSample *pIn, I MediaSample *pOut) { BYTE *pInput = NULL; BYTE *pOutput = NULL; if (pIn->GetPointer(&pInput) != S_OK) return S_OK; if (pOut->GetPointer(&pOutput) != S_OK) return S_OK; DWORD dwSrcLength = pIn->GetActualDataLength(); DWORD dwDstLength = pOut->GetSize(); // decode if (m_pBuffer == NULL) m_pBuffer = new BYTE[4 * 8 * m_nChannels * 1024]; NeAACDecFrameInfo hInfo; m_pBuffer = (BYTE*) NeAACDecDecode(m_hDecoder, &hI nfo, ( unsigned char *)pInput, dwSrcLength); if (hInfo.error != 0) return S_FALSE;



// copy to output buffer memcpy(pOutput, m_pBuffer, hInfo.samples * m_nChann els * sizeof ( short )); DWORD dwActualDstLength = hInfo.samples * sizeof ( short ); pOut->SetActualDataLength(dwActualDstLength); return S_OK; }

La fonction Transform utilise donc, comme prévu une fonctionnalité de décodage de

données au format AAC contenue dans une mémoire tampon, fournie par la bibliothèque FAAD2 : NeAACDecode. Le buffer contenant alors les données brutes est alors fournie à la sortie du filtre.

Une autre partie intéressante du code est la description globale du filtre. Il y est précisé le

nombre de broches total, ainsi que les types de données en entrée ou en sortie ou le nom sous lequel sera connu le filtre. Le « MERIT » du filtre y est aussi mentionné. Ce nombre désigne en fait la priorité que peut avoir un filtre par rapport à un autre pouvant traiter les même type de données, information utilisé lors du processus de construction automatique de graphe DirectShow par le système.

const AMOVIESETUP_MEDIATYPE sudMediaInputType[2] = // Input media types { {&MEDIATYPE_Audio, &MEDIASUBTYPE_MP4A}, {&MEDIATYPE_Audio, &MEDIASUBTYPE_AAC}, }; const AMOVIESETUP_MEDIATYPE sudMediaOutputType[] = {&MEDI ATYPE_Audio, &MEDIASUBTYPE_PCM}; // Output media type const AMOVIESETUP_PIN sudPins[] = { { L "Input" , // pin name FALSE, // is rendered FALSE, // is an output pin FALSE, // allowed none FALSE, // allowed many &CLSID_NULL, // connects to filter NULL, // connects to pin 2, // number of types sudMediaInputType // pin details }, { L "Output" , // pin name FALSE, // is rendered TRUE, // is an output pin FALSE, // allowed none FALSE, // allowed many &CLSID_NULL, // connects to filter NULL, // connects to pin 1, // number of types sudMediaOutputType // pin details } }; AMOVIESETUP_FILTER sudFilterReg = // Filter description {



&CLSID_AACDECODER, // CLSID L "GigAACDecoder" , // filter name MERIT_NORMAL, // merit 2, // number of pins sudPins // structure providing pins information };

On peut enfin s’attarder un peu sur la fonction DLLRegisterServer, appellée afin d’enregister

le filtre dans la base de registre du système.

STDAPI DllRegisterServer() { HRESULT hr = AMovieDllRegisterServer(); if (FAILED(hr)) return hr; IFilterMapper *pFm = 0; hr = CoCreateInstance(CLSID_FilterMapper, NULL, CLS CTX_INPROC_SERVER, IID_IFilterMapper, ( void **)&pFm ); if (FAILED(hr)) return hr; hr = pFm->RegisterFilter(CLSID_AACDECODER, L "GigAACDecoder" , MERIT_NORMAL); pFm->Release(); return hr; }

La méthode RegisterFilter est ici utilisé pour réaliser cette opération. Il est nécessaire de lui

passer en argument un CLSID (Class Identifier) utilisé dans le mécanisme COM , ainsi que le « MERIT » accordé au filtre.

La macro DEFINE_GUID (GUID : Globally Unique Identifier) permet de créer le CLSID précédent. L’utilitaire Microsoft UUIDGEN.EXE permet de générer un tel identifiant.

// Filter GUID DEFINE_GUID(CLSID_AACDECODER, 0x8b336527, 0x76f8, 0 x4668, 0xa8, 0x00, 0x6f, 0x6c, 0x9c, 0xa0, 0x90, 0xfa);

Projet SE :

Document réalisé par Nicolas ROBIN, Jonathan GUILL

V – Les solutions alternatives

FFmpeg est une collection de projet a été créé par Fabrice BellardMPlayer. FFmpeg est publié sous licence GPL. Développé sous Linux, il peut être compilé sur la plupart des Windows et Windows Mobile. FFmpeg supporte les fichiers vidéo et audio AVI, MPEG et ASF et les codecs WMV, WMA et Sorenson 3 FFmpeg est souvent considéré comme une alternative sérieuse à DirectShow, que ce soit dans les applications sur les plateformes Win32 ou plus spécifique comme Windows Mobile.

1 – Mplayer

MPlayer

licence publique générale GNUtrès grand nombre de formats vidéo. Windows Mobile.

2 – VLC

VLC Media Player (à l'origine

VideoLAN. Ce logiciel tendances GNU/Linux

plateformes. Il est distribué sous licence Un des grands atouts de VLC est qu'il intègre les plupart des formats audio et vidéo.VLC prend en charge les codecs vidéo H.264 et audio AAC.

3 – TCPMP

TCPMP est un ancien projet open source distribué sous

devenu une alternative commerciale nommée CorePlayer.libres FFmpeg et autres plugins qui lui permettent de lire un panel assez large de formats de fichiers et de codecs audio et vidéo.

: Développement d’un lecteur multimédia sous Windows CE


alternatives

est une collection de logiciels libres dédiés au traitement de flux audio ou vidéo. Ce Fabrice Bellard en 2000. Il est actuellement hébergé sur les serveurs du projet

. FFmpeg est publié sous licence GNU LGPL mais incorpore des modules sous licence , il peut être compilé sur la plupart des systèmes d'exploitation

FFmpeg supporte les fichiers vidéo et audio AVI, MPEG et ASF et les MV, WMA et Sorenson 3.

FFmpeg est souvent considéré comme une alternative sérieuse à DirectShow, que ce soit dans les applications sur les plateformes Win32 ou plus spécifique comme Windows Mobile.

MPlayer est un lecteur multimédia libre et open sourcelicence publique générale GNU version 2, et connu pour prendre en charge un très grand nombre de formats vidéo. Mplayer a de plus connu un portage sur Windows Mobile.

(à l'origine VideoLAN Client) est un lecteur multimédia est multiplateformes puisqu'il fonctionne sous

Linux, Mac OS X, et même Pocket PC, soit en tout près de 20 plateformes. 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. VLC prend en charge les codecs vidéo H.264 et audio AAC.

TCPMP est un ancien projet open source distribué sous GNU GPL. La solution est désormais devenu une alternative commerciale nommée CorePlayer. Ce lecteur s’appuie sur

plugins qui lui permettent de lire un panel assez large de formats de fichiers

T, Romain MONTAGNE, Mathieu ALBRESPY

dédiés au traitement de flux audio ou vidéo. Ce . Il est actuellement hébergé sur les serveurs du projet

mais incorpore des modules sous licence GNU systèmes d'exploitation, y compris

FFmpeg supporte les fichiers vidéo et audio AVI, MPEG et ASF et les

FFmpeg est souvent considéré comme une alternative sérieuse à DirectShow, que ce soit dans les applications sur les plateformes Win32 ou plus spécifique comme Windows Mobile.

open source distribué sous la version 2, et connu pour prendre en charge un

Mplayer a de plus connu un portage sur

lecteur multimédia libre issu du projet est multiplateformes puisqu'il fonctionne sous Windows, toutes les

, soit en tout près de 20

nécessaires à la lecture de la

GNU GPL. La solution est désormais Ce lecteur s’appuie sur les bibliothèques

plugins qui lui permettent de lire un panel assez large de formats de fichiers



VI – Conclusion

La réalisation d’un projet DirectShow pour plateforme Mobile nécessite l’utilisation de plusieurs outils de programmation et de traitement des données. Une grande partie du projet a porté sur la recherche des outils nécessaire à la réalisation de ce projet ainsi que des outils de communication entre le Pocket PC et l’ordinateur.

La programmation multimédia utilisant l’API DirectShow ne semble connaitre qu’assez peu

d’engouement auprès des développeurs tiers. Ceci peut être du à une implémentation que partielle de l’API sur la plateforme Windows Mobile, ne fournissant alors pas toutes les fonctionnalités que l’on retrouve sur les plateformes Win32. Il est ainsi difficile de trouver de la documentation ou autres ressources concernant DirectShow pour Windows Mobile.

La suite de développement Microsoft Visual Studio pour plateforme mobile offre une

multitude d’outils pour réaliser une interface graphique simple et conviviale, aisément. Ainsi nous avons pu mettre en place une interface graphique gérant la lecture d’un fichier multimédia ou encore l’affichage plein écran.

De manière générale, seule la partie décodage des flux audio et vidéo n’est pas fonctionnelle.

Pour remédier à ce problème, nous avons axé les recherches de notre projet, d’une part sur la réalisation manuelle de filtres permettant le décodage des flux audio AAC et vidéo H.264, d’autre part sur des solutions alternatives, comme l’utilisation de projet de type FFMPEG.

développement d’un lecteur multimédia sous windows mobile · (iso/cei 13818-3) et a été...

Documents