dardouri ghazi

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


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



format MPEG4 sera pris en charge. Nous pourrons interagir avec le décodeur grâce à

l’interface Freevo qui permet de visualiser un contenu multimédia selon le choix.

Nous allons aussi étudier les solutions existantes pour le contrôle d’accès avec carte à

puce ou dans le cas de la présence d’un serveur DRM (Digital Right Management) pour avoir

une idée sur le choix futur à prendre concernant l’implémentation du contrôle d’accès. Nous

proposerons entre autre deux solutions à base de carte à puce dont le choix va dépendre du

choix économique du fournisseur.

Chapitre 1 État de l’art


Chapitre 1: État de l’Art

1.1 Introduction Le travail dans le domaine de la transmission numérique de la vidéo nécessite de

mettre l’accent sur les techniques qui peuvent rendre cette opération faisable. Ainsi, il faut

naturellement détailler les différentes normes qui régissent cette transmission et qui

permettent d’offrir les services souhaités.

1.2 Initiation au monde de la télévision numérique On a été chargés au départ de se familiariser avec le monde de la télévision numérique

terrestre et de faire en sorte à ce que nous soyons opérationnels le plus rapidement possible.

Cette tâche consistait à découvrir les principes de la télévision numérique terrestre ainsi que

celle de la norme Linux DVB. La dernière partie de cette mission consistait à préparer notre

plateforme de travail afin que nous puissions découvrir ces fonctionnalités en premier lieu et

pouvoir travailler dessus après.

Dans cette section, nous présentons une description succincte de la télévision numérique.

1.2.1 La télévision numérique terrestre La télévision numérique terrestre est l'une des technologies en vogue en ce moment.

Cette nouvelle génération de télévision fera la une pour au moins les dix années à venir et sera

l'un des domaines d'intérêt des chercheurs et des scientifiques. Nous commencerons par un

historique de cette technologie et nous étalerons dans la suite quelques principes de la

télévision numérique.

1.2.1.1 Historique

Le système de télévision numérique terrestre européen (normalisé sous la référence

ETS 300 744) utilise la modulation OFDM (également appelé COFDM) déjà utilisée pour la

radio numérique (DAB) [1]. Cette norme utilise deux variantes la 2K et la 8K. Le Royaume-

Uni a été le premier pays européen à démarrer (fin 1998) un service de TV numérique

terrestre, en majeure partie à péage, à la norme DVB-T. Elle est le seul pays européen à



utiliser la modulation COFDM à 2K porteuse en raison de la non disponibilité de circuits

démodulateur pour le mode 8K à l'époque.

• La Suède et l'Espagne ont suivi, respectivement fin 1999 et mi-2000, et utilisent le

mode DVB-T 8K. Ceci a permis à l'Espagne de développer un réseau de multiplex à

fréquence unique (SFN) sur tout le territoire sur les canaux les plus élevés de la bande

UHF (66 à 69), inutilisés jusque-là par la télévision analogique. La France ne rejoint le

club des pays dotés de la télévision numérique qu'en mars 2005. Elle a pu ainsi offrir

au grand public un bouquet de huit chaînes gratuites avec une très haute qualité de son

et d'image et ceci en utilisant une simple antenne terrestre.

Cependant, le remplacement complet des émissions analogiques actuelles par les

nouveaux services numériques promet d'être un processus long (environ 10 ans), à moins

d'une volonté politique d'accélérer le mouvement, affirmée par exemple en fournissant

gratuitement ou à un prix très modique des adaptateurs numériques de base à tous les foyers

acquittant la taxe TV...

Le système DVB-T a d'ores et déjà été choisi par un certain nombre de pays non

européens, dont l'Australie et Singapour, mais, pour les pays n'ayant pas encore fait leur

choix, il se trouve désormais en concurrence avec un nouveau système japonais (ISDB-T),

également basé sur la modulation COFDM avec quelques ajouts qui le rendent encore plus

robuste (surtout pour la réception mobile), au prix cependant d'une complexité et d'un surcoût

importants.

Les Etats-Unis quant à elle a démarré en 1998 les émissions numériques terrestres, en

TVHD au standard ATSC avec pour objectif initial l'arrêt des émissions analogiques NTSC

en 2008. Cependant, en raison de choix à la fois techniques et politiques discutables

(performances décevantes de la modulation choisie 8-VSB ou BLR-8 à bande latérale

résiduelle à 8 états, coût élevé des afficheurs à haute définition, absence de services interactifs

associés), le développement a été très décevant jusqu'à présent, ce qui rend très improbable un

arrêt effectif des émissions analogiques en 2008.

En conclusion, la télévision numérique terrestre est une technologie émergente dans

tous les coins de la planète dans ce début du troisième millénaire et il est assez clair qu'elle a

encore besoin des efforts de la recherche et des industriels pour s'imposer comme un unique

standard de télévision. Mais elle reste par ailleurs une technologie très prometteuse. Dans la

suite, on va décrire les principes de fonctionnement de la TNT.



1.2.1.2 Principes de fonctionnement de la TNT

Avant de passer à la description d'un récepteur avec décodeur intégré, appelé IRD

(Integrated Receiver-Decoder) ou plus familièrement set top box (littéralement « boite posée

sur le poste ») par les Anglo-Saxons, nous récapitulerons rapidement de façon très simpliste la

suite des opérations que subit le signal TV de sa source à sa visualisation par l'utilisateur.

La Figure 1.1 illustre tout le processus d'émission et de réception en TV numérique. La

partie supérieure de cette figure décrit les étapes du cycle d'émission. La partie inférieure est

destinée pour la réception[2].

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



d'accès ECM et EMM sont alors insérés) ainsi que les informations de tables PAT et PMT

et celles du guide de programme (EPG).

3. La correction d'erreur RS porte la longueur des paquets à 204 octets; dans le cas du

satellite, le code convolutif multiplie de plus en plus le débit par un facteur 1,14 à 2; un

reformatage des données suivi d'un filtrage et d'une conversion fournit les signaux I et Q

analogique.

4. I et Q modulent en COFDM une porteuse FI (Fréquence Intermédiaire).

5. Cette fréquence intermédiaire est transposée ensuite dans la bande de fréquence appropriée

à sa transmission selon le médium utilisé.

Côté récepteur, la partie basse de la figure montre que les opérations, symétrique de

celle de l'émission, s'effectuent, logiquement, dans l'ordre inverse de l'émission.

6. Seulement en cas d'une réception satellite, un premier abaissement de fréquence se fait

dans la tête de réception de l'antenne. En suite le signal subit un deuxième changement de

fréquence à l'entrée du récepteur. Cette deuxième opération est valable pour tous les modes

de réceptions .A la fin de cette étape, on obtient une FI démodulée.

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

