Travail de Bachelor 2017

Compression Audio d’un flux Dante™

Etude

Compression Audio d’un flux Dante™ sur une FPGA.

Auteur : Conseiller : Lambert Vincent Mosqueron Romuald

De Juillet à Septembre 2017 Centre Formation de Base

Travail de Bachelor

Préambule

Ce travail de Bachelor est réalisé en vue de l'obtention du titre de Bachelor of Sciences en Ingénierie.

Son contenu, sans préjuger de sa valeur, n'engage ni la responsabilité de l'auteur, ni celles du jury du travail de Bachelor et de l'Ecole.

Aucune utilisation, même partielle, de ce travail ne peut être faite sans l'autorisation écrite préalable de la Direction. Toutefois, l'entreprise ou l'organisation qui a confié un sujet de travail de Bachelor peut utiliser les résultats du travail pour ses propres besoins.

Doyenne du Centre Formation de Base

L. Larghi

Yverdon-les-Bains, novembre 2016

______HEIG-VD, av. Sport 20, 1401 Yverdon-les-Bains Tél. 024/557 76 09 / 07 Fax : 024/557 76 01

Lambert Vincent 29 septembre 2017

Remerciements

Pour commencer, je tiens tout particulièrement à remercier toutes les personnes qui m’ont aidé et qui ont contribué à l’élaboration de ce travail.

M. Romuald Mosqueron, professeur à la HEIG-VD, pour son suivi et ses précieux conseils.

M. Gaëtan Matthey, ingénieur R&D, pour ses conseils avisés.

M. Nicolas Sturmel, Senior Technologist chez Merging Technologies, pour sa disponibilité et ses infor- mations concernant ANEMAN.

Mme Lucile Roux, Mme Melissa Amantini et Mme Nathalie Maillard pour leur aide précieuse dans la relecture de ce document.

Pour terminer, je remercie encore toutes les personnes qui ont oeuvré pour ce travail d’une quelconque façon.

Version 2.0 page: 4 Lambert Vincent Table des matières 29 septembre 2017

Table des matières

Remerciements 4

1 Introduction 9 1.1 Présentation du mandant...... 9

1.2 Contexte...... 9

1.3 Objectif du projet...... 10

1.4 Acteur concerné...... 11

1.5 Déroulement du projet...... 12

2 Cahier des charges 13 2.1 Objectifs...... 13

2.2 Risques identifié lors de la pré-étude...... 14

2.3 Description des phases du projet...... 15

2.3.1 Principes théoriques...... 15

2.3.2 Analyse de la mission...... 15

2.3.3 Gestion des risques rencontrées...... 15

2.3.4 Nouveau concept innovant à haut niveau...... 15

2.3.5 Technologie intéressante pour notre concept...... 15

2.3.6 Implémentation du concept...... 15

2.3.7 Conclusion...... 16

2.4 Organisation...... 16

2.4.1 Gestion des documents...... 16

2.4.2 Gestion de projet...... 16

2.4.3 Planification...... 16

3 Principe théorique 17 3.1 Modèle OSI...... 17

3.2 Ethernet...... 18

3.2.1 Composition d’une trame Ethernet standard...... 18

3.3 Signal analogique et numérique...... 20

Version 2.0 page: 5 Lambert Vincent Table des matières 29 septembre 2017

3.4 Le système Dante™ ...... 22

3.4.1 Caractèristiques du module Brooklyn-II...... 23

3.4.2 Composants essentiel du système Dante™ ...... 25

3.4.3 Fonctionnement du système Dante™ ...... 27

3.5 Le protocole AES 67...... 28

3.5.1 Différence par rapport au protocole Dante™ ...... 28

3.6 Avantages - Désavantage de Dante™et AES 67...... 29

3.7 TDM...... 30

3.8 Méthode de compression audio...... 31

3.8.1 La psychoacoustique...... 31

3.8.2 Compression G.722...... 33

3.8.3 Compression Opus...... 35

4 Analyse de la solution envisagée 37 4.1 Tests du système Dante™ ...... 37

4.1.1 Test effectué...... 37

4.1.2 Matériel utilisé...... 37

4.1.3 Séparation de l’audio Dante™ ...... 39

4.1.4 Comportement de la solution sur wifi...... 41

4.1.5 Blocage du port audio...... 42

4.1.6 Utilisation des header J6 pour acquisition audio externe...... 42

5 Gestion des risques rencontrés 43 5.1 Mesures prises...... 43

5.2 Redéfinition du cahier des charges...... 43

6 Nouveau concept Innovant à haut niveau 44 6.1 Définition du concept...... 44

7 Technologie intéressante pour notre concept 45 7.1 La technologie MPEG TS...... 45

7.1.1 Principe de compression vidéo...... 45

7.1.2 Flux élémentaire vidéo...... 46

7.1.3 Flux élémentaire audio...... 47

Version 2.0 page: 6 Lambert Vincent Table des matières 29 septembre 2017

7.1.4 Description des paquets PES...... 47

7.1.5 Description des paquets MPEG TS...... 48

7.2 ANEMAN™ ...... 49

8 Implémentation du concept 52 8.1 Fonctionnement de ANEMAN™ ...... 53

8.2 Description de l’implémentation...... 54

8.2.1 Création des fichiers JSON...... 54

8.2.2 Adaptation du programme DtmCmd v.1.4.0...... 54

8.3 Conclusion...... 54

9 Conclusion 55 9.1 Débriefing...... 55

9.2 Perspectives pour le futur...... 55

9.3 Conclusion personnelle...... 55

Bibliographie 58

A Dossier de gestion 59 A.1 Echéancier détaillé...... 59

A.2 Rendez-vous et contacts avec le Conseiller...... 59

B Annexe 61 B.1 Vision détaillée de RTP...... 61

B.2 Vision détaillée de RTCP...... 62

B.3 Prise en main du système Dante™ ...... 69

B.4 Test séparation de l’audio Dante™ ...... 74

B.5 Test comportement du système Dante™ sur wifi...... 78

B.6 Test blocage du port audio...... 80

B.7 Test audio externe...... 84

B.8 Fichier JSON...... 88

Datasheet DTM-3200...... 90

Datasheet DTU-245...... 91

Table des figures 92

Version 2.0 page: 7 Lambert Vincent Table des matières 29 septembre 2017

Table des tableaux 93

Version 2.0 page: 8 Lambert Vincent Chapitre 1. Introduction 29 septembre 2017

1 Introduction

1.1 Présentation du mandant

Nulink SA est une société suisse active depuis 2007, son siège est situé à Neuchâtel.

Elle est active dans le dévelopement de solution de broadcasting wireless.

Leurs solutions sont utilisées dans le cadre de broadcast d’événements sportifs tel que jeux olympiques, courses cyclistes, triathlon, marathon, courses automobiles et programme de divertissement mobile.

1.2 Contexte

Dans le monde du broadcasting, les caméras wireless sont de plus en plus utilisées. Cela s’explique par le fait qu’elles offrent une plus grande mobilité qu’une caméra filaire. Ces caméras wireless utilisent une tête RF 1pour transmettre leurs images et sons à la régie. Lors de grands événements, ces transmissions RF sont relayées via des avions relais. Une fois les données disponibles en régie, des techniciens traitent ces données en vue de leurs diffusions. Avant d’en arriver là, un technicien doit calculer le budget bande-passante. Pour un flux vidéo compressé, 8Mbit/s sont utilisés et 2 Mbit/s pour 2 canaux audios non-compressés. L’audio représente donc 1/5 du budget bande-passante. Cela n’a pas de sens et l’on comprend alors la volonté de la société Nulink de mettre en place une solution pour compresser et gérer l’audio de ces transmissions broadcast.

1. Radio-fréquence

Version 2.0 page: 9 Lambert Vincent Chapitre 1. Introduction 29 septembre 2017

1.3 Objectif du projet

Le but principal de ce projet est de rendre possible l’utilisation du protocole Dante™ sur une in- frastructure de réseau sans fil. Etant donné que la source de l’audio est sans fil, il est capital que notre projet puisse fonctionner en sans-fil. De plus, afin d’économiser des coûts de bande-passante, le système devra être capable de faire transiter de l’audio compressé.

En utilisant le système Dante™ , cela implique une dé-paquetisation du flux pour en extraire les trames audio, les compresser du côté émetteur et d’effectuer l’opération inverse du côté récepteur. L’opération doit rester transparente aux yeux de l’utilisateur final. De plus, les trames d’identification qui rendent Dante™ intéressant seront aussi transmises pour garder le côté interopérabilité et plug- n-play du protocole. La compression devra être de très basse latence pour pouvoir permuter entre sans-fil et filaire sans que le spectateur ne s’en rende compte. [1]

Figure 1.1 – Réseau Dante™standard [1]

Version 2.0 page: 10 Lambert Vincent Chapitre 1. Introduction 29 septembre 2017

1.4 Acteur concerné

Responsable de la section informatique en sys- Conseiller de projet tème embarqué communicant Bernard Collet Romuald Mosqueron Professeur HEIG-VD Professeur HES associé Dr ès sciences physique Dr ès Image Instrumentation and Informatic [email protected] [email protected] 024/ 557 61 55 Répondant pour les questions administratives Laurent Zwahlen Directeur [email protected] 079/ 326 32 10 Réalisateur du projet Vincent Lambert Etudiant en informatique section système embarqué communicant et technicien en architecture réseaux fibres optiques chez FTTH-FR à Bulle [email protected] 078 /629 29 15

Version 2.0 page: 11 Lambert Vincent Chapitre 1. Introduction 29 septembre 2017

1.5 Déroulement du projet

L’Etude a été divisée en plusieurs phases, chaque point ci-dessous correspondant à un chapitre de cette étude :

Création du cahier des charges

Principes théoriques

Analyse de la mission

Gestion des risques rencontrés

Nouveau concept innovant à haut niveau

Analyse du concept

Implémentation du concept

Conclusion

Figure 1.2 – Déroulement de l’étude

Version 2.0 page: 12 Lambert Vincent Chapitre 2. Cahier des charges 29 septembre 2017

2 Cahier des charges

2.1 Objectifs

Afin de mener à bien ce projet, trois objectifs-clés ont été ciblés. 1. Etude du protocole Dante™au moyen de Wireshark. 2. Choix d’une solution appropriée aux problèmes. 3. Conception d’une IP 1 permettant de compresser / décompresser un flux audio. 4. Réalisation d’une preuve de faisabilité de la solution. 5. Création d’une IHM permettant de piloter la solution. Voici ci-dessous les contraintes de ce projet : 1. Le traitement doit rester invisible aux yeux de l’utilisateur. 2. Utilisation d’un protocole de compression basse latence. 3. Langage de programmation C ou C++. 4. Implémentation sur FPGA Zynq.

1. Intellectual Property

Version 2.0 page: 13 Lambert Vincent Chapitre 2. Cahier des charges 29 septembre 2017

2.2 Risques identifié lors de la pré-étude

Dans la pré-étude qui a été rédigée de mai à juin 2017, des risques avaient été identifiés. Nous retrouvons un descriptif de ces risques dans les tableaux 2.1 ainsi qu’une représentation matricielle AMDEC 2 2.2

Table 2.1 – Risques identifiés

Table 2.2 – Représentation AMDEC

2. Analyse des Modes de Défaillance, de leurs Effets et de leur Criticité

Version 2.0 page: 14 Lambert Vincent Chapitre 2. Cahier des charges 29 septembre 2017

2.3 Description des phases du projet

2.3.1 Principes théoriques

Cette première étape consiste à étudier les principes qui régissent la mise en place d’un réseau AoIP 3

Afin de bien pouvoir comprendre le fonctionnement des systèmes de diffusion de contenus audio sur les réseaux privés, les protocoles et principes suivants seront analysés :

• Modèle OSI • Ethernet

H Unicast

H Multicast • Signal analogique et numérique • Dante™ • AES 67 • TDM • Méthode de compression audio

2.3.2 Analyse de la mission

Dans ce chapitre, une étude a été effectuée pour vérifier que le système Dante répondait à nos attentes.

2.3.3 Gestion des risques rencontrées

Dans cette section, il est décrit comment les risques rencontrés dans ce projet ont été gérés.

2.3.4 Nouveau concept innovant à haut niveau

Cette quatrième étape a pour but de définir un concept à haut niveau.

2.3.5 Technologie intéressante pour notre concept

Dans cette étape, nous avons recherché des technologies et méthodes qui nous aideraient à mettre en place le concept.

2.3.6 Implémentation du concept

Cette étape va consister à prouver la vivabilité du concept.

3. Audio over IP

Version 2.0 page: 15 Lambert Vincent Chapitre 2. Cahier des charges 29 septembre 2017

2.3.7 Conclusion

Finalement, je vais capitaliser ce projet. Cela consiste à vérifier le respect du cahier des charges, enumérer les difficultés rencontrées, donner les perspectives d’amélioration du projet, de tirer une conclusion personelle sur ce projet et finalement de remercier toutes les personnes qui m’ont aidé dans la réalisation de ce projet.

2.4 Organisation

2.4.1 Gestion des documents

Toute la documentation ainsi que les rendus de documents (rapports, invitations aux séances, PV, etc....) seront stockés sur Dropbox.

Les codes sources, les exécutables et la documentation seront stockés sur le Github de l’institut Re- configurable & Embedded Digital Systems(ReDS) de la HEIG-VD. Ce dépôt est réservé aux membres du projet.

2.4.2 Gestion de projet

La méthodologie de gestion de projet durant l’étude sera une approche de type AGILE. La durée d’un sprint est d’une semaine.

2.4.3 Planification

