Revue technique

SÉLECTION 2008

Revue technique L’iPlayer de la BBC Mobiles libres pour la DAB

UER – REVUE TECHNIQUE SÉLECTION 2008

Compression vidéo SVC Tests UER de codecs HD Portail médias P2P de l’UER Audio sur IP de l’UER

Éditorial

3

Radio et télévision de rattrapage Évolution de l’iPlayer de la BBC Anthony Rose (Controller du Groupe Vision & Online Media de la BBC)

4

Mobiles de source ouverte Appareils mobiles libres – L’innovation des radiodiffuseurs pour des services BTH François Lefebvre (Chef de projet), Jean-Michel Bouffard et Pascal Charest (Centre de recherches sur les communications Canada)

16

Compression vidéo SVC : une version hautement scalable de l’H.264/AVC Adi Kouadio (Département technique de l’UER) ; Maryline Clare et Ludovic Noblet (Orange Labs, Recherche et développement – France Telecom) ; Vincent Bottreau (Thomson – Département recherche)

27

Codecs de production HD Test de codec de production TVHD Massimo Visca (RAI) et Hans Hoffmann (UER) Groupe de projet P/HDTP de l’UER

44

Webcasting Portail médias P2P de l’UER Franc Kozamernik (Département technique de l’UER)

54

Audio sur IP Programmes radiophoniques sur réseaux IP : une nouvelle norme de l’UER Lars Jonsson (Radio suédoise) et Mathias Coinchon (Département technique de l’UER)

2008 – REVUE TECHNIQUE DE L’UER

62

2008

La sélection

Bienvenue à la « Sélection 2008 » des meilleurs articles de la Revue Technique de l’UER qui ont été publiées électroniquement sur http:// tech.ebu.ch. Depuis 1998, la revue technique est publiée en ligne quatre fois par an en anglais. Le choix de ce mode de publication s’est révélé très concluant car il a permis d’élargir le lectorat. Il est très gratifiant d’apprendre que de nombreux lecteurs ont « découvert » la Revue Technique grâce à la version en ligne. Certains d’entre eux n’ont aucun rapport direct avec l’UER mais travaillent dans des domaines ou des sociétés proches de la radiodiffusion, comme les entreprises qui fournissent des logiciels ou du matériel aux organismes de radiodiffusion.

de lecture, de qualité, de prix et surtout de durée de vie des batteries ! L’ére de la disparition totale des documents papier n’étant pas encore arrivée, l’UER publie chaque année une sélection d’articles en version imprimée. Alors que la version en ligne est disponible uniquement en anglais, cette sélection d’articles est publiée en anglais et en français. Si vous appréciez la Revue Technique, n’hésitez pas à la consulter en ligne. Et surtout n’oubliez pas de donner son URL à vos amis et à vos collègues !

Notre service de publication électronique propose en ligne les archives de la Revue Technique de l’UER jusqu’à 1992. Ces archives réunissent de nombreux articles de grande qualité sur des sujets très divers. La navigation s’appuie sur une approche thématique. Une rubrique sujets d’actualité, récemment introduite, regroupe les articles qui traitent des questions sur le devant de la scène, comme la TVHD ou la radiodiffusion sur les dispositifs de poche. La version en ligne comprend en outre une liste des abréviations anglaises utilisées dans la revue technique au cours des 15 dernières années. Des nouveaux termes sont constamment ajoutés à la liste téléchargeable en cliquant sur le lien « Abbreviations » de la barre de navigation de la version anglaise.

Lieven Vermaele Directeur, EBU Technical

Début 2000, l’UER a décidé de ne plus publier la version papier de la Revue Technique. Toutefois, il était clair que la publication électronique ne pouvait pas remplacer totalement les exemplaires imprimés. Cet idéal sera atteint quand les ordinateurs seront en mesure de remplacer avantageusement les publications papier en termes de poids, de facilité


3

Radio et télévision de rattrapage

Évolution de l’

iPlayer de la BBC Anthony Rose Controller, Groupe Vision et Online Media, BBC

Depuis plus de dix ans, les Membres de l’UER développent et améliorent leurs sites Web afin de renforcer et d’accroître leurs activités principales de radio et télédiffusion. De simple médium d’information (donnant des informations textuelles et graphiques), le Web est aujourd’hui, pour les utilisateurs de PC connectés à Internet, un support de distribution du contenu audiovisuel des programmes des chaînes classiques (linéaires) et des services non linéaires (à la carte). La conception du iPlayer par la BBC est sans conteste l’un des meilleurs exemples pour illustrer le parti que les radiodiffuseurs peuvent tirer d’Internet en tant que mécanisme de distribution des nouveaux médias. Elle pourra sûrement inspirer d’autres radiodiffuseurs désireux de développer leurs services diffusés sur Internet. Cet article est basé sur une série d’appels téléphoniques qui ont eu lieu en août 2008 entre Franc Kozamernik (Département technique de l’UER) et Anthony Rose, Controller du groupe Vision & Online Media de la BBC, notamment chargé du iPlayer. Les profanes trouveront quelques informations de base sur le iPlayer dans l’encadré de la Page 5. Franc Kozamernik (FK) : Les Membres de l’UER s’intéressent beaucoup à l’évolution du iPlayer mis au point par la BBC. Le Comité de gestion de la distribution (DMC – Distribution Management Committee) de l’UER a constitué un groupe de projet, le D/ WMT (Technologies des médias en ligne), qui, sous la direction de Paola Sunna (RAI), doit mettre au point et évaluer un appareil similaire, appelé « lecteur média UER », qui sera capable de distribuer toutes sortes de contenu, notamment les flux reçus des

4

chaînes par satellite, terrestres, par câble et de TV sur IP, ainsi que des services de TV de rattrapage et de vidéo à la carte. Quels conseils pourriez-vous donner à ce groupe ?

de savoir s’il s’agira d’un système automatisé qui récupérera le contenu à partir d’un satellite ou d’une autre source, ou si une équipe s’occupera manuellement de traiter et d’acquérir le contenu.

Anthony Rose (AR) : En général, le principal problème que l’on rencontre pour mettre au point des services comme le iPlayer, ce n’est pas tant le site Web ou le système de lecture, ni même le système de transcodage, mais bien les métadonnées et l’ingestion du contenu.

FK : Pour l’instant, nous envisageons un système entièrement automatisé qui permettra aux utilisateurs de trouver le contenu qui les intéresse, par catégorie et selon d’autres critères. Les métadonnées seront diffusées par le DVB-SI et TVAnytime selon le cas.

Dans le cas du projet de l’UER que vous mentionnez, la première question à laquelle il faut répondre au moment de la conception est

AR : Je pense qu’il faut régler un certain nombre de questions importantes avant

REVUE TECHNIQUE DE L’UER – 2008


d’entamer un projet comme celui-ci. Par exemple, l’UER doit déterminer si elle veut que chaque radiodiffuseur crée son propre site Web par lequel les utilisateurs accéderont au contenu capturé, ou si elle préfère fournir un système générique de base (ce qui signifie qu’elle met en place un site Web entièrement fonctionnel) que chaque radiodiffuseur peut ensuite personnaliser pour le faire ressembler à son propre site ? Est-ce que les radiodiffuseurs devront négocier les droits pour chaque territoire ou est-ce l’UER qui le fera pour tous ? D’où tirerez-vous les métadonnées détaillées (nom des acteurs, descriptions des programmes entiers, etc. ?) Pensez-vous les extraire du signal DVB ou est-ce que les éditeurs devront se connecter séparément pour appliquer les métadonnées améliorées ? Il se peut que le projet de l’UER soit plus proche du système Redux mis au point par BBC Research que du iPlayer. Le Redux est un essai technique basé sur un système entièrement automatisé d’ingestion et de capture de médias, qui repose en grande partie sur des logiciels libres et n’intègre pas le management des droits (Anglais : DRM – Digital Rights Management). La BBC

utilise le Redux pour transcoder le contenu et l’envoyer sur ses plates-formes. C’est un système d’entrée très pratique et très flexible. Pour sa part, le iPlayer est un système qui fonctionne 24 heures sur 24, 7 jours sur 7, avec un effectif important, et qui traite un grand nombre de téléspectateurs. Nous nous assurons que notre système de métadonnées détaillées est parfaitement exact. L’un des principaux atouts du iPlayer réside dans le fait qu’il offre le bon niveau de protection du contenu pour les fichiers comme pour les flux, ainsi qu’une protection géographique, de manière à répondre aux préoccupations liées à la redevance et à la propriété du contenu. Il y a plus de chance que nous puissions mettre le Redux à la disposition de l’UER pour des essais que le iPlayer compte tenu des ressources dépensées en vue de commercialiser le iPlayer. De nombreux radiodiffuseurs européens nous contactent pour obtenir une licence du iPlayer. Il faut savoir s’ils veulent un système complet de bout en bout ou seulement des éléments isolés du système de production, du système de lecture ou du site Web du iPlayer. Après avoir dépensé plusieurs millions de livres des

contribuables, nous ne pouvons pas donner notre produit pour rien. Le Redux, quant à lui, a nécessité des investissements nettement moindres et pourrait peut-être être plus facilement mis à la disposition de tiers. FK : Nous aimerions nous concentrer sur le iPlayer maintenant. Quelle était la raison qui a poussé la BBC à le développer ? AR : En concevant le iPlayer, nous cherchions à mettre au point une solution destinée à l’utilisateur final, c’est-à-dire l’auditeur et le téléspectateur de la BBC, à une époque où les gens vont chercher leurs programmes de divertissement sur Internet et non plus seulement sur leur téléviseur. Que veut vraiment l’utilisateur ? Il se moque bien des codecs et de la taxinomie des métadonnées. Ce qu’il veut, c’est trouver le contenu qui l’intéresse. Nous ne voulons pas faire du iPlayer un site normal de partage de vidéo comme YouTube ou un magasin de musique comme iTunes, où il faudrait fouiller dans des milliers de programmes avant de trouver celui qui nous intéresse. C’est un mode d’utilisation différent. La raison pour laquelle les gens aiment venir sur le site iPlayer, c’est parce qu’ils peuvent y trouver un programme précis

L’iPlayer de la BBC en quelques mots Le iPlayer est une application en ligne, disponible à l’adresse www.bbc.co.uk/iplayer, qui permet aux utilisateurs d’Internet du RoyaumeUni de télécharger et de lire en continu les programmes de radio et de télévision de la BBC jusqu’à sept jours après leur diffusion. Les internautes sont ainsi en mesure de télécharger et de lire en continu les programmes dès qu’ils ont été diffusés sur une chaîne de TV ou de radio de la BBC. Ils peuvent conserver les téléchargements et les regarder autant de fois qu’ils le souhaitent au cours des 30 jours suivants. Tous les épisodes de certaines séries, surnommées Series Stacking (les séries en rayon), sont disponibles pendant 13 semaines. Dans quelque temps, les utilisateurs du iPlayer pourront s’abonner à une série de programmes et télécharger automatiquement chaque émission après sa diffusion. On a récemment ajouté au iPlayer des fonctions de streaming et en simultané afin de permettre aux utilisateurs de regarder des programmes TV en direct en plus des services de rattrapage à la carte. On peut accéder aux services iPlayer sur les appareils connectés à Internet large bande tels que les PC, les Mac d’Apple et les ordinateurs Linux, ainsi que sur le iPhone d’Apple, les consoles de jeu Wii de Nintendo et PS3 de Sony, les téléphones portables N96 de Nokia, les lecteurs de médias portatifs compatibles avec Windows Media et enfin les décodeurs Virgin Media. Pour découvrir les derniers développements du iPlayer, visitez le site www.bbc.co.uk/blogs/bbcinternet/iplayer/. Le iPlayer accueille maintenant plus d’un million de personnes chaque jour et traite jusqu’à 1,7 million de demandes de flux et de téléchargement. Il devrait répondre à sa 300 millionième demande début 2009.


5


qu’ils ont raté à la TV ou à la radio. Ils veulent retrouver un programme dont ils connaissent l’existence, mais qu’ils n’ont pas pu regarder ou écouter au moment de sa diffusion. Il est possible que dans les mois ou les années à venir, le iPlayer devienne un système de navigation général, dans lequel la demande proviendra de vous ou de vos amis plus que des grilles de programmation linéaires. En attendant, pour l’instant, il permet seulement de « rattraper » des programmes de radio ou de TV des grilles normales de la BBC. Quand nous avons lancé le streaming à Noël 2007, la page d’accueil ne présentait en tout et pour tout que six programmes, choisis par l’équipe de marketing de la BBC. Si c’était l’un d’eux qui vous intéressait, vous aviez de la chance parce qu’il était facile à trouver, directement sur la page d’accueil. Le problème, c’était quand le programme qui vous intéressait n’était pas l’un de ceux-là. Il fallait alors travailler un peu et faire des recherches par catégorie, par jour, par titre, etc. Comme c’était une opération qui non seulement pouvait se révéler complexe, mais parfois n’aboutissait pas, nous avons essayé de faciliter la recherche de programmes. En gros, avec la première page d’accueil que nous avons conçue, c’était « La BBC choisit ce que vous regardez ». Nous lui avons ensuite ajouté une zone « les plus populaires » ; là, c’étaient d’autres téléspectateurs (plutôt que la BBC) qui vous recommandaient certains programmes. Après sont arrivées les zones « viennent de rentrer » pour présenter les programmes les plus récents, et « dernière chance » pour ceux qui bientôt ne seront plus disponibles. Enfin, nous avons encore ajouté une option « dans le même genre », en guise de système de recommandation (semblable à celui utilisé par Amazon). Ces mécanismes de sélection du contenu se sont révélés extrêmement utiles et très appréciés des utilisateurs du iPlayer. FK : Contrairement à la Mediathek de ZDF en Allemagne, le iPlayer n’utilise pas d’évaluation. Pourquoi ? AR : En fait, nous avons envisagé d’ajouter un mécanisme d’évaluation, mais cela ne nous semble utile que pour recommander un programme à vos amis, plutôt que pour l’évaluer à la manière de YouTube. Si vous

6

avez un site Web de vidéo avec des millions de vidéos, qui peuvent être chargées par les utilisateurs eux-mêmes et sont souvent de qualité médiocre, vous avez sûrement besoin d’un système d’évaluation pour que les utilisateurs puissent dire celles qui valent la peine d’être regardées et celles qui ne sont pas intéressantes. Au contraire, si vous n’avez que 600 programmes de qualité professionnelle, il ne sert pas à grand-chose d’inviter les téléspectateurs à les évaluer. Par exemple, comment vous y prendriez-vous pour évaluer une chaîne de débats parlementaires ? Evaluer les programmes de la BBC n’apporterait pas grand-chose à l’utilisateur du iPlayer. D’une certaine manière, les programmes sont tous plutôt bons et destinés à différents publics. Nous devons cependant développer l’aspect des recommandations plus personnelles, c’est-à-dire quels programmes sont bons pour « vous ». Quand nous avons amélioré le site en lui ajoutant les zones de sélection dont je viens de parler, comme « les plus populaires », nous avons nettement facilité la recherche de programmes. Avant de lancer ces fonctions, nous nous sommes posé plusieurs questions : l

est-ce que les gens regarderont plus de programmes parce qu’ils peuvent en trouver davantage ? l est-ce qu’ils consulteront moins de pages (parce que la navigation est plus facile) ? l est-ce qu’ils consulteront plus de pages (parce que la navigation est plus facile) ? l est-ce qu’ils regarderont plus de programmes, mais pendant moins longtemps (ils peuvent voir les recommandations concernant d’autres programmes et décider de cliquer sur quelque chose d’autre avant la fin du programme en cours) ? Avant que nous appliquions ces recommandations, il fallait compter environ dix pages consultées par programme lu. Après la mise en place des changements, le nombre de pages consultées a diminué de 30 % tandis que celui des programmes lus augmentait de 30 %. Ces chiffres montrent bien que nos modifications ont réellement aidé les gens à trouver plus facilement les programmes qu’ils cherchaient. Maintenant, le nombre de pages consultées par programme regardé s’est stabilisé à cinq environ.

Il est intéressant de noter que le temps de visionnage moyen par programme n’a pas changé. Nous avons constaté qu’en moyenne, les gens regardent un programme qu’ils ont choisi pendant 22 minutes, et qu’ils regardent deux programmes par jour, avec un temps de visionnage moyen de 40 minutes par personne et par jour. Environ 35 % des programmes sont regardés en entier. C’est un résultat excellent compte tenu du fait que nos programmes durent généralement 30 ou 60 minutes. FK : Sur le plan éditorial, quelle est la relation entre le site Web de la BBC et iPlayer? Comment se distinguent-ils ? AR : Le iPlayer est une destination parmi d’autres à l’intérieur du site Web de la BBC. Bien souvent, un programme donné est proposé à la fois dans iPlayer et ailleurs dans le site Web de la BBC, ce qui permet aux utilisateurs de le découvrir et de le regarder dans le cadre dans lequel ils consultaient le site de la BBC. Par exemple, la plupart des gens ont utilisé le site des sports de la BBC, plutôt que le iPlayer, pour les Jeux olympiques de Pékin. Nous présentons le iPlayer comme le site d’hébergement du contenu de format long. Le site des sports, celui des actualités et d’autres sites de la BBC sont généralement consacrés à des formats plus courts, comme les clips d’actualités et les bandes-annonces de programmes. Ils couvrent aussi des événements en direct comme la cérémonie d’ouverture à Pékin : le streaming en direct a été regardé par plus de 100 000 utilisateurs simultanés sur le site ww.bbc.co.uk. En tout, le réseau de distribution (CDN) d’Akamai a fourni une capacité de flux de 45 Gbit/s. Pour le codage vidéo, on a utilisé le format flash VP6 de On2. La consommation des programmes des Jeux olympiques sur le iPlayer a été très bonne. Beaucoup de gens qui n’avaient pas pu regarder les événements au moment de leur diffusion sur les réseaux hertziens, câblés ou par satellite ont pu utiliser le iPlayer pour les regarder en différé. Par exemple, la cérémonie d’ouverture a été le programme le plus regardé sur iPlayer. Nous avons constaté une augmentation de plus de 20 % du trafic sur iPlayer après cet événement1. FK : Comment décririez-vous la structure du système iPlayer? Quelles sont les couches principales ?



1)

Cette interview s’est déroulée pendant les Jeux olympiques. Au cours de la deuxième semaine, alors que l’on passait à la phase finale des Jeux, la consommation du iPlayer a même augmenté de 40 %.


7


AR : Grosso modo, le iPlayer se compose de quatre couches : l

le site du portail de destination du iPlayer : c’est ce que tout le monde voit ; l le lecteur média intégré : un lecteur Flash, utilisé pour la lecture média dans le iPlayer et dans tout le site de la BBC ; l la production média : pour créer le contenu qui est utilisé par le lecteur Flash, mais que la plupart des gens ne peuvent pas voir ; l un système de distribution média. FK : Est-ce qu’on peut commencer par ce dernier point ? AR : Pour le streaming VP6 de On2, nous utilisons actuellement le CDN d’Akamai, mais pour le streaming H.264, nous utilisons celui de Level 3, qui est l’un des plus gros aux États-Unis (en août 2008, Akamai n’offrait pas le streaming H.264). FK : Pourquoi est-ce que le iPlayer de la BBC n’utilise pas un réseau pair-à-pair (P2P)? AR : La BBC a étudié plusieurs options de distribution, mais le P2P n’offre pas la solution optimale pour le streaming. Tout d’abord, les téléspectateurs ne veulent pas avoir à installer de module d’extension spécifique. Actuellement, pour utiliser le P2P, il faut installer d’autres logiciels. Ensuite, le P2P utilise l’unité centrale et la bande passante d’un ordinateur, et en général, la plupart des utilisateurs n’aiment pas ça. Si vous voulez télécharger du contenu via BitTorrent, vous accepterez peut-être d’utiliser le P2P et beaucoup de gens échangent volontiers de la bande passante contre du contenu gratuit. Mais dans le cas de la BBC, les gens paient une redevance de 130 £ par an et certains n’apprécient pas que nous leur demandions d’utiliser leur bande passante et d’installer un logiciel spécial. En particulier ceux qui ont peu de bande passante et ceux qui paient un supplément lorsqu’ils dépassent une certaine limite de téléchargement. Il était certainement avantageux d’utiliser le P2P il y a deux ans, mais le prix de la bande passante a diminué considérablement depuis, et les avantages liés à cette utilisation ont fondu également. Bien sûr, rien n’est jamais figé dans

8

le monde de la technologie et il est tout à fait possible que le P2P redevienne l’option la plus favorable dans un an ou deux. Nous connaissons naturellement Octoshape, Rawflow et quelques autres et nous avons étudié la possibilité de les utiliser pour distribuer le iPlayer. Nous sommes cependant très contents de notre système actuel de streaming basé sur un CDN ; on clique sur « Play » et en 300 ms environ, le flux commence. Les coûts et les économies potentielles pourraient être la seule raison de ne pas utiliser le streaming direct. Pour le téléchargement, nous utilisons pour l’instant le système P2P Kontiki, qui nous permet d’économiser environ 60 % de bande passante, et réduit ainsi de moitié notre facture de bande passante pour les téléchargements. Mais nous avons besoin d’une salle de serveurs très complexe pour compenser les coûts correspondants. À l’heure actuelle, la BBC exploite ellemême une énorme salle de serveurs, avec plus de 200 ordinateurs, mais seulement 8% du trafic est fourni par les serveurs (CDN). En fait, notre bande passante ne 2)

nous revient pas très cher, du moins pour les téléchargements. Si on examine ces différents éléments, on s’interroge sur les avantages du P2P. Pour nous, le P2P marche vraiment bien dans certains cas, surtout dans les cas où beaucoup de gens téléchargent un petit nombre de programmes ou de fichiers, parce qu’alors nous obtenons une bonne efficacité de l’appairage. Il ne marche pas bien lorsqu’on a un catalogue gigantesque, car le fichier téléchargé ne réside qu’avec quelques pairs. Pour le projet Kangaroo2, le P2P pourrait donner de bons résultats pour les 50 programmes les plus populaires, mais il ne sera pas optimal de l’utiliser pour un catalogue bien étoffé. Nous pensons que la bonne approche ne réside pas dans le P2P, mais dans une mémorisation amont dans le réseau (« edgecaching »). Nous n’avons que 500 heures par semaine de contenu vidéo, ce qui fait qu’un Téraoctet (To) de stockage suffit pour stocker tout notre catalogue. Il est possible de le faire plus efficacement en installant tout simplement un service « caching » dans notre réseau.

Article Wikipedia : http://en.wikipedia.org/wiki/Kangaroo_(video_on_demand) (en anglais)



légèrement différents. Pour notre part, nous voulons seulement que le iPlayer fonctionne pour que tout le monde puisse aller sur le site iPlayer, trouver un programme sur la page d’accueil, cliquer dessus et le regarder. D’autres services, comme BBC Research, ont une vision à plus long terme et aimeraient que les ISP offrent le multicast sur IP dans leurs réseaux. Naturellement, cela nous plairait aussi, mais la réalité d’aujourd’hui est, selon les statistiques du Royaume-Uni, que seuls 5 % des utilisateurs ont accès au multicast. Ce n’est probablement pas la peine d’investir autant d’efforts pour produire un système de multicast pour si peu d’utilisateurs. En fait, nous nous trouvons dans la situation de la poule et de l’œuf.

On peut envisager d’offrir une solution principale pour laquelle l’utilisateur n’a pas besoin d’installer de module d’extension, et une solution secondaire dans laquelle la qualité est meilleure (TV haute définition par exemple). Dans ce dernier cas, l’utilisation d’un module d’extension P2P pourrait être justifiée car les coûts de distribution du streaming en HD sont très élevés et pourraient être considérablement réduits avec le P2P. FK : Avez-vous pensé à combiner P2P et CDN, ce que les fournisseurs de ces deux types de technologie font de plus en plus ? AR : Avec le iPlayer, notre facture de bande passante n’est pas négligeable, mais nous pouvons la payer. Nous réalisons aux alentours de 100 To par jour de trafic en streaming, ce qui n’est pas rien. Le coût de la bande passante diminue très rapidement et la concurrence est rude entre les CDN. Pour l’instant, les coûts ne sont pas trop excessifs. Mais imaginez ce que ce sera dans un an ou deux, lorsque nous aurons un décodeur TV doté d’un iPlayer intégré et des millions de personnes en train de l’utiliser, chacune d’elles consommant 1,6 Mbit/s pour un flux TV. Nous aurons besoin de 10 fois plus de bande passante que maintenant. Évidemment, si cela


arrive, nous aurons un problème. La question est de savoir quelle est la meilleure solution à apporter à ce problème. Est-ce le P2P, devrions-nous équiper ce nouveau décodeur en P2P ou nous tourner vers une solution « edge-caching » des bords, conjointement avec les autres radiodiffuseurs et les ISP ? Nous ne connaissons pas la réponse, mais nous devons élaborer une architecture souple permettant de fonctionner avec différentes couches de transport. Nous devons séparer la couche de distribution des formats de distribution du contenu, de la DRM et du gestionnaire de téléchargement, afin de pouvoir ajouter facilement et rapidement différentes solutions selon les besoins. Bien sûr, nous suivons l’évolution de Tribler et des autres approches P2P des futures générations, ainsi que les systèmes hybrides dans lesquels le P2P est couplé à un cache, par exemple. FK : La BBC est célèbre pour ses essais de multicast sur IP. Est-ce que ce pourrait être aussi une option de distribution du iPlayer ? AR : BBC Research procède à des essais de multicast sur IP depuis un certain temps. D’autres services de la BBC ont des objectifs

Nous envisageons néanmoins, dans les mois à venir, d’utiliser JavaScript ou d’autres moyens pour déterminer si les utilisateurs ont accès au multicast et, dans ce cas, nous serons peut-être en mesure de leur offrir un flux de meilleure qualité. Ceux qui n’y auront pas accès recevront un flux de moins bonne qualité. De cette manière, les ISP comme les utilisateurs seront incités à s’intéresser au multicasting. Les utilisateurs choisiront probablement les ISP qui auront pu mettre leurs routeurs à niveau et qui leur proposeront des flux de meilleure qualité. FK : Au Royaume-Uni, on parle beaucoup, depuis quelque temps, de l’augmentation de la charge du réseau due au trafic à l’iPlayer. Est-il vrai que certains ISP se sont plaints auprès de l’organisme de réglementation des télécommunications ? AR : Les médias ont beaucoup déformé la situation en disant que le iPlayer va entraîner l’effondrement d’Internet et que tout va s’arrêter. C’est absolument faux. Nous avons longuement discuté avec les ISP et nous continuons à les rencontrer régulièrement. La réalité est qu’environ 7 % de l’utilisation de pointe d’Internet au Royaume-Uni est due au iPlayer. Notre trafic ne représente donc qu’une petite fraction du trafic général et ne va certainement pas causer l’interruption d’Internet. Il existe trois classes de réseaux de distribution de type FAI au Royaume-Uni : le câble (par exemple, Virgin Media), le dégroupage (Anglais : LLU – Local Loop Unbundling) et IPStream.

9


Atteindre l’utilisateur final par le câble ne coûte pas très cher. Dans le cas du dégroupage, les FAI (Anglais : ISP – Internet Service Providers) ont investi beaucoup d’argent pour installer certains équipements dans les commutateurs locaux, ce qui donne un coût par bit très bas. La troisième classe, IPStream, est une bande passante louée à BT Wholesale. Prenons quelques chiffres. On compte environ 5 000 points de présence (POP) dans l’ensemble du pays. Approximativement 1 500 d’entre eux fonctionnent en dégroupage. 30 % des utilisateurs sont desservis par le câble. Le coût du câble et du dégroupage est relativement bas, alors que celui de la bande passante pour IPStream est très élevé. C’est de là que vient le problème pour ces ISP, pas de la quantité de bande passante, puisque le iPlayer est loin d’atteindre la limite. Toutefois, nos statistiques audiométriques montrent que l’utilisation du iPlayer est la plus forte entre 18 heures et 23 heures, c’est-à-dire aux heures de pointe du trafic des ISP. Ces ISP ont une licence de bande passante pour IPStream qui est basée sur l’utilisation de pointe. C’est pourquoi le trafic de iPlayer leur coûte cher. Ce n’est pas seulement iPlayer, mais tout le trafic de YouTube, de Facebook et d’autres services qui leur coûte de l’argent. Selon nos statistiques, ce trafic est encore plus important que celui de iPlayer. La situation se complique encore du fait que certains ISP, comme Virgin Media (câble) proposent des offres de 50 Mbit/s, ce qui encourage les gens à utiliser davantage de bande passante. La consommation de bande passante par iPlayer et les autres gros consommateurs ne pose pas de problème à Virgin Media, mais d’autres ISP, qui vendent un service IPStream, sont mécontents car le trafic de iPlayer leur coûte plus cher. FK : C’est donc une situation très complexe, n’est-ce pas ? Comment prévoyez-vous de la résoudre ? AR : Je pense qu’à l’avenir, nous devrons avoir différents niveaux de services. Ce que nous devons faire, c’est créer des services iPlayer à différents niveaux de qualité et laisser les ISP proposer diverses offres de bande passante aux consommateurs. Par exemple, l’utilisateur qui veut une connexion dans une

10

bande passante plus élevée paiera davantage que celui qui se contente d’une connexion dans une bande passante inférieure. Bien sûr, personne ne devrait se retrouver avec une qualité inférieure à celle d’aujourd’hui. Au début, nous proposions le streaming à 500 kbit/s. Aujourd’hui, nous l’offrons aussi à 800 kbit/s et peut-être que dans trois mois, nous le proposerons à 1,5 Mbit/s.

correspondants. On se trouverait dans une situation où tout le monde est gagnant et où les ISP considèrent les services vidéo comme un centre de profit et non plus comme un fardeau financier.

Certaines personnes resteront à 500kbit/s, mais elles ne pourront pas découvrir nos flux de qualité supérieure. Si vous signez un contrat avec Virgin, vous ferez partie d’un système à 20 Mbit/s et vous pourrez télécharger un film en six minutes, au lieu d’une heure si vous n’avez qu’une ligne à 2 Mbit/s. Nous pourrions donc mettre en place un nouveau modèle commercial personnalisable. Par exemple, l’utilisateur obtient un service iPlayer de bonne qualité pour, disons, 10 £ par mois, mais s’il est prêt à payer 20 £, il aura un service de bien meilleure qualité.

AR : À Noël 2007, nous avons commencé à 500 kbit/s pour le streaming en direct et à 1,2 Mbit/s pour les téléchargements codés en WMV (Windows Media Video). Aujourd’hui, nous avons aussi du 800 kbit/s. À l’avenir, il ne devrait pas y avoir de différence entre les téléchargements et les flux, mais nous allons proposer plusieurs débits, par exemple 500, 800 et 1 500 kbit/s.

Si nous pouvons créer différents niveaux de qualité iPlayer, les ISP seront en mesure de trouver comment les commercialiser. Chaque fournisseur de contenu devra créer ces niveaux de qualité et les ISP pourront alors élaborer les modèles de commercialisation

FK : Quels débits binaires utilise-t-on actuellement pour le streaming et le téléchargement ?

L’autre chose que nous allons mettre en place, c’est les pré-réservations. L’utilisateur pourra alors télécharger automatiquement un programme pendant la nuit. Si vous laissez votre ordinateur branché et que, par exemple, vous avez regardé Dr Who la semaine dernière et la semaine d’avant, vous voudrez probablement le regarder aussi la semaine prochaine. Pour les ISP, la bande passante en heures de pointe est très chère, mais elle ne l’est pas pendant la nuit. Nous