8. Après conversion analogique/numérique, filtrage et reformatage de I et Q, la correction

d'erreur permet de retrouver les paquets « transport » de 188 octets.

9. Le démultiplexeur sélectionne les PES correspondant au programme choisi par l'utilisateur,

éventuellement désembrouillés au préalable grâce aux ECM et EMM et à la clé privée de

l'utilisateur (généralement une carte).

10. Le décodeur MPEG-2 reconstruit les images et le son du programme sélectionné.

Après avoir décrit le processus d'émission et de réception d'un signal de télévision

numérique, nous procéderons dans la suite à la description de l'outil de réception. Le modèle

d'un récepteur TV numérique basé sue le système d'exploitation Linux est normalisé suivant

la norme Linux DVB.

1.3 La norme Linux DVB 1.3.1 Présentation de la norme DVB

Digital Video Broadcasting (ou DVB), soit « diffusion vidéo numérique », est une

norme de télévision numérique édictée par le consortium DVB, organisme européen, mais

utilisée partout au monde, sauf pour la télévision terrestre dans quelques pays dont les États-

Unis d'Amérique et Canada (où la norme ATSC prédomine) et le Japon (autre norme).



La télé par satellite en Amérique est diffusée partiellement en DVB et partiellement en

un autre système (propriété de Motorola); les DirecTV se sert des normes incompatibles

utilisées en aucun autre système. Globecast, Dish Network et ExpressVu sont DVB, aussi

certains canaux libres ou ethniques. La version 1 de la norme utilise la compression vidéo

MPEG-2 et le MPEG-2 Transport Stream comme flux de transport de paquet.

On peut remarquer que c'est le 'MPEG-2 Program Stream' qui est utilisé dans les

périphériques utilisant la norme MPEG-2 comme les lecteurs DVD. La différence essentielle

entre le MPEG-2 Transport Stream et le 'MPEG-2 Program Stream' est la taille des paquets

d'octets des flux de données: un paquet 'Transport' a une taille de 188 octets, alors qu'un

paquet 'Program' peut avoir une taille de 2048 octets.

Le DVB est surtout une norme qui concerne la signalisation diffusée dans le flux (les

tables DVB), qui permet à tout décodeur DVB de retrouver les programmes reçus. Elle

enrichit la Norme MPEG (ISO 13818). Les différents canaux numérisés (de télévision

principalement) sont multiplexés: c'est à dire séparés (en Audio, en Vidéo, en informations..),

découpés en paquets et mélangés. Un programme de TV se compose donc du flux de la

composante vidéo, du flux de la composante audio, du flux des sous-titres en français, du flux

des sous titre en anglais, du flux... Chacun de ces flux est transporté par des paquets de

transport (TS) qui portent un même numéro pour chacun des flux, le Paquet Identifier (PID).

Les tables DVB servent à déterminer ce que transporte un flux de paquets de transport avec

un même PID[2].

Il y a trois tables importantes qui donnent des informations sur le flux:

• La 'Program Association Table' (PAT) qui donne la liste des programmes présents

• La 'Program Map Table' (PMT) qui donne pour un programme sa composition, les

différents PID qui le constituent

• La 'Conditional Access Table' (CAT) qui donne la localisation des informations pour

le décodage des programmes cryptés.

Ajoutons quelques informations:

• La 'Service Definition Table' qui donne un nom entre autres aux services

• La 'Network Information Table' qui donne la liste des canaux composant un réseau

• La 'Event Information Table' qui donne les informations sur les programmes en cours

ou à venir.

Les normes DVB sont définies par l'Etsi: The European Telecommunications Standards

Institute.



Le DVB a spécifié une norme pour chaque un des types les décodeurs [3]:

• DVB-S pour la télévision par satellite. C'est le plus ancien et le plus établi des travaux

du groupe DVB. Il est employé sur tous les continents. Il permet d'occuper au mieux

la bande passante des canaux satellitaires existants. Une des images couramment

employées pour expliquer le DVB est de dire que c'est un oignon. Dans son coeur se