Afin d’aboutir à une réussite de ce projet et d’avoir une bonne gestion du temps, une planification a été réalisée. Une marge de sécurité a été prévue pour certains jalons, afin de pouvoir faire face à des imprévus ou des risques mentionnés qui seraient rencontrés.

Version 2.0 page: 16 Lambert Vincent Chapitre 3. Principe théorique 29 septembre 2017

3 Principe théorique

La phase principe théorique va constituer à appronfondir les différents protocoles et notions qui consti- tuent un réseau AoIP. Le fonctionnement de ce ces protocoles sera défini afin d’avoir une bonne vision des différents protocoles permettant la mise en place d’une solution AoIP.

Dans une seconde étape, la tâche sera d’étudier les protocoles de compression basse-latence dispo- nibles sur le marché. Le principe de fonctionnement de ces protocoles sera détaillé.

3.1 Modèle OSI

Le modèle OSI a été conçu dans les années 70. Il est devenu une norme en 1984 (ISO 7498 :1984). L’objectif de cette norme est de codifier, donner un cadre général à la création de futur standard de communication. Le modèle comporte sept couches présentées ci-dessous :

Logiciel Application HTTP,FTP 7

Cryptage, Présentation MIME, XDR 6 Compression hautes Couches DNS, Session RPC,NetBIOS 5 Transaction

Datagrammes Transport TCP,UDP,RTP 4

Paquets, Réseau IPv4, IGMP 3 Routeur basses

Couches Ethernet, Trames, Pont Liaison 2 HDLC

Modem, Bit Physique 1 multiplexeur

Table 3.1 – Modèle OSI

Version 2.0 page: 17 Lambert Vincent Chapitre 3. Principe théorique 29 septembre 2017

3.2 Ethernet

Ethernet fait référence à un protocole de réseau local. Il a été pensé sur un système de commutations de paquets. Historiquement, il a vu le jour dans les années 1970 au Xerox PARC à Palo Alto en Californie. Ce centre de recherche est à la base de découvertes comme l’impression laser, l’ordinateur personnel, les premières interfaces graphiques, ...[1]

3.2.1 Composition d’une trame Ethernet standard

Une trame Ethernet est composée des parties ci-dessous :

Adresse de Adresse Type de Préambule Données CRC destination source trame 8 octets 6 octets 6 octets 2 octets 46 - 1500 octets 4 octets

Table 3.2 – Composition Trame Ethernet standard

Version 2.0 page: 18 Lambert Vincent Chapitre 3. Principe théorique 29 septembre 2017

Unicast : Il s’agit d’une connexion point à point, d’une adresse IP vers une autre adresse IP.

Figure 3.1 – Principe Unicast

Multicast : Il s’agit d’une méthode de diffusion multipoint, cela signifie que l’on a une adresse de diffusion unique vers plusieurs récepteurs.

Figure 3.2 – Principe Multicast

Cette méthode de diffusion utilise une plage d’adresses IPv4 bien définie, décrite ci-dessous :

Plage Description 224.0.0.0 - 224.0.0.255 Réseau local 224.0.1.0 - 224.0.1.255 Inter-réseaux 224.0.2.0 - 224.0.2.255 Ad-hoc 224.1.0.0 - 255.1.255.255 Non assigné 224.2.0.0 - 255.2.255.255 SDP/SAP 224.3.0.0 - 231.255.255.255 Non assigné 232.0.0.0 - 232.255.255.255 Source spécifique 233.0.0.0 - 233.255.255.255 GLOP 234.0.0.0 - 238.255.255.255 Non assigné 239.0.0.0 - 239.255.255.255 Usage privé libre

Table 3.3 – Plage IPv4 Multicast[2]

Le principe de diffusion multicast fonctionne avec des groupes de diffusion. Les clients de la diffusion gèrent leur appartenance à ces groupes de diffusions au moyen du protocole IGMP 1. Ce protocole implémente des méthodes d’abonnement Join et de désabonnement Leave. Ces méthodes permettent aux clients de s’abonner ou se désabonner à des flux multi-diffusés. 1. Internet Group Management Protocol

Version 2.0 page: 19 Lambert Vincent Chapitre 3. Principe théorique 29 septembre 2017

3.3 Signal analogique et numérique

Le terme signal analogique définit un signal continu qui comporte une infinité de valeurs, à contrario le signal numérique est un signal discontinu contenant une quantité finie de valeurs. Par exemple, dans le domaine de l’audio, un disque vinyle est un signal analogique, alors qu’un CD est un signal numérique. Pour passer du domaine analogique au domaine numérique, nous allons numériser le signal analogique.

Deux éléments doivent être définis correctement pour obtenir une numérisation de qualité :

— La quantification — La fréquence d’échantillonage

La quantification correspond au nombre de bits sur lequel les valeurs sont représentées. On l’appelle aussi résolution. Plus la résolution est grande, meilleure est la qualité du signal de sortie.

La fréquence d’échantillonage est le nombre d’échantillons par unité de temps. Si cette unité est la seconde, la fréquence d’échantillonage sera exprimée en hertz.

Afin que le signal de sortie demeure fidèle au signal d’entrée, il est nécessaire que la fréquence d’échan- tillonage soit assez grande. Le théorème de Shannon nous indique : «Pour reconstruire un signal de sortie de manières fidèle au signal d’entrée, il faut choisir une fréquence d’échantillonage au moins deux fois supérieure à la fré- quence maximale contenue dans le signal d’entrée. Voici son équation 3.1

fe > 2fmax (3.1)

Par conséquent, plus le son est aigu et plus la fréquence d’échantillonage devra être élevée. Au contraire avec un son grave elle pourra être plus faible.

Si cette règle n’est pas appliquée, du repliement spectral fait son apparition.

En résumé, la numérisation d’un signal analogique permet de garantir la qualité d’un signal ou de réduire la qualité du signal pour : — Diminuer le coût de stockage — Diminuer le coût de la numérisation — Diminuer les temps de traitement — Tenir compte du nombre de valeurs requises par l’application — Tenir compte des limitations matérielles [3]

Version 2.0 page: 20 Lambert Vincent Chapitre 3. Principe théorique 29 septembre 2017

Ci-dessous, dans la figure 3.3, la représentation d’un signal analogique et son équivalent en numérique.

Figure 3.3 – Représentation signal analogique et numérique

Version 2.0 page: 21 Lambert Vincent Chapitre 3. Principe théorique 29 septembre 2017

3.4 Le système Dante™

Dante™ fait référence à une technologie de réseau audio. Cette technologie a vu le jour en 2006 et a été développée par la société Audinate basée en Australie. Cette technologie permet aux différents périphériques présents sur un réseau de se détecter automatiquement, ayant pour avantage de simplifier la mise en oeuvre d’un système tout en évitant des disfonctionnements. Ce protocole peut tout autant transmettre un flux en unicast qu’en multicast. Il est à notifier que les données sont transmises en UDP. Celui-ci se situe dans la couche 4 du modèle OSI.

Version 2.0 page: 22 Lambert Vincent Chapitre 3. Principe théorique 29 septembre 2017

3.4.1 Caractèristiques du module Brooklyn-II

Etant donné que l’un des objectifs primaires de ce travail de Bachelor est d’étudier le protocole Dante™, on peut aisément comprendre que nous connaissons peu de choses sur ce protocole étant donné qu’il s’agit d’un protocole propriétaire. La couche Dante™ est ajoutée au moyen de modules vendus par Audinate. Pour les différentes analyses et tests, nous avons utilisé le module Brooklyn-II implémenté sur le PDK 2 d’Audinate a été utilisé. Voici ses caractéristiques :

Figure 3.4 – Schéma de principe module Brooklyn II [4]

Sur la figure 3.4 les éléments en vert sont les données disponibles pour la partition utilisateur de la FPGA du module Brooklyn-II

2. Product Development Kit

Version 2.0 page: 23 Lambert Vincent Chapitre 3. Principe théorique 29 septembre 2017

Figure 3.5 – Spécifications module Brooklyn II[4]

Version 2.0 page: 24 Lambert Vincent Chapitre 3. Principe théorique 29 septembre 2017

3.4.2 Composants essentiel du système Dante™

Selon la documentation technique disponible sur le site d’Audinate, ainsi que suite aux différentes analyses effectuées, ce protocole a besoin de trois éléments pour fonctionner correctement :

Le protocole PTP

Il s’agit d’un protocole de synchronisation Ethernet. Il a été défini pour la première fois en 2001 par l’IEEE. Son principe de fonctionnement se base sur un système d’une horloge maître et de plusieurs horloges esclaves (selon le nombre de périphériques). Son fonctionnement est expliqué dans la figure 3.6

Figure 3.6 – Fonctionnement du protocole PTP[5]

• Horloge maître génère un message Sync à 100s. il est envoyé à 101s du fait des latences. • L’esclave reçoit le message Sync 2 secondes plus tard à 83s (temps locale de l’esclave). • Un message de suivi est envoyé par le maître à 103s. Ce message contient contient l’horodatage précédent soit 101s. • Ce message de suivi est reçu par l’esclave 2 secondes plus tard à 85s. L’esclave extrait la valeur 101s du message et déduit son horodatage (83s), générant ainsi un écart de calcul de 18 secondes. Cet écart est alors ajouté à l’heure actuelle et génère une heure d’horloge ajustée à 103 secondes. Toutefois, les horloges ne sont pas totalement synchronisées. La correction ne tient pas compte du retard accumulée sur le réseau. Voici maintenant le calcul du délai de réseau : • L’esclave envoie un message de demande du délai au maître à 108s. • Le maître reçoit et enregistre ce message à 112s. • Un message de réponse du délai est envoyé à l’esclave. Ce message indique 112s, heure à laquelle le message de demande de délai a été reçu.

Version 2.0 page: 25 Lambert Vincent Chapitre 3. Principe théorique 29 septembre 2017

• L’esclave reçoit ce message à 115s. L’esclave est maintenant capable de déterminer le délai du réseau en déduisant l’heure à laquelle il a envoyé la demande du délai (108s) de l’heure à laquelle le maître à reçu la réponse du délai (112s). Obtenant ainsi un délai de 4 secondes. Toutefois, comme deux messages ont été envoyés, il divise cette valeur par 2 pour obtenir 2 secondes. • L’esclave applique alors cette correction de 2 secondes pour obtenir une valeur d’horloge de 117s devenant ainsi parfaitement synchrone avec le maître. • Cette opération est répétée périodiquement afin de palier aux décalages des horloges.

Dante™ConMon

Il s’agit d’un mini-protocole interne au protocole Dante™. Il permet de contrôler les équipements et de les interroger. Il existe plusieurs types de messages, les voici :

Figure 3.7 – Type de message ConMon[6]

ConMon annonce les ports d’écoute des différents services ainsi que les adresses IP et caractéristiques des cartes via mDNS 3. 3. Multicast Domain Name System

Version 2.0 page: 26 Lambert Vincent Chapitre 3. Principe théorique 29 septembre 2017

Données Audio

Bien évidemment pour fonctionner, ce protocole a besoin de données Audio. Sans quoi il n’y a pas lieu de l’utiliser. Les formats d’encodages supportés sont :

— 32 bits PCM — 24 bits PCM — 16 bits PCM — 32 bits Custom (sur demande)

Le système Dante utilise un port distinct pour les données Audio, Ce port est annoncé par mDNS tout comme l’adresse IP et les différentes capacités de la carte. Dans la figure 3.8, chaque point de la courbe est représenté par un échantillon. Pour un taux d’échan- tillonage à 48 [kHz], nous aurons donc 48’000 batonnets par seconde.

Figure 3.8 – Représentation d’un signal Audio PCM[7]

3.4.3 Fonctionnement du système Dante™

Le système Dante™met en commun les trois éléments vu dans le point 3.4.2. Selon le manuel de la carte Brooklyn-II [4], il effectue ces opérations ainsi : • Données audio : Les données audios sont émises à un temps qui est défini selon le taux d’échan- tillonage sélectionné. • ConMon : Le protocole ConMon permet de connaître les périphériques qui se connectent, de les configurer et de connaître leur statut. Ces informations sont transmises à intervalles régulier. • PTP : Lorsqu’on connecte une première carte, celle-ci est automatiquement définie en tant que maître. A la connection d’une seconde carte des informations sur la qualité de l’horloge sont

Version 2.0 page: 27 Lambert Vincent Chapitre 3. Principe théorique 29 septembre 2017

échangées via ConMon. L’horloge avec la meilleure stabilité est définie comme maître ou celle qui a été définie comme maître par l’utilisateur. S’en suive des messages PTP pour synchroniser les périphériques entre eux. Ces messages sont renvoyés périodiquement.

3.5 Le protocole AES 67

Ce protocole réseau Audio a le même principe de fonctionnement que le protocole Dante™à quelques différences prés. Il a été créé par le groupe AES X192 au mois de novembre 2013. Il est à noter que le module Brooklyn-II supporte AES 67.

3.5.1 Différence par rapport au protocole Dante™

La différence majeure est que contrairement au protocole Dante™ qui utilise de l’UDP pour le trans- port, l’AES 67 utilise les protocoles RTP et RTCP comme moyen de transport.

RTP

Ce protocole fournit un moyen uniforme pour transmettre des données qui comprennent des contraintes temps réel. Il est classé dans la couche 4 du modèle OSI. Il permet : — L’identification du type d’information transportée. — L’ajout de marqueurs temporels à des fins de synchronisation. — L’inclusion de numéros de séquence afin de détecter la perte de paquets.

Dans les tableaux ci-dessous, respectivement le format du paquet RTP 3.4 et son en-tête B.1

En-tête RTP (12 octets) Payload

Table 3.4 – Format du paquet RTP[8]

RTCP

Il s’agit du protocole qui permet la mise en oeuvre des sessions RTP.

