INTRODUCTION GENERALE

La forte croissance des flux des donnees et des flux multimedia observes ces dernieres annees n'a pas empeche la telephonie et la visiophonie d'etre le principal media de communication pour les particuliers, aussi bien en matiere de communication interne qu'externe.

Ce projet de fin d'etude s'inscrit dans le cadre des projets de l'equipe MultiMedia de l'entreprise TELNET et comme une extension du projet 'cadre photo numerique' [1] deja realise au sein de la meme equipe. En fait, ce dernier se presente sous forme d'un systeme embarque integrant plusieurs fonctionnalites multimedia telles que l'afficheur des photos JPEG, lecteur MP3 et aussi editeur des documents en format PDF.

Ainsi, on desire implementer sur le projet existant l'aspect de communication par voix et video sur le reseau IP afin de s'orienter vers un produit commercial 'l'interphone video IP' et propre a TELNET, qui est une societe de sous-traitance.

Dans ce cadre, ce projet actuel a pour but d'etudier et implementer une solution embarquee de visiophonie destinee pour le grand public et permettant la communication audiovisuelle via le reseau IP entre clients et avec tout equipement compatible Voix sur IP connue sous l'abreviation VoIP pour 'Voice Over IP', comme les visiophones et les Softphones sur PC.

Cette solution de visiophonie embarquee repose sur la technologie VoIP, parmi ses applications on trouve la voix et la video sur IP ou plus connue sous l'appellation 'V2IP' ou 'VVoIP'. Ce procede vise essentiellement une meilleure fiabilite et qualite de communication ainsi qu'une reduction des coûts de communication et l'elimination des obligations de deplacement ou l'elargissement de la zone de couverture.

Suivant cette technologie, le flux multimedia doit pouvoir etre echange entre les utilisateurs sur un reseau local ou etendu. Ces echanges font appels a des technologies evoluees telles que 'le streaming' qui est une technique de transfert des donnees audio et video suivant des protocoles et sous forme d'un flux regulier et continu autorisant sa lecture simultanee a sa reception.

Cependant, ce projet se situe dans ce domaine et vise a traiter en temps reel les flux multimedia en volume toujours croissant d'informations et se base sur le processeur DAVINCI DM355 de chez Texas Instruments, qui est dedie aux applications multimedia avec des hautes performances et un coût faible par rapport a ce qu'existait auparavant.

Ce rapport est structure en trois parties.

La premiere presente d'abord l'organisme d'accueil puis le concept general des systemes embarques, de la technologie de la voix et video sur IP, connue sous l'abreviation de V2IP, ainsi que le principe du streaming, pour aborder par suite une vue d'ensemble du projet 'Interphone video IP' en precisant ses fonctionnalites qui sont axees principalement autour de la communication bidirectionnelle par voix et video sur le reseau IP. Ensuite, on precisera les difficultes a ne pas negliger et les choix a faire pour surpasser les contraintes de temps, de ressources et de fiabilite des communications.

La deuxieme partie sera consacree a la presentation de la technologie voix et video sur IP ou V2IP, ses applications, ses standards et la technique de streaming garantissant l'echange de ces flux multimedia. On s'appuiera de meme sur les criteres de choix des outils materiel et logiciel pour l'implementation de la communication audiovisuelle via IP.

Finalement, dans la 3eme et derniere partie, on detaillera les elements de l'environnement de travail qui repose essentiellement sur le processeur Davinci DM355. On abordera egalement les etapes de realisation et de test de la solution de visiophonie proposee de d'implantation de streaming jusqu'a l'etablissement des sessions de communication audiovisuelle via le reseau IP.

Chapitre1:

Cadre, fonctionnalites et contraintes d'implementation de l'interphone video IP

Introduction

Dans ce chapitre, nous presenterons dans une premiere partie la place de l'Unite Multimedia dans l'entreprise TELNET dans laquelle l'interphone video IP a ete developpe. Ensuite, dans une deuxieme partie, nous donnerons quelques elements relatifs aux domaines de la voix et video sur IP ainsi que celui des systemes embarques afin de comprendre le cadre du projet. Nous detaillerons ensuite non seulement les fonctionnalites visees derriere l'implementation de ce projet, mais aussi les contraintes d'implementation relevees telles que synchronisation audio/video, compromis Debit/qualite, temps de reponse, pour en deduire les choix a faire en consequence.

Presentation entreprise TELNET

TELNET ou TELecom NETwork engineering, qui a ete creee en 1994, est une societe d'ingenierie produit et de conseil dans l'innovation et les hautes technologies. Elle œuvre egalement dans les secteurs des Telecoms & Multimedia, Transport & Automotive, Defense & Avionique, Securite & Carte a Puce, Electronique & Industrie et Ingenierie Mecanique.

TELNET est certifiee ISO 9001 version 2000 dans la conception et le developpement de logiciels. En Août 2005 elle a mis en place la norme de qualite logicielle CMMI.

Effectif

TELNET Dispose d'une equipe technique composee de plus de 450 consultants, ingenieurs et chefs de projets provenant de differentes formations: ecoles d'ingenieurs Americaines, grandes ecoles Europeennes et ecoles d'ingenieurs Tunisiennes. Ses ingenieurs sont specialises en technologies de l'information, en telecommunication, en electronique et en mecanique. [1]

Place de la Voix et video sur IP dans l'Unite Multimedia

L'unite Multimedia de l'entreprise TELNET œuvre principalement dans les secteurs de communication via Internet, ou generalement par voie IP, de traitement d'image, de la video et de l'audio. Cette unite propose des solutions embarquees et travaille sur l'integration des nouvelles technologies de la voix et video sur IP comme la video a la demande, le streaming en HD et la television numerique sur des processeurs et des microcontrôleurs specialises.

Dans le but d'etendre ses domaines d'activite et de penetrer de plus le secteur grand public, l'equipe Multimedia cherche a mettre au point un nouveau produit 'Interphone video IP', d'une part destine pour etre utilise par les particuliers par exemple dans des immeubles, et d'autre part, base sur l'existant projet 'cadre photo numerique'. Ce dernier est une solution embarquee sur le processeur Davinci de chez Texas Instruments, et possedant ces fonctionnalites:

  • affichage et defilement des images en format JPEG depuis une carte memoire
  • lecteur de musique en format MP3
  • reglage de reveil
  • menu pour configuration des parametres
  • interfaçage avec une telecommande par infrarouge

Ainsi, nous sommes amenes a integrer dans ce cadre photo numerique la technologie de communication voix et video sur le reseau IP et le streaming qui est la base des echanges multimedias.

Les systemes embarques

Puisque l'interphone video IP se presente comme une application de voix et video sur IP embarquee, nous detaillons tout d'abord le principe d'un systeme embarque et puis nous passerons a une vue d'ensemble de la technologie de la voix et video sur IP ou V2IP.

Un systeme embarque est un systeme electronique et informatique autonome dedie a une tâche precise avec des contraintes de temps, de memoire reservee et de consommation energetique.

En general un systeme embarque se compose de trois couches, qui sont presentees sur la figure 2:

  • Application
  • Systeme d'exploitation ou OS
  • Materiel

Le systeme d'exploitation est une couche logicielle sur laquelle on va placer les applications lancees par l'utilisateur (couche 2). De plus, cet OS comprend toutes les librairies necessaires pour le developpement, des drivers pour gerer les peripheriques.

Le noyau se charge de contrôle des acces des I/O, de la gestion des processus et de la memoire et de manipuler la distribution des signaux.

Ainsi, dans ce projet, l'application se presente sous forme d'un interphone video qui permet une communication V2IP entre 2 clients point a point avec tous les librairies et les modules necessaires pour l'etablissement des sessions et le streaming.

Concernant le systeme d'exploitation, on a utilise Linux dans sa distribution professionnelle 'MONTA VISTA Pro version 5'. Ce systeme d'exploitation et l'application de l'interphone sont implementes sur la plateforme d'evaluation EVM DM355 dont le cœur est un ARM9.

La voix et video sur IP: V2IP

La technique de voix/video sur IP, connue sous l'abreviation V2IP ou VVoIP, n'est qu'une application particuliere de la VoIP (Voice Over IP) ou voix sur IP.

Cette derniere concerne le cœur du systeme de telephonie sur IP qui comprend tous les elements assurant le transport de la voix et la video sur un reseau Ethernet ainsi que les autocommutateurs IP, les passerelles de communication, les reseaux operateurs, communication intersites et les protocoles de transport et de signalisation. [2]

On utilise la V2IP dans le but de beneficier de l'avantage de la telephonie sur IP 'ToIP' ou meme, precisement dans notre cas, de la visiophonie sur IP dans laquelle les usagers peuvent se voir dans leur communication telephonique.

Pour etre precis, dans la V2IP, le signal numerique obtenu par numerisation de la voix et de la video, issue generalement d'un microphone et une camera, est decoupe en paquets qui seront transmis sur un reseau IP vers une application qui se chargera de la transformation inverse, c'est-a-dire convertir les paquets en voix et images.

Dans le cas de ce projet, on vise a mettre en relief une application de telephonie sur IP par la voix et la video. Toutes les fonctions de capture des donnees, codage, diffusion sur le reseau, decodage et affichage sont implementees sur un interphone video IP qui comporte des peripheriques comme le microphone, la camera, l'ecran LCD et les hauts parleurs.

Le streaming: la base de la visiophonie

Une des specificites de notre projet est que l'on a developpe l'application de streaming bidirectionnel comme extension du projet cadre photo numerique sur la carte d'evaluation TMS320DM355.

Par definition, le streaming ou la lecture en continu est un principe utilise pour l'envoi du contenu multimedia 'en direct' ou reellement en leger differe. Grâce a ce mecanisme, on peut lire le flux audiovisuel a mesure qu'il est diffuse. Il s'oppose ainsi a la diffusion par telechargement qui necessite de recuperer l'ensemble des donnees envoyees avant de pouvoir l'ecouter ou le visualiser.