savons que nos 20 programmes principaux représentent environ 70 % de notre bande passante totale. De cette manière, il serait possible de distribuer la plupart de nos programmes en dehors des heures de pointe, de les télécharger et de les enregistrer sur le disque dur local de l’utilisateur. On réduirait ainsi considérablement l’utilisation de la bande passante pendant les heures de pointe. Nous sommes en présence d’une économie mixte où la différence entre streaming et téléchargement devient floue. Dans ce scénario, la DRM s’appliquera à tous nos programmes et vous pourrez soit les lire en continu, soit les télécharger. Une personne ayant une bonne connexion réseau pourra les lire en continu, tandis que l’utilisateur ayant une vitesse de connexion plus lente les téléchargera et les regardera après, voire pendant le téléchargement. L’expérience première de l’utilisateur est et restera toujours le site Web iPlayer. Imaginez que vous vous rendez sur ce site pour regarder quelque chose. Vous ne devriez sûrement pas avoir à chercher sur votre disque dur pour savoir ce qui s’y trouve, votre page Web devrait maintenant être suffisamment intelligente pour savoir si le programme est déjà enregistré sur votre disque dur local et pour, dans ce cas, le lire à partir de votre disque local plutôt qu’à partir du serveur de la BBC. C’est cette intégration totale et transparente de la lecture en ligne et locale que nous aimerions mettre en œuvre en 2009. Un autre avantage est que les utilisateurs peuvent tout simplement débrancher leur ordinateur et regarder le programme téléchargé hors connexion, par exemple à bord d’un avion. FK : La BBC a récemment installé des codecs H.264 pour le iPlayer et certains utilisateurs se sont plaints d’une mauvaise accessibilité. Pourquoi ? AR : Les codecs H.264 nécessitent des processeurs plus puissants et de meilleures cartes graphiques. Nous avons passé pas mal de temps à étudier ce problème. Certains paramètres de compression H.264 produisent des résultats brillants, mais exigent un ordinateur et une carte graphique haut de gamme. Si vous avez un processeur à double cœur équipé d’une carte graphique haut


de gamme, bravo, vous pouvez avoir de la HD à 4 Mbit/s. Cependant, si vous avez un ordinateur portatif bas de gamme, la qualité est mauvaise, avec une vidéo tournant à 10 images par seconde ou moins. Vous devez donc choisir soigneusement le profil que vous utilisez pour vous assurer que la vidéo s’exécute en transparence sur de nombreux types d’ordinateurs. La norme H.264 prévoit trois profils (Baseline, Main et High) pour chacun desquels vous pouvez activer différentes fonctions. Nous avons choisi le profil Main et l’accélérateur vidéo pour la lecture plein écran comme paramètre par défaut. Nous nous sommes aperçus depuis que pour notre configuration, un codec H.264 n’utilise pas plus de puissance d’unité centrale qu’un codec VP6 de On2. En fait, c’est même le contraire en mode plein écran et comme nous utilisons l’accélération vidéo, il consomme moins de puissance d’unité centrale. Il faut faire attention car un codec H.264 ne tourne pas sur les appareils bas de gamme, mais si on choisit les équipements soigneusement, il peut constituer une très bonne solution pour l’utilisateur. En réalité, c’est un peu plus compliqué que ça car les ordinateurs Mac plus anciens fonctionnent mal avec les codecs H.264 et réussissent mieux avec les VP6 de On2. Il y a un problème avec les ordinateurs plus anciens. Mais avec les appareils plus récents, si on choisit bien, je le répète, on peut en fait obtenir de meilleurs résultats.

n’est pas encore dotée de la fonction de rendu du Windows Media Player. FK : Est-ce la raison pour laquelle la BBC envisage aussi AIR d’Adobe? AR : AIR d’Adobe marche bien avec les appareils H.264 et peut très bien convenir pour le téléchargement avec son système de DRM, car il répond notamment à l’exigence d’être entièrement multiplate-forme et en plus, s’exécute sur PC, sur Mac et sur Linux. FK : Les radiodiffuseurs se heurtent souvent au problème des codecs sous licence. Quelle est votre expérience dans ce domaine ? AR : Le iPlayer utilise maintenant des codecs H.264 et la question de la licence ne se pose pas. Si on utilise Flash, les contrats d’Adobe couvrent les droits de licence de lecture. La position de la BBC est qu’il n’y a pas de droit H.264 par flux. FK : BBC Research travaille à un codec de type source ouverte, sans licence, appelé Dirac. L’UER prévoit d’en évaluer les mérites techniques car de nombreux Membres pourraient souhaiter l’utiliser pour la distribution sur Internet. Est-ce que le système iPlayer prévoit de migrer à Dirac ?

Le MPEG-2, ancien, n’est plus dans la course car les exigences en matière de débit binaire sont bien trop élevées. Les deux autres solutions de codage possibles sont le VC-1 de Microsoft et le VP6, ou plutôt le VP7, de On2. Beaucoup de personnes les ont évalués, ainsi que d’autres codecs, et en général, c’est le H.264 qui l’emporte. Mais ce n’est pas toujours aussi net. Pour les ordinateurs bas de gamme, le meilleur choix est le VP6 de On2. Par ailleurs, si vous visez des ordinateurs Windows et la lecture plein écran, je pense que Microsoft a fait du vraiment bon travail avec son programme de rendu Windows et que le VC-1 marche superbement, même sur les appareils Windows bas de gamme, mais il ne passe pas bien sur Mac.

AR : Pour l’instant, il nous semble préférable de concentrer le Dirac sur le codage vidéo de haute qualité plutôt que sur la transmission sur Internet. Prenez les éléments nécessaires à une bonne transmission sur Internet et qui doivent être intégrés au flux de travaux de production (à l’aide de TeleStream, AnyStream ou un autre logiciel de flux de travaux) : vous voyez tout de suite que vous avez besoin d’un codec que vous pouvez inclure dans le logiciel de flux de travaux. Ensuite, il vous faut un serveur de streaming avec un CDN qui connaît ce format de codec. Vous avez aussi besoin d’un modèle de protection des droits (DRM), et l’ordinateur de l’utilisateur doit être équipé d’un module d’extension avec un bon rendu, capable d’ajuster la vitesse de défilement, et ainsi de suite. Il y a en fait pas mal d’éléments à assembler.

Microsoft Silverlight est une application multiplate-forme, mais malheureusement elle

Actuellement, le Dirac est un codeur autonome et n’a pas encore été intégré dans les

11


différents flux de travaux. Le lecteur Dirac n’est pas tout à fait adapté au temps réel sur les appareils bas de gamme. Il n’y a pas d’intégration avec les CDN et aucun module d’extension n’a encore été développé. Il est donc prématuré de commercialiser le Dirac pour l’instant, mais le temps viendra. FK : Quelle est l’importance de la gestion des droits numériques (DRM) pour le iPlayer ? AR : On ne peut pas se contenter de ne s’intéresser qu’au streaming et au téléchargement. Pour les émissions analogues ou numériques générales, nous n’utilisons pas de DRM ou d’obscurcissement, et les gens peuvent faire ce qu’ils veulent, quand ils le veulent, avec le contenu reçu. Il est facile d’enregistrer les émissions en direct et nous n’essayons pas d’empêcher les gens de le faire. Pour ce qui est du streaming sur Internet, nous n’utilisons pas de DRM (au sens classique du terme), mais nous recourons à certaines techniques d’obscurcissement du flux. Pour résumer, un flux doit rester un flux, il ne doit pas se transformer en téléchargement. Et donc si un flux reste un flux, nous ne pensons pas avoir besoin de lui appliquer de la DRM. Pour empêcher un flux de devenir un téléchargement, nous utilisons des technologies comme le RTMP ou autres, qui garantissent qu’un flux demeure un flux.

Microsoft est l’une de ces sociétés, avec son produit appelé MMS. Il existe aussi une norme ouverte, le RTSP (protocole de streaming en temps réel), et la norme privée d’Adobe, RTMP (Real Time Messaging Protocol) et sa version chiffrée, RTMPE. Cette dernière offre une meilleure protection, mais nécessite davantage de puissance d’unité centrale sur l’ordinateur de l’utilisateur. Pour l’instant, nous n’en voyons pas la nécessité dans la mesure où il n’y a pas beaucoup de fraude ou de piratage. Nous vérifions régulièrement s’il y a du piratage et ce n’est pas le cas pour le moment. De plus, étant donné que le programme a été diffusé en clair la veille, ce n’est pas rentable et nous ne voyons vraiment pas la nécessité d’appliquer la DRM au contenu de streaming. Notre position est naturellement différente pour le téléchargement. Dans ce cas, nous devons appliquer la DRM à nos fichiers pour deux raisons. Tout d’abord, les titulaires des

droits sur le contenu ne les accordent que pour le Royaume-Uni. Ensuite, le contenu ne doit être disponible que pendant une durée limitée afin de pouvoir être exploité commercialement, comme le programme Top Gear, sous licence de BBC Worldwide. Les radiodiffuseurs américains qui paient des millions de livres à BBC Worldwide pour obtenir les droits de diffusion verseraient probablement moins sans DRM puisqu’ils pourraient trouver le contenu ailleurs. C’est la raison principale pour laquelle les titulaires des droits imposent la DRM. De plus, BBC Trust (l’organe directeur de la BBC) exige que les fichiers ne soient disponibles que 30 jours après le téléchargement et sept jours après leur diffusion. Ce sont les raisons pour lesquelles nous devons appliquer la DRM aux téléchargements. Pourtant, tous les propriétaires de contenu n’exigent pas la DRM. Par exemple, nous n’avons pas besoin de DRM pour notre

FK : Quelle expérience de l’utilisation du RTMP avez-vous? AR : Si vous vous connectez à un fichier média à partir d’un serveur HTTP, votre lecteur média va s’ouvrir et commencer à le lire : c’est ce qu’on appelle un téléchargement progressif. Le fichier lu aboutira probablement dans le cache de votre navigateur et il serait alors très facile de copier ce lien et de le placer dans une autre application qui vous permettrait de l’enregistrer. Le problème que présente cette approche, c’est qu’il devient facile d’enregistrer un fichier qui n’est destiné qu’à une lecture en continu. Donc, nous ne le faisons pas. Beaucoup de sociétés vendent des systèmes de streaming qui ne vous permettent pas facilement d’enregistrer le fichier. Ils obligeront votre lecteur média à jeter les segments du fichier lorsqu’ils ont été lus au lieu de le laisser les enregistrer dans votre disque dur.

12



chaîne parlementaire. Nous sommes cependant obligés de l’appliquer compte tenu des restrictions temporelles et d’utilisation encore en vigueur, mais la communauté en faveur des sources ouvertes, bien sûr, affirme que nous ne devrions pas appliquer de DRM du tout. FK : Vous venez de nous expliquer pourquoi il faut ou ne faut pas appliquer la DRM au contenu du iPlayer, mais il reste une question : quelle DRM utilisez-vous pour contrôler l’utilisation du iPlayer ? AR : La communauté en faveur des sources ouvertes nous reproche d’utiliser la DRM de Microsoft et nous conseille de recourir à un de ses systèmes. Nous avons fait nos devoirs et avons étudié tous les systèmes de DRM viables. Nous avons discuté avec les sociétés qui les développent, nous avons examiné les technologies et nous les avons évaluées. La réalité est que jusqu’à très récemment, le système de Microsoft était le seul viable. Il est gratuit, sûr et approuvé par les marques de Hollywood, ainsi que par les titulaires des droits. Il est facile à installer sur les serveurs et les clients. Le problème, c’est qu’il ne fonctionne que sur Windows. D’autres sociétés qui proposent des systèmes de DRM, comme Apple, ne donnent pas accès au système. La seule manière d’offrir le contenu avec la DRM d’Apple, c’est de le placer dans le magasin iTunes, ce qui en fait implique de segmenter notre contenu. C’est pourquoi le contenu du iPlayer de la BBC n’est pas disponible dans le magasin iTunes. Apple voudrait que nous lui donnions notre contenu pour le mettre dans le même seau qu’un million d’autres programmes. Pour la BBC, cela équivaudrait à donner le contenu des programmes de BBC1 à ses concurrents pour qu’ils le mettent sur leurs sites. Ce n’est naturellement pas acceptable. Nous avons demandé à Apple de nous donner accès à son système de DRM, mais pour l’instant nous ne l’avons pas obtenu. La bonne nouvelle, c’est que d’autres sociétés comme Adobe sont en train de développer des produits de DRM multiplate-forme. AIR d’Adobe propose déjà la DRM pour PC, Mac et Linux. Nous espérons avoir une solution multiplate-forme, basée sur AIR et DRM d’Adobe, d’ici la fin de l’année.


FK : Les services iPlayer ne sont pas disponibles en dehors du Royaume-Uni. Chez moi, en Suisse, j’ai reçu le message « Indisponible dans votre région ». Pourquoi limitez-vous le iPlayer au territoire du Royaume-Uni ? AR : Pour deux raisons. L’une est les droits. Les titulaires des droits vendent leur contenu dans chaque territoire. Les programmes classiques sont ciblés géographiquement par le rayonnement de l’émetteur et la portée de la TV est généralement très faible. Mais sur Internet, les flux peuvent aller n’importe où. Les modèles de licence sont en pleine évolution, mais sont encore limités par un cadre de télédiffusion, ou fonctionnent dans un tel cadre. La BBC possède une licence pour émettre au Royaume-Uni et ce sont généralement les droits de licence que nous acquérons. L’autre raison est moins évidente : les services publics sont financés par les contribuables britanniques qui paient la redevance. Dans la mesure où il y a toujours un coût de distribution sur Internet, il n’est pas juste qu’un contribuable britannique paie pour la distribution d’un programme à un téléspectateur en Amérique. Même lorsque nous détenons les droits qui nous permettent de diffuser en dehors du Royaume-Uni ou de proposer le contenu en dehors du pays, nous faisons en sorte que les contribuables britanniques ne financent pas la distribution. BBC Worldwide peut le faire, couvrir les coûts de distribution ou diffuser des publicités pour soutenir le modèle. Voilà les deux raisons pour lesquelles nous avons besoin d’un verrouillage géographique. FK : Quel système de géolocalisation utilisez-vous et quelle en est l’efficacité? AR : La réponse est fort simple. Nous utilisons des tables de correspondance des adresses IP au Royaume-Uni, qui sont conservées dans une base de données Quova. Ces listes sont mises à jour régulièrement. Nous vérifions l’adresse IP de l’utilisateur. Si elle est située au Royaume-Uni, pas de problème, sinon, nous répondons « Désolés, vous n’avez pas accès ». Pourquoi ne pas utiliser la base de données Geolocation d’Akamai ? Tout d’abord, cela nous obligerait à utiliser uniquement Akamai

et nous ne voulons pas faire appel à Akamai pour tous les services. En fait, le contenu H.264 est maintenant distribué par Level 3 Communications Inc. Stratégiquement, c’est mieux que d’avoir notre propre système de contrôle central. Ensuite, nous devons tenir à jour nos listes blanches et nos listes noires. Par exemple, parfois nous décidons d’installer un proxy pour essayer d’accéder à iPlayer depuis l’extérieur du Royaume-Uni. Nous devons alors être en mesure d’effectuer ce contrôle nous-mêmes, sans dépendre d’Akamai. Nous avons une autre raison pour ne pas dépendre du service de géolocalisation d’une société de CDN : nous voulons vraiment informer l’utilisateur qu’il n’aura pas accès à la vidéo dès qu’il consultera la page Web de iPlayer, au lieu d’attendre qu’il ait cliqué sur le bouton Play et reçu un message d’erreur de streaming. Nous devons réellement connaître l’emplacement géographique au moment où nous envoyons la page Web, afin de pouvoir afficher un message aimable pour informer l’utilisateur qu’il n’a pas accès au contenu, du genre : « Nous sommes désolés, mais comme vous ne vous trouvez pas au Royaume-Uni, vous ne pouvez pas accéder à la TV. Vous pouvez cependant écouter la radio. » Si nous confiions simplement l’application de la géolocalisation au service de streaming de la société de CDN, l’utilisateur recevrait un message d’erreur de flux, qui ne lui expliquerait pas pourquoi il ne peut pas accéder au contenu. Les choses se compliquent aujourd’hui avec l’accès 3G. Par exemple, vous pouvez avoir signé un contrat d’itinérance avec Vodafone UK. Si vous êtes en France, notre système peut penser que vous êtes encore au Royaume-Uni, même si en fait vous êtes en France. C’est un nouveau type de problème. Il n’est pas encore très généralisé car l’accès en itinérance est tellement cher que cela vous coûterait probablement une fortune de recevoir les programmes de la BBC à l’étranger sur un téléphone portable. C’est pourquoi il n’y a pas beaucoup de gens qui essaient. Nous allons néanmoins devoir modifier légèrement les adresses IP et collaborer avec les vendeurs de 3G pour nous assurer que vous vous trouvez au Royaume-Uni, même si Vodafone UK a un accord d’itinérance avec la France.

13


Anthony Rose est Responsable du Vision & Online Media Group de la BBC, dans le cadre duquel il dirige une équipe de plus de 200 personnes qui sont chargées du iPlayer de la BBC, du lecteur médias intégré, des médias sociaux, de la syndication, des sites Internet des programmes et d’autres projets de la division Future Media & Technology de la BBC. M. Rose a rejoint la BBC en septembre 2007, après avoir travaillé pendant six ans pour Kazaa/Altnet où il a participé à une série de projets et de brevets concernant les réseaux P2P, la publication du contenu basée sur la gestion numérique des droits et les services de réseautage social. Avant de commencer à travailler pour Kazaa/Altnet, M. Rose a été Vice-président de la technologie chez Sega Australia New Developments, qui mettait au point des animations 3D en temps réel et des moteurs graphiques 3D.

FK : Quel type d’ententes avez-vous avec les ISP pour qu’ils vous fournissent les adresses IP des utilisateurs? AR : C’est Quova qui s’occupe de ces ententes et qui met régulièrement à jour les tables de correspondance. Les ISP sont eux aussi en mesure de le faire. Ces dispositions nous conviennent parfaitement, elles sont efficaces à 99,9 %. FK : Vous avez étendu le contenu aux appareils mobiles comme le téléphone portable N96 de Nokia. Pouvez-vous nous décrire les grandes lignes de ce processus ? AR : Nous avons étudié la création de contenu non seulement pour les PC, mais aussi pour certains appareils portables. Auparavant, si vous utilisiez des fichiers de Windows Media Video (WMV) et les téléchargiez dans votre lecteur média portatif, ils risquaient soient d’être refusés par l’appareil, soit d’être lus avec un affaiblissement sensible de l’image. À compter de septembre, nous allons créer du contenu spécifiquement pour les appareils mobiles compatibles avec Windows Media. Nous travaillons à une version spéciale à basse résolution, suffisamment petite pour être téléchargée et bien fonctionner sur ces appareils. La résolution standard sur ces appareils est de 320 x 240 pixels. Pour l’instant, la résolution de notre principal profil pour PC est de 720 x 544 pixels non carrés, ce qui donne la 3)

meilleure qualité sur un PC, mais ne convient pas aux petits appareils portatifs, pour lesquels nous prévoyons donc de produire un certain nombre de formats encodés spéciaux. Pour ce qui est du téléchargement de ces formats, nous proposons plusieurs options. Les formats seront encore essentiellement disponibles à partir du site iPlayer destiné aux PC, mais nous mettrons en place plusieurs sites Web adaptés au téléchargement du contenu sur divers appareils mobiles et portatifs, comme le Nokia N96, etc. Pour certains qui, selon nous, offrent une expérience intéressante à l’utilisateur, nous pensons préparer une version spéciale de ce site, qui adaptera automatiquement le contenu aux caractéristiques de l’appareil mobile (taille de l’écran, résolution, etc.). Le premier de ces appareils était le iPhone. De cette manière, si vous consultez le site iPlayer à partir d’un iPhone, vous obtenez une version en ligne agréablement personnalisée. La BBC produira une version personnalisée de ce site pour un certain nombre d’appareils mobiles et portatifs afin que le média s’exécute automatiquement dans le bon format pour cet appareil. FK : Prévoyez-vous que le iPlayer sera accessible à partir de décodeurs et d’appareils grand public comme les téléviseurs? AR : La réponse est oui. Le problème vient du fait que ces appareils essaient souvent

d’agréger différents contenus dans un seul portail. Dans la mesure où ce n’est qu’un appareil de lecture comme les Windows Media Extender3, la réponse est, en gros, que nous aimerions que le contenu iPlayer s’y trouve. Si les fabricants sont capables d’offrir l’expérience du site iPlayer, nous aimerions travailler avec eux. Mais s’ils veulent prendre les programmes de la BBC et les mettre dans leur propre interface, d’une manière générale, notre réponse est non. La BBC ne peut pas accepter de tout simplement offrir son contenu à d’autres sites Web pour que ceux-ci les exploitent ensuite commercialement. Si vous faites une recherche dans Google sur « BBC IPTV », vous verrez que nous annonçons notre intention de travailler à des décodeurs de TVIP qui sont déjà ouverts et mis à la disposition, soit de tout le monde, soit de certains tiers. C’est une très bonne solution de TVIP de la deuxième génération. L’un des problèmes réside dans le fait que souvent ces décodeurs ne sont pas nombreux sur le marché et qu’il est vraiment très difficile de les trouver. En d’autres termes, cela représente une énorme charge de travail pour nous, mais très peu de consommateurs en profiteront. La rentabilité n’est pas là, et c’est pourquoi nous ne travaillons pas à ce projet pour l’instant. Aujourd’hui, il y a un certain nombre de différents fournisseurs et le marché est encore relativement petit, quelques centaines de milliers d’abonnés. Mais la situation changera peut-être.

Windows Media Center Extender est un décodeur configuré pour se connecter, via une liaison réseau, à un ordinateur exécutant Windows XP Media Center Edition ou Windows Vista de Microsoft afin de lire en continu les fonctions de centre de média de l’ordinateur dans l’Extender, ce qui permet d’utiliser le Media Center et ses fonctions sur un téléviseur classique ou un autre afficheur. Le Media Center domestique peut être physiquement installé dans une pièce mieux adaptée à son rôle, plutôt que le salon. De plus, avec un Extender, plusieurs utilisateurs peuvent accéder au Media Center simultanément. La console de jeu Xbox 360 est un exemple très connu de Media Center Extender.

14



FK : Merci de nous avoir expliqué les questions les plus brûlantes au sujet du iPlayer. Je suis certain que les Membres de l’UER trouveront cet article très intéressant et très utile. S’ils ont d’autres questions, peuvent-ils vous les poser directement ? AR : Bien sûr. Vous pouvez leur donner mon adresse électronique si nécessaire. Première publication : 2008-Q2

Note de FK : Depuis l’interview (en août 2008), le iPlayer a connu des développements logiciels constants, avec l’ajout de nouvelles fonctions et fonctionnalités presque chaque semaine. Pendant la Microsoft Professional Developers Conference, en octobre, Anthony Rose a présenté une démonstration de la synchronisation du contenu iPlayer entre ordinateurs et appareils mobiles à l’aide d’une application de bureau de Microsoft, appelée nuage Live Mesh et basée sur la technologie multiplate-forme Silverlight. Cette application synchronise automatiquement les programmes téléchargés sur tous les appareils compatibles avec le iPlayer sur le réseau Mesh de la personne, y compris sur les ordinateurs Mac, qui ont également un client de téléchargement pour le iPlayer. Le nouveau prototype du iPlayer s’enrichit aussi de plusieurs fonctions de réseautage personnel, comme les listes des programmes les plus populaires regardés par vos amis sur la liste MSN Messenger et les mises à jour sur les programmes téléchargés et regardés par chacun de vos contacts. Les utilisateurs du iPlayer pourront aussi évaluer des scènes de l’émission au fur et à mesure (à l’aide du « Lovemeter »), ce qui permettra de déterminer les parties des programmes que le public a préférées. Erik Huggers, directeur du groupe Future Media and Technology de la BBC, a récemment

4)

affirmé que la réussite du iPlayer est la preuve que l’entreprise a raison de miser sur son avenir sur Internet. Il a déclaré que le service de TV de rattrapage en ligne a fourni 248 m de sujets de contenu depuis son lancement officiel, le jour de Noël 2007. À lui seul, le service iPlayer offert par le service câblé de Virgin Media a livré 49 m de vidéos depuis juin 2008. La série dramatique East Enders, qui attire une moyenne de 18,9 millions de téléspectateurs chaque mois sur BBC1 et BBC3, a été regardée par 457 000 personnes environ sur le iPlayer. Le programme de la chaîne numérique CBBC, MI High, obtient quant à lui une part beaucoup plus grande de téléspectateurs sur le iPlayer : il compte en effet un public TV de 145 000 personnes, plus 30 000 sur le iPlayer. Huggers est affirmatif : le public en ligne n’a pas « avalé » celui de la TV. Le iPlayer est populaire la journée pendant les heures de bureau mais, le taux d’écoute atteignant son maximum le soir vers 21 heures, la forte demande se poursuit en général une heure de plus que celle de la TV. Les données de la BBC sur les utilisateurs montrent que des gens de tous âges utilisent le iPlayer : les 15 à 34 ans représentent 37 % de son public, les 35 à 54 ans 43 %, les 55 ans et plus constituant les 21 % restants. Huggers attribue la popularité du iPlayer à sa facilité d’utilisation. La priorité est de proposer le iPlayer sur autant de plateformes qu’il est possible économiquement de le faire. Avec 85 % du

public total, les utilisateurs de PC demeurent la grande majorité des téléspectateurs du iPlayer, la Wii de Nintendo et Linux comptant chacun pour 1 %. L’équipe Future Media and Technology de la BBC ne s’attendait pas au succès du iPhone et du iPod Touch. Pour leur part, les utilisateurs de Mac représentent 10 % du public du iPlayer, les propriétaires de iPhone et de iPod Touch, 3 %. Erik Huggers conclut sa présentation par les remarques suivantes : « N ous sommes en présence de situations intéressantes, avec les parents qui regardent la TV linéaire dans le salon tandis que les enfants suivent leurs programmes différemment … sur un iPhone, un iPod Touch ou un ordinateur portable. » « Maintenant que j’ai vu tout cela et que je comprends mieux la réussite du service, les types d’utilisateurs, ce qu’ils regardent et quand ils le regardent … je pense que la BBC mise totalement sur le protocole Internet, mais pas uniquement pour l’élément distribution que permet Internet. » « Nous sommes en train de repenser entièrement la manière dont nous produisons des programmes fantastiques. »

Article dans le Guardian : www.guardian.co.uk/media/2008/nov/07/bbc-erikhuggers


15

Mobiles de source ouverte

mobiles libres Appareils

– L’innovation des radiodiffuseurs pour des services BTH

François Lefebvre (Project Leader), Jean-Michel Bouffard and Pascal Charest Communications Research Centre, Canada

Les technologies émergentes de radiodiffusion mobile pourraient servir à acheminer bien d’autres services que de simples programmes audio ou vidéo. Depuis longtemps déjà, les radiodiffuseurs ont imaginé et normalisé de nombreuses applications multimédia et de données qui, malheureusement, n’ont pas réussi à s’imposer sur le marché. Dans la première partie de cet article, nous allons montrer que les appareils mobiles libres (ou à code source libre) qui font leur apparition grâce aux récentes percées technologiques, pourraient également mener à l’émergence d’applications radiodiffusées sur les appareils mobiles. Dans la seconde partie, nous décrirons le projet Openmokast et expliquerons comment le CRC a pu produire, avec des ressources très limitées, le premier prototype de téléphone portable libre, capable de recevoir et de décoder des services de radiodiffusion en temps réel. L’ e n g o u e m e n t e s t d e p l u s e n p l u s prononcé aujourd’hui pour les services de radiodiffusion mobile (BTH) décrits par Weck et Wilson dans la Revue technique de l’UER [1]. Ces services s’appuient soit sur les normes de radiodiffusion telles que la DAB/DMB et ATSC -MH, soit sur celles proposées par le secteur des télécommunications mobiles comme DVB-H ou MediaFLO. Ces technologies offrent aux utilisateurs mobiles des mécanismes efficaces de distribution d’informations actualisées, des médias populaires ainsi que de précieux services de données. Avec l’intérêt que suscite actuellement la convergence des médias enrichis, les technologies de télécommunications mobiles et BTH offrent des caractéristiques complémentaires. Les infrastructures de BTH promettent de transmettre de grands volumes de contenu intéressant dans les communications de type

16

un à plusieurs, tandis que les réseaux de télécommunications sans fil peuvent fournir les canaux des échanges un à un. Cet intérêt a conduit à la préparation de bien des normes nouvelles sur les services de BTH dans le cadre de la DAB : transport MOT, Broadcast Web Site (BWS), SlideShow, DLS, TopNews, GEP et TPEG. Mais seules quelques-unes de ces normes ont été mises en œuvre dans les récepteurs commerciaux. La norme BWS, par exemple, qui pourrait servir à fournir des services d’information très intéressants, n’est généralement pas prise en charge dans les récepteurs actuels. Dans le reste de cet article, nous appellerons « applications manquantes » ces applications qui n’ont pas réussi à percer. On peut expliquer la stagnation des avancées technologiques de la BTH par

l’écosystème innovant et compétitif des communications sans fil qui s’épanouit aujourd’hui. Plusieurs types de nouvelles technologies de communications sans fil sont en train de voir le jour, cherchant à atteindre les utilisateurs mobiles, où qu’ils soient, avec un débit maximal. On dirait que la BTH se trouve à un carrefour entre les radiodiffuseurs et les exploitants de réseaux mobiles (ERM). Leurs modèles commerciaux sont opposés. Les radiodiffuseurs tendent naturellement à poursuivre et à développer leurs services en clair, financés par des fonds publics, les redevances et la publicité. Les ERM, pour leur part, prévoient de déployer des services de BTH pour générer de nouvelles sources de revenus s’inspirant des modèles d’abonnements au câble et de la télévision à péage.



Internet aussi remet en question le modèle de la radiodiffusion traditionnelle. Il a entraîné des cycles d’innovation rapide qui offrent des avantages importants aux utilisateurs finaux. Par exemple, la webdiffusion, la diffusion poste à poste et la baladodiffusion sont toutes de séduisantes concurrentes de la radiodiffusion.

Tendances favorisant l’innovation des radiodiffuseurs

Nous pensons que l’une des principales limitations aux innovations des radiodiffuseurs vient du contrôle limité qu’ont les radiodiffuseurs sur la mise en œuvre de leurs normes dans les récepteurs. Le marché des récepteurs est horizontal. La mise en œuvre des normes de radiodiffusion dans les téléphones mobiles est encore compliquée par le fait que ces appareils relèvent d’un marché vertical. En effet, les ERM contrôlent étroitement les ensembles de fonctions qui sont mis en œuvre dans « leurs » appareils. Et il est naturel qu’ils favorisent les fonctions de téléphonie plutôt que celles liées à la radiodiffusion. C’est pourquoi il est peu probable de trouver les innovations de BTH provenant des radiodiffuseurs dans les téléphones mobiles. Selon la théorie de Von Hippel [2], on peut penser qu’en tant qu’« utilisateurs » des technologies de téléphonie mobile, les ERM sont en position de force pour innover et faire preuve de compétitivité.

La fabrication des appareils mobiles est onéreuse. Pour parvenir à la rentabilité, il est impératif de passer par une production de masse, ce qui crée de solides barrières à l’entrée de nouveaux acteurs sur le terrain. Heureusement, l’élan soutenu de la loi de Moore a permis de mettre en œuvre des circuits intégrés génériques, compacts et puissants, qui peuvent être produits à des coûts raisonnables et n’utilisent pas beaucoup d’énergie. Ces progrès profitent également aux téléphones intelligents.

Dans la section suivante, nous allons nous pencher sur les tendances émergentes qui pourraient offrir de nouveaux débouchés aux innovations des radiodiffuseurs dans l’univers de la BTH. Veuillez vous reporter à l’Annexe A : « atomie d’un appareil mobile », où vous trouverez une brève description des éléments et de la terminologie à laquelle nous ferons référence dans le suite de cet article.

Note : D ans cet article, l’expression « appareils mobiles » désigne les appareils électroniques génériques de poche capables d’offrir ou non, une connectivité à un réseau quelconque. Les téléphones portables (aussi appelés téléphones mobiles), quant à eux, sont une catégorie particulière d’appareils mobiles qui communiquent par l’intermédiaire des infrastructures des ERM.