Ce système de contrôle offre trois fonctions : • Sa fonction principale permet de collecter les statistiques sur la qualité de la session RTP. • RTCP fournit un identificateur canonique (CNAME) à tous les participants de la session RTP. Bien qu’un identificateur de source (SSRC) d’un flux RTP devrait être unique, celui-ci peut changer en cours de session. Le CNAME permet une identification unique des participants au sein de la même instance. • RTCP gère lui-même la bande-passante de la session. La bande passante RTCP ne devrait pas dépasser 5% de la bande passante de la session. 25% de la bande passante RTCP devrait être réservé aux média, ceci afin que lorsqu’il y a beaucoup de participants au sein de la même session, tout nouveau participant reçoive les CNAME des expéditeurs dans un délai raisonnable. 5 paquets RTCP ont été définis dans la Norme :

Version 2.0 page: 28 Lambert Vincent Chapitre 3. Principe théorique 29 septembre 2017

• SR : Sender Report, transmission de statistiques des participants actifs en émission. • RR : Receiver Report, transmission de statistiques des participants passifs. • SDES : Source Description items (CNAME, NAME, EMAIL, PHONE,....) • BYE : Fin de participation • APP : fonctions spécifiques à l’application RTCP commence par une en-tête fixe, suivie des éléments propre au type de paquets, toutefois la taille limite est de 32 bits.

3.6 Avantages - Désavantage de Dante™et AES 67

Voici ci-dessous deux tableaux (3.5 et 3.6) résumant les avantages et désavantages de ces deux proto- coles.

Dante™ Avantages Désavantages Meilleur taux d’échantillonage (192 kHz) Protocole fermé Audio en profondeur 32 bits (quantification) Coût des modules

Table 3.5 – Avantages et Désavantages de Dante™

AES 67 Avantages Désavantages Protocole ouvert Taux d’échantillonage limité à 96kHz Compatible avec la plupart des équipements sur le marché Audio en profondeur maximale de 24 bits

Table 3.6 – Avantages et Désavantages de AES 67

Pour résumer, je dirais que si nous ne sommes pas trop limités au niveau financier notre choix devrait se tourner vers le système Dante™ qui offre une meilleure qualité audio. Toutefois, il existe un risque important dans ce projet que nous n’arrivions pas à comprendre le fonctionnement du système Dante™. Dans ce cas, notre choix devra se tourner vers AES 67.

Version 2.0 page: 29 Lambert Vincent Chapitre 3. Principe théorique 29 septembre 2017

3.7 TDM

TDM ou Time Division Multiplexing est un processus de communication qui transmet deux ou plu- sieurs signaux au sein d’un même canal. Dans le système TDM, les signaux sont divisés en portions de temps équivalentes. Après multiplexage, ces signaux sont transmis et réassemblé en leur signaux d’origine après dé-multiplexage.

Ce procedé peut être utilisé pour des signaux analogiques ou numériques. Il est toutefois plus adapté pour des signaux numériques.

TDM est asynchrone, cela permet une optimisation de la bande passante.

Ci-dessous un schéma de principe de son fonctionnement 3.9.

Figure 3.9 – Schéma de principe TDM [9]

Version 2.0 page: 30 Lambert Vincent Chapitre 3. Principe théorique 29 septembre 2017

3.8 Méthode de compression audio

Ce point a pour but de présenter les principes de bases régissant la compression audio.

3.8.1 La psychoacoustique

Qu’est ce que la psychoacoustique ? Il s’agit de la branche psychophysique étudiant le sens de l’ouïe. Elle définit, qualifie et quantifie les sensations auditives mises en rapport avec les propriétés physiques des sons qui les provoquent.

La psychoacoustique est à la limite entre l’acoustique, la physiologie et la psychologie.[10]

L’une des notions principales de la psychoacoustique est le phénomène de masquage, qui définit qu’un son peut cacher un autre son partiellement ou entièrement.

On parle alors de : — Sons masquants, audibles. — Sons masqués, et donc inaudibles. Le principe de la compression psychoacoustique est donc le fait de ne pas conserver ces sons inaudibles. On parle alors de compression avec pertes mais sans perte perceptible.

On peut appliquer ce principe de 2 façons : — Fréquentiel — Temporel

Le masquage fréquentiel

3 sons partiels avec des fréquences proches pourraient se masquer 3.10.

Figure 3.10 – 3 sons partiels avec fréquences proches

Par conséquent, tous les sons dont l’amplitude est inférieure au masque total sont inaudibles (voir 3.11). Pour plus de détails, voir :[11]

Version 2.0 page: 31 Lambert Vincent Chapitre 3. Principe théorique 29 septembre 2017

Figure 3.11 – Représentation des masques et des fréquences

Version 2.0 page: 32 Lambert Vincent Chapitre 3. Principe théorique 29 septembre 2017

Le masquage temporel

Le masquage temporel apparait lors de fortes variations du signal : l’oreille ne perçoit plus les sons faibles précédents et suivants immédiatement un son de forte intensité. On parle alors de : • Post-masquage : Perte de sensibilité -10[dB] et +100[ms] autour de cette fréquence. • Pré-masquage : Masquage actif -5[ms] avant que le son masquant n’apparaisse. Une représentation est disponible ci-dessous 3.12. Toutefois, cette méthode étant difficile à modéliser, elle est rarement utilisée.

Figure 3.12 – Représentation d’un masquage temporel

Pour plus d’informations voir :[11]

Méthode pour compression avec masquage fréquentiel

Deux techniques mathématiques sont utilisées pour la compression audios. Il s’agit de : • La DCT 4, qui permet de quantifier l’énergie contenu dans un signal et ainsi de supprimer les signaux avec peu d’énergie. • La FFT 5, qui permet de transformer les données discrètes du domaine temporel dans le domaine fréquentiel et ainsi d’identifier les fréquences qui ne nous intéressent pas. A la suite de ces opérations, un seuil ou quantification est défini et les données ne respectant pas ce seuil sont détruites. On parle alors de compression avec perte.

3.8.2 Compression G.722

G.722 est une norme de codage qui a été normalisée par l’UIT-T 6 en 1987. Cette méthode de com- pression permet d’avoir une voix sur IP 7 de qualité haute définition. Cette qualité vient du fait que l’on a doublé la bande de fréquence (50-7000[Hz]) par rapport à la bande usuelle (300-3400[Hz])[12].

Principe de fonctionnement

Ce protocole utilise le même débit que son prédécesseur, le G.711, 64[kbit/s]. Son fonctionnement consiste à séparer les parties de basse fréquence(0-4[kHz]) des parties de haute fréquence (4-8[kHz]) grâce à un filtrage QMF 8. Par la suite, un codage MICDA 9 est appliqué.

4. Transformée en cosinus discrète 5. Transformée de Fourier rapide 6. Union internationale des télécommunications 7. Internet Protocol 8. Filtre miroir en quadrature 9. Modulation par impulsion et codage différentiel adaptif

Version 2.0 page: 33 Lambert Vincent Chapitre 3. Principe théorique 29 septembre 2017

Ci-dessous, le schéma de principe du fonctionnement de G.722 3.13

Figure 3.13 – Schéma de principe G.722[12]

G.722 est-il adapté à notre projet ?

Comme nous utilisons une bande de fréquence allant de 50 - 7000[Hz], cela convient pour tout ce qui est de la voix. En revanche, comme on peut le voir dans la figure3.14, cela n’est pas le protocole idéal pour la compression de la musique. Si dans le futur le projet devait uniquement diffuser de la voix cela pourrait convenir. Toutefois, en cas de diffusion de musique ce protocole ne serait pas adapté.

Figure 3.14 – Largeur de bande G.722[13]

Version 2.0 page: 34 Lambert Vincent Chapitre 3. Principe théorique 29 septembre 2017

3.8.3 Compression Opus

Opus se prénommait à l’origine Harmony. Il s’agit d’un format ouvert développé par l’IETF 10. Il a été standardisé le 10 septembre 2012.

Principe de fonctionnement

Il utilise deux algorithmes distincts. SILK, qui a été créé par Skype et qui s’oriente sur la voix humaine, et CELT, créé par la fondation Xiph.org qui, lui, est orienté sur la musique. Opus va donc sélectionner l’algorithme le plus adapté en fonction de la bande passante disponible et du type de son qu’il doit transmettre. Son fonctionnement est décrit dans le RFC 6716.

Ci-dessous le principe de fonctionnement de Opus3.15

Figure 3.15 – Schéma de principe Opus[14]

SILK utilise un algorithme LPC 11. Son principe repose sur le postulat qui indique que la parole peut être modélisée par un processus linéaire. Cet algorithme va donc prédire le signal au temps [t] grâce aux [n] échantillons précédents.

CELT, quant à lui, utilise une DCT 12 modifiée. [14]

Opus peut fonctionner en trois modes distincts : • SILK only : utile pour la voix uniquement. • CELT only : utile pour la musique. • Hybrid mode : Opus va utiliser CELT pour les hautes fréquences (> 8 [kHz]) et il utilisera SILK pour les basses fréquences (< 8[kHz]).

Opus est-il adapté à notre projet ?

Opus pourrait convenir pour ce qui est de la partie compression de notre projet. Il est capable de gérer autant la voix seule, la musique seule ainsi qu’une combinaison des deux.

Comme on peut le voir sur la figure 3.16 ci-dessous, Opus couvre un large spectre de débit.

10. Internet Engineering Task Force 11. Codage prédictif linéaire 12. transformée en cosinus discrète

Version 2.0 page: 35 Lambert Vincent Chapitre 3. Principe théorique 29 septembre 2017

Figure 3.16 – Comparaison méthode de compression audio[15]

Version 2.0 page: 36 Lambert Vincent Chapitre 4. Analyse de la solution envisagée 29 septembre 2017

4 Analyse de la solution envisagée

Dans cette phase, il a été étudié si le système Dante répondait à nos attentes.

4.1 Tests du système Dante™

L’avantage du système Dante™ pour notre projet réside dans le fait de pouvoir gérer les flux audios sans pratiquement aucune configuration préalable vu que les périphériques échanges ces informations via ConMon. Différents tests ont été effectués pour valider que le système Dante™ était adapté à ce projet.

4.1.1 Test effectué

Voici ci-dessous une liste des tests effectués et la raison de la réalisation du test. Une conclusion est faite à la fin de chaque test. • Séparation de l’audio Dante™ : Ce test a été réalisé afin de comprendre comment les paquets audios était construits. Nous avions besoin d’avoir cette information, car dans notre première approchent nous voulions effectuer une compression après le passage dans Dante™. • Comportement de la solution sur wifi : Comme le projet est destiné à être utilisé dans un en- vironnement wireless, il est important de vérifier que la solution est utilisable sur une telle configuration. • Blocage du port audio : Ce test a pour but de vérifier s’il est possible de bloquer le port audio sans que cela affecte les autres fonctions du système Dante™. Si le test s’avère réussit nous aurions une solution de secours pour faire transiter l’audio sans passer par Dante™. • Acquisition audio externe : Ce test va vérifier que comme le spécifie la documentation de la carte Dante PDK [16], il est possible de fournir des données audios via les connecteurs J6 de la carte. Cela nous permettrait d’avoir une solution plus propre que d’effectuer une compression après le passage dans Dante™.

4.1.2 Matériel utilisé

Vous trouverez ci-dessous le matériel qui a été utilisé lors des tests. Si pour certains tests du matériel supplémentaire a été nécessaire, vous trouverez son descriptif dans le point se rapportant au test en question.

• 2 cartes Dante Brooklyn-II PDK • 1 switch CISCO SG1 10D-08HP • 1 Ordinateur Intel Core i7-4790 3.6GHz 16 GB RAM fonctionnant sous Windows 10 64 bits

Version 2.0 page: 37 Lambert Vincent Chapitre 4. Analyse de la solution envisagée 29 septembre 2017

Installation du matériel

Dans la figure ci-dessous 4.1, on retrouve le schéma de principe de l’environnement utilisé. Comme vous pouvez le voir il n’y a pas de routeur, nos périphériques avaient donc des IP en 169.254.X.X. Ce choix a été fait pour éviter tout problème d’adressage IP et de configuration du routeur. Une prise en main rapide du système Dante™ est disponible en Annexe B.3.

Figure 4.1 – Schéma de principe environnement de test

Version 2.0 page: 38 Lambert Vincent Chapitre 4. Analyse de la solution envisagée 29 septembre 2017

4.1.3 Séparation de l’audio Dante™

Ce test a pour but de démontrer s’il est possible de séparer l’audio à l’intérieur des paquets UDP de Dante™. Ce test a été réalisé avec un flux multicast et un taux d’échantillonage à 48kHz en PCM 24 et 2 canaux. Il est à relever que lors de transmission multicast le port 4321 est utilisé, partant d’une carte Brooklyn-II PDK et dans un second temps depuis la solution DVS 1 de Dante™ qui permet de simuler un périphérique Dante™ depuis un ordinateur. La marche à suivre pour reproduire le test est disponible dans l’annexe B.4

Analyse Wireshark

Sur les captures wireshark ci-desssous figures 4.2, 4.3, 4.4 on constate que le premier octet reste systématiquement à 0x02, 8 octets suivant s’incrémentent systématiquement de 16 à chaque paquet. Pour arriver à 1 seconde de transmission, il a fallu 3017 trames transmises.

Figure 4.2 – Capture multicast Dante au temps 0.0

1. Dante Virtual Soundcard

Version 2.0 page: 39 Lambert Vincent Chapitre 4. Analyse de la solution envisagée 29 septembre 2017

Figure 4.3 – Capture multicast Dante au temps 0.000082

Figure 4.4 – Capture multicast Dante au temps 0.000082