trouvent les paquets MPEG (l'information utile). DVB a rajouté des "peaux

supplémentaires" pour protéger des erreurs ces informations du milieu difficile qu'elles

vont traverser. En fonction de l'épaisseur de ces "peaux", le débit utile qu'un canal

satellite peut transporter varie. C'est l'opérateur de service qui détermine l'épaisseur de

ces couches de protection. Par exemple, sur un canal de largeur de bande 36MHz, on

pourra transporter environ 38 Mbit/s d'information utile.

• DVB-C est utilisé pour la télévision par câble. Le DVB-C est basé sur le DVB-S. La

modulation change, on utilise le QAM à la place du QPSK, et le milieu de transport (le

câble) étant moins bruité que la voie satellite, on supprime une couche de protection

d'erreurs. Ici, nos 38 Mbit/s de données utiles peuvent circuler dans un canal de

8MHz.

• DVB-T pour la télévision hertzienne/terrestre. Le DVB-T a été approuvé par l'ETSI en

Février 1997. Comme pour le DVB-S et le DVB-C, les informations sont codées, de

base, selon la norme MPEG2, DVB définissant le mode de transport et les systèmes de

protection d'erreurs. C'est la modulation COFDM qui a été retenue, sous une forme 2K

(1705 porteuses) et 8K (6817 porteuses). Chacune de ces porteuses étant elle-même

modulée en QUAM ou QPSK. Ce système, insensible aux échos, présente l'avantage

de pouvoir réaliser des réseaux mono fréquences (SFN).

• DVB-M/CS ici, on utilise les micro-ondes pour une distribution multipoint.

• DVB-SI MPEG 2 permet de séparer les informations système (SI), des informations

spécifiques de programme (PSI). DVB a mis à disposition un système ouvert

d'insertion d'information système qui permet au terminal ou à l'utilisateur de naviguer

à travers les services. On va ainsi retrouver toutes les informations pour un zapping

simplifié, toutes les informations concernant les programmes (heure de début et de fin

d'une émission, type de l’émission), etc.

• DVB-CA Vu du coté du terminal, les systèmes de contrôle d'accès peuvent être vus

comme étant composés de deux parties:



-le décryptage: la clé d'embrouillage est transmise codée dans le flux. Si on a

souscrit le bon abonnement, un module fournit la clé en clair au module de

désembrouillage.

-le désembrouillage : grâce à la clé en clair, on peut restituer l'information

originale.

De plus, grâce au DVB-CA, on peut faire du:

-SimulCrypt : un opérateur embrouille un programme à la fois en

Viaccess et en Médiaguard, par exemple. Ce programme peut alors être diffusé

sur chacun des réseaux utilisant son propre système de CA.

-MultiCrypt : un terminal peut travailler avec différents systèmes de contrôle

d'accès.

• DVB-CI : l'interface commune est une interface normalisée entre une carte PCMCIA

et le terminal numérique. C'est cette interface qui permet à un terminal DVB

d'accepter différents types de contrôle d'accès (Viaccess, Médiaguard, Irdeto...).

• DVB-H : pour les applications portables (H pour « handheld »).

Dans ce document, nous nous intéressons à la norme DVB-T qui définit un ensemble

de standards pour les décodeurs destinés à la télévision numérique terrestre.

1.3.2 Flexibilité de la norme DVB-T La norme DVB-T, qui définit les techniques de modulation et de codage canal pour la

diffusion hertzienne numérique, prévoit plusieurs configurations, ce qui offre de la flexibilité

pour la mise en oeuvre de la diffusion. Ces configurations diffèrent notamment sur :

• la couverture d'un émetteur donné de puissance donnée : c’est l’identification de la

zone où on reçoit le signal à l'aide d'une antenne fixe sur le toit (réception fixe ou

mobile). Identification des zones de réception portable (récepteur avec une antenne

intégrée, situé dans la maison) ou des zones de réception mobile (dans un véhicule).

• Le débit utile d'un multiplex (un canal de 8 Mhz), qui conditionne le nombre de

programmes et la qualité du codage.

Il s'agit de définir quels sont les modes qui pourront être utilisés dans les réseaux de

diffusion, ou corrélativement ceux que devront inclure les terminaux.



1.3.3 Configurations de la norme DVB-T La norme DVB-T prévoit :

• Quatre valeurs d'intervalle de garde (1/4 ; 1/8 ; 1/16 ; 1/32) : plus l'intervalle est élevé,

plus la réception est robuste à des échos longs, naturels ou artificiels (réseaux mono

fréquences), mais moins le débit utile est élevé.

• Cinq codes correcteurs d'erreurs : cela correspond à différents compromis entre la

robustesse au bruit et le débit utile.

• Trois modulations non hiérarchiques (QPSK, 16-QAM et 64-QAM) et deux

modulations hiérarchiques (QPSK + QPSK et QPSK + 16 QAM). Les trois

modulations non hiérarchiques correspondent à différents compromis entre robustesse

au bruit et débit utile. Globalement, les codes correcteurs et les modulations non

hiérarchiques offrent un continuum de compromis allant de 5 à 31 Mbit/s. Les

possibilités des modulations hiérarchiques seront développées ci-dessous.

• Deux nombres de porteuses, l'OFDM étant une modulation multi porteuse, 1705 et

6817, connus sous les noms 2k et 8k, car ils sont réalisés via des transformées de

Fourier rapides à 2048 et 8192 points.

1.3.4 Modes 2k et 8k Le système retenu par DVB est tel que les circuits implantant le mode 8k savent traiter

les signaux 2k. Le choix doit donc s'effectuer entre «2k» et «8k compatible 2k».

Sur le plan opérationnel, le seul avantage du mode 2k concerne la réception mobile : comme

les porteuses sont plus écartées, le signal est plus robuste aux effets Doppler en présence

d'échos.

Le mode 8k présente principalement l'avantage d'accroître les intervalles de garde, et

donc la robustesse de la réception aux échos longs, naturels ou artificiels (émetteurs

constituant un réseau mono fréquences ou réémetteurs iso fréquences en particulier). En 2k,

les valeurs d'intervalles de garde 1/32 et 1/16 sont sans doute trop faibles, car elles

correspondent à des échos de 7 _s et de 14 _s respectivement, tandis qu'on rencontre des

échos naturels supérieurs à 14 _s en milieu urbain. Avec les intervalles de garde 1/8 et 1/4 (28

_s et 56 _s), on résiste bien aux échos naturels; cependant, comme l'indique le tableau ci-

dessous, les modes 8k avec intervalles de garde 1/32 et 1/16 conduisent à 28 _s et 56 _s

également, avec un débit utile supérieur de 9% et de 18% respectivement au mode 2k : même

en l'absence de réseau mono fréquences, le 8k est donc préférable. Pour des réseaux mono

fréquences, la densité des émetteurs doit être d'autant plus élevée que la durée de l'intervalle



de garde est courte : en pratique, il faut donc le mode 8k, avec un intervalle de garde de 1/8

voire de 1/4 pour disposer de mailles larges (supérieures à 50 Km).

intervalle de garde 2k : durée des échos débit utile 8k : durée des échos

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

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

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

1/4 56 _s 19,91 Mbit/s 224 _s

Tableau 1.1 : Débit utile modulation (64 QAM, code correcteur de taux 2/3) et résistance aux

échos pour les modes 2k et 8k

En termes de coûts des récepteurs, l'impact est a priori d'une part sur le circuit de

démodulation, et d'autre part sur le circuit tuner. En ce qui concerne le circuit de

démodulation, le circuit est constitué de logique programmable et de mémoire. La logique

programmable est du même ordre de grandeur en 2k et en 8k.

En revanche, la mémoire est approximativement deux fois plus élevée en 8k. Les

perspectives d'évolution technologique font que le surcoût du 8k baissera non seulement en

valeur absolue, mais aussi proportionnellement. En ce qui concerne le circuit tuner, il n'y a

pas de surcoût significatif en 8k.

1.3.5 Modes non hiérarchiques Du fait des limitations en spectre et de la volonté de réduire les coûts de diffusion, il

est souhaitable d'utiliser autant qu’on peut la modulation 64 QAM. Comme le surcoût est

marginal pour le circuit, il faut que tous les terminaux sachent traiter la modulation 64 QAM,

et il leur est alors facile de traiter les autres modulations qui sont plus simples.

De même, pour les différents codes correcteurs et intervalles de garde, le surcoût sur

les circuits est nul, et il faut que toutes les possibilités soient offertes en diffusion.

Il est donc légitime d'attendre que tous les modes non hiérarchiques soient supportés par tous

les récepteurs.

1.3.6 Aptitude à traiter les échos Les échos sont présents naturellement (en particulier en ville et en intérieur) et

artificiellement (réseaux SFN et réémetteurs iso fréquence). Il convient de s'assurer que les

récepteurs sont capables de s'adapter à ces échos.

L'implantation «standard» de l'estimateur de canal de la norme DVB-T rend le

récepteur robuste à des échos d'une durée inférieure à l'intervalle de garde. Il est légitime



d'attendre de tous les récepteurs cette fonction. Pour des échos d'une durée supérieure à

l'intervalle de garde, il faut des dispositifs d'égalisation du canal plus complexes que

l'estimateur «standard», qui ne peuvent en aucun cas être attendus dans tous les récepteurs. Il

est donc indispensable de faire en sorte que les échos artificiels soient d'une durée inférieure à

l'intervalle de garde.

1.3.7 Modulations hiérarchiques Les modulations hiérarchiques consistent à séparer le signal en deux flux, un flux

prioritaire et un flux non prioritaire. Le flux prioritaire est mieux protégé que le flux non

prioritaire, si bien que lorsque la réception est mauvaise, seul le flux prioritaire est décodé.

A titre d'exemple, considérons un flux de 22,12 Mbit/s, reçu sur une zone de 10 Km de

rayon avec un mode non hiérarchique avec une puissance donnée. Si le flux est divisé en un

flux prioritaire de 7,37 Mbit/s et un flux non prioritaire de 14,75 Mbit/s, et si ces deux flux

sont diffusés avec un mode hiérarchique avec la même puissance, le flux prioritaire est reçu

jusqu'à 15,4 Km de l'émetteur, mais le flux non prioritaire jusqu'à 8,7 Km de l'émetteur

seulement. Avec un autre mode hiérarchique, le flux prioritaire est reçu jusqu'à 13 Km et le

flux non prioritaire jusqu'à 9,8 Km de l'émetteur. Précisons qu'il s'agit de valeurs théoriques

nécessitant une confirmation expérimentale.

Concrètement, cela permet par exemple d'avoir une bonne couverture portable de

certaines chaînes, tout en proposant en réception fixe une large offre de programmes. Cela

signifie également qu'il existe une zone (dépendant de la planification de fréquences) limitée à

l'offre prioritaire. Ce ne sera pas forcément compatible avec les choix d'introduction des

services.

Il aurait été envisageable de combiner les modulations hiérarchiques avec un codage

de source hiérarchique. Cela signifie par exemple qu'un signal TVHD aurait été codé en deux

flux : un flux contenant les informations nécessaires à la reconstitution d'un signal TV de

qualité standard, transmis de manière prioritaire, et un flux contenant les informations

complémentaires nécessaires à la reconstitution du signal haute définition. Il a été décidé par

DVB de ne pas retenir cette possibilité : il n'y a pas de codage de source hiérarchique dans les

systèmes DVB, un système de double diffusion qualité standard - haute définition est choisi.

Les modulations hiérarchiques peuvent cependant être utilisées dans un contexte de double

diffusion qualité standard - haute définition, en transmettant le flux standard de manière

prioritaire, à l'attention des récepteurs portables, et le flux haute définition de manière non

prioritaire, à l'attention des récepteurs fixes.



Le surcoût des modes hiérarchiques n'est pas significatif pour les récepteurs.

Cependant, ils doivent être pris en compte lors de la conception du terminal : par exemple, il

faut gérer au niveau du démultiplexeur le fait que le démodulateur peut générer deux flux. Il

semble qu'une partie de l'offre de composants permettront ces modes (au moins SGS

Thomson, VLSI Technology et LSI Logic), mais il existe en Europe des récepteurs qui ne

l'incluront pas.

En ce qui concerne les émetteurs, les modes non hiérarchiques ne sont sans doute pas

installés «en série», mais les émetteurs peuvent facilement insérer «en option» ces modes,

dont le surcoût sur les émetteurs est marginal. Il faut également considérer les difficultés pour

l'alimentation des émetteurs par le réseau de transport : l'émetteur doit disposer de deux flux,

et si les signaux sont repris de la diffusion par satellite, cela signifie que l'émetteur doit avoir

deux équipements de transmultiplexage pour constituer les flux prioritaire et non prioritaire.

L'usage des deux flux suppose la duplication de la gestion des informations de service (SI). Le

déploiement de services dans les modes hiérarchiques implique donc un surcoût pour le

réseau de diffusion. 1.4 Les services interactifs 1.4.1 La vidéo à la demande (Video on Demand ou VoD)

L'avantage majeur que fournissent les réseaux à hauts débits par rapport aux réseaux

de diffusion classique de télévision réside dans l'interactivité et la personnalisation offerte au

client. L'aboutissement de ces caractéristiques est résumé dans la délivrance de contenus à la

demande, où le client peut choisir quel contenu il désire consulter, et à quel instant.

De nombreux opérateurs évoquent depuis longtemps des services de vidéo à la

demande. Il faut cependant faire la distinction entre plusieurs types de ces services, qui sont

résumés sur le Tableau 4. La première étape de la personnalisation des contenus vidéo est

franchie dès lors que les services en « Pay-Per-View » apparaissent. Ceux-ci permettent à un

client d'acheter le droit de voir une émission (film ou événement sportif en général). Cela

s'apparente en fait à un contrôle d'accès sur ce contenu spécifique, accompagné d'une

transaction électronique, le paiement se faisant en général par carte de paiement. Sur les

réseaux à hauts débits, ce type de service devrait voir le jour assez rapidement car il permet de

maîtriser assez facilement de nombreux paramètres.Un second type de service est déjà fourni

par un grand nombre d'hôtels, et consiste à diffuser sur des chaînes internes (dans ce cas cela

n'est pas une contrainte) des films à intervalles réguliers. Il existe donc des « séances » pour

chaque film, en général payantes. Ce type de service, est appelé near Video on Demand ou



nVOD. Techniquement, la fourniture de ce service n'est pas fondamentalement différente des

contraintes d'une télévision classique. La programmation en est même simplifiée. Il faut noter

que ce type de schéma ne présente que peu d'intérêt dans le cas des réseaux à hauts débits,

leur objectif étant de se satisfaire des infrastructures existantes.

Enfin, le véritable service de vidéo à la demande consiste à fournir un contenu vidéo à

la demande du client, au moment de son choix, après avoir effectué celui-ci sur un catalogue.

L'apport des réseaux à hauts débits est ici amplifié par les facilités de conception de

catalogues véritablement interactifs, qui sont en fait des sites Web «classiques», dont le

financement peut être assuré par la publicité car sa consultation constitue une grande partie de

la consommation du client.

Plusieurs architectures ont été testées pour le déploiement du DVB, mais une seule semble

être la plus adaptée. Ces cas sont illustrés par la figure 1.2.

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



Remarque :

Les technologies de serveurs vidéo ne sont pas encore non plus tout à fait prêtes pour

permettre à de tels services de se développer. C’est pour cela que nous proposerons une

solution à base de serveur Video LAN VLC.

1.4.2 La visioconférence (UIT-T F730)

La vidéoconférence combine la voix et les données dans une communication qui peut

comporter plusieurs personnes. La seule contrainte qui a rendue cette application non

répondue auparavant était la qualité médiocre de la vidéo qui est transmise. Mais, comme

l’ADSL est devenu courant et disponible pour toutes les tranches de la société avec des débits

très élevés, la vidéoconférence est devenue une chose possible sans la présence d’immenses

obstacles techniques. De plus, la vidéo à haute définition est supportée par ces réseaux ce qui

rend cette application attractive pour le domaine de la télévision numérique.

1.5 Conclusion Dans ce chapitre, nous avons mis l’accent sur les normes existantes pour la

transmission vidéo qui vont être utilisées dans la suite du travail et qui sont DVB-T, MPEG2-

TS et MPEG2-PS. Nous avons précisé les services qui peuvent être supportés par

l’architecture qu’on va proposer.

Dans le prochain chapitre, nous allons présenter notre apport au niveau de l’application

SAGEM_DVB_ZAP.

Chapitre 2 Architecture du système


Chapitre 2: Architecture du système

2.1 Introduction Ce chapitre contient nos différentes contributions au déroulement du travail de

l’équipe Sagem. Nous proposons en premier lieu une description de l’environnement du

travail exigé pour pouvoir travailler avec l’équipe. En second lieu, nous allons décrire

l’application SAGEM DVB en insistant sur nos apports personnels.

2.2 Architecture de SAGEM DVB Pour pouvoir réaliser du développement sur un décodeur à base d'une carte DVB, on

doit s'équiper de 3 ordinateurs, un switch, un minicom, une sonde, une télévision, une antenne

TNT et un décodeur. Chacun de ces composants joue un rôle particulier dans l'élaboration des

tâches de développement.

Un des ordinateurs est destiné à faire du développement pur et dur. Il doit être doté du

système d'exploitation Linux, on note que la distribution utilisée chez Sagem Communication

est Mandriva 2006. Les deux autres machines servent comme hôte pour un serveur DHCP et

un serveur VLC. Un serveur VLC permet la diffusion de la vidéo sur IP. La télévision est

utilisée comme un outil de test du flux sortant du décodeur. Le minicom permet de récupérer

sur le poste de développement les traces du noyau embarqué sur le décodeur via une interface

de communication série. Et bien sur cette plateforme comporte une carte DVB sujet de notre

projet.

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

contient pas la sonde).



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



2.3 Poste de développement ST-Linux Dans cette partie, nous décrirons le procédé générique pour installer les logiciels sur

un ordinateur principal et ceci servira pour tout le groupe pour pouvoir travailler ensemble sur

les mêmes versions et avec les mêmes bibliothèques.

2.3.1 La distribution MANDRIVA 2006.A

2.3.1.1 Présentation de la distribution MANDRIVA 2006.A

La distribution Mandriva Linux (anciennement Mandrake linux) doit une grande partie

de sa popularité à sa simplicité pour l'utilisateur final

Contrairement à beaucoup d'autres distributions de GNU/Linux, son installation est

extrêmement simple. En effet, il existe différents assistants qui se chargent d'expliquer à

l'utilisateur les notions de base, le conseillent pour des choix délicats, etc. Il est ainsi possible,

pour quelqu'un qui installe GNU/Linux pour la première fois sur un ordinateur, de s'orienter

avec facilité. Cette simplicité est se manifeste encore lors l'utilisation de ce software.

La distribution Mandriva Linux rassemble environ 3000 logiciels. Elle inclut tous les

paquetages/logiciels les plus populaires, à commencer par les bureaux GNOME et KDE, qui

permettent aux utilisateurs venant de Microsoft Windows de trouver rapidement des repères.

On note aussi que les documents créés sous Open Office avec extension .doc, .xls, .ppt sont

compatibles avec Microsoft Windows.

Pour des utilisateurs francophones, beaucoup d'informations et de programmes ont été

traduits. Mandriva Linux permet ainsi d'associer la fiabilité de GNU/Linux à la facilité de

Windows. Lors de l'installation il est, bien sur, possible de conserver son système

d'exploitation Microsoft Windows.

2.3.1.2 Installation

Pour que tout le groupe de travail soit en phase, il faut qu’ils utilisent les mêmes

versions de logiciel et les mêmes systèmes. Pour cela, il nous a fallu installer la distribution

Mandriva 2006.A. Notons que lors de l’installation, il est judicieux de suivre la

documentation de l’entreprise qui réponde aux besoins du projet.

2.3.2 Installation de ST LINUX ENVIREMENT OF DEVELOPPMENT Dans cette étape, nous allons installer les différents paquetages STLinux, définir les

liens et les commandes pour installer les différents logiciels. Pour cela, il faut d’abord ouvrir

la session utilisateur Admin.



On commence par copier les différents logiciels et paquetages se trouvant dans trois

CD dans les répertoires correspondants.

2.3.2.1 ST- Paquetage

Il est nécessaire pour pouvoir travailler sur le set-top-box. Nous allons installer les

paquetages de ST qui se trouve dans le CDROM1 et CDROM2 et nous avons changer

l’utilisateur su et créer les chemins INSTALL/PACKAGE-ST/CDROM1 et

INSTALL/PACKAGE-ST/CDROM2.

2.3.2.2 La Sonde

La sonde permet de réaliser les opérations de flashage du set-top-box, c'est à dire

l'embarcation des travaux de l'équipe sur la mémoire du décodeur.

Pour installer le ST Micro connect probe (sonde utilisé), il suffit de faire la liaison dans le

dossier /opt qui pointe sur le dossier /home/admin/INSTALL/ST40R3.0.3. On écrit donc la

commande « ln -s /home/admin/INSTALL/ST40R3.0.3 /opt/STM »

2.3.2.3 Changement de la racine en mode NFS

Le RootFS de la cible peut être placé comme NFS, dans cette utilisation attentive la

configuration suivante d'exporter l'annuaire de cible : Comme la racine éditent le dossier

d'exportations enfin il faut redémarrer le service NFS en se situons administrateur

2.3.3 Logiciels utilisés

2.3.3.1 CSCOPE

CSCOPE est un outil interactif orienté écran qui nous aide à:

• Localiser la section de code à changer pour corriger un bug sans avoir à connaître le

programme complet,

• Examiner l'effet d'un changement envisagé, comme d'ajouter une occurrence à une

variable énumérée,

• Vérifier qu'un changement a bien été appliqué dans tous les fichiers sources, comme

d'ajouter un argument à une fonction existante,

• Renommer une variable globale dans tous les fichiers sources,

• Changer la valeur d'un symbole du pré processeur dans des lignes.

2.3.3.2 Subversion 1.1.4

Subversion (ou SVN) est un logiciel libre qui sert à visualiser toutes les modifications

de l’équipe faites afin de contrôler les versions, ce qui est très utile dans le cadre de la création

de logiciels.



2.3.3.3 JAVA SDK

J2EE est une plate-forme fortement orientée serveur pour le développement et

l'exécution d'applications distribuées. Elle est composée de deux parties essentielles :

• un ensemble de spécifications pour une infrastructure dans laquelle s'exécute les

composants écrits en java : un tel environnement se nomme serveur d'application.

• un ensemble d'API qui peuvent être obtenues et utilisées séparément. Pour être

utilisées, certaines nécessitent une implémentation de la part d'un fournisseur tiers.

J2EE permet une grande flexibilité dans le choix de l'architecture de l'application en

combinant les différents composants la partie cliente, la partie encapsulation des traitements

et la partie données.

2.3.3.4 ECLIPSE “eclipse-SDK-3.0.2”

Il s’agit d’un logiciel multi plateforme, multi langages. Par le mécanisme des plugins,

il permet de créer des applications indépendantes. Ce logiciel comprend plusieurs plugins

avancés comme :

• Interface Graphique VEP (Visual Editor Project) : Nombreux plugins commerciaux,

• Editeur d’objets graphiques GEF (Graphical Editor Framework) : Permet de gérer tout

type d’organigrammes,

• Développement embarqué : Device Software Development Platform qui gère toutes

les phases du développement d’un logiciel embarqué, de la mise au point du Hardware

et de développement du SDK,

• Analyse/Conception UML 2.0 Outils propriétaires IBM Plugin Open Source.

Dans notre étude, nous avons installé Eclipse dans le dossier

/home/admin/LOGICIELS/ ECLIPSE. Après, nous avons installé les différents plugins

nécessaires en utilisant Eclipse dans les répertoires correspondants

• CDT plugin (C/C++ Development Toolkit) dans le répertoire

/home/admin/LOGICIELS/CDT/eclipse,

• Subversion plugins for Eclipse (Site) dans le répertoire

/home/admin/LOGICIELS/SITE.

2.4 Serveur de vidéo : VidéoLan VLC 2.4.1 Description

VLC est principalement le logiciel client du projet VideoLan. Il peut être utilisé en

tant que serveur, pour diffuser des fichiers MPEG-1, MPEG-2 et MPEG-4, des DVDs, ou de

la vidéo en temps réel sur un réseau en unicast ou multicast. Il peut être aussi utilisé en tant



que client pour recevoir, décoder et afficher des flux vidéo .Dans le présent travail, nous nous

intéressons aux VLC comme serveur.

VLC tourne sur de nombreux systèmes d'exploitation : Linux, Windows, Mac OS X,

BeOS, *BSD, Solaris, Familiar Linux, Yopy/Linupy et QNX .Dans le cadre de ce projet, nous

se limitons au système Linux et Windows.

Figure 2.2 : Solution de diffusion VideoLAN

VLC est capable de lire :

• des fichiers MPEG-1, MPEG-2 et MPEG-4 / DivX depuis un disque dur, un lecteur de

CD-ROM, ...

• des DVDs et VCDs,

• depuis une carte satellite (DVB-S),

• des flux MPEG-1, MPEG-2 et MPEG-4 envoyés sur le réseau par un VLS ou un VLC.

VLC peut également être employé en tant que serveur en IPv4 ou IPv6 pour diffuser:

• des fichiers MPEG-1, MPEG-2 et MPEG-4 / DivX,

• des DVDs,

• depuis une carte d'encodage MPEG.

Vers :

• une machine (c'est à dire à une addresse IP) : ceci est appelé unicast,

• un groupe dynamique de machines que les clients rejoignent ou quittent (une addresse

IP multicast): ceci est appelé multicast .



2.4.2 Installation de VLC Des binaires précompilés de VLC sont disponibles pour le système d’exploitation

Windows, mais pas pour Linux bien qu’il est supporté par VLC. Si nous désirons l’installer et

changer les paramètres, nous pouvons compiler VLC depuis ses sources.

2.4.2.1 Compilation des sources

Pour compiler le VLC à partir de ses sources, il est nécessaire d’avoir un certain

nombre de librairies qui doivent être requises:

• libdvbpsi (obligatoire),

• mpeg2dec (obligatoire),

• libdvdcss si nous désirons pouvoir lire des DVD encryptés,

• libdvdplay si nous désirons profiter des menus DVD,

• a52dec si nous désirions pouvoir décoder le son AC3 (A52), souvent utilisé dans les

DVDs,

• ffmpeg, libmad, faad2 si nous désirons lire des fichiers MPEG 4 / DivX,

• libogg & libvorbis si nous désirons pouvoir lire des fichiers Ogg/Vorbis.

Nous allons installer chaque librairie en suivant les étapes classiques : Décompression,

configuration, compilation et installation. Nous devons vérifier que le fichier /etc/ld.so.conf

contient la ligne: /usr/local/lib. Si elle n’existe pas, nous l’ajoutons.

2.4.2.2 Installation du VLC

Enfin, nous installons VLC à partir du fichier compressé nommé vlc-version.tar.gz.

Les étapes de l’installation sont comme d’habitude sur linux. Pour la décompression, la

configuration, la compilation et installation, nous exécutons successivement tar xvzf vlc-

version.tar.gz, cd vlc-version, ./configure, make, make install.

2.4.3 Modules et options de VLC

2.4.3.1 Modules

VLC utilise un système modulaire, ce qui permet un ajout simplifié de nouvelles

fonctions et de nouveaux formats. Lorsqu’on installe VLC par un fichier binaire, on a tous les

modules par défaut. Et on peut personnaliser VLC, pour cela on doit le compiler depuis ses

sources. On peut compiler un module qui est marqué désactivé par défaut et inversement, on

peut désactiver un module qui est activé par défaut .Chaque module VLC possède sa propre

aide et ses options.

• Modules d'entrée



Ces modules permettent à VLC de lire depuis différentes sources. VLC essaie de

choisir le module le plus adapté au moment de la lecture. Mais on peut forcer un

module particulier.

• Démultiplexeurs

Dans un flux, les signaux vidéo et audio sont toujours inclus dans un format

"conteneur". Les démultiplexeurs extraient les flux de ce conteneur et les envoient aux

décodeurs. Par exemple, un fichier AVI peut contenir une vidéo encodée en MPEG-4,

ou une vidéo non compressée. AVI est seulement un format de stockage, pas un

format de compression.

• Décodeurs

Ces modules permettent à VLC de supporter de nombreux codecs (formats de

compression).

• Modules de filtre vidéo

Ces modules permettent de modifier l'image (dés-entrelacement, réglage du trio

teinte/contraste/saturation, recadrage etc.). On peut les activer pour VLC en utilisant

l'option suivante: --filter filter1, filter2,...

• Modules de sortie audio

Ces modules permettent de choisir le système de sortie du son. VLC essaie de deviner

le module de sortie audio le plus adapté au système. On peut toutefois forcer

l'utilisation d'un module spécifique.

2.4.3.2 Options de compilation

Il y a quelques options qu’on peut régler par les scripts de configuration, qui ne sont

pas liées aux modules. Par exemple, on peut régler les répertoires d'installation et le système

sur lequel on désire compiler VLC (normalement automatique), ...

2.4.4 Méthode de diffusion VLC

2.4.4.1 Utilisation de la ligne de commande

2.4.4.1.1 Architecture modulaire

Le stream output possède une puissante architecture qui utilise des modules. Chaque

module apporte des fonctionnalités, et il est possible de chaîner les modules pour combiner

plusieurs possibilités. Voici la liste des modules disponibles :

standard :"Envoie" le flux grâce à un module de sortie: par exemple, UDP, fichier,

HTTP, ... on utilise ce module à la fin de chaînes.

transcode : Permet de transcoder à la volée l'audio et la vidéo de notre flux d’entrée.



duplicate : Permet de créer une seconde chaîne dans laquelle le flux sera traité

séparément.

display : nous permet d'afficher le flux d'entrée, comme VLC le ferait normalement.

Utilisé avec le module duplicate, il nous permet de voir le flux en même temps que

nous l’envoyons.

es : nous permet de séparer les flux élémentaires (ES) d'un flux d’entrée.

2.4.4.1.2 Syntaxe

La syntaxe employée pour la diffusion est composée de plusieurs champs qui sont le

flux d’entrée, les modules utilisés et les différentes options pour chaque module. Ce syntaxe a

la forme suivante : « vlc input_stream --sout '#module1 {option1=..., option2=...}:#module2

{option1=..., option2=...}:...' ».

L’exemple ci-dessous illustre les opérations de transcodage et d’envoi des flux :

«vlc input_stream --sout '#transcode{options}:#standard{options}' ».

Chacun de ces modules peut prendre différentes options :

• access: comment envoyer file, udp, rtp, http,

• mux: quel multiplexeur (format) utiliser ? Doit être: avi (format AVI) ogg (format

Ogg) ps (format MPEG2-PS) ts (format MPEG2-TS),

• url: Si on utilise le fichier access, url désigne l'emplacement du fichier, sinon, il s’agit

de l'adresse IP multicast ou unicast,

• sap: Cette option est utilisé dans le cas d'access udp ou rtp, on emploi celle là pour

annoncer le flux par SAP/SDP (mini serveur). L'option contient le nom sous lequel le

programme sera annoncé.

On remarque que si on utilise le multicast, on peut utiliser l'option globale –TTL t pour

régler le TTL avec les options réseaux :

• --server-port <entier> pour règler le port UDP,

• --iface <chaîne> pour spécifier l'interface réseau à utiliser,

• --iface-addr <chaîne> pour spécifier l'adresse IP de l'interface réseau,

• --mtu <entier> pour spécifier le MTU de l'interface réseau,

• --ipv6 force l'utilisation d’IPv6,

--ipv4 force l'utilisation d’IPv4.

Notons que VLC inclut un petit serveur HTTP, qui lui permet de diffuser en HTTP, et

aussi de proposer une interface de contrôle à distance utilisant HTTP. Pour démarrer VLC

avec l'interface HTTP, il faut faire : « vlc -I http (--http-src /directory/ --http-host host:port) ».



L'interface HTTP se met en écoute sur le host dont le port est 8080 par défaut et

reproduit la structure de /directory sur http://host:port/.

La diffusion d’un fichier avec VLC se fait en exécutant la commande « vlc -vvv

video1.xyz --sout udp:192.168.0.42 --ttl 12 » où video1.xyz est le fichier à diffuser,

192.168.0.42 est soit l'adresse IP de la machine vers laquelle on désire diffuser en unicast, le

nom DNS de la machine vers laquelle on désire envoyer en unicast, une adresse IP multicast.

12 est la valeur du TTL (Time To Live) des paquets IP (cela signifie qu'ils pourront traverser

11 routeurs). Si on désire diffuser un continu, il faut ajouter l'option --loop.

2.4.4.2 Diffusion facile en utilisant l’interface graphique

Le plus facile pour commencer à diffuser avec VLC consiste à utiliser l'une des

interfaces graphiques utilisateur : wxWidgets pour Windows et GNU/Linux. Deux

méthodes sont disponibles, la première c’est d’utiliser l'Assistant et la deuxième le mode

graphique.

2.4.4.2.1 Diffuser en utilisant l'Assistant

L'assistant de Diffusion/Transcodage guide pas à pas pour diffuser le média sur un

réseau ou le sauvegarder sur le disque dur. Cet Assistant fournit des menus simples à

utiliser, mais les choix d'options sont restreints.

On note que l'assistant est seulement disponible depuis l'interface wxWidgets.

Pour démarrer l'Assistant de diffusion/transcodage, on ouvre le menu "Fichier", et on

sélectionne Assistant de diffusion.

Figure 2.3 : Démarrer l'assistant

Pour commencer, on sélectionne le type de tâche :

• Diffuser vers un réseau : Choisi si on veut diffuser un média sur un réseau.

• Transcoder/Sauvegarder : Choisi si on souhaite changer le codec d'un fichier

audio et/ou vidéo, son échantillonnage et/ou sa méthode d'encapsulation.



Figure 2.4 : La boîte de dialogue de l'Assistant

Maintenant, on sélectionne un flux (tel qu'un fichier, un flux réseau, un disque, un

périphérique de capture, ...) avec le bouton Choisir, ou un élément existant de la liste de

lecture avec l'option Elément de la liste.

Il y’a dans la Figure 1.5 l’option Extraction partielle : Pour lire uniquement une

partie du flux, on coche "Activer" et on choisit un début et une fin (en secondes). Cette

option ne doit être utilisée que dans le cas de flux qu’on peut contrôler, comme des

fichiers placés dans les disques, mais pas des flux réseaux ou des périphériques de

capture.

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



(a) (b)

Figure 2.6 : (a) Sélection de l'entrée depuis la liste de lecture par l'Assistant

(b) Sélection de l'entrée depuis fichier

Si on a choisit l'option Diffuser vers un réseau, on peut spécifier la méthode de

diffusion. Les méthodes de diffusion sont :

• UDP Unicast : Ici, il faut entrer l'adresse IP du client (dans la plage 0.0.0.0 -

223.255.255.255).