Les circuits spécialisés deviennent génériques

À l’intérieur des appareils mobiles d’aujourd’hui, les éléments matériels spécialisés sont de plus en plus remplacés par leurs homologues génériques. On peut réutiliser des processeurs d’applications (PA) flexibles dans la conception de nombreux types d’appareils, ce qui permet de réduire les coûts de production pour des applications aux marchés limités.

La fonctionnalité se fait logicielle Dans les téléphones mobiles des premières générations, les applications utilisateur étaient exécutées par du logiciel de bas niveau inscrit directement dans la mémoire permanente de l’appareil. Seules les tâches de base étaient prises en charge : composeur, annuaire, paramètres de l’appareil ou sélection de la sonnerie. Il n’y avait pas de place pour les nouvelles applications. Aujourd’hui, des PA génériques et puissants, associés à de grandes mémoires, ont donné le jour à de meilleures fonctionnalités. Ils ont également considérablement augmenté l’importance du logiciel dans les appareils mobiles. De ce fait, les fonctionnalités, maintenant logicielles, sont beaucoup plus accessibles qu’avant grâce aux propriétés fondamentales du logiciel qui:

l

se duplique sans coût ;

l

se distribue instantanément et sans coût ;

l

se développe avec des outils peu onéreux ou gratuits ;

l

se modifie, s’ajuste, et se met à jour sans incidence sur la chaîne de fabrication.

Les logiciels se libèrent L’arrivée progressive du code source libre (OSS) fait peu à peu changer le secteur du logiciel. Avec les OSS, le niveau mondial de collaboration ajoute une grande valeur à la chaîne de développement des logiciels. Programmeurs et organisations adoptent désormais une approche du type « ne réinventons pas la roue » pour innover et résoudre les problèmes, et travaillent ensemble pour créer un noyau commun solide qui soutient leurs modèles commerciaux respectifs. Pour nous, le qualificatif « à code source libre » n’est pas en lui-même très important. Ce qui compte, ce sont les droits liés au code lorsqu’il est distribué. C’est là que les licences de logiciel prennent tout leur sens. On dit qu’un projet est libre, ou à code source libre (FLOSS), lorsque les conditions d’octroi de sa licence offrent une flexibilité d’utilisation tout en restant accessible à la communauté la plus vaste possible. La Free Software Foundation classe les licences de logiciels et fait la promotion de ceux qui sont réellement libres selon ses critères. La Open Source Initiative (OSI) est également un organisme de référence reconnu qui examine et approuve les licences qui respectent la définition de l’Open Source [3]. On observe une tendance évidente en ce moment. L’industrie a adopté de nombreuses solutions logicielles à code source libre. Plusieurs produits OSS sont largement déployés : GNU/Linux, Apache, OpenOffice, Firefox, Asterisk, Eclipse et MySQL. Les entreprises qui utilisent ces outils y trouvent divers avantages en termes de flexibilité, d’indépendance, de capacité à arranger, à améliorer et à adapter le logiciel dont elles ont besoin. Les OSS sont la clé du succès pour toutes les parties concernées.

17


La popularité des OSS a même atteint l’un des bastions du secteur technologique. En effet, nous pouvons désormais acheter des produits d’électronique grand public qui « tournent » sur des OSS. En voici quelques exemples importants : l

l

l

l

18

Le routeur Wi-Fi sans fil WRT54G [4] de Linksys est un produit pour lequel le micrologiciel GNU/Linux a été lancé en code ouvert. Depuis, les utilisateurs en ont amélioré les fonctionnalités pour en faire un routeur d’entreprise. Neuros [5], un fabricant de décodeurs Internet, va prochainement sortir un nouveau produit baptisé OSD2. Neuros s’appuie en partie sur ses utilisateurs et sur des développeurs externes pour créer et intégrer de nouvelles applications dans leurs plates-formes, lesquelles utilisent des OSS. L e DASH Express [6] est un nouveau type de système de navigation GPS embarqué, doté d’un canal de données bidirectionnel. Il peut recevoir des informations routières en temps réel et offrir la recherche sur Internet de points d’intérêt. Le DASH est commercialisé depuis un an et semble bien réussir aux Etats-Unis. Il est intéressant de noter que le DASH est basé sur la première version du matériel Openmoko de FIC Inc. C’est un bon exemple d’appareil à intégration verticale, et une excellente étude de cas pour montrer comment les OSS peuvent être utilisés, avec un bon système de licence, dans des modèles commerciaux fermés. Certains développeurs ont également activé des frameworks (aussi appelés cadriciels) OSS dans des appareils électroniques grand public fermés. Le projet Rockbox [7] crée ainsi des micrologiciels de remplacement libres pour plusieurs marques de baladeurs numériques comme Apple, Archos et iRiver. Les codecs audio sont parmi les nombreuses fonctions ajoutées : FLAC, WavPack, AC3 (A/52), AAC/MP4 et WMA, qui n’étaient pas disponibles dans les iPod commercialisés par Apple.

Les appareils mobiles se tournent vers le code source libre Aujourd’hui, de nombreux intervenants de l’industrie favorisent les OSS sur les appareils mobiles. Ils souhaitent ainsi participer à la chaîne des valeurs de la mobilité grâce aux tendances actuelles que nous venons de décrire. Nous allons étudier maintenant certains projets clés susceptibles d’avoir une incidence sur la BTH.

Openmoko Openmoko [8] est un projet OSS mené par First International Computer, Inc. (FIC Inc.), un important fabricant de cartes mères pour ordinateurs personnels. Très tôt, la société a estimé que pour rendre ses nouveaux produits de téléphones intelligents concurrentiels, sa meilleure chance résidait dans l’ouverture d’une suite logicielle complète permettant aux utilisateurs d’innover et d’exploiter ces innovations. En juillet 2007, FIC Inc. lançait son premier prototype « pour développeurs », le Neo 1973, équipé de la suite logicielle Openmoko. Pour beaucoup de développeurs, le Neo représente la première plate-forme de téléphonie mobile réellement ouverte. Il comprend plusieurs options de connectivité intéressantes : GSM, GPRS, GPS et Bluetooth. Curieusement, à l’origine, le Neo 1973 était doté d’une suite logicielle primitive qui ne permettait même pas de passer des appels téléphoniques. Il a fallu attendre encore quelques mois avant que des mises à jour de la suite logicielle permettent d’installer la « fonction téléphone ». La version suivante, le Neo FreeRunner (GTA02), est arrivée en juin 2008 dotée d’une convivialité et d’un matériel améliorés, ainsi que de la connectivité Wi-Fi. Openmoko a été conçu pour être compatible avec divers modèles commerciaux. Openmoko Inc., son fabricant, commercialise ses appareils en vue d’en tirer profit. Les développeurs indépendants peuvent vendre des applications privées grâce à la licence LGPL qui couvre l’ensemble de logiciels

Openmoko. Avec le DASH express, FIC Inc. a également montré qu’il est possible d’utiliser Openmoko pour construire des appareils à intégration verticale. Avec ce framework, les applications fermées et ouvertes sont à égalité pour s’affronter. Dans cet environnement, les utilisateurs sont « à un clic près » d’une application payante ou d’une gratuite. C’est l’utilisateur final qui détermine celle qui lui convient le mieux. Il est également intéressant de noter que peu après la sortie du FreeRunner, une autre communauté de développeurs a réussi à lui adapter la suite OSS Qtopia, mise au point quelques années auparavant par Trolltech, une entreprise rachetée par Nokia en 2008. Koolu, une société canadienne, vient d’annoncer qu’elle intégrera Android (une autre suite OSS, que nous étudierons dans la section suivante) au FreeRunner d’ici la fin novembre 2008. Tous ces développements montrent bien l’organicité et l’efficacité potentielles d’un écosystème OSS. Quelques mois à peine après son lancement, le FreeRunner peut déjà héberger plusieurs nouvelles plates-formes logicielles.

Android Android [9] devait à l’origine être l’élément de base des nouveaux appareils mobiles. Il s’agit d’une suite logicielle comprenant un système d’exploitation, une couche d’intergiciels et quelques applications clés. Elle est développée par la Open Handset Alliance (OHA), un consortium de 34 membres, dont Google, H T C , T- M o b i l e e t d ’ a u t r e s a c t e u r s importants dans ce secteur. La trousse de développement logiciel (SDK) d’Android, basée sur Java, est sortie en novembre 2007 pour permettre le développement d’applications bien avant la production même d’un appareil Android. Depuis, un concours de développement d’applications, parrainé par Google, a été lancé en vue de stimuler l’apparition de nouvelles applications Android. En tout, 5 millions USD ont été attribués aux 50 soumissions présentant les applications les plus novatrices [10]. Le premier téléphone portable Android (T-Mobile G1) a été introduit en octobre 2008 sur certains marchés.



Au début, le degré d’ouverture d’Android était limité, même si l’on pouvait se procurer sa SDK gratuitement. La OHA vient de décider de publier le code source d’Android [11], qui englobera la plupart des éléments de sa plate-forme. Avec l’ouverture du système d’exploitation et de la machine virtuelle Android, de nouveaux projets passionnants sont désormais possibles. On pourrait même assister à la création de nouveaux éléments matériels. Les précisions, encore inconnues, sur les licences et la gouvernance du projet révéleront le degré d’ouverture réel d’Android. Mais dans sa configuration actuelle, Android représente une option séduisante pour la conception d’appareils mobiles libres.

La Ubuntu Mobile Edition est un autre exemple de suite logicielle basée sur GNU/ Linux et capable de satisfaire les exigences des nouveaux appareils mobiles. Ce projet a été lancé par Canonical Inc. pour soutenir le développement d’une suite OSS pour les appareils Internet mobiles. Une autre grande avancée dans le domaine des OSS sur téléphones portables pourrait venir de Nokia, qui a annoncé la création de la Symbian Foundation et le lancement de son système d’exploitation Symbian sous forme de logiciel à code source libre [13]. Ce système d’exploitation a été conçu pour les appareils mobiles et vient avec des bibliothèques, des frameworks d’interface utilisateur et des mises en œuvre de référence. Avec une part de marché de plus de 50 %, Symbian reste la plate-forme la plus déployée sur les téléphones intelligents.

Autres plates-formes mobiles ouvertes On peut aussi créer de nouveaux appareils mobiles avec d’autres plates-formes ouvertes qui ne comprennent pas d’interfaces de réseaux de téléphonie mobile. Ces appareils pourraient aussi convenir à la réception de la radiodiffusion.

Le projet Openmokast Aucun des frameworks et appareils libres étudiés ne prenait en charge le matériel de radiodiffusion numérique. La BTH étant un domaine de recherche principal pour notre groupe au CRC, la possibilité d’intégrer la fonctionnalité de radiodiffusion dans un tel appareil libre nous fascinait. Lorsque, en février 2007, FIC Inc. a annoncé le lancement de son prototype de téléphone portable libre basé sur le framework Openmoko, nous avons décidé d’entamer le projet Openmokast

Les tablettes Internet Nokia, basées sur la plate-forme Maemo [12], en sont un exemple. Cette plate-forme offre de nombreuses fonctions et un grand potentiel pour bien des scénarii d’utilisation. Maemo est une plate-forme logicielle basée sur des projets OSS tels que Debian GNU/Linux et GNOME.

OPENMOKAST

S u b-C h (s) F IC

R x C o m m a n d (D C S R )

R x C om m and

Rx Com m and R x N o tifica tio n

T elnet

E n se m b le In fo U se r

O u tp u t M anager

La CRC-DABRMS est une plate-forme logicielle stable déjà mise au point par le CRC pour le contrôle de récepteurs de DAB

IP

U se r C o m m a n d In te rp re te r

O u tp u t S e le ctio n

F IC D ecoder

DAB E n se m b le In fo

R a w S u b-C h a n n e l F ile W rite r

E xte rn a l D ecoder

M P 2 A u d io F ile , S tre a m D a ta R a w , D M B V id e o F ile, ...

M O T D ecoder + P a cke t D a ta D e c o d e r

F IC R e ce ive r C o n tro l

R x N o tifica tio n (D C S R )

E n s. In fo R e q u e st

S u b-C h(s)

O utput S e lection

RDI D ecoder

R x N o tification

USB

RDI

F IC

D A B S ig n a l

D A B R e ce ive r: Bosch U SB DR Box 1 M te c h U D R A 3 L

La plate-forme logicielle Openmokast

F IC

S ub-C h(s)

E T I F ile

Ce projet visait à intégrer un récepteur de DAB dans un téléphone portable pleinement fonctionnel. Nous voulions concevoir, construire et tester, avec un signal DAB en temps réel, un prototype capable de décoder les services audio DAB classiques, ainsi que certaines des applications manquantes. Nous appuyant sur notre expérience passée au laboratoire, nous avons décidé de travailler avec GNU/Linux et d’autres logiciels OSS. Nous avons ainsi appris que l’utilisation de logiciels OSS accélère l’intégration d’un prototype car elle réutilise certains composants déjà existants. Pour construire le produit final, nous devions trouver une plate-forme de réception de DAB et l’intégrer à notre prototype. Nous avons dû développer entièrement les autres principaux éléments logiciels comme l’unité de contrôle du récepteur, le démultiplexeur et le décodeur. Nous avons même dû fabriquer un module phy sique à ajouter au combiné de départ afin de pouvoir incorporer le petit récepteur USB de DAB et son antenne dans notre prototype.

R a w S u b-C h a n n e l U D P W ra p p e r

S u b-C h(s)

ETI D ecoder

(« OPEN MObile broadKASTing ») dans notre laboratoire.

R T P W ra p p e r D M B T ra n s p o rt D ecoder D A B IP T u n n e lin g D ecoder + P a cke t D a ta D e c o d e r

M O T A p p lica tio n: J o u rn a lin e, S lid e S h o w , ... IP

IP

M e d ia P la y e r

M e d ia P la y e r

IP P a c k e ts

Openmokast Output Libraries

Figure 1 – Architecture de la plate-forme logicielle Openmokast


19


(a)

(b)

(c)

Figure 2 – Captures d’écrans d’Openmokast en cours d’exécution

commerciaux pour ordinateurs. Ce premier projet nous a donné accès aux trains de bits DAB bruts sur des ordinateurs personnels classiques. La CRC-DABRMS peut décoder les informations de signalisation contenues dans le canal d’information rapide et attribuer les sous-canaux accessibles aux divers types de sorties. Elle nous a ensuite permis de faire la démonstration et l’essai de nouvelles applications destinées à la DAB, mais pas encore normalisées. Ce système avait été mis en œuvre pour les plates-formes Windows et GNU/Linux. La version GNU/Linux de la CRC-DABRMS a été adaptée à la plate-forme Openmoko et rebaptisée Openmokast. Pour l’adapter, il a fallu recompiler l’application pour le nouveau PA cible et adapter le code tout en s’assurant que toutes les bibliothèques requises seraient présentes sur la nouvelle plate-forme au moment de l’exécution. L’architecture de l’intergiciel Openmokast est illustrée sur la Fig. 1 (page précédente). La première interface d’Openmokast était la ligne de commande. Nous avons par la suite développé une interface utilisateur graphique à l’aide des bibliothèques GTK d’Openmoko. Des captures d’écrans d’Openmokast en cours d’exécution sont reproduites sur la Fig. 2. Au démarrage, Openmokast affiche un menu permettant de sélectionner l’appareil d’entrée (Fig. 2a). Le système accepte également en

20

entrée un fichier multiplex DAB stocké sur la mémoire locale. Cette fonction permet de tester hors ligne et de développer de nouvelles applications sans nécessiter de récepteur physique et de signal en temps réel. Différentes applications ont été programmées ou simplement intégrées directement à partir de projets OSS existants. L’application radio DAB standard a été réalisée en encapsulant le son MP2 dans un format conteneur HTTP pour l’acheminer vers le lecteur média Mplayer. Un paquetage Mplayer était déjà disponible pour Openmoko. L’application DAB+ a été construite de la même manière en prenant soin toutefois d’extraire le protocole de transport avant d’envoyer le flux AAC+ au Mplayer. Deux applications de données ont été intégrées en réutilisant le code source du projet OSS Dream [14]. Dream est un récepteur de radio logicielle pour DRM qui comprend un décodeur de protocole de transport MOT et deux des applications manquantes : Journaline et Slideshow (Fig. 2c). Nous avons dû mettre au point le décodeur de mode paquets à l’interne. En réutilisant le code d’autres projets OSS, nous avons pu développer ces applications rapidement et efficacement. Cette expérience nous a confortés dans l’idée que le concept OSS est très avantageux pour les développeurs.

Le récepteur DAB Un récepteur DAB était un élément fondamental de la conception du prototype. D’après notre première analyse, un récepteur USB semblait pouvoir convenir. Tout d’abord, le FreeRunner disposait d’un port USB. Nous savions aussi que son PA n’était pas assez puissant pour effectuer la démodulation du signal DAB en temps réel. Nous avons donc cherché un composant USB permettant d’effectuer cette tâche efficacement sur silicone. Nous avons d’abord testé le USB Terratec DrBox, dont les pilotes (DABUSB) étaient déjà inclus dans le noyau d’Openmoko. Cela aurait dû faciliter l’intégration, mais malheureusement, nous n’avons pas pu charger correctement le micrologiciel pour l’appareil. Nous avons connu des expériences semblables avec d’autres récepteurs USB qui n’ont pas fonctionné lors de nos premiers essais. Pour trouver le bon récepteur, nous pouvions aussi nous procurer les trousses de développement offertes par les fabricants de puces. Nous avons contacté de nombreuses sociétés, mais aucune n’était en mesure de nous fournir les éléments dont nous avions besoin. En général, leurs produits ne correspondaient pas aux exigences d’un projet de recherchedéveloppement comme le nôtre et elles ne



jugeaient pas intéressant de soutenir notre projet, qui n’allait probablement pas générer des ventes importantes. De plus, les trousses de développement disponibles sont onéreuses et les pilotes USB fournis sont généralement conçus pour Windows et non GNU/Linux, de plus l’utilisation de ces trousses nécessite la signature d’ententes de non-divulgation. Ce n’était pas la voie de développement que nous voulions emprunter, et nous sommes restés bloqués un moment. En poursuivant nos recherches, nous avons trouvé un produit « prêt à l’emploi » capable de répondre à nos exigences. La clé USB UDR-A3L de MTECH présentait toutes les caractéristiques dont nous avions besoin. Nous avons choisi la bibliothèque libusb pour communiquer avec elle. libusb est une suite de routines en mode utilisateur Unix qui contrôle le transfert de données entre les appareils USB et les systèmes hôtes. Nous avons pu établir des communications de base entre la clé MTECH et le port USB du FreeRunner. Nous avons ajouté cette nouvelle source dans le menu d’entrée d’Openmokast (matériel 1 sur la Fig. 2a).

Figure 3 Extension ABS pour le FreeRunner

Figure 4 Comparaison d’épaisseur entre l’appareil initial et le prototype d’Openmokast

Construction du prototype L’ouverture préconisée par le projet Openmoko a dépassé nos premières attentes. Même les plans de CAO du boîtier mécanique du FreeRunner étaient publics et pouvaient être téléchargés gratuitement. En les prenant comme référence, nous avons modifié la conception mécanique initiale et produit un module plastique amovible offrant l’espace supplémentaire nécessaire à l’intérieur de l’appareil pour y intégrer la clé USB dénudée, comme on le voit sur la Fig. 3. Pour fabriquer le module physique, nous avons fait appel à une entreprise d’impression en 3D. Nous lui avons envoyé le fichier 3D modifié formaté en Pro/Engineer et avons reçu en 48 heures la pièce finie en acrylonitrile-butadiène-styrène (ABS), pour 90 USD. Nous avons été heureux de constater que comme avec les logiciels OSS, les composants matériels mécaniques d’un prototype bénéficiaient eux aussi de la « démocratisation » des moyens de production.


Figure 5 L’intérieur du prototype d’Openmokast

Le CRC publiera les schémas de ce module sous une licence non restrictive Creative Commons. La Fig. 4 montre l’épaisseur du prototype Openmokast final. Le récepteur MTECH a été connecté directement aux points de vérification USB internes sur la carte mère du Neo. Dans

Figure 6 Le prototype final d’Openmokast

cette configuration, il pouvait s’alimenter sur la batterie principale de l’appareil. Cette configuration présentait aussi l’avantage de libérer le connecteur USB externe sur le combiné, qui reste la manière la plus pratique de recharger l’appareil. Une fois démontés, le FreeRunner et le module offraient suffisamment d’espace interne disponible pour que nous puissions y installer l’antenne en bande L.

21


La Fig. 5 illustre l’intérieur du prototype, la Fig. 6 le produit final. Notez l’habillage coloré qui porte la marque de notre organisme et le logo d’Openmokast.

Quelques résultats Jusqu’à présent, nous sommes satisfaits des résultats globaux des tests du prototype d’Openmokast. Cet appareil, mis au point par une petite équipe en peu de temps, a bien fonctionné depuis sa création. Son format physique a été bien apprécié lors des tests. Nous avons pu faire la démonstration de certaines des applications manquantes DAB qui ne sont généralement pas disponibles dans les récepteurs commerciaux. Le prototype d’Openmokast a été présenté à l’IBC 2008 et salué en tant que premier récepteur mobile de radiodiffusion basé sur une plate-forme ouverte. Le rendement global du récepteur est bon. Le MTECH donne une bonne réception du signal dans les gammes de fréquences des bandes L et III, dans diverses conditions. L’appareil a pu recevoir des signaux provenant soit de l’émetteur mmbTools LiveCD du CRC [15], soit d’équipements commerciaux standards. La charge totale de calcul de l’unité centrale mesurée pour le décodage de l’audio DAB et DAB+ en temps réel dans le FreeRunner était faible. Nous avons utilisé l’utilitaire top de GNU/Linux pour estimer les cycles de traitement pour deux scénarii de décodage audio (Tableau 1). Le Tableau 2 montre

Scenario 1 Scenario 2

l’autonomie en énergie estimée à partir des mesures prises pendant trois scénarii d’utilisation.

doivent être payées au titulaire des droits pour chaque mise en œuvre de technologie « vendue ».

Le logiciel Openmokast a été installé et testé sur des PC GNU/Linux classiques. Le code a pu s’exécuter sur un émulateur du Neo1973 dont disposait le projet Openmoko. Dans cette configuration, nous avons pu tester la GUI d’Openmoko et celle d’Openmokast. Nous n’avons pas pu répéter de test similaire pour la configuration avec FreeRunner car il n’existe pas encore d’émulateur pour cet appareil.

Les normes comprenant des brevets privés apparaissent ainsi comme des obstacles aux mises en œuvre OSS pour deux raisons. Les projets OSS sont publiés gratuitement et ne génèrent pas de revenus. Il est également impossible de contrôler leur distribution. Il serait donc très difficile de collecter des royalties. Certains pays ont reconnu la nécessité des normes « libres » et favorisent l’adoption de nouvelles normes disponibles gratuitement et pouvant être mises en œuvre sans coût. La question du code source libre et de la normalisation a fait l’objet d’un rapport commandé par l’ETSI en 2005 Rannou & Soufron:[16].

Nous avons aussi pu tester le logiciel d’Openmokast directement sur deux suites GNU/Linux différentes, sans avoir besoin d’émulateur d’Openmoko. Ces expériences nous permettent de conclure que nous pouvons déployer Openmokast sur d’autres plates-formes et utiliser des appareils DAB dans ces environnements.

Ouvrir Openmokast Pendant ce projet, nous avons dû nous pencher sur le problème de la propriété intellectuelle relative aux mises en œuvre de logiciels OSS. En fait, il est important de comprendre que la mise en œuvre de la plupart des normes internationales ouvertes de radiodiffusion en vigueur implique l’utilisation de brevets privés. Une mise en œuvre comme Openmokast doit donc comprendre des algorithmes ou techniques privés pour pleinement appliquer une telle norme. Le plus souvent, les royalties

Type de codec

Débit (kbit/s)

Mplayer

Musicam HE-AACv2

192 64

12,70% 14,30%

OPEN SOURCE HANDHELDS

Pour mettre en œuvre les normes sous brevet privé dans les logiciels OSS, on pourrait envisager de concevoir des frameworks avec des systèmes de licence permettant d’intégrer à la fois des modules sous brevet privé et d’autres libres. Selon cette approche, il faut retirer de la distribution générale les éléments sous brevet privé. Un framework morcelé pourra ainsi être distribué à grande échelle sans les modules sous brevet privé. Il faudra veiller à distribuer séparément les éléments sous brevet privé en tenant compte des dispositions financières. Nous prévoyons d’appliquer cette méthode pour le projet Openmokast. Le framework pourra être distribué librement sans les modules nécessitant une licence spéciale (décodage MP2 et HE-AACv2, etc.).

Openmokast 1,00% 0,60%

DAB+

Total

0,60%

13,70% 15,50%

Table 1 – Utilisation de l’unité centrale pour deux scénarii de décodage audio (%)

Scenario 1 Scenario 2 Scenario 3

Source

Consommation mesurée

Autonomie estimée

Récepteur dans la bande III Fichier ETI Aucune

650-670 mA 220-230 mA 190 mA

1h49 5h20 6h19

Table 2 – Consommation et autonomie d’Openmokast avec une batterie de 1 200 mAh

22



Conclusions Dans cet article, nous avons déterminé les tendances qui façonnent l’environnement actuel pouvant avoir une incidence sur le développement de nouveaux services de BTH. Depuis longtemps déjà, la loi de Moore a inspiré les avancées du matériel et de la fonctionnalité assurées auparavant par les circuits spécialisés, mais aujourd’hui par des puces génériques. Le passage au logiciel dans la mise en œuvre d’appareils mobiles puissants est déjà une tendance lourde. Grâce au logiciel et à sa flexibilité, les développeurs ont pu créer, en quelques mois, des milliers de nouvelles applications novatrices pour un Android ou un iPhone. Nous pensons qu’une force transformationnelle se cache peut-être derrière les possibilités offertes par la loi de Moore et le logiciel flexible. La principale tendance identifiée pendant notre étude est que le logiciel à code source libre, une fois intégré dans les appareils mobiles, présente un énorme potentiel pour l’innovation. Il s’agit d’une révolution en puissance qui réalisera son potentiel réel lorsque nous aurons trouvé un mélange adéquat de collaboration et d’ouverture. S’ils choisissent de suivre cette tendance, les radiodiffuseurs pourraient découvrir de nouvelles occasions de faire connaître leurs technologies, ce qui projeterait leurs applications au premier plan et stimulerait le déploiement de nouveaux réseaux de BTH. Nous vous avons présenté dans cet article plusieurs projets de récepteurs ouverts, des appareils électroniques grand public similaires et le prototype d’Openmokast mis au point au CRC. Après cette étude, nous pensons que les radiodiffuseurs ont maintenant la possibilité de parrainer le développement de récepteurs de radiodiffusion mobile. S’ils le font, il faudrait encourager les fabricants de puces à participer à ce processus. Il serait en fait facile d’adapter le framework d’Openmokast pour prendre en charge d’autres technologies comme DVB-T ou ATSC-M/H en exploitant la redondance des éléments actuels. Dans un appareil ouvert doté d’interfaces de BTH et de télécommunications mobiles, des synergies devraient se dégager. Un simple logiciel dans l’appareil mobile suffit à relier ces deux réseaux. Avec Openmokast, nous


