Bienvenue dans la rubrique Audio d'ActuAV.com.

La diffusion
La radio et la télévision sont globalement appelées le Broadcast. Cette activité se définit par la diffusion de sons et d'images selon un protocole unique choisi par le diffuseur (radio AM ou FM, Secam ou PAL, etc..) sans aucune requête des auditeurs, ni aucune interactivité avec eux : le broadcaster pousse l'information. Le médium traditionnel radio / TV est par ondes électromagnétiques avec un multiplexage fréquentiel : toutes les émissions existent simultanément et le client choisit son programme par changement de la fréquence d'accord du récepteur. Transmettre plus d'émissions demande simplement plus de fréquences disponibles mais aucune intervention ni dépense du client.

Or dans un réseau, le multiplexage est temporel : toutes les informations passent dans le même tuyau, les unes à la suite des autres. Transmettre plus d'émissions demande un débit supérieur, donc le remplacement du lien physique (de cuivre à fibre par exemple) par le client et à ses frais. Le client comme le serveur ont intérêt à limiter la quantité d'informations pour limiter les investissements. Le mode Broadcast existe dans les réseaux mais il n'est utilisé qu'à l'occasion d'opérations particulières, fréquentes mais peu gourmandes en bande passante (résolutions d'adresses notamment), et ne sort jamais du réseau local.

Le mode Multicast est plus astucieux car le client choisit le programme qu'il souhaite recevoir parmi ceux disponibles à ce moment et ne reçoit que celui-là (Cf. MaLigneTV, FreeBox, …). Le débit est donc limité aux informations voulues par le client. Le flux est le même pour tous les clients et cela limite le débit pour le serveur et l'opérateur. Le récepteur n'a toujours pas le choix du protocole ni du niveau de qualité car il est le même pour tous ; c'est l'émetteur qui décide. Le multicaster pousse l'information, de Point à Multipoint, à la demande du client. Hélas, le flux multicast n'est possible que sur un LAN ou sur un réseau d'opérateur (Free par exemple) mais pas sur Internet.

Pour avoir le choix du programme, du protocole, du niveau de qualité et du moment de réception, il faut passer en mode Unicast (comme le téléchargement ou la VoD - vidéo à la demande). Cette liaison unique est établie en Point à Point, à l'initiative du récepteur qui tire l'information, et fonctionne généralement de manière bidirectionnelle pour les applications professionnelles. Très avantageux pour le récepteur, ce mode est au détriment de l'émetteur qui doit s'adapter à chaque requête et nécessite un protocole de négociation préalable. Le mode Unicast est possible sur réseau local comme sur réseau public mais génère une forte charge du réseau.

La contribution
Dans les exemples cités ci-dessus, la diffusion en Multicast ou en Unicast concerne un produit fini, livré au destinataire pour être regardé et écouté mais pas pour être retravaillé. Le codec utilisé est donc optimisé pour réduire le débit au maximum avec une qualité acceptable et un délai de codage raisonnable, c'est-à-dire de l'ordre de quelques secondes.

Mais avant d'être fini, un programme AV nécessite de nombreux éléments qui concourent à sa fabrication : des flux internes (micros, serveur de musique, de news, ..), des flux externes (journalistes, retransmissions, ..) et des flux auxiliaires (réseau d'ordres, signalisation, ..).

Puisque les éléments sonores sont destinés à être recodés pour la diffusion, il convient que leur marge de codage (tandem coding) soit suffisante. Cette marge représente le nombre de codages - décodages successifs sans dégradation audible. Elle varie selon les algorithmes et le mélange des algorithmes entre 1 à 5 cycles avec une compression de type Diffusion, à une dizaine avec une compression de type Contribution. Une solution consiste à peu compresser (d'où un flux plus important) pour préserver le rapport Masque à Bruit. D'autre part, il convient que le délai de codage soit faible pour pouvoir tenir une conversation ou une interview sans se couper la parole. En fait, il vaudrait mieux parler de la latence, c'est-à-dire du délai supplémentaire total introduit par le réseau. Avec le RNIS sur ATM, un délai maximal de 50 ms était toléré de bout en bout. Pour la VoIP, l'ETSI (organisme normatif européen de téléphonie) a repoussé la tolérance à 150 ms. C'est dire si l'objectif est difficile à atteindre.

Jusqu'à maintenant, la majorité des flux externes et auxiliaires était transmise vers le diffuseur par le réseau téléphonique RNIS (ISDN en anglais). Son débit de 2 fois 64 kb/s a d'ailleurs conditionné une bonne partie des codecs audio en termes d'objectif de débit (par exemple MP3 à 64 ou 128 kb/s). Le RNIS est transporté par les réseaux téléphoniques au protocole ATM. Hélas, le coût d'exploitation des équipements RNIS est élevé et peu compétitif devant celui des équipements IP.

La fourniture du service RNIS est considérée comme une dépense importante par le client mais aussi par le fournisseur (l'opérateur historique suèdois a programmé pour 2007 la fin de son service RNIS). L'alternative pour les diffuseurs de programmes AV est évidemment d'utiliser IP. Mais on passe d'un protocole de flux à un protocole de paquets : il faut donc tout réadapter. Les 2 technologies cohabitent, l'une pouvant être le secours (backup) de l'autre pour des liaisons redondées.

(Document MAYAH Communications)

UER et N/ACIP
L'Union européenne de Radiodiffusion (EBU) est partie prenante de cette réadaptation en ce sens qu'elle est l'association de tous ceux qui utilisent ces flux de contribution. Elle a créé le groupe de travail N/ACIP (Audio Contribution over Internet Protocol) pour harmoniser au plus vite les procédures d'échange qu'il avait fallu si longtemps à mettre au point en RNIS et permettre ainsi l'interopérabilité entre fabricants. Evidemment les fabricants européens comme AETA et MAYAH, mais aussi américains comme ORBAN et TELOS, développent leurs équipements dans la direction indiquée par l'UER.