• UDP Multicast : Diffuser un flux vers plusieurs utilisateurs. Il faut entrer

l'adresse IP du groupe multicast (dans la plage 224.0.0.0 - 239.255.255.255).

Dans ce projet, on a utilisé 225.190.0.3 ou bien 225.190.1.1.

• HTTP : Diffuser en utilisant le protocole HTTP. Si on laisse le champ

Destination vide, VLC va attendre les connexions sur toutes les interfaces

réseaux du serveur sur le port 8080. On spécifie une adresse, un port et un chemin

pour les connexions en utilisant la syntaxe suivante [ip][:port][/path].

Par exemple, 192.168.0.1:80/stream va faire écouter VLC sur l'interface portant

l'adresse IP 192.168.0.1, sur le port TCP 80, dans le fichier virtuel /stream.



(a) (b)

Figure 2.7 : Méthode de diffusion par l'Assistant

(a) pour la diffusion en UDP multicast

(b) pour la diffusion en HTTP

On peut maintenant spécifier plusieurs options.

• Time To Live (TTL) : Ceci définit le nombre de routeurs que le flux peut traverser

avant d'être supprimé. Pour le multicast UDP, la valeur par défaut du TTL est 1, ce

qui signifie que le flux n'ira pas au-delà du premier routeur. On veut certainement