pouvons au moins affirmer que nous avons atteint la convergence. Pour soutenir notre vision de la convergence et les nouvelles occasions qui en découlent, le CRC prévoit de rendre publics, sous forme de logiciels à code source libre, plusieurs outils mis au point pour le projet Openmokast (http://www.openmokast.org).

Remerciements Les auteurs tiennent à remercier leur collègue Martin Quenneville pour son travail sur le prototype d’Openmokast. Ils remercient également en particulier Karl Boutin pour sa revue exhaustive du texte et André Carr, René Voyer, Bernard Caron, Silvia Barkany et Bruce Livesey pour leurs commentaires et leur soutien.

Références [1] C. Weck et E. Wilson: « Nomadisme » et radiodiffusion Revue technique de l’UER, n° 305, janvier 2006 [2] E . v o n H i p p e l : D e m o c r a t i z i n g Innovation MIT Press, 2006 [3] http:/www.opensource.org/docs/osd [4] h t t p : / / f r. w i k i p e d i a . o r g / w i k i / WRT54G [5] http://wiki.neurostechnology.com/ index.php/OSD2.0_Development [6] http://www.dash.net/ [7] http://www.rockbox.org/ [8] http://www.openmoko.com — http://www.openmoko.org [9] http://code.google.com/android/ [10] http://code.google.com/android/ adc_gallery/ [11] http://source.android.com/ [12] http://maemo.org/ [13] http://www.symbianfoundation. org/ [14] http://drm.sourceforge.net/ [15] P. Charest, F. Lefebvre: Software DAB Transmitter on Live CD Publié dans les débats de la conférence de 2008 WOC de l’IASTED, Québec, QC, mai 2007 [16] Rannou & Soufron: Open Source Impacts on ICT Standardization Rapport – Analyse – VA6, ETSI

23


Annexe A : Anatomie d’un appareil mobile La Fig. 7 décrit les éléments matériels et logiciels des appareils mobiles d’aujourd’hui. Les composants matériels (HBB) s’articulent autour d’un processeur d’application (PA). Du fait de la portabilité des appareils mobiles, des caractéristiques spéciales sont requises : connectivité sans fil, GPS et accéléromètres par exemple. Même si les PA peuvent exécuter la plupart des tâches de traitement, certaines doivent être

confiées à des processeurs spécialisés comme des processeurs de signaux numériques (PSN). Le PA ne dispose en fait pas de la puissance de traitement nécessaire. De plus, même s’il pouvait effectuer les calculs, il aurait besoin de beaucoup trop d’énergie. On le remplace donc par des PSN, qui remplissent bien ces fonctions et se révèlent moins énergivores. Les composants matériels (HBB) sans fil du récepteur illustré sur la Fig. 7 constituent un ensemble de ces PSN. Par exemple, l’étage d’entrée du récepteur de radiodiffusion filtre le signal avant de le numériser et de l’abaisser en fréquence. Le signal sort alors à une fréquence intermédiaire ou directement

en bande de base. Un PSN effectue à ce point la démodulation afin de produire un train de bits que le PA peut traiter. Le traitement des médias nécessite habituellement un certain degré de puissance et d’efficacité et est aussi confié à des PSN. Les systèmes les plus courants comprennent des processeurs de médias spécialisés pour décoder les flux médias comme la vidéo H.264 et l’audio AAC. Le composant matériel d’accès conditionnel est un autre élément à prendre en compte dans la conception d’un appareil mobile. Cette fonction dépend généralement du

François Lefebvre a commencé à travailler pour le Département des technologies de radiodiffusion du Centre de recherches sur les communications (Canada) en 1999. Dans ce cadre, il dirige notamment l’équipe chargée de la radiodiffusion mobile multimédia. Depuis, il a participé à de nombreux projets nationaux et internationaux de normalisation et de recherche et développement. Ses travaux les plus récents ont porté notamment sur la création et la mise au point d’éléments constitutifs de logiciels ouverts pour la prochaine génération de réseaux, d’appareils et d’applications pour la radiodiffusion mobile. M. Lefebvre a obtenu son diplôme en ingénierie électrique auprès de l’Université Laval où il a également décroché un doctorat en 1989. Il a ensuite déménagé en Europe où il a travaillé pendant 10 ans, en tant qu’ingénieur, pour plusieurs laboratoires de recherche et développement, puis en tant qu’indépendant sur plusieurs projets multimédias et Internet en Allemagne. Jean-Michel Bouffard a obtenu sa licence en informatique en 2003, auprès de la Sherbrooke University, au Canada. Il a ensuite rejoint le Département des technologies de radiodiffusion du Centre de recherches sur les communications d’Ottawa, où il a travaillé sur des projets portant sur les systèmes de radiodiffusion mobile multimédia. Les connaissances de M. Bouffard dans le domaine des communications multimédias et son intérêt pour la convergence l’ont amené à participer à des études sur les applications des concepts participatifs du web à la radiodiffusion et à la mobilité. Toujours dans la même optique, son poste actuel l’amène à s’occuper de la mise en service et de la promotion de la radiodiffusion sur des appareils mobiles ouverts. En outre, il travaille à son doctorat en ingénierie et systèmes informatiques à l’Université Carleton.

Pascal Charest a obtenu son diplôme en Informatique en décembre 2000, auprès de l’Université Laval, à Québec, au Canada. Il a ensuite rejoint le Département des technologies de radiodiffusion du Centre de recherches sur les communications à Ottawa, en tant qu’ingénieur de recherche. Il a participé à plusieurs projets de recherche dans le domaine de la radiodiffusion mobile multimédia. Ses travaux plus récents ont porté notamment sur les éléments constitutifs des systèmes et les logiciels en source ouverte, notamment le codage, le décodage, la modulation, le contrôle d’appareils et l’intégration des systèmes. En outre, il fait partie du Club Linux Gatineau, dont il a été Vice-président et Président.

24



Figure 7 – Composants matériel et logiciel typiques d’un portable actuel


25


matériel pour gérer l’accès aux services payants. Heureusement, comme elle ne représente pas une exigence pour les services en clair, la conception des appareils mobiles pour la radiodiffusion s’en trouve simplifiée. L’évolution rapide des PA nous amène à penser que dans un avenir proche, ce sont des radios logicielles (SDR) qui effectueront la démodulation des signaux radiodiffusés et autres en temps réel, avec des étages

d’entrée large bande polyvalents et des convertisseurs analogiques/numériques installés à même le PA. Les trois principaux niveaux de logiciel sont également présentés sur la Fig. 7 : le système d’exploitation, l’intergiciel et la couche application. Il n’y a pas de séparation nette entre les couches et certains éléments logiciels (SBB) pourraient en fait couvrir deux ou trois couches. On appelle souvent

« suite logicielle » ou « pile logicielle » une mise en œuvre complète, comprenant tous les SBB nécessaires pour faire fonctionner un appareil. Dans la pile logicielle décrite plus haut, les éléments de la couche inférieure offrent leurs interfaces de programmation (API) à ceux de la couche supérieure. Les pilotes de l’appareil présentent les API des éléments matériels (HBB) aux composants logiciels supérieurs.

Première publication : 2008-Q4

26


Compression vidéo

SVC :

une version hautement scalable de l’H.264/AVC

Adi Kouadio Département technique de l’UER Maryline Clare et Ludovic Noblet Orange Labs, Recherche et développement – France Telecom Vincent Bottreau Thomson – Département recherche

Le SVC (Scalable Video Coding – codage vidéo scalable) est un récent amendement de la norme ISO/UIT H.264/AVC (Advanced Video Coding – codage vidéo avancé). Il met à disposition des fonctionnalités optionnelles mais performantes, qui viennent compléter la grande efficacité de codage de la norme H.264/AVC. Le SVC représente une solution intéressante, tant du point de vue financier que technique, pour distribuer plusieurs formats d’un même contenu à de multiples utilisateurs. Il peut également être utilisé pour offrir une meilleure expérience aux utilisateurs (portabilité améliorée du contenu, adaptation de la qualité du contenu aux performances de l’appareil utilisé, rapidité du passage d’une chaîne à l’autre lors du zapping, fonctions d’avance/retour en arrière fluides et rapides, retransmission efficace des erreurs, etc.). Cet article décrit le potentiel du SVC pour ce qui est des applications et des performances. Les paragraphes qui suivent donnent une vue d’ensemble des fonctionnalités du SVC et quelques exemples d’utilisations pratiques de cette technologie. Plusieurs évaluations des performances, basées sur les résultats de plusieurs tests figurent également ci-dessous.

1. Introduction

l Services

de “catch-up” TV de vidéo à la demande l TV mobile l Web 2.0 (notamment le contenu généré par les utilisateurs), les plateformes médias, etc. l Services

L’un des objectifs principaux des fournisseurs de services vidéo est de mettre à disposition du contenu sur toutes les plateformes. Outre la radiodiffusion TV traditionnelle, les applications vidéo destinées au grand public utilisent les technologies suivantes : l IPTV (sur des réseaux privés ou l’Internet

ouvert) ;


Toutes ces nouvelles applications vidéo entrent progressivement en service, grâce à l’évolution des technologies de stockage, de transmission et de compression.

D’autres facteurs favorisant cette diversité de services sont la forte pénétration des appareils destinés aux utilisateurs finaux (écrans plats HDTV, lecteurs multimédias portables (PMP), appareils mobiles 3G, etc.) et la disponibilité d’accès Internet à large bande qui permettent une connectivité à haut débit vers les foyers (xDSL, FTTH), dans les foyers, entre appareils (Ethernet, Wi-Fi, PLC) et hors des foyers (3G, 4G, WiMax).

27

Compression vidéo

Toutefois, mettre à disposition du contenu sur toutes les plateformes dans un tel environnement en maintenant un rapport coût/prestations favorable est toujours difficile pour les fournisseurs de services vidéo. Pour proposer de tels services, il faut que les différents éléments permettant d’optimiser le contenu pour chaque plateforme soient intégrés dans l’architecture du service. Dans ce contexte, il est en effet nécessaire de réaliser un transcodage entre : l plusieurs

formats d’image (QCIF, CIF, QVGA, VGA, SD, HD); l plusieurs débits (variables ou constants, selon le réseau d’accès) ; l plusieurs fréquences (50 Hz, 25 Hz, 12,5 Hz) ; l différentes plateformes de distribution (avec différents schémas de codage). Adapter le contenu à la plateforme (transcodage) à n’importe quel endroit de la chaîne génère des coûts supplémentaires, que ce soit pour le fournisseur de services, l’utilisateur ou l’opérateur réseau. Une telle adaptation a également une influence sur l’expérience de l’utilisateur, car elle représente un obstacle supplémentaire à la portabilité et ne préserve pas nécessairement la gestion numérique des droits (DRM). D’autres solutions, comme la diffusion simultanée du contenu, entraîneraient une augmentation des exigences au niveau du débit.

lorsque l’on prend en considération le SVC, qui est une extension scalable de la norme H264/AVC [2]. Si l’on tient compte du nombre croissant de combinaisons format/débit, l’optimisation de l’adaptation du contenu devient, à l’heure actuelle, une condition clé pour arriver à mettre le contenu à disposition sur toutes les plateformes. Au vu des considérations qui précèdent, la scalabilité et la flexibilité sont des points essentiels pour les services vidéo (anciens et nouveaux). Une telle scalabilité est nécessaire à tous les niveaux : architecture, infrastructure et contenu. Le SVC apporte les outils permettant de mettre en œuvre efficacement la scalabilité et la portabilité du contenu. Il s’agit de la solution de codage vidéo scalable la plus récente. Elle a été normalisée récemment sous la forme d’un amendement de la norme H.264/AVC [1], mise au point par le JVT (Joint

Video Team)1, très connue et largement utilisée. D’autres technologies de scalabilité vidéo ont été proposées dans le passé. Parfois, elles ont même été normalisées sous la forme de modes optionnels pour le MPEG-2 [3] et le MPEG-4 - Part 2 [4], mais elles étaient moins efficaces et plus compliquées. Il y a quelque temps, les services vidéo étaient proposés uniquement en définition normale. Par conséquent, ces technologies de scalabilité n’ont jamais été utilisées. Dans les paragraphes suivants, nous commencerons par donner un e v ue d’ensemble des aspects techniques des fonctionnalités du SVC. La seconde partie du présent document traitera des différentes possibilités d’utilisation de cette norme alors que la troisième partie fera un résumé des résultats de l’évaluation préliminaire des performances. La quatrième et dernière partie décrira les travaux en cours et les actions entreprises par l’UER et les autres organes de normalisation (MPEG, JVT) afin d’élargir la norme et de définir plus précisément les performances du SVC.

Dans le passé, on utilisait de nombreux codecs vidéo. Le choix dépendait du type d’appareil auquel le service était destiné. Heureusement, aujourd’hui la tendance générale est à l’utilisation du H264/AVC [1]. Ce codec a été largement utilisé dans les décodeurs externes. De plus, il va bientôt être adopté à grande échelle pour les appareils et les lecteurs multimédias portables. Il a même commencé à être utilisé dans les lecteurs médias Flash 9 (Adobe) et QuickTime (Apple). Avec la généralisation de l’utilisation de la norme H264/AVC, le transcodage se limitera bientôt à l’adaptation du format et du débit. Il y aura donc moins besoin d’un large choix de codecs de sortie. Il s’agit d’un point important

1)

Figure 1 Vue générale de la structure en couche SVC (EL = couche d’amélioration)

Le JVT (Joint Video Team) est un groupe de travail commun du groupe VCEG de l’UIT et du groupe MPEG ISO/CEI. Les travaux du JVT sont à l’origine de la norme H.264/AVC.

28


Compression vidéo

2. Vue d’ensemble du SVC

S o u rc e vid eo

Le codage scalable consiste à compresser une vidéo numérique en un flux binaire unique, de manière à ce que d’autres flux significatifs et cohérents puissent être générés en éliminant des parties du flux compressé de départ. Ces “sous-flux” peuvent être interprétés directement à différents débits, résolutions ou échelles temporelles. Le SVC partage le fichier compressé en une couche de base (BL – base layer), qui est codée avec la norme H264/AVC, et une couche d’amélioration (EL – enhancement layer) apportant des informations supplémentaires sur la qualité, la résolution ou la fréquence d’image (voir Figure 1). Cela implique que les flux de la couche de base peuvent être décodés par des appareils H.264/AVC (décodeurs externes, lecteurs multimédias personnels), ce qui assure une compatibilité ascendante pour les utilisateurs qui ne disposent pas de la mise à jour SVC. De plus amples informations sur la norme H264/AVC peuvent être trouvées dans [1]. Le SVC met à disposition trois types de scalabilité (spatiale, qualitative et temporelle), qui peuvent être combinés à chaque niveau (voir le point 2.1). Les couches d’amélioration peuvent être totalement hiérarchisées, mais cela n’est pas obligatoire : l

une couche peut être générée (“prédite”) à partir d’une autre couche et servir de “prédiction” pour une autre ; l une couche peut être une prédiction de deux couches qui ne sont pas hiérarchiquement interdépendantes. De tels paramètres de codage dépendent de l’application prévue. Un flux binaire vidéo compressé se compose d’unités NAL (Network Abstraction Layer – couche d’abstraction réseau) et chaque couche d’amélioration correspond à un ensemble d’unités NAL identifiées. Une unité NAL est un paquet de données avec une en-tête de quelques bytes (contenant des informations sur la charge utile) et une charge utile correspondant aux données compressées. Un ensemble d’unités NAL successives, partageant les mêmes propriétés, constitue une unité d’accès NAL.


M u lti-ta rg et co m p res s e d vid e o

SVC en co d er

A V C -com patible base la ye r

2 S V C enhancem ent laye rs A V C -com patible base la yer

1 S V C enhancem ent la yer A V C -com patible base la yer

Figure 2 – Scalabilité spatiale

Selon le contexte, les couches d’amélioration peuvent être transmises par le réseau et décodées par les appareils des utilisateurs finaux. Dans le premier cas, le réseau intègre des modules d’adaptation, qui décident ce qui va être transmis et ce qui va être filtré (cela pourrait par exemple dépendre des caractéristiques de largeur de bande du réseau). Dans le second cas, le terminal extrait les couches qu’il est en mesure d’exploiter. Un tel mécanisme d’adaptation se fonde sur la sélection/l’élimination des paquets. Pour mettre en œuvre un service utilisant la technologie SVC, il faut tenir compte de deux facteurs importants : la décision et l’adaptation, qui font l’objet d’un examen plus approfondi au point 2.3.

2.1. Scalabilité 2.1.1. Scalabilité spatiale La résolution spatiale donne les dimensions horizontale et verticale en pixels de la vidéo, qui peuvent ainsi correspondre à plusieurs “formats vidéos” bien connus, tels que le QCIF (176 x 144 pixels), le CIF (352 x 288), la SD (720 x 576) et la HD (1280 x 720 à 1920 x 1080). La capacité de la norme SVC d’intégrer des formats 4:3 et 16:9 est une fonctionnalité

de scalabilité spatiale très importante, notamment pour les radiodiffusions en SD/ HD. Il convient de remarquer que, selon le format utilisé, le rapport entre les couches peut être limité à un groupe de valeurs restreint (voir le point 2.2). La scalabilité spatiale est rendue possible par des mécanismes de filtrage/d’augmentation de la fréquence d’échantillonnage et des prédictions inter-couches (prédiction des données de mouvement, prédiction intraimage et prédiction du signal résiduel). Chaque couche d’amélioration spatiale (EL) est considérée comme une représentation de dépendance. Une couche d’amélioration ayant fait l’objet d’une prédiction indique toujours la représentation de la couche de référence de laquelle elle a été prédite à l’origine. Les macroblocs des couches d’amélioration sont prédits à partir des macroblocs des couches de référence. Ils reprennent les valeurs des vecteurs de mouvement et les autres données de prédiction (texture et résiduelle) des macroblocs des couches de référence appropriées, après des processus normatifs de fusion et d’adaptation des proportions. Un exemple typique d’utilisation de la scalabilité spatiale est la transmission d’un même flux binaire à des PC et des appareils portables (voir Fig. 2), ou à des récepteurs TV en définition standard et en haute définition.

29

Compression vidéo

2.1.2. Scalabilité temporelle La scalabilité temporelle définit la différence du nombre d’images par seconde (exprimé en Hz). Les fréquences les plus répandues en Europe sont 50 Hz, 25 Hz et 12,5 Hz. Le SVC complète la gamme d’outils déjà mis à disposition par la norme H264/AVC (codage hiérarchique des tranches P ou B), en structurant le flux binaire qui devient ainsi une hiérarchie d’images, ce qui permet d’éliminer facilement le(s) niveau(x) le(s) plus bas de la description hiérarchique. Le plus souvent, la scalabilité temporelle est utilisée si le terminal cible est équipé d’un CPU dont les performances sont très limitées ou pour les transmissions vidéo sur des réseaux mobiles pour lesquels la capacité de largeur de bande peut changer très souvent. Il peut alors être intéressant d’éliminer les couches d’amélioration et d’envoyer uniquement la couche de base (qui pourrait, par exemple, contenir seulement la moitié du nombre d’images par seconde).

2.1.3. Scalabilité en qualité La scalabilité en qualité, souvent appelée également scalabilité SNR (Signal-to-Noise Ratio – rapport signal sur bruit) permet de donner différents niveaux de détail et de fidélité à la vidéo originale, tout en gardant les mêmes resolutions spatiales et temporelles. Dans un flux binaire compressé par SVC, chaque couche spatio-temporelle peut avoir différents niveaux de qualité et amener des détails et des précisions supplémentaires. C’est lors du processus de codage qu’il est décidé si des détails seront ajoutés à des parties choisies au hasard des images vidéo ou si des détails seront ajoutés à des parties spécifiques de certaines images. Les différences de qualité peuvent être moyennes (MGS, Medium Grain Scalability – scalabilité moyenne) ou grandes (CGS, Coarse Grain Scalability – scalabilité grossière). La CGS donne une différence de qualité d’environ 25 % entre deux couches, alors que la MGS présente des écarts de 10 %. La MGS utilise une signalisation (identifiants) , qui permettent de passer entre différentes couches MGS depuis n’importe quelle unité d’accès, ainsi que le concept d’image de reference (key picture

30

M ulti-target com pressed video

S ource video SVC en co d er

C lien t in m o b ility, 3G n etw o rk A V C -com patible base la yer

R ea c h ed a W iF I access p oin t

1 S V C e nha ncem ent la yer A V C -com patible base la yer

Figure 3 – Scalabilité en qualité

concept), qui donne la possibilité d’arriver à un compromis convenable entre la derive video (“drift”) et l’efficacité du codage de la couche d’amélioration, pour les structures de prédiction hiérarchiques. Avec le concept MGS, toute unité NAL de la couche d’amélioration peut être éliminée d’un flux binaire devant faire l’objet d’un processus de scalabilité en qualité, ce qui fait qu’un codage à qualité scalable basé du des paquets est mis en œuvre. L’utilisation d’écarts de qualité très petits (FGS, Fine Grain Scalability – scalabilité fine), qui permet d’avoir des flux binaires pouvant être coupés à n’importe quel endroit, a été envisagée pendant le processus de normalisation commune MPEG/ UIT, mais n’a pas été retenue. En effet, plus la scalabilité en qualité est fine, plus le processus de codage/décodage est complexe. En outre, le concept MGS permet de distribuer les coefficients de transformation des couches d’amélioration sur plusieurs tranches. Ainsi, les informations pour une image d’amélioration de la qualité qui correspond à un certain pas de quantification peuvent être distribuées entre plusieurs unités NAL correspondant à différentes couches de raffinement de la qualité.

l

la transmission HD aux clients qui ont le droit de recevoir en HD (qualité maximum) et aux utilisateurs n’ayant pas accès à la HD, mais équipés d’écrans HD (la couche d’amélioration la plus élevée est éliminée) ; l pour des améliorations supplémentaires lorsque la bande passante augmente dans le cadre des services mobiles (voir Figure 3).

2.1.4. Scalabilité du balayage Le SVC reprend les outils d’entrelaçage du système H.264/AVC : le PAFF (Picture adaptive frame/field) et le MBAFF (Macroblock adaptive frame/field). Le SVC comprend quatre types de scalabilité pour le mode de balayage, plusieurs d’entre eux étant sujets à des restrictions de codage (cela dépend du mode de codage entrelacé des couches de base et d’amélioration) : l

progressif-à-entrelacé entrelacé-à-entrelacé l entrelacé-à-progressif l progressif-à-progressif l

De plus amples informations sur la scalabilité du mode de balayage peuvent être trouvées dans [5].

La scalabilité en qualité s’utilise notamment pour :


Compression vidéo

Outils\Profils

De base scalable

Profil de couche de base AVC base CABAC et transformation 8x8 Uniquement pour certains niveaux Rapport spatial de la couche 1:1 , 1.5:1 or 2:1 Tranches I, P et B Limité tranches B Outils d’entrelaçage Non (MABFF et PAFF)

Supérieur scalable

Supérieur intra scalable

AVC supérieur Oui Non limité Toutes

AVC supérieur intra Oui Non limité Seulement tranches I

Oui

Oui

Tableau 1 – Profils SVC – différences principales

2.2. Profils et niveaux Les profils définissent l’ensemble d’outils de codage (notamment le codage arithmétique ou le codage entropique) qui peuvent être utilisés pour construire le flux. Les niveaux spécifient les contraintes pour les paramètres de codage-clés, tels que le nombre de macroblocs et le débit. L’extension SVC spécifie trois nouveaux profils scalables, qui sont très proches des profils H.264/AVC : l

Scalable Baseline Profile (profil de base scalable) : destiné à des applications peu complexes ; l Scalable High Profile (profil supérieur scalable) : destiné à des applications de radiodiffusion et de stockage de vidéo ; l Scalable High Intra Profile (profil supérieur intra-scalable) : destiné à des applications professionnelles. Les niveaux sont les mêmes que ceux du H.264/AVC. Toutefois, le nombre caractéristique de macroblocs par seconde dans un flux SVC est calculé selon le nombre de couches dans le flux (voir formule cidessous).


S ource applicatio n

R eception applicatio n D ecision & A daptation

C ustom er param eters

S ervice constraints

N etw ork statistics

co n te nt flo w

d e scrip tio n flo w Figure 4 – Adaptation du flux de données

2.3. Vue d’ensemble de l’architecture d’un service utilisant le SVC Après que le flux binaire a été généré, ses propriétés de scalabilité lui permettent de s’adapter au mieux aux conditions de transmission d’un chemin réseau menant à une destination donnée et à l’appareil de l’utilisateur final. Un ou plusieurs mécanismes d’adaptation peuvent être mis en œuvre dans le cadre du réseau de distribution du contenu, entre la source du flux vidéo et l’appareil de l’utilisateur final. Un tel processus d’adaptation doit disposer d’un mécanisme de décision, basé sur l’ensemble des conditions existantes au moment où le service est proposé (propriétés du terminal, caractéristiques de l’abonnement, largeur de bande disponible, taux d’erreur, DRM, etc.). Habituellement, dans un environnement IMS/ TISPAN, les informations sur les conditions

au début du service peuvent être traitées en relation très étroite non seulement avec les fonctions relatives au contrôle d’accès des réseaux IMS/TISPAN, mais également avec des données concernant l’utilisateur. Selon l’application, les processus de décision et d’adaptation pourraient ne pas être mis en œuvre par le même appareil. Les flux de données pour les mécanismes de décision et d’adaptation sont présentés dans la Figure 4. Une telle décision peut être statique (prise une seule fois, au début de la transmission) ou dynamique, elle pourra alors être mise en œuvre à différents endroits de l’architecture du service, par exemple : l

au codage – en séparant les unités vidéo en différents niveaux de débit, tous attribués à un flux de sortie différent et envoyés à des groupes d’utilisateurs disposant de capacités hétérogènes au niveau des réseaux/terminaux ;

31

Compression vidéo

l

au serveur de vidéo à la demande – en adaptant le débit de la transmission vidéo dans une session unicast ou en utilisant les propriétés de scalabilité pour ameliorer les fonctionnalités telle que l’avance ou le retour rapide dans une video. ; l à un nœud du réseau – en réorganisant les unités vidéo afin de permettre au flux vidéo de passer sur un sous-réseau ayant des caractéristiques différentes ; l à la fin du réseau – ou un DSLAM (Digital Subscriber Line Access Multiplexer – multiplexeur de lignes d’abonné numériques) peut sélectionner de manière dynamique les unités vidéo (les paquets) pour la qualité du service, les changements de chaîne ou simplement la gestion des accès ; o au niveau du routeur domestique – pour tenir compte des conditions du réseau domestique.

3. Utilisations envisagées Le paysage audiovisuel actuel est en constante évolution et, dans un tel contexte, la scalabilité est devenue une caractéristique essentielle des systèmes. Nous avons déjà identifié plusieurs cas de figure dans lesquels le SVC pourrait être un développement positif. Nous allons présenter quelques cas dans lesquels les spécialistes sont d’accord pour dire que le SVC devrait être très utile.

3.1. Qualité de service et expérience utilisateur améliorée 3.1.1. Zapping rapide, avance et retour en arrière fluides L’objectif ici est d’améliorer l’expérience client lors de l’utilisation de fonctions telles que le changement de chaîne ou l’avance/ retour en arrière rapide des images. Si la vidéo actuelle est affichée à un débit donné et qu’elle est décomposée en, au moins, une couche de base et une couche d’amélioration, le passage vers la couche la plus basse nous permet soit de visualiser la chaîne suivante (changement de chaîne TV), soit d’avoir un mécanisme d’avance rapide plus fluide (fonction vidéo à la demande). Cela s’explique par le fait que moins d’informations sont nécessaires pour décrire

32

fast forward without SVC: n images/second at full resolution

with SVC : n*4 images/second, at lower resolution: fast forward is more fluid => HD images not transmitted because of lack of bandwidth

Figure 5 – SVC pour avance rapide à résolution moindre

les images des couches inférieures. Ainsi, la largeur de bande disponible est utilisée pour transmettre un plus grand nombre d’images de dimensions inférieures (voir Figure 5). Bien évidemment, le nouveau flux décodé (un nouveau canal, en cas de changement de chaîne, ou d’autres séquences de la vidéo, dans le cas d’une avance rapide) offre une qualité inférieure jusqu’à ce que les deux couches puissent être envoyées. Dans un premier temps, des images d’une résolution plus faible sont reçues et agrandies artificiellement afin de correspondre aux dimensions de l’écran. Il a toutefois été démontré que la vision humaine devient vraiment sensible à la qualité après environ deux secondes. Ainsi, une image noire (changement de chaîne) ou une avance rapide non fluide sont plus gênantes que des informations visionnées rapidement, même si la qualité d’image diminue pendant un laps de temps pouvant aller jusqu’à deux secondes.

Une caractéristique intéressante du SVC est sa capacité à utiliser la couche d’amélioration comme couche de retransmission : en cas d’erreur, les paquets devant être retransmis seront insérés dans les couches d’amélioration, ce qui permet de fournir une correction d’erreurs à débit constant (voir Figure 6). En contrepartie, il faut accepter une perte de qualité, car la quantité de données d’amélioration reçue est inférieure, une partie de ces données étant remplacée par les données de la couche de base envoyées une deuxième fois. Ce mécanisme garantit une réception des informations avec une qualité minimum, en mettant à disposition une protection maximale de ces informations.

3.1.2. Intégration des transmissions à débit constant

La réception mobile ne peut se baser sur une largeur de bande stable. En effet, la largeur de bande diminue lorsque la cellule du réseau est saturée ou lorsque le client est transféré d’une cellule à une autre. Toutefois, le client est très dérangé par les interruptions de service. L’avantage d’avoir une vidéo décomposée en couches est que les couches peuvent simplement être sorties du flux, puis réinsérées, selon la largeur de bande disponible (voir la Figure 7).

Dans le cas d’erreurs de transmission fréquentes, différents mécanismes sont mis en œuvre pour les éliminer et améliorer la qualité du service. Un de ces mécanismes consiste à retransmettre les paquets qui ne sont jamais arrivés au terminal. Toutefois, ces mécanismes exigent de la largeur de bande supplémentaire, sinon ils ralentissent la vitesse de transmission en raison du supplément d’informations à envoyer.

3.2. Continuité du service dans l’environnement mobile

Une telle fonction n’est pas seulement utilisée en cas de transmission difficile sur un seul


Compression vidéo

réseau, elle peut également être employée pour un même contenu vidéo transmis sur différents types de réseau à différents types de terminaux : une même vidéo est envoyée avec seulement une couche de base aux téléphones mobiles, mais les PC connectés au même réseau peuvent la recevoir en qualité maximum (base + amélioration).

3.3. Portabilité pour la vidéo à la demande : l’exemple de l’Internet ouvert Le SVC permet d’utiliser très simplement la même source vidéo sur des terminaux différents. Aucune opération de transcodage n’est nécessaire, ce qui veut dire qu’aucun temps de calcul supplémentaire n’est à prévoir et qu’il n’y aura aucune perte de qualité. Cette particularité devient particulièrement utile lorsque l’on ne sait pas à l’avance où et comment la vidéo en question sera utilisée. Le SVC permet d’acheter le contenu, de commencer à le regarder sur un terminal et de finir de le visionner sur un autre terminal. Il en découle quelque chose de très important pour les propriétaires de contenu : la gestion numérique des droits est préservée, ce qui représente un avantage essentiel par rapport au transcodage. L’exemple d’utilisation le plus évident de cette caractéristique est la plateforme vidéo naturellement convergente appelée Internet ! Il est possible d’accéder aux portails depuis des PC, mais également (et c’est de plus en plus fréquent) depuis des téléphones mobiles. Comme on peut le voir à la Figure 8, cela implique que le contenu sera visionné sur une plateforme qui n’est pas définie à l’avance (c’est-à-dire au moment du téléchargement).

3.4. Optimisation des coûts pour la gestion des contenus à la demande moins populaire. Les catalogues à la demande deviennent de plus en plus grands en termes de titres disponibles / références. Par conséquent, les coûts générés par la préparation et réadaptation de ces contenus sont en constante augmentation,


1RHUURUVGHWHFWHGERWK EDVHDQGHQKDQFHPHQW OD\HUVUHFHLYHG 14

12

B itrate