Version 2.0 page: 40 Lambert Vincent Chapitre 4. Analyse de la solution envisagée 29 septembre 2017

Si nous faisons le calcul suivant 4.1. 3017 ∗ 16 = 48272 (4.1) Nous retombons sur environ 48’000 échantillons par seconde, ce qui correspond à notre fréquence d’échantillonage. Ces 8 octets correspondent donc au nombre d’échantillons transmis, sa valeur initiale est aléatoire. De plus, nous avons un delta temps d’environ 3.14 ∗ 10−4[s] entre chaque trame. Comme nous avons 16 échantillons par trame, nous faisons :

3.14 ∗ 10−4 = 1.9625 ∗ 10−5 (4.2) 16 L’équation 4.2 nous donne la période pour un échantillon. Pour passer de la période à la fréquence nous faisons : 1 = 50955.41 (4.3) 1.9625 ∗ 10−5 Nous voyons dans l’équation 4.3 que nous arrivons pratiquement sur la fréquence d’échantillonage de 48 [kHz]. Le même test a été effectué avec DVS, il s’est avéré qu’avec DVS le nombre d’échantillons par trame était de 48. Suite à ces captures, j’ai émis l’hypothèse que les données audios commençaient au neuvième octet. Cela s’est avéré correct et a été démontré dans l’application de test «Separa- teur_Audio.exe.». Le déroulement de ce test est disponible en annexe B.4

Conclusion

Dans le tableau ci-dessous 4.1, nous retrouvons une description du protocole Dante™ suite à l’analyse des captures Wireshark et du test qui confirme notre hypothèse. Suite à ce test, il a été étudié la

Constante 0x02 Nombre d’échantillons transmis Données audios

Table 4.1 – Représentation du protocole Dante™audio

possibilité d’effectuer la compression en amont du système Dante™. Cela a pour avantages d’être une solution beaucoup plus propre. Une séance a été organisée avec Audinate pour définir l’encodage que nous désirions. Nous leur avons donc proposé un encodage 32 bits Raw avec un débit binaire possible de 128 kbit/s. L’ajout de l’encodage consistait à construire un nouveau firmware avec l’outil de configuration de module en ligne et à flasher les cartes avec ce nouveau firmware. Lorsque nous avons reçu l’encodage et après test, il s’est avéré que lorsque nous passions sur le nouvel encodage, les cartes disparaissaient du logiciel de contrôle. Après une nouvel séance, il a été convenu que les cartes restent disponibles dans le controller. Cette fois lors du test de l’encodage, les cartes restaient bien disponibles, toutefois le comportement était le même que du 32 bits PCM. Après discussion avec Audinate, il s’est avéré que ce que nous voulions faire n’était finalement pas possible avec leurs solutions. Nous étions donc face à la réalisation d’un risque identifiés, en effet des mesures avait été définis pour ce genre de problèmes. Les mesures prises sont détaillés dans le chapitre5. Les tests qui suivent ont été réalisés alors que nous étions en attente de réponse de la part d’Audinate.

4.1.4 Comportement de la solution sur wifi

Ce test a pour but de démontrer s’il est possible d’utiliser Dante sur un réseau wireless. Ces opérations ont été effectuées sur 2 PC. L’un équipé avec DVS et l’autre avec la solution VIA de Audinate qui permet de rerouter l’audio d’une application sur le réseau Dante. L’un des ordinateurs a été connecté sur le réseau par wifi. Le déroulement de ce test est disponible en annexe B.5.

Version 2.0 page: 41 Lambert Vincent Chapitre 4. Analyse de la solution envisagée 29 septembre 2017

Conclusion

Il s’est avéré qu’il est possible d’utiliser le système Dante™ sur une connexion sans-fil. Il est quand même à relever que quelques distorsions du son peuvent faire leur apparition.

4.1.5 Blocage du port audio

Ce test a pour but de vérifier que le système Dante continue à fonctionner même sans que des données audios transitent sur le système. Le déroulement du test est disponible en annexe B.6

Conclusion

Le test a démontré que le système ConMon et PTP continuait à fonctionner en l’absence de données audios. Toutefois, cette solution n’étant pas propre elle n’a pas été retenue dans le cadre de notre projet.

4.1.6 Utilisation des header J6 pour acquisition audio externe

Ce test vérifie que la carte Brooklyn-II PDK accepte des données encodées en PCM 24 sur une carte externe. Selon la documentation de la carte [16], ces données doivent être au format TDM. Pour ce faire, nous avons utilisé la carte PCM4222EVM de Texas Instruments. Cette carte a été configurée pour encoder un signal audio analogique à 1[kHz] en PCM 24 transmis en TDM. Ci-dessous, un schéma bloc de principe de l’installation 4.5 Le déroulement du test est détailé en annexe B.7.

Figure 4.5 – Schéma de principe de l’installation réalisée

Conclusion

Le test a révélé qu’il était possible de fournir des données audios sans passer par la carte PDK.

Version 2.0 page: 42 Lambert Vincent Chapitre 5. Gestion des risques rencontrés 29 septembre 2017

5 Gestion des risques rencontrés

Comme expliqué au point 4.1.3, un risque identifié s’est réalisé. Dans ce chapitre, les mesures qui ont été prises ainsi que le cahier des charges a été redéfini.

5.1 Mesures prises

Il a été décidé d’arrêter la collaboration avec Audinate sur ce projet. En effet il semblerait que le pro- duit Dante ne correspond pas à nos attentes. Son public cible est plutôt l’univers de la musique haute définition. Hors le but de ce projet initialement était de faire du broadcasting de flux audio compressés.

5.2 Redéfinition du cahier des charges

Le cahier des charges est dorénavant définit ainsi :

1. Trouver une solution ayant les forces de Dante sans ses faiblesses. 2. Proposer une solution viable pour la société Nulink.

Les contraintes sont définies ainsi :

1. Le traitement doit rester invisible aux yeux de l’utilisateur. 2. Language de programmation C ou C++.

Version 2.0 page: 43 Lambert Vincent Chapitre 6. Nouveau concept Innovant à haut niveau 29 septembre 2017

6 Nouveau concept Innovant à haut niveau

Comme la demande initiale de la société de Nulink était de concevoir un système AoIP compressé sur wifi et que malheureusement la solution qu’offre Audinate ne correspond pas à nos attentes, il a été imaginé d’aller plus loin et de créer un concept permettant de gérer une régie de broadcasting. Nulink étant très actif dans le domaine du broadcasting, il serait vraiment intéressant pour eux de disposer d’une solution permettant de piloter tous les flux, aussi bien vidéo que audio, depuis le même système.

6.1 Définition du concept

Dans une régie, on compte 4 postes distincts : — Le technicien audio — Le technicien vidéo — Le technicien RCP 1 (Choix des caméras et pilotages) — Le chef de régie Le concept serait d’avoir un programme avec des droits d’accès différents selon le poste occupé, qui permettrait de piloter les équipements à distance depuis le car de régie. Ce système devrait pouvoir faire communiquer ensemble la vidéo, l’audio et le contrôle des caméras. Toutes ces données devront avoir un système de synchronisation afin de pouvoir reconstruire le flux correctement.

De plus, le système devra pouvoir traiter des flux compressés ou non compressés.

1. Remote Control Production

Version 2.0 page: 44 Lambert Vincent Chapitre 7. Technologie intéressante pour notre concept 29 septembre 2017

7 Technologie intéressante pour notre concept

Aussitôt le concept établi, il a fallu analyser les technologies nécessaires et les solutions qui se propo- saient à nous.

7.1 La technologie MPEG TS

La technologie MPEG TS se présente comme un choix judicieux pour ce genre de concept. En effet, un transport stream permet de transporter un flux compressé comme un flux brut. Il est aussi possible de faire transiter un protocole de contrôle. Cela nous serait utile pour piloter des caméras par exemple.

Le MPEG transport stream a été défini pour la première fois en 1995 dans l’ISO/IEC 13818-1. Il s’agit d’un format container constitué de plusieurs flux enfants appelés PES 1.

Ces paquets PES sont constitués de flux élémentaires à la sortie de compression comme de la vidéo ou de l’audio.

Un transport stream est donc un multiplexage de plusieurs paquets PES auxquels on a rajouté des marqueurs temporels ainsi qu’une PCR 2 afin de pouvoir synchroniser les paquets avec l’application. La taille standard d’un paquet MPEG TS est de 188 octets.

7.1.1 Principe de compression vidéo

Le tableau ci-dessous 7.1 représente des exemples de débits non compressés et leur équivalent com- pressés : On comprend alors aisément qu’il est impératif que le flux vidéo soit compressé.

Définition SD HD UHD Débit du flux HD SDI : SDI 3 en sortie SDI : 270Mbps UHD SDI 6G : Gbps 1.5Gbps de caméra Débit après Blu-ray : env. YouTube 4K : DVD : 8Mbps compression 20Mbps 20Mbps

Table 7.1 – Comparatif flux vidéo non-compressé et compressé

La compression de la vidéo passe par 3 étapes. La première étape consiste à diminuer le nombre de pixels sur la définition horizontale. On appelle cette méthode le sous échantillonage. La deuxième étape va consister à passer d’un espace couleur RVB 4 à un espace couleur YCbCr.Voici la définition de ces trois acronymes : — Y : Il s’agit de la luminance (noir et blanc). — Cb : Il s’agit de la différence bleu (B - Y). — Cr : Il s’agit de la différence rouge (R - Y).

1. Packetized Elementary Streams 2. Program Clock Reference 4. Rouge Vert Bleu

Version 2.0 page: 45 Lambert Vincent Chapitre 7. Technologie intéressante pour notre concept 29 septembre 2017

Le gain obtenu vient du fait qu’il est plus léger de transporter l’information de différence que l’infor- mation des composantes elles-mêmes. La troisième étape va consister à réduire la définition de la couleur, ou chroma, sans toucher à la définition de luminance, ou luma. On peut diviser cette définition par 2 ou par 4. Dans le domaine du broadcasting, on applique une définition 4 :2 :2. Cela est expliqué dans le tableau ci-dessous 7.2

Composante Composante Composante Y Cb Cr Définition 1920 960 960 horizontale Définition 1080 1080 1080 verticale Poids numérique sur 8 bits par 2 Mo 1 Mo 1Mo image

Table 7.2 – Réduction de la définition d’une image HD en 4 :2 :2

Sans compression, cette image pèse 6 Mo/image. En appliquant une réduction de la définition de la couleur en 4 :2 :2, nous passons à 4Mo/image. Cela représente une diminution de 1/3 [17].

7.1.2 Flux élémentaire vidéo

L’unité fondamentale d’un flux élémentaire vidéo est le bloc DCT qui spécifie une portion de 8 x 8 à 64 x 64 pixels pouvant être Y, Cr ou Cb.

Ces 3 signaux sont construit à partir des trois primaires RVB, selon des coefficients dépendant de la norme utilisée.Cette opération est réalisée dans la caméra. Ces blocs DCT sont ensuite regroupés en macroblocs qui constituent ensemble une image. Ces macro- blocs peuvent comprendre de la compensation de mouvement. Chaque macrobloc comporte dans son en-tête un vecteur de mouvement bi-dimensionnel.[18]

Il existe trois types d’images : — I : Ce sont les images les moins compressées mais ne nécessitent pas d’autre image pour être décodé. — P : Ces images utilisent les images précédentes pour être décompressées et sont donc plus com- pressible que les images I. — B : Ces images utilisent les images précédentes et suivantes comme référence et ont ainsi le plus haut taux de compression. [19]

Version 2.0 page: 46 Lambert Vincent Chapitre 7. Technologie intéressante pour notre concept 29 septembre 2017

Nous sommes donc en présence d’un système de compression prédictif. Dans le domaine du broadcasting, Une image est découpée en slice. Dans le tableau ci-dessous 7.3, on retrouve le découpage typique pour du broadcasting. Ce découpage est utilisé dans le broadcasting car il représente le meilleur rapport qualité/latence.

I P P P

Table 7.3 – Découpage image broadcast

Ces images sont ensuites regroupées dans des GOP 5 qui commencent systèmatiquement par une image I.

Une séquence commence par un code de début de séquence suivi par un en-tête et se termine par un code de fin de séquence. Des en-têtes sont disséminés au cours de la séquence afin de permettre un décodage n’importe où dans la séquence.

7.1.3 Flux élémentaire audio

Un multiplex MPEG-2 peut accepter plusieurs encodages audio. Les catégories acceptées comprennent MPEG selon normes des couches 1,2 ou 3 et ATSC. L’encodage doit être spécifié dans l’en-tête. On pourrait toutefois faire passer un flux audio non compressé.

L’audio est compressé de façon psychoacoustique comme expliqué dans ce point 3.8.

7.1.4 Description des paquets PES

Dans le tableau ci-dessous 7.4 vous trouverez une représentation de l’en-tête d’un paquet PES[20].

Packet start code prefix Stream id PES Packet length Optional PES header Stuffing bytes Data

Table 7.4 – Représentation de l’en-tête d’un paquet PES

• Packet start code prefix (32 bits) : Identifie le début d’un paquet conjointement avec le champ stream id. Il s’agit d’une constante qui est égal à : 0x000001. • Stream id (8 bits) : Identifie le type ainsi que le nombre de flux élémentaires. • PES Packet length (16 bits) : Spécifie le nombre d’octets suivant ce champ dans le paquet PES. • Optional PES header (> 32 bits) : Header optionnel, n’est pas présent dans le cas de Padding stream et Private stream. • Stuffing bytes (variable) : Bits de rembourrage, de valeurs constantes (0xFF) et au maximum 32 fois. • Data : Données des flux élémentaires.

5. Group of Pictures

Version 2.0 page: 47 Lambert Vincent Chapitre 7. Technologie intéressante pour notre concept 29 septembre 2017