augmenter ce nombre si on souhaite que ce flux multicast soit routé.

• Annonce SAP : Elle sert à annoncer le flux sur le réseau. Quand on utilise une

méthode de diffusion UDP, en utilisant le protocole SAP, il faut entrer le nom du

flux dans le champ de texte et cocher la case correspondante. Ceci n’est pas

disponible pour la méthode de diffusion HTTP.



Figure 2.8 : Options de l'assistant de diffusion

Un clic sur Terminer commence la diffusion de la source.

2.4.4.2.2 Diffusion en mode graphique

Une deuxième façon de paramétrer une instance de diffusion avec VLC est d'utiliser

le menu Flux de sortie dans la boite de dialogue Ouvrir... des interfaces wxWidgets

(Windows / GNU Linux), skins (Windows / GNU Linux). Les options et les méthodes les

plus courantes de diffusion sont accessibles dans ce menu pour diffuser le media ouvert, il

faut cocher "flux de sortie" dans la boite de dialogue "ouvrir un fichier/disque/flux

réseau/périphérique de capture"et cliquer sur le bouton "paramètres".

Figure 2.9 : Diffusion du flux de sortie en mode graphique



Dans l'interface wxWidgets, un boite de dialogue affiche le MRL de flux de sortie

(Media Ressource Locator). Elle est mise à jour quand on modifie des options dans le menu

