Post on 28-Nov-2014
description
1
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
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
Projet de fin d’études 2005-2006 1
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
Introduction générale
Projet de fin d’études 2005-2006 2
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
Projet de fin d’études 2005-2006 3
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 à
Chapitre 1 État de l’art
Projet de fin d’études 2005-2006 4
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.
Chapitre 1 État de l’art
Projet de fin d’études 2005-2006 5
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].
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
Codage MPEG
Codage MPEG
Multiplexage + embrouillage
FEC, formatage, DAC
Modulation Elévation de fréquence
Prog 1
Prog n
PES
PES
Paquet 188 oc I, Q FI
Support de transmission
Abaissement de fréquence
Démodulation FEC, formatage, DAC
Multiplexage + embrouillage
Codage MPEG
PES Paquet 188 oc I, Q FI
Image + Son
Codage /Décodage de la source Codage /Décodage du canal
1
2 3 45
6
789 10
Chapitre 1 État de l’art
Projet de fin d’études 2005-2006 6
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).
Chapitre 1 État de l’art
Projet de fin d’études 2005-2006 7
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.
Chapitre 1 État de l’art
Projet de fin d’études 2005-2006 8
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:
Chapitre 1 État de l’art
Projet de fin d’études 2005-2006 9
-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.
Chapitre 1 État de l’art
Projet de fin d’études 2005-2006 10
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
Chapitre 1 État de l’art
Projet de fin d’études 2005-2006 11
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
Chapitre 1 État de l’art
Projet de fin d’études 2005-2006 12
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.
Chapitre 1 État de l’art
Projet de fin d’études 2005-2006 13
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
Chapitre 1 État de l’art
Projet de fin d’études 2005-2006 14
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
Chapitre 1 État de l’art
Projet de fin d’études 2005-2006 15
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
Projet de fin d’études 2005-2006 16
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).
Chapitre 2 Architecture du système
Projet de fin d’études 2005-2006 17
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.
Décodeur
Télévision
Caméra web
PC de développement
PC WEB
Serveur DHCP
PC Vidéo LAN
Switcher
Minicom
Antenne TNT
ETH ETH
ETH
ETH
ETH
Série
Péritel
Péritel
USB
Frontend
Chapitre 2 Architecture du système
Projet de fin d’études 2005-2006 18
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.
Chapitre 2 Architecture du système
Projet de fin d’études 2005-2006 19
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.
Chapitre 2 Architecture du système
Projet de fin d’études 2005-2006 20
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
Chapitre 2 Architecture du système
Projet de fin d’études 2005-2006 21
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 .
Chapitre 2 Architecture du système
Projet de fin d’études 2005-2006 22
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
Chapitre 2 Architecture du système
Projet de fin d’études 2005-2006 23
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.
Chapitre 2 Architecture du système
Projet de fin d’études 2005-2006 24
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) ».
Chapitre 2 Architecture du système
Projet de fin d’études 2005-2006 25
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.
Chapitre 2 Architecture du système
Projet de fin d’études 2005-2006 26
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
Chapitre 2 Architecture du système
Projet de fin d’études 2005-2006 27
(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.
Chapitre 2 Architecture du système
Projet de fin d’études 2005-2006 28
(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.
Chapitre 2 Architecture du système
Projet de fin d’études 2005-2006 29
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
Chapitre 2 Architecture du système
Projet de fin d’études 2005-2006 30
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.
Chapitre 2 Architecture du système
Projet de fin d’études 2005-2006 31
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.
Entrées Gestionnaire Convertisseur
Sorties
Fichier DVD
Réseaux Fichier
Interface d’administration
Chapitre 2 Architecture du système
Projet de fin d’études 2005-2006 32
• 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,
Chapitre 2 Architecture du système
Projet de fin d’études 2005-2006 33
● 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.
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.
Frontend CA Demux
Vidéo Audio SEC
Anten
TV
Chapitre 2 Architecture du système
Projet de fin d’études 2005-2006 34
2.5.2.2 API infra rouge
Pour zapper, nous avons développé deux méthodes qui utilisent l’infra rouge. La
première étant le zapping avec le clavier Sejin, la deuxième est le zapping avec la
télécommande.
Dans chaque cas, nous avons spécifié le code hexadécimal associé à chaque bouton de
manipulation du matériel considéré. Puis, nous avons chargé les drivers du matériel. Ici, nous
avons pris en compte le zapping pour les différents types de flux.
2.5.2.3 API de test
Pour cette api, nous avons écrit trois programmes. Le but du premier est le test de la
vidéo et la manipulation de la lecture de la vidéo. Avec le deuxième, nous sommes capables
de faire de test de DVB, mais aussi, nous pouvons visualiser les paramètres de différentes
chaînes TV et mode de transmission. La dernière est un test de zapping, l’ouverture de
périphérique, la création des liaisons et la sélection de la source sont aussi possibles.
2.6 Application FREEVO 2.6.1 Présentation de Freevo
Freevo est une interface graphique écrite en python qui permet de contrôler les
fonctionnalités multimédia de Linux sur une télé. Les principales fonctionnalités de Freevo
sont :
• Télé avec enregistrement,
• DVD, Divx, videos,...
• CD Audion, MP3, ...
• Slideshow d’images,
• Télécommandable.
Avec Freevo, on peut créer aussi un centre multimédia avec un PC classique :
• Lecteur de divx,
• Lecteur de DVD (si le PC possède un lecteur DVD),
• Regarder la télévision (si le PC possède une carte TV),
• Lecteur mp3, ogg, etc,
• Visionneur de photos,
• Lecteur de flux rss (si le PC est connecté à Internet),
• La météo (si le PC est connecté à Internet),
• Lecteur de webradios (si le PC est connecté à Internet).
Chapitre 2 Architecture du système
Projet de fin d’études 2005-2006 35
Actuellement, Freevo soutient le câble analogue traditionnel, mais ne soutient pas
encore le service de télévision par satellite.
L’avantage de Freevo est que tout est greffon, tout peut être active ou désactive. Il
possède donc une grande qualité d’options mais n’oblige pas à installer celles non utilisées,
détail utile pour une configuration linux embarqué avec une occupation mémoire du système
qui n’est pas une ressource inépuisable. Elle peut être contrôlée aussi bien au clavier qu’avec
une télécommande, elle peut être utilisé sans TV simplement sur ordinateur classique, ce qui
facilitera sa mise en place.
Figure 2.12 : Interface Freevo
2.6.2 Les dépendances de Freevo Freevo a un grand nombre de dépendances. En effet, son déploiement nécessite
l’installation de tous ces logiciels mentionnés ci-dessous.
• Python
Python 2.3, Pygame, mmpython, PyXML, Egenix(python-mx-base), PIL (Python Image
Library), Python Twisted, Numeric.
• Python Plugin Modules
TwistedWeb ,libexif ,SDL ,SDL_Mixer ,SDL_ttf ,SDL_image ,Freetype ;smpeg 4.4 ;jpgtran;
aumix ;lsdvd ;libdvdread ;libdvdcss,
• Applications coeur
tvtime ;MPLAYER ;Xine-0.9.22 or newer,
• Perl Modules (optionel, seulement pour xmltv )
LWP ;XML::Twig ;XML::Parser ;XML::Writer Date::Manip.
Chapitre 2 Architecture du système
Projet de fin d’études 2005-2006 36
Figure 2.13 : Logiciels requis pour l’installation de Freevo
2.6.3 Installation de Freevo Un répertoire Freevo a été créé pour regrouper tous les programmes. Freevo utilise
MPLAYER de manière intensive (pour la TV, pour les MP3, pour les vidéos, pour le VCR).
De plus, Freevo propose le téléchargement des RPM/TGZ suivants :
• freevo-X.X.X-1.src.rpm : Les sources de l'ensemble (apps+runtime+freevo), à
installer via RPM,
• freevo-X.X.X.tgz : de même, mais en TGZ,
• freevo-boot-X.X.X-1.i386.rpm : Scripts pour bootter directement avec Freevo,
• freevo-src-X.X.X.tgz : le TGZ des scripts Python de Freevo,
• freevo-testfiles-X.X.X-1.i386.rpm : Les fichiers de test (audio/vidéo) de Freevo,
permettant un test rapide après l'installation. Installé par défaut en
/usr/local/freevo/testfiles. 2.6.4 Configuration générale
Freevo se fonde sur les outils externes et les programmes pour ses fonctions. Par
exemple, il appelle Xine ou MPLAYER pour montrer les vidéos et la TV, lirc pour tracer des
fonctions à distance etc.
python
pygame/python-game
mmpython
python-xml
python-imaging/PIL
python-twisted
pyXML-0.8.4
imaging-1.1.5
twisted-1.3.0
mmpython-0.4.9
python-game-1.6
python-2.3.5
numeric 24.2
smpeg 0.4.3
SDL_ttf 2.0.7
SDL-1.2.9
Logiciels Versions Sous dépendances
Chapitre 2 Architecture du système
Projet de fin d’études 2005-2006 37
La configuration de Freevo est gérée par trois fichiers principaux : freevo_config.py,
local_conf.py et freevo.conf, les deux placé à la racine.
• freevo.conf :
Contient quelques informations de base sur notre système, comme chemins aux programmes
importants, le type de notre affichage (X11 ou framebuffer), la résolution de notre écran et
d'autres choses. Il sera produit par l'installation de Freevo de commande.
• freevo_config.py
Ce fichier contient tous les paramètres par défaut de Freevo, mais il ne doit pas être modifié
en local Si nous souhaitons changer un paramètre, nous le copions dans le fichier
local_conf.py et nous l’éditons.
• local_conf.py
Nous allons tenter de passer en revue les principaux paramètres de ce fichier, le son, Auto-
montage du/des CDROM/DVD, ajout de nouvelles commandes, activation des fonctions et
autres plugins, la sortie vidéo Freevo_config.py. Nous pouvons faire des tests en remplaçant
'noia' par d'autres fichiers FXD du même répertoire (info.fxd, blue1.fxd, ...).
2.7 Décodeur STBLinux La plateforme logicielle utilisée pour ce projet est centré sur le système d'exploitation
Linux. En effet comme le montre la figure suivante, cette plateforme se compose de deux
mondes: le monde user et le monde Kernel.
Figure 2.14 : Plateforme logicielle
DVB_SAGEM_ZAP Freevo
Linux Kernel 2.6
Pile TCP/IP et DHCP Drivers ST
Drivers Sagem
Architecture ST 7100
Monde Kernel
Linux DVB API
Monde User
Chapitre 2 Architecture du système
Projet de fin d’études 2005-2006 38
Le monde user est constitué essentiellement de l'application DVB_Sagem_Zap qui
permet de configurer et d'utiliser les différentes fonctionnalités offertes par le décodeur.
Le mode kernel se devise lui en deux ensembles majeur d'application. Le premier contient le
noyau du système d'exploitation et les options qui vont avec tels que la pile TCP/IP et le
programme permettant de gérer la partie client du protocole DHCP.
Le deuxième est constitué essentiellement des drivers. Ces drivers se divisent eux
aussi en deux ensembles. Le premier ensemble est formé par les drivers ST c'est à dire fourni
par ST Microélectronique, l'entreprise qui fourni le hardware du décodeur. L'ensemble de ces
drivers et le noyau du système forme la distribution Linux dite STLinux. Cette distribution
est maintenue et mise à jour par ST Microélectronique. La deuxième partie de cet ensemble
est constituée des drivers Sagem. Ces drivers Sagem constituent la couche applicative qui
fonctionne juste en dessus de la couche des drivers ST qui sont des drivers de bas niveau.
La dernière partie de l'ensemble des applications est la couche Linux DVB. Cette couche se
situe entre le monde user et le monde kernel et c'est elle qui fournit l'ensemble des api Linux
DVB au monde user.
A cet ensemble d'application s'ajoute une multitude de script réalisée par Sagem pour
faciliter le développement et l'application du processus Extreme Programming. Pour cela,
l'équipe dispose d'un ensemble de script permettant la mise à jour, la compilation croisée et le
flashage des applications. Elle dispose aussi d'applications facilitant la mise en marche et la
configuration du mode de fonctionnement en NFS.
2.8 Conclusion Ce chapitre illustre bien notre intégration à l’équipe SAGEM. Les différentes
applications abordées dans ce chapitre constituent une véritable occasion pour nous pour
mieux comprendre plusieurs aspects pratiques dans le domaine de multimédia et pour bien
nous entraîner au travail d’équipe de recherche et développement.
Nous aborderons dans le chapitre suivant la suite de notre travail qui représente une étude
d’anticipation de la partie contrôle d’accès qui représente une phase future pour le projet
SAGEM_ DVB.
Chapitre 3 Contrôle d’accès
Projet de fin d’études 2005-2006 39
Chapitre 3: Contrôle d'accès
3.1 Introduction Le contrôle d’accès est une phase d’anticipation programmée dans les travaux futurs
de SAGEM. Pour cela, une étude préalable de cette fonction est jugée nécessaire. A cette fin,
nous allons voir d’abord les différentes techniques existantes pour le contrôle d’accès. Après,
nous allons évoquer le protocole SSL qui peut être envisagé comme solution pour effectuer
cette tâche. Enfin nous proposons une solution et un outil pour appliquer le contrôle d’accès.
3.2 Méthodes et protocoles pour le contrôle d’accès 3.2.1 Méthodes existantes de contrôle d’accès
Au cours de cette de partie du projet, nous allons décrire deux méthodes existantes
pour le contrôle d’accès, la première est celle avec carte à puce et la seconde sans carte à puce
où il y’a un serveur DRM pour acquérir les droits d’accès.
3.2.1.1 Solution avec carte à puce
3.2.1.1.1 Cartes à puce et domaines d’applications
Les cartes à puce sont apparues vers les années 80 et envahissent la plupart des
secteurs de notre vie :
• dans le domaine public : on cite les permis de conduire électroniques et les cartes d’aide
sociale, les cartes de sécurité sociale.
• Dans le domaine privé :
Télécommunications : les cartes GSM.
Monétique : les cartes bancaires dont les applications vont du débit, crédit,
« purses électroniques », aux programmes de loyauté aux grands magasins.
Sécurité : les cartes d’accès à un système informatique ou aux bâtiments.
Péages : TV payant, décodeurs des chaînes satellites.
Aujourd'hui, c’est la course aux cartes multi-prestataires (appelées aussi
multifonctions, multi-applications, multi-branded, multi-issuer...). Quelle que soit la
Chapitre 3 Contrôle d’accès
Projet de fin d’études 2005-2006 40
nomenclature, la tendance est de remplacer les cartes dans notre portefeuille par une carte
unique sur laquelle coexistent plusieurs applications appartenants à plusieurs institutions.
Mais il y a deux contraintes :
contrainte technique : on est limité à 25 mm2 de puce encartée selon le standard
ISO-7816. Mais le progrès technique est promettant, on est maintenant à 30 k
Octets d’EEPROM. Il y a aussi d’autres solutions : cartes à multi-puces , carte
optique à puce (ISO-11693/4), carte à puce avec barres codées bi-
dimensionnelles ou carte à puce ayant un certain disque souple encastré .
contrainte logistique : les conséquences de perte d’une carte contenant trop
d’informations sont graves : il faut du temps et des nerfs d’acier pour récupérer le
récupérable (carte de crédit, permis de conduire, assurance maladie, ...) et on perd
l’irrécupérable.
L’industrie de télécommunications déploie la majorité des cartes à puces pour
l’utilisation en GSM, radio mobile et PCS (personal communication service) et pour la
diffusion TV payante. En effet cette carte sert à l’identification sécurisée et peut ainsi être
utilisée comme solution pour assurer l’accès à la télévision à travers un décodeur.
3.2.1.1.2 Diverses architectures des cartes à puce existantes
Architecture de la carte à puce à micro contrôleur
C’est la carte intelligente (Smart Card SC), elle a un microprocesseur 8 bits (il y a des
prototypes à 32 bits GemXpresso par exemple), une mémoire RAM (128 à 256 octets), ROM
(contenant des programmes fixes, c’est le DOS de la carte), EEPROM (de 1 jusqu’à 64 k
octets, c’est le Hard disc de la carte) et un port E/S appelé UART (Universal Asynchronous
Receiver/ Transmiter) qui communique avec le monde extérieur selon des protocoles
standardisés par l’ISO .
La Figure suivante montre les éléments principaux d’une puce (25 mm2 ) :
Chapitre 3 Contrôle d’accès
Projet de fin d’études 2005-2006 41
Figure 3 .1 : Eléments principaux d’une puce
Les questions posées pour choisir une puce convenable :
• type et utilisation des mémoires (RAM, ROM, EEPROM).
• protocoles de communications
• vitesse (débit)
• nécessité d’un co-processeur.
• choix de l’OS.
• choix du masque (la partie de l’application résidente dans le ROM).
Pour obtenir le maximum de fonctionnalités dans une surface de puce bien limitée, il
faut trouver un compromis de choix entre différents types de mémoires (on ne peut pas avoir
tout), mais un co-processeur est équipé d’une ROM et un masque.
Les commandes ISO d’une telle carte sont normalisées.
Architecture de la carte à puce à mémoire
Les cartes à mémoires ou synchrones étaient conçues pour emmagasiner des
informations ou des valeurs, elles sont utilisées pour des applications tels que cartes de
téléphones prépayées :
• Télécarte T1G : c’est la télécarte actuelle en France, elle est équipée par l’une des
puces suivantes : ET1001 (1983), TMS3561 (1986) de Texas ou TS1001 (1987) de
SGS-Thomson. Toutes ces puces sont à 8 contacts.
• Télécarte T2G (2ème génération) : France Télécom a imaginé en 1989 de passer en
CMOS, après une phase d’expérimentation sur 100000 cartes fin 1993, l’adaptation de
l’ensemble du parc de publiphone à cartes est maintenant achevée.
Vdd
ROM
OS, Mask. RAM
scratch pad
EEPROM
répertoires, fichiers, codes, données, clés.
CPU
coprocesseur Entrée/Sortie programmable
Tempo.
RESET
CLK
Vss
E/S 1 E/S 2 (option)
Chapitre 3 Contrôle d’accès
Projet de fin d’études 2005-2006 42
Exécutée à l’insu de la plupart des usagers, cette opération se traduira un jour par la
péremption des T1G encore en circulation.
Ces nouvelles Télécartes sont équipées d’une puce ST1332 ou ST1303 (Thomson) à 6
contacts, sa mémoire est du type EEPROM (celle de T1G est EPROM).
Grâce à un mécanisme d’authentification par certificat et calcul de signature à partir
des clés secrètes internes, la T2G est plus sûres que la T1G.
• La 3ème génération est apparue au Canada et aux états unis (toujours sans
microprocesseur). Une telle carte fournit au lecteur du téléphone un PIN, et c’est
l’opérateur concerné (AT&T, MCI, Bell, ...) qui va authentifier la carte et procéder à
la décrémentation.
3.2.1.1.3 Opérations supportées par les cartes à puce
Une carte à puce conforme EMV supporte les opérations suivantes :
• Sélection d’une application : la carte doit avoir au moins 6k ROM, 3k EEPROM et
128 RAM pour qu’elle puisse supporter une deuxième application.
• Options de traitement : en utilisant les données propriétaires de l’émetteur qui se
trouvent dans un ADF, la carte peut refuser une transaction en jugeant son type ou la
somme mise en jeu.
• Vérification du détenteur de la carte : possibilité de vérifier le PIN en mode off line
(locale c'est-à-dire non connectée au réseau) et possibilité de bloquer et de débloquer
une application sur la carte (chaque application a son propre PIN).
• Authentification statique : si la mémoire est suffisante pour stocker le certificat de la
clé publique de l’émetteur et les données signées de l’application. Sinon la
transaction doit se faire on-line.
• Authentification dynamique : quelle que soit la taille de la mémoire, mais la carte a
éventuellement besoin d’un co-processeur pour signature RSA.
• Gestion de risque de la carte : La carte peut faire passer la transaction en mode on-
line quand la somme atteint un plafond ou si le nombre de transactions offline
consécutives dépasse une certaine limite. Ceci permet à l’émetteur de faire sa gestion
de risque indépendamment du terminal et en plus la carte peut garder une certaine
somme « open to buy » en mode off line.
• Cryptogrammes d’application : le chiffrement à clé secrète reconnu et utilisé par
l’EMV est le DES.
Chapitre 3 Contrôle d’accès
Projet de fin d’études 2005-2006 43
3.2.1.2 Solution sans carte à puce (décodeur)
3.2.1.2.1 Architecture du système adopté pour le contrôle d’accès
La solution sans carte à puce est appliquée dans des cas précis. Elle devient très
courante pour le cas de services qui ne nécessitent pas d’un abonnement au préalable comme
VOD (Video On Demand) vidéo à la demande ou bien pour le cas de la télévision à la
demande. L’architecture considérée [4]pour le déploiement de ces systèmes est illustrée par la
Figure 3.2.
Figure 3.2 : Contrôle d’accès sans carte à puce pour le cas des services VOD et TV à la
demande
Dans ce cas on peut acquérir les droits d’accès on-line pour choisir accéder aux medias
3.2.1.2.2 Transactions STB serveurs
Les principales transactions pour le contrôle d’accès entre le décodeur et les différents
serveurs sont illustrées par la Figure 3.3.
Chapitre 3 Contrôle d’accès
Projet de fin d’études 2005-2006 44
Figure 3.3: transactions entre STB et les serveurs de l’architecture d’accès
Les phases en question sont :
• Phase1 : Requête pour le demande de service (Vidéo ou télévision).
• Phase2 : Consultation des droits sur le contenu choisi par le client entre serveur
media et serveur DRM.
• Phase3 : Présentation des droits en question pour le contenu demandé pour le
client.
• Phase4 : Acceptation ou refus des conditions proposées.
• Phase5 : dans le cas d’acceptation des conditions portant sur l’acquisition des
droits, le client se verra délivrer des paramètres d’accès pour lui permettre de
visualiser le contenu multimédia escompté.
• Phase6 : Accéder au contenu (flux vidéo).
3.2.2 Le protocoles SSL
3.2.2.1 Présentation générale du protocole SSL
Le protocole SSL (Socket Secure Layer) est un protocole généraliste mais qui est
actuellement très utilisé dans les applications dites de commerce électronique. SSL avait été
intégré en 1994 dans le navigateur de Netscape pour sécuriser les échanges sur un réseau
ouvert tel que l'Internet entre un client et un serveur.
La première version publique était la version 2.0, la version 1.0 ayant été testée en interne par
les employés de Netscape. La version 3.0, actuellement en vigueur, a remédié aux quelques
défaillances qui ont été découvertes dans la version précédente[5].
STB Serveur media
Serveur de DRM
1
23
4 5
6
Chapitre 3 Contrôle d’accès
Projet de fin d’études 2005-2006 45
3.2.2.2 Fonctionnement du protocole SSL
3.2.2.2.1 Position de SSL dans la pile protocolaire
SSL sécurise les échanges entre un client et un serveur d'une manière transparente en
se plaçant entre les couches application et transport. Par rapport au modèle de référence OSI,
on pourrait à la rigueur qualifier SSL de «protocole de présentation».
La Figure 3.4 illustre l'emplacement de SSL dans l'empilement des protocoles TCP/IP.
Figure 3.4 Modèle de fonctionnement de SSL
La Figure 3.5 montre la correspondance entre SSL et les différents protocoles de
l'Internet. SSL n'opère pas au dessus du protocole de transport UDP (User Datagram
Protocol), car la fiabilité du transport de ce dernier laisse à désirer. Aussi, les interruptions de
flux qui résulteraient des pertes de paquets IP seraient interprétées comme des brèches de
sécurité entraînant l'interruption de la communication.
Figure 3.5 Position du protocole SSL au sein de la pile TCP/IP
Chapitre 3 Contrôle d’accès
Projet de fin d’études 2005-2006 46
3.2.2.2.2 Les apports de SSL
La communication est confidentielle. A l’issue de la phase de négociation, les parties
en présence disposent d’une clef secrète à usage unique utilisée pour le chiffrement
symétrique (DES RC4, …) de la suite des échanges.
Les parties peuvent s’authentifier en utilisant leurs clefs publiques et des algorithmes
de chiffrement asymétriques (RSA, DSS, …). L’intégrité des échanges est garantie par
l’emploi d’une empreinte numérique (SHA, MD5, …).
3.2.2.2.3 Les sous protocoles de SSL
Le protocole SSL comporte 4 sous-protocoles:
1- Le protocole Handshake;
2- Le protocole Record;
3- Le protocole ChangeCipherSpec;
4- Le protocole Alert ;
La Figure 3.6 illustre l'agencement des différentes composantes. On voit que le
protocole Record se place au-dessus de la couche transport, tandis que les trois autres
protocoles se situent entre l'application et la couche Record.
Figure 3.6 Empilement des sous-couches protocolaires de SSL
Le protocole Handshake est chargé de l'authentification des parties en communication,
de la négociation des algorithmes de chiffrement et de hachage et de l'échange d'un secret, le
PreMasterSecret. Le protocole ChangeCipherSpec a pour fonction de signaler à la couche
Record toute modification des paramètres de sécurité. Enfin, le protocole Alert signale les
Chapitre 3 Contrôle d’accès
Projet de fin d’études 2005-2006 47
erreurs rencontrées pendant la vérification des messages ainsi que toute incompatibilité qui
pourrait éventuellement survenir pendant le Handshake.
Le protocole Record met en oeuvre les paramètres de sécurité négociés pour protéger
les données d'application ainsi que les messages en provenance des protocoles Handshake,
Change CipherSpec (CCS) et Alert.
3.2.2.3 Le protocole Handshake
3.2.2.3.1 Fonctionnement général
Le protocole Handshake commence par l'authentification obligatoire du serveur, celle
du client étant facultative. Une fois l'authentification établie, les deux parties passent à la
phase de négociation afin de choisir la suite de chiffrement qui sera utilisée tout le long de la
session.
Le protocole Handshake, on le voit, conditionne l'ensemble du processus de transfert
sécurisé de données, raison pour laquelle cette phase sera la cible privilégiée des agresseurs
potentiels.
Figure 3.7 Messages échangés pendant l’établissement d’une nouvelle session
3.2.2.3.2 Ouverture d'une nouvelle session
L'ouverture d'une nouvelle session à l'initiative du client commence par l'envoi du
message ClientHello au serveur. Le serveur peut aussi prendre l'initiative en envoyant le
message HelloRequest qui ne contient aucune information et sert exclusivement à notifier le
client que le serveur est prêt. Les échanges suivants se déroulent de la même manière dans les
deux cas.
Chapitre 3 Contrôle d’accès
Projet de fin d’études 2005-2006 48
La Figure 3.8 reprend en condensé les échanges effectués durant l'ouverture d'une
nouvelle session. Ces échanges comportent quatre étapes qui se rapportent aux opérations
suivantes:
• l'identification des suites de chiffrements disponibles des deux côtés;
• l'authentification du serveur;
• l'échange de secrets;
• la vérification et confirmation des messages échangés.
Figure 3.8 Echanges pendant l’ouverture d’une session
3.2.2.3.3 Authentification du serveur
Dans cette deuxième phase, le serveur s'authentifie en envoyant le message Certificat.
Si le serveur ne possède pas de certificat, à la place du message Certificate, il transmet le
message ServerKeyExchange. Cependant, les serveurs du commerce électronique ont intérêt à
être authentifié. Même si le serveur présente un certificat, il peut être conduit à transmettre un
message.
3.2.2.3.4 Ouverture d'une connexion
L'ouverture de la première connexion d'une session SSL ramène au cas de l'ouverture
d'une session traitée plus haut. Si la session SSL a déjà été établie, ce qui signifie que les flux
TCP peuvent transiter dans les deux sens, l'ouverture d'une connexion consiste à rafraîchir les
paramètres client_random et server_random à l'aide des messages ClientHello et ServerHello,
tout en préservant les algorithmes de chiffrement et de hachage déjà choisis.
Chapitre 3 Contrôle d’accès
Projet de fin d’études 2005-2006 49
Une nouvelle authentification est donc évitée mais, contrairement à ce qui se passe
pendant l'ouverture d'une session, les messages ClientHello et ServerHello sont envoyés
chiffrés. Les échanges sont illustrés dans la Figure 2.9.
Figure 3.9 Messages échangés pour l’ouverture d’une connexion
Le message ClientHello contient l'identificateur de la session qui contiendra la
connexion. Si cet identificateur ne figure pas dans les tables du serveur, soit parce qu'il est
erroné ou parce que le session à laquelle il renvoie ait expirée, le client n'est pas rejeté et le
serveur entame un Handshake complet afin d'établir une nouvelle session SSL.
Le client et le serveur confirment leur accord par l'envoie du message
ChangeCipherSpec de chaque côté et terminent le Handshake abrégé par le message Finished
comme précédemment.
3.2.2.4 Le protocole ChangeCipherSpec (CCS)
Le protocole ChangeCipherSpec (CCS) comprend un seul et unique message, du
même nom que le protocole, et qui tient sur un octet. Il a pour objectif d'indiquer au protocole
Record la mise en place effective des algorithmes cryptographiques qui viennent d'être
négociés afin qu'il entame le chiffrement.
3.2.2.5 Le protocole Record
Le protocole Record n'intervient, comme on vient de le voir, qu'à la suite de l'émission
du message ChangeCipherSpec. Pendant la phase d'établissement de la session, le rôle de la
Chapitre 3 Contrôle d’accès
Projet de fin d’études 2005-2006 50
couche du protocole Record est d'encapsuler les données du Handshake et de les transmettre
sans aucune modification vers la couche du protocole TCP.
Pendant la phase de chiffrement des données, le protocole Record reçoit les données
des couches supérieures (Handshake, Alert, CCS, HTTP, ftp, etc., et les transmet au protocole
TCP après avoir effectué dans l'ordre les tâches suivantes :
1. La fragmentation des données en blocs de taille maximum 214 octets ;
2. La compression des données, fonction prévue mais non supportée actuellement ;
3. La génération d'un condensât pour assurer le service d'intégrité ;
4. Le chiffrement des données pour assurer le service de confidentialité.
Les tâches inverses sont effectuées du côté récepteur: déchiffrement, vérification de
l'intégrité, décompression et recomposition.
Figure 3.10 Fonctions effectuées par la couche Record
3.2.2.6 Le protocole Alert
Le protocole Alert sert essentiellement à générer des messages d'alerte suite aux
erreurs de parcours, et à signaler les changements d'état tels que la fermeture d'une connexion.
Comme tout autre message provenant des couches supérieures, les messages sont chiffrés
avec les attributs de chiffrement en vigueur.
Selon la gravité de la menace, l'alerte peut constituer un simple avertissement ou
déclencher l'abandon de la session. Un message d'avertissement est une simple mise en garde
qui n'exige aucune action particulière. Par contre, à la suite d'un message fatal, l'entité
émettrice doit clore promptement la connexion sans attendre l'acquittement du récepteur. De
Chapitre 3 Contrôle d’accès
Projet de fin d’études 2005-2006 51
son côté, le récepteur, quant à lui, ferme la connexion dès l'arrivée du message d'alerte.
Comme les messages de niveau «fatal» causent l'abandon d'une session, SSL est susceptible
aux attaques du type «déni de service», si un intrus parvient à substituer aux messages
réglementaires d'autres non conformes, provoquant de la sorte la rupture de la session.
Le protocole Alert peut être invoqué:
• par l'application, par exemple pour signaler la fin de connexion;
• par le protocole Handshake suite à un problème survenu au cours de son
déroulement;
• par la couche Record directement, par exemple si l'intégrité d'un message est mise
en doute.
3.3 Solution proposée
3.3.1 Méthode de contrôle d’accès proposée pour le cas avec carte à puce 3.3.1.1 Services et fonctionnalités offertes par la carte à puce
La carte à puce offre plusieurs services et possède une multitude de fonctionnalités.
Elle est introduite comme une plate-forme de stockage et de traitement. Elle peut être
présentée comme une plate-forme dotée des fonctions pour rendre des services (voir le tableau
3.1).
Fonctions →
Services↓
Chiffreme
nt
Signature Contrôle
d’accès
Intégrité Authentificat
ion mutuelle
Bourrage
Authentificati
on
X X X
Contrôle
d’accès
X
Confidentialit
é
X
Secret du flux X X
Intégrité X X X
Non
répudiation
X X
Tableau 3.2 Liste exhaustive des services de sécurité et des fonctions permettant de les assurer
[LAM 89]
Chapitre 3 Contrôle d’accès
Projet de fin d’études 2005-2006 52
3.3.1.2 Utilisation de la carte a puce
3.3.1.2.1 Authentification de la carte par le décodeur
La carte utilisée doit être valide. Quelqu’un peut utiliser une carte qui n’est pas
conforme aux spécificités du décodeur ou qui est utilisée pour une autre application pour
essayer d’accéder aux services. Ainsi, il est nécessaire d’authentifier la carte par le décodeur.
Ceci peut se faire grâce à l’insertion d’informations confidentielles sur la carte qui
soient propres au fournisseur du media et ainsi on peut garantir l’authentification de la carte.
Ceci est le cas de la plupart des applications dans les secteurs monétaires comme les banques
et les applications Télécoms (authentification de l’opérateur lors de l’insertion de la carte).
3.3.1.2.2 Sécurisation de l’accès au media
Dans le but de restreindre l’utilisation de la carte à son porteur légitime, il est
nécessaire de s’authentifier auprès du décodeur avant toute demande de service. Ceci peut se
faire par l’insertion d’un code confidentiel par l’utilisateur qui réussit ainsi à garantir une
limitation de l’accès à lui-même ou à toute personne qu’il a autorisée au préalable. On peut
ajouter l’option qui limite l’insertion des codes à un nombre limité de fois sous peine de voir
le décodeur bloqué momentanément. Ceci peut résoudre les problèmes en cas de vol de la
carte et d’essai de découverte du code.
3.3.1.2.3 Authentification de l’accès : validité de la carte à puce
On est face à deux situations dans le cas des contenus multimédia (VOD…) :
• Carte avec validité prédéfinie suivant un créneau temporel (durée déterminée) : ce cas
est notamment utilisé dans l’industrie audiovisuelle comme les bouquets de chaînes
numériques. L’accès au media ne peut se faire que lorsque la carte est insérée dans le
décodeur, son retrait provoquera immédiatement la coupure de la visualisation du
contenu multimédia. Ainsi, on peut garantir qu’une carte ne pourra être utilisée que
par son possesseur seul et que celui-ci n’ouvre qu’un seul media en même temps (ce
cas s’applique seulement pour le premier cas précédemment cité).
L’organigramme pour ce cas est illustré par la Figure 3.11
Chapitre 3 Contrôle d’accès
Projet de fin d’études 2005-2006 53
Figure 3.11 : Cas de carte à puce avec durée de temps prédéfini
• Carte avec un nombre de visualisations de contenu déterminé, ce nombre est
décrémenté à chaque fois qu’un contenu est visualisé jusqu’à expiration du solde dans
la carte (ce cas est désormais très utilisé pour les bouquets à la demande où le contenu
ne peut être visualisé que pour un nombre fini de fois). La condition sur l’insertion de
la carte est aussi valide pour ce cas.
L’organigramme pour ce cas est illustré par la Figure 3.12. Il est à noter que les deux
approches peuvent être combinées.
Les trois phases sont illustrées par l’organigramme suivant :
Chapitre 3 Contrôle d’accès
Projet de fin d’études 2005-2006 54
Figure 3.12 : Cas de carte à puce avec durée de temps prédéfinie
Ces solutions proposées peuvent être adoptées pour le cas du projet
SAGEM_DVB_ZAP pour la partie contrôle d’accès sur les décodeurs. Mais leur
implémentation sera une future tâche dans le cadre de ce projet puisque ce point n’est pas
encore atteint par l’équipe.
3.3.2 Utilisation de OpenSSL SSL est utilisé pour la sécurisation des transactions entre le décodeur et les différents
serveurs pour les cas sans et avec carte à puce.
Chapitre 3 Contrôle d’accès
Projet de fin d’études 2005-2006 55
3.3.2.1 Définition
OpenSSL est une boîte à outils de chiffrement comportant deux bibliothèques une de
cryptographie générale et une implémentant le protocole SSL, ainsi que des commandes en
ligne[6]. Les bibliothèques qui sont écrites en C implémentent les fonctions basiques de
cryptographie et fournissent un certain nombre de fonctions utiles. Grâce aux wrappers, il est
possible d'utiliser la bibliothèque OpenSSL dans une grande variété de langages
informatiques.
Les paramètres de la commande en ligne OpenSSL sont très nombreux ; ils
permettent d'indiquer entre autre l'un des nombreux types de chiffrement (exemple : blowfish,
DES ou Triple DES, DSA, RC4, RC5, RSA ...), d'encodage (base64 ou autre) et de hachage
(MD5, SHA-1, ...). Cet utilitaire et les bibliothèques associées sont disponibles pour la plupart
des Unix incluant Linux et Mac OS X, mais aussi pour Microsoft Windows, DOS, Open
VMS.
3.3.2.2 Apports de OpenSSL
OpenSSL permet d’implémenter les commandes nécessaires à utiliser pour garantir
une communication sécurisée avec les serveurs. En effet, le décodeur doit communiquer avec
les serveurs et l’occurrence de cette communication ne peut se faire que par des échanges
d’informations confidentielles (clés) et donc des informations cryptées. L’échange de
l’information cryptée se fait par l’exécution au niveau du décodeur de commandes
instantanées qui vont utiliser les clés de chiffrement présentes au niveau du décodeur pour les
échanges. La génération des clés, l’application d’algorithme cryptographique et génération
des certificats peuvent se faire grâce aux commandes OpenSSL.
3.3.3 Scénario global pour le contrôle d’accès dans l’application SAGEM_DVB
Le scénario de l’échange entre le fournisseur et le client est illustré par la Figure 3.13.
Ce scénario suivant illustre les différents échanges qui se passent lors d’une demande de
service entre le fournisseur et le client. De plus, celle-ci illustre les différentes tâches propres
à chacune des parties en question.
Chapitre 3 Contrôle d’accès
Projet de fin d’études 2005-2006 56
Figure 3.13: scénario proposé
Chapitre 3 Contrôle d’accès
Projet de fin d’études 2005-2006 57
3.4 Conclusion Dans ce chapitre, qui représenter un travail d’anticipation sur le projet SAGEM_DVB,
nous avons donné un aperçu sur les méthodes et techniques existantes qui peuvent être
employées pour la sécurisation du contrôle d’accès. Nous avons étudié le cas avec puce et
sans puce au niveau du décodeur et avons mis l’accent sur un protocole qui peut être
appliqués pour chacun des cas et les acteurs qui interviennent dans les deux cas.
Conclusion générale
Projet de fin d’études 2005-2006 58
Conclusion générale
Dans ce projet, nous avons présenté l’état de l’art des normes qui régissent la diffusion
DVB.
Nous avons ensuite présenté le travail effectué au sein de QUATERNOVE en
collaboration avec SAGEM Communications entre autre les contributions faites pour la
réalisation du projet ambitieux SAGEM_DVB_ZAP qui regroupe diverses applications et
services comme la vidéo à la demande et la vidéoconférence. Nous avons mis en place
l’architecture correspondante et avons diffusé de la vidéo sur le réseau. Nous avons aussi
contribué à une amélioration du prototype de l’application SAGEM_DVB_ZAP.
Nous avons ensuite abordé le problème du contrôle d’accès pour la sécurisation de
l’accès aux services. Nous avons donné un aperçu sur les techniques existantes à base de carte
à puce et sans carte à puce pour effectuer ce contrôle. Ensuite, nous avons proposé plusieurs
solutions à base de cartes à puce et avons précisé l’architecture et les différentes transactions
qui entrent en jeu entre client et fournisseur de média.
Enfin, il est à préciser que nous avons pu nous familiariser avec l’utilisation des
décodeurs TV Linux et des différentes composantes qui régissent leurs fonctionnements.
Ainsi, nous avons eu un aperçu sur le mode de travail au sein d’un leader mondial dans le
domaine Télécoms en plus du travail au sein d’une équipe de recherche où nous avons réalisé
des tâches de conception et de développement.
Bibliographie et webographie
Projet de fin d’études 2005-2006 59
Bibliographie et Webographie
[1] Fabien Leborgne, ''Transmission audiovisuelle: De la télévision hertzienne analogique à la
télévision numérique (hertzienne) terrestre dite TNT'', DEA, 2004-2005
[2] Doc CTE-TNT/GT3-03, ''Services et profil de signalisation pour la diffusion de la TV
numérique de terre'', France, juillet 2001
[3] BRASSAC Anne, DARRIEULAT Maya, HADJISTRATIS Emmanuel, ROUSSE David,
''Travaux d'Etudes et de Recherches : Les réseaux sans fil'', DESS MIAGe, Toulouse, 2001-
2002
[4] France Télécom R&D, ''La télévision sur ADSL'', Farnce, 2003
[5] Hikmat ADHAMI, ''Intégration de ISAKMP au sein du protocole SSL'', DEES, AUF,
2003
[6] Charles CHEBLI, ''Signature et Chiffrement'', DESS, AUF, mars 2003
http://www.freevo.sourceforge.net
http://www.xinehq.de
http://www.lirc.org
http://www.tldp.org/REF/VLS-User-Guide
Glossaire
Projet de fin d’études 2005-2006 60
Glossaire
API : Application Programming Interface
CCS : Change Cipher Spec.
DRM : Digital Right Management
DVB : Digital Video Broadcast
EPROM : Erasable Program Read Only Memory
HTTP : Hypertext Transport Protocol
MPEG-2 : Moving Picture Experts Group
NFS : Network File system
STB : Set Top Box
SDRAM : Synchronous Dynamic Memory
SRAM : Static Random Access Memory
SSL : Secure Socket Layer
TNT : Télévision Numérique Terrestre
UDP : User Data Protocol
VLS : Video LAN Server
VLC : Video LAN Client
VOD : Video On Demand
Titre : Cryptage MPEG2/MPEG4 et gestion de droits sur un
décodeur TV Linux
Résumé :
Le secteur de la télévision numérique est en pleine expansion. Ce domaine prend de plus
en plus d’ampleur surtout avec l’apparition dans les pays développés de nouveaux
services comme la vidéo à la demande et la TNT. C’est pour cela que ce domaine attire
de plus en plus les grandes firmes mondiales qui se focalisent sur une industrie comme
celle des décodeurs.
La sécurité est de plus en plus présente dans le cas du contrôle d’accès qui prend une
position capitale pour la garantie des intérêts du fournisseur de service.
Dans ce projet, nous avons proposé différentes solutions pour mettre en place un contrôle
d’accès assez efficace et ce dans le but de sécuriser l’accès au contenu multimédia.
Ce travail présente une anticipation quant à l’élaboration future des décodeurs STB au
sein de SAGEM Communications.
Mots Clés : DVB, VLC, VLS, TNT, VOD, SSL, DRM, MPEG2.