Pour plus de détails, voir :[20]

7.1.5 Description des paquets MPEG TS

Vous trouverez dans le tableau 7.5 ci-dessous la composition d’un paquet MPEG TS.

Sync byte TEI PUSI Transport Priority PID TSC Adaptation field control Continuity counter Adaptation field Payload Data

Table 7.5 – Représentation de l’en-tête d’un paquet TS

• Sync byte (8 bits) : Constante qui est égal à 0x47. • TEI (Transport error indicator) (1 bit) : Si à 1 indique qu’il y a une erreur dans les paquets associés à ce transport stream. • PUSI (Payload Unit Start Indicator) (1 bit) : Si à 1 indique la présence de paquets PES dans ce transport stream. • Transport Priority (1 bit) : Si à 1 indique que les paquets associés sont prioritaires par rapport au autres paquets ayant le même PID. • PID (13 bits) : Indique le type de données transportées dans le payload. • TSC (Transport Scrambling Control) (2 bits) : Indique le mode de brouillage. Si égal à 0x00 pas de brouillage. • Adaptation field control (2 bits) : Renseigne si un champ Adaptation field est présent. • Continuity counter (4 bits) : Numéro de séquence indépendant pour chaque stream. Incrémenté uniquement en présence d’un payload. • Optionnel :Adaptation field (taille variable) : Champ servant à la synchronisation des données. • Payload Data (taille variable) : Champ de données.

Dans le tableau ci-dessous 7.6, les catégories de PID que l’on peut retrouver.

Valeur Description 0x0000 Program Association Table (PAT) 0x0001 Conditional Access Table (CAT) 0x0002 Transport Stream Description Table 0x0003 − > 0x000F Réservé 0x0010 − > 0x1FFE Peut être network_PID, Program_map_PID, elementary_PID,... 0x1FFF Le paquet est NULL

Table 7.6 – Catégorie de PID TS [21]

Pour plus de détails voir :[20]

Version 2.0 page: 48 Lambert Vincent Chapitre 7. Technologie intéressante pour notre concept 29 septembre 2017

Ci-dessous un graphique montrant comment est construit un flux TS 7.1.

Figure 7.1 – Représentation de la construction d’un flux TS

7.2 ANEMAN™

Nous avions besoin d’un système acceptant les flux TS et ayant une interface intuitive. Après en avoir discuté avec mon conseiller Monsieur Mosqueron, il m’a guidé vers le système ANEMAN™. La solution ANEMAN™permet de connecter, surveiller et configurer des périphériques connectés. Bien que cette solution ait été développée initialement pour de l’AoIP, selon le product manager, il est tout à fait possible de développer un plugin pour le moteur ANEMAN™ permettant de gérer un flux TS. Pour notre concept, nous avons sélectionné la technologie MPEG-TS. Toutefois, ANEMAN™ serait capable de faire transiter d’autre flux.

L’un des grand avantage du projet ANEMAN™, en plus d’être gratuit, est le fait qu’il s’agit d’un projet ouvert. Cela implique que n’importe quel fabricant de périphériques peut venir s’ajouter au projet et développer un plugin permettant la communication avec ses périphériques. Une version payante permettant la gestion des droits est en cours de développement.

Version 2.0 page: 49 Lambert Vincent Chapitre 7. Technologie intéressante pour notre concept 29 septembre 2017

Actuellement, les fabricants ayant développé un plugin pour ANEMAN™ sont : • Digigram’s avec LX-IP et la gamme IQOYA • ArchWave avec la gamme uNETs • DirectOut avec le périphérique Montone.42 • Ward-Beck avec le périphérique PreMo mic pre-amp • Neumann Berlin avec l’interface DMI-8digital microphone • Merging’s avec les convertisseurs HORUS & HAPI • Merging’s avec les périphériques virtuels OSX VAD • Merging’s avec les driver RAVENNA/AES67 ASIO • Merging’s avec le convertisseur Mergin+NADAC

ANEMAN™ fonctionne avec un système de plugin développé par les fabricants de périphériques. Le moteur ANEMAN™ envoie les informations au plugin qui les traite et les retransmet au périphérique. Tous les échanges d’informations s’effectuent au moyen d’objet JSON 6. Sur la figure 7.2, on peut voir l’architecture de ANEMAN™[22].

Figure 7.2 – Architecture de ANEMAN™

6. JavaScript Object Notation

Version 2.0 page: 50 Lambert Vincent Chapitre 7. Technologie intéressante pour notre concept 29 septembre 2017

La version que nous avons eu l’occasion de tester est toujours une version bêta, cependant il est à souligner que la solution ANEMAN™ a reçu deux awards à l’IBC 2017 à Amsterdam. Les voici : — IBC Best of Show award — IABM design and innovation award Comme vous pouvez le voir dans la figure 7.3, l’interface étant très similaire à Dante™, celle-ci ne sera pas détaillée dans ce rapport. Toutefois, ANEMAN™ permet d’assigner des zones aux périphériques. Cela permet par exemple de créer une zone sample rate et dès qu’un périphérique dans cette zone change de taux d’échantillonage, les autres périphériques dans la zone changent automatiquement leur taux d’échantillonage. On pourrait aussi imaginer à futur avoir une zone pour les droits d’accès.

Figure 7.3 – Aperçu de l’interface ANEMAN [22]

De par le fonctionnement plug and play, l’orientation open project et la possibilité de gérer des flux TS, ANEMAN™ s’avère être un choix judicieux pour notre concept. De plus comme les flux TS peuvent embarquer plusieurs flux vidéos et audios, il serait tout à fait possible d’utiliser le système de souscription / désouscription à un canal pour passer d’un flux vidéo et audio à l’autre. Ce principe utiliserait les PES contenu dans un flux TS comme canaux.

Version 2.0 page: 51 Lambert Vincent Chapitre 8. Implémentation du concept 29 septembre 2017

8 Implémentation du concept

Afin de vérifier la cohérence du concept, une implémentation a été réalisée en créant un plugin permet- tant de communiquer avec des cartes DTM-3200 de chez dektec. Ces cartes permettent de prendre un flux TS depuis l’ASI 1 vers un port Ethernet, de le transmettre sur le réseau et d’effectuer l’opération inverse de l’autre côté avec une autre carte DTM-3200.

Ces cartes sont ensuites connectées à un module DTU-245 de chez DekTec permettant d’envoyer et recevoir le flux sur un ordinateur.

La transmission du flux se fait au moyen de l’application DekTec StreamXpress et la réception avec l’application DekTec StreamXpert.

Une librairie en C existe pour communiquer avec les cartes DTM-3200. La communication se fait via un module RS-232. Toutefois la librairie a été adaptée pour les besoins de notre concept. Les datasheet du DTM-3200 B.8 et du DTU-245 B.8 sont disponibles en annexe.

Ci-dessous un schéma de principe de l’installation qui a été réalisée 8.1:

Figure 8.1 – Schéma de principe installation DTM-3200

1. Asynchronous serial interface

Version 2.0 page: 52 Lambert Vincent Chapitre 8. Implémentation du concept 29 septembre 2017

8.1 Fonctionnement de ANEMAN™

Pour communiquer avec les périphériques, ANEMAN™ utilise des plugin développer par le fabricant du périphérique. Ce sont ces plugins qui vont envoyer les commandes et informations, dans un langage compris par le périphérique, au périphérique. Un certain nombre de fonction doit être implémenté dans le plugin. Les voici :

• Factory_Initialize : Cette fonction est appellée au chargement des librairies dynamiques. • Factory_Uninitialize : Cette fonction est appellée au déchargement des librairies dynamiques. • Factory_Accept : Cette fonction reçoit une chaîne de caractères JSON. Si le JSON a le format attendu. La fonction retourne 1. • Factory_Create : Retourne une instance du proxy. Cette fonction est toujours appellée après un appel réussit de Factory_Accept. La fonction retourne une valeur non NULL si les conditions suivantes sont respectées : N Les paramètres sont valides. N Le plugin a réussi à se connecter au périphérique ou support le mode hors-connexion. N Le plugin a vérifié que l’arbre de configuration du périphérique, le numéro de modèle et la version du firmware est supportée. Si l’un de ces tests échoue, le plugin devrait retourner une instance NULL et ainsi passer à un autre plugin. • Factory_Delete : Détruit l’instance du plugin. • Proxy_Action : Effectue la liste d’actions contenu dans le tableau JSON commandJsonList. • Proxy_Get : Retourne la partie de l’arbre de configuration demandée et la place dans resultJ- sonString. La libération de la mémoire alloué est gérée par la fonction Proxy_ReleaseJsonString. • Proxy_RegisterCallback : Cette fonction est utilisée par le moteur ANEMAN™. Elle sert à en- registrer les callback du périphérique. Par exemple lorsque le statut d’un flux de transmission ou de réception est mise à jour. Le prototype du callback est le suivant : void * F(const std : :string). • Factory_Info : Donne des informations sur le plugin. A l’heure actuelle cette fonction n’est pas obligatoire. • Proxy_Priority : Définit la priorité du plugin dans le cas où il y aurait plusieurs plugin pour un même périphérique. • RVMG_Get_By_Id : Référence les fonctions par le biais de pointeur sur des fonctions. Permet- tant ainsi de nommer comme l’on veut les fonctions au sein de notre plugin.

Version 2.0 page: 53 Lambert Vincent Chapitre 8. Implémentation du concept 29 septembre 2017

8.2 Description de l’implémentation

Dans les points ci-dessous est décrit les points importants pour que notre plugin communique avec les cartes DTM-3200. Bien évidemment il a fallu aussi créer toutes les fonctions standards de l’API d’ANEMAN™pour que notre plugin soit reconnu par le moteur ANEMAN™.

8.2.1 Création des fichiers JSON

Dans notre implémentation, les cartes DTM-3200 n’ont pas la possibilité d’avoir une interface web ou mDNS. Par conséquent, il n’est pas possible de les découvrir sur le réseau et il a fallu simuler leur découverte au moyen de fichier JSON. Ces fichiers doivent être placés dans le répertoire suivant :

C:\Users\%USERNAME\%\AppData\Roaming\Mergin Technologies\Aneman\simulation

Un exemple de fichier JSON est disponible en annexe B.8.

8.2.2 Adaptation du programme DtmCmd v.1.4.0

Par la suite, il a fallu modifier le programme en ligne de commande DtmCmd v1.4.0 pour qu’il puisse fonctionner au sein de notre plugin. Le programme non modifié est disponible ici : https: //www.dektec.com/downloads/OEM/DtmCmd.zip. Pour que le programme puisse fonctionner sans trop de modifications, une fonction simulant les paramètres reçu en mode console a été créée. Son prototype est le suivant :

send_command(int argc, char *argv_val[])

Par la suite deux fonctions appellant la fonction send_command ont été créées. Une fonction dtm_receive_on sert à enclencher le flux. L’autre dtm_receive_off interrompt le flux. La liste des commandes suppor- tés par le DTM-3200 est disponible dans ce document : https://www.dektec.com/products/OEM/ DTM-3200/downloads/DTM-3200%20Manual.pdf

8.3 Conclusion

Il a été démontré que le plugin créé était fonctionnel. Ce plugin permet de créer un flux et de l’arrêter selon les actions réalisées dans ANEMAN™. Toute la documentation du code a été placée sur le git de l’institut REDS.

Version 2.0 page: 54 Lambert Vincent Chapitre 9. Conclusion 29 septembre 2017

9 Conclusion

9.1 Débriefing

Le premier objectif consistait à trouver une solution ayant les forces de Dante sans ses faiblesses. Cela a été réalisé en proposant la solution ANEMAN™ qui permet une gestion des flux via une interface intuitive sans avoir de restriction au niveau du type de données traitées. Le projet a été encore plus loin en proposant une gestion complète d’un flux TS depuis ANEMAN™.

Pour atteindre le second objectif, une maquette de test a été mise en oeuvre dans le laboratoire du REDS pour démontrer la viabilité du concept. La maquette fonctionne avec succès.

Durant l’étude du protocole Dante, la première difficulté rencontrée consistait à comprendre la com- position du protocole avec uniquement des captures Wireshark. Durant la phase d’analyse, la gestion du risque mentionné au point5 a été l’une des difficultés majeure de ce projet. En effet, bon nombre de développements avait déjà été effectué et il a fallu les mettre de côté car il n’avait plus d’utilité dans le cadre du nouveau concept proposé.

Bien qu’un risque s’est réalisé, nous avons réussi à le surmonter et aller plus loin que ce qui nous était demandé. Le nouveau cahier des charges définit a été respecté. Une implémentation du concept, certe basique mais fonctionnel, a démontré la possibilité d’utiliser la solution ANEMAN™ pour la gestion de flux TS.

9.2 Perspectives pour le futur

Ce projet en est encore à ses balbutiements, une demande de projet européen devrait être déposé en mars 2018. Les développements futurs seraient les suivants : • Création d’une IP FPGA permettant l’encodage / décodage TS avec interface web. • Design d’un protocole de communication avec la carte. • Création d’une librairie permettant de communiquer avec la carte. • Création d’un plugin ANEMAN™ utilisant la librairie développée

9.3 Conclusion personnelle

Durant ce travail de bachelor, la partie que j’ai préférée fût l’analyse du concept. Elle m’a permit de découvrir des notions qui m’étaient alors inconnues et qui ont su réveiller mon intêret au point de vouloir poursuivre ce projet au-delà de mon travail de bachelor.

Lors de la conception du plugin ANEMAN™, j’ai pu me rendre compte à quel point une documen- tation du code en bonne et du forme était importante. Cela m’a permis de rapidement arriver à des résultats concrets.