Flux de sortie.

On distingue plusieurs modes de diffusion :

• Jouer en local: affiche la diffusion à l'écran. Cela permet d'afficher le flux qu’on est

en train de diffuser. Les effets de transcodage, etc... peuvent être surveillés en local

avec cette fonction.

• Fichier: Sauvegarder la diffusion dans un fichier. L'option Dumper le flux brut

permet d'enregistrer le flux d'entrée en même temps qu'il est lu par VLC, sans aucun

traitement.

• HTTP: Pour utiliser la méthode de diffusion HTTP, il faut Spécifier l'adresse IP

ainsi que le numéro de port TCP à écouter.

• MMSH: Cette méthode d'accès permet de diffuser vers Microsoft Windows Media

Player. On doit Spécifier l'adresse IP ainsi que le numéro de port TCP à écouter.

Cela fonctionne seulement avec la méthode d'encapsulation ASF.

• UDP: Diffuse en unicast en donnant une adresse dans la gamme 0.0.0.0 -

223.255.255.255 ou en multicast en donnant une adresse dans la gamme 224.0.0.0 -

239.255.255.255 dans notre cas 225.190.0.3 ou bien 225.190.1.1. Il est aussi

possible de diffuser vers des adresses IPv6. Cela fonctionne seulement avec la

