Dardouri ghazi

Cycle de formation des ingénieurs en Télécommunications
Option :
Services et Communication Multimédia

Rapport de Projet de fin d’études

Thème :

Cryptage MPEG2/MPEG4 et gestion des
droits sur un décodeur TV Linux

Réalisé par :
Ghazi DARDOURI

Encadrant (s) :
M. Olivier Delfosse
M. Ziad BELHADJ

Travail proposé et réalisé en collaboration avec

Année universitaire : 2005/2006

1

Dédicaces

Dédicaces

A mon père : Farah

A ma mère : kaouther

A mon frère : Ghassen

A mes sœurs : Wissal, Olfa, Nihel,

A ma grande famille

A ma chère Fatma

A tous mes amis et ceux qui m’aiment

A l’âme du défunt et grand ami Ayoub Chiha

Je dédie ce mémoire.

DARDOURI Ghazi

Remerciements

Remerciements

Ce travail s’inscrit dans le cadre d’un projet de fin d’études en
télécommunications, option Service et communication multimédia à l’école
supérieure des communications de Tunis (Sup’Com).
Ce projet a été réalisé au sein de la société QUATERNOVE spécialisée
en Informatique Industrielle, Electronique, Ingénierie Optique et dans les
Systèmes d’information

Je remercie dieu pour l’accomplissement de ce modeste travail.

Au terme de ce travail, je tiens à remercier et à exprimer ma profonde
gratitude à mes encadreurs Mr. Ziad BELHADJ, maître de conférence à
SUP’COM, Mr Olivier DELFOSSE ingénieur et Manager de UR&D44 de
Sagem Communication pour leur aide précieuse, leurs conseils et leurs
suggestions avisées qui m’on aidé à mener à bien ce travail.

Le mérite revient également à Mr Tanguy LAUSIN, ingénier d’affaires à
Quaternove, ainsi qu’à toutes les personnes qui m’ont facilité la tâche de
réaliser ce travail, et spécialement Mr Thierry MAJIMEL et Madame Aïda
GHORBEL pour leurs soutiens durant toute la période de mon stage.

Je remercie également les membres de jury pour avoir accepté d’évaluer
mon travail.
Enfin, je remercie tous mes enseignants pour la qualité de la formation
qu’ils nous ont prodiguée durant nos études.

Avant Propos

Avant Propos

Ce travail a été élaboré dans le cadre de mon projet de fin d’études d’ingénieur en
Télécommunication de l’Ecole Supérieure des Communications de Tunis (SUP’COM). Le
développement de ce projet a été mené dans les locaux de Quaternove et en collaboration avec
SAGEM Communications au sein de l’unité UR&D 44.

Présentation de la société QUATERNOVE
QUATERNOVE est un groupe de conseil en technologies crée en 1995. Certifié ISO 9002 en
1997 puis ISO 9001 v2000 en 2003 et inscrit sur le Marché Libre d’Euronext Paris en 2000, il
est aujourd’hui implanté au niveau national. Fort à ce jour de 270 personnes, le groupe
QUATERNOVE a réalisé un chiffre d’affaires de 19,03 M€ en 2002 et maintenu un chiffre
d’affaires de 18,74 M€ en 2003.

Spécialisé en Informatique industrielle, Electronique, Ingénierie Optique et dans les Systèmes
d’information, le groupe QUATERNOVE offre à ses partenaires des solutions adaptées -
assistance technique, forfait, solutions personnalisées, externalisation - grâce à sa maîtrise des
domaines clefs des hautes technologies telles que l’informatique temps réel, les technologies
objet, l’intégration de systèmes informatiques, l’ingénierie des tests logiciels, la conception
électronique, les systèmes de mesure de phénomènes physiques, la communication haut-débit
sur fibres optiques, les systèmes optiques, les systèmes d’information et le transfert de
technologie.

Le groupe a acquis et valorisé des compétences pointues et un savoir-faire étendu dans les
domaines de l'aéronautique, du spatial, de l'automobile, du ferroviaire, de la défense, de
l’industrie, des télécommunications, du multimédia et de l'énergie.

Les études et les expertises de QUATERNOVE portent sur toutes les étapes du cycle de
développement du produit informatique ou optique, des spécifications à la validation. A la
demande du client, l’intervention peut se faire à des niveaux plus amonts ou transverses

Avant Propos

(conduite de projet, démarche qualité, qualification de systèmes, ergonomie) et sur des
missions de très haut niveau. QUATERNOVE s’est entourée pour cela de plusieurs
consultants exclusifs et d’experts techniques confirmés.

Philosophie : la valorisation des compétences, la réactivité et la souplesse des solutions
apportées permettent à QUATERNOVE de s’engager sur une qualité de service de haut
niveau et des résultats concrets.

Nos clients : ALSTOM, ALCATEL, AREVA, CEA, DASSAULT, EADS, PSA, SAGEM,
SCHNEIDER, AXALTO, THALES, MBDA, ZODIAC, WINCOR NIXDORF...

Historique du groupe QUATERNOVE

1995 : Création de la société QUATERNOVE.
1997 : Certification ISO 9002 des procédures et de l’assistance technique de la société.
1998 : Ouverture de l’agence de Toulouse.
2000 : Inscription sur le Marché Libre d’Euronext Paris,
Acquisition de la société SAGEIS, implantée à Aix-en-Provence et Toulouse,
spécialisée dans l’ingénierie optique et l’électronique.
2001 : Acquisition de la société CSO Mesure, implantée à Grenoble, spécialisée dans
les études et le développement de produits spécifiques pour l’industrie spatiale et
l’ingénierie de machines de mesures par moyens optiques,
Fusion de SAGEIS et CSO Mesure en SAGEIS CSO,
Obtention du label « société innovante FCPI » attribuée par l’ANVAR.
2003 : Certification ISO 9001 vs 2000 des procédures et de l’assistance technique de la
société,
Création de QUATERNOVE SI, spécialisée dans les systèmes d’information,
Prise de participation de 20% dans le capital de SOLENT.
2004 : Prise de participation de 10% dans la société vietnamienne IFI Solution.
2005 : Création de l’établissement d’Eragny sur Oise.

Table des matières

Table des matières

Introduction générale.................................................................................................................. 1
Chapitre 1: État de l’Art ............................................................................................................. 3
1.1 Introduction ...................................................................................................................... 3
1.2 Initiation au monde de la télévision numérique ............................................................... 3
1.2.1 La télévision numérique terrestre.............................................................................. 3
1.2.1.1 Historique ........................................................................................................... 3
1.2.1.2 Principes de fonctionnement de la TNT............................................................. 5
1.3 La norme Linux DVB ...................................................................................................... 6
1.3.1 Présentation de la norme DVB.................................................................................. 6
1.3.2 Flexibilité de la norme DVB-T ................................................................................. 9
1.3.3 Configurations de la norme DVB-T........................................................................ 10
1.3.4 Modes 2k et 8k ........................................................................................................ 10
1.3.5 Modes non hiérarchiques ........................................................................................ 11
1.3.6 Aptitude à traiter les échos ...................................................................................... 11
1.3.7 Modulations hiérarchiques ...................................................................................... 12
1.4 Les services interactifs ................................................................................................... 13
1.4.1 La vidéo à la demande (Video on Demand ou VoD) .............................................. 13
1.4.2 La visioconférence(UIT-T F730) ............................................................................ 15
1.5 Conclusion...................................................................................................................... 15
Chapitre 2: Architecture du système ........................................................................................ 16
2.1 Introduction .................................................................................................................... 16
2.2 Architecture de SAGEM DVB....................................................................................... 16
2.3 Poste de développement ST-Linux ................................................................................ 18
2.3.1 La distribution MANDRIVA 2006.A ..................................................................... 18
2.3.1.1 Présentation de la distribution MANDRIVA 2006.A ...................................... 18
2.3.1.2 Installation ........................................................................................................ 18
2.3.2 Installation de ST LINUX ENVIREMENT OF DEVELOPPMENT ..................... 18
2.3.2.1 ST- Paquetage .................................................................................................. 19
2.3.2.2 La Sonde.......................................................................................................... 19
2.3.2.3 Changement de la racine en mode NFS ........................................................... 19
2.3.3 Logiciels utilisés...................................................................................................... 19
2.3.3.1 CSCOPE........................................................................................................... 19
2.3.3.2 Subversion 1.1.4 ............................................................................................... 19
2.3.3.3 JAVA SDK....................................................................................................... 20
2.3.3.4 ECLIPSE “eclipse-SDK-3.0.2”........................................................................ 20
2.4 Serveur de vidéo : VidéoLan VLC................................................................................. 20
2.4.1 Description .............................................................................................................. 20
2.4.2 Installation de VLC ................................................................................................. 22
2.4.2.1 Compilation des sources................................................................................... 22
2.4.2.2 Installation du VLC.......................................................................................... 22
2.4.3 Modules et options de VLC .................................................................................... 22
2.4.3.1 Modules ............................................................................................................ 22
2.4.3.2 Options de compilation .................................................................................... 23

Table des matières