(UURUVGHWHFWHGEDVHHQKDQFHPHQW DIIHFWHGE\SDFNHWORVV

S tre a m B itra te R e trie s

14

B itrate

S tre a m B itra te R e trie s

12

Congestion

No Congestion M a x im um B a n d w id th

10

8

6

6

4

4

R etra nsm issions w ith out S V C : con g estio n

0

M a x im um B a n d w id th

10

8

2

(UURUVGHWHFWHG EDVHUHWUDQVPLWWHGSDFNHWV RIEDVHLQIRUPDWLRQ

Stream and Retries are adapted

2 T im e

R etra nsm issions w ith SVC : no extra b an d w idth n ee de d

0

T im e

Figure 6 – SVC pour intégration des retransmissions à débit binaire constant

availab le b an dw id th / q u ality

tim e

Figure 7 – SVC pour maintien du service en mobilité

G et//u se P C versio n fro m /fo r T V

G et P C versio n

G et T V versio n

T ransfer to m o b ile

G et m o b ile versio n

E xtract m o b ile versio n fro m P C versio n Figure 8 – SVC pour faciliter la gestion de la portabilité du contenu

33

Compression vidéo

malgré l’automatisation des processus. En outre, cette augmentation des coûts est également en rapport avec les appareils et les débits utilisés (réseaux d’accès). Il existe des solutions bien connues pour résoudre la question des coûts dans le cas des contenus les plus populaires. Cependant, la question de l’amortissement efficace des coûts de préparation pour les contenus moins populaires- long tail content - n’a pas été résolue, même si les droits relatifs à ces contenus sont moins importants que pour les contenus très demandés par le grand public. Les coûts susmentionnés correspondent aux différentes tâches faisant partie du processus global de mise à disposition du contenu à la demande : l l

l

l l l

acquisition du contenu. saisie du contenu (à partir de bandes, de signaux, de fichiers, etc.) et montage – pour réaliser ces deux opérations, il faut parfois indexer les images et extraire / générer des métadonnées ; préparation du contenu (codage et transcodage) et traitement des métadonnées ; vérification de l’intégrité du contenu ; création du fichier (y compris la protection des droits - DRM) ; distribution du contenu ;

La préparation et la vérification du contenu génèrent des coûts importants dans le cadre de ce processus. En multipliant le nombre de fois où le flux doit être généré pour être adapté à différents appareils sur de multiples réseaux d’accès, on augmente les coûts de traitement à la demande, notamment pour les contenus moins populaires, même avec des processus de traitement automatisés. Nous sommes d’avis qu’en réalisant un seul codage à l’aide du SVC, on peut éviter une suite de codages avec le H.264/AVC, ce qui permet de diminuer les investissements et les dépenses d’exploitation relatifs au traitement du contenu. De plus, nous sommes d’avis que le SVC permet également de gérer plus efficacement la gestion du contenu au sein d’un réseau de distribution d’un contenu. En fait, on

34

peut ainsi utiliser les paramètres d’accès au réseau pour gérer la distribution du contenu jusqu’aux utilisateurs finaux. Dans ce contexte, la combinaison de la scalabilité spatiale (appareils multiples) et de la scalabilité SNR (capacité du réseau d’accès) est probablement la fonctionnalité la plus attendue. Enfin, les coûts de stockage sont réduits, car un flux complet SVC occupe moins de place de stockage que plusieurs fichiers AVC.

3.5. Adaptation fine liée à l’éligibilité xDSL dans les foyers 3.5.1. Qualité optimale pour un niveau d’éligibilité donné : exemple pour un écran HD sans éligibilité HD Le SVC contribue à définir des niveaux d’éligibilité ADSL intermédiaires, pour lesquels différentes qualités peuvent être proposées. Il est donc possible de fournir une bonne qualité d’image en définition normale aux clients qui ne peuvent atteindre les débits nécessaires pour la HD, mais qui ont la possibilité d’avoir une qualité d’image bien meilleure que celle fournie par le seuil d’éligibilité de la définition standard. Le programme peut être codé en SVC, avec une couche de base H264/AVC en définition normale, plus une première couche d’amélioration de la qualité et/ou de la résolution (à un débit intermédiaire entre le débit de la définition normale et celui de la HD) et d’une seconde couche d’amélioration pour les clients HD (voir la Figure 9). Cela permettrait d’améliorer la faible qualité constatée par les clients qui regardent des programmes sur leurs écrans HD, si la qualité de la vidéo qu’ils reçoivent n’est pas véritablement celle de la HD. Cette fonctionnalité peut également être utile dans le cadre des projets FTTH (Fiber To The Home – fibre optique à domicile). Pendant un certain laps de temps, la FTTH ne sera disponible nulle part. Le SVC permet de distribuer un même contenu à différents débits, qualités et résolutions. Par conséquent, lorsque la FTTH sera en service, il sera

possible de mettre en place une dernière couche d’amélioration spécifiquement adaptée aux capacités de largeur de bande de la FTTH, et donc de proposer du contenu HD “premium” aux foyers qui sont en mesure de le recevoir.

3.5.2. Accès dynamique mutuel à la largeur de bande disponible dans un domicile La scalabilité SNR du SVC met à disposition un moyen efficace pour proposer simultanément aux utilisateurs finaux de meilleurs services tant au niveau d’Internet que de l’IPTV privée (WG-IPTV), en adaptant le débit vidéo IPTV, selon la largeur de bande nécessaire pour fournir une navigation sur Internet à une vitesse correcte. De plus, si la vidéo pour Internet est codée avec la scalabilité SNR du SVC, elle pourra également être adaptée de manière à ce que l’impact sur le flux WG IPTV ne soit pas perceptible (même avec des mécanismes de fondu lors des transitions). Cette adaptation peut être gérée dynamiquement par le réseau ou être confiée à l’utilisateur. Avec des technologies vidéo à une seule couche, la mise en œuvre de tels mécanismes dynamiques exigerait une conversion des débits quelque part dans le réseau (probablement à une extrémité), ce qui, bien évidemment, n’est pas intéressant en termes d’architecture réseau et d’efficacité du traitement des données. Un autre exemple de cette utilisation est l’adaptation dynamique de la largeur de bande, par exemple si une autre télévision (en définition normale) est allumée alors qu’une télévision HD est déjà utilisée. Dans ce cas, la largeur de bande peut être partagée entre les deux programmes, ce qui donne une qualité optimale à chaque poste TV, selon leurs propriétés et les caractéristiques des terminaux cibles.

3.5.3. Vecteur d’une mise en œuvre efficace des services TVHD premium Les consommateurs sont encore en train de s’équiper de décodeurs externes utilisant le H.264/AVC. L’introduction sur le marché d’un système scalable totalement nouveau impliquerait la création d’un ensemble de produits de nouvelle génération et entraînerait


Compression vidéo

l

: D is ta n c e s to D S L A M = > d iffe re n t e lig ib ility = > b e s t m a tc h in g q u a lity le v e l

l

H D n o n e lig ib le , ye t H D scre e n s = > 1 st e n h a n ce m e n t la ye r w ith re so lu tio n im p ro ve m en t H D e lig ib le zo n e , H D scre e n s : = > 2 nd e n h a n ce m e n t la ye r w ith b e tte r q u a lity

l

D S L AM

l

S D e ligible zo n e o n ly = > A V C b a se la ye r, S D re so lu tio n

Figure 9 – SVC pour une gestion fine du niveau d’éligibilité

des problèmes d’interopérabilité avec les systèmes existants. La diffusion simultanée de plusieurs flux exigerait une largeur de bande plus importante que celle d’un seul flux en SVC. En outre, les utilisateurs seraient obligés de sélectionner le canal diffusant la qualité/ résolution souhaitée (selection du canal SD ou du canal HD si disponible). La compatibilité de la couche de base SVC avec le H.264/AVC permettrait aux consommateurs qui ne peuvent exploiter le SVC de pouvoir continuer à voir leurs programmes habituels (en définition standard ou en HD [1080i/25 ou 720p/50]), si la HD est diffusée sous forme de couche de base du flux SVC. Les utilisateurs dont les appareils sont compatibles avec le SVC auront accès, par exemple, aux signaux de qualité supérieure (1080p/50) stockés dans la couche d’amélioration, en tant que service “premium”. Il est intéressant de rappeler que le support offert au type de balayage (entrelacé/

progressif) est très important pour le secteur de la radiodiffusion, car il permet une transition sans problèmes (pour les consommateurs) et efficace (pour les radiodiffuseurs) d’un paysage audiovisuel en définition standard à une diffusion HD (utilisant si possible uniquement le balayage progressif).

l

3.6. Autres utilisations possibles Même si elles nous semblent pour l’heure moins urgentes à traiter, un certain nombre d’autres utilisations possibles doivent également être étudiées. l

Encouragement à l’utilisation du contenu “premium” (teasing) : montrer gratuitement du contenu auquel les informations essentielles ont été enlevées (par exemple, les joueurs lors d’un match de foot) et mettre ces informations à disposition lorsque les utilisateurs ont payé pour le contenu en question.

l

l

Streaming P2P : introduire le SVC en tant qu’outil permettant d’exploiter les informations distribuées par des sources multiples. Contenu généré par les utilisateurs : contenu auquel on accède le plus souvent par des terminaux hétérogènes et par le biais de différents réseaux, qui pourrait exploiter pleinement le potentiel du SVC. Distribution et préparation vidéo : comment analyser, indexer, prétraiter, vérifier la gestion des droits numériques et attribuer des propriétés à une vidéo spécifique dans les différentes couches. Optimisation des serveurs de courrier vidéo : donner accès à la vidéo uniquement avec la qualité la plus faible lorsqu’elle est visualisée grâce à un réseau mobile, et permettre de visualiser les images avec la résolution maximum lorsque le message est consulté depuis la maison, éventuellement mettre à disposition des versions intermédiaires adaptées au réseau et au terminal utilisés (le SVC permet d’économiser de la place de stockage car il n’est plus nécessaire de disposer de versions intermédiaires). Optimisation de la durée de la batterie des appareils mobiles : le SVC permet de passer à une résolution inférieure si l’autonomie (durée de la batterie) passe en dessous d’un seuil prédéfini. Il permet également d’informer le client du nombre de minutes de visualisation restantes à la résolution choisie. Terminaux hétérogènes et réseaux d’accès pour les vidéoconférences, l’eapprentissage et la surveillance vidéo : le SVC permet de ne pas imposer les caractéristiques du réseau et du terminal les plus faibles aux autres participants. Le SVC permet de surveiller efficacement les signaux des liens de contribution en décodant uniquement la résolution la plus faible et en évitant de décoder la totalité du flux vidéo.

Définitions 720p/50 1080i/25 1080p/50

Format TV haute définition à balayage progressif de 1280 x 720 pixels à 50 images par seconde Format TV haute définition à balayage entrelacé de 1920 x 1080 pixels à 25 images par seconde, soit 50 trames (demi-images) par seconde Format TV haute définition à balayage progressif de 1920 x 1080 pixels à 50 images par seconde


35

Compression vidéo

4. Évaluation de la technologie Le comité MPEG a rédigé un document rassemblant toutes les “exigences” relatives au SVC avant que le véritable processus de normalisation ne soit véritablement engagé. Les principales exigences étaient les suivantes : l

Mise à disposition d’une norme compatible avec la technologie la plus avancée (le H264/AVC). Cette exigence a été satisfaite car toutes les couches de base SVC sont codées en respectant la norme H264/AVC. l Compression dans un seul flux de différentes versions (différentes résolutions ou différentes qualités) de la même vidéo : – l’efficacité devait être supérieure à celle obtenue en codant séparément les différentes versions en H264/ AVC et en diffusant simultanément les flux (simulcast) – cette exigence a été satisfaite ; – augmentation maximum de 10 % de la quantité d’informations par rapport à un flux codé en H264/ AVC avec la résolution/qualité maximale. Dans ce cas, l’appréciation dépend du cas de figure envisagé. De manière générale, plus le nombre de niveaux inclus est élevé, plus l’utilisation du SVC est intéressante par rapport à des compressions séparées. Toutefois, la quantité d’informations supplémentaires augmente proportionnellement à la diversité des couches spatiales. Pour donner une appréciation d’une nouvelle technologie, il faut définir des tests pour évaluer ses performances par rapport aux autres technologies équivalentes dans le même domaine. Il n’est pas facile de mettre au point des tests pour le SVC car il ne s’agit pas d’une nouvelle norme de compression qu’on peut comparer à une norme plus ancienne. Dans ce cas, il s’agit de compresser plusieurs représentations des mêmes informations. Ensuite, après avoir choisi l’application cible, il faut définir la structure interne de l’information c’est a dire définir les différentes manières dont la vidéo peut être exploitée : améliorations spatiales (à quelles résolutions),

36

améliorations de qualité (jusqu’à quelle qualité ?), améliorations temporelles (quelles fréquences ?) ... ou une combinaison de toutes ces améliorations ? Tout cela implique que la comparaison dépend de l’application prévue :

subjectivement (qualité visuelle). Un résumé des résultats de ces tests figure dans les prochains paragraphes.

4.1. Évaluation des performances

Pour des services multicast, nous pouvons comparer un flux SVC avec la somme des informations diffusées simultanément codées avec le H264/AVC (voir Figure 10). La diffusion simultanée des flux en jaune (sur la gauche du diagramme) doit être comparée à la transmission du flux unique en bleu (sur la droite), en tenant compte du fait qu’il faut adapter/ extraire ce flux, quelque part entre la zone de production du flux et l’appareil de l’utilisateur final. l Pour les services à la demande, on peut comparer les flux SVC avec la somme des fichiers codés stockés. Il s’agit dans ce cas de comparer le stockage des flux colorés en jaune à celui du flux en bleu clair. Il est intéressant de relever que l’indexage est plus facile si l’on adopte la solution dans laquelle plusieurs versions sont intégrées dans un seul fichier. l Pour la portabilité du contenu, on peut comparer les capacités du SVC au transcodage d’une première version codée de la vidéo.

4.1.1. Test visant à déterminer la qualité visuelle réalisé par Orange Labs

Les évaluations des performances du SVC pour les différentes utilisations ont été menées par plusieurs laboratoires de recherche, des industries et le JVT, afin de quantifier les performances du SVC, que ce soit objectivement (par des mesures) que

Il est important de remarquer que, contrairement à ce qui se fait pour évaluer une compression “classique” où l’on compare la différence de débit pour une qualité donnée, dans ce cas, c’est la perte de qualité à débit constant qui est étudiée. Il ne faut

l

Orange a décidé de déterminer les critères qui sont essentiels pour les services audiovisuels actuels. Il a donc été décidé de procéder à des évaluations de scenarios critiques afin de disposer de valeurs minimales permettant de considérer que, à l’avenir, tout résultat devrait être supérieur au plancher ainsi défini. Orange a choisi l’éligibilité ADSL comme condition minimum pour mettre en service de nouvelles technologies. En d’autres termes, Orange a décidé d’étudier les implications de la mise à disposition d’un service TV et vidéo codé en SVC aux débits utilisés actuellement. Orange a ensuite comparé un fichier HD codé/décodé en H264/AVC avec une seule couche (fichier jaune en bas à gauche de la Figure 10) avec un fichier complètement codé/ décodé avec le SVC et contenant une couche de base en définition standard (fichier bleu de la Figure 10).

SD

HD

2 separate AVC bitstreams : multiple instances

SD + HD

1 unique SVC bitstream : data amount for same information

Figure 10 – Comparaison de la diffusion simultanée des flux avec codage H264/AVC par rapport à un flux unique SVC


Compression vidéo

Les tests ont été réalisés en utilisant plusieurs débits : 12 Mbit/s, 10 Mbit/s, 8 Mbit/s, 6 Mbit/s et 4 Mbit/s.

standard et la HD) donne une qualité visuelle qui a été considérée de semblable à meilleure que le flux HD AVC à couche unique pour des débits supérieurs à 7 Mbit/s. Transmettre en même temps la définition normale et la HD avec un fichier AVC à couche unique implique l’utilisation d’un débit supérieur (la somme des débits des deux flux) à celui nécessaire pour le flux SVC. Pour un débit HD AVC à une seule couche de moins de 7 Mbit/s, le SVC a besoin, afin de fournir une qualité visuelle similaire, d’un débit supplémentaire correspondant à celui de la définition standard de l’AVC avec une seule couche. l Dans les cas les plus critiques, la perte entre la représentation H264/AVC

Pour tester le débit n, un fichier H264/AVC a été entièrement codé à n Mbit/s. Le fichier SVC a une couche de base pour la définition standard qui est toujours codé à 2 Mbit/s, plus une couche d’amélioration codée à n-2 Mbit/s.

l

l

l

Excellent

100

Good

80

Scores

Plus précisément, les tests effectués ont été les suivants :

l

et la représentation SVC maximum peut atteindre jusqu’à 10 points MOS (Mean Opinion Score), ce qui n’est pas négligeable. Dans les cas moins extrêmes, la différence est toujours perceptible, mais pas pénalisante, dans la mesure où les appréciations restent bonnes (“excellent” ou “bon”). Le SVC est plus performant si la couche de base est de bonne qualité, car toutes les prédictions d’amélioration se basent sur elle. Si la séquence de départ est entrelacée, le SVC est plus efficace avec la scalabilité entrelacé à-entrelacé qu’un mélange de couches entrelacées et progressives. Si la séquence de départ est progressive,

60 Fair

pas pour autant en conclure que le SVC offre une qualité moindre par rapport aux anciennes méthodes (sinon, il serait inutile de remplacer les technologies déjà utilisées !). Cette démarche implique donc l’evaluation des effets secondaires provoqués par la scalabilité : le coût supplémentaire impliqué par la version “maximum” (sans tenir compte du fait que les versions “minimum” sont également transmises dans tous les cas, dans la mesure où elles sont intégrées dans le fichier) est comparé à ce qui se passerait si une telle version était codée avec d’autres méthodes.

40 Poor

a) fichier H264/AVC (720p/50) / fichier SVC (576i/25, 720p/50) b) fichier H264/AVC (1440x1080i/252) / fichier SVC (576i/25, 1440x1080i/25)

Subjective quality scores for all the scenes

720p50_AVC 720p50_SVC

Bad

20

Explicit Ref. Hidden Ref.

Les détails figurent dans le Tableau 2.

0 3

4

5

6

7

8

9

10

11

12

13

Bitrate (Mbit/s)

Les fichiers H264/AVC et SVC ont été générés grâce au JSVM (Joint Software Verification Model) du MPEG-ITU.

Excellent

80 Good

Scores

60 Fair

L’évaluation de la qualité visuelle a été réalisée sur un écran LCD de 46 pouces, selon la méthode SAMVIQ (Subjective Assessment Methodology for Video Quality) [6] [7].

100

40

Il est possible de tirer plusieurs conclusions de ces données :

20

l

Le flux SVC (englobant la définition

Poor

Les figures 11 et 12 illustrent les résultats des deux tests.

Subjective quality scores for all the scenes

1080i_AVC 1080i_SVC

Bad

Explicit Ref. Hidden Ref.

0 3

4

5

6

7

8

9

10

11

Bitrate (Mbit/s) 2)

1440 samples per line are subsampled from a 1920 samples/line source signal.


Figure 11 (en haut) Résultats des tests A

Figure 12 (en bas) Résultats des tests B

37

Compression vidéo

Débit H264/AVC (Mbit/s)

Base

Amélioration

Total

4 6 8 10 12 4 6 8 10

2 2 2 2 2 2 2 2 2

2 4 6 8 10 2 4 6 8

4 6 8 10 12 4 6 8 10

1280x720p/50

1440x1080i/25

Débit SVC (Mbit/s)

Tableau 2 – Données portant sur le débit SVC/AVC pour les comparaisons visuelles

le SVC est plus efficace avec la scalabilité progressif-à-progressif qu’un mélange de couches entrelacées et progressives. Il est intéressant de remarquer que ces résultats ont été obtenus en utilisant uniquement des versions du logiciel SVC (MPEG/ITU JSVM) auxquelles tout un chacun a accès. Il est évident que les versions industrielles, une fois mises au point, auront fait l’objet d’une optimisation. Ces tests ont été conçus dans le but d’identifier l’impact sur la qualité d’une éventuelle substitution du H264/AVC par le SVC, en partant du principe que les autres facteurs, tels que le débit, ne changent pas. Ce débit constant a une influence sur le niveau le plus élevé, dans ce cas la HD, puisque nous imposons que la couche de base en définition standard codée dans le fichier SVC soit codée en tenant compte des exigences pour la définition standard actuelle (2 Mbit/s). Cela permet sans aucun doute d’assurer la compatibilité avec les services existants dans la mesure où la couche en définition standard peut simplement être décodée par les utilisateurs qui disposent d’un décodeur H264/AVC, incapable d’exploiter le SVC. Il est ainsi possible de simuler une base qui répond aux besoins des services TV actuels.

4.1.2. Évaluation des performances réalisée par le département Corporate Research de Thomson La radiodiffusion HD basée sur la norme H.264/AVC a été lancée en janvier 2005.

38

Depuis, des millions de récepteurs ont été mis sur le marché (DirecTV, Echostar, BSkyB,...). Les formats HD utilisés sont au nombre de deux : le 720p/50-60 et le 1080i/25-30. Pour les services “premium”, notamment les sports, les radiodiffuseurs veulent diffuser en 1080p/50 60, sans perdre leur clientèle existante. La diffusion de flux SVC en 1080p/50-60 améliore la résolution vidéo par rapport au 720p/50-60 ou au 1080i/2530. Des décodeurs externes améliorés pourraient être fournis aux clients des services “premium”. Ces décodeurs pourraient tirer parti du codage SVC en 1080p/50-60 (en plus du H.264/AVC), sans qu’il soit nécessaire de changer les décodeurs qui ont déjà été livrés. a) Comparaison entre le 720p/1080p et le 1080i/1080p Actuellement, les radiodiffuseurs utilisent principalement le 1080i/25-30 pour la TVHD. Dans un avenir proche, le contenu source sera de plus en plus souvent en format 1080p/50-60. Le SVC permet une migration vers le 1080p/50-60 en utilisant une solution compatible avec le H264/AVC (couche de base). Il reste à décider si la couche de base du H.264/AVC doit être codée en 720p/5060 ou en 1080i/25-30. Thomson Corporate Research a réalisé une première évaluation en utilisant le logiciel SVC de référence et en examinant les courbes du taux de distorsion. Conditions du test Nous avons utilisé le logiciel JSVM pour un exemple d’utilisation à deux couches :

l

le 720p50/1080p50 : prédiction intercouches progressif-à-progressif ; l le 1080i25/1080p50 : prédiction intercouches entrelacé-à-progressif avec un codage par trames. Le paramétrage du codeur était le suivant : l l l l l

l

Profil supérieur scalable ; GoP hiérarchique taille 4 (structure de codage IbBbP) ; Intra-période = 32; 100 premiers cadres ; couches de base H.264/AVC codées à débit constant (CBR) – R0 = 4 Mbit/s ; – R1 = 6 Mbit/s ; – R2 = 8 Mbit/s ; – R3 = 10 Mbit/s ; Po u r c h a q u e d é b i t , l e s c o u c h e s d’amélioration SVC ont été codées en utilisant le paramètre de quantification QpEL = QpBL + {0, 4, 8, 12}.

Résultats Une partie des résultats de ces tests est résumée aux Figures 13 à 18 des deux pages suivantes. Conclusions En utilisant une couche de base H.264/AVC en 720p/50 ou 1080i/25 avec une couche d’amélioration en 1080p/50, on arrive approximativement au même rapport signal de puissance sur bruit (PSNR Peak Signal to Noise Ratio), pour ce qui est de l’efficacité de compression (une différence de moins de


Compression vidéo

Figure 13 Résultats pour la séquence EBU_dance au débit R0

Figure 14 Résultats pour la séquence EBU_dance au débit R3

Figure 15 Résultats pour la séquence SVT_ CrowdRun au débit R0


39

Compression vidéo

Figure 16 Résultats pour la séquence SVT_ CrowdRun au débit R3

Figure 17 Résultats pour la séquence SVT_ParkJoy au débit R0

Figure 18 Résultats pour la séquence SVT ParkJoy au débit R3

40


Compression vidéo

0,5 dB). De plus, on peut relever que le gain au niveau du débit par rapport à la diffusion simultanée est apparent et confirmé (environ 30 %). En sachant que le rapport signal de puissance sur bruit n’est pas toujours proportionnel à la perception visuelle, d’autres évaluations subjectives de la qualité visuelle devront être organisées sur un échantillon de séquences plus large, afin de valider ces résultats.

4.1.3. Évaluation des performances réalisée par JVT Au début de cette année, le groupe JVT a publié un rapport sur l’évaluation des performances du SVC, sur une série d’études de cas d’étude prédéfinis [8]. Les tests couvraient les points suivants : l

évaluation de la qualité objective par l’utilisation des méthodes PSNR et SSIM (Structutral SIMilarity metric) ; l évaluation de la qualité subjective par l’utilisation de deux méthodes basées sur la recommandation BT.500 de l’UIT-R[9]. Il convient de remarquer que les différents scénarios testés ont examiné uniquement la scalabilité du format d’image en progressifà-progressif, en excluant du champ d’études la scalabilité entrelacé à-progressif (SDI vers le 720p/50 ou le 1080p/50), progressif-àentrelacé (moins probable) et entrelacéà-entrelacé (SDi vers le 1080i/25), qui pourraient présenter un intérêt pour le secteur de la radiodiffusion. Les tests ont permis de conclure que, selon les applications, le SVC permet un gain de 17 à 34 % du débit, par rapport à la diffusion simultanée. Au niveau de la qualité visuelle, pour les séquences difficiles, le SVC a besoin d’un supplément de débit pouvant aller jusqu’à 10 % pour fournir une qualité similaire ou supérieure que celle offerte

par un flux à couche unique. Pour de plus amples informations, veuillez vous référer au document suivant : [8].

membres du groupe de coordination du logiciel JSVM peuvent modifier les fichiers stockes dans le serveur.

4.2. Mise en œuvre et complexité

5. Informations sur la normalisation

Pour le moment, seule la version de référence du logiciel, la 9.12, est librement accessible. Des laboratoires de recherche comme HHI et d’autres entités du secteur développent constamment des versions optimisées des codeurs. Des évaluations des codeurs doivent encore être réalisées, mais il semble que cela ne soit pas un problème pour la version du logiciel. On a des raisons de penser de la complexité du codeur par rapport au H.264/AVC ne devrait pas être très importante. La conception du SVC comprend une seule boucle de compensation du mouvement (en imposant une prédiction intra dans les couches de référence). Ainsi, la différence de complexité du décodeur pour le SVC, par rapport au codage en simple couche, est plus faible que celle des normes de codage vidéo précédentes, qui ont toutes besoin de boucles de compensation du mouvement multiples au niveau du décodeur. En outre, chaque unité NAL de couche d’amélioration spatiale ou qualitative peut être traitée indépendamment des unités NAL de couche inférieure, ce qui peut contribuer à réduire encore la complexité du décodeur.

L’environnement audiovisuel actuel a évolué à bien des égards (services, terminaux, accès réseau. etc.). De plus, les services sont désormais conçus également pour des appareils destinés au grand public. Dans ce contexte, le besoin d’interopérabilité n’a jamais été aussi grand. Les organismes chargés de la normalisation s’intéressent à une technologie lorsqu’un grand nombre de fournisseurs de services et d’industries commencent à l’utiliser. De nombreux organismes de normalisation et des forums ont donc annoncé la création de groupes de travail consacrés au SVC : l

l l

Afin de suivre l’évolution du logiciel et de toujours mettre à disposition une version à jour du logiciel JSVM, un serveur CVS pour le logiciel JSVM a été mis en service à la Rheinisch-Westfälische Technische Hochschule (RWTH) d’Aix-la-Chapelle, en Allemagne. Il est possible d’accéder au serveur CVS en utilisant WinCVS ou tout autre client CVS. Les paramètres spécifiés au Tableau 3 sont nécessaires pour avoir accès au serveur, qui est configuré en lecture seule. Seuls les

l

l

authentication: host address: path: user name: password: module name:

pserver garcon.ient.rwth-aachen.de /cvs/jvt jvtuser jvt.Amd.2 jsvm or jsvm_red

D V B – Le DV B a u n e i n f l u e n c e considérable dans le monde des codecs audio/vidéo et les groupes du DVB chargés du H264/AVC ont inclus le SVC dans leurs programmes de travail pour la radiodiffusion mobile (DVB-H), le 1080p et l’IPTV. Les groupes IPTV examinent actuellement le SVC dans le cadre de leurs unités chargées de la distribution du contenu. 3GPP – Le SVC sera présenté afin d’étudier son impact sur l’architecture. Forum OpenIPTV – puisque la première phase se base sur les codecs disponibles actuellement et qu’elle touche à sa fin, une seconde phase sera bientôt lancée. Nous avons proposé d’inclure le SVC dans les sujets à traiter, tant dans le cadre des codecs que dans celui de l’infrastructure IPTV. Groupe spécialisé de l’UIT sur l’IPTV – Des contacts ont été pris avec le DVB pour étudier les questions liées aux codecs. UER – Le Comité de gestion des technologies de distribution (DMC) a créé le groupe de projet D/SVC en juin 2008, afin d’étudier les performances objectives et subjectives du SVC dans le cadre de la radiodiffusion. Ce groupe est ouvert aux Membres de l’UER et aux intervenants du secteur.

Tableau 3 – Paramètres d’accès CVS


41

Compression vidéo

Adi Kouadio est titulaire d’une licence et d’une maîtrise en systèmes de communication qu’il a obtenues à l’Ecole polytechnique fédérale de Lausanne (EPFL), en Suisse. Il a d’abord travaillé pour la société Fastcom Technology SA, dans le cadre de plusieurs projets liés à la reconnaissance d’objets dans des images vidéo. Il a ensuite rejoint le Département technique de l’UER en 2007, où il participe activement à des études et à des évaluations des systèmes de compression utilisés dans le cadre de diverses applications de la radiodiffusion (production, contribution et distribution en TVHD). M. Kouadio coopère au nom de l’UER avec les groupes de travail ISO/IEC JTC1/SG26/WG1 (JPEG) et ISO/IEC JTC1/SG26/WG11 (MPEG).

Maryline Clare obtient en 1989 son diplôme de l’INSA (Institut National des Sciences Appliquées), une école d’ingénieur française. Elle se spécialise ensuite pendant près de 10 ans dans le codage des images fixes, chez Canon Research France. Elle contribue alors activement aux efforts de normalisation de JPEG2000 et dans ce cadre, elle est chef de la délégation française et Vice-présidente du groupe “Transform – Quantization – Entropy coding”. Mme Clare a continué à travailler dans le domaine de la compression vidéo, tout d’abord pour Canon Research France puis au sein d’Orange Labs (nouveau label du réseau de recherche et développement de France Télécom), à Rennes. Elle s’est intéressée dans un premier temps à la norme AVC (Advanced Video Coding, MPEG-4 - Part 10, ITU H.264), puis a suivi avec attention son extension scalable, la SVC (Scalable Video Coding). Elle pilote actuellement un projet sur ce sujet dans le cadre d’Orange Labs.

Ludovic Noblet a obtenu son diplôme d’ingénieur, spécialisé en électronique et systèmes informatiques, à l’Ecole polytechnique de l’Université de Nantes, en 1992. Il débute ensuite sa carrière chez Alcatel, où il est chargé d’intégrer les technologies Internet dans le réseau privé de la société (Alcanet). En octobre 1994, il rejoint la société Thomson Corporate Research, pour laquelle il s’occupe de concevoir trois générations successives de codeurs MPEG-2, ainsi qu’une génération de décodeur MPEG-2. En 2002, il commence à travailler sur les premières implémentations du codage H.264/MPEG-4 AVC, pour la première génération de codeurs Thomson AVC en TVDS et TVHD. En 2004, M. Noblet rejoint France Télécom, en qualité d’architecte IPTV et de conseiller technique senior pour le lancement de la norme lH.264/MPEG-4 AVC et de la haute définition, dans le cadre du service Orange TV. En septembre 2006, il est nommé responsable de l’équipe “Advanced Video Compression” d’Orange Labs. Depuis décembre 2004, M. Noblet représente la société Orange auprès du consortium DVB et au sein de groupes ad hoc commerciaux et techniques chargés de définir le cadre d’utilisation des codeurs A/V dans les applications DVB. Il représente également Orange au forum Open IPTV, sur les mêmes sujets.

Vincent Bottreau obtient le diplôme d’Etat français d’ingénieur physicien auprès de l’École Nationale Supérieure de Physique de Strasbourg (ENSPS), en 1999. Il obtient également un DEA en photonique et traitement d’images à l’Université Louis Pasteur de Strasbourg, en 1999. De 1999 à 2003, M. Bottreau travaille pour Philips Research à Suresnes, où il occupe un poste de chercheur dans le groupe Vidéo et Communication. En 2003, il rejoint l’IRISA en tant qu’expert de recherche au sein de l’équipe TEMICS. Depuis 2005, il travaille comme ingénieur pour le Département Recherche et Développement de Thomson. Parmi ses activités de recherche, on peut mentionner des travaux sur le codage vidéo, avec une prédilection pour l’estimation du mouvement, la scalabilité et le transcodage. Il participe notamment aux travaux de l’UIT et aux activités de normalisation MPEG. Dans ce cadre, il s’intéresse plus particulièrement au SVC.

42


Compression vidéo

Il reste encore des points à éclaircir : l

La DLNA (Digital Living Network Alliance – activités de normalisation des réseaux domestiques) n’a pas encore décidé si elle souhaite étudier la technologie SVC. Nous espérons qu’elle le fera, car les activités de normalisation dans le secteur des appareils grand public restent très insuffisantes. Comme la DLNA s’occupe des questions liées aux réseaux domestiques, elle serait en bonne position pour entreprendre de tels travaux. l TISPAN devrait examiner la question de savoir si et comment le SVC pourrait avoir un impact sur la prochaine génération d’architectures de réseau qu’elle met au point, notamment au niveau des flux entre les blocs fonctionnels, non seulement pour ce qui est du trafic du contenu, mais également du contrôle. l ATSC (États-Unis) et DMB (Corée) ont annoncé qu’ils travaillent sur le SVC, ou qu’ils l’ont inclus dans les exigences pour les fonctionnalités liées à la scalabilité.

6. Conclusions Le SVC semble être une technologie intéressante et prometteuse pour les services audiovisuels actuels et futurs, tout particulièrement dans les domaines suivants : l

l

l

l

l

l l

Vidéo à la demande, pour réduire les coûts liés à la génération de multiples formats de la même vidéo, notamment pour la gestion de la “longue traîne”. Mise en œuvre à grande échelle des services “premium” en TVHD (1080p/5060). Transmissions vidéo mobiles, afin d’assurer une meilleure continuité du service. Adaptation plus précise aux paramètres des installations domestiques, tels que les types d’écrans HD et la largeur de bande disponible sur le réseau. Qualité de l’expérience utilisateur (temps de passage d’une chaîne à l’autre, avance et retour en arrière rapides, etc.). Gestion dynamique de l’accès à la largeur de bande. Applications pour l’IPTV ouvert (sur internet).


Le SVC est une technologie qui pourrait permettre de fournir “le contenu n’importe quand et n’importe où”. Toutefois, des études supplémentaires doivent être réalisées afin d’évaluer plus précisément l’efficacité du SVC. Parmi ces études, on peut mentionner les suivantes : l

Autres évaluations visuelles, afin de pouvoir comparer le SVC à d’autres solutions possibles (diffusion simultanée, codage à descriptions multiples, transcodage). l Des séquences de référence et des vidéos sources à qualité maximale doivent être mises à disposition dans tous les formats médias usuels (CIF, QCIF, SDTV, HDTV, etc.). l Des évaluations visuelles devraient être à nouveau réalisées lorsque les codeurs optimisés seront à disposition. Il est en effet évident qu’il existe encore une importante marge d’amélioration. l Evaluation de la complexité des codeurs.