méthode d'encapsulation TS.

2.4.5 Autre solution possible pour un serveur VideoLAn : Serveur de

streaming VLS

2.4.5.1 Structure de VLS

De point de vue utilisateur, VLS peut être divisé en quatre composants majeurs:

• Un gestionnaire,

• Des entrées,

• Des convertisseurs,

• Des sorties.



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



• Le gestionnaire

Le gestionnaire contrôle l'envoi des flux. En utilisant une interface d'administration,

on peut lancer, arrêter, interrompre, ou reprendre les programmes. On peut également

afficher la liste des programmes disponibles, lire depuis le fichier de configuration de

VLS c'est pourquoi elle ne peut pas être changée après le démarrage.

Pour l'instant, on ne peut pas demander au gestionnaire si un flux est en cours de

diffusion, mais une erreur se produira si on tente de stopper un flux qui ne l'est pas.

2.4.5.2 Interface d'administration

Il existe deux moyens de contrôler VLS : la ligne de commande, l'interface Telnet.

Lorsqu’on utilise l'interface Telnet, on doit tout d'abord s’authentifier, car tous les utilisateurs

ne peuvent exécuter toutes les commandes. Une fois que VLS a démarré, il ne prend pas

d'arguments sur son entrée standard, et on peut le mettre en tâche de fond