Bien que sur le plan académique et professionel j’ai une certaine expérience en gestion de projet, ce travail m’a permis de consolider les connaissances acquises jusqu’à présent.

Version 2.0 page: 55 Lambert Vincent Chapitre 9. Conclusion 29 septembre 2017

La motivation principale dans ce projet, fut le fait de savoir que ce travail serait peut-être utilisé dans le futur pour des retransmissions d’événements sportifs.

Version 2.0 page: 56

Lambert Vincent Bibliographie 29 septembre 2017

Bibliographie

[1] techspot. xerox, jun 2003. http://www.techspot.com/guides/ 477-xerox-parc-tech-contributions/. [2] rap. multicast. https://www.rap.prd.fr/pdf/technologie_multicast.pdf. [3] ENS de Lyon. Culture sciences physique, jun 2017. http://culturesciencesphysique. ens-lyon.fr/ressource/principe-numerisation.xml. [4] "Audinate Pty Ltd". Dante_ Brooklyn_ II_ 17_ mar-2014. "Audinate Pty Ltd", "2014". [5] Perle Systems. precision-time-protocol. https://www.perlesystems.fr/supportfiles/ precision-time-protocol.shtml. [6] Audinate Pty Ltd. AUD-MAN-DAPI-Programmers_ Guide-V9. 9. Audinate Pty Ltd. [7] what-when-how. http://what-when-how.com/how-to-build-a-digital-library/ audio-digital-library/. [8] EFORT. Rtp et rtcp. http://www.efort.com/r_tutoriels/RTP_EFORT.pdf. [9] Dinesh Thakur. Time division multiplexing. http://ecomputernotes.com/ computernetworkingnotes/network-technologies/time-division-multiplexing. [10] Claude Gabriel. Chapitre 8 : psychoacoustique. http://www.claudegabriel.be/Acoustique% 20chapitre%208.pdf. [11] F.Payan. Compression du son - psychoacoustique. http://www.i3s.unice.fr/~fpayan/data/ enseignements/Tsig/2014-Chapitre4-Compression-Son-Etudiants.pdf. [12] UIT-T. Recommandation uit-t g.722. Technical report, UIT-T, 1988. [13] GL Communications Inc. Press release : G.722 wideband audio codec support across tdm and voip platforms. [14] Auphonic. Opus, the revolutionary open audio codec for pod- casts and internet audio. https://auphonic.com/blog/2012/09/26/ opus-revolutionary-open-audio-codec-podcasts-and-internet-audio/. [15] Un codec pour les dominer tous. http://sebsauvage.net/rhaa/images/201209/rha_ 20120912_opus.png. [16] "Audinate Pty Ltd". DanteProductDevelopmentKit-UserGuide . "Audinate Pty Ltd", "2016". [17] Jean-Charles Fouché. L’échantillonage 4 :4 :4, 4 :2 :2 et 4 :2 :0 en vidéo. https://www.focus-numerique.com/comprendre/dossiers/ l-echantillonnage-4-4-4-4-2-2-et-4-2-0-en-video-637.html. [18] Daniel Jean. Le flux élémentaire (elementary stream) de mpeg, 2005. http://danjean. developpez.com/video/mpeg-elementary-stream/. [19] ISO/IEC. Iso/iec 11172-2 :information technology - coding of moving pictures and associated audio for digital storage media at up to about 1.5 mbit/s – part 2 :video, 1993. [20] ISO/IEC. Iso/iec 13818-1 :information technology - generic coding of moving pictures and asso- ciated audio information : Systems, 2000. [21] Joévin Magron. Démultiplexage et décodage de flux de vidéos compressées. Master’s thesis, EPFL, 2015. [22] Merging Technologies. ANEMAN User Manual. Merging Technologies. [23] H. Schulzrinne, S. Casner, R. Frederick, and V.Jacobson. Rtp : A transport protocol for real-time applications, 2003. [24] Texas Instruments. PCM4222EVM User’s Guide. Texas Instruments, 2006.

Version 2.0 page: 58 Lambert Vincent Annexe A. Dossier de gestion 29 septembre 2017

A Dossier de gestion

A.1 Echéancier détaillé

Tâches Début Fin Semaines Rédaction de la pré-étude 02.05.2017 01.06.2017 18 - 22 Validation de la pré-étude 10.07.2017 28 Début du travail de diplôme 10.07.2017 28 Réception matériel et installation environnement 10.06.2017 15.06.2017 28 Analyse du protocole Dante™ 17.07.2017 29.07.2017 29 - 30 Séance avec Audinate 25.07.2017 25.07.2017 30 Séance avec Audinate 30.08.2017 30.08.2017 35 Dépôt du résumé sur GAPS 01.09.2017 à 16h 35 Test fonctionnel de la solution Dante™ 31.07.2017 04.09.2017 31-36 Séance avec Merging Technologies 06.09.2017 06.09.2017 36 Dépôt de l’affiche sur GAPS 15.09.2017 à 16h 37 Analyse de la solution ANEMAN™ 07.09.2017 16.09.2017 36 - 37 Implémentation de la solution ANEMAN 18.09.2017 23.09.2017 38 - 39 Dépôt du mémoire de diplôme 29.09.2017 à 16h 39 Soutenance 10.10.2017 à 9h 42

A.2 Rendez-vous et contacts avec le Conseiller

• 28.04.2017, Durée :50min

Objectifs de la pré-étude, documentations et études, questions-réponses.

• 10.07.2017, Durée :1h

Séance Kick-off TB.

• 17.07.2017, Durée 20min

Rapport avancement projet : Question choix librairie réseau.

• 24.07.2017, Durée 20min

Rapport avancement projet :Préparation question Audinate.

• 25.07.2017, Durée 1h

Séance avec Audinate, explication projet.

Version 2.0 page: 59 Lambert Vincent Annexe A. Dossier de gestion 29 septembre 2017

• 31.07.2017, Durée 20min

Rapport avancement projet : Discussion API Dante™.

• 15.08.2017, Durée 20min

Rapport avancement projet : Discussion Custom encoding Dante™.

• 29.08.2017, Durée 25min

Rapport avancement projet : Préparation question audinate pour séance du 30.08.2017.

• 30.08.2017, Durée 1h

Séance avec Audinate concernant encodage.

• 06.09.2017, Durée 1h

Séance avec Merging Technologies, présentation ANEMAN™.

• 11.09.2017, Durée 20m

Rapport avancement projet : Discussion programmation proxy.

• 19.09.2017, Durée 20min

Rapport avancement projet : Conseils sur rédaction rapport.

• 25.09.2017, Durée 20min

Rapport avancement projet : Discussion documentation code.

• 29.09.2017 Dépôt du travail de Bachelor au secrétariat en trois exemplaires.

Version 2.0 page: 60 Lambert Vincent Annexe B. Annexe 29 septembre 2017

B Annexe

B.1 Vision détaillée de RTP

Ci-dessous le détails d’un paquet RTP :

V P X CC M PT N° Séquence Timestamp Synchronization Source(SSRC) Identifiers Contributing Source (CSRC) Identifiers

Table B.1 – Détail En-tête RTP [8]

• Version (V) (2 bits) : Indique le numéro de version RTP utilisé. • Padding (P) (1 bit) : Si à 1, indique que le champ de données Payload a du «bourrage». • Extension (X) (1 bit) : Si à 1, indique que l’en-tête standard a une partie d’en-tête supplémen- taire. • CSRC Count (CC) (4 bits) : Indique le nombre d’identifiants CSRC. • Marker (M) (1 bit) : Bit de signalisation, son sens dépend des données transportées. • Payload type (PT) (7 bits) : Ce champ indique le type de contenu qui est transporté. • Sequence Number (16 bits) : Il s’agit d’un champ qui est incrémenté de 1 à chaque paquet RTP envoyé. Sa valeur initiale est aléatoire. Il permet notamment de détecter les paquets RTP perdus. • TimeStamp (32 bits) : Ce champ permet de dater les paquets envoyés. • Synchronization Source (SSRC) (32 bits) : Champ identifiant la source ayant émis le paquet. • Contributing Source (CSRC) : Ce champ peut contenir de 0 à 15 instances, selon le nombre de sources ayant contribué à l’émission du paquet.

Ci-dessous, un exemple de paquet RTP Figure :B.1

Figure B.1 – Exemple de paquet RTP

Toutes ces informations sur le protocole RTP ont été trouvées dans le RFC 3550 [23]

Version 2.0 page: 61 Lambert Vincent Annexe B. Annexe 29 septembre 2017

B.2 Vision détaillée de RTCP

Voici la description de ces types de paquets :

SR(Sender Report)

Dans le tableau B.2 la description du paquet SR.

V P SC PT=SR=200 length SSRC of sender NTP timestamp, most significant word NTP timestamp, least significant word RTP timestamp sender’s packet count sender’s octet count SSRC_1 (SSRC of first source) fraction lost cumulative number of packets lost extended highest sequence number received interarrival jitter last SR (LSR) delay since last SR (DLSR) SSRC_2 (SSRC of second source) ... profile-specific extensions

Table B.2 – Détail paquet type SR

• version (V) (2 bits) : Identifie la version RTP utilisée. • padding (P) (1 bit) :Si à 1, indique la présence de padding à la fin du paquet de contrôle. • reception report count (RC) (5 bits) : Indique le nombre de bloc de réception dans le paquet. Un zéro est toléré. • packet type (PT) (8 bits) : Contient la constante 200 pour identifier le fait qu’il s’agit d’un paquet RTCP SR. • length (16 bits) : Précise la taille de ce paquet RTCP. • SSRC (32 bits) : Champ identifiant la source ayant émis le paquet. • NTP timestamp (64 bits) : Permet de dater le moment où le paquet a été envoyé. • RTP timestamp (32 bits) : Correspond au champ NTP timestamp, en respectant toutefois le format du timestamp contenu dans le paquet de données (RTP). • sender’s packet count (32 bits) : Représente le nombre total de paquets RTP transmis par l’émet- teur depuis le début de la transmission et la génération de ce paquet SR. • sender’s octet count (32 bits) :Indique la taille de payload transmis dans les paquets RTP depuis le début de la transmission et la génération de ce paquet SR. • SSRC_n (32 bits) : Identifie le SSRC auquel appartient les informations de ce bloc de rapport. • fraction lost (8 bits) : Indique le nombre de paquets perdus depuis le dernier paquet SR ou RR. • cumulative number of packets lost (24 bits) : Représente le nombre total de paquets perdus de- puis le début de la réception. • extended highest sequence number received (32 bits) : Les 16 bits de poids faible représentent le plus haut n° de séquence reçu dans un paquet RTP, les 16 bits de poids fort représentent le nombre de cycle de numéro de séquence.

Version 2.0 page: 62 Lambert Vincent Annexe B. Annexe 29 septembre 2017

• interarrival jitter (32 bits) : Représente le temps de transit. • last SR timestamp (LSR) (32 bits) : 32 premiers bits du champ NTP timestamp du dernier pa- quet SR • delay since last SR (DLSR) (32 bits) : Délai depuis le dernier paquet SR

Ci-dessous, un exemple de paquet RTCP SR Figure :B.2

Figure B.2 – Exemple de paquet SR

Version 2.0 page: 63 Lambert Vincent Annexe B. Annexe 29 septembre 2017

RR(Receiver Report)

Dans le tableau B.3 la description du paquet RR.

V P RC PT=RR=201 length SSRC of sender SSRC_1 fraction lost cumulative number of packets lost extended highest sequence number received interarrival jitter last SR delay since last SR SSRC_2 ... profile-specific extensions

Table B.3 – Détail paquet type RR

• version (V) (2 bits) : Identifie la version RTP utilisée. • padding (P) (1 bit) :Si à 1, indique la présence de padding à la fin du paquet de contrôle. • reception report count (RC) (5 bits) : Indique le nombre de blocs de reception dans le paquet. Un zero est toléré. • packet type (PT) (8 bits) : Contient la constante 201 pour identifier le fait qu’il s’agit d’un paquet RTCP RR. • length (16 bits) : Précise la taille de ce paquet RTCP. • SSRC (32 bits) : Champ identifiant la source ayant émis le paquet. • SSRC_n (32 bits) : Identifie le SSRC auquel appartient les informations de ce bloc de rapport. • fraction lost (8 bits) : Indique le nombre de paquets perdus depuis le dernier paquet SR ou RR. • cumulative number of packets lost (24 bits) : Représente le nombre total de paquets perdus de- puis le début de la réception. • extended highest sequence number received (32 bits) : Les 16 bits de poids faible représentent le plus haut n° de séquence reçu dans un paquet RTP, les 16 bits de poids fort représentent le nombre de cycle de numéro de séquence. • interarrival jitter (32 bits) : Représente le temps de transit. • last SR timestamp (LSR) (32 bits) : 32 premiers bits du champ NTP timestamp du dernier pa- quet SR • delay since last SR (DLSR) (32 bits) : Délai depuis le dernier paquet SR.

Version 2.0 page: 64 Lambert Vincent Annexe B. Annexe 29 septembre 2017

Ci-dessous, un exemple de paquet RTCP RR Figure :B.3

Figure B.3 – Exemple de paquet RR

Version 2.0 page: 65 Lambert Vincent Annexe B. Annexe 29 septembre 2017

SDES(Source Description)

Dans le tableau B.4 la description du paquet SDES.

V P SC PT=SDES=202 length SSRC / CSRC_n SDES items

Table B.4 – Détail paquet type SDES