7. Références [1] Thomas Wiegand, Gary J. Sullivan, Gisle Bjontegaard and Ajay Luthra: Overview of the H.264/AVC Video Coding Standard IEEE Transactions on Circuits and Systems for Video Technology, Vol. 13, No. 7, pp. 560-576, July 2003. [2] Heiko Schwarz, Detlev Marpe and Thomas Wiegand: Overview of the Scalable Video Coding Extension of the H.264/AVC Standard IEEE Transactions on Circuits and Systems for Video Technology, Special Issue on Scalable Video Coding, Vol. 17, No. 9, pp. 1103-1120, September 2007, Invited Paper. [3] ITU-T Recommendation H.262 and ISO/IEC 13 818-2 (MPEG-2): Generic Coding of Moving Pictures and Associated Audio Information – Part 2: Video ITU-T and ISO/IEC JTC 1, 1994. [4] ISO/IEC 14 496-2 (MPEG-4 Visual Version 1): Coding of audio-visual objects – Part 2: Visual ISO/IEC, Apr. 1999. [5] Edouard Francois, Jérome Viéron and

Vincent Bottreau: Interlaced coding in SVC IEEE Transactions on Circuits and Systems for Video Technology, Vol. 17, No. 9, pp 1136-1148 September 2007. [6] EBU BPN 056: SAMVIQ – Subjective Assessment Methodology for Video Quality Report by EBU Project Group B/VIM (Video In Multimedia), May 2003. [7] F. Kozamernik, V. Steinman, P. Sunna and E. Wyckens: SAMVIQ – A New EBU Methodology for Video Quality Evaluations in Multimedia IBC 2004, Amsterdam, pp. 191 - 202. [8] N9577: SVC Verification Test Report ISO/IEC JTC 1/SC 29/WG 11, Antalya, TR - January 2007. [9] ITU-R Recommendation BT.500-11: Methodology for the Subjective Assessment of the Quality of Television Pictures Question ITU-R 211/11, Geneva, 2004. [10] TD 531 R1 (PLEN/16), Draft new ITU-T Rec. H.264 (11/2007) | ISO/IEC 1449610 (2008) Corrigendum 1: Advanced video coding for generic audiovisual services: Corrections and clarifications


43

Codecs de production HD

Test de codec de production

TVHD

Massimo Visca (RAI) 1 et Hans Hoffmann (UER) Groupe de projet P/HDTP de l’UER

Afin de répondre au besoin de systèmes de compression TVHD studio plus efficaces, des fabricants ont récemment présentés de nouveaux codecs TVHD studio. En 2007, un groupe de projet de l’UER a étudié ces codecs. Le présent article décrit la méthodologie utilisée pour les tests, et résume les résultats obtenus. Pour introduire la TVHD en Europe, il faut que les radiodiffuseurs renouvellent leurs équipements de production. Alors que les équipements TVHD faisaient naguère appel à des solutions sur bande, la production TVHD moderne repose sur des fichiers, selon une méthode non linéaire, non en temps réel (avec accès partagé par le biais de réseaux et de serveurs). Et surtout, cette production doit être d’un bon rapport coût/efficacité. Ces besoins constituent un défi pour le format de compression vidéo appliqué aux équipements de production TVHD conventionnels, notamment en ce qui concerne le compromis entre débit de données et niveau de qualité vidéo. Pour répondre à ces besoins, ce secteur d’activité propose plusieurs types de codecs pour la production TVHD conventionnelle. L’UER a donc décidé de tester ces codecs par l’intermédiaire de son groupe de projet P/HDTP (production de télévision haute définition). Pour ces tests, les entreprises suivantes ont fourni de nouveaux codecs : l l 1)

44

AVID (DNxHD); GVG/Thomson (Infinity J2K);

l l

Panasonic (AVC-I); Sony (XDCAM HD422).

Les anciens systèmes existants ont également été inclus dans les évaluations afin de comprendre les améliorations apportées par la nouvelle technologie par rapport aux anciens systèmes. Tous les tests effectués sur les nouveaux codecs ont été réalisés individuellement (c’està-dire sans tests comparatifs) avec chacun des produits des fabricants. Le programme des tests et les résultats obtenus ont fait l’objet d’une discussion entre le groupe de projet de l’UER et les fabricants. Les tests ont eu lieu entre le printemps et l’automne 2007. Ils ont été effectués par plusieurs grands Membres de l’UER du projet P/HDTP. Les tests de l’AVID ont été réalisés par l’IRT (Allemagne) ; ceux du GVG/ Thomson et de Sony par la RAI (Italie), et les tests de Panasonic par l’UER (Suisse) avec l’aide de la RTVE (Espagne). Un représentant du fabricant concerné était présent à chaque test, et lors des séances de visionnage de spécialistes suivantes.

Massimo Visca est le coordonnateur du projet et le responsable d’équipe des tests de codecs.

1. Portée des tests Les tests de codecs de l’UER se sont concentrés sur la qualité de l’image que produirait l’algorithme individuel de compression après un traitement multi-génération. Les performances des codecs ne représentent certes qu’une partie de l’ensemble des performances du matériel d’un enregistreur/serveur, d’un caméscope, d’une caméra, etc. Mais c’est un paramètre très important, notamment pour la TVHD, avec son exigence inhérente d’images de haute qualité. L’évaluation du codec multi-génération, en introduisant des décalages de pixels après chaque génération, simule la manière dont la chaîne de production affecte les images à la suite de phases de multicompression et de décompression. Pour la TVSD, la méthode convenue de tests multi-génération consistait à comparer visuellement les 1ère, 4e et 7e générations (y compris les décalages de pixels après chaque génération) avec l’image initiale, dans des conditions définies (écran vidéo de référence, réglages particuliers de l’environnement de visionnage et observateurs experts). La même méthode a été adaptée aux tests actuels de codec TVHD. En outre, une mesure objective (le PSNR) a été calculée pour donner des



indications de tendances générales des performances multi-génération des codecs individuels.

2. Algorithmes testés Les tests étaient destinés à étudier les performances de pratiquement tous les algorithmes de compression TVHD disponibles sur le marché ou en développement dans les laboratoires des fabricants. Le programme de tests incluait les algorithmes dits “anciens”, appliqués dans la plupart des systèmes largement utilisés depuis le début de la production TVHD, et les “nouveaux” algorithmes dont la commercialisation était prévue à court terme au moment des tests : lorsque le présent article a été rédigé, certains de ces algorithmes étaient alors commercialisés.

HDCAM

Débit binaire vidéo (Mbit/s) 116.64

Bits d’info 8

DVCPRO

100

8

100

8

HDCAM-SR

440

10

HDCAM@35

35

8

2.1. “Anciens” algorithmes Les principales caractéristiques des algorithmes de compression vidéo employés dans les “anciens” matériels sont récapitulées dans le tableau 1.

2.2. “Nouveaux” algorithmes Les nouveaux systèmes TVHD (AVID (DNxHD), GVG/Thomson (Infinity J2K), Panasonic (AVC -I) et Sony (XDCAM HD422) par ordre alphabétique) emploient des algorithmes de compression très divers en termes de débit binaire et de par les outils mathématiques utilisés pour la compression.

Souséchantillonnage 1440 Y 480 Cb /Cr 1440 Y 480 Cb /Cr 960 Y 480 Cb /Cr

Il convient de noter que le présent article ne donne, en ce qui concerne ces algorithmes, que les informations nécessaires à une compréhension globale de leur fonctionnement. Les tableaux qui suivent donnent des informations de base (débit binaire, bits d’information, etc.), mais pour obtenir des informations complètes, le lecteur se reportera à la bibliographie et à toutes les informations officielles fournies par les fabricants. Par ailleurs, il est utile de souligner que ces paramètres donnent certes des informations objectives quant aux ressources du système (telles que le rapport débit binaire/ capacité de stockage et largeur de bande du réseau), mais leur corrélation avec la qualité d’image disponible est bien plus difficile, voire impossible, à déterminer à partir de ceux-ci. C’est pourquoi le groupe P/HDTP a déployé de grands efforts pour tester la mise en œuvre réelle de ces algorithmes.

Compression

Format

Norme SMPTE SMPTE 367M-368M SMPTE 370M-371M

Basée sur DCT (Intra) Basée sur DV (Intra) Basée sur DV

1080i/25 1080p/25 1080i/25 1080p/25 720p/50

NO

MPEG-4 SP (Intra)

SMPTE 409-2005

1440 Y 720 Cb /Cr 4:2:0

MPEG-2 (GoP)

1080i/25 1080p/25 720p/50 1080i/25 1080p/25

Compression

Format

Basée sur DCT (Intra) Basée sur DCT (Intra) Basée sur DCT (Intra) Basée sur DCT (Intra) Basée sur DCT (Intra) Basée sur DCT (Intra)

1080i/25 1080p/25 720p/50

Norme SMPTE SMPTE VC-3 SMPTE VC-3 SMPTE VC-3 SMPTE VC-3 SMPTE VC-3 SMPTE VC-3

–

Tableau 1 – Algorithmes de compression vidéo employés dans les “anciens” matériels.

2.2.1. AVID (DNxHD) Nom DNxHD

DNxHD

DNxHD

Débit binaire vidéo (Mbit/s) 120

Bits d’info 8

Souséchantillonnage NON

115

8

NON

185

8

NON

175

8

NON

185

10

NON

175

10

NON

1080i/25 1080p/25 720p/50 1080i/25 1080p/25 720p/50

Tableau 2 – Paramètres du codec de compression vidéo AVID DNxHD


45


2.2.2. GVG/Thomson (Infinity J2K) Nom

Débit binaire vidéo (Mbit/s)

Bits d’info

Souséchantillonnage

Compression

Format

Infinity

50

10

NON

Ondelettes (Intra)

Infinity

75

10

NON

Ondelettes (Intra)

Infinity

100

10

NON

Ondelettes (Intra)

1080i/25 1080p/25 720p/50 1080i/25 1080p/25 720p/50 1080i/25 1080p/25 720p/50

Norme de compression JPEG2000

JPEG2000

JPEG2000

Tableau 3 – Paramètres du codec de compression vidéo GVG/Thomson

2.2.3. Panaso nic (AVC-I) Nom AVC-I

AVC-I

Débit binaire vidéo (Mbit/s) 54.272

Bits d’info

Souséchantillonnage 1440 Y 720 Cb /Cr 4:2:0 960 Y 480 Cb /Cr 4:2:0

Compression

Format

AVC (Intra)

1080i/25 1080p/25

54.067

10

AVC (Intra)

720p/50

Haut profil 10 Intra

111.820

10

NON

10

NO

AVC (Intra) AVC (Intra)

1080i/25 1080p/25 720p/50

Haut profil 4:2:2 Intra Haut profil 4:2:2 Intra

111.616

10

Norme de compression Haut profil 10 Intra

Tableau 4 – Paramètres du codec de compression vidéo Panasonic AVC-I

2.2.4. Sony (XDCAM HD422) Nom

Débit binaire vidéo (Mbit/s)

Bits d’info

Souséchantillonnage

Compression

Format

SMPTE standard

XDCAM HD50

50

8

NON

MPEG-2 GoP L=12 M=3

1080i/25 1080p/25 720p/50

–

Tableau 5 – Paramètres du codec de compression vidéo Sony MPEG-2

Cet algorithme utilise un long GoP (groupe d’images) avec L = 12 et M =3 , c’est-à-dire que la structure du GoP est IBBPBBPBBPBBI. Cette caractéristique a d’importantes implications sur les tests des performances multi-génération, comme on peut le voir en détail au paragraphe 3.2.3.

3. Méthodologie Afin d’évaluer les performances des divers algorithmes TVHD dans un environnement de production, on a utilisé l’approche très classique du test multi-génération (en

46

cascade). Cette méthode a été beaucoup utilisée dans tous les tests UER depuis l’introduction des algorithmes de compression dans l’environnement de production TVSD, en commençant par le Betacam numérique et en allant jusqu’aux systèmes IMX et DVCPRO les plus récents. Elle est considérée par la communauté des radiodiffuseurs comme étant une technologie fiable, capable de produire des résultats reproductibles et stables, facilement interprétables. La méthode repose simplement sur la performance de diverses phases de compression-décompression utilisant

l’algorithme testé, afin de simuler l’effet cumulatif des éléments introduits par l’algorithme de compression sur la qualité de l’image. Cette méthode était initialement conçue pour solliciter les équipements traditionnels à bandes, où chaque copie impliquait une phase de décompression et une phase de compression. On pourrait peut-être penser que cela ne reflète pas entièrement le processus de fonctionnement d’une future infrastructure basée sur la production informatique, où la nécessité d’effectuer des compressions en cascade pourrait être réduite. Néanmoins,



en considérant que dans le contexte actuel de production, la compression en cascade est encore courante, la méthode permet d’évaluer le niveau de qualité du système. On connaît bien l’évaluation des résultats utilisant cette méthode d’évaluation. Il a donc été convenu de continuer à l’utiliser pour l’analyse des performances des algorithmes de compression, mis en œuvre dans les matériels TVHD testés.

3.1. Sélection et filmage des séquences de test Le choix des séquences de test à utiliser est toujours très crucial ; même la recommandation UIT-R BT. 500, qui est le document de référence le plus important qui contient toutes les procédures relatives à l’évaluation de la qualité de l’image basée sur l’évaluation subjective, ne donne qu’une simple indication en spécifiant que les séquences doivent être “cruciales, mais pas trop”. On peut évidemment utiliser un choix déformé de séquences pour mener le test. La seule manière de résoudre ce problème est de sélectionner de très nombreux matériels afin d’inclure des séquences qui couvrent toutes les fonctions possibles en termes de : l

contenu haute fréquence (détails), description du mouvement, colorimétrie, contraste, etc. ; l tournage en intérieur et en extérieur ; l genres de contenu différents, à savoir objets naturels et artificiels, textures, teints de peau, etc.

Toutes les séquences ont été tournées en formats différents, à savoir 1080p/50, 1080i/25, 1080p/25 (avec et sans obturateur) et 720p/50, en faisant le maximum pour garantir les mêmes conditions d’éclairage et d’exposition. Note : L es séquences 1080p/50 ont été converties pour obtenir des versions 1080i/25 ou 720p/50 ; elles ne furent donc pas directement utilisées dans ces tests, mais elles constitueront une bibliothèque pour de futurs tests, et notamment le test comparatif du 1,5 Gbit/s actuel avec les futurs 3 Gbit/s.

Certaines séquences ont été choisies dans le matériel initialement tourné en un seul format TVHD. D’autres séquences ont été converties à partir d’un film ou rendues graphiques, voire même prises dans des archives en format PAL. Toutes ces séquences ont été converties dans les trois formats TVHD inclus dans les tests pour obtenir un ensemble plus étoffé de séquences de test, d’une durée de 10 secondes. Note : Toutes les précisions techniques concernant les équipements, les logiciels, etc., relatives au processus de conversion peuvent être obtenues, sur demande, auprès des auteurs.

S’agissant des formats 1080i/25 et 720p/50, 14 séquences d’une durée de 10 secondes chacune ont été enchaînées l’une après l’autre

(sans images grises ou noires incluses) afin de former un seul clip. S’agissant des formats 1080p/25 (obturateur ouvert), seules huit séquences d’une durée de 10 secondes chacune ont été enchaînées l’une après l’autre afin de former un seul clip. Le nombre de matériels de test utilisés, la diversité de leurs origines et les critères de sélection ont garanti que les tests étaient complets et officiellement corrects. Certaines images extraites des séquences sont présentées à la figure 1.

3.2. Chaîne autonome La “chaîne autonome” comprenait plusieurs processus de compression et de décompression en cascade du même algorithme ; on appelle généralement “génération” une paire de processus de compression et de décompression. Afin de simuler divers cas de production et d’étudier les diverses caractéristiques de l’algorithme testé, la chaîne peut inclure ou non un traitement entre chaque génération, tel qu’il l’est expliqué ci-après. Comme on l’a déjà mentionné, chaque algorithme testé a été soumis à un traitement multi-génération jusqu’à la septième génération.

3.2.1. Chaîne autonome sans traitement La chaîne autonome sans traitement se composait simplement de plusieurs

Il est en outre mieux qu’au moins une partie du matériel testé soit neuf, afin d’éviter toute sorte d’optimisation du nouvel algorithme de compression utilisant des séquences connues. On ne disposait pas d’une bibliothèque en tant que telle lors des tests. Il a donc été nécessaire de filmer des séquences totalement nouvelles. Le tournage a été effectué en utilisant la technologie la plus récente (lentille Canon Série FJS, caméra Sony HDC 1500 et stockage sans compression sur un serveur DVS via HD-SDI). Cela a donné un grand nombre de séquences de test, chacune d’une durée de 10 secondes, ce qui répondait aux critères susmentionnés.


Figure 1 – Images extraites de quatre des séquences test utilisées

47


générations en cascade du codec testé, sans modification du contenu de l’image, autre que celles appliquées par le codec testé (voir le résumé à la figure 2). Ce processus simule avec précision l’effet d’un simple doublage de séquence, et il ne sollicite généralement pas beaucoup l’algorithme de compression. En fait, l’impact le plus important sur la qualité de l’image devrait se produire à la première génération lorsque le codeur doit éliminer certaines informations, mais l’effet sur les générations suivantes devrait être minime car le contenu doit pratiquement éliminer les mêmes informations que celles qui ont été supprimées lors de la première génération. Toutefois, cette chaîne simple peut fournir des informations utiles sur la performance du filtrage du sous-échantillonnage employé, ou bien sur la précision de l’application mathématique du code.

3.2.2. Chaîne autonome avec traitement Dans une chaîne de production réelle, l’image subit plusieurs manipulations pour produire le master. Parmi ces manipulations figurent le montage, le zoom, le montage non linéaire (LNE) et la correction des couleurs. Une simulation réaliste doit donc tenir compte de cela. Étant donné que tous ces processus sont actuellement uniquement réalisables dans un cadre sans compression, l’effet du traitement est simulé en décalant l’image horizontalement (pixels) ou verticalement (lignes) entre chaque étape de compression, comme le résume la figure 3. Ce décalage rend évidemment la tâche du codeur plus complexe, notamment en ce qui concerne les algorithmes reposant sur une division de l’image en blocs (tels que le bloc NxN DCT), car dans toute génération ultérieure, le contenu de chaque bloc est différent de celui de la génération précédente. Les décalages ont été diversement appliqués en utilisant le logiciel ou le matériel, mais la méthode employée était exactement la même pour tous les algorithmes testés. Le tableau 6 récapitule les décalages, et le processus est résumé à la figure 4. Pour le décalage horizontal (H), un décalage positif signifie un déplacement vers la droite,

48

F ra m e N u m b e r

n

n +1

n +2

n +3

n +4

n +5

n +6

n +7 n + 8 n +9 n +1 0 n +11 n +1 2

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

O rig in a l S e q u e n c e C o m p re s s io n & D e c o m p re s s io n F irs t G e n e ra tio n C o m p re s s io n & D e c o m p re s s io n S e c o n d G e n e ra tio n C o m p re s s io n & D e c o m p re s s io n T h ird G e n e ra tio n

(T he process continues up to the seventh generation) C o m p re s s io n & D e c o m p re s s io n

I

I

I

I

I

I

I

I

I

I

I

S e v e n th G e n e ra tio n

Figure 2 Chaîne autonome (sans décalage spatial) pour le codec INTRA


n

n +1

n +2

n +3

n +4

n +5

n +6

n +7 n + 8 n +9 n +1 0 n +11 n +1 2

I

I

I

I

I

I

I

I

I

I

I

I

I

S

S

S

S

S

S

S

S

S

S

S

S

S

I

I

I

I

I

I

I

I

I

I

I

I

I

S

S

S

S

S

S

S

S

S

S

S

S

S

I

I

O rig in a l S e q u e n c e C o m p re s s io n & D e c o m p re s s io n F irs t G e n e ra tio n S p a tia l S h ift F irs t G e n . w ith O N E S p a tia l S H IF T C o m p re s s io n & D e c o m p re s s io n S e c o n d G e n . W ith O N E S p a tia l S H IF T S p a tia l S h ift S e c o n d G e n . w ith T W O S p a tia l S H IF T


I

I

I

I

I

I

I

I

I

I

I

S e v e n th G e n . W ith S IX S p a tia l S H IF T

Figure 3 Chaîne autonome (avec décalage spatial) pour le codec INTRA

et un décalage négatif, un déplacement vers la gauche. Les décalages effectués sont tous pairs pour tenir compte du sous-échantillonnage chromatique du format 4:2:2. Pour le décalage vertical (V), un décalage positif signifie un déplacement vers le bas, et un décalage négatif, un déplacement vers le haut. Le décalage est appliqué sur une image et il a toujours une valeur paire. En ce qui concerne les formatifs progressifs, l’ensemble de l’image est décalé d’un nombre de lignes

correspondant au décalage vertical appliqué, alors que dans le cas des formats entrelacés, chaque trame est décalée d’un nombre de lignes correspondant à la moitié du décalage appliqué. Ainsi, un décalage égal à +2V signifie deux lignes vers le bas en format progressif et 1 ligne vers le bas pour chaque trame d’un format entrelacé. Le processus de décalage introduit des pixels noirs sur les bords de l’image si besoin est, ou quand il le faut.



Décalage entre

3.2.3. Chaîne autonome pour les algorithmes à base de GoP

Décalage spatial

1ère et 2e générations 2e et 3e générations 3e et 4e générations 4e et 5e générations 5e et 6e générations 6e et 7e générations

+4H et +4V +2V –2H –2H –2V –4V

Tableau 6 – Décalage spatial (vertical et horizontal) appliqué entre chaque génération

O rig in a l F ra m e 1920 x 1080

S h ifte d F ra m e 1920 x 1080 B la c k lin e s in s e rte d

S H IF T + 150H + 100 V S H IF T - 150H - 100 V

B la c k p ix e ls in s e rte d

C ro p p e d a re a

In th is exam p le th e sh ift is exag g erated (150 p ixels an d 100 lin es) to m ake evid en t th e in tro d u ctio n o f b lack p ixels an d lin es an d th e cro p p in g o f th e im ag e o n th e b o rd ers.

Figure 4 Processus de décalage dans la chaîne autonome


n

n +1

n +2

n +3

n +4

n +5

n +6

n +7 n + 8 n +9 n +1 0 n +11 n +1 2

I

B

B

P

B

B

P

B

B

P

B

B

I

I

B

B

P

B

B

P

B

B

P

B

B

I

I

B

B

P

B

B

P

B

B

P

B

B

I

B

I

O rig in a l S e q u e n c e C o m p re s s io n & D e c o m p re s s io n F irs t G e n e ra tio n C o m p re s s io n & D e c o m p re s s io n S e c o n d G e n . W ith G O P A lig n m e n t C o m p re s s io n & D e c o m p re s s io n T h ird G e n . W ith G O P A lig n m e n t


I

B

B

P

B

B

P

B

B

P

B


Figure 5 Chaîne autonome avec alignement du GoP (sans décalage spatial) pour le codec INTER


Comme le montre la figure 5 de la page 4, le système XDCAM HD50 exploite les outils de compensation de mouvement MPEG-2, et notamment un codage GoP long avec L=12 et M=3 (c’est-à-dire IBBPBBPBBPBBI) ; même si chaque codeur MPEG-2 applique une stratégie assez complexe pour attribuer ses ressources en débit binaire à divers types d’images, tous les algorithmes MPEG-2 garantissent généralement la meilleure qualité pour l’image intra (I), une qualité réduite de l’image prévue (P) et, de la même manière, une qualité encore moindre pour l’image bidirectionnelle (B). Par conséquent, la structure GoP a des implications importantes sur la manière dont la chaîne autonome doit être réalisée, et elle introduit une variable supplémentaire dans la manière dont la multi-génération peut être effectuée, selon que l’alignement GoP est garanti entre chaque génération (alignement du GoP) ou non (non-alignement du GoP). Comme il l’est expliqué dans la figure 5, le GoP est considéré comme étant aligné, si une image de l’image originale qui est codée à la première génération à l’aide de l’un des trois types possibles d’images (intra, prévue ou bidirectionnelle) est une nouvelle fois codée en utilisant le même type d’image dans toutes les générations suivantes : si l’image n, par exemple, de la séquence originale est toujours codée comme étant intra, et si l’image n + 6 est codée comme étant Prévue. Il est par conséquent possible de n’avoir qu’une seule chaîne multigénération avec “l’alignement du GoP”. En revanche, si cette condition n’est pas garantie, plusieurs conditions de nonalignement du GoP sont possibles ; en prenant la longueur de GoP L = 12, 11 nonalignements du GoP sont possibles pour la deuxième génération, puis 11 fois 11 pour la troisième génération et ainsi de suite, ce qui rend irréaliste le test de toutes les conditions possibles. Il a donc été convenu d’appliquer un “décalage temporel” égal à une image entre chaque génération, comme il l’est expliqué dans la figure 6, de sorte que l’image qui est codée en mode intra à la première génération, soit codée en mode bidirectionnel dans la deuxième génération et, de manière

49


générale, dans un mode différent pour chaque génération suivante. Il est intéressant de souligner que l’alignement du GoP des différentes générations était contrôlé (et non aléatoire) et que c’était considéré comme étant vraisemblablement le pire des cas en ce qui concerne l’effet de non-alignement. Ce phénomène a été qualifié de “chaîne sans alignement GoP” dans les documents. En tenant aussi compte de la nécessité de simuler l’effet de la manipulation au moyen du décalage spatial, il a été convenu, pour le système à base de GoP (XDCAM HD50), d’envisager et de réaliser quatre chaînes autonomes différentes possibles jusqu’à la septième génération, de la manière suivante : l

l

l

l

Chaîne multi-génération avec alignement GoP (sans décalage spatial) (voir figure 5). Chaîne multi-génération sans alignement GoP (sans décalage spatial) (voir figure 6). Chaîne multi-génération avec alignement GoP ET décalage spatial (voir figure 7). Chaîne multi-génération sans alignement GoP ET décalage spatial (voir figure 8).

Toutes les chaînes susmentionnées ont été réalisées sur les anciens et les nouveaux systèmes. Les séquences résultantes ont toutes été mémorisées en format YUV 10 bits. Note : Pour la chaîne XDCAM @35, il n’a pas été possible de contrôler l’alignement GoP, et cette multi-génération a donc dû être considérée comme étant “aléatoire” en termes d’alignement GoP.

Les tests sur le codec AVID DNxHD ont été effectués par l’IRT, les tests sur le codec GVG/Thomson par la RAI avec une caméra prototype Infinity, les tests sur le codec Panasonic AVC-I par l’UER avec un codeur prototype, et les tests sur le codec Sony XDCAM HD50 par la RAI avec un codeur prototype. Les ingénieurs des fabricants respectifs ont assisté aux tests au moins la première journée, pour s’assurer du bon fonctionnement de leur équipement.

50


n

n +1

n +2

n +3

n +4

n +5

n +6

n +7 n + 8 n +9 n +1 0 n +11 n +1 2

I

B

B

P

B

B

P

B

B

P

B

B

I

B

I

B

B

P

B

B

P

B

B

P

B

B

B

B

I

B

B

P

B

B

O rig in a l S e q u e n c e C o m p re s s io n & D e c o m p re s s io n F irs t G e n e ra tio n C o m p re s s io n & D e c o m p re s s io n S e c o n d G e n . W ith G O P A lig n m e n t C o m p re s s io n & D e c o m p re s s io n T h ird G e n . W ith G O P A lig n m e n t

C o m p re s s io n & D e c o m p re s s io n

P

B

B

P

B

B

P

(T he process continues up to the seventh generation) P

B

B

P

B

B

I

B

B

P

B


Figure 6 Chaîne autonome sans alignement du GoP (sans décalage spatial) pour le codec INTER


n

n +1

n +2

n +3

n +4

n +5

n +6

n +7 n + 8 n +9 n +1 0 n +11 n +1 2

I

B

B

P

B

B

P

B

B

P

B

B

I

S

S

S

S

S

S

S

S

S

S

S

S

S

I

B

B

P

B

B

P

B

B

P

B

B

I

S

S

S

S

S

S

S

S

S

S

S

S

S

B

I



I

B

B

P

B

B

P

B

B

P

B


Figure 7 Chaîne autonome avec alignement du GoP ET avec décalage spatial pour le codec INTER

4. Analyse des performances des algorithmes L’analyse des performances des algorithmes a été effectuée au moyen de mesures objectives (PSNR) et par un examen visuel de l’image (à savoir visionnage par un spécialiste), tel qu’il l’est décrit ci-après. Ces deux méthodes donnent des genres d’information différents, et elles sont considérées comme étant complémentaires.

4.1. Mesures objectives Le PSNR a été calculé par un logiciel et on lui a évidemment appliqué une procédure pour rétablir l’alignement spatial entre la version originale et la version décompressée de la séquence de test. Il a en outre sauté 16 pixels sur les bords de l’image afin d’éviter de prendre des mesures sur les pixels noirs introduits pendant le décalage. La formule utilisée pour évaluer le PSNR par l’intermédiaire du logiciel était la suivante :




n

n +1

n +2

n +3

n +4

n +5

n +6

n +7 n + 8 n +9 n +1 0 n +11 n +1 2

I

B

B

P

B

B

P

B

B

P

B

B

I

S

S

S

S

S

S

S

S

S

S

S

S

S

B

I

B

B

P

B

B

P

B

B

P

B

B

S

S

S

S

S

S

S

S

S

S

S

S

S

B

P



P

B

B

P

B

B

I

B

B

P

B


Figure 8 Chaîne autonome sans alignement du GoP ET avec décalage spatial pour le codec INTER

pas officiellement dans une recommandation de l’UIT, elle est très souvent utilisée, car elle donne des résultats rapides et cohérents. L’appellation générique de “visionnage par spécialiste” comporte plusieurs types d’analyses de l’évaluation de la qualité de l’image.

où: ori (i,j) = l’image originale, cod(i,j) = l’image manipulée, Ncol = la résolution horizontale en pixels, Nlin = la résolution verticale en pixels et Vpeak = 210 – 1 = 1023.

Compressed (Impaired) version (e.g. Seventh generation with spatial shift)

Aux fins de ces tests P/HDTP, il a été convenu d’avance avec les fabricants d’utiliser l’interprétation suivante de ce que comporterait le “visionnage par spécialiste”. Toutes les séquences (d’images originales et celles soumises à compression) ont été mémorisées sous forme non comprimée (format YUV10) sur deux serveurs vidéo qui pouvaient fonctionner en parallèle. Les séquences étaient visualisées simultanément verticalement sur un écran divisé en deux parties (les images originales d’un côté, et les images soumises à compression de l’autre côté) Pendant le visionnage, la barre T du mixeur qui partageait l’écran (un Panasonic type AV-HS300) a été déplacée pour comparer les mêmes zones de versions différentes des mêmes séquences, comme on l’a jugé nécessaire. La position de la séparation a été rendue plus visible en appliquant une barre verticale blanche juste perceptible à la séparation des deux images (un exemple réel est présenté à la figure 9). La distance de visionnage a été marquée sur le sol. Elle était fixée à 3 H, H étant la dimension verticale de l’écran. Les observateurs ont été

vs.

Ori_B (Original 4:2:2)

Les résultats sont exprimés en dB. Il est bien connu que le PSNR n’est pas précisément en corrélation avec la qualité de l’image et il serait donc inexact de comparer directement le PSNR provenant d’algorithmes différents. En revanche, ce paramètre peut donner des informations sur le comportement de l’algorithme de compression lors du processus multi-génération.

4.2. Visionnage par spécialiste L’analyse de la performance de l’algorithme (du point de la qualité de l’image) a été effectuée en faisant appel au visionnage dit de spécialiste. Même si cette méthode ne figure


T-bar line T-bar m ovem ent Figure 9 Chaîne autonome avec alignement du GoP ET avec décalage spatial pour le codec INTER

51