2.4.4 Méthode de diffusion VLC ..................................................................................... 23
2.4.4.1 Utilisation de la ligne de commande ................................................................ 23
2.4.4.1.1 Architecture modulaire.............................................................................. 23
2.4.4.1.2 Syntaxe ...................................................................................................... 24
2.4.4.2 Diffusion facile en utilisant l’interface graphique............................................ 25
2.4.4.2.1 Diffuser en utilisant l'Assistant ................................................................. 25
2.4.4.2.2 Diffusion en mode graphique.................................................................... 29
2.4.5 Autre solution possible pour un serveur VideoLAn : Serveur de ........................... 30
2.4.5.1 Structure de VLS.............................................................................................. 30
2.4.5.2 Interface d'administration................................................................................. 32
2.5 Application SAGEM DVB ZAPPING........................................................................... 32
2.5.1 L’API Linux DVB................................................................................................... 32
2.5.2 Logique du travail ................................................................................................... 33
2.5.2.1 Chargeur générique de modules....................................................................... 33
2.5.2.2 API infra rouge................................................................................................. 34
2.5.2.3 API de test ........................................................................................................ 34
2.6 Application FREEVO .................................................................................................... 34
2.6.1 Présentation de Freevo ............................................................................................ 34
2.6.2 Les dépendances de Freevo..................................................................................... 35
2.6.3 Installation de Freevo .............................................................................................. 36
2.6.4 Configuration générale............................................................................................ 36
2.7 Décodeur STBLinux ...................................................................................................... 37
2.8 Conclusion...................................................................................................................... 38
Chapitre 3: Contrôle d'accès..................................................................................................... 39
3.1 Introduction .................................................................................................................... 39
3.2 Méthodes et protocoles pour le contrôle d’accès ........................................................... 39
3.2.1 Méthodes existantes de contrôle d’accès ................................................................ 39
3.2.1.1 Solution avec carte à puce ................................................................................ 39
3.2.1.1.1 Cartes à puce et domaines d’applications ................................................. 39
3.2.1.1.2 Diverses architectures des cartes à puce existantes................................... 40
3.2.1.1.3 Opérations supportées par les cartes à puce .............................................. 42
3.2.1.2 Solution sans carte à puce (décodeur) .............................................................. 43
3.2.1.2.1 Architecture du système adopté pour le contrôle d’accès ......................... 43
3.2.1.2.2 Transactions STB serveurs........................................................................ 43
3.2.2 Le protocoles SSL ................................................................................................... 44
3.2.2.1 Présentation générale du protocole SSL........................................................... 44
3.2.2.2 Fonctionnement du protocole SSL................................................................... 45
3.2.2.2.1 Position de SSL dans la pile protocolaire.................................................. 45
3.2.2.2.2 Les apports de SSL.................................................................................... 46
3.2.2.2.3 Les sous protocoles de SSL....................................................................... 46
3.2.2.3 Le protocole Handshake................................................................................... 47
3.2.2.3.1 Fonctionnement général ............................................................................ 47
3.2.2.3.2 Ouverture d'une nouvelle session.............................................................. 47
3.2.2.3.3 Authentification du serveur ....................................................................... 48
3.2.2.3.4 Ouverture d'une connexion........................................................................ 48
3.2.2.4 Le protocole ChangeCipherSpec (CCS) .......................................................... 49
3.2.2.5 Le protocole Record ......................................................................................... 49
3.2.2.6 Le protocole Alert ............................................................................................ 50
3.3 Solution proposée........................................................................................................... 51
3.3.1 Méthode de contrôle d’accès proposée pour le cas avec carte ................................ 51

Table des matières

3.3.1.1 Services et fonctionnalités offertes par la carte à puce .................................... 51
3.3.1.2 Utilisation de la carte a puce ............................................................................ 52
3.3.1.2.1 Authentification de la carte par le décodeur.............................................. 52
3.3.1.2.2 Sécurisation de l’accès au media............................................................... 52
3.3.1.2.3 Authentification de l’accès : validité de la carte à puce ............................ 52
3.3.2 Utilisation de OpenSSL........................................................................................... 54
3.3.2.1 Définition ......................................................................................................... 55
3.3.2.2 Apports de OpenSSL........................................................................................ 55
3.3.3 Scénario global pour le contrôle d’accès dans l’application SAGEM_DVB.......... 55
3.4 Conclusion...................................................................................................................... 57
Conclusion générale ................................................................................................................. 58
Bibliographie et Webographie ................................................................................................. 59
Glossaire................................................................................................................................... 60

Liste des figures

Liste des Figures

Figure 1.1 : Schéma de la chaîne d’émission/transmission/réception DVB .............................. 5
Figure 1.2 : solutions proposées pour le déploiement DVB .................................................... 14
Figure 2.1 : Architecture générale de l’application.................................................................. 17
Figure 2.2 : Solution de diffusion VideoLAN.......................................................................... 21
Figure 2.3 : Démarrer l'assistant............................................................................................... 25
Figure 2.4 : La boîte de dialogue de l'Assistant ....................................................................... 26
Figure 2.5 : Sélection de l'entrée par l'Assistant ...................................................................... 26
Figure 2.6 : (a) Sélection de l'entrée depuis la liste de lecture par l'Assistant ......................... 27
(b) Sélection de l'entrée depuis fichier ..................................................................................... 27
Figure 2.7 : Méthode de diffusion par l'Assistant .................................................................... 28
Figure 2.8 : Options de l'assistant de diffusion ........................................................................ 29
Figure 2.9 : Diffusion du flux de sortie en mode graphique .................................................... 29
Figure 2.10. Structure de VLS ................................................................................................. 31
Figure 2.11 : Structure d’une carte Linux DVB....................................................................... 33
Figure 2.12 : Interface Freevo .................................................................................................. 35
Figure 2.13 : Logiciels requis pour l’installation de Freevo .................................................... 36
Figure 2.14 : Plateforme logicielle........................................................................................... 37
Figure 3 .1 : Eléments principaux d’une puce.......................................................................... 41
Figure 3.2 : Contrôle d’accès sans carte à puce pour le cas des services VOD et TV à la
demande ................................................................................................................................... 43
Figure 3.3: transactions entre STB et les serveurs de l’architecture d’accès ........................... 44
Figure 3.4 Modèle de fonctionnement de SSL......................................................................... 45
Figure 3.5 Position du protocole SSL au sein de la pile TCP/IP ............................................. 45
Figure 3.6 Empilement des sous-couches protocolaires de SSL.............................................. 46
Figure 3.7 Messages échangés pendant l’établissement d’une nouvelle session ..................... 47
Figure 3.8 Echanges pendant l’ouverture d’une session .......................................................... 48
Figure 3.9 Messages échangés pour l’ouverture d’une connexion .......................................... 49
Figure 3.10 Fonctions effectuées par la couche Record........................................................... 50
Figure 3.11 : Cas de carte à puce avec durée de temps prédéfini ............................................ 53
Figure 3.12 : Cas de carte à puce avec durée de temps prédéfinie........................................... 54
Figure 3.13: scénario proposé .................................................................................................. 56

Liste des Tableaux

Liste des Tableaux

Tableau 1.1 : Débit utile modulation (64 QAM, code correcteur de taux 2/3) et résistance aux
échos pour les modes 2k et 8k.................................................................................................. 11
Tableau 3.2 Liste exhaustive des services de sécurité et des fonctions permettant de les assurer
[LAM 89] ................................................................................................................................. 51

Introduction générale


Le domaine de la télévision numérique est en pleine expansion. Ce domaine prend de
plus en plus d’ampleur surtout avec l’introduction de la TNT en France et dans les pays
développés. C’est pour cela que ce domaine attire de plus en plus de firmes mondiales
spécialisées dans le domaine multimédia et Télécoms qui font la course pour le gain des
marchés fleurissants dans ce secteur.

Ces firmes s’intéressent à optimiser le coût des décodeurs qui constituent le maillon le
plus important dans la chaîne puisqu’ils concernent le client directement de point de vue
satisfaction et prix. De plus, ces sociétés tendent à adopter les logiciels open sources pour
l’implémentation dans un but de réduction de coûts de production en plus de la performance
de ces logiciels qui ne cesse de croître : les plateformes comme LINUX commencent à attirer
de plus en plus de monde.

Mais, la contrainte de sécurité est de plus en plus présente dans le cas du contrôle
d’accès. Plusieurs solutions sont disponibles pour le contrôle d’accès qui constitue l’une des
dépenses les plus importantes des chaînes de télévision qui dépensent des sommes colossales
dans le but de protéger les événements qu’ils achètent. Ainsi, la partie de contrôle d’accès
prend une dimension très importante dans le processus de diffusion du contenu multimédia.
Le projet SAGEM_DVB_ZAP s’inscrit dans le cadre de l’implémentation sur le décodeur
STB 7100 sous Linux de fonctions telles que le fonctionnement sur des flux hétérogènes
(vidéo sur IP, DVB-T, DVB-C etc.).

Nous allons dans ce projet mettre en place une architecture de test sur cette
application, chaque fois qu’on a un prototype qui est fonctionnel pour pouvoir le valider. Le
flux supporté par ce décodeur jusqu’à maintenant est MPEG2-TS et dans un proche avenir, le

Projet de fin d’études 2005-2006 1


format MPEG4 sera pris en charge. Nous pourrons interagir avec le décodeur grâce à
l’interface Freevo qui permet de visualiser un contenu multimédia selon le choix.

Nous allons aussi étudier les solutions existantes pour le contrôle d’accès avec carte à
puce ou dans le cas de la présence d’un serveur DRM (Digital Right Management) pour avoir
une idée sur le choix futur à prendre concernant l’implémentation du contrôle d’accès. Nous
proposerons entre autre deux solutions à base de carte à puce dont le choix va dépendre du
choix économique du fournisseur.


Chapitre 1 État de l’art

Chapitre 1: État de l’Art

1.1 Introduction
Le travail dans le domaine de la transmission numérique de la vidéo nécessite de
mettre l’accent sur les techniques qui peuvent rendre cette opération faisable. Ainsi, il faut
naturellement détailler les différentes normes qui régissent cette transmission et qui
permettent d’offrir les services souhaités.