• version (V) (2 bits) : Identifie la version RTP utilisée. • padding (P) (1 bit) :Si à 1, indique la présence de padding à la fin du paquet de contrôle. • source count (SC) (5 bits) : Indique le nombre d’objets SSRC/CSRC contenus dans ce paquet RTCP SDES • packet type (PT) (8 bits) : Contient la constante 202 pour identifier le fait qu’il s’agit d’un paquet RTCP SDES. • length (16 bits) : Précise la taille de ce paquet RTCP • SSRC/CSRC_n (32 bits) : Champ identifiant le SSRC/CSRC décrit dans la partie SDES items • SDES items : Contient les objets SDES, au minimum le CNAME 1 doit être indiqué. Il peut contenir les champs : NAME, EMAIL, PHONE, LOC, TOOL, NOTE, PRIV.

Ci-dessous, un exemple de paquet RTCP SDES Figure :B.4

Figure B.4 – Exemple de paquet SDES

BYE(Goodbye)

Dans le tableau B.5 la description du paquet BYE.

1. Canonical NAME

Version 2.0 page: 66 Lambert Vincent Annexe B. Annexe 29 septembre 2017

V P SC PT=BYE=203 length SSRC / CSRC_n ... length reason for leaving

Table B.5 – Détail paquet type BYE

• version (V) (2 bits) : Identifie la version RTP utilisée. • padding (P) (1 bit) :Si à 1, indique la présence de padding à la fin du paquet de contrôle. • source count (SC) (5 bits) : Indique le nombre d’objets SSRC/CSRC contenus dans ce paquet RTCP BYE • packet type (PT) (8 bits) : Contient la constante 203 pour identifier le fait qu’il s’agit d’un paquet RTCP BYE. • length (16 bits) : Précise la taille de ce paquet RTCP. • SSRC/CSRC_n (32 bits) : Champ identifiant le(s) SSRC/CSRC concerné(s).

Il existe deux champs optionels pour le paquet BYE, les voici : • length : Définit la taille du champ reason for leaving • reason for leaving : Donne la raison pour laquelle le SSRC/CSRC quitte la session. Ci-dessous, un exemple de paquet RTCP BYE Figure :B.5

Figure B.5 – Exemple de paquet BYE

Version 2.0 page: 67 Lambert Vincent Annexe B. Annexe 29 septembre 2017

APP(Application-Defined)

Dans le tableau B.6 la description du paquet APP.

V P subtype PT=APP=204 length SSRC / CSRC_n ASCII application-dependent data

Table B.6 – Détail paquet type APP

• version (V) (2 bits) : Identifie la version RTP utilisée. • padding (P) (1 bit) :Si à 1, indique la présence de padding à la fin du paquet de contrôle. • subtype (5 bits) : Permet de regrouper les paquets APP d’une application sous un même sous- type. • packet type (PT) (8 bits) : Contient la constante 204 pour identifier le fait qu’il s’agit d’un paquet RTCP APP. • length (16 bits) : Précise la taille de ce paquet RTCP • SSRC/CSRC_n (32 bits) : Champ identifiant le(s) SSRC/CSRC concerné(s). • name (ASCII) (32 bits)(4 caractères) : Définit le nom de l’application auquel ce paquet est des- tiné. • application-dependent data : Contient les données destinées à l’application spécifiée dans le champ name.

Ci-dessous, un exemple de paquet RTCP APP Figure :B.6

Figure B.6 – Exemple de paquet APP

Toutes ces informations sur le protocole RTCP ont été trouvées dans le RFC 3550 [23].

Version 2.0 page: 68 Lambert Vincent Annexe B. Annexe 29 septembre 2017

B.3 Prise en main du système Dante™

Le système Dante a besoin de deux périphériques Dante et d’une application pour piloter les cartes. L’application pour piloter les cartes fournit pas Audinate est Dante controller.Voici un guide pour une prise en main rapide :

Lorsque vous ouvrez l’application, vous devriez arriver sur cette fenêtre B.7

Figure B.7 – Interface Dante Controller

Cette fenêtre comporte 4 menus dont voici un bref explicatif des fonctions que l’on y trouve. — File : H Load Preset : Permet de charger une configuration au format XML. H Save Preset : Permet de sauvegarder la configuration actuelle au format XML. — Device : H Refresh (F5) : Permet de rafraîchir l’état des périphériques Dante™. H Device View (CTRL + D) : Permet d’ouvrir la vue de configuration des périphériques Dante™. — View : H Show/Hide Channel Groups : Permet d’afficher/masquer le regroupement des canaux dans l’onglet Routing — Help : H About : Donne des informations sur la version du Dante Controller. H License : Affiche la license utilisateurs. H Check for Updates : Vérifie la disponibilité d’une mise à jour. H Online Help (F1) : Ouvre l’aide en ligne H Offline Help (MAJ + F1) : Ouvre l’aide hors-ligne.

Version 2.0 page: 69 Lambert Vincent Annexe B. Annexe 29 septembre 2017

Voici maintenant une présentation des onglets rapides :

Cette icône permet d’afficher/masquer le panneau de filtre qui apparait sur la gauche de l’interface.

Permet de rafraîchir l’état des périphériques Dante™.

Permet de charger une configuration préalablement enregistrée.

Permet de sauvegarder la configuration actuelle dans un fichier XML.

Permet de choisir l’interface réseau où se situe les périphériques Dante™.

Active/Désactive le monitoring de l’horloge.

Permet d’afficher/masquer le regroupement des canaux dans Routing.

Affiche l’horloge maître actuelle.

Lance l’aide en ligne.

Version 2.0 page: 70 Lambert Vincent Annexe B. Annexe 29 septembre 2017

Ci-dessous une présentation des onglets et de leurs fonctions : — Routing : Permet de gérer les flux Dante, ce qui comprend l’inscription et la désincription. Les receveurs sont sur la gauche et les transmetteurs sur le dessus. — Device Info : Donne des informations générales à propos des différents périphériques sur le réseau. — Clock Status : Nous renseigne sur l’état des horloges des périphériques. — Network Status : Informe l’utilisateur sur les latences actuelles du réseau. — Events : Log de tous les événements qui se sont produits.

Il existe une autre fenêtre importante qui est appellée au moyen de CTRL + D ou via Device->Device View.

Dans la figure B.8, vous voyez son aspect général.

Figure B.8 – Aspect général de la vue périphérique

Version 2.0 page: 71 Lambert Vincent Annexe B. Annexe 29 septembre 2017

La fenêtre Device View comporte 4 menus dont voici un bref explicatif des fonctions que l’on y trouve. — File : H Close Windows : Permet de fermer la fenêtre. — Device : H Refresh (F5) : Permet de rafraîchir l’état des périphériques Dante ™. H Create Multicast flow : Permet de créer un flux multicast. H Device View (CTRL + D) : Permet d’ouvrir la vue de configuration des périphériques Dante™. — View : H Show/Hide Channel Groups : Permet d’afficher/masquer le regroupement des canaux. — Help : H About : Donne des informations sur la version du Dante Controller. H License : Affiche la license utilisateurs. H Check for Updates : Vérifie la disponibilité d’une mise à jour. H Online Help (F1) : Ouvre l’aide en ligne. H Offline Help (MAJ + F1) : Ouvre l’aide hors-ligne.

Voici maintenant une présentation des onglets rapides :

Permet de rafraîchir l’état des périphériques Dante™.

Ouvre l’interface web de configuration du périphérique.

Permet d’identifier le périphérique.

Permet de créer un flux multicast.

Permet d’afficher/masquer le regroupement des canaux.

Permet de verouiller le périphérique afin d’éviter toutes modifications de la confi- guration.

Liste déroulante permettant de choisir le périphérique à contrôler.

Lance l’aide en ligne.

Version 2.0 page: 72 Lambert Vincent Annexe B. Annexe 29 septembre 2017

Ci-dessous une présentation des onglets et de leurs fonctions : • Receive : Permet de voir les canaux de réception du périphérique ainsi que les canaux disponibles sur le réseaux. On peut s’abonner à un canal en effectuant un glisser-déposer depuis Available Channels vers Receive Channels. • Transmit : Permet de voir les canaux en cours d’émission ainsi que les flux utilisés. • Status : Affiche un résumé des différentes informations à propos du périphérique. • Latency : Affiche un graphique des latences. • Device Config : Permet de configurer les paramétres audio du périphérique. • Network Config : Permet de configurer les paramètres réseau du périphérique.

Version 2.0 page: 73 Lambert Vincent Annexe B. Annexe 29 septembre 2017

B.4 Test séparation de l’audio Dante™

Cette application capture les trames multicast udp sur le port 4321, sépare l’audio de ces trames et les stocks dans un fichier «test.pcm>. Il suffit ensuite de passer ce fichier dans l’application Audacity pour décoder notre audio en son audible.

Voici la marche à suivre :

Figure B.9 – Sélectionner interface

Ouvrez l’application «Separateur_Audio.exe» et selectionnez l’interface sur laquelle les données audios sont émises et appuyez sur Enter B.9

Figure B.10 – Selection du sampling

Selectionnez ensuite le nombre d’échantillons par trame (16 pour carte physique et 48 pour DVS) et validez avec Enter B.10.

Version 2.0 page: 74 Lambert Vincent Annexe B. Annexe 29 septembre 2017

Version 2.0 page: 75 Lambert Vincent Annexe B. Annexe 29 septembre 2017

Figure B.11 – Selection encodage

Entrez 1, 2 ou 3 afin de sélectionner l’encodage des données B.11.

Figure B.12 – Selection du nombre de canaux

Il vous reste à choisir le nombre de canaux transmis dans la trame B.12.

La capture démarre.

Pour quitter la capture faites CTRL-C.

Pour la suite, veuillez ouvrir le logiciel Audacity.

Version 2.0 page: 76 Lambert Vincent Annexe B. Annexe 29 septembre 2017

Figure B.13 – Ouverture en mode Raw

Cliquez sur : Fichier -> Importer-> Données brutes (Raw) B.13

Figure B.14 – Sélection fichier test.pcm

Séléctionnez le fichier test.pcm et cliquez sur ouvrir B.14.

Version 2.0 page: 77 Lambert Vincent Annexe B. Annexe 29 septembre 2017

Figure B.15 – Configuration paramétres import

Configurez les paramétres d’import selon le flux capturé B.15 et cliquez sur Importer.

Figure B.16 – Ecoute des données audios

Il ne vous reste plus qu’à cliquer sur le bouton vert Play pour écouter les données capturées.

B.5 Test comportement du système Dante™ sur wifi

Comme le stipule la documentation de Dante, l’ordinateur qui s’est connecté sur le réseau via wifi est invisible sur le controller. Il semblerait que Dante regarde les paquets auto-négociation pour identifier un réseau wireless. Pour essayer de contourner cette limitation, nous allons réaliser une connexion en pont sur l’ordinateur connecté en wifi. L’ordinateur en question fonctionne sous Windows 10 64 bits.

Ouvrez le Centre réseau et partage de windows. Vous devriez arriver sur la fenêtre ci-dessous B.17:

Version 2.0 page: 78 Lambert Vincent Annexe B. Annexe 29 septembre 2017

Figure B.17 – Centre réseau et partage

Cliquez ensuite sur Modifier les paramètres de la carte sur la gauche.

Version 2.0 page: 79 Lambert Vincent Annexe B. Annexe 29 septembre 2017

Figure B.18 – Fenêtre des interfaces

Vous allez arriver sur la fenêtre ci-dessus B.18. Cette fenêtre regroupe toutes les interfaces réseau de votre ordinateur.

Figure B.19 – Réalisation d’une connexion pont

Séléctionnez maintenant 2 interfaces réseaux. L’une doit être votre interface wifi et l’autre une in- terface ethernet. Faites clique-droit et sélectionnez Connexions pont, comme sur la capture ci-dessus B.19. Attendez la fin de l’opération et l’ordinateur qui était auparavant invisible dans le controller, devient maintenant visible.

B.6 Test blocage du port audio

Afin de vérifier que le système continue à fonctionner même sans données audios, nous allons bloquer le port 4321, port utilisé en multicast par Dante, dans le pare-feu de windows.

Ouvrez le Panneau de configuration –> Pare-feu Windows pour arriver sur la fenêtre ci-dessus B.20. Cliquez ensuite sur Paramètres avancés sur la gauche de la fenêtre pour arriver sur cette nouvelle fenêtre B.21

Version 2.0 page: 80 Lambert Vincent Annexe B. Annexe 29 septembre 2017

Figure B.20 – Fenêtre du pare-feu Windows

Nous allons maintenant définir une règle de traffic entrant et une règle de traffic sortant. Commençons par la règle de traffic entrant. Pour se faire cliquez sur Régles de trafic entrant sur la gauche de la fenêtre. La fenêtre devrait se modifier comme sur la capture B.22.

Version 2.0 page: 81 Lambert Vincent Annexe B. Annexe 29 septembre 2017

Figure B.21 – Fenêtre des options avancées du firewall Windows

Figure B.22 – Vue de la fenêtre des règles de trafic entrant

Version 2.0 page: 82 Lambert Vincent Annexe B. Annexe 29 septembre 2017

Maintenant sur la droite de cette fenêtre, vous pouvez cliquer sur Nouvelle règle. La fenêtre suivante va alors s’ouvrir B.23

Figure B.23 – Fenêtre de l’assistant de création de règle de trafic entrant

Figure B.24 – Paramètres de la nouvelle règle de trafic entrant

Sélectionnez port et cliquez sur Suivant. Vous allez maintenant pouvoir remplir les champs comme sur la capture ci-dessus B.24 et cliquer sur Suivant .

Version 2.0 page: 83 Lambert Vincent Annexe B. Annexe 29 septembre 2017

Figure B.25 – Définition de l’action de la règle