Ainsi, le client dans tout cela, va recuperer la partie diffusee du contenu qu'il place dans une memoire tampon ou buffer. Lorsqu'il y a suffisamment de donnees dans cette memoire pour permettre de lire le flux multimedia arrive, et cela meme en cas de petites ralentissements a cause du reseau, la lecture demarre.

En arriere plan, le telechargement du flux multimedia se poursuit afin d'alimenter sans cesse la memoire tampon avec la suite des paquets. En raison de latences creees par le reseau ou les systemes de codage et decodage effectuees, un delai de 5 a 35 s peut intervenir entre le signal emis par la source et le signal reçu.

Presentation de l'interphone video IP

Vue d'ensemble et etude de l'existant:

Au cours d'une experience precedente, l'equipe Multimedia de Telnet a realise des applications de traitement d'image et du son en employant le processeur DAVINCI DM355 de chez Texas Instruments. En ce qui nous concerne, nous citons l'exemple du projet du cadre photo numerique developpe sur le meme processeur.

Dans ce contexte, ce projet de fin d'etude vise a finaliser le projet existant du cadre photo numerique afin de mettre au point un produit commercial propre a Telnet et qui n'est autre que 'l'Interphone video IP'.

Le precedent projet cadre photo numerique n'avait developpe que des fonctionnalites liees au defilement des images et lecture de la musique depuis une memoire externe et nous ici nous allons rajouter les specificites de communication point a point et de diffusion du flux multimedia sur le reseau IP via la technique de streaming.

Ainsi, notre projet combine a la fois deux marches independants qui sont les cadres photo numerique et celui des visiophones IP.

Ainsi, ce projet consiste a:

  • etudier les systemes de visiophonie mis a la disposition de grand public
  • developper un interphone compatible voix et video sur reseau IP et se basant sur la technique de streaming.

Architecture possible d'interconnexion :

L'interphone video IP propose doit garantir la diffusion de l'audio et du video sur IP en utilisant le principe de streaming. Il doit pouvoir jouer a la fois le serveur ou le client dans les conversations sur un reseau IP.

Comme l'indique la figure 3, il peut etre interconnecte avec tout equipement presentant les caracteristiques de compatibilite Voix et video sur IP tels que

  • les telephones compatibles protocole SIP appeles visiophones,
  • les telephones fonctionnant par la voix sur IP seulement
  • meme les PCs equipes d'un logiciel de telephonie sur IP: 'le softphone'.

Notre systeme doit etre connecte a un serveur autocommutateur Asterisk qui se charge de l'authentification, de l'enregistrement et de la localisation des multiples participants sur le reseau IP.

Fonctionnalites a implementer:

Derriere cette application embarquee, on vise a implanter l'ensemble des fonctionnalites suivantes:

  • Etablissement et signalisation des communications temps reel, audiovisuelles et bidirectionnelles entre clients grâce au protocole SIP.
  • Capture de la video depuis une camera a capteur CMOS
  • Capture de la voix depuis le microphone
  • Streaming en temps reel, sur reseau Ethernet, non seulement du flux video encode au format MPEG4 et mais aussi du flux audio encode en G711
  • Synchronisation audio/video
  • Reception et decodage du flux multimedia
  • Affichage sur un ecran LCD

A cote de ces fonctions, et puisque l'interphone video IP renferme l'aspect du cadre photo numerique, on ajoute bien evidemment les services offerts par ce dernier et qui sont:

  • Defilement automatique ou manuel des photos numeriques au format JPEG
  • Reglage reveil
  • Un lecteur de musique MP3
  • Visualisation des documents PDF
  • La lecture depuis les memoires externes (SD, Flash disques)

Contraintes d'implementation

La difficulte de ce projet reside dans les solutions a apporter aux 3 contraintes suivantes :

  • synchronisation entre l'audio et la video
  • le compromis entre debit et qualite
  • le temps de reponse

Synchronisation audio/video

La synchronisation entre l'audio et la video est l'axe de tout equipement fonctionnant suivant la technologie de la voix et video sur IP et contenant des systemes d'encodage et de decodage de l'audio et la video comme dans notre cas de l'interphone video IP.

Ainsi, les donnees multimedia vehiculent entre les codeurs et les conteneurs et passent par le reseau Ethernet. Puisque les composantes intrinseques de la voix et la video sont differentes, alors l'approche de synchronisation est differente entre les deux systemes.

En general, les operations sur l'audio ont une tres faible latence et ne sont pas tres gourmandes en memoire et en processeur.

Le traitement de la video pendant prend plus de temps et plus de ressources que celui de l'audio et la latence dans ce cas peut etre mesuree en images par seconde.

On peut palier a ce defaut de synchronisation en tamponnant le signal audio numerise pour ajouter des retards et avoir un flux audio et video sans decalage. Ceci sera le rôle principal de l'outil de streaming employe dans notre projet.

Compromis Debit/qualite

L'adaptation du debit pour une qualite acceptee a la reception est un point crucial pour les applications de streaming et de Voix et video sur IP mettant en œuvre des reseaux a bande passante limitee et susceptibles de perdre des paquets.

En fait, le codage, specialement de la video, avant la diffusion sur le reseau IP, agit sur la resolution spatiale, spectrale ou temporelle pour atteindre le debit cible du canal de transmission.

La suppression des composantes de haute frequence, le sous-echantillonnage temporel d'image ou le changement de format sont des strategies d'adaptation du debit souvent adoptees. En fin de chaîne, la strategie de decodage (restitution) si elle ameliore necessairement la qualite de restitution de la video et la voix, genere neanmoins des degradations au niveau de la qualite aperçue a la reception.

Dans le cadre de ce projet, afin de palier a la degradation de la qualite a la reception, on aura recours a des modifications, de type programmation, des differents modules d'encodage et de decodage et plus precisement le debit ou 'bitrate' en anglais.

Tu aurais pu ici apporter des aspects perceptuels : pour la mesure de qualite audio, image et video. Fais ref a la norme IUT-T (2009) developpee en mastere par Raya TICV pour la video.

Temps de reponse

Dans une conversation audiovisuelle en temps reel, l'utilisateur vise a avoir une reponse aussi rapide que possible de ses actions par exemple faire un appel ou mettre en attente une conversation.

Il est important de remarquer que le delai de transit, qui est le temps que va mettre en moyenne un paquet sur le reseau IP contenant un echantillon pour traverser l'infrastructure entre les deux interlocuteurs, de moins de 150 ms est tolerable pour l'audio.

Concernant la gigue de phase ou 'jitter', qui est le dephasage entre le signal reçu et le signal transmis, doit etre de moins de 20ms.

D'une part, compte tenu de l'aspect embarque de l'interphone video IP, il doit assurer un temps de reponse minime par rapport aux performances de la carte utilisee parmi lesquelles on peut citer :

  • la frequence du processeur
  • l'accelerateur hardware embarque
  • le coprocesseur MJCPpour le MPEG4 et JPEG

D'autre part, si les conditions de circulation sur le reseau se degradent, certains paquets contenant de l'information peuvent arriver trop tard. Ce probleme est en partie compense par l'utilisation des 'buffers' ou memoire tampon mais la gigue peut etre telle que le transmetteur soit oblige de renvoyer au recepteur un paquet alors qu'il n'est pas arrive.

Toutes ces contraintes peuvent etre depassees si les outils de streaming et de communication sont bien choisis en fonction de la plateforme utilisee et bien configures pour gerer d'une façon optimale les ressources materielles et logicielles.

Choix materiel

Choix logiciel

Il nous faut decider, non seulement des protocoles de signalisation et de donnees a utiliser dans l'implementation de l'interphone video, mais aussi des codecs pour la voix et la video.

Conclusion

Dans ce chapitre, on a essaye de mettre le projet dans son cadre. On a commence par presenter l'organisme d'accueil, ensuite on a donne une vue globale sur les systemes embarques et la technologie de V2IP de meme sur le streaming audio et video et on a continue par aborder l'architecture proposee et les fonctionnalites souhaitees derriere l'implementation de l'interphone video IP. Puis, on s'est interesse aux problemes et les contraintes qui peuvent se presenter pour tout systeme embarque de visiophonie.

On a fini ce chapitre par preciser les specifications materielles et logicielles employees dans la realisation de ce projet.

On passera, par la suite, au deuxieme chapitre, qui portera, dans une premiere partie sur la presentation de la technique de la VVoIP et ses standards utilises dans le cadre de l'interphone IP. Dans une 2eme partie, on va decrire les criteres de choix technologiques pour les protocoles, les codecs audio et video et l'outil de streaming employe.

Enfin, dans la derniere partie du chapitre, on presentera les cas d'utilisation de l'interphone video IP ainsi que les descriptions des diagrammes presentant les scenarios possiblestels que l'envoi, la reception, l'enregistrement et la communication RTP.

CHAPITRE 2: Specificites techniques de l'interphone:

Streaming, protocoles et diagrammes d'utilisation

Introduction

Dans ce chapitre, on va s'interesser d'abord aux standards de la technologie VVoIP employes dans l'implementation de l'interphone video IP tout en precisant nos criteres de choix sur les protocoles RTP, UDP et SIP ainsi que les codecs G711 et MPEG-4.

Puis, on passera a la description du fonctionnement du streaming et les atouts de l'outil Gstreamer pour ce projet.

La fin de ce chapitre portera sur la conception de l'interphone video IP. Pour cela, on elaborera les diagrammes des cas d'utilisation et pour chaque scenario possible: envoi, reception, communication point a point et enregistrement.

La technologie V2IPet choix de ses standards

Principe de la V2IP

La figure 4 ci-dessous presente en clair les differents elements de base intervenant dans une application de voix et video sur IP comme dans notre cas de l'interphone video IP:

On remarque que le principe de la V2IP peut etre resume dans les etapes suivantes:

  • Le signal vocal et video est capte depuis des equipements analogiques audio et video comme le microphone et la camera.
  • Ce signal ainsi numerise est encode au moyen des codecs et selon des algorithmes de compression bien definis
  • Le signal encode est fragmente en des paquets, selon le protocole de transport utilise, afin d'etre transmis sur le reseau local ou distant.
  • De l'autre bout, un client compatible V2IP se charge dans l'ordre de: depaquetage du flux multimedia UDP et RTP, decodage, conversion numerique / analogique et l'affichage sur l'ecran LCD.