1.2 Initiation au monde de la télévision numérique
On a été chargés au départ de se familiariser avec le monde de la télévision numérique
terrestre et de faire en sorte à ce que nous soyons opérationnels le plus rapidement possible.
Cette tâche consistait à découvrir les principes de la télévision numérique terrestre ainsi que
celle de la norme Linux DVB. La dernière partie de cette mission consistait à préparer notre
plateforme de travail afin que nous puissions découvrir ces fonctionnalités en premier lieu et
pouvoir travailler dessus après.
Dans cette section, nous présentons une description succincte de la télévision numérique.
1.2.1 La télévision numérique terrestre
La télévision numérique terrestre est l'une des technologies en vogue en ce moment.
Cette nouvelle génération de télévision fera la une pour au moins les dix années à venir et sera
l'un des domaines d'intérêt des chercheurs et des scientifiques. Nous commencerons par un
historique de cette technologie et nous étalerons dans la suite quelques principes de la
télévision numérique.
1.2.1.1 Historique
Le système de télévision numérique terrestre européen (normalisé sous la référence
ETS 300 744) utilise la modulation OFDM (également appelé COFDM) déjà utilisée pour la
radio numérique (DAB) [1]. Cette norme utilise deux variantes la 2K et la 8K. Le Royaume-
Uni a été le premier pays européen à démarrer (fin 1998) un service de TV numérique
terrestre, en majeure partie à péage, à la norme DVB-T. Elle est le seul pays européen à



utiliser la modulation COFDM à 2K porteuse en raison de la non disponibilité de circuits
démodulateur pour le mode 8K à l'époque.
• La Suède et l'Espagne ont suivi, respectivement fin 1999 et mi-2000, et utilisent le
mode DVB-T 8K. Ceci a permis à l'Espagne de développer un réseau de multiplex à
fréquence unique (SFN) sur tout le territoire sur les canaux les plus élevés de la bande
UHF (66 à 69), inutilisés jusque-là par la télévision analogique. La France ne rejoint le
club des pays dotés de la télévision numérique qu'en mars 2005. Elle a pu ainsi offrir
au grand public un bouquet de huit chaînes gratuites avec une très haute qualité de son
et d'image et ceci en utilisant une simple antenne terrestre.
Cependant, le remplacement complet des émissions analogiques actuelles par les
nouveaux services numériques promet d'être un processus long (environ 10 ans), à moins
d'une volonté politique d'accélérer le mouvement, affirmée par exemple en fournissant
gratuitement ou à un prix très modique des adaptateurs numériques de base à tous les foyers
acquittant la taxe TV...
Le système DVB-T a d'ores et déjà été choisi par un certain nombre de pays non
européens, dont l'Australie et Singapour, mais, pour les pays n'ayant pas encore fait leur
choix, il se trouve désormais en concurrence avec un nouveau système japonais (ISDB-T),
également basé sur la modulation COFDM avec quelques ajouts qui le rendent encore plus
robuste (surtout pour la réception mobile), au prix cependant d'une complexité et d'un surcoût
importants.
Les Etats-Unis quant à elle a démarré en 1998 les émissions numériques terrestres, en
TVHD au standard ATSC avec pour objectif initial l'arrêt des émissions analogiques NTSC
en 2008. Cependant, en raison de choix à la fois techniques et politiques discutables
(performances décevantes de la modulation choisie 8-VSB ou BLR-8 à bande latérale
résiduelle à 8 états, coût élevé des afficheurs à haute définition, absence de services interactifs
associés), le développement a été très décevant jusqu'à présent, ce qui rend très improbable un
arrêt effectif des émissions analogiques en 2008.
En conclusion, la télévision numérique terrestre est une technologie émergente dans
tous les coins de la planète dans ce début du troisième millénaire et il est assez clair qu'elle a
encore besoin des efforts de la recherche et des industriels pour s'imposer comme un unique
standard de télévision. Mais elle reste par ailleurs une technologie très prometteuse. Dans la
suite, on va décrire les principes de fonctionnement de la TNT.



1.2.1.2 Principes de fonctionnement de la TNT
Avant de passer à la description d'un récepteur avec décodeur intégré, appelé IRD
(Integrated Receiver-Decoder) ou plus familièrement set top box (littéralement « boite posée
sur le poste ») par les Anglo-Saxons, nous récapitulerons rapidement de façon très simpliste la
suite des opérations que subit le signal TV de sa source à sa visualisation par l'utilisateur.
La Figure 1.1 illustre tout le processus d'émission et de réception en TV numérique. La
partie supérieure de cette figure décrit les étapes du cycle d'émission. La partie inférieure est
destinée pour la réception[2].

Prog 1 PES
Codage
MPEG Paquet
188 oc I, Q FI
Multiplexage + FEC, formatage, Modulation Elévation de
1 embrouillage DAC fréquence

Prog n Codage
MPEG 2 3 4
5
PES

Support de
transmission

Codage /Décodage de la source Codage /Décodage du canal
6
10 9
Paquet 8 7
PES 188 oc I, Q FI
Image Codage Multiplexage + FEC, formatage, Démodulation Abaissement de
+ Son MPEG embrouillage DAC fréquence