Arrivé sur cette fenêtre B.25, spécifiez que vous voulez bloquer la connexion lorsque la règle est res- pecté (blocage du port 4321 en entrée). Sur l’écran d’après, vous pouvez cliquer sur Suivant. Vous arriverez sur une fenêtre permettant de donner un nom à la règle ainsi qu’une description. Une fois ceci effectué vous pouvez cliquer sur Terminer pour enregistrer la règle.

Pour spécifier la règle du pare-feu pour le port 4321 sortant, veuillez répéter l’opération depuis la figure B.21, mais en cliquant cette fois-ci sur Règles de trafic sortant.

B.7 Test audio externe

Selon la documentation de la carte PCM4222EVM [24], voici comment doit être configurée la carte :

Figure B.26 – Position de SW1 et SW2

Comme on peut le voir sur la figure B.26, voici la position des switch 1 et 2 : SW1 : — UNUSED –> 0 — DSDMODE –> 0

Version 2.0 page: 84 Lambert Vincent Annexe B. Annexe 29 septembre 2017

— MODEN –> 0 — DSDEN –> 0 — DF –> 1 — FS1 –> 0 — FS0 –> 0 — HPFDL –> 1 — HPFDR –> 0 — PCMEN –> 1 SW2 : — SUB0 –> 0 — SUB1 –> 0

Version 2.0 page: 85 Lambert Vincent Annexe B. Annexe 29 septembre 2017

Figure B.27 – Position de SW3

La position des switch 3 B.27: SW3 : — FMT0 –> 0 — FMT1 –> 1 — OWL0 –> 0 — OWL1 –> 0 — S/M –> 1 — DIT –> 1 — DITCLK1 –> 1 — DITCLK0 –> 1 — DITFMT –> 0 — DITMONO –> 0

Figure B.28 – Position de SW6

La position des switch 6 B.28 SW6 : — EXT_CLK –> 1 — X1 –> 0 — X2 –> 1 — undef

Version 2.0 page: 86 Lambert Vincent Annexe B. Annexe 29 septembre 2017

Pour alimenter notre carte PCM4222EVM, une alimentation symétrique PPE-3323 de la société GW Instek a été utilisée. Elle permet de fournir + 15 [V] et - 15 [V] pour la partie analogique de la carte ainsi que 5 [V] pour la partie numérique comme spécifié dans la documentation [24]. Ces données audios numériques sont disponibles sur les pin J6 de la carte PCM4222EVM et doivent être branchées sur les pin J6 de la carte Brooklyn-II PDK.

Pour le branchement des pins entre les 2 cartes, les connecteurs J6 de la carte PCM4222EVM seront appelés A et les connecteurs J6 de la carte Brooklyn-II PDK seront appelés B.

Voici un tableau qui présente les branchements entre les 2 cartes B.7, pour avoir les données audios sur les canaux 5-6 dans Dante Controller

A B 2 1 3 5 5 4 7 13

Table B.7 – Présentation des branchements des cartes Brooklyn-II PDK et PCM4222EVM

Dans l’image ci-dessous B.29, nous avons le signal analogique à 1 [kHz] à l’entrée de la carte PCM4222EVM.

Figure B.29 – Signal analogique à l’entrée de la carte PCM4222EVM

A la sortie de la carte nous retrouvons notre signal numérique à 1 [kHz] transmis en TDM B.30.

Figure B.30 – Signal numérique à la sortie de la carte PCM4222EVM

Version 2.0 page: 87 Lambert Vincent Annexe B. Annexe 29 septembre 2017

B.8 Fichier JSON

{ "Actions":{ "CreateStreamer":"", "DeleteStreamer":"StreamId", "CreateReceiver":"ReceiverId", "DeleteReceiver":"ReceiverId", "SetSampleRate":"Sample"}, "Id":3001, "Identity":{ "Version":"1.0", "Company":"Reds", "Product":"Reds_compressor", "Serial":"Reds-1234", "Name":"DTM-3200_1" }, "Network":{ "HostName":"Streamer", "Interfaces":[{ "Id":0, "Name":"standard", "Config":1, "Address":"192.168.1.100", "Gateway":"192.168.1.1", "Netmask":"255.255.255.0" }], "Services":{ "PTP":{ } } }, "WebServices":[{ "Name":"API_Reds", "URL":"http://localhost:9000/resource" } ], "IOGroups":[{ "Name":"0", "Id":0, "Inputs":[{ "Id":0, "Name":"0", "Status":{ "State":1 } }], "Outputs":[{ "Id":0, "Name":"0", "Status":{

Version 2.0 page: 88 Lambert Vincent Annexe B. Annexe 29 septembre 2017

"State":1 } }], "Status":{ "SampleRate":48000 }, "Capabilities":{ "SampleRates":[48000] } }], "Streamers":[ ], "Receivers":[ ]

}

Version 2.0 page: 89 DTM-3200

 Converts ASI to IP or IP to ASI Standalone OEM Module for  Parallel TS port ASI to/from IP Conversion  UDP, RTP, 2D FEC (SMPTE-2022)

FEATURES  Compact OEM module for interfacing Transport Streams to a network. The DTM-3200 converts IP to ASI, or ASI to IP  Additional 8-bit parallel Transport Stream I/O port on a 26-way boxed header for easy connectivity to custom hardware  Advanced IP-jitter filtering algorithm, with programmable jitter tolerance  IP encapsulation and 2D-FEC encoding and decoding as defined in SMPTE 2022  Unicast and multicast IP addressing  Several interface standards supported for APPLICATIONS serial control (RS-232, RS-422, RS-485  Easy way to add an IP input or output to and I2C) your TS-processing product  Persistent storage of configuration  Tunnelling of ASI signals over LAN, WAN parameters or the Internet

KEY ATTRIBUTES PROTOCOL SUPPORT Parameter Value Ethernet encapsulation IEEE 802.2 SNAP, Eth. II GigE port Physical layer IEEE 802.3a IP support IPv4 Data rate 100/1000 IP-address assignment DHCP, link local or Connector RJ-45 with LEDs static DVB-ASI Physical layer EN50083-9 Multicast support IGMP v2 port Connector 1x 75-Ω MCX Device management Out of band: RS-232, RS-422, RS-485, I2C Tx bitrate 0.01 .. 214Mbit/s Network management Not supported Parallel Physical layer M-LVDS port Signals Clock, sync, valid, ORDERING INFORMATION 8-bit data Connector 26-way header Type Description Transport TP per IP 1 .. 7 DTM-3200 OEM ASI to/from IP converter Encapsulation UDP or RTP DTM-3200-RA OEM ASI to/from IP converter with right-angle connectors FEC SMPTE 2022 DTM-3200-DEVKIT Developer kit for DTM-3200 IP to ASI latency* 1ms Please refer to www.dektec.com for the latest pricing and a list of dis- Jitter tolerance range 1 .. 500ms tributors and resellers.

Dimensions WxHxD 80x55x14mm * Excluding FEC reconstruction and jitter tolerance delay.

© 2016 DekTec Digital Video BV www.dektec.com DTM-3200 Product Leaflet Quality Tools for Digital-TV Professionals November 2016 DTU-245

 Portable streaming of DVB-ASI and SDI FantASI USB-2 ASI/SDI  The essential tool for every DTV engineer Input+Output Adapter  No AC power adapter required

FEATURES  Convenient, compact USB adapter that can be used to capture and generate MPEG-2 transport streams (DVB-ASI) as well as and uncompressed serial digital video (SD-SDI)  USB powered - no power supply required  Simultaneous input and output operation for transport streams  Huffman compression of SDI signals for reducing required USB bandwidth  16-Mbytes of local RAM for sustained real-time streaming AVAILABLE SOFTWARE  StreamXpress ASI / SD-SDI player APPLICATIONS  StreamXpert Lite basic viewer and recorder  General-purpose USB adapter for  StreamXpert transport-stream analyser capturing, generating and processing  SdEye SDI waveform analyser of ASI and SDI streams  VF-Rec advanced capturing  On-site recording and analysis  Free Windows/Linux drivers and associated  Portable demo set SDK for developing custom applications

KEY ATTRIBUTES ORDERING INFORMATION Parameter Value Type Description Connector 75-Ω BNC (2x) DTU-245-SLP USB-2 ASI/SDI input and output ASI Physical layer EN50083-9 with StreamXpert Lite and StreamXpress Bitrate range (full-duplex) 0 to 160Mbit/s DTU-245-SXP DTU-245-SLP with StreamXpert Bitrate range (half-duplex) 0 to 214Mbit/s DTU-245-SY-SXP DTU-245-SLP with SdEye and Packet size 188 or 204 StreamXpert SDI Physical layer SMPTE 259M DTU-245-DVB+ DTU-245-SLP with DVBAnalyzer Bitrate (half-duplex only) 270Mbit/s in-depth TS analyser and viewer The latest pricing information and a list of DekTec resellers can be found YUV #bits 8 or 10 bit on www.dektec.com. An OEM version of the DTU-245 without case is available upon request. USB port USB-2 Please contact DekTec for OEM conditions. Power (through USB-2) 5V, 400mA max Dimensions in mm (LxWxH) 87 x 104 x 30

© 2017 DekTec Digital Video BV www.dektec.com DTU-245 Product Leaflet Affordable Tools for Digital-TV Professionals January 2017 Lambert Vincent Table des figures 29 septembre 2017

B Table des figures

1.1 Réseau Dante™standard [1]...... 10

1.2 Déroulement de l’étude...... 12

3.1 Principe Unicast...... 19

3.2 Principe Multicast...... 19

3.3 Représentation signal analogique et numérique...... 21

3.4 Schéma de principe module Brooklyn II [4]...... 23

3.5 Spécifications module Brooklyn II[4]...... 24

3.6 Fonctionnement du protocole PTP[5]...... 25

3.7 Type de message ConMon[6]...... 26

3.8 Représentation d’un signal Audio PCM[7]...... 27

3.9 Schéma de principe TDM [9]...... 30

3.10 3 sons partiels avec fréquences proches...... 31

3.11 Représentation des masques et des fréquences...... 32

3.12 Représentation d’un masquage temporel...... 33

3.13 Schéma de principe G.722[12]...... 34

3.14 Largeur de bande G.722[13]...... 34

3.15 Schéma de principe Opus[14]...... 35

3.16 Comparaison méthode de compression audio[15]...... 36

4.1 Schéma de principe environnement de test...... 38

4.2 Capture multicast Dante au temps 0.0...... 39

4.3 Capture multicast Dante au temps 0.000082...... 40

4.4 Capture multicast Dante au temps 0.000082...... 40

4.5 Schéma de principe de l’installation réalisée...... 42

7.1 Représentation de la construction d’un flux TS...... 49

7.2 Architecture de ANEMAN™ ...... 50

7.3 Aperçu de l’interface ANEMAN [22]...... 51

8.1 Schéma de principe installation DTM-3200...... 52

Version 2.0 page: 92 Lambert Vincent Table des figures 29 septembre 2017

B.1 Exemple de paquet RTP...... 61

B.2 Exemple de paquet SR...... 63

B.3 Exemple de paquet RR...... 65

B.4 Exemple de paquet SDES...... 66

B.5 Exemple de paquet BYE...... 67

B.6 Exemple de paquet APP...... 68

B.7 Interface Dante Controller...... 69

B.8 Aspect général de la vue périphérique...... 71

B.9 Sélectionner interface...... 74

B.10 Selection du sampling...... 74

B.11 Selection encodage...... 76

B.12 Selection du nombre de canaux...... 76

B.13 Ouverture en mode Raw...... 77

B.14 Sélection fichier test.pcm...... 77

B.15 Configuration paramétres import...... 78

B.16 Ecoute des données audios...... 78

B.17 Centre réseau et partage...... 79

B.18 Fenêtre des interfaces...... 80

B.19 Réalisation d’une connexion pont...... 80

B.20 Fenêtre du pare-feu Windows...... 81

B.21 Fenêtre des options avancées du firewall Windows...... 82

B.22 Vue de la fenêtre des règles de trafic entrant...... 82

B.23 Fenêtre de l’assistant de création de règle de trafic entrant...... 83

B.24 Paramètres de la nouvelle règle de trafic entrant...... 83

B.25 Définition de l’action de la règle...... 84

B.26 Position de SW1 et SW2...... 84

B.27 Position de SW3...... 86

B.28 Position de SW6...... 86

B.29 Signal analogique à l’entrée de la carte PCM4222EVM...... 87

B.30 Signal numérique à la sortie de la carte PCM4222EVM...... 87

Version 2.0 page: 93 Lambert Vincent Liste des tableaux 29 septembre 2017

B Liste des tableaux

2.1 Risques identifiés...... 14

2.2 Représentation AMDEC...... 14

3.1 Modèle OSI...... 17

3.2 Composition Trame Ethernet standard...... 18

3.3 Plage IPv4 Multicast[2]...... 19

3.4 Format du paquet RTP[8]...... 28

3.5 Avantages et Désavantages de Dante™ ...... 29

3.6 Avantages et Désavantages de AES 67...... 29

4.1 Représentation du protocole Dante™audio...... 41

7.1 Comparatif flux vidéo non-compressé et compressé...... 45

7.2 Réduction de la définition d’une image HD en 4 :2 :2...... 46

7.3 Découpage image broadcast...... 47

7.4 Représentation de l’en-tête d’un paquet PES...... 47

7.5 Représentation de l’en-tête d’un paquet TS...... 48

7.6 Catégorie de PID TS [21]...... 48

B.1 Détail En-tête RTP [8]...... 61

B.2 Détail paquet type SR...... 62

B.3 Détail paquet type RR...... 64

B.4 Détail paquet type SDES...... 66

B.5 Détail paquet type BYE...... 67

B.6 Détail paquet type APP...... 68

B.7 Présentation des branchements des cartes Brooklyn-II PDK et PCM4222EVM.... 87

Version 2.0 page: 94