2.5 Application SAGEM DVB ZAPPING Dans l’application il y a deux types de zapping : zapping de flux sur voie ip et zapping

de flux DVB-T. Cette api en cours de réalisation en langage C sous linux

2.5.1 L’API Linux DVB La norme DVB ne se contente pas à décrire le processus que doit suivre le signal entre

les phases d’émission et de réception mais elle précise aussi l'ensemble des routines à utiliser

pour programmer et configurer le décodeur. L’ensemble de ces routines destinées au décodeur

fonctionnant avec système d’exploitation Linux, est connu sous le nom de Linux DVB API.

Une carte DVB PCI ou encore DVB set-top-box (STB) est généralement constituée de six

composants. Comme la montre la figure suivante, ces composants sont :

● Le frontend : il représente le tuner et le démodulateur de DVB. Ici le signal atteind le

matériel de DVB à partir d'une antenne parabolique ou directement du câble. Le frontend

abaisse la fréquence du signal et le démodule, ensuite, dans un flux de transport MPEG

(TS),

● Le contrôle d'accès (CA):

Le flux complet est passé par l'unité de contrôle d'accès. Les programmes auxquels

l'utilisateur a accès sont décodés en temps réel et réinsérés dans le Transport Stream (TS),

● Le démultiplexeur (Demux): Il filtre le flux entrant. Le démultiplexeur découpe le

transport stream suivant ses composants comme les stream audio et vidéo. En plus de ce

flux, se rajoutent des flux de données contenant des informations sur les programmes

offerts dans ce flux ou dans d'autre flux du même fournisseur,



● Décodeurs MPEG de l'audio et de la vidéo : Le flux démultiplexé passe ensuite dans les

décodeurs MPEG audio et vidéo dont le traitement est spécifique à chaque flux. Après leur

décodage et décompression, les flux passent soit à l'ordinateur soit au poste de télévision

via l'interface PAL/NTSC.

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



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).



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.



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



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



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


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



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 ) :



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)



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.



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.



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



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



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



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.



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.



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



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



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]



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



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 :



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.



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.



Figure 3.13: scénario proposé



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


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


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


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.

dardouri ghazi

Documents