priés de respecter cette distance. On a parfois utilisé une distance plus courte, telle que 1 H, pour observer de près de petits détails. Lorsqu’on a utilisé cette distance, cela a clairement été signalé dans le rapport. Il conviendrait de clarifier que cette méthode permet l’évaluation de très petits affaiblissements, proches du seuil de visibilité, et qu’elle doit être considérée comme une analyse très stricte de la qualité de l’image. Comme on l’a mentionné, les tests se concentraient sur la performance des algorithmes, aux première, quatrième et septième générations, en comparant la qualité de l’image à l’original (évaluation de niveau), ou à l’ancien système (amélioration apportée par le nouveau système). Une liste des tests qui résumait, sous forme de tableaux, toutes les diverses comparaisons planifiées, a été préparée et discutée auparavant. Chaque spécialiste a reçu une copie papier de la liste des tests, de manière à toujours savoir parfaitement quelle séquence était présentée sur chaque partie de l’écran. Dans le cas d’une comparaison, par exemple, entre la séquence de l’”original” et la version soumise à sept générations d’algorithme “A”, comprenant un décalage spatial entre chaque génération, le spécialiste avait reçu le tableau suivant :

Il a été expressément demandé à tous les spécialistes de s’abstenir de faire des commentaires au cours des sessions, afin d’éviter d’influencer les autres personnes.

4.2.1. Écrans

Ce n’est qu’après l’analyse complète de la séquence de test (pendant toute sa durée) qu’une discussion était entamée pour résumer en quelques phrases l’avis des divers spécialistes. Il était parfois impossible de parvenir à un consensus sur l’analyse visuelle d’une séquence. Dans ce cas, la séquence en question était réitérée. Si alors un consensus était tout de même impossible, cette situation était notée dans le rapport.

l

Écran cathodique Sony 32 pouces type BVM-A32E1WM

l

Écran cathodique Sony 20 pouces type BVM-A20F1M

l

Écran plasma Full HD 50 pouces type TH50PK9EK Panasonic

l

Écran LCD 47 pouces type Focus.

Tous les efforts possibles ont été faits pour garantir que le panel de spécialistes comprenne les mêmes personnes pendant les diverses séances de visionnage ; cette condition était aisément remplie pendant chaque journée et presque parfaitement pendant les différentes journées. Une journée de visionnage était consacrée à chaque fabricant, et les représentants du fabricant en question y participaient également.

Les écrans étaient connectés par des interfaces HD-SDI. Ils étaient alignés dans les conditions décrites dans l’UIT-R BT.50011, et les conditions de la salle étaient fixées en conséquence.

Les résultats des visionnages ont été recueillis dans une série de documents UER BPN, à savoir BPN 076 (résultats relatifs à l’Avid DNxHD), BPN 077 (résultats relatifs au GVG/Thomson JPEG2000), BPN 078

Version compressée (affaiblie) (septième génération avec décalage spatial, par exemple)

par rapport à

Ori_A (original 4:2:2)

Rapport : perte due à sept générations avec traitement postérieur

Le spécialiste savait que “A” signifiait un fabricant spécifique et il avait reçu tous les détails concernant chaque condition de test (débit binaire, GoP aligné ou non, etc.). Le tableau incluait également une courte phrase décrivant la raison d’être du test et, afin d’éviter tout malentendu, la position (à droite ou à gauche) des séquences était la même sur le tableau papier que sur l’écran, à savoir la séquence originale à droite et la séquence traitée à gauche dans le tableau ci-dessus.

52

(résultats relatifs au Panasonic AVC-I) et BPN 079 (résultats relatifs au Sony XDCAM HD50). Ces documents sont publiés par l’UER et sont exclusivement réservés aux Membres de l’UER. Le lecteur doit être conscient qu’en raison de la complexité et du cadre des tests, seule une analyse approfondie de ces documents peut donner une appréciation complète des résultats.

Au cours des tests, les écrans suivants ont été utilisés :

L’évaluation finale a toujours été faite en considérant la qualité perçue sur les écrans cathodiques. Il a néanmoins été généralement reconnu que les écrans plats, tant LCD que plasma, agrandissaient les affaiblissements.

5. Résultats Il a été convenu, entre le groupe de projet de l’UER et les fabricants, d’établir des comptes rendus des détails des tests, uniquement à disposition des Membres de l’UER. À la fin de l’année 2007, les résultats des tests ont été publiés dans les documents BPN076 à BPN079, comme on l’a indiqué précédemment. Note : En raison de l’importance du sujet, les fabricants et l’UER ont convenu de fournir des résultats préliminaires par le biais d’une présentation PowerPoint faite lors de la conférence de l’IBC 2007, avant de mettre les rapports BPN proprement dit, à la disposition des Membres de l’UER. Cette présentation PowerPoint contenait un bref résumé des résultats des tests sous forme de tableaux. Les rapports BPN076 à BPN079 publiés contiennent un



cadre beaucoup plus large des conditions de test que celui présenté dans la présentation PowerPoint de l’IBC 2007. Il est à noter que ni les rapports des tests, ni la présentation PowerPoint ne sont destinés à des études comparatives et qu’ils ne s’y prêtent pas. Les tableaux de la présentation PowerPoint n’incluaient pas d’informations sur la question de savoir si les tests avaient été effectués avec ou sans décalage de pixels.

Le Comité PMC de gestion de la production de l’UER a ensuite conclu dans une recommandation (UER R124-2008)2 que :

Pour les applications d’acquisition en format TVHD avec échantillonnage 4:2:2,

longs GoP, le débit binaire ne doit pas être inférieur à 50 Mbit/s. En outre, les tests de visionnage par spécialiste ont révélé que : l

Dix bits d’information en production, ce n’est important que pour la postproduction avec des graphiques et après le codage et décodage de transmission à l’extrémité consommateur si le contenu (graphiques ou animation, par exemple) a été produit à l’aide d’une graduation avancée des couleurs, etc. l S’agissant des images normales en mouvement, 8 bits d’information en production ne dégraderont pas substantiellement la qualité de l’image HD chez le consommateur.

Remerciements Les auteurs adressent leurs remerciements à Giancarlo De Biase (RAI), Dagmar Driesnack (IRT), Adi Kouadio (UER) et Damian Ruiz Croll (RTVE) pour le travail considérable qu’ils ont effectué lors des tests des codecs.


il convient de ne pas appliquer d’autres sous-échantillonnages horizontaux ou verticaux. Huit bits d’information suffisent pour les programmes

6. Bibliographie

généraux, mais 10 bits sont mieux pour des acquisitions supérieures. Pour des applications de production de HD courante, les tests de l’UER n’indiquent aucune raison d’assouplir l’exigence relative aux codecs de studio SDTV, selon laquelle il faut conserver une “qualité quasi-transparente” après 7 cycles de codage et recodage, avec application de décalages horizontaux et verticaux de pixels. Tous les codecs testés présentent une qualité quasi-transparente jusqu’à au moins 4 ou 5 multi-générations. Ils présentent toutefois aussi quelques défauts tels que le bruit ou la perte de résolution avec des images critiques à la 7e génération. C’est pourquoi il est demandé aux Membres de l’UER de concevoir soigneusement le processus de production et d’éviter 7 phases de multi-génération.

Dans le document R124-2008, l’UER recommande que : l

Si le format de production/archivage doit reposer uniquement sur des images I, le débit binaire ne doit pas être inférieur à 100 Mbit/s. l Si le format de production/archivage doit reposer sur des images MPEG-2 à 2)

[1] UIT-R BT.500-11 : Méthodologie d’évaluation subjective de la qualité des images de télévision, UIT-R Genève, 2003. [2] UIT-R BT.709-5 : Valeurs des paramètres des normes de TVHD pour la production et l’échange international de programmes, UIT-R Genève, 2002. [3] SMPTE 296M : 1280 x 720 Scanning, Analogue and Digital Representation and Analogue Interface, SMPTE New York, 2001. [4] SMPTE 292M : Bit-Serial Digital Interface for High-Definition Television Systems, SMPTE New York, 1998. [5] SMPTE 274M : 1920 x 1080 Scanning and Analogue and Parallel Digital Interfaces for Multiple Picture Rates, SMPTE New York, 1998. [6] Sony : http://www.sonybiz.net puis chercher XDCAM-HD 422. [7] Panasonic : http://www.panasonic. com/business/provideo/p2-hd/ white-papers.asp [8] Avid : http://www.avid.com/dnxhd/ [9] Thomson Grass Valley : http:// thomsongrassvalley.com/products/ infinity/

R124-2008: http://tech.ebu.ch/docs/r/r124.pdf


53

WEBCASTING

Portail médias

P2P de l’UER Franc Kozamernik Ingénieur senior, UER

Le portail médias P2P de l’UER (EBUP2P) est un outil de démonstration qui a été mis au point pour les Membres de l’UER souhaitant diffuser leurs programmes TV et radio dans le monde entier. Un essai de six mois a été organisé par le Groupe de projet UER D/P2P au cours du premier semestre 2008, afin d’évaluer la technologie P2P (Peer-to-Peer / pair-à-pair) grâce au service mis à disposition par l’entreprise Octoshape. Le présent article décrit les conclusions auxquelles cet essai a permis d’aboutir. Le Groupe de projet UER D/P2P (Peer-toPeer), présidé par Frank Hoffsümmer (SVT) et créé en 2006, a pour mission :

l

l

Le séminaire organisé à Genève en février 2006 par le Département technique de l’UER a réuni un grand nombre de participants, ce qui a permis de constater que les Membres de

d’évaluer les nouvelles technologies pairà-pair ; l de formuler des normes UER pour de tels systèmes ;

de réaliser des études techniques et des essais sur un système P2P déjà en fonction.

l’Union sont très intéressés par cette nouvelle technologie. Par ailleurs, la forte participation au séminaire a conforté le Groupe dans sa mission. L’idée de créer un portail médias UER a été avancée par le Groupe D/P2P lors de sa réunion de juin 2007. Le Groupe a proposé

En quoi consiste la technologie pair-à-pair (P2P) ? Dans le présent article, le P2P est considéré comme un système de distribution de médias qui se sert des ordinateurs des utilisateurs finaux pour transmettre le contenu par le biais des réseaux informatiques existants.Le système P2P n’a rien à voir avec Napster ou le partage illicite de contenus. Bien au contraire, le P2P offre aux radiodiffuseurs une solution intéressante pour distribuer efficacement leurs contenus sur Internet. La technologie P2P ne nécessite pas la mise en place d’une infrastructure d’émission spécifique. Par conséquent, les investissements et les coûts de maintenance sont bien inférieurs à ceux de réseaux de distribution de contenu (Content Distribution Networks - CDN) qui peuvent utiliser plusieurs milliers de serveurs spécifiquement destinés au streaming. En outre, le P2P n’a pas un seul point de panne, ce qui permet de proposer un service extrêmement fiable. Toutefois, le P2P est une technologie assez récente, pour laquelle il sera nécessaire de réaliser encore un grand nombre d’études. Il faudra également acquérir une certaine expérience pratique avant de pouvoir l’utiliser à des fins commerciales.

54


WEBCASTING

aux Membres de se réunir et de créer un portail Internet commun, grâce auquel les programmes TV et radio des Membres pourraient être mis à disposition du grand public, partout dans le monde. Le portail, s’il devait être ouvert de manière permanente et prendre la forme d’un projet UER commun sans but commercial, pourrait être bien plus qu’un simple projet novateur et à la pointe de la technique. Il pourrait devenir une sorte de “guichet unique”, permettant de mettre en valeur les réalisations des Membres dans le domaine des programmes. Avant l’arrivée du P2P, les Membres de l’UER utilisaient différentes approches client serveur, telles que les CDN, la diffusion par IP et une grande variété de solutions propriétaires pour le streaming, mises au point par Microsoft, Real Networks ou QuickTime. Une caractéristique commune de ces systèmes est qu’ils sont tous relativement chers. En effet, les radiodiffuseurs doivent rétribuer les fournisseurs de services Internet pour chaque flux connecté, c’est-àdire pour chaque utilisateur. Ainsi, plus les utilisateurs sont nombreux, plus les coûts générés par les fournisseurs de services Internet sont élevés. Les frais encourus par les radiodiffuseurs sont donc proportionnels au succès de leurs programmes. Par exemple, en 2005, le Concours Eurovision de la Chanson a été distribué sur Internet au

TV TV TV TV TV TV TV TV TV Radio Radio Radio Radio Radio Radio Radio

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

moyen d’un système CDN dont le support était assuré par Akamai. Ce programme étant très populaire, il a suscité beaucoup d’intérêt partout dans le monde (plusieurs dizaines de milliers d’internautes). On a calculé que le coût du streaming vidéo pour cet événement a été d’environ 1 CHF par utilisateur et par heure, ce qui équivaut approximativement à CHF 100’000 (€ 65’000) pour la totalité du programme (trois heures). La technologie P2P pourrait changer radicalement cette situation. Des images vidéo peuvent être distribuées par un système P2P pour un coût inférieur à € 0,05 par GB1. Compte tenu de la concurrence exercée par le P2P, les coûts des services CDN ont également baissé de manière significative. Ils restent toutefois bien supérieurs à ceux des systèmes P2P. Hormis leur coût, les technologies P2P présentent de nombreux avantages par rapport aux autres systèmes de distribution Internet : aucun ensemble de serveurs de streaming n’est nécessaire, il n’y a donc pas de point de panne central (pour autant que l’on utilise un traqueur décentralisé et distribué). Cependant, le P2P n’en est qu’à ses débuts et il reste de nombreux obstacles à surmonter. La création de l’EBUP2P n’est que le premier pas d’un processus visant à acquérir de l’expérience avec cette

technologie et à résoudre les éventuels problèmes liés au P2P.

Exigences relatives à un système de distribution des médias sur Internet Quel que soit le système de distribution sur Internet, il doit répondre à plusieurs exigences pour satisfaire les radiodiffuseurs : l

faible coût de distribution (dans l’idéal, il doit être indépendant du lieu, de l’heure, de la qualité et du nombre d’utilisateurs) ;

l

distribution fiable (pas de pannes ou d’interruptions de service, latence point à point raisonnable, changement de chaîne rapide) ;

l

grande qualité en définition normale et en haute définition (le cas échéant, en audio multicanal);

l

importante capacité au niveau des canaux (en principe, il n’y a pas de contraintes liées au spectre, c’est le cas pour la radiodiffusion traditionnelle) ;

l

nombre d’utilisateurs simultanés aussi élevé que possible (des tests ont été réalisés avec plusieurs centaines de milliers d’utilisateurs).

Chaîne

Organisme

URL

HR DW - TV TV SLO 1 TV SLO 2 24H tve DOCU tve TV Ciencia on-line iTVP Taiwan TV radio-suisse jazz radio-suisse pop radio 3 radio classica youfm

Hessischer Rundfunk (HR) Deutsche Welle (DW) RTV Slovénie (RTVSLO) RTV Slovénie (RTVSLO) RTV Espagne (RTVE) RTV Espagne (RTVE) TV Portugal TV polonaise (TVP)

www.hr-online.de www.dw-world.de www.rtvslo.si www.rtvslo.si www.rtve.es www.rtve.es www.tvciencia.pt www.itvp.pl

SRG-SSR SRG-SSR RNE RNE HR RTVSLO RTVSLO

www.srg-ssr.ch www.srg-ssr.ch www.rne.es www.rne.es www.hr-online.de www.rtvslo.si www.rtvslo.si

RSI Val 202

Commentaire

Suspendu Depuis mai 08 Depuis mai 08 Depuis juin 08 MP3, 192 kbit/s MP3, 192 WM, 96 WM, 128 MP3, 160 – jusqu’à fin avril 08

WM, 192 WM, 192

Tableau 1 – Membres participants aux essais du portail EBUP2P 1)

Sur son site, Octoshape annonce un prix de 2 centimes d’euro par GB (http://www.octoshape.com/)


55

WEBCASTING

L’essai P2P Afin que le projet reste gérable, il était nécessaire de limiter à une dizaine le nombre de Membres participants (voir Tableau 1). Le système P2P choisi pour cet essai a été mis à disposition par Octoshape. Il a fait l’objet d’un article dans une édition précédente de la Revue technique de l’UER2.

Brève description du portail Pendant l’essai, un logo très visible “Test du portail médias P2P” était affiché sur la page d’accueil de l’UER. En cliquant sur le logo, on pouvait accéder à la page d’accueil du portail3. N’importe quel utilisateur, partout dans le monde, avait accès au portail. La Figure 1 montre une des premières versions de la page d’accueil. Au cours de l’essai, la conception du portail Internet a été améliorée plusieurs fois, tant du point de vue graphique qu’au niveau de l’accessibilité et de la convivialité. La Figure 2 illustre la conception graphique actuelle du portail, réalisée par Nathalie Cullen du Service de la Communication de l’UER.

possibilité d’utiliser soit un lecteur intégré (qui est lancé automatiquement lorsque l’on ouvre la page), soit Windows Media Player (qui s’ouvre dans une fenêtre dont il est possible d’ajuster la taille).

l l l l l

Sous chaque logo, nous avons mis un lien vers l’URL du Membre, ce qui donne aux utilisateurs la possibilité de consulter la grille des programmes et d’avoir accès à des informations supplémentaires sur la chaîne/ station concernée. En bas de la page, nous avons placé un lien temporaire “Vos commentaires”, qui permettait aux internautes d’envoyer des messages et des commentaires. Pendant l’essai, nous avons reçu plus de cent commentaires de la part des utilisateurs, qui ont tous exprimé une opinion positive sur le service. Cette page contenait également des informations sur ce dont les utilisateurs avaient besoin pour accéder au contenu : l l

une connexion haut débit ; un PC équipé de Windows, Mac ou Linux ;

le navigateur Internet Explorer (IE) ou Firefox Active X (en cas d’utilisation de IE); Windows Media Player (vidéo et audio) ; un lecteur MP3 ; le plug-in d’Octoshape.

Le plan d’essais Avant de créer un portail médias UER opérationnel, il fallait identifier une technologie de distribution Internet adaptée et décider quels seraient les paramètres de fonctionnement. Un groupe d’essais techniques, composé de dix Membres de l’UER s’est réuni pour la première fois le 10 juillet 2007 à Genève, afin de définir les paramètres opérationnels et techniques basés sur la technologie pair-à-pair (P2P)4. Une fois ces paramètres définis, l’essai a pu être lancé officieusement en automne 2007, puis officiellement en janvier 2008. Il a duré six mois, jusqu’à fin juin 2008. La coordination du groupe d’essais a été assurée par l’auteur du présent document. Le Groupe a travaillé sous les auspices du Groupe D/P2P. Il s’est réuni à trois reprises afin de superviser

Chaque Membre participant est représenté par une icône identique à son logo. En haut, à droite de l’écran, huit icônes représentent les chaines TV. En dessous de ces icônes, six autres icônes représentant des stations de radio. Ce nouveau design donne aux internautes la

Figure 1 – Portail médias P2P de l’UER avec utilisation de Windows Media Player uniquement (crédit photo : Nathalie Cullen) 2) 3) 4)

56

Figure 2 – Forme finale du portail médias P2P de l’UER (crédit photo : Nathalie Cullen) utilisant soit Windows Media Player, soit un lecteur intégré au navigateur

Visitez : http://tech.ebu.ch/docs/techreview/trev_303-octoshape.pdf Le lien vers le portail médias est le suivant : http://www.ebu.ch/members/EBU_Media_portal_Trial_1.php La technologie P2P d’Octoshape a été sélectionnée sur la base de plusieurs tests comparatifs réalisés par le Groupe de projet D/P2P à l’occasion l’IBC 2006, mais également suite aux résultats obtenus lors des Concours Eurovision de la Chanson à partir de 2005, pour lesquels Octoshape a été utilisé avec succès.


WEBCASTING

Essai 1 2

3 4 5 6 7 8 9

10 11 12

Description

Accessibilité des contenus depuis le site Internet de l’UER Performance globale au niveau de la qualité (continuité et fiabilité) dans différentes conditions de réseau à large bande Extensibilité : 200 et 700 kbit/s Différents systèmes d’exploitation/ plateformes informatiques Différents navigateurs Géolocalisation (dynamique) Gestion des droits Statistiques concernant l’audience Publicité au début du flux (pre-roll)

Participants

Bon fonctionnement des liens, passage d’une chaîne à l’autre sans problèmes, un seul flux à la fois Capacité différente en amont et en aval, différentes charges du réseau (causant des pertes de paquets et une instabilité de l’image)

Tous

Nombre d’utilisateurs simultanés PC, Mac, Linux

Tous IRT

IE, Firefox, etc. Affichage de messages en cas d’indisponibilité des flux Différents systèmes DRM, notamment MS DRM et DVB CPCM Disponibilité immédiate des données pour chaque radiodiffuseur Octoshape insère un maximum de 3 annonces publicitaires au début de chaque flux. Le contenu des annonces devrait être décidé d’un commun accord avec le propriétaire de la chaîne et Octoshape Intégration d’environ 100 bit/s En plus de WM, nous devrions tester le codec Flash Lecture de fichiers vidéo à la demande

Watermarking audio a Codec Flash a Livraison à la demande a

Tableau 2 – Essais techniques prévus

Doit être testé lors de la deuxième phase du projet (pour autant qu’un accord soit trouvé avec Octoshape)

le développement et surveiller la qualité technique du portail.

d’annonces publicitaires au début des flux vidéo demandés (pre-roll), etc.

L’objectif principal de cet essai était de déterminer si la technologie P2P d’Octoshape constitue une plateforme efficace et fiable pour le streaming en direct des services radio et télévision des Membres. Nous avons saisi cette occasion pour réaliser quelques essais pour des services annexes tels que la conception graphique et l’accessibilité du portail (principalement afin de déterminer comment les utilisateurs accèdent au site et changent de chaîne - zapping), le codage vidéo, la géolocalisation, l’introduction

Sur la base du système et des exigences susmentionnés, un plan d’essais a été mis au point. Les détails figurent dans le Tableau 2.

Spécifications techniques de l’essai Les paramètres techniques convenus pour les flux audio et vidéo figurent au Tableau 3.

Octoshape Octoshape s’est chargée des opérations suivantes : l

l

Débit

Format et résolution

MS Windows Media

environ 700 kbit/s

4:3 480 x 360 px; 16:9 520 x 360 pixels

l

Stéréo/Mono

l

Audio Débit 64 kbit/s

Codec MS Windows Media 9

Bitrate 96/128/192 kbit/s

Mpeg Layer 3

192 kbit/s

48 kHz, stéréo (A/V) CBR 1 passe

Stereo/Mono 44.1/48 kHz, stereo (A/V) CBR 1 passe

Tableau 3 – Paramètres techniques utilisés pour le portail médias P2P de l’UER


?

Les organismes participants ont été chargés d’un certain nombre de tâches en vue de la réalisation du projet.

Distribution par Internet : P2P et HTTP.

Audio Radio

? ?

Répartition du travail

Codec

Codec MS Windows Media 9

IRT ? ? Tous, UER HR, TVP

a)

Vidéo

Télévision

Tous

l

l

mise à disposition des informations nécessaires, pour que les Membres de l’UER puissent coder leurs flux en WM ; mise à disposition du logiciel Source Signal Solution (SSS) d’Octoshape afin que les Membres puissent coder leur matériel ; réalisation du codage à la demande des Membres (codage réalisé par Octoshape elle-même ou par un tiers). mise à disposition des informations nécessaires pour que les Membres puissent envoyer des flux à Octoshape ; mise à disposition de “plug-in” (écrits par Octoshape) pour les utilisateurs et des mises à jour pour ces logiciels ; mise à disposition des services P2P pour le streaming en direct nécessaires au portail ;

57

WEBCASTING

l

mise à disposition des statistiques d’audience pour tous les participants ; l mise à disposition de services de géolocalisation l insertion d’annonces publicitaires en début de flux (sur demande).

Les Membres de l’UER participant à l’essai ont coordonné leurs activités avec le Département technique de l’UER. Il s’agissait notamment des activités suivantes : l

Collaborateurs de l’UER L’UER a assumé les responsabilités suivantes : l

l l

l

l

l

l

l

l l

l

respect et prise en compte des intérêts des Membres de l’UER (technique, juridique, programmes) ; coordination du processus d’évaluation ; mise au point d’un site Internet spécifique, en collaboration avec Octoshape et conformément aux spécifications de cette dernière, mise à disposition d’un lien vers la page d’accueil de l’UER ; conception de la page Internet, amélioration constante de son apparence et de ses fonctions ; mesures visant à assurer une bonne visibilité à toutes les chaînes participantes (aucune discrimination) ; mise à disposition des informations nécessaires pour que les utilisateurs finaux puissent accéder à toutes les chaînes et à toute autre information recherchée ; mise à disposition de la dernière version des lecteurs de médias nécessaires et du “plug-in” d’Octoshape ; rédaction de rapports à l’intention des différents organes de l’UER, sur l’état d’avancement des essais techniques ; promotion du portail afin de maximiser l’utilisation du site ; promotion du portail à l’occasion d’événements importants, de séminaires UER, de conférences et d’expositions ; évaluation des stratégies communes en vue des services préopérationnels et commerciaux d’Octoshape (phases suivantes du projet et possibilités au niveau des modèles économiques).

Membres de l’UER – organismes participant à l’essai 5)

58

l

l l l

l

l

mise à disposition du contenu - sélection des stations radio/chaînes TV et des autres contenus destinés à être publiés sur le site Internet de l’UER5 ; octroi à l’UER des droits relatifs au contenu destiné à être publié sur le site Internet de l’UER ; codage de leurs flux (au moyen des technologies appropriées); envoi de leurs flux à Octoshape ; définition des contraintes en termes de couverture (le cas échéant) et mise à disposition d’Octoshape des instructions nécessaires pour mettre en œuvre un filtrage basé sur la géolocalisation ; mise à disposition d’un lien vers le site Internet de l’UER depuis leur propre site, afin que les utilisateurs de leurs pays respectifs puissent facilement accéder au contenu proposé par d’autres membres de l’UER ; contrôle éditorial des éventuelles publicités diffusées au début du streaming (pre-roll adverts).

Questions juridiques : Pendant toute la durée de l’essai, les questions d’ordre juridique, notamment celles portant sur le droit d’auteur, ont joué un rôle important. Nous pensions initialement que l’EBUP2P pouvait être considéré comme une sorte de rediffusion du contenu des Membres de l’UER et donc qu’il était possible de l’assimiler à un réseau câblé. Dès lors, l’UER (en sa qualité de propriétaire du portail) avait besoin de la permission explicite des Membres pour rediffuser leurs émissions. Le cas échéant, l’UER devrait également régler le problème des droits avec les sociétés de gestion collective. Il a par conséquent été demandé à tous les participants de signer un formulaire de cession de droits confirmant qu’il n’y avait aucun obstacle d’ordre juridique empêchant l’UER de mettre les chaînes TV à disposition du grand public, gratuitement, dans leur forme originale et

parallèlement à la diffusion terrestre de ces mêmes chaînes. Dans un second temps, il est apparu que l’utilisateur final qui clique sur une icône du site Internet de l’UER, pour accéder à une chaîne TV donnée, est tout simplement redirigé vers le flux original de l’organisme qui met le contenu à disposition. Par conséquent, l’UER ne retransmet pas le flux. Il a donc été décidé de publier l’avertissement suivant :

Les utilisateurs sont redirigés vers le flux original de l’organisme mettant à disposition le contenu. L’UER ne retransmet pas le flux en question.

Si un autre portail devait être créé à l’avenir, l’UER pourrait simplement mettre à disposition les liens vers les pages Internet des Membres qui comporteraient alors des lecteurs média intégrés. Cette solution permettrait de résoudre le problème.

Les résultats de l’évaluation Audience Le tableau ci-dessous indique le nombre d’utilisateurs uniques qui ont pu participer à l’essai (toutes chaînes/stations confondues) au cours de la période janvier – juin 2008. Il indique également le nombre d’heures de programmes visionnés chaque mois.

Mois

Utilisateurs uniques

Total heures

Janvier Février Mars Avril Mai Juin

9 072 8 157 8 652 7 031 3 808 2 936

32 375 39 777 44 898 41 519 26 247 24 184

La Figure 3 montre l’évolution de l’audience pour la chaîne TV et la station radio de Hessicher Rundfunk (HR) pendant la campagne politique, avant les élections à Hessen, en Allemagne. Les membres du SPD,

En règle générale, tous les programmes sur Internet devraient être disponibles 24 heures sur 24, mais chaque Membre peut décider de l’heure et de la durée de ses services ; dans ce cas, il est toutefois souhaitable de mettre à disposition une grille horaire des émissions.


WEBCASTING

l’un des partis politiques participant à la campagne, ont pu regarder les programmes TV grâce à notre flux P2P, car ils n’avaient pas de postes TV dans leurs bureaux. À noter que le système Octoshape était limité à 600 utilisateurs simultanés, car HR n’avait pas averti Octoshape à l’avance (voir le chapitre ci-dessous sur la “extensibilité”).

Accessibilité L’ensemble des liens Internet a fonctionné de manière satisfaisante. Il était possible de passer facilement d’une chaîne/station à une autre. En outre, on pouvait visionner un seul flux à la fois (ce qui correspondait aux spécifications). Occasionnellement, quelques problèmes ont été constatés (absence de son, mauvaise synchronisation du son). Ils étaient dus à un codage non adapté. La chaîne de programmes documentaires espagnole n’est pas disponible hors d’Espagne pour des questions de droit d’auteur. Le filtrage par géolocalisation a permis de résoudre ce problème. L’utilisateur final était informé par un message qui s’affichait sur son écran : “Ce flux vidéo n’est pas disponible dans votre territoire”. Il est arrivé que des utilisateurs aient des difficultés à télécharger le plugin d’Octoshape. Certains d’entre eux, notamment des personnes travaillant pour de grandes entreprises (dont plusieurs importants organismes de radiodiffusion), n’ont pas pu télécharger le plug-in. Il leur a donc été impossible d’accéder aux services du portail. Il s’agit d’une particularité du système Octoshape dont nous devons tenir compte, car elle peut constituer un frein à l’utilisation du portail.

Qualité et performance – remarques générales Nous n’avons aucune raison de penser que l’intensité du trafic sur le réseau, l’asymétrie ou des questions liées au “dernier kilomètre” ont eu une influence négative quelconque sur la qualité globale du système Octoshape.

6)

Figure 3 – Variations d’audience sur les chaînes radio et télévision de HR

Il convient toutefois de souligner que seuls des essais en laboratoire à grande échelle, permettant d’assurer la reproductibilité des résultats, pourraient fournir des conclusions scientifiquement valables. Selon les rapports reçus, la qualité du service semble être bonne, ce qui nous permet d’affirmer qu’Octoshape a fonctionné correctement sur tous les réseaux.

un codage en deux étapes était possible, cela aurait certainement pour effet d’améliorer les performances. L’utilisation de sources SDI est fortement recommandée alors que les sources composites (permettant de réduire les interférences que ce soit entre différentes couleurs ou différentes luminances) doivent être évitées.

La qualité du service dépend principalement de la qualité du codage. Nous avons identifié quelques erreurs commises par les Membres au moment du codage du matériel vidéo, notamment au niveau du format d’écran, lorsque le matériel source avait été produit en TVHD (16:9).

Niveau audio :

Si un service régulier devait un jour être créé, il faudra examiner la question du codage avec une très grande attention. Il est préférable d’éviter des différences entre les sources. Cela permettra de ne pas voir des écarts trop importants au niveau sonore ou autre lors des changements de chaîne. Les radiodiffuseurs devraient adopter un ensemble commun de paramètres de codage. Il faudrait utiliser uniquement des pixels carrés.

0 dB FS level (full scale)

Extensibilité Au mois de mai, à l’occasion d’un grand événement Internet, HR a été victime d’une interruption de service. Octoshape a expliqué que son réseau P2P était configuré par défaut pour accepter un maximum de 6006 utilisateurs (ce qui veut dire que le service est interrompu si plus de 600 utilisateurs se connectent simultanément). Il s’agit en fait d’une simple mesure de précaution mise en place par Octoshape. En effet, cette dernière ne peut connaître les limites de tous les réseaux utilisés par les différents fournisseurs de services Internet. Octoshape peut toutefois adapter la largeur de bande aux limites du réseau utilisé.

Résolutions :

4:3 – 512 x 384 pixels 16:9 – 512 x 288 pixels

Les problèmes de désentrelacement devraient être gérés par le matériel (carte de codage). Le codage complexe devrait être activé. Si