Figure 1.1 : Schéma de la chaîne d’émission/transmission/réception DVB
Le processus d'émission a comme but de fournir sur un seul canal RF un multiplex de
programmes MPEG-2 ou MPEG-4. Ce résultat est obtenu en suivant les étapes suivantes:
1. Les signaux vidéo et audio des programmes à transmettre attaquent autant de décodeur
MPEG (de l'ordre de 4 à 8 par canal selon les paramètres de codage choisis) qui fournissent
les PES vidéo et audio à l'entrée du multiplexeur.
2. Ces PES sont utilisés par le multiplexeur pour former des paquets transport de 188 octets,
éventuellement embrouillés (des paquets CAT transportant les informations de contrôle



d'accès ECM et EMM sont alors insérés) ainsi que les informations de tables PAT et PMT
et celles du guide de programme (EPG).
3. La correction d'erreur RS porte la longueur des paquets à 204 octets; dans le cas du
satellite, le code convolutif multiplie de plus en plus le débit par un facteur 1,14 à 2; un
reformatage des données suivi d'un filtrage et d'une conversion fournit les signaux I et Q
analogique.
4. I et Q modulent en COFDM une porteuse FI (Fréquence Intermédiaire).
5. Cette fréquence intermédiaire est transposée ensuite dans la bande de fréquence appropriée
à sa transmission selon le médium utilisé.
Côté récepteur, la partie basse de la figure montre que les opérations, symétrique de
celle de l'émission, s'effectuent, logiquement, dans l'ordre inverse de l'émission.
6. Seulement en cas d'une réception satellite, un premier abaissement de fréquence se fait
dans la tête de réception de l'antenne. En suite le signal subit un deuxième changement de
fréquence à l'entrée du récepteur. Cette deuxième opération est valable pour tous les modes
de réceptions .A la fin de cette étape, on obtient une FI démodulée.

7. Cette FI démodulée, fournit les vecteurs I et Q analogiques.

8. Après conversion analogique/numérique, filtrage et reformatage de I et Q, la correction
d'erreur permet de retrouver les paquets « transport » de 188 octets.

9. Le démultiplexeur sélectionne les PES correspondant au programme choisi par l'utilisateur,
éventuellement désembrouillés au préalable grâce aux ECM et EMM et à la clé privée de
l'utilisateur (généralement une carte).
10. Le décodeur MPEG-2 reconstruit les images et le son du programme sélectionné.
Après avoir décrit le processus d'émission et de réception d'un signal de télévision
numérique, nous procéderons dans la suite à la description de l'outil de réception. Le modèle
d'un récepteur TV numérique basé sue le système d'exploitation Linux est normalisé suivant
la norme Linux DVB.

1.3 La norme Linux DVB
1.3.1 Présentation de la norme DVB
Digital Video Broadcasting (ou DVB), soit « diffusion vidéo numérique », est une
norme de télévision numérique édictée par le consortium DVB, organisme européen, mais
utilisée partout au monde, sauf pour la télévision terrestre dans quelques pays dont les États-
Unis d'Amérique et Canada (où la norme ATSC prédomine) et le Japon (autre norme).



La télé par satellite en Amérique est diffusée partiellement en DVB et partiellement en
un autre système (propriété de Motorola); les DirecTV se sert des normes incompatibles
utilisées en aucun autre système. Globecast, Dish Network et ExpressVu sont DVB, aussi
certains canaux libres ou ethniques. La version 1 de la norme utilise la compression vidéo
MPEG-2 et le MPEG-2 Transport Stream comme flux de transport de paquet.
On peut remarquer que c'est le 'MPEG-2 Program Stream' qui est utilisé dans les
périphériques utilisant la norme MPEG-2 comme les lecteurs DVD. La différence essentielle
entre le MPEG-2 Transport Stream et le 'MPEG-2 Program Stream' est la taille des paquets
d'octets des flux de données: un paquet 'Transport' a une taille de 188 octets, alors qu'un
paquet 'Program' peut avoir une taille de 2048 octets.
Le DVB est surtout une norme qui concerne la signalisation diffusée dans le flux (les
tables DVB), qui permet à tout décodeur DVB de retrouver les programmes reçus. Elle
enrichit la Norme MPEG (ISO 13818). Les différents canaux numérisés (de télévision
principalement) sont multiplexés: c'est à dire séparés (en Audio, en Vidéo, en informations..),
découpés en paquets et mélangés. Un programme de TV se compose donc du flux de la
composante vidéo, du flux de la composante audio, du flux des sous-titres en français, du flux
des sous titre en anglais, du flux... Chacun de ces flux est transporté par des paquets de
transport (TS) qui portent un même numéro pour chacun des flux, le Paquet Identifier (PID).
Les tables DVB servent à déterminer ce que transporte un flux de paquets de transport avec
un même PID[2].
Il y a trois tables importantes qui donnent des informations sur le flux:
• La 'Program Association Table' (PAT) qui donne la liste des programmes présents
• La 'Program Map Table' (PMT) qui donne pour un programme sa composition, les
différents PID qui le constituent
• La 'Conditional Access Table' (CAT) qui donne la localisation des informations pour
le décodage des programmes cryptés.
Ajoutons quelques informations:
• La 'Service Definition Table' qui donne un nom entre autres aux services
• La 'Network Information Table' qui donne la liste des canaux composant un réseau
• La 'Event Information Table' qui donne les informations sur les programmes en cours
ou à venir.
Les normes DVB sont définies par l'Etsi: The European Telecommunications Standards
Institute.



Le DVB a spécifié une norme pour chaque un des types les décodeurs [3]:
• DVB-S pour la télévision par satellite. C'est le plus ancien et le plus établi des travaux
du groupe DVB. Il est employé sur tous les continents. Il permet d'occuper au mieux
la bande passante des canaux satellitaires existants. Une des images couramment
employées pour expliquer le DVB est de dire que c'est un oignon. Dans son coeur se
trouvent les paquets MPEG (l'information utile). DVB a rajouté des "peaux
supplémentaires" pour protéger des erreurs ces informations du milieu difficile qu'elles
vont traverser. En fonction de l'épaisseur de ces "peaux", le débit utile qu'un canal
satellite peut transporter varie. C'est l'opérateur de service qui détermine l'épaisseur de
ces couches de protection. Par exemple, sur un canal de largeur de bande 36MHz, on
pourra transporter environ 38 Mbit/s d'information utile.
• DVB-C est utilisé pour la télévision par câble. Le DVB-C est basé sur le DVB-S. La
modulation change, on utilise le QAM à la place du QPSK, et le milieu de transport (le
câble) étant moins bruité que la voie satellite, on supprime une couche de protection
d'erreurs. Ici, nos 38 Mbit/s de données utiles peuvent circuler dans un canal de
8MHz.
• DVB-T pour la télévision hertzienne/terrestre. Le DVB-T a été approuvé par l'ETSI en
Février 1997. Comme pour le DVB-S et le DVB-C, les informations sont codées, de
base, selon la norme MPEG2, DVB définissant le mode de transport et les systèmes de
protection d'erreurs. C'est la modulation COFDM qui a été retenue, sous une forme 2K
(1705 porteuses) et 8K (6817 porteuses). Chacune de ces porteuses étant elle-même
modulée en QUAM ou QPSK. Ce système, insensible aux échos, présente l'avantage
de pouvoir réaliser des réseaux mono fréquences (SFN).
• DVB-M/CS ici, on utilise les micro-ondes pour une distribution multipoint.
• DVB-SI MPEG 2 permet de séparer les informations système (SI), des informations
spécifiques de programme (PSI). DVB a mis à disposition un système ouvert
d'insertion d'information système qui permet au terminal ou à l'utilisateur de naviguer
à travers les services. On va ainsi retrouver toutes les informations pour un zapping
simplifié, toutes les informations concernant les programmes (heure de début et de fin
d'une émission, type de l’émission), etc.
• DVB-CA Vu du coté du terminal, les systèmes de contrôle d'accès peuvent être vus
comme étant composés de deux parties:



-le décryptage: la clé d'embrouillage est transmise codée dans le flux. Si on a
souscrit le bon abonnement, un module fournit la clé en clair au module de
désembrouillage.
-le désembrouillage : grâce à la clé en clair, on peut restituer l'information
originale.
De plus, grâce au DVB-CA, on peut faire du:
-SimulCrypt : un opérateur embrouille un programme à la fois en
Viaccess et en Médiaguard, par exemple. Ce programme peut alors être diffusé
sur chacun des réseaux utilisant son propre système de CA.
-MultiCrypt : un terminal peut travailler avec différents systèmes de contrôle
d'accès.
• DVB-CI : l'interface commune est une interface normalisée entre une carte PCMCIA
et le terminal numérique. C'est cette interface qui permet à un terminal DVB
d'accepter différents types de contrôle d'accès (Viaccess, Médiaguard, Irdeto...).
• DVB-H : pour les applications portables (H pour « handheld »).
Dans ce document, nous nous intéressons à la norme DVB-T qui définit un ensemble
de standards pour les décodeurs destinés à la télévision numérique terrestre.
1.3.2 Flexibilité de la norme DVB-T
La norme DVB-T, qui définit les techniques de modulation et de codage canal pour la
diffusion hertzienne numérique, prévoit plusieurs configurations, ce qui offre de la flexibilité
pour la mise en oeuvre de la diffusion. Ces configurations diffèrent notamment sur :
• la couverture d'un émetteur donné de puissance donnée : c’est l’identification de la
zone où on reçoit le signal à l'aide d'une antenne fixe sur le toit (réception fixe ou
mobile). Identification des zones de réception portable (récepteur avec une antenne
intégrée, situé dans la maison) ou des zones de réception mobile (dans un véhicule).
• Le débit utile d'un multiplex (un canal de 8 Mhz), qui conditionne le nombre de
programmes et la qualité du codage.
Il s'agit de définir quels sont les modes qui pourront être utilisés dans les réseaux de
diffusion, ou corrélativement ceux que devront inclure les terminaux.



1.3.3 Configurations de la norme DVB-T
La norme DVB-T prévoit :
• Quatre valeurs d'intervalle de garde (1/4 ; 1/8 ; 1/16 ; 1/32) : plus l'intervalle est élevé,
plus la réception est robuste à des échos longs, naturels ou artificiels (réseaux mono
fréquences), mais moins le débit utile est élevé.
• Cinq codes correcteurs d'erreurs : cela correspond à différents compromis entre la
robustesse au bruit et le débit utile.
• Trois modulations non hiérarchiques (QPSK, 16-QAM et 64-QAM) et deux
modulations hiérarchiques (QPSK + QPSK et QPSK + 16 QAM). Les trois
modulations non hiérarchiques correspondent à différents compromis entre robustesse
au bruit et débit utile. Globalement, les codes correcteurs et les modulations non
hiérarchiques offrent un continuum de compromis allant de 5 à 31 Mbit/s. Les
possibilités des modulations hiérarchiques seront développées ci-dessous.
• Deux nombres de porteuses, l'OFDM étant une modulation multi porteuse, 1705 et
6817, connus sous les noms 2k et 8k, car ils sont réalisés via des transformées de
Fourier rapides à 2048 et 8192 points.
1.3.4 Modes 2k et 8k
Le système retenu par DVB est tel que les circuits implantant le mode 8k savent traiter
les signaux 2k. Le choix doit donc s'effectuer entre «2k» et «8k compatible 2k».
Sur le plan opérationnel, le seul avantage du mode 2k concerne la réception mobile : comme
les porteuses sont plus écartées, le signal est plus robuste aux effets Doppler en présence
d'échos.
Le mode 8k présente principalement l'avantage d'accroître les intervalles de garde, et
donc la robustesse de la réception aux échos longs, naturels ou artificiels (émetteurs
constituant un réseau mono fréquences ou réémetteurs iso fréquences en particulier). En 2k,
les valeurs d'intervalles de garde 1/32 et 1/16 sont sans doute trop faibles, car elles
correspondent à des échos de 7 _s et de 14 _s respectivement, tandis qu'on rencontre des
échos naturels supérieurs à 14 _s en milieu urbain. Avec les intervalles de garde 1/8 et 1/4 (28
_s et 56 _s), on résiste bien aux échos naturels; cependant, comme l'indique le tableau ci-
dessous, les modes 8k avec intervalles de garde 1/32 et 1/16 conduisent à 28 _s et 56 _s
également, avec un débit utile supérieur de 9% et de 18% respectivement au mode 2k : même
en l'absence de réseau mono fréquences, le 8k est donc préférable. Pour des réseaux mono
fréquences, la densité des émetteurs doit être d'autant plus élevée que la durée de l'intervalle



de garde est courte : en pratique, il faut donc le mode 8k, avec un intervalle de garde de 1/8
voire de 1/4 pour disposer de mailles larges (supérieures à 50 Km).
intervalle de garde 2k : durée des échos débit utile 8k : durée des échos

1/32 7 _s 24,13 Mbit/s 28 _s

1/16 14 _s 23,42 Mbit/s 56 _s

1/8 28 _s 22,12 Mbit/s 112 _s

1/4 56 _s 19,91 Mbit/s 224 _s
Tableau 1.1 : Débit utile modulation (64 QAM, code correcteur de taux 2/3) et résistance aux
échos pour les modes 2k et 8k
En termes de coûts des récepteurs, l'impact est a priori d'une part sur le circuit de
démodulation, et d'autre part sur le circuit tuner. En ce qui concerne le circuit de
démodulation, le circuit est constitué de logique programmable et de mémoire. La logique
programmable est du même ordre de grandeur en 2k et en 8k.
En revanche, la mémoire est approximativement deux fois plus élevée en 8k. Les
perspectives d'évolution technologique font que le surcoût du 8k baissera non seulement en
valeur absolue, mais aussi proportionnellement. En ce qui concerne le circuit tuner, il n'y a
pas de surcoût significatif en 8k.
1.3.5 Modes non hiérarchiques
Du fait des limitations en spectre et de la volonté de réduire les coûts de diffusion, il
est souhaitable d'utiliser autant qu’on peut la modulation 64 QAM. Comme le surcoût est
marginal pour le circuit, il faut que tous les terminaux sachent traiter la modulation 64 QAM,
et il leur est alors facile de traiter les autres modulations qui sont plus simples.
De même, pour les différents codes correcteurs et intervalles de garde, le surcoût sur
les circuits est nul, et il faut que toutes les possibilités soient offertes en diffusion.
Il est donc légitime d'attendre que tous les modes non hiérarchiques soient supportés par tous
les récepteurs.
1.3.6 Aptitude à traiter les échos
Les échos sont présents naturellement (en particulier en ville et en intérieur) et
artificiellement (réseaux SFN et réémetteurs iso fréquence). Il convient de s'assurer que les
récepteurs sont capables de s'adapter à ces échos.
L'implantation «standard» de l'estimateur de canal de la norme DVB-T rend le
récepteur robuste à des échos d'une durée inférieure à l'intervalle de garde. Il est légitime



d'attendre de tous les récepteurs cette fonction. Pour des échos d'une durée supérieure à
l'intervalle de garde, il faut des dispositifs d'égalisation du canal plus complexes que
l'estimateur «standard», qui ne peuvent en aucun cas être attendus dans tous les récepteurs. Il
est donc indispensable de faire en sorte que les échos artificiels soient d'une durée inférieure à
l'intervalle de garde.
1.3.7 Modulations hiérarchiques
Les modulations hiérarchiques consistent à séparer le signal en deux flux, un flux
prioritaire et un flux non prioritaire. Le flux prioritaire est mieux protégé que le flux non
prioritaire, si bien que lorsque la réception est mauvaise, seul le flux prioritaire est décodé.
A titre d'exemple, considérons un flux de 22,12 Mbit/s, reçu sur une zone de 10 Km de
rayon avec un mode non hiérarchique avec une puissance donnée. Si le flux est divisé en un
flux prioritaire de 7,37 Mbit/s et un flux non prioritaire de 14,75 Mbit/s, et si ces deux flux
sont diffusés avec un mode hiérarchique avec la même puissance, le flux prioritaire est reçu
jusqu'à 15,4 Km de l'émetteur, mais le flux non prioritaire jusqu'à 8,7 Km de l'émetteur
seulement. Avec un autre mode hiérarchique, le flux prioritaire est reçu jusqu'à 13 Km et le
flux non prioritaire jusqu'à 9,8 Km de l'émetteur. Précisons qu'il s'agit de valeurs théoriques
nécessitant une confirmation expérimentale.
Concrètement, cela permet par exemple d'avoir une bonne couverture portable de
certaines chaînes, tout en proposant en réception fixe une large offre de programmes. Cela
signifie également qu'il existe une zone (dépendant de la planification de fréquences) limitée à
l'offre prioritaire. Ce ne sera pas forcément compatible avec les choix d'introduction des
services.
Il aurait été envisageable de combiner les modulations hiérarchiques avec un codage
de source hiérarchique. Cela signifie par exemple qu'un signal TVHD aurait été codé en deux
flux : un flux contenant les informations nécessaires à la reconstitution d'un signal TV de
qualité standard, transmis de manière prioritaire, et un flux contenant les informations
complémentaires nécessaires à la reconstitution du signal haute définition. Il a été décidé par
DVB de ne pas retenir cette possibilité : il n'y a pas de codage de source hiérarchique dans les
systèmes DVB, un système de double diffusion qualité standard - haute définition est choisi.
Les modulations hiérarchiques peuvent cependant être utilisées dans un contexte de double
diffusion qualité standard - haute définition, en transmettant le flux standard de manière
prioritaire, à l'attention des récepteurs portables, et le flux haute définition de manière non
prioritaire, à l'attention des récepteurs fixes.



Le surcoût des modes hiérarchiques n'est pas significatif pour les récepteurs.
Cependant, ils doivent être pris en compte lors de la conception du terminal : par exemple, il
faut gérer au niveau du démultiplexeur le fait que le démodulateur peut générer deux flux. Il
semble qu'une partie de l'offre de composants permettront ces modes (au moins SGS
Thomson, VLSI Technology et LSI Logic), mais il existe en Europe des récepteurs qui ne
l'incluront pas.
En ce qui concerne les émetteurs, les modes non hiérarchiques ne sont sans doute pas
installés «en série», mais les émetteurs peuvent facilement insérer «en option» ces modes,
dont le surcoût sur les émetteurs est marginal. Il faut également considérer les difficultés pour
l'alimentation des émetteurs par le réseau de transport : l'émetteur doit disposer de deux flux,
et si les signaux sont repris de la diffusion par satellite, cela signifie que l'émetteur doit avoir
deux équipements de transmultiplexage pour constituer les flux prioritaire et non prioritaire.
L'usage des deux flux suppose la duplication de la gestion des informations de service (SI). Le
déploiement de services dans les modes hiérarchiques implique donc un surcoût pour le
réseau de diffusion.

1.4 Les services interactifs
1.4.1 La vidéo à la demande (Video on Demand ou VoD)
L'avantage majeur que fournissent les réseaux à hauts débits par rapport aux réseaux
de diffusion classique de télévision réside dans l'interactivité et la personnalisation offerte au
client. L'aboutissement de ces caractéristiques est résumé dans la délivrance de contenus à la
demande, où le client peut choisir quel contenu il désire consulter, et à quel instant.

De nombreux opérateurs évoquent depuis longtemps des services de vidéo à la
demande. Il faut cependant faire la distinction entre plusieurs types de ces services, qui sont
résumés sur le Tableau 4. La première étape de la personnalisation des contenus vidéo est
franchie dès lors que les services en « Pay-Per-View » apparaissent. Ceux-ci permettent à un
client d'acheter le droit de voir une émission (film ou événement sportif en général). Cela
s'apparente en fait à un contrôle d'accès sur ce contenu spécifique, accompagné d'une
transaction électronique, le paiement se faisant en général par carte de paiement. Sur les
réseaux à hauts débits, ce type de service devrait voir le jour assez rapidement car il permet de
maîtriser assez facilement de nombreux paramètres.Un second type de service est déjà fourni
par un grand nombre d'hôtels, et consiste à diffuser sur des chaînes internes (dans ce cas cela
n'est pas une contrainte) des films à intervalles réguliers. Il existe donc des « séances » pour
chaque film, en général payantes. Ce type de service, est appelé near Video on Demand ou



nVOD. Techniquement, la fourniture de ce service n'est pas fondamentalement différente des
contraintes d'une télévision classique. La programmation en est même simplifiée. Il faut noter
que ce type de schéma ne présente que peu d'intérêt dans le cas des réseaux à hauts débits,
leur objectif étant de se satisfaire des infrastructures existantes.

Enfin, le véritable service de vidéo à la demande consiste à fournir un contenu vidéo à
la demande du client, au moment de son choix, après avoir effectué celui-ci sur un catalogue.
L'apport des réseaux à hauts débits est ici amplifié par les facilités de conception de
catalogues véritablement interactifs, qui sont en fait des sites Web «classiques», dont le
financement peut être assuré par la publicité car sa consultation constitue une grande partie de
la consommation du client.

Plusieurs architectures ont été testées pour le déploiement du DVB, mais une seule semble
être la plus adaptée. Ces cas sont illustrés par la figure 1.2.

Figure 1.2 : solutions proposées pour le déploiement DVB



Remarque :
Les technologies de serveurs vidéo ne sont pas encore non plus tout à fait prêtes pour
permettre à de tels services de se développer. C’est pour cela que nous proposerons une
solution à base de serveur Video LAN VLC.
1.4.2 La visioconférence (UIT-T F730)
La vidéoconférence combine la voix et les données dans une communication qui peut
comporter plusieurs personnes. La seule contrainte qui a rendue cette application non
répondue auparavant était la qualité médiocre de la vidéo qui est transmise. Mais, comme
l’ADSL est devenu courant et disponible pour toutes les tranches de la société avec des débits
très élevés, la vidéoconférence est devenue une chose possible sans la présence d’immenses
obstacles techniques. De plus, la vidéo à haute définition est supportée par ces réseaux ce qui
rend cette application attractive pour le domaine de la télévision numérique.

1.5 Conclusion
Dans ce chapitre, nous avons mis l’accent sur les normes existantes pour la
transmission vidéo qui vont être utilisées dans la suite du travail et qui sont DVB-T, MPEG2-
TS et MPEG2-PS. Nous avons précisé les services qui peuvent être supportés par
l’architecture qu’on va proposer.
Dans le prochain chapitre, nous allons présenter notre apport au niveau de l’application
SAGEM_DVB_ZAP.


Chapitre 2 Architecture du système

Chapitre 2: Architecture du système

2.1 Introduction
Ce chapitre contient nos différentes contributions au déroulement du travail de
l’équipe Sagem. Nous proposons en premier lieu une description de l’environnement du
travail exigé pour pouvoir travailler avec l’équipe. En second lieu, nous allons décrire
l’application SAGEM DVB en insistant sur nos apports personnels.

2.2 Architecture de SAGEM DVB
Pour pouvoir réaliser du développement sur un décodeur à base d'une carte DVB, on
doit s'équiper de 3 ordinateurs, un switch, un minicom, une sonde, une télévision, une antenne
TNT et un décodeur. Chacun de ces composants joue un rôle particulier dans l'élaboration des
tâches de développement.

Un des ordinateurs est destiné à faire du développement pur et dur. Il doit être doté du
système d'exploitation Linux, on note que la distribution utilisée chez Sagem Communication
est Mandriva 2006. Les deux autres machines servent comme hôte pour un serveur DHCP et
un serveur VLC. Un serveur VLC permet la diffusion de la vidéo sur IP. La télévision est
utilisée comme un outil de test du flux sortant du décodeur. Le minicom permet de récupérer
sur le poste de développement les traces du noyau embarqué sur le décodeur via une interface
de communication série. Et bien sur cette plateforme comporte une carte DVB sujet de notre
projet.

La plateforme qu'on a utilisée est représentée par la Figure3.1 (Cette plateforme ne
contient pas la sonde).



PC de
développement
Série
PC ETH
WEB ETH Minicom
Péritel
ETH USB
Switcher Décodeur Caméra web
ETH
Serveur Frontend
DHCP ETH Péritel

Antenne TNT
PC Télévision
Vidéo
LAN

Figure 2.1 : Architecture générale de l’application
Par rapport à la plateforme référence, on a ajouté une webcam, car suivant les
spécifications du client, notre boite doit offrir la possibilité d'effectuer de la visioconférence.
Les connexions entre les différents composants de la plateforme ainsi que leur type sont
représentées sur la Figure2.1.
Pour accélérer les opérations de test et éviter le long processus de flashage de la boite,
l'équipe fait fonctionner cette dernière en un mode dit NFS pour Network File System. En
effet, tout l'environnement logiciel dont la boite à besoin pour fonctionner est placé sur le PC
de développement, le décodeur accède à cet ensemble de logiciel via une connexion NFS.
Pour réaliser une telle opération, il suffit de créer un espace de montage, via NFS pour le
dossier contenant les logiciels, sur l'os de la boite. Il suffit ensuite de configurer cette espace
comme la racine du système d'exploitation Linux embarqué sur le décodeur. Ainsi, le
décodeur charge dans sa mémoire des binaires contenus sur le disque dur du poste de
développement.
Donc, comme première tâche, nous avons mis en place cette plateforme. Les
paragraphes proposent une description de l’environnement logicielle de cette plateforme.



2.3 Poste de développement ST-Linux
Dans cette partie, nous décrirons le procédé générique pour installer les logiciels sur
un ordinateur principal et ceci servira pour tout le groupe pour pouvoir travailler ensemble sur
les mêmes versions et avec les mêmes bibliothèques.
2.3.1 La distribution MANDRIVA 2006.A
2.3.1.1 Présentation de la distribution MANDRIVA 2006.A
La distribution Mandriva Linux (anciennement Mandrake linux) doit une grande partie
de sa popularité à sa simplicité pour l'utilisateur final
Contrairement à beaucoup d'autres distributions de GNU/Linux, son installation est
extrêmement simple. En effet, il existe différents assistants qui se chargent d'expliquer à
l'utilisateur les notions de base, le conseillent pour des choix délicats, etc. Il est ainsi possible,
pour quelqu'un qui installe GNU/Linux pour la première fois sur un ordinateur, de s'orienter
avec facilité. Cette simplicité est se manifeste encore lors l'utilisation de ce software.
La distribution Mandriva Linux rassemble environ 3000 logiciels. Elle inclut tous les
paquetages/logiciels les plus populaires, à commencer par les bureaux GNOME et KDE, qui
permettent aux utilisateurs venant de Microsoft Windows de trouver rapidement des repères.
On note aussi que les documents créés sous Open Office avec extension .doc, .xls, .ppt sont
compatibles avec Microsoft Windows.

Pour des utilisateurs francophones, beaucoup d'informations et de programmes ont été
traduits. Mandriva Linux permet ainsi d'associer la fiabilité de GNU/Linux à la facilité de
Windows. Lors de l'installation il est, bien sur, possible de conserver son système
d'exploitation Microsoft Windows.

2.3.1.2 Installation
Pour que tout le groupe de travail soit en phase, il faut qu’ils utilisent les mêmes
versions de logiciel et les mêmes systèmes. Pour cela, il nous a fallu installer la distribution
Mandriva 2006.A. Notons que lors de l’installation, il est judicieux de suivre la
documentation de l’entreprise qui réponde aux besoins du projet.
2.3.2 Installation de ST LINUX ENVIREMENT OF DEVELOPPMENT
Dans cette étape, nous allons installer les différents paquetages STLinux, définir les
liens et les commandes pour installer les différents logiciels. Pour cela, il faut d’abord ouvrir
la session utilisateur Admin.



On commence par copier les différents logiciels et paquetages se trouvant dans trois
CD dans les répertoires correspondants.
2.3.2.1 ST- Paquetage
Il est nécessaire pour pouvoir travailler sur le set-top-box. Nous allons installer les
paquetages de ST qui se trouve dans le CDROM1 et CDROM2 et nous avons changer
l’utilisateur su et créer les chemins INSTALL/PACKAGE-ST/CDROM1 et
INSTALL/PACKAGE-ST/CDROM2.
2.3.2.2 La Sonde
La sonde permet de réaliser les opérations de flashage du set-top-box, c'est à dire
l'embarcation des travaux de l'équipe sur la mémoire du décodeur.
Pour installer le ST Micro connect probe (sonde utilisé), il suffit de faire la liaison dans le
dossier /opt qui pointe sur le dossier /home/admin/INSTALL/ST40R3.0.3. On écrit donc la
commande « ln -s /home/admin/INSTALL/ST40R3.0.3 /opt/STM »
2.3.2.3 Changement de la racine en mode NFS
Le RootFS de la cible peut être placé comme NFS, dans cette utilisation attentive la
configuration suivante d'exporter l'annuaire de cible : Comme la racine éditent le dossier
d'exportations enfin il faut redémarrer le service NFS en se situons administrateur
2.3.3 Logiciels utilisés
2.3.3.1 CSCOPE
CSCOPE est un outil interactif orienté écran qui nous aide à:
• Localiser la section de code à changer pour corriger un bug sans avoir à connaître le
programme complet,
• Examiner l'effet d'un changement envisagé, comme d'ajouter une occurrence à une
variable énumérée,
• Vérifier qu'un changement a bien été appliqué dans tous les fichiers sources, comme
d'ajouter un argument à une fonction existante,
• Renommer une variable globale dans tous les fichiers sources,
• Changer la valeur d'un symbole du pré processeur dans des lignes.
2.3.3.2 Subversion 1.1.4
Subversion (ou SVN) est un logiciel libre qui sert à visualiser toutes les modifications
de l’équipe faites afin de contrôler les versions, ce qui est très utile dans le cadre de la création
de logiciels.



2.3.3.3 JAVA SDK
J2EE est une plate-forme fortement orientée serveur pour le développement et
l'exécution d'applications distribuées. Elle est composée de deux parties essentielles :
• un ensemble de spécifications pour une infrastructure dans laquelle s'exécute les
composants écrits en java : un tel environnement se nomme serveur d'application.
• un ensemble d'API qui peuvent être obtenues et utilisées séparément. Pour être
utilisées, certaines nécessitent une implémentation de la part d'un fournisseur tiers.
J2EE permet une grande flexibilité dans le choix de l'architecture de l'application en
combinant les différents composants la partie cliente, la partie encapsulation des traitements
et la partie données.
2.3.3.4 ECLIPSE “eclipse-SDK-3.0.2”
Il s’agit d’un logiciel multi plateforme, multi langages. Par le mécanisme des plugins,
il permet de créer des applications indépendantes. Ce logiciel comprend plusieurs plugins
avancés comme :
• Interface Graphique VEP (Visual Editor Project) : Nombreux plugins commerciaux,
• Editeur d’objets graphiques GEF (Graphical Editor Framework) : Permet de gérer tout
type d’organigrammes,
• Développement embarqué : Device Software Development Platform qui gère toutes
les phases du développement d’un logiciel embarqué, de la mise au point du Hardware
et de développement du SDK,
• Analyse/Conception UML 2.0 Outils propriétaires IBM Plugin Open Source.
Dans notre étude, nous avons installé Eclipse dans le dossier
/home/admin/LOGICIELS/ ECLIPSE. Après, nous avons installé les différents plugins
nécessaires en utilisant Eclipse dans les répertoires correspondants
• CDT plugin (C/C++ Development Toolkit) dans le répertoire
/home/admin/LOGICIELS/CDT/eclipse,
• Subversion plugins for Eclipse (Site) dans le répertoire
/home/admin/LOGICIELS/SITE.

2.4 Serveur de vidéo : VidéoLan VLC
2.4.1 Description
VLC est principalement le logiciel client du projet VideoLan. Il peut être utilisé en
tant que serveur, pour diffuser des fichiers MPEG-1, MPEG-2 et MPEG-4, des DVDs, ou de
la vidéo en temps réel sur un réseau en unicast ou multicast. Il peut être aussi utilisé en tant



que client pour recevoir, décoder et afficher des flux vidéo .Dans le présent travail, nous nous
intéressons aux VLC comme serveur.
VLC tourne sur de nombreux systèmes d'exploitation : Linux, Windows, Mac OS X,
BeOS, *BSD, Solaris, Familiar Linux, Yopy/Linupy et QNX .Dans le cadre de ce projet, nous
se limitons au système Linux et Windows.

Figure 2.2 : Solution de diffusion VideoLAN
VLC est capable de lire :
• des fichiers MPEG-1, MPEG-2 et MPEG-4 / DivX depuis un disque dur, un lecteur de
CD-ROM, ...
• des DVDs et VCDs,
• depuis une carte satellite (DVB-S),
• des flux MPEG-1, MPEG-2 et MPEG-4 envoyés sur le réseau par un VLS ou un VLC.
VLC peut également être employé en tant que serveur en IPv4 ou IPv6 pour diffuser:
• des fichiers MPEG-1, MPEG-2 et MPEG-4 / DivX,
• des DVDs,
• depuis une carte d'encodage MPEG.
Vers :
• une machine (c'est à dire à une addresse IP) : ceci est appelé unicast,
• un groupe dynamique de machines que les clients rejoignent ou quittent (une addresse
IP multicast): ceci est appelé multicast .



2.4.2 Installation de VLC
Des binaires précompilés de VLC sont disponibles pour le système d’exploitation
Windows, mais pas pour Linux bien qu’il est supporté par VLC. Si nous désirons l’installer et
changer les paramètres, nous pouvons compiler VLC depuis ses sources.
2.4.2.1 Compilation des sources
Pour compiler le VLC à partir de ses sources, il est nécessaire d’avoir un certain
nombre de librairies qui doivent être requises:
• libdvbpsi (obligatoire),
• mpeg2dec (obligatoire),
• libdvdcss si nous désirons pouvoir lire des DVD encryptés,
• libdvdplay si nous désirons profiter des menus DVD,
• a52dec si nous désirions pouvoir décoder le son AC3 (A52), souvent utilisé dans les
DVDs,
• ffmpeg, libmad, faad2 si nous désirons lire des fichiers MPEG 4 / DivX,
• libogg & libvorbis si nous désirons pouvoir lire des fichiers Ogg/Vorbis.
Nous allons installer chaque librairie en suivant les étapes classiques : Décompression,
configuration, compilation et installation. Nous devons vérifier que le fichier /etc/ld.so.conf
contient la ligne: /usr/local/lib. Si elle n’existe pas, nous l’ajoutons.
2.4.2.2 Installation du VLC
Enfin, nous installons VLC à partir du fichier compressé nommé vlc-version.tar.gz.
Les étapes de l’installation sont comme d’habitude sur linux. Pour la décompression, la
configuration, la compilation et installation, nous exécutons successivement tar xvzf vlc-
version.tar.gz, cd vlc-version, ./configure, make, make install.
2.4.3 Modules et options de VLC
2.4.3.1 Modules
VLC utilise un système modulaire, ce qui permet un ajout simplifié de nouvelles
fonctions et de nouveaux formats. Lorsqu’on installe VLC par un fichier binaire, on a tous les
modules par défaut. Et on peut personnaliser VLC, pour cela on doit le compiler depuis ses
sources. On peut compiler un module qui est marqué désactivé par défaut et inversement, on
peut désactiver un module qui est activé par défaut .Chaque module VLC possède sa propre
aide et ses options.
• Modules d'entrée



Ces modules permettent à VLC de lire depuis différentes sources. VLC essaie de
choisir le module le plus adapté au moment de la lecture. Mais on peut forcer un
module particulier.
• Démultiplexeurs
Dans un flux, les signaux vidéo et audio sont toujours inclus dans un format
"conteneur". Les démultiplexeurs extraient les flux de ce conteneur et les envoient aux
décodeurs. Par exemple, un fichier AVI peut contenir une vidéo encodée en MPEG-4,
ou une vidéo non compressée. AVI est seulement un format de stockage, pas un
format de compression.
• Décodeurs
Ces modules permettent à VLC de supporter de nombreux codecs (formats de
compression).
• Modules de filtre vidéo
Ces modules permettent de modifier l'image (dés-entrelacement, réglage du trio
teinte/contraste/saturation, recadrage etc.). On peut les activer pour VLC en utilisant
l'option suivante: --filter filter1, filter2,...
• Modules de sortie audio
Ces modules permettent de choisir le système de sortie du son. VLC essaie de deviner
le module de sortie audio le plus adapté au système. On peut toutefois forcer
l'utilisation d'un module spécifique.
2.4.3.2 Options de compilation
Il y a quelques options qu’on peut régler par les scripts de configuration, qui ne sont
pas liées aux modules. Par exemple, on peut régler les répertoires d'installation et le système
sur lequel on désire compiler VLC (normalement automatique), ...
2.4.4 Méthode de diffusion VLC
2.4.4.1 Utilisation de la ligne de commande
2.4.4.1.1 Architecture modulaire
Le stream output possède une puissante architecture qui utilise des modules. Chaque
module apporte des fonctionnalités, et il est possible de chaîner les modules pour combiner
plusieurs possibilités. Voici la liste des modules disponibles :
standard :"Envoie" le flux grâce à un module de sortie: par exemple, UDP, fichier,
HTTP, ... on utilise ce module à la fin de chaînes.
transcode : Permet de transcoder à la volée l'audio et la vidéo de notre flux d’entrée.



duplicate : Permet de créer une seconde chaîne dans laquelle le flux sera traité
séparément.
display : nous permet d'afficher le flux d'entrée, comme VLC le ferait normalement.
Utilisé avec le module duplicate, il nous permet de voir le flux en même temps que
nous l’envoyons.
es : nous permet de séparer les flux élémentaires (ES) d'un flux d’entrée.
2.4.4.1.2 Syntaxe
La syntaxe employée pour la diffusion est composée de plusieurs champs qui sont le
flux d’entrée, les modules utilisés et les différentes options pour chaque module. Ce syntaxe a
la forme suivante : « vlc input_stream --sout '#module1 {option1=..., option2=...}:#module2
{option1=..., option2=...}:...' ».
L’exemple ci-dessous illustre les opérations de transcodage et d’envoi des flux :
«vlc input_stream --sout '#transcode{options}:#standard{options}' ».
Chacun de ces modules peut prendre différentes options :
• access: comment envoyer file, udp, rtp, http,
• mux: quel multiplexeur (format) utiliser ? Doit être: avi (format AVI) ogg (format
Ogg) ps (format MPEG2-PS) ts (format MPEG2-TS),
• url: Si on utilise le fichier access, url désigne l'emplacement du fichier, sinon, il s’agit
de l'adresse IP multicast ou unicast,
• sap: Cette option est utilisé dans le cas d'access udp ou rtp, on emploi celle là pour
annoncer le flux par SAP/SDP (mini serveur). L'option contient le nom sous lequel le
programme sera annoncé.
On remarque que si on utilise le multicast, on peut utiliser l'option globale –TTL t pour
régler le TTL avec les options réseaux :
• --server-port <entier> pour règler le port UDP,
• --iface <chaîne> pour spécifier l'interface réseau à utiliser,
• --iface-addr <chaîne> pour spécifier l'adresse IP de l'interface réseau,
• --mtu <entier> pour spécifier le MTU de l'interface réseau,
• --ipv6 force l'utilisation d’IPv6,
--ipv4 force l'utilisation d’IPv4.
Notons que VLC inclut un petit serveur HTTP, qui lui permet de diffuser en HTTP, et
aussi de proposer une interface de contrôle à distance utilisant HTTP. Pour démarrer VLC
avec l'interface HTTP, il faut faire : « vlc -I http (--http-src /directory/ --http-host host:port) ».



L'interface HTTP se met en écoute sur le host dont le port est 8080 par défaut et
reproduit la structure de /directory sur http://host:port/.
La diffusion d’un fichier avec VLC se fait en exécutant la commande « vlc -vvv
video1.xyz --sout udp:192.168.0.42 --ttl 12 » où video1.xyz est le fichier à diffuser,
192.168.0.42 est soit l'adresse IP de la machine vers laquelle on désire diffuser en unicast, le
nom DNS de la machine vers laquelle on désire envoyer en unicast, une adresse IP multicast.
12 est la valeur du TTL (Time To Live) des paquets IP (cela signifie qu'ils pourront traverser
11 routeurs). Si on désire diffuser un continu, il faut ajouter l'option --loop.
2.4.4.2 Diffusion facile en utilisant l’interface graphique
Le plus facile pour commencer à diffuser avec VLC consiste à utiliser l'une des
interfaces graphiques utilisateur : wxWidgets pour Windows et GNU/Linux. Deux
méthodes sont disponibles, la première c’est d’utiliser l'Assistant et la deuxième le mode
graphique.
2.4.4.2.1 Diffuser en utilisant l'Assistant
L'assistant de Diffusion/Transcodage guide pas à pas pour diffuser le média sur un
réseau ou le sauvegarder sur le disque dur. Cet Assistant fournit des menus simples à
utiliser, mais les choix d'options sont restreints.
On note que l'assistant est seulement disponible depuis l'interface wxWidgets.
Pour démarrer l'Assistant de diffusion/transcodage, on ouvre le menu "Fichier", et on
sélectionne Assistant de diffusion.

Figure 2.3 : Démarrer l'assistant
Pour commencer, on sélectionne le type de tâche :
• Diffuser vers un réseau : Choisi si on veut diffuser un média sur un réseau.
• Transcoder/Sauvegarder : Choisi si on souhaite changer le codec d'un fichier
audio et/ou vidéo, son échantillonnage et/ou sa méthode d'encapsulation.



Figure 2.4 : La boîte de dialogue de l'Assistant
Maintenant, on sélectionne un flux (tel qu'un fichier, un flux réseau, un disque, un
périphérique de capture, ...) avec le bouton Choisir, ou un élément existant de la liste de
lecture avec l'option Elément de la liste.
Il y’a dans la Figure 1.5 l’option Extraction partielle : Pour lire uniquement une
partie du flux, on coche "Activer" et on choisit un début et une fin (en secondes). Cette
option ne doit être utilisée que dans le cas de flux qu’on peut contrôler, comme des
fichiers placés dans les disques, mais pas des flux réseaux ou des périphériques de
capture.

Figure 2.5 : Sélection de l'entrée par l'Assistant



(a) (b)
Figure 2.6 : (a) Sélection de l'entrée depuis la liste de lecture par l'Assistant
(b) Sélection de l'entrée depuis fichier
Si on a choisit l'option Diffuser vers un réseau, on peut spécifier la méthode de
diffusion. Les méthodes de diffusion sont :
• UDP Unicast : Ici, il faut entrer l'adresse IP du client (dans la plage 0.0.0.0 -
223.255.255.255).
• UDP Multicast : Diffuser un flux vers plusieurs utilisateurs. Il faut entrer
l'adresse IP du groupe multicast (dans la plage 224.0.0.0 - 239.255.255.255).
Dans ce projet, on a utilisé 225.190.0.3 ou bien 225.190.1.1.
• HTTP : Diffuser en utilisant le protocole HTTP. Si on laisse le champ
Destination vide, VLC va attendre les connexions sur toutes les interfaces
réseaux du serveur sur le port 8080. On spécifie une adresse, un port et un chemin
pour les connexions en utilisant la syntaxe suivante [ip][:port][/path].
Par exemple, 192.168.0.1:80/stream va faire écouter VLC sur l'interface portant
l'adresse IP 192.168.0.1, sur le port TCP 80, dans le fichier virtuel /stream.



(a) (b)
Figure 2.7 : Méthode de diffusion par l'Assistant
(a) pour la diffusion en UDP multicast
(b) pour la diffusion en HTTP
On peut maintenant spécifier plusieurs options.
• Time To Live (TTL) : Ceci définit le nombre de routeurs que le flux peut traverser
avant d'être supprimé. Pour le multicast UDP, la valeur par défaut du TTL est 1, ce
qui signifie que le flux n'ira pas au-delà du premier routeur. On veut certainement
augmenter ce nombre si on souhaite que ce flux multicast soit routé.
• Annonce SAP : Elle sert à annoncer le flux sur le réseau. Quand on utilise une
méthode de diffusion UDP, en utilisant le protocole SAP, il faut entrer le nom du
flux dans le champ de texte et cocher la case correspondante. Ceci n’est pas
disponible pour la méthode de diffusion HTTP.



Figure 2.8 : Options de l'assistant de diffusion
Un clic sur Terminer commence la diffusion de la source.
2.4.4.2.2 Diffusion en mode graphique
Une deuxième façon de paramétrer une instance de diffusion avec VLC est d'utiliser
le menu Flux de sortie dans la boite de dialogue Ouvrir... des interfaces wxWidgets
(Windows / GNU Linux), skins (Windows / GNU Linux). Les options et les méthodes les
plus courantes de diffusion sont accessibles dans ce menu pour diffuser le media ouvert, il
faut cocher "flux de sortie" dans la boite de dialogue "ouvrir un fichier/disque/flux
réseau/périphérique de capture"et cliquer sur le bouton "paramètres".

Figure 2.9 : Diffusion du flux de sortie en mode graphique



Dans l'interface wxWidgets, un boite de dialogue affiche le MRL de flux de sortie
(Media Ressource Locator). Elle est mise à jour quand on modifie des options dans le menu
Flux de sortie.
On distingue plusieurs modes de diffusion :
• Jouer en local: affiche la diffusion à l'écran. Cela permet d'afficher le flux qu’on est
en train de diffuser. Les effets de transcodage, etc... peuvent être surveillés en local
avec cette fonction.
• Fichier: Sauvegarder la diffusion dans un fichier. L'option Dumper le flux brut
permet d'enregistrer le flux d'entrée en même temps qu'il est lu par VLC, sans aucun
traitement.
• HTTP: Pour utiliser la méthode de diffusion HTTP, il faut Spécifier l'adresse IP
ainsi que le numéro de port TCP à écouter.
• MMSH: Cette méthode d'accès permet de diffuser vers Microsoft Windows Media
Player. On doit Spécifier l'adresse IP ainsi que le numéro de port TCP à écouter.
Cela fonctionne seulement avec la méthode d'encapsulation ASF.
• UDP: Diffuse en unicast en donnant une adresse dans la gamme 0.0.0.0 -
223.255.255.255 ou en multicast en donnant une adresse dans la gamme 224.0.0.0 -
239.255.255.255 dans notre cas 225.190.0.3 ou bien 225.190.1.1. Il est aussi
possible de diffuser vers des adresses IPv6. Cela fonctionne seulement avec la
méthode d'encapsulation TS.
2.4.5 Autre solution possible pour un serveur VideoLAn : Serveur de
streaming VLS
2.4.5.1 Structure de VLS
De point de vue utilisateur, VLS peut être divisé en quatre composants majeurs:
• Un gestionnaire,

• Des entrées,

• Des convertisseurs,

• Des sorties.



Fichier Entrées Gestionnaire Réseaux
Convertisseur
DVD Fichier

Sorties

Interface d’administration

Figure 2.10. Structure de VLS
• Entrées
Le rôle d'une entrée est de lire des flux MPEG depuis une source donnée (fichier,
DVD, carte DVB, ...), et de les envoyer aux convertisseurs. Une entrée peut lire
plusieurs flux. Ceux-ci sont alors appelés des programmes. Il existe plusieurs types
d'entrées :
o L'entrée local, qui peut lire depuis des fichiers et des DVDs ,
o L'entrée vidéo, qui peut lire des vidéos depuis des cartes d'encodage MPEG,
o L’entrée dvb, qui peut lire depuis des cartes DVB,
o L'entrée v4l, qui peut lire depuis les cartes d'acquisition supportées par les
pilotes Video4Linux.
On peut utiliser plusieurs entrées et jouer plusieurs programmes en même temps.
• Les convertisseurs
Le rôle d'un convertisseur est de recevoir un flux depuis une entrée et de le convertir
au format MPEG-TS. VLS peut convertir des flux PS (provenant d'un DVD, par
exemple) en flux TS, en utilisant le convertisseur ps2ts. Bien sûr, il peut également lire
les flux TS, et les réparer en prenant en charge les discontinuités du flux (convertisseur
ts2ts).
• Les sorties
Une sortie reçoit le flux depuis le convertisseur, et l'envoie vers une destination
donnée (réseau, fichier). Actuellement, il existe deux types de sorties: network et file.
Pour l'instant, VLS ne peut utiliser qu'une sortie par flux, donc on ne peut pas diffuser
un flux sur le réseau et l'enregistrer dans un fichier en même temps. La sortie réseau
est très configurable: On peut choisir l'interface réseau, et spécifier les adresses IP
source et destination.



• Le gestionnaire
Le gestionnaire contrôle l'envoi des flux. En utilisant une interface d'administration,
on peut lancer, arrêter, interrompre, ou reprendre les programmes. On peut également
afficher la liste des programmes disponibles, lire depuis le fichier de configuration de
VLS c'est pourquoi elle ne peut pas être changée après le démarrage.
Pour l'instant, on ne peut pas demander au gestionnaire si un flux est en cours de
diffusion, mais une erreur se produira si on tente de stopper un flux qui ne l'est pas.
2.4.5.2 Interface d'administration
Il existe deux moyens de contrôler VLS : la ligne de commande, l'interface Telnet.
Lorsqu’on utilise l'interface Telnet, on doit tout d'abord s’authentifier, car tous les utilisateurs
ne peuvent exécuter toutes les commandes. Une fois que VLS a démarré, il ne prend pas
d'arguments sur son entrée standard, et on peut le mettre en tâche de fond

2.5 Application SAGEM DVB ZAPPING
Dans l’application il y a deux types de zapping : zapping de flux sur voie ip et zapping
de flux DVB-T. Cette api en cours de réalisation en langage C sous linux
2.5.1 L’API Linux DVB
La norme DVB ne se contente pas à décrire le processus que doit suivre le signal entre
les phases d’émission et de réception mais elle précise aussi l'ensemble des routines à utiliser
pour programmer et configurer le décodeur. L’ensemble de ces routines destinées au décodeur
fonctionnant avec système d’exploitation Linux, est connu sous le nom de Linux DVB API.
Une carte DVB PCI ou encore DVB set-top-box (STB) est généralement constituée de six
composants. Comme la montre la figure suivante, ces composants sont :
● Le frontend : il représente le tuner et le démodulateur de DVB. Ici le signal atteind le
matériel de DVB à partir d'une antenne parabolique ou directement du câble. Le frontend
abaisse la fréquence du signal et le démodule, ensuite, dans un flux de transport MPEG
(TS),
● Le contrôle d'accès (CA):
Le flux complet est passé par l'unité de contrôle d'accès. Les programmes auxquels
l'utilisateur a accès sont décodés en temps réel et réinsérés dans le Transport Stream (TS),
● Le démultiplexeur (Demux): Il filtre le flux entrant. Le démultiplexeur découpe le
transport stream suivant ses composants comme les stream audio et vidéo. En plus de ce
flux, se rajoutent des flux de données contenant des informations sur les programmes
offerts dans ce flux ou dans d'autre flux du même fournisseur,



● Décodeurs MPEG de l'audio et de la vidéo : Le flux démultiplexé passe ensuite dans les
décodeurs MPEG audio et vidéo dont le traitement est spécifique à chaque flux. Après leur
décodage et décompression, les flux passent soit à l'ordinateur soit au poste de télévision
via l'interface PAL/NTSC.

Anten Frontend CA Demux

SEC Vidéo Audio

TV
Figure 2.11 : Structure d’une carte Linux DVB
En pratique, une carte DVB ne doit pas contenir impérativement tous ces composants.
Par exemple, les tâches de décodage et de décompression MPEG peuvent être déléguées à
l'unité de calcul de l'ordinateur. De même la partie chargée du contrôle d'accès peut être
incluse ou non dans le décodeur.
2.5.2 Logique du travail
Le souci initial de l’équipe du travail est de réaliser au moins une partie dans le projet
qui soit fonctionnelle. Toutes les tâches sont susceptibles à des éventuelles modifications pour
aboutir finalement à un projet optimal qui satisfait le client en répondant à son spécification.
En effet, divers tests peuvent montrer des défaillances. Nous avons programmé les tâches qui
vont suivre avec le langage C. Ce dernier est caractérisé par sa rapidité d’exécution. Les
paragraphes suivants résument la fonctionnalité de quelques programmes dont j’ai contribué à
la réalisation et l’amélioration.
2.5.2.1 Chargeur générique de modules
L’équipe Sagem sont habitués à charger les différents modules du décodeur
manuellement, en exécutant des commandes. Nous avons automatisé cette tâche par
implémenter un algorithme. L’entrée de cet algorithme est une liste de module et de leur type
(ST, SAGEM_DVB_ZAP). Après, le chargement des modules s’effectue suivant leur type.
Cet algorithme vérifie aussi s’il y a des modules manquants.


Dardouri ghazi

Recomendados

Recomendados

Más contenido relacionado

Similar a Dardouri ghazi

Similar a Dardouri ghazi (20)

Dardouri ghazi