Revue technique

Transcription

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
É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 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.
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
lServices
de “catch-up” TV
de vidéo à la demande
lTV mobile
lWeb 2.0 (notamment le contenu généré
par les utilisateurs), les plateformes
médias, etc.
lServices
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 :
lIPTV (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 :
lplusieurs
formats d’image (QCIF, CIF,
QVGA, VGA, SD, HD);
lplusieurs débits (variables ou constants,
selon le réseau d’accès) ;
lplusieurs fréquences (50 Hz, 25 Hz, 12,5
Hz) ;
ldiffé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
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
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
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
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
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
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
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
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
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
S e c o n d G e n e ra tio n
T h ird G e n e ra tio n
(T he process continues up to the seventh generation)
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
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
S e c o n d G e n . W ith
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
+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
G O P A lig n m e n t
T h ird G e n . W ith
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
T h ird G e n . W ith
P
B
B
P
B
B
P
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
S p a tia l S h ift
S p a tia l S h ift
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
S p a tia l S h ift
S p a tia l S h ift
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).
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) ;
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.
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

Transcription

Documents pareils

UER - Concours Eurovision de la chanson junior en P2P avec Oc

rtp accueille l`assemblee generale le l`union europeene de

356-CA-3829 - Université du Québec

François DURET, DDS, DSO, PhD, MS, MD-PhD

Une fenêtre ouverte sur les Médias de Service Public Européens

Comment analyser une vidéo

Aymeric KUNTZ

Le film d`animation Pierre et le Loup reçoit la Rose d

Contenu des cours d`informatique dispensés par la 2TF Asso (2