On aurait donc pu éviter une telle interruption de service si Octoshape avait été informée à l’avance qu’un grand nombre d’utilisateurs allait vraisemblablement se connecter simultanément. Octoshape est en mesure d’adapter automatiquement ou manuellement le débit, qui peut passer de 700 kbit/s à 200 kbit/s .

Octoshape a précisé que la limite de 600 utilisateurs est tout à fait arbitraire et que, en cas de besoin, elle peut être bien plus élevée (notamment pour les événements en direct).


59

WEBCASTING

Afin d’assurer la extensibilité et la continuité du service, même en cas d’augmentation du nombre d’utilisateurs, il est nécessaire de coder les flux en deux ou trois débits. Ainsi, Octoshape peut passer automatiquement à un débit inférieur dès que le nombre d’utilisateurs dépasse la limite initialement fixée. Il convient de remarquer qu’un codage à deux débits peut être mis en œuvre par un seul PC. Octoshape a déjà démontré à de nombreuses reprises qu’elle dispose d’un système tout à fait capable de s’adapter aux besoins. En effet, à l’occasion du Concours Eurovision de la Chanson, ce système à pu fournir environ 45’000 flux simultanés sans aucun problème.

Plateformes informatiques et navigateurs

se contente de servir d’interface avec cette base de données. Octoshape est d’avis que ce système de géolocalisation offre un excellent niveau de précision et de sécurité. Elle utilise ce système depuis de nombreuses années et n’a jamais eu aucun problème. Si nécessaire, Octoshape pourrait utiliser n’importe quel autre système de géolocalisation, y compris Akamai ou Quova. Les Membres ont décidé que le système de géolocalisation de EBUP2P devrait répondre aux exigences les plus élevées, tant au niveau des performances que de la sécurité.

l

En cas d’utilisation du filtrage basé sur la géolocalisation, le contenu protégé par le droit d’auteur doit être accessible uniquement dans la région pour laquelle les droits ont été obtenus. En dehors de celle-ci, un message expliquant la situation doit apparaître à l’écran. Le texte du message pourrait être le suivant :

Aucun problème lié à l’utilisation de différents systèmes d’exploitation, navigateurs et plateformes informatiques n’a été signalé.

Géolocalisation Au cours de l’essai, le Groupe a prêté une attention particulière à la question du filtrage basé sur la géolocalisation. En effet, un tel outil est essentiel pour limiter la couverture de certaines régions, notamment pour des raisons liées au droit d’auteur. Le système de géolocalisation doit répondre à des critères très stricts en termes de sécurité, de précision et de fiabilité, afin d’éviter que des contenus ne soient diffusés hors des régions pour lesquelles les droits ont été obtenus. Le système de géolocalisation utilisé par Octoshape est un produit commercial très perfectionné appelé “IP2location”. Il permet l’identification de l’emplacement géographique et du nom de domaine grâce à l’adresse IP. La base de données d’IP2location permet, grâce à l’adresse IP entrante, d’identifier le pays, la région, la ville, la latitude, la longitude, le code postal, le fournisseur de services Internet, le fuseau horaire, la vitesse du réseau et le nom de domaine de l’internaute. Octoshape 7)

60

Le “pre-roll” est un modèle économique dans lequel l’utilisateur final reçoit tous les flux audio et vidéo gratuitement. Lors de l’essai du EBUP2P, Hessischer Rundfunk a utilisé un service “pre-roll” avec des annonces de 5 secondes. Octoshape a confirmé qu’elle était en mesure de fournir une technologie pour diffuser des annonces publicitaires “preroll” qui est très proche de celle de Zattoo. Toutefois, si ce système “pre-roll” devait être utilisé pour un service opérationnel, plusieurs questions se poseraient :

“En raison de restrictions dues au droit d’auteur, ce programme est disponible uniquement dans la région autorisée. Vous n’êtes pas dans cette zone, par conséquent vous ne pouvez pas avoir accès au contenu. Veuillez nous excuser pour ce désagrément.”

Qui fournit le contenu des annonces publicitaires ? l Le contenu des annonces doit-il être adapté au marché ? l Le contenu des annonces doit-il varier selon la chaîne visualisée et la région dans laquelle se trouve l’utilisateur (ce qui conduirait à avoir des annonces différentes pour chaque marché) ?

Conclusions préliminaires Les conclusions principales auxquelles il a été possible d’aboutir sont les suivantes : l

Il serait préférable que le message ci-dessus soit affiché dans la langue nationale et en anglais. D’autres langues pourront être ajoutées en temps voulu. Pour les contenus touchés par le filtrage basé sur la géolocalisation, il serait possible de bloquer les images et de laisser le son à disposition des internautes. l

La mise en œuvre du filtrage basé sur la géolocalisation pourrait se faire de deux manières : [a] à heures fixes (début et fin prédéterminés) ou [b] flexible (marques temporelles ou activation manuelle).

Gestion des droits

l

La gestion numérique des droits (DRM) n’a pas été testée. Elle est indépendante du système P2P utilisé. l

Publicité au l) début du flux (pre-rol

La limite inférieure de 200 kbit/s a été portée à 350 kbit/s afin d’améliorer la qualité minimum.

l

L’EBUP2P est une solution qui utilise des techniques de pointe. En outre, cet essai a permis de vérifier que ce portail répond à toutes les exigences techniques et opérationnelles, que ce soit au niveau de la qualité du service, de l’extensibilité, de la qualité vidéo et audio, de l’accessibilité, de la sécurité et de la convivialité. L’EBUP2P n’implique aucune limite pour ce qui est du nombre de stations radio et de chaînes TV qui peuvent être mises à disposition sur le portail. Les Membres peuvent décider de mettre leurs programmes à disposition par ce moyen et suspendre le service à tout moment. L’EBUP2P peut répondre à nos exigences en matière de droit d’auteur, en mettant en œuvre un système de filtrage territorial (géolocalisation) et de watermarking. L’EBUP2P permet d’exploiter un grand nombre de modèles économiques. L’EBUP2P peut évoluer et être adapté aux appareils destinés au grand public.

Malgré des ressources humaines et financières très limitées, l’essai du portail médias EBU


WEBCASTING

Franc Kozamernik est diplômé de la Faculté d’ingénierie électromécanique de l’Université de Ljubljana (Slovénie), en 1972. Il a commencé sa carrière professionnelle en tant qu’ingénieur chargé de la recherche et du développement à la radiotélévision slovène. Depuis 1985, il travaille au Département technique de l’UER. Dans ce cadre, il a participé à de nombreuses activités touchant à la radiodiffusion par satellite, à la planification du spectre, à la radiodiffusion numérique sonore, au codage de sources audio et aux questions concernant les radiofréquences dans le cadre du développement de plusieurs systèmes de radiodiffusion audio et vidéo, tels que la DVB et la DAB. Depuis qu’il travaille à l’UER, M. Kozamernik a assuré la coordination d’études relatives à Internet réalisées par le groupe B/BMW (Broadcast of Multimedia on the Web) et a participé à plusieurs études techniques dans le cadre du groupe I/OLS (On-Line Services). Actuellement, il est coordinateur de plusieurs groupes de projet qui s’occupent de recherche et de développement dans le cadre de l’UER, notamment le B/AIM (Audio in Multimedia), le B/VIM (Video in Multimedia) et le B/SYN (Synergies of Broadcast and Telecom Systems and Services). Il assure également la coordination des groupes de travail de l’UER suivants : B/BTV (Broadband Television) et B/MCAT (MultiChannel Audio Transmission). Franc Kozamernik représente l’UER au sein de plusieurs organismes internationaux et projets en collaboration. Il a également participé à la rédaction d’un grand nombre d’articles publiés dans la presse spécialisée et a présenté plusieurs rapports à l’occasion de conférences internationales.

P2P s’est déroulé selon le calendrier de travail prévu et a débouché sur un succès. Les participants ont pu effectuer un grand nombre d’essais techniques et opérationnels. Le nombre d’organismes participants avait été limité à dix. Nos ressources logistiques étant très modestes, il était impossible d’accepter plus de participants. En outre, le nombre d’utilisateurs finaux est resté assez modeste, car nous n’avons pas souhaité que le portail fasse l’objet d’une promotion à grande échelle. Ces essais conduits dans le cadre de l’UER ne peuvent pas être considérés comme des tests scientifiquement rigoureux. Ils relevaient davantage d’une évaluation de la technologie en question, le but étant de valider le concept et d’acquérir de l’expérience. Octoshape n’est pas le seul système P2P commercial sur le marché, mais nous l’avons sélectionné car nos expériences précédentes avec cette entreprise s’étaient avérées positives. La conclusion principale que nous pouvons tirer de cet essai est qu’Octoshape est un excellent système de distribution Internet pour faire parvenir des flux audio et vidéo à des utilisateurs de PC. Ce système est extensible, fiable, facile à gérer et interopérable avec de nombreux codecs, systèmes d’exploitation, navigateurs et systèmes de géolocalisation. Ce projet nous a permis de résoudre bon nombre 8)

de problèmes. Certaines questions restent toutefois en suspens et pourront faire l’objet de travaux futurs (voir le chapitre ci-dessous). Cet essai média P2P a prouvé que le système Octoshape peut être utilisé par nos Membres. Il représente une solution viable et techniquement satisfaisante pour la distribution de flux audio et vidéo sur Internet. Il peut être utilisé comme système de distribution indépendant ou être associé à des technologies CDN ou IP.

Travaux futurs Exploiter un portail médias est un projet complexe et les technologies nécessaires évoluent très rapidement. Montrer que le système de distribution P2P fonctionne correctement et selon nos attentes ne suffit pas. Pour mettre en œuvre un portail commercial, il faudra également prendre en considération les questions suivantes : l

watermarking (et fingerprinting) – pour intégrer des signaux de watermarking audio permettant de retrouver l’origine du contenu (si nécessaire) ; l possibilité d’utiliser des lecteurs médias personnalisés (qui s’ouvrent dans une page séparée) et des lecteurs intégrés ; l intégration optionnelle de la gestion numérique des droits (si cela s’avère nécessaire pour contrôler la consommation des medias)8 ;

Les participants pourront utiliser différents outils de gestion numérique des droits pour protéger leur contenu.


l

mise au point d’un modèle de EPG basé sur le XML et possibilité de mettre à disposition un EPG (journalier ou hebdomadaire) ; l mise à disposition de la couverture supplémentaire d’événements spéciaux (si nécessaire) ; l élargissement des services liés au portail afin de proposer le téléchargement de contenus et des services de vidéo à la demande (documentaires, archives, événements sportifs enregistrés, etc.) ; l récepteurs TV hybrides avec une connexion large bande (Ethernet ou WiFi) : intégration du client P2P dans les récepteurs TV et les décodeurs externes du commerce (comme en DVB).

Remerciements L’UER souhaite remercier tous les participants pour leur aimable coopération. Les collaborateurs d’Octoshape – Stephen Alstrup, Theis Rauhe et Lasse Riis – méritent une mention particulière pour l’efficacité avec laquelle ils ont résolu tous les problèmes qui ont pu se poser lors des essais. Nous devons également remercier Nathalie Cullen, du Service de la Communication de l’UER, pour le design du portail Internet, qui était à la fois fonctionnel et attrayant. Enfin, nous tenons à exprimer notre gratitude à la direction de l’UER pour le soutien sans faille dont elle fait preuve à notre égard et pour les encouragements dont elle nous a gratifiés à l’occasion de ce projet. Première publication : 2008-Q3

61

Audio sur IP

Programmes radiophoniques sur

réseaux IP

– une nouvelle norme de l’UER

Lars Jonsson Radio suédoise

Mathias Coinchon Département technique de l’UER

Les équipements terminaux audio sur IP sont de plus en plus utilisés pour la transmission de programmes radiophoniques sur des réseaux IP, depuis des emplacements éloignés ou des bureaux locaux jusqu’à des studios. Les réseaux IP utilisés peuvent être des réseaux privés bien gérés, avec une qualité de service garantie. L’Internet ouvert est cependant de plus en plus utilisé pour différents types de contributions radiophoniques, en particulier sur de longues distances. Pour distribuer leurs reportages, les correspondants radio auront le choix d’utiliser un RNIS, Internet via l’ADSL, ou d’autres réseaux IP disponibles. Les services RNIS utilisés pour la radiodiffusion seront interrompus dans certains pays. L’UER a mis au point une norme d’interopérabilité dans le cadre d’un Groupe de projet baptisé N/ACIP (Audio Contribution over IP, contribution audio sur IP). Cette norme, conçue par des membres de ce groupe en collaboration avec des fabricants, a été publiée sous la référence EBU Tech 3326-2007 et rapidement mise en œuvre par les fabricants. Un « plug test » réunissant neuf fabricants, organisé en février 2008, a prouvé que des appareils qui étaient auparavant incompatibles pouvaient désormais être reliés selon cette nouvelle norme.

Les équipements terminaux audio sur IP sont de plus en plus utilisés pour la transmission de programmes radiophoniques sur des réseaux IP, depuis des emplacements éloignés ou des bureaux locaux jusqu’à des studios. Les réseaux IP utilisés peuvent être des réseaux privés bien gérés, avec une qualité de service garantie. L’Internet ouvert est cependant de plus en plus utilisé pour différents types de contributions radiophoniques, en particulier sur de longues distances. Pour distribuer leurs reportages, les correspondants radio auront le choix d’utiliser un RNIS, Internet via l’ADSL, ou d’autres réseaux IP disponibles. Les services

62

Audio over IP application B

Audio over IP application A

Audio stream / Packets

Audio stream / Packets RTP

RTP

TCP UDP

UDP TCP

IP

IP

NC

NC

IP network


Audio sur IP

RNIS utilisés pour la radiodiffusion seront interrompus dans certains pays. L’UER a mis au point une norme d’interopérabilité dans le cadre d’un Groupe de projet baptisé N/ACIP (Audio Contribution over IP, contribution audio sur IP). Cette norme, conçue par des membres de ce groupe en collaboration avec des fabricants, a été publiée sous la référence EBU Tech 33262007 et rapidement mise en œuvre par les fabricants. Un « plug test » réunissant neuf fabricants, organisé en février 2008, a prouvé que des appareils qui étaient auparavant incompatibles pouvaient désormais être reliés selon cette nouvelle norme. Le protocole Internet (Internet Protocol, IP) est utilisé dans le monde entier, sur le web et également sur les réseaux privés ou d’entreprise à protocole Internet de certains radiodiffuseurs. Ce protocole de routage est indépendant des technologies de transmission de données aux couches sous-jacentes et de nombreuses adaptations IP existent pour les couches physiques (Ethernet, ATM et SDH, par exemple) sur des liaisons de cuivre, à fibre ou radio. Les applications peuvent communiquer de manière standardisée sur des réseaux IP interconnectés. On peut ainsi entrer en contact quasiment instantanément avec les serveurs, quel que soit l’endroit où ils se trouvent. Des connexions fixes ou temporaires pour les contributions audio peuvent partager les mêmes types d’applications. On établit la connexion en composant un numéro ou un nom comparable à une adresse de courrier électronique. Le flux audio est ensuite envoyé au moyen de protocoles normalisés (SIP, RTP, UDP). De nombreux formats de codage audio peuvent être utilisés à des débits différents. Des débits élevés permettront de réaliser des transmissions de données audio en stéréo ou multivoies, avec un codage PMC linéaire. Le débit audio maximum autorisé pour des transmissions de ce type dépendra de la largeur de bande et de la qualité de service du réseau. L’Internet ouvert et les réseaux IP fermés font constamment l’objet d’améliorations et évoluent vers des largeurs de bande plus importantes, ce qui permettra de transférer à l’ensemble des utilisateurs des images


Typical infrastructure using SIP GSM + Wi-Fi VoIP Phone

IP Net

Studio-side AoIP Codec Firewall/NAT Location/ Redirect Server

Wi-Fi VoIP Phone

SIP Proxy Server

The location server associates VoIP names with IP addresses and/or telephone numbers

• •

SIP name: sip:[email protected] (picture courtesy: Steve Church, Telos) Telephone number:

1 216 2417225

outside - broadcast

Interview

bidirectional with narrowband return

PMP

Discussion

bidirectional broadband

File transfer

unidirectional

temporary connection

permanent connection

undefined / shared bandwidth

defined and constant bandwidth

Codec(s) or endpoint(s) unknown

Codec(s) and endpoint(s) known

temporary + permanent = temporary

undefined + defined = undefined

: rare combination

63

Audio sur IP

TV haute définition et des données audio de qualité élevée. On pourra utiliser à la fois des réseaux IP d’entreprise et Internet pour réaliser et distribuer des contributions uniquement audio. Les coûts d’utilisation des réseaux sont appelés à diminuer, alors que la qualité de service devrait s’améliorer. On appelle généralement réseaux de prochaine génération (Next Generation Networks, NGN) des réseaux publics améliorés, qui offriront une largeur de bande nettement plus importante. Dans bon nombre de pays, les réseaux mobiles IP mis à disposition offriront une bonne couverture de la population. Les systèmes 3G/UMTS et LTE (4G) proposeront bientôt des débits plus élevés en amont. D’autres évolutions envisageables sont des points d’accès public (« hotspots ») WiMAX et WLAN, qui pourraient offrir des solutions en matière de contribution radio. Cela étant, ces systèmes pourraient ne pas assurer toujours la robustesse exigée pour les contributions en direct, en raison des interférences et de l’accès partagé. La valeur ajoutée de ces nouveaux réseaux résidera dans l’accès quasi-instantané qu’ils offriront aux journalistes travaillant dans des zones urbaines. Une amélioration que l’on peut obtenir en utilisant la fonctionnalité de présence dans SIP (Session Initiation Protocol, protocole d‘ouverture de session) est la suivante : une identité permettra d’entrer en contact avec un reporter, quel que soit l’endroit où celui-ci se trouve et quelle que soit la plateforme utilisée (téléphone mobile ou codec audio sur IP, par exemple).

Types de connexions Deux types de connexions peuvent être utilisés : l

l

64

C onnexions permanentes – elles s’appuient généralement sur des réseaux privés gérés, avec une largeur de bande et une qualité de services constantes et connues. Avec des connexions permanentes, les types de codecs audio sont généralement connus à l’avance. Connexions temporaires – elles peuvent reposer sur des réseaux préalablement inconnus, avec une largeur de bande partagée et elle aussi inconnue sur Internet ou sur des réseaux privés loués

temporairement. Les codecs et les points d’extrémité peuvent être inconnus. Le type de codec audio peut être identifié par le biais d’une négociation au moyen des protocoles SIP et SDP.

Types d’équipements Deux types d’équipements peuvent être identifiés : l

Norme UER Jusqu’à présent, les équipements terminaux audio sur IP de différents fabricants n’étaient pas compatibles. Sous l’impulsion de fabricants et de radiodiffuseurs allemands, l’UER a mis sur pied un groupe de projet baptisé N/ACIP (Audio Contribution over IP, contribution audio sur IP). L’une des missions confiées à ce groupe consiste à proposer une solution en matière d’interopérabilité. A l’issue d’une réunion entre radiodiffuseurs et fabricants organisée en septembre 2007, une recommandation sur l’interopérabilité a été publiée. Elle est déjà appliquée par un certain nombre de fabricants [1].

Exemple de terminal fixe RNIS et audio sur IP l

Dans le cadre d’un « plug test » organisé à l’IRT de Munich, en février 2008, neuf fabricants ont démontré l’interopérabilité. L’UER travaille actuellement sur un logiciel de référence, susceptible d’être utilisé pour vérifier la compatibilité.

Équipement de contribution générique – utilisé pour tous les types de contributions (fixes ou à distance);

Équipement de contribution portable – utilisé principalement pour des contributions vocales monophones, à faible débit.

Les exigences en matière d’interopérabilité se fondent sur l’utilisation du protocole RTP sur UDP pour la session audio et du protocole SIP pour la signalisation. L’encapsulation des trames audio dans les paquets RTP est définie dans plusieurs documents RFC de l’IETF relatifs aux formats audio les couramment plus utilisés en matière de contribution radio, comme le G.722, le MPEG Layer II et le PCM linéaire. Si l’on utilise un protocole SIP, une négociation peut être engagée pour trouver automatiquement un système de codage audio commun entre des unités quelconques à chaque extrémité. La norme UER préconise l’utilisation du protocole TRP sur UDP, au détriment du TCP. Un flux RTP unidirectionnel avec une en-tête limitée (faible quantité d’informations superflues) est plus adapté à des transferts audio. De plus, le RTP sur UDP a parfois une priorité plus élevée que le TCP dans les routeurs. De plus amples informations sur le projet N/ ACIP de l’UER sont disponibles à l’adresse suivante : http://www.ebu-acip.org

Exemple d’unité portable RNIS et audio sur IP

Réseaux Les opérateurs de télécommunications offrent un nombre croissant de services basés sur IP. Les services traditionnels basés


Audio sur IP

sur ATM, PSTN, RNIS, SDH et PDH vont progressivement être abandonnés ou devenir des produits de « niche » au coût élevé. Ils seront peu à peu remplacés par des services entièrement sur IP, transportés sur des liaison en cuivre, à fibre ou sans fil. Certains Membres de l’UER ont testé concrètement des codecs audio sur IP, sur différents types de réseaux IP. Pour identifier le type de réseau le mieux adapté, parmi les solutions proposées par les fournisseurs, on doit procéder à un examen attentif. Il reviendra en particulier aux radiodiffuseurs de réaliser des mesures et des essais audio pour analyser l’accord de niveau de service et vérifier les performances des fournisseurs réseaux. Il convient en effet de tester le réseau au moyen des applications destinées à être utilisées. Il est recommandé de réaliser des essais à long terme sur un débit audio ininterrompu. Par ailleurs, il est important de bien faire la distinction entre réseaux IP bien gérés et l’Internet ouvert. Sur l’Internet ouvert, il n’existe encore aucun mécanisme permettant d’atteindre une qualité de service satisfaisante. Le Net est un réseau « de meilleur effort », qui ne garantit aucune qualité de service. Sur une période de dix ans, les problèmes liés à la perte de paquets, aux retards et à la gigue (« jitter ») sur Internet se sont peu à peu résorbés. Cela étant, les performances du réseau continuent à poser problème aux concepteurs d’unités audio sur IP.

l

Fibres optiques l

Cette solution d’accès est celle qui offre la meilleure qualité, le taux d’erreur le


Satellite l

Cuivre avec xDSL (ADSL, ADSL2+, VDSL, SDSL) l

l

l

C e type d’accès est désormais très largement utilisé dans le cadre de connexions Internet. Les fournisseurs commerciaux proposent également des solutions de raccordement aux réseaux IP privés, avec xDSL et une qualité de service garantie. Ce type de solution est privilégié par rapport à un accès Internet classique, à des fins de contribution. ADSL : débit liaison montante/liaison descendante asymétrique SDSL : débit liaison montante/liaison descendante symétrique. Type d’accès privilégié en termes de contribution, en raison d’un débit d’envoi plus élevé en liaison montante.

Communications mobiles : 3G/UMTS, HSDPA, WiMAX l

Accès au dernier kilomètre Il existe de nombreuses solutions pour raccorder l’utilisateur final à Internet ou à des réseaux IP privés. En voici une vue d’ensemble :

plus faible et les retards les plus limités. C’est la solution idéale en termes de contribution, mais elle reste coûteuse et encore peu utilisée. Certaines villes ont commencé à installer un accès FTTH (Fibre to the Home, fibre jusqu’au domicile).

l

Des accès mobiles à débit élevé à Internet commencent à apparaître. Aucune qualité de service n’est cependant garantie. Dans de nombreux cas, plusieurs utilisateurs de la même cellule radio se partagent l’accès. Pour l’heure, cette solution n’est donc pas idéale en termes de contribution, malgré l’avantage qu’elle présente au niveau de la mobilité. Bon nombre d’opérateurs filtrent également le trafic et bloquent l’accès pour la voix/l’audio sur IP. D ans l’avenir, certains opérateurs prévoient de proposer l’accès à des réseaux IP privés Les solutions proposées dans un proche avenir devraient offrir une meilleure qualité de service, du moins peut-on l’espérer.

l

l

O n p e u t a c c é d e r à I n t e r n e t p a r l’intermédiaire d’un satellite, en utilisant un système d’émission pour le canal de retour. On l’utilise dans un endroit éloigné, où aucune autre technologie d’accès n’est disponible. Dans la plupart des cas, on utilise la technologie DVBRCS (Return Channel over Satellite). L’accès est généralement partagé entre les utilisateurs, il est donc difficile d’avoir une qualité de service garantie. Le service BGAN d’Inmarsat est une autre possibilité envisageable. Dans l’avenir, il pourrait être possible d’avoir accès à des réseaux satellites privés, avec une qualité de service améliorée. Le temps de transmission par satellite est généralement long (environ 500ms pour un temps de propagation allerretour). Il est également nécessaire qu’il n’y ait aucune obstruction vis-à-vis du satellite.

Wifi l

l

Le système Wifi n’offre pas réellement un accès au dernier kilomètre, il constitue davantage une solution réseau à domicile. Il est cependant disponible sous la forme d’un accès au dernier kilomètre dans certaines villes (parfois gratuitement). La bande de fréquences est partagée entre de nombreux utilisateurs et de nombreux systèmes (fours à micro-ondes, téléphones DECT). Il est donc impossible d’avoir une qualité de service garantie pour de tels accès, même si ceux-ci donnent de bons résultats dans le cadre d’un accès local, dans des endroits ne réunissant pas un trop grand nombre d’utilisateurs.

Synchronisation Des variations de la durée de transmission des paquets peuvent se produire, principalement

65

Audio sur IP

en raison de retards au niveau des routeurs et du partage de la capacité disponible avec un autre trafic de données. Pour compenser cette variation, un stockage temporaire des données est nécessaire (voir le diagramme). De surcroît, aucune horloge n’est habituellement transportée ; elle doit donc être reconstruite à l’extrémité de réception. Il existe de nombreux algorithmes de récupération de d’horloge. La difficulté consiste à estimer correctement le décalage de l’horloge et à le séparer de la gigue de courte durée due au réseau. Une transmission audio de qualité dépend d’une fréquence d’horloge stable et garantie, au niveau des extrémités d’émission et de réception. Une autre possibilité consiste à utiliser une source externe, comme GPS ou une horloge réseau commune non basée sur IP.

Retard Les mémoires tampons situées à l’extrémité de réception peuvent causer un retard

important. L’ampleur de ce retard est le résultat d’un compromis entre retard acceptable et transmission fiable. En outre, le réseau IP connaît lui-même des retards, allant de quelques dizaines de millisecondes (dans des réseaux bien gérés) à 500 ms, voire plus, sur de très longues distances sur l’Internet ouvert. Le codage audio peut luimême causer des retards allant de quelques millisecondes, dans le cas d’une modulation par impulsions et codage, à plusieurs centaines de millisecondes, pour certains formats de codage à débit limité. Il convient en outre de prendre en compte le temps nécessaire pour remplir les paquets. En effet, des paquets plus longs seront synonymes de retard accru, en particulier à faible débit. Dans le cas d’une conversation bidirectionnelle, un temps de propagation aller-retour inférieur à 50ms est généralement préférable ; sinon, une conversation devient difficile, en particulier si des personnes du grand public sont interviewées. Des reporters expérimentés peuvent s’avérer moins sensibles à des retards plus importants. Lorsque l’on utilise l’audio sur IP en association avec une contribution vidéo, la synchronisation audio/vidéo peut poser problème.

Conclusions Le développement continu des réseaux IP, associé à des équipements audio sur IP de plus en plus perfectionnés, devrait aboutir à une utilisation généralisée de cette technologie, dans un proche avenir. Le Groupe N/ACIP de l’UER a formulé une proposition concernant l’interopérabilité. Les connexions sur Internet réalisées au moyen de différents types d’appareils téléphoniques et professionnels de radiodiffusion amélioreront la qualité sonore du téléphone et l’accès mondial, pour les journalistes. Ceux-ci, avec de petites unités portables et des codecs logiciels dans les « laptops » (PCs portables) ou les téléphones mobiles, disposeront d’outils très efficaces. Le protocole SIP constituera une solution efficace pour localiser l’autre extrémité et pour négocier un format de codage audio adapté. Les unités fixes audio sur IP remplaceront progressivement les dispositifs point à point synchrones plus anciens, qui étaient utilisés pour la contribution audio en stéréo ou multicanal.


Né en 1949, Lars Jonsson obtient en 1972 une maîtrise en ingénierie électronique auprès de l’Institut royal de Stockholm. Il rejoint ensuite l’équipe de recherche de la radio suédoise. Dans ce cadre, il est appelé à travailler sur la mise au point de systèmes vidéo et RF. Il travaille ensuite pour une société de radio locale, où il s’occupe des opérations et du développement. Puis, en 1992, il intègre l’équipe de SR chargée du développement. Dans le cadre de ses activités à la radio suédoise, M. Jonsson s’est intéressé ces dix dernières années à des questions comme la qualité audio numérique, l’archivage et l’infrastructure audio informatique. Il est membre de plusieurs groupes de travail de l’Audio Engineering Society et de l’UER. Lars Jonsson est actuellement Président du Groupe de travail N/ACIP (contribution audio sur IP) de l’UER. Mathias Coinchon est né en 1975 et a obtenu en 2000 son diplôme d’ingénieur spécialisé dans les systèmes de communication auprès de l’Ecole polytechnique fédérale de Lausanne, en Suisse. Il également étudié à l’institut Eurecom de Sophia-Antipolis (France). Il a soutenu sa thèse à l’issue de son passage au Département Recherche et Développement de la BBC, à Kingswood Warren. A cette occasion, il a notamment été appelé à concevoir des solutions en matière d’analyse de propagation pour des essais réalisés en DRM (Digital Radio Mondiale). Il est ensuite devenu responsable de projet technique chez Wavecall, une start-up qui s’occupe notamment de mettre au point un outil de prédiction de propagation physique pour le secteur des télécommunications mobiles. M. Coinchon a ensuite travaillé pendant quatre ans à la RSR, la radio publique suisse, où il a été responsable d’un groupe qui s’intéressait aux réseaux de distribution, de contribution et informatiques. Dans le cadre de ses fonctions, il a pris une part active aux travaux du groupe d’étude technique de SRG-SSR idée suisse, chargé du nouveau lancement de la radio numérique DAB en Suisse. Depuis 2006, Mathias Coinchon est ingénieur senior au Département technique de l’UER. Dans ce cadre, il est actuellement secrétaire des groupes N/ACIP et N/VCIP, qui s’intéressent aux contributions audio et vidéo sur IP. Il est également Vice-président du Comité technique du consortium WorldDMB et s’intéresse à diverses questions en rapport avec la radio numérique. Dans le cadre de ses activités professionnelles, il travaille en outre sur l’audio, la distribution, les logiciels à source ouverte, les studios télévisés informatisés et les informations sur le trafic. Mathias consacre une partie de son temps libre à une station de radio communautaire.

66


Visitez le nouveau site du département technique de l’UER : http://tech.ebu.ch


67

Retrouvez les publications techniques de l’UER, y compris la revue technique sous : http://tech.ebu.ch/publications

Revue technique

Revue technique

Suggest Documents

REVUE TECHNIQUE

REVUE TECHNIQUE

.REVUE ·TECHNIQUE - Autoalkatreszek.com

Revue Technique Luxembourgeoise

REVUE TECHNIQUE 450i

Revue Technique 600 Bandit.pdf

revue technique - ICRC Shop

REVUE TECHNIQUE 1.6L - nx power

Revue Technique 2Cv Type a1960.pdf

Revue Technique Automobile mars 1955 - Série 02

Revue

Revue

REVUE

Revue

Revue Technique Fiat Panda [Download] PDF [eBooks] - Google Sites

40 YEARS OF DELPHI IN LUXEMBOURG - Revue Technique ...

revue technique synthetique des resultats de recherche solwplantes ...

(Re)penser la technique - Revue du MAUSS permanente

Logitech Revue

geographische revue

Revue 12

Revue 12

Revue mars

revue REPERES