Avantages de la V2IPdans la visiophonie

Avec un reseau base sur l'IP, la V2IP offre de nombreuses possibilites aux utilisateurs et operateurs. Ainsi, l'interphone video IP offre des avantages qui sont les suivants:

Reduction des coûts

En utilisant la technologie de la V2IP, par exemple via l'interphone video IP, a la place du reseau RTC 'Reseau Telephonique Commute', l'utilisateur peut reduire les coûts de communication telephonique en particulier les communications intersites ou internationales. De maniere plus simple, la communication entre utilisateurs V2IP pourrait reduire leurs coûts de communication entre 60%et 70%.

Facilite de l'utilisation

L'utilisation ne necessite aucun branchement telephonique separe necessaire puisque dans une application V2IP on connecte seulement le materiel directement au port reseau standard qui est le RJ45 dans le cas de l'interphone video IP.

De plus, contrairement a un telephone classique, le materiel compatible voix et video sur IP peut rester avec son utilisateur et seulement on a besoin d'une connexion reseau donc plus de mobilite.

Deploiement des fonctions de telephonie avancees

La V2IP integre a part une gestion de la voix et de la video, des applications et des services touchant le domaine du Triple-Play(voix, donnees et video) commeVoice mail, click to dial et la messagerie instantanee.

Standards de la V2IP: protocoles et codecs

Dans une communication par Voix et Video sur IP, deux etapes importantes interviennent:

  • une premiere etape de negociation et etablissement de la conversation audiovisuelle
  • une deuxieme etape de transport du flux multimedia et echange de datagrammes presentant les donnees sur le reseau Ethernet, tels que la voix et la video.

Dans notre cas actuel, cette communication se fait en temps reel et de pair a pair (interphone -interphone). Les protocoles correspondant a ces deux etapes sont en general designes par les termes'protocoles de signalisation' d'une part, et 'protocoles de donnees' ou 'protocoles temps reel' d'autre part.

Dans notre etude, on va s'interesser aux protocoles de signalisation et de transport utilises dans l'implementation de l'interphone video IP et on abordera de meme les atouts et les criteres de choix pour les protocoles SIP, UDP et RTP.

Le protocole de signalisation SIP: presentation et criteres de choix

Principe du protocole SIP

Le protocole SIP, 'Session Initiation Protocol', est un protocole de signalisation point a point appartenant a la couche application du modele OSI comme indique dans la figure ci-dessous.

Il utilise par defaut le port de communication 5060. Son rôle principal est d'ouvrir, modifier et terminer des sessions de communication pour echanger du flux entre des utilisateurs. L'ouverture de ces sessions permet entre autres de transmettre le flux multimedia et sa diffusion sur le reseau IP au moyen d'un outil de streaming.

Fonctionnement de SIP

Le protocole SIP intervient durant les differentes phases de l'appel. En effet, il se charge de:

  • Authentification des utilisateurs
  • La localisation des multiples participants et terminaux
  • L'analyse du profil et des ressources du destinataire
  • La negociation des types de media echanges (voix, video et donnees) et des parametres de communication
  • La disponibilite du correspondant c'est-a-dire il determine si le poste appele souhaite communiquer et autoriser l'appelant a le contacter
  • L'etablissement et le suivi de l'appel: il avertit les parties appele et appelant de la demande d'ouverture de session, gestion du transfert et de fermeture de la session

La mise en place de SIP repose sur 3 elements:

  • User Agent (UA): est un element final de l'architecture SIP, constitue d'un User Agent Client (UAC) et d'un Agent Server (UAS): telephones SIP, softphones, PDA, passerelles SIP, interphone video IP
  • Registrar Server: serveur gerant les requetes envoyees par les Users Agents pour signaler leur emplacement courant sur le reseau. Ces requetes contiennent une adresse IP et le port de communication qui seront stockes dans une base de donnees.
  • Proxy: intermediaire entre deux Users Agents qui ne savent pas leurs adresses IP.

Les protocoles de donnees UDP et RTP

Le protocole UDP

Le protocole UDP, ou 'User Datagram Protocol', est un protocole de la couche transport, en mode non connecte, permettant un debit optimal mais ' non fiable '.

En fait, UDP n'inspecte pas les pertes des paquets a la reception, et ne garantit pas leur arrivee dans l'ordre. Si une application a besoin de ces garanties, elle doit faire appel au protocole RTP (Real-Time Transport Protocol), ou bien tout simplement utiliser TCP.

Puisque UDP est generalement utilise par des applications de diffusion multimedia (audio et video) pour lesquelles le temps requis par TCP pour gerer les retransmissions et l'ordonnancement des paquets n'est pas disponible, on a opte pour ce protocole de transport tout en le reliant avec le protocole RTP.

Le protocole RTP

RTP (Real-Time Transport Protocol), est un protocole base sur IP fournissant un support pour le transport des donnees en temps reel entre le client recevant le flux et un serveur de streaming. Les services fournis par RTP consistent dans la reconstruction temporelle, la detection de pertes, la securite et l'identification du contenu.

De plus, RTP fournit des services de bout en bout pour des applications qui necessitent un temps reel comme l'audio et la video interactive qui est le cas de l'interphone video IP.

Il necessite le support des couches les plus basses qui ont le contrôle sur les ressources materielles et logicielles comme les routeurs. Il tourne typiquement au-dessus d'udp qui permet le multiplexage et le checksum.

Il faut souligner que le RTP est unidirectionnel donc il est economique au niveau des ressources reseaux.

Les codecs audio et video: presentation et criteres de choix

Choix du codec de parole G.711

Dans cette partie, on va s'appuyer dans notre etude, pour le choix du codec audio approprie, sur la comparaison entre les deux codecs de parole les plus utilises dans le domaine de la VoIP et qui sont le G.711 et le G.729.

Presentation de G.711

Lecodec de parole G.711se classe comme une norme de compression audio de l'UIT-T le plus utilisee dans les applications de voix sur IP.

La norme a ete liberee pour une utilisation en 1972 et la derniere revision date de l'an 2000.Son nom officiel est la modulation par impulsions codees (PCM).

Ses caracteristiques sont les suivantes:

  • Frequence d'echantillonnage: 8000Hzpour une bande passante de parole 300 et 3400Hz
  • Bande passante: 64 kbit/s
  • Type de codage: MIC (Modulation d'impulsion codee, PCM en anglais)
  • Quantification: presentation de chaque echantillon sur 8 bits

Le principe de G711 repose sur une grille de quantification non lineaire, qui a pour rôle la diminution du rapport signal a bruit 'RSB' de l'erreur de quantification pour les sons de faible amplitude.

Il existe deux versions legerement differentes:

  • µ-law, principalement utilise en Amerique du Nord
  • a-law, en usage dans la plupart des pays hors Amerique du Nord.

Presentation de G.729

La recommandation UIT-TG.729definit G729 comme un codage de la parole a 8 kbit/s par prediction lineaire avec excitation par sequences codees astructurealgebriqueconjuguee [].

Le codec G.729 fonctionne a un debit de 8 kbit / s, mais il ya des extensions, qui offrent des taux de 6,4 kbit/s et de 11,8 kbit/s pour une mauvaise et meilleure qualite de la parole, respectivement.

Choix de G711 pour le cas de l'interphone video IP

Le choix du codec de parole est un compromis entre la capacite de l'infrastructure du reseau employe en ce qui concerne la bande passante et la qualite de service souhaitee.

On va s'appuyer particulierement dans notre etude sur l'appreciation du meilleur codec de parole selon le score MOS, Mean Operational Score. Le tableau suivant releve une comparaison au niveau du score MOS et la bande passante entre les 2 codecs G711 et G729.

Choix du codec video MPEG-4

Presentation de la norme MPEG4

La norme MPEG-4 (ISO/CEI 14496) est une norme de codage audiovisuel designee par le Moving Picture Experts Group, MPEG, comite developpant aussi les normes MPEG1 et MPEG2.

D'abord, la norme MPEG-4 a ete conçue pour gerer le contenu de scenes comprenant un ou plusieurs objets audio et video. Contrairement a la norme MPEG-2 qui concerne simplement des usages lies a la television numerique, les usages de MPEG-4 joignent toutes les nouvelles applications multimedias comme le telechargement et le streaming sur Internet, la video mobile, la radio IP, les jeux video et la television.

Criteres de choix pour le mpeg-4

L'interphone video IP se base sur les performances de la plateforme utilisee de chez Texas Instruments: TMS320DM355. Cette carte d'evaluation embarque un coprocesseur MJCP, pour MPEG-4-JPEG Co-Processor, qui offre non seulement une acceleration materielle pour la video MPEG 4 et pour les images JPEG, mais aussi des performances equivalentes a un DSP fonctionnant a 400 MHz.

Puisque ce coprocesseur realise une acceleration d'encodage et de decodage de la video avec le codec MPEG-4 SD a 30 images par seconde, notre choix a porte sur l'utilisation de ce type de codec pour l'encodage depuis la camera et le decodage juste avant l'affichage sur l'ecran.

Le Streaming: base de l'interphone video IP

Principe et fonctionnement

Le streaming est defini comme un procede de transfert de donnees sous forme d'un flux regulier et continu ou en anglais 'Stream', d'où l'appellation streaming. Il permet ainsi de diffuser des contenus multimedia, en temps reel et a la demande, et ceci sans solliciter les ressources materielles de stockage de l'utilisateur comme son disque dur.

Le mecanisme de streaming peut etre simplement presente par ces etapes:

  • La source des donnees envoie le flux video ou audio, qui peut etre capte depuis des instruments analogiques ou simplement un fichier video ou audio, par paquets de donnees qui seront traitees au fur et a mesure de leurs arrivees.
  • l'envoi du flux necessite un protocole de transport comme le RTP qui manipule l'UDP
  • Les paquets n'arrivent pas constamment dans le bon rangement a cause des fluctuations du reseau. D'où, on utilise une memoire tampon ou buffer pour rassembler les paquets dans le bon ordre. Cette memoire tampon ou buffer est cree par le lecteur media de l'ordinateur de l'utilisateur.
  • Apres un certain temps minime, une fois que le buffer de reception dispose d'assez d'informations, le decodage du flux multimedia se declenche et puis l'element d'affichage ou le 'player' dans le cas courant permet d'afficher la video ou l'audio.

L'outil de streaming: GSTREAMER

Presentation de Gstreamer

Gstreamer est un 'Framework' ou un canevas d'outils, c'est-a-dire un ensemble de bibliotheques et outils, dedie a la creation d'applications de manipulation de flux multimedia. Ce kit de composants logiciels, Gstreamer, permet d'ecrire n'importe quelle application ayant besoin de manipuler des flux multimedia. Comme la lecture des fichiers audio ou video, encodage, decodage, l'enregistrement dans des fichiers, diffusion sur UDP du media (audio, video) ...

Toutes les manipulations se basent sur le concept d''un pipeline' qui se presente sous forme d'une ligne de commande où la sortie d'une fonction est reliee a l'entree de l'autre et dans lequel le media passe, selon une direction bien definie, de l'entree vers la sortie.

La conception des pipelines facilite l'implementation de n'importe quel type de transmission en continu d'une application multimedia.

De plus, GStreamer fournit une couche d'abstraction afin de manipuler tout type de format normalement pour lequel il existe un plugin integre dans les bibliotheques de Gstreamer. Ainsi, les developpeurs n'ont pas besoin de s'inquieter de la mise en œuvre des decodeurs, des melangeurs, de synchronisation, ni des codecs, ils peuvent se concentrer uniquement sur les elements a joindre dans un seul pipeline.

Gstreamer est compose:

  • d'une structure logicielle axee sur un cœur (Gstreamer Core) et de nombreux plugins (plus de 150 pour la version 0.10) dont les principaux sont 'gst-plugins-good', 'gst-plugins-bad' et 'gst-plugins-ugly'.
  • d'API pour le developpement des elements de Gstreamer, tels que les codecs les multiplexeurs, avecle support de nombreux langages.
  • d'outilsde tests et d'execution dont la plus importante est 'gst-launch', de documentation (gst-inspect).

Fonctionnement de GStreamer

Afin d'expliquer le plus simplement le fonctionnement de Gstreamer, la figure 9 [5] presente un exemple de pipeline ainsi que son schema bloc. En effet, ce pipeline permet la lecture d'un fichier TS, ou Transport Stream, nomme 'video.ts'. Par la suite, on ajoute l'element 'Typefind' qui detectera le type de media transitant. La sortie de ce dernier est reliee directement a un demultiplexeur 'mpeg2ts' qui se chargera de la decomposition en 2 flux audio et video qui seront traites chacun a part.

D'une part, le flux video est mis dans une file d'attente ou queue pour etre ensuite decode et affiche sur le pilote d'affichage video par defaut.

Image:gstreamer_example_pipeline.jpgD'autre part, en ce qui concerne l'audio, on l'affecte a une file d'attente, puis on le decode et avant de l'envoyer vers le pilote de la carte son 'ALSA', on a eu recours a regler le volume.

Criteres de choix de Gstreamer pour l'interphone video IP

Nous avons opte pour l'utilisation de l'outil de streaming Gstreamer pour plusieurs raisons. Parmi lesquelles, on cite:

  • Grâce a ses differentes implementations sous plusieurs langages de programmation, les developpeurs peuvent desormais ajouter des nouveaux plugins et greffons pour integrer des elements de traitement de l'audio et la video comme les codecs et les filtres.
  • Il assure a travers les pipelines la synchronisation entre l'audio et la video
  • Comme il supporte les protocoles SIP et H323 et le protocole RTP, il peut etre une solution de streaming audio et video en temps reel.
  • Gstreamer est le 1er Framework cross-compile et adapte aux processeurs integrant des cœurs de type ARM9. En fait, le moteur de codecs ou 'Codec Engine' present sur la carte comprend divers modules de decodeurs audio et video qui sont ensuite adaptes aux composants des pipelines de Gstreamer pour creer des differentes applications audiovisuelles sur des cartes d'evaluation de chez Texas Instruments comme la DM355.
  • L'existence du plugin 'Gst-ti-dmai' qui a ete developpe specialement pour les plateformes TI pour s'interfacer avec le DMAI ou 'Davinci Multimedia Application Interface' dans le but d'implementer une application embarquee et portable sur des processeurs Davinci. Ceci constitue le benefice le plus important pour l'implementation de l'application de streaming pour l'interphone video IP sur la carte d'evaluation TMS320DM355.

Conception de l'interphone video IP: les diagrammes d'utilisation

Les cas d'utilisation de l'interphone video IP

L'interphone video IP presente une multitude de fonctionnalites comme il integre a la fois le systeme de cadre photo numerique et la communication audiovisuelle point a point sur IP.

En effet, il permet de:

  • Faire un appel video: cette fonction permet a l'utilisateur de transmettre un appel video sur reseau IP apres avoir composer le numero du correspondant.
  • Terminer un appel video: elle permet de raccrocher et mettre fin a une communication audiovisuelle.
  • Accepter un appel video: l'utilisateur peut a travers cette fonction accepter une invitation de communication par voix et video.
  • Defiler les images en mode diaporama: Permet de visualiser en boucle une serie d'images a condition que la carte memoire soit presente. D'où, la relation d'inclusion doit etre utilisee pour mettre en relief le fait que le defilement des images ne peut se faire que lorsque la carte memoire existe.
  • Defiler les images en mode manuel: dans ce cas d'utilisation, l'utilisateur est amene a defiler les images manuellement via la commande infrarouge ou le clavier de l'interphone video IP. Cette fonction fait egalement appel a la verification de la presence de la carte memoire.
  • Ecouter la musique: elle permet de lire la musique et faire des pauses lors de la lecture. La condition d'enclenchement est la presence de la carte memoire qui contient les pistes audio en format MP3.
  • Visualiser des documents PDF: la verification de la carte memoire doit etre faite avant tout.
  • Configurer les parametres du systeme: Cette fonction permet a l'utilisateur de configurer l'heure et la date, le reveil, la langue des menus, le delai de defilement et le type de transition et defilement entre les images
  • Utiliser le reveil: l'interphone video IP permet l'utilisation d'un reveil configurable.

D'une façon generale, le diagramme de cas d'utilisation sert a simuler les scenarios d'interactions fonctionnelles dans lesquels les acteurs utilisent le systeme a etudier. Ce diagramme vise donc a identifier les utilisateurs potentiels du systeme et a mettre en evidence touts leurs besoins sans qu'il presente des solutions au niveau de l'implementation [4].

Les elements de base d'un diagramme des cas d'utilisations sont :

  • Les acteurs : un acteur est toute entite externe qui interagit avec le systeme.
  • Il peut etre un operateur ou un autre systeme. Dans notre cas l'operateur est le seul acteur.
  • Use case : ensemble d'actions qui decrivent le but de systeme. Ces actions sont realisees par le systeme, en reponse a une action de l'acteur.
  • Les relations entre les differents cas d'utilisations

Dans le diagramme de cas precedent, on a fait recours a deux relations et qui sont:

  • La relation est une relation utilisee entre deux cas d'utilisation pour signaler le fait que la realisation d'un cas d'utilisation necessite la realisation de la fonction de l'autre. Dans notre cas de diagramme, la realisation des fonctions de defilement des images, de lecture des pistes audio et de visualisation des documents PDF passe par l'execution de la fonction de verification de la presence de la carte memoire contenant normalement le media necessaire: des fichiers MP3, des images JPEG et des documents PDF.
  • La relation est une relation qui reclame la validation de la condition presentee entre les deux cas d'utilisation. Dans notre cas de figure, la fonction de verification de la carte memoire ne fait recours au balayage de cette carte que si la condition de presence est validee.

Schema de principe de l'interphone video

En ce qui concerne notre projet, on va implementer les nouvelles fonctionnalites pour la visiophonie sur le projet existant du cadre photo numerique.

Donc le schema de principe de la figure 10 s'interesse seulement aux aspects de la communication audiovisuelle point a point via le protocole SIP ainsi que l'aspect de diffusion du flux multimedia sur le reseau IP selon technique de streaming.

A titre de remarque, la diffusion point a point de la voix et la video sur le reseau IP n'est realisee que si les 2 clients sont authentifies sur le serveur SIP et la communication par SIP est etablie.

Les diagrammes des scenariosde l'interphone video IP

Scenario de l'envoi

Ce scenario permet de capturer un flux video ou audio a partir des peripheriques d'entree comme le microphone ou la camera et de l'envoyer vers une machine distante.

Dans ce cas, les lignes de vie seront presentees par:

  • Module 'Capture'
  • Module 'encodage'
  • Module 'streaming-envoi'
  • Machine 'receptrice'

On presente le scenario de l'envoi du flux multimedia par le diagramme de sequence de la figure 11:

Le diagramme de sequence de la figure 10 decrit l'interaction entre les differents elements de streaming lors de l'envoi de flux multimedia. En effet, ce scenario commence par la capture des donnees de voix et de la video a partir des entrees analogiques. Puis, l'element d'encodage fait le chargement des donnees et l'appel au codeur approprie. Si le module de l'envoi du flux multimedia est active, ce dernier diffuse le flux sur UDP venant de l'encodeur vers une machine distante apres encapsulation RTP. Il faut remarquer que la diffusion de flux ne depend pas de l'etat de la machine receptrice distante puisque meme si cette derniere n'est pas a l'ecoute du canal de reception, l'envoi du flux est toujours realise.

Scenario de reception

Ce scenario decrit la phase de reception du flux diffuse depuis une machine emettrice distante et d'affichage des donnees decodees.

On utilisera dans ce cas comme les lignes de vie:

  • la machine emettrice
  • Module 'streaming-reception'
  • Module 'decodage'
  • Module 'Affichage'

Le diagramme de sequence de la figure 12 decrit en details le scenario de reception.

Scenario d'enregistrement avec authentification

Ce scenario decrit la 1ere phase pour la communication audiovisuelle point a point qui est l'enregistrement aupres d'un Registrar SIP Server avec les parametres necessaires pour l'authentification de l'utilisateur qui est en general le terminal ou dans notre cas l'interphone video IP.

Depuis le diagramme precedent, on note que la phase d'enregistrement est realisee entre un client et un serveur Registrar. Cet enregistrement est base sur les reponses du serveur Registrar et les requetes SIP dont la principale est le message 'REGISTER'.

Comme remarque, la reponse UNAUTHORIZED du serveur vers le client demande a ce dernier de fournir ses coordonnees d'authentification. D'où la 2eme requete REGISTER est envoyee.

Scenario de communication RTP via serveur

La figure 14 presente le scenario typique d'une communication SIP entre 2 clients dans laquelle les communications video et audio gerees par le protocole RTP passent par le serveur, qui jouera le rôle lui-meme d'un User Agent. En effet, les etapes sont comme suit:

  1. Tout d'abord, le client 1 devrait inviter le client 2 pour un appel, donc il va envoyer une demande INVITE au serveur.
  2. Ce dernier repond le client 1 par un message de 100 Trying qui signifie que cette demande INVITE est en cours de traitement.
  3. Le serveur prend la releve pour delivrer une demande INVITE au 2eme client appele
  4. Le client 2 reçoit la demande INVITE, il commence a sonner puis il traite l'invitation et revoie un message RINGING de sonnerie au serveur
  5. Lorsque le serveur SIP reçoit le message 180 RINGING il le transmet au client1.
  6. Lorsque le client2 decroche pour accepter l'appel audiovisuel, il enverra un message 200 OK pour le serveur.
  7. Puis, ce dernier retransmet le meme message 200 OK a l'appelant.
  8. Ce dernier comprend que son invitation a ete acceptee par l'appele, par la suite il envoie un message ACK au serveur pour une confirmation definitive.
  9. Le serveur assure le client2 que la confirmation est faite par un message ACK
  10. Les deux parties sont amenees a etablir la communication en voix et video. Le flux RTP transite via le serveur. Il ne faut pas oublier que le transfert des donnees est assure par l'outil de streaming et non pas le protocole SIP.
  11. Pour terminer l'appel, par exemple le client1, il envoie une demande BYE au serveur.
  12. Apres reception de BYE, le serveur la transmet au 2eme client.
  13. Quand la demande est reçue, le 2eme client enverra un message 200 OK au serveur.
  14. Apres la reception du message OK depuis le serveur, les deux parties sont pretes pour mettre fin a la communication video IP.

Scenario de communication RTP point a point

Dans ce scenario de communication RTP point a point, Ce qui est ajoute par rapport au scenario precedent c'est que le serveur envoie a chaque terminal un 2eme messageINVITEdans lequel la partie de description des sessions indique les adresses IP des terminaux, dans le but de modifier le chemin effectif des trames RTP.

Conclusion

Durant ce chapitre, on a clarifie les choix technologiques dans l'implementation de l'interphone video IP. Ces choix ont porte principalement, d'une part sur le protocole de signalisation SIP et les protocoles de donnees UDP et RTP qui facilitent une application de visiophonie en temps reel, et d'autre part sur le codec de parole G711 et le codec video MPEG4.

Cette etude s'est basee sur des criteres comme le score MOS et sur les performances hardware presentes sur la plateforme d'evaluation DM355.

On a aussi precise les cas d'utilisation de l'interphone video IP puis on s'est focalise sur les diagrammes des differents scenarios.

Details de l'environnement de test materiel et logiciel

Specificites de l'environnement de test materiel

Vue generale de l'environnement de test

Les outils et les methodes d'interconnexion entre la machine hôte et la carte DM355

Les types de liaisons et echange de donnees:

Dans cette partie, on va essayer de presenter les outils et les methodologies permettant l'interconnexion entre la partie logicielle et la partie materielle.

Puisque le principe de l'implementation de l'interphone video IP de base sur l'embarquement des applications de streaming et de communication SIP sur la DM355, deux liaisons sont mises en œuvre:

  • une liaison serie entre la machine hôte et la carte cible sert pour la configuration de chargeur de demarrage (le boot loader) de la carte cible. Ainsi, la carte peut charger son noyau Linux embarque a partir du serveur TFTP, ou Trivial FTP, et elle contacte le systeme de fichier a partir du serveur NFS (Network File System) de la machine hôte.
  • une liaison Ethernet plus rapide est utilisee une fois le 'boot loader' configure. Ainsi, le boot loader de la carte supporte le telechargement des fichiers par liaison Ethernet. C'est pourquoi, il inclut un client TFTP [11].

Cross compilation

De point de vue architecture de processeur, il existe une grande difference entre la carte a base de processeur Davinci et la machine hôte de processeur Intel.

Cette contrainte ne nous permet pas d'executer des programmes compiles par le compilateur de PC sur la carte.

De plus, vue les limitations des ressources materielles et logicielles de la carte, on ne peut pas compiler directement sur la plateforme.

Dans ce cas, il nous faut donc installer une chaine de compilation croisee ou cross compilateur. En fait, un compilateur croise est un outil qui permet de compiler des programmes de maniere a les faire marcher sur une carte cible dotee d'un processeur dissemblable de celui de l'hôte.

Dans ce projet, nous avons fait recours au cross-compilateur speciale pour des architecture ARM qui est le 'arm_v5t_le-gcc'.

Presentation de la partie materielle

Dans cette partie, on va enumerer les differentes ressources materielles utilisees dans le developpement et test de l'application de l'interphone video IP.

De point de vue materiel, on a utilise pour le test et validation du streaming bidirectionnel et de la communication SIP:

  • 2 modules d'evaluation Davinci TMS320DM355, de chez Texas Instruments a base d'ARM9, 216 Mhz.
  • 2 ordinateurs hôtes equipes du systeme d'exploitation Linux Open source 'Ubuntu'.
  • webcam et lecteur DVD comme sources video.
  • 2 Microphones.
  • 2 TV LCD.
  • Un switcher/hub
  • Commande infrarouge pour la plateforme EVM DM355

Carte d'evaluation TMS320DM355

Presentation

Le module d'evaluation EVM TMS320DM355 (EValuation Module) est une plate-forme de developpement qui permet aux utilisateurs d'evaluer et de developper des applications de type multimedia pour les processeurs DM355 de chez Texas Instruments [].

Ce kit d'evaluation TMS320DM355 est constitue de plusieurs peripheriques destines pour etre programmes et interfaces avec tout materiel de traitement audio et video.

On a choisit d'implementer les solutions de streaming et de communication SIP sur la carte TMS320DM355 qui contient principalement:

  • Un processeur Davinci DM355 base sur le cœur ARM926EJ-S a 216 MHz et contient:

          ARM Subsystem (ARSS): sous-systeme ARM

            Video Processing SubSystem VPSS : sous-systeme de traitement visuel

            Coprocesseur MPEG JEPEG Co-Processor
  • Memoire flash NAND 2 Go
  • Memoire RAM DDR2128 Mo
  • Liaison serie RS232
  • horloge de surveillance 64-bit
  • EEPROM SPI
  • Un circuit master/slave (I2C)
  • Interface USB
  • Interface commande infrarouge
  • Chargeur de demarrage configurable
  • Entree / sortie Audio et video
  • Interface Ethernet pour RJ45
  • Lecteur de carte memoire SD/MMC
  • Codec stereo AIC33
  • 3 UARTs (UART rapide avec RTS et CTS contrôle de flux)
  • Connecteur JTAG
  • Entree d'horloge en cristal ou externe (typiquement 24MHz ou 36MHz)
  • 104 bornes de GPIO (entree-sortie d'usage universel)
  • 4 sorties PWM
  • 4 sorties de RTO (temps reel dehors)
  • Chargeur-amorce de ROM de BRAS de Sur-Morceau (RBL) soit initialise du flash non-et, du MMC/SD, ou de l'UART.
  • Generateurs a horloge flexibles de PLL

Parmi toutes les composantes de la carte d'evaluation EVM DM355, le coprocesseur MJCP nous interesse le mieux.

Nous visons durant l'implementation du streaming via l'outil Gstreamer de profiter de cet accelerateur materiel afin de liberer le processeur ARM pour qu'il puisse se charger d'autres tâches en paralleles comme les processus de traitement de la voix et la commande infrarouge.

C'est pour cela, nous allons aborder une description du MJCP dans la section suivante.

Coprocesseur MJCP

C'est l'element le plus important dans le fonctionnement de l'interphone video IP et en particulier au niveau du traitement de la video MPEG-4.

En fait, le coprocesseur ' MPEG JEPEG Co-Processor ' fournit l'equivalent d'un DSP fonctionnant a 400 MHz. Ce dernier permet l'acceleration de l'encodage et decodage MPEG en 30 images par seconde ainsi que le codage des images JPEG a 50 mega pixels par seconde.

De meme, ce coprocesseur interagit avec le sous-systeme de traitement video VPSS de telle façon que le traitement de la video et l'mage s'executera en materiel.

Depuis la figure XX, il est clair que le coprocesseur MJCP est en relation directe avec le DMA dont le peripherique responsable de la plateforme DM355 est l'EDMA, (Enhanced DMA), pour pouvoir gerer l'acceleration materielle via le VPSS.

Specificites de l'environnement de test logiciel

L'implementation de notre solution embarquee sur la carte DM355 necessite une multitude de solutions logicielles telles que:

  • Linux Monta vista Pro 5 avec noyau linux 2.6 et LSP 'Linux Support Package' a integrer dans le noyau de la carte
  • Le kit de developpement 'Davinci Software Development Kit', DVSDK
  • Bibliotheques Gstreamer 0.10
  • Plugin Texas Instruments pour Gstreamer 'Gst-ti-dmai'
  • Serveur Asterisk
  • Librairies Osip2 et Exosip2

Les drivers ALSA et V4L2

Pour pouvoir mettre en marche le streaming audio et video, il est necessaire de manipuler les drivers de la carte son et du module de capture et affichage de la video. C'est pourquoi nous avons utilise les drivers:

  • ALSA, pour Advanced Linux Sound Architecture, est un composant du noyau Linux, destine a manipuler la carte son. Les objectifs initiaux de ce composant comportent la configuration automatique des cartes son et le support aise de plusieurs cartes son dans le meme systeme.
  • V4L2, pour Video for Linux 2, est une interface de capture de la video disponible dans le noyau Linux et compatible avec plusieurs types de camera et des recepteurs. On va par la suite utiliser le peripherique /dev/video0 pour effectuer la capture video et le peripherique /dev/video2 pour l'affichage.

DVSDK

On a eu l'occasion de cross-compiler et de modifier le code source de ce kit de developpement logiciel pour la video numerique (Digital Video development Kit).

Ce DVSDK nous a permis de developper les applications multimedias et de les porter facilement sur le processeur Davinci.

En effet, ce kit renferme:

  • U-boot: le chargeur d'amorçage pour l'OS
  • Codec Engine: ce Framework fournit un ensemble d'APIs pour les codecs multimedia, connus sous xDM, eXpressDSP Digital Media, sans tenir compte de leurs executions soit sur l'ARM ou le coprocesseur. De plus, le Codec Engine est utilise pour instancier et executer des algorithmes xDAIS (eXpressDSP algorithm interoperability standard).
  • L'interface DMAI: permet le developpement des applications portables et compatibles avec plusieurs OS.
  • Des codecs multimedia: fournit des librairies pour les codecs et des clips video et audio pour le test par exemple du decodage te codage de la video mpeg4.
  • Des demonstrations: pour visualiser et tester les traitements possibles par le processeur Davinci comme le codage et le decodage audio et video.

Plugin TI gstreamer

Gstreamer peut s'interfacer avec le DMAI 'DaVinci Multimedia Application Interface' via des plug-ins ou des greffons, dans notre cas appele 'gst-ti-dmai plug-in', afin d'implementer des applications portables sur des plateformes DaVinci de chez Texas Instruments.

La figure XX pour mieux expliquer le fonctionnement du plugin TI gstreamer.

En effet, il utilise le DMAI pour acceder aux accelerateurs TI hardware puisque le DMAI est une couche qui se trouve au-dessus de systeme d'exploitation (linux) et du CodecEngine afin d'ecrire des applications portables sur les differentes plateformes Davinci avec un minimum de changement.

Librairies osip et eXosip

Afin de pouvoir implementer le protocole SIP comme protocole de signalisation entre les 2 cartes DM355, on a fait recours aux 2 librairies Osip et eXosip dans leur 2eme version.

En fait, la bibliotheque Osip est une pile du protocole SIP sous licence LGPL. C'est le resultat du projet oSIP realise par Aymeric Moizard.

Il faut noter qu'elle est une implementation de 'bas-niveau' du protocole SIP.

Pour mettre en œuvre le protocole SIP plus simplement via des APIs, on a utilise la bibliotheque eXosip, ou eXtended osip, qui est une solution optimale pour l'utilisation d'Osip.

Les etapes de l'implementation de l'interphone video IP

Preparation de l'environnement de test

Puisque l'application de l'interphonie video IP est l'extension du projet du cadre photo numerique, on n'a pas ete amene a preparer la carte cible depuis le debut:

  • Compilation du noyau Linux
  • Mise en œuvre du systeme de fichier par NFS
  • Reglage des variables d'environnement pour U-boot
  • Cross-compilation du DVSDK sur la carte TMS320DM355

Mais, au cours de resolution de certaines contraintes de realisation, nous avons fait face a recompiler le DVSDK et le noyau Linux version 2.6.

Pour plus de details concernant les etapes de preparation de l'environnement de travail, se referer a l'annexe XX.

Implementation du streaming entre 2 PCs

Dans cette partie, on vise a implementer le streaming bidirectionnel via l'outil Gstreamer de la video et l'audio entre PCs.

Pour ce faire, on a eu recours a plusieurs etapes:

  • Installation de Gstreamer depuis les sources
  • Verification des codecs et elements disponibles sur PC
  • Utilisation des pipelines pour envoi et reception de l'audio et la video
  • Tests de l'envoi et la reception

Compilation de Gstreamer sur PC:

Dans cette partie, nous avons eu recours a la compilation de la derniere version de la Framework Gstreamer dans sa version 0.10.25 sur l'OS Ubuntu 8.01 depuis les depôts officiels.

Puisque ce canevas d'outils se base sur des librairies et plugins externes, ces dernieres ont ete telechargees et compilees depuis les sites appropries.

Pour ce faire, nous avons installe les plugins et librairies suivants:

  • gstreamer0.10-plugins-good : Ce paquet renferme les greffons 'good' de Gstreamer, un ensemble de greffons de bonne qualite sous licence LGPL.
  • gstreamer0.10-plugins-bad

Gstreamer Bad Plug-ins est un ensemble de plug-ins qui ne sont pas optimales par rapport au reste des plugins Gstreamer.La qualite n'est pas aussi bonne, et ils manquent a ces plugins que ce soit une bonne revision de code, de la documentation, une serie de tests, ou une large utilisation actuelle.

  • gstreamer0.10-plugins-bad-multiverse

Depuis les depôts multiverse pour les paquets non libres

  • gstreamer0.10-plugins-base

C'est un ensemble de plugins fixes, couvrant un large eventail de types d'elements, qui sont continuellement mis a jour avec les changements de base au cours des developpements de l'outil Gstreamer.

  • gstreamer0.10-plugins-ugly

Un ensemble de plug-ins qui sont de bonne qualite et de fonctionnalite correcte, mais la distribution entre eux pourrait poser des problemes. Le code source de ce plugin 'ugly' peut etre largement connu pour presenter des problemes de brevets.

  • gstreamer0.10-plugins-ugly-multiverse

la version du plugin "ugly" depuis les depôts officiels multiverse maintenus par la communaute.

  • gstreamer0.10-ffmpeg :

Ce plugin GStreamer supporte un grand nombre de compression des formats audio et video formats grâce a l'utilisation de la bibliotheque FFmpeg.Il contient plus que 40 encodeurs pour differents formats comme MPEG, DivX, MPEG4, et plus que 90 decodeurs par exemple pour (AVI, MPEG, OGG, ASF, ...), ainsi que des demultiplexeurs, et des convertisseurs de palette.

La compilation et l'installation des greffons Gstreamer precedents seront clarifies et detailles dans l'annexe 3.

Verification des elements de Gstreamer installes

La commande 'GST-INSPECT' montre la description des plugins GStreamer et des elements qui sont installes sur la machine, sinon une erreur se produit car une application basee sur GStreamer ne peut pas trouver un certain element qui est utilise par exemple pour decoder un fichier MPEG4.

Ainsi, pour verifier et lister les plugins et les differents codecs et elements Gstreamer installes, on utilise la commande 'gst-inspect' sans arguments.

Test du streaming entre 2 PC

Pour ce faire, au moyen des pipelines, on a realise un module d'envoi du flux audio et video et un autre module de reception et d'affichage.

Par manque de documentation sur les regles et la façon d'enchainement des elements de Gstreamer dans un pipeline, on va presenter d'abord les schemas en blocs des modules d'envoi et de reception pour clarifier l'utilisation des elements dans les pipelines et l'acheminement du flux multimedia depuis la source jusqu'a l'affichage.

Ensuite, on precisera les details de chaque element utilise dans ces pipelines.

Les tests ont porte d'une part sur le streaming a partir d'un fichier video ou audio, d'autre part sur la diffusion d'un flux multimedia depuis une camera ou un microphone.

A titre de remarque, on a teste les pipelines d'envoi et de reception premierement en local (localhost) et puis on a realise le streaming entre 2 PCs connectes sur un reseau local.

Streaming de la video:

Depuis un fichier video test

Schema blocs du streaming de la video:

Les pipelines de streaming:

Pour le streaming video

Depuis une webcam, seulement le pipeline d'envoi change puisque la source du flux n'est plus la meme. La source devient l'element de capture depuis le pilote 'Video for linux' version 2, v4l2src:

Pour le streaming Audio:

Streaming en local:

Dans ce cas de figure, on change seulement la propriete 'host' de l'element 'udpsink' d'envoi sur UDP et on affecte l'adresse IP de la machine locale ou simplement localhost comme suit:

Host=192.168.14.46

Description des elements des pipelines:

Gst-launch : la commande cle de Gstreamer qui permet de construire et exploiter un pipeline. On a utilise l'option '-v' ou '--verbose' pour afficher les informations sur l'etat de sortie

V4l2src : element de capture des images depuis l'interface Video for Linux 2

Videotestsrc: source de flux video test

Ffenc_mpeg4: encodeur video de la librairie FFMPEG compatible MPEG-4 part 2

Ffdec_mpeg4: decodeur video de la librairie FFMPEG compatible MPEG4-part2

Rtpmp4vpay: encapsuler le flux video MPEG-4 dans des paquets RTP

Rtpmp4vdepay: extraction de la video MPEG-4 depuis les paquets RTP

Udpsink: envoi des paquets reseaux sur UDP. On a fait recours dans notre cas de streaming aux proprietes 'port' et 'host' pour definir le port et l'adresse IP de destination.

Udpsrc: element pour reception des paquets UDP sur le reseau. On a concatene a cet element les capacites 'caps' du flux video reçu.

Alawenc: encodeur de parole A-law: la version europeenne de G711. Il convertit PCM 16 bits en A-law 8 bits.

Alawdec: Decodeur de parole A-law. Il convertit A-law sur 8 bits en PCM 16 bits.

Volume: element de configuration du volume du flux audio.

Resultats

Implementation du streaming entre 2 cartes DM355

Cross compilation de gst dmai

Le streaming audio et video bidirectionnel, depuis les webcams et les microphones, est realise avec succes en local et entre deux ordinateurs connectes sur le meme reseau local. La qualite aperçue a la reception de la voix et la video est jugee tres bonne.

Test et validation du streaming sur la carte TMS320DM355:

Cross-compilation du plugin TI: 'GST-TI-DMAI'

Cette partie presente la phase la plus interessante dans la realisation du projet puisque elle touche directement le domaine de la microelectronique et de programmation destinee pour l'embarque.

Il est evident que la version de Gstreamer, qu'on a manipulee durant le test precedent du streaming entre 2 PC, ne peut pas etre compatible avec la plateforme DAVINCI utilisee.

Comme il existe un plugin Gstreamer 'Gst-ti-dmai plugin' destine pour etre implemente sur les cartes d'evaluation TI Davinci, nous avons recours a integrer ce greffon sur la carte TMS320DM355 au moyen de la cross-compilation pour manipuler les pipelines de streaming depuis la carte.

En fait, ce paquet contient les composants de base et open-source necessaires pour generer et executer GStreamer sur notre carte d'evaluation DM355, ainsi qu'un plugin qui permet aux elements de Gstreamer de s'interfacer directement avec le DMAI ( Davinci Multimedia Application Interface), et donc le 'Codec Engine' present sur la carte.

La cross-compilation du plugin TI Gstreamer, qui peut etre telecharge depuis les depôts officiels ou le site officiel de TI, sur la carte Davinci DM355 est effectuee a travers des lignes de commande. Les etapes de cross-compilation de Gstreamer sur la DM355 seront detaillees dans l'annexe 4.

Durant l'etape de la cross-compilation du plugin TI Gstreamer, nous sommes amenes a utiliser le cross-compilateur 'arm-v5t-le' present sur la carte et plus precisement integre avec l'OS Monta Vista pro 5. De plus, la compilation de ce plugin sur la carte a fait appel au:

  • DVSDK version 2_00_00_22 present sur la machine hôte
  • paquet 'pkg-config-0.18' qui est un outil d'assistance utilise lors de la compilation des librairies et permettant l'insertion des options de compilation dans les lignes de commande.
  • paquet 'flex-2.5.35': analyseur de fichiers utilises comme entree dans la configuration et la compilation des librairies.

Verification de Gstreamer sur la plateforme Davinci:

Avant de pouvoir manipuler les elements Gstreamer sur la carte d'evaluation, il faut configurer la carte d'evaluation.

Pour ce faire, nous sommes amenes a initialiser les modules appropries du noyau pour la plateforme DM355 dans le but de configurer la memoire pour s'adapter a notre application. En effet, apres l'installation du plugin TI Gstreamer, sous le repertoire /opt/gstreamer_demo/dm355 on trouve le script loadmodules.sh.

Ce dernier est un script executable permettant de charger les modules:

  • 'cmem.ko': pilote de memoire pour allocation physique de la memoire contigüe dans le noyau Linux pour les applications ARM
  • 'dsplinkk.ko': requis pour les applications ARM executables pour communiquer avec le DSP.

Pour mieux eclaircir notre façon pour allouer la memoire RAM, il faut presenter la CMEM, 'Contiguous Memory Allocator'. Cette derniere est une API et une librairie pour gerer les blocs de memoire physique contigüe. Cette memoire est utile pour l'allocation des buffers et des tampons pour les donnees qui seront partages avec l'accelerateur materiel MJCP present sur la plateforme DM355.

Dans notre cas de figure, la memoire RAM disponible est de 128 Mo. On a alloue des blocs de memoires contigües de taille totale 48 Mo qui sera consacree pour les elements de Gstreamer tels que les codeurs et les decodeurs video MPEG-4 et le pilote d'affichage. Le reste de la memoire sera employe pour les applications Linux utilisant le Kernel.

Ainsi, la verification des elements installes sur la carte d'evaluation EVM DM355 peut etre faite a l'aide de la commande 'gst-inspect'.La figure suivante montre le resultat de l'execution de cette commande et devoile un nombre de plugins et de pour les ..................

FIGURE

Ce qui nous s'interesse le plus apres la cross-compilation du plugin TI Gstreamer, c'est les elements TI comportant les encodeurs et les decodeurs TI:

  • TIAudenc1: TI xDM 1.x Audio Encoder
  • TIAuddec1: TI xDM 1.x Audio Decoder
  • TIAuddec: TI xDM 0.9 Audio Decoder
  • TIImgdec: TI xDM 0.9 Image Decoder
  • TIImgdec1: TI xDM 1.0 Image Decoder
  • TIImgenc: TI xDM 0.9 Image Encoder
  • TIImgenc1: TI xDM 1.0 Image Encoder
  • TIViddec2: TI xDM 1.2 Video Decoder
  • TIViddec: TI xDM 0.9 Video Decoder
  • TIVidenc: TI xDM 0.9 Video Encoder
  • TIVidenc1: TI xDM 1.x Video Encoder

Ces differents elements possedent 2 parametres en commun:

'engineName': specifie l'engine utilise (decode ou encode)

'codecName': precise le nom de codec utilise (il doit etre un codec TI)

Mise en œuvre du streaming sur la carte TMS320DM355en local:

Le schema bloc du streaming video entre cartes:

Pour la video:

Audio

Ensuite, on a teste la diffusion du flux audio et video entre les 2 plateformes Davinci. Le seul changement au niveau des pipelines Gstreamer est au niveau de la propriete 'host' de l'element d'envoi sur UDP 'udpsink'. On l'affecte a l'adresse IP de la machine destinataire.

Description des elements de Gstreamer employes :

Les pipelines de streaming audio et video entre les cartes d'evaluation DM355 ont fait appel aux codecs developpes par Texas Instruments et d'autres elements Gstreamer necessaires pour la capture, filtrage et affichage.

  • TIViddec2: decodeur TI du flux video utilisant l'interface XDM 1.2.

Dans le pipeline de reception, on a utilise un decodage de la video mpeg4 a un debit de 20 images par seconde (framerate).

  • TIVidenc1: encodeur TI utilisant l'interface XDM 1.x. Dans notre cas, on a utilise le codec mpeg4 a 20 images par seconde et a un debit de 500 Kbits/s.
  • Dmaiperf: element Gstreamer permettant de capter les performances du pipeline et precisement le charge CPU et le debit utilise.
  • TIDmaiVideoSink: Element TI pour l'affichage et l'envoi du flux decode au pilote V4L2. On a utilise dans ce projet la sortie video composite de la carte DM355 depuis le pilote d'affichage /dev/video2 avec le standard PAL.
  • alsasrc: lecteur depuis la carte son via le pilote ALSA. Dans notre projet, la capture de la voix synthetisee depuis un microphone se fait par blocs de taille 2 Ko de memoire tampon ou buffer de capture audio de duree egale a 180 ms.
  • alsasink: permet l'envoi du flux audio decode en PCM 16bits vers la carte son via le pilote ALSA pour etre ecoute en connectant des hauts parleurs a la sortie audio de la carte d'evaluation DM355.

Resultatsde streaming entre cartes:

Concernant le streaming audio et video unidirectionnel entre les 2 cartes TMS320DM355, la qualite a la reception est bonne et la synchronisation entre la voix et la video est acceptable.

Dans le cas du streaming bidirectionnel entre les 2 plateformes connectees a travers le reseau IP, la video et l'audio presentent une qualite acceptable a la reception mais avec un peu de decalage entre la voix et la video.

Il faut noter que le streaming bidirectionnel demande beaucoup de ressources de memoire et de CPU. Apres des modifications et des corrections au niveau des proprietes des elements Gstreamer, qui seront plus detaillees dans la section .............(difficultes et solutions)

Le streaming bidirectionnel utilise a peu pres 90 % des performances du CPU pour chaque carte.

Realisation de la communication SIP

Apres test et validation du streaming bidirectionnel entre les 2 cartes d'evaluation DM355, malgre la contrainte de la surcharge du CPU, on passe maintenant a la manipulation des APIs des librairies Osip2 et EXosip2 pour l'implementation des sessions de communication par voix et video entre les 2 cartes Davinci.

Installation et configuration du serveur Asterisk

Dans cette partie du projet, on est amene a compiler le serveur Asterisk qui sera le serveur d'enregistrement et d'authentification des clients, sur la machine hôte.

De plus, il n'etait pas facile et trivial de configurer des la premiere tentative, d'une part l'enregistrement des clients ou les 'peers' dans la base de donnees, et d'autre part les echanges des capacites et les messages SIP entre les 2 clients en communication.

Pour cela, nous avons eu recours a modifier les fichiers de configuration du serveur Asterisk pour avoir une communication SIP fiable.

Ces details, ainsi que les etapes de compilation d'Asterisk, seront developpes dans l'annexe 6.

Installation des librairies OSip2 et EXosip2

Une fois le streaming est valide entre les 2 plateformes Davinci, on passe maintenant a l'implementation d'une connexion SIP entre ces 2 clients.

Pour ce faire, nous avons recours aux APIs disponibles depuis les librairies libosip2 et libeXosip2.

Les details de compilation des librairies libosip2 et libeXosip2 feront l'objet de l'annexe 5.

API utilises

Avant d'entamer cette partie descriptive des APIs utilisees, on insiste a signaler que nous visons a etablir des sessions de communications SIP avec echange du flux multimedia point a point sans passer par le serveur ASTERISK.

Ceci est lie a l'outil Gstreamer qui se chargera apres l'etablissement de communication SIP de la diffusion des flux RTP entre les 2 cartes Davinci.

En fait, Gstreamer est un outil de streaming point a point donc ça serait impossible de gerer le flux RTP d'une part entre le premier client et le serveur Asterisk et d'autre part entre le serveur et le deuxieme client.

Ainsi, le scenario de communication SIP audiovisuelle avec echange du flux RTP point a point nous interesse dans ce projet.

Pour mieux representer les APIs utilises lors du test de la communication entre les 2 cartes Davinci, on va les grouper dans le tableau suivant tout en precisant leurs fonctions dans la communication SIP entre les 2 clients.

Fonction souhaitee

API utilise

Initialisation de la bibliotheque eXosip et ecoute des sockets reseaux

eXosip_init

eXosip_listen_addr

Enregistrement avec authentification aupres du serveur Asterisk

eXosip_register_build_initial_register

eXosip_add_authentication_info

eXosip_register_send_register

Invitation pour commencer une communication: INVITE

eXosip_call_send_initial_invite

eXosip_call_send_initial_invite

Envoi d'un message SDP indiquant les coordonnees et capacites du client

osip_message_set_body

osip_message_set_content_type

Envoi d'une reponse 200 OK

eXosip_call_send_answer en precisant le type de message 200

Signal de sonorisation RINGING

eXosip_call_send_answer en precisant 180 comme message

Reponse par un acquittement

eXosip_call_build_ack

eXosip_call_send_ack

Terminer Session SIP : envoi requete BYE

eXosip_call_terminate

Capture et lecture des informations depuis le message SDP reçu

Pour notre cas, on a essaye d'extraire le message SDP ainsi que les ports utilises et l'adresse IP:

eXosip_get_remote_sdp sdp_message_c_addr_get

sdp_message_m_port_get

Verrouillage de la bibliotheque eXosip par semaphore

eXosip_lock

eXosip_unlock

Gerer automatiquement les etats dans la communication SIP et renouvellement automatique des requetes d'invitation et d'enregistrement

eXosip_automatic_action

Pour plus de details sur les fonctions employees dans le tableau, se referer a l'annexe 6.

Resultat de test pour la communication SIP

Pour valider le bon fonctionnement du scenario de la communication SIP entre les 2 clients presentes par les 2 plateformes Davinci, on a utilise le logiciel d'analyse des paquets reseaux 'Wireshark'[].

Pour la phase d'enregistrement, la figure XX represente les differents messages SIP echanges entre le serveur Asterisk, affecte a l'adresse IP '192.168.14.36', et un des clients d'adresse '192.168.14.45'.

La figure suivante presente l'analyse des messages SIP permettant l'etablissement d'une communication SIP entre les clients d'adresses IP '192.168.14.45' et '192.168.14.46'.

Integration du streaming dans les sessions SIP

Cette partie presente le mariage entre l'etape de streaming teste par l'outil Gstreamer et la communication en SIP. Elle a necessite la manipulation des processus en execution pour donner naissance a d'autres processus fils.

En fait, une fois l'invitation est acceptee par l'appele et apres la reception de l'acquittement signifiant que le client destinataire a decroche, la diffusion du flux de la video et de la voix commence en bidirectionnelle et point a point entre les 2 clients. Cette tâche est assuree bien sure par les pipelines d'envoi et de reception, qu'on a deja presentes dans la section XX.

Resultat de l'integration du streaming point a point dans les communications SIP:

Difficultes rencontrees et solutions proposees:

Durant la realisation de ce projet, plusieurs contraintes et problemes de type materiels et logiciels se sont devoiles.

Pour y remedier, on a depense plus de temps a manipuler le code source des librairies et a attendre l'aide des professionnels et developpeurs de Texas Instruments et de l'entreprise ITTIAM [], leader mondial dans le developpement des codecs pour les systemes embarques.

Nous allons presenter dans cette partie simultanement les difficultes rencontrees dans le test et la validation de Gstreamer et de la communication SIP ainsi que les solutions qu'on a proposees.

Probleme et solution du decodeur mpeg4pour TI:

Durant la phase de streaming video entre les 2 cartes et meme sur la meme carte Davinci, le decodeur TI pour la video 'TIViddec2' n'arrive pas a decoder le flux en mpeg4 reçu depuis le reseau IP.

Nous n'avons pas eu la simplicite de resoudre ce probleme meme apres contacter les ingenieurs de chez Texas Instruments et les forums des developpeurs de Gstreamer.

La solution etait de voir de pres les differents elements de Gstreamer et analyser leurs proprietes. Apres plusieurs tentatives cette contrainte de decodage a ete resolue.

En effet, le decodeur mpeg4 de TI ne reçoit pas les bonnes configurations concernant le flux video reçu. Pour remedier a ce probleme, il suffit d'activer l'envoi de la configuration et les capacites d'encodage dans les paquets RTP et ceci est obtenu en modifiant la propriete 'send-config=true' au niveau de l'element d'encapsulation RTP 'rtpmp4vpay'.

Apres l'appreciation de cette solution de la part des developpeurs de TI, nous avons eu l'occasion de la poster sur la page officielle du wiki de l'entreprise Texas Instruments [].

Probleme et solution de surcharge de la CPU de la DM355

Le streaming audio et video entre les plateformes Davinci a revele une surcharge important de la CPU.

En fait, les sources de ce probleme de surcharge de la CPU sont au nombre de deux.

D'une part, seulement le codage et le decodage de l'audio consomment a peu pres 95 % de la CPU puisque il n'existe aucun element TI destine pour le traitement de l'audio sur la DM355 en employant son accelerateur materiel. D'autre part, le traitement de la video prend une grande partie dans les ressources disponibles de la CPU environ 98% pour le codage et le decodage mpeg4.

Pour palier au probleme de l'audio, on a eu recours a deux etapes:

  • Puisque les codecs TI disponibles dans le plugin TI Gstreamer ne contiennent aucun codec de parole destine pour notre plateforme DM355, on a essaye
      d'integrer le codec A-law dans la cross-compilation du plugin 'gst-ti-dmai'.
    • On a pu reconfigurer les parametres de l'element 'alsasrc' de capture via l'interface ALSA depuis la carte son. En fait, apres modification du code source du plugin TI Gstreamer, on a fixe la capture depuis la carte son en PCM 16 bits, echantillonne a 8 KHz et en mono.

    Concernant le traitement de la video mpeg4, il s'aperçoit quel'utilsation intensive de la CPU est liee a:

    • l'element TI pour l'encodage de la video mpeg4 n'est pas configure par defaut de telle façon que l'encodage video utilise l'accelerateur hardware disponible dans le DM355 et emploie des tampons de memoires contigües venant d'une source video delivrant des buffers contigus.
    • Par defaut, l'element d'affichage de GStreamer 'TIDmaiVideoSink' n'est pas en mesure de s'interfacer avec le module 'Framecopy' de l'accelerateur materiel ou DMA de la DM355.
    • Le debit d'encodage pour la vide, par defaut 2Mbits/s, est considere un peu eleve pour l'encodage des images venant du pilote V4L2.

    En vue de palier a ces contraintes, on a eu recours a manipuler certaines proprietes des elements de Gstreamer employes dans les pipelines pour le streaming de la video.

    Les changements sont les suivants:

    • on a configure l'encodeur TIVidenc1 pour utiliser le module 'Framecopy' de l'accelerateur DMA et utiliser le copiage du buffer en amont vers les buffers circulaires (circular buffer). D'où, on a force l'utilisation des blocs de memoire contigüe par activation de la propriete 'contiguousInputFrame' de l'element 'TIVidenc1'. De plus, l'element de capture via le pilote 'v4l2' doit delivrer des buffers contigus en changeant la propriete 'always-copy' a 'false'.
    • on a change le parametre 'accelFrameCopy' a 'true' afin de permettre l'utilisation du module 'framecopy' de l'accelerateur materiel DMA par l'element d'affichage ''TIDmaiVideoSink'
    • Le debit pour l'encodeur mpeg4 est fixe dorenavant a 500 Kbits/s

    Probleme de streaming video entre PC et carte DM355

    La complication vient du fait que le streaming de la video du PC vers la carte d'evaluation EVM DM355 se bloque au niveau du decodage du flux mpeg-4 mais le cas contraire (carte vers PC hôte) est fonctionnel.

    En fait, les 2 codecs, celui de TI Gstreamer pour le mpeg4 et l'autre codec mpeg4 de la librairie FFMPEG presente sur la machine hôte, ne sont pas compatibles.

    Probleme et solution de recuperation des coordonnees des clients

    Dans la partie de la realisation de la communication SIP, on n'a pas pu recuperer l'adresse IP et les ports de communication des clients de la session SIP. Cette contrainte a ete resolue par la configuration du serveur Asterisk de telle maniere que le serveur soit capable d'envoyer une 2eme requete INVITE aux 2 clients juste apres l'acceptation de l'invitation a commencer une session SIP. Cette requete contiendra les messages corrects SDP contenant les coordonnees des clients ainsi que les types de media echanges.

    De point de vue programmation, on est amene a activer la propriete 'canreinvite' du fichier de configuration 'sip.conf' du serveur Asterisk.

    Autre difficultes:

    Durant l'implementation de la solution de streaming point a point par Gstreamer et la compilation des librairies osip et eXosip, on a fait face, non seulement aux problemes de compatibilite avec les librairies existantes sur la machine hôte, mais aussi aux contraintes de l'integration de deux pipelines Gstreamer dans un seul pipeline.

    Pour remedier a ça, on a installe ces librairies depuis les paquets open source telechargeables depuis les sites Internet. De plus, en ce qui concerne les pipelines Gstreamer, on a utilise chaque pipeline a part.

    Conclusion

    Au cours de ce chapitre, nous avons commence par detailler l'environnement materiel de test, qui repose principalement sur la plateforme TMS320DM355. Son point fort etait l'embarquement du coprocesseur MJCP, l'accelerateur hardware de la video.

    Par la suite, nous avons aborde les differents solutions logicielles de test, y comprises le plugin TI pour Gstreamer et les piles du protocole SIP, Osip et eXosip.

    La partie suivante a ete consacree pour les differentes phases de test de streaming, soit entre les PCs, soit entre les 2 cartes. Ces tests ont ete valides et le streaming bidirectionnel est fonctionnel.

    Ensuite, on a fait les tests sur l'etablissement des sessions SIP. Apres succes de cette etape, on a pris le temps d'integrer le streaming point a point dans les communications SIP.

    La derniere partie de ce chapitre a porte sur les remedes a differentes difficultes rencontrees dont la plus importante est la surcharge de la CPU.

    Reference wireshark: http://www.wireshark.org/

    Reference ITTIAM: http://www.ittiam.com/

    Reference wiki TI: http://processors.wiki.ti.com/index.php/Example_GStreamer_Pipelines