Types de synchronisation

Les flots multim´edia pr´esentent diff´erents besoins de synchronisation, qui peuvent ˆetre li´es soit `a l’ordre et `a la fr´equence de pr´esentation de chacune des unit´es d’un flot (synchronisation intra-flux), soit aux d´ependances entre des unit´es appartenant `a des flots diff´erents (synchronisation inter-flux). Un exemple de ce dernier cas est la synchronisation naturelle entre la vid´eo et l’audio (en anglais lip-sync). Enfin, dans les applications coop´eratives, les utilisateurs doivent percevoir, la mˆeme vue (l’ensemble des flux) au mˆeme moment ou au moins des vues similaires et coh´erentes. On parle alors de la synchronisation de groupe. Dans la communaut´e CSCW, ce principe est traduit par l’expression : What You See Is What I See (WYSIWIS).

Le probl`eme de la synchronisation couvre divers aspects : la mod´elisation et la sp´ecification des rela- tions temporelles, la mise en oeuvre de m´ecanismes pour assurer le respect de ces relations, l’´etablissement des m´ecanismes de r´ecup´eration apr`es une perte de synchronisation. Jusqu’`a pr´esent, la synchronisation multim´edia a ´et´e trait´ee au niveau de l’application. Pourtant, les m´ecanismes n´ecessaires sont suffi- samment g´en´eriques pour ˆetre fournis par une couche sp´ecifique du syst`eme d’exploitation. Dans les

applications coop´eratives, cette couche est repr´esent´ee par le niveau de coordination.

De nombreuses recherches ont abord´e le probl`eme de synchronisation dans diff´erentes perspectives. Blakowski et Steinmetz r´esument en [BS96] la probl´ematique de la synchronisation des m´edia en termes de besoins, sp´ecifications et mod`eles de r´ef´erence. Ishibashi et Tasaka analysent divers algorithmes et techniques de synchronisation dans des environnements r´eseau h´et´erog`enes.

Contrairement aux ´etudes sur la synchronisation intra ou inter-flux, moins de recherches se sont concentr´ees sur la synchronisation de groupe [EPD94, AY96, JK03]. Une premi`ere hypoth`ese qui dis- tinguent les travaux sur cette th´ematique concernent l’existence [EPD94] ou l’absence [AY96] d’une horloge globale `a laquelle toutes les horloges des clients se synchronisent. Une autre hypoth`ese souvent rencontr´ee est la connaissance des valeurs limites des d´elais du r´eseau. Le cas des environnement virtuels en r´eseau (networked virtual environments - NVE) est plus complexe car il s’agit de g´erer `a la fois des m´edia continus et discrets [ITTI03].

Synchronisation intra-flux

Au sein d’un flux multim´edia, chaque unit´e d’acc`es (image, ´echantillon audio) a une estampille tem- porelle repr´esentant l’´ech´eance `a laquelle elle doit ˆetre pr´esent´ee. La qualit´e de pr´esentation d’un flux multim´edia est ´etroitement li´ee au respect des relations temporelles entre ses unit´es d’acc`es. La plupart du temps, ces contraintes sont sp´ecifi´ees implicitement lors de l’acquisition du m´edia. Elles peuvent aussi ˆ

etre explicitement sp´ecifi´ees par un processus de traitement `a des fins d’adaptation.

La figure 4.3 pr´esente un exemple de contrainte temporelle dans le cas d’un flux vid´eo. En g´en´eral, une vid´eo est pr´esent´ee `a une fr´equence de 30 images par seconde. Par cons´equent, chaque image doit ˆetre pr´esent´ee pour un intervalle de temps de 33ms. Le non-respect de cette contrainte temporelle se traduit par une discontinuit´e de la pr´esentation, ce qui pourrait ennuyer l’utilisateur. Dans le cas d’un flux audio, des interruptions fr´equentes rendent la d´egradation encore plus s´ev`ere. Ce type de synchronisation est appel´e dans la litt´erature synchronisation intra-flux.

Image 1 Image 2 Image 3 Image n

33 ms 33 ms _temps

Fig. 4.3 – Contraintes temporelles des unit´es d’acc`es (images) au sein d’un flux vid´eo

Le r´eseau Internet fournit un service meilleur effort pour l’acheminement de chaque paquet depuis sa source vers sa destination. Il n’existe aucune garantie quant au temps de transmission des paquets d’un mˆeme flux, ce qui entraˆıne une gigue. De plus, des paquets achemin´es par des routes diff´erentes peuvent arriver dans un ordre quelconque. Enfin, les congestions dans les routeurs interm´ediaires peuvent provoquer des pertes.

En absence de m´ecanismes de synchronisation, un flux vid´eo diffus´e depuis le site A (figure 4.3) peut subir plusieurs d´egradations en termes de perte, d´es´equencement (sur le site B) ou gigue (sur le site C). Le rˆole d’un m´ecanisme de synchronisation, en coop´eration avec un protocole de transport, est alors de reconstruire cˆot´e r´ecepteur, les contraintes temporelles et logiques sp´ecifi´ees `a la source.

Internet <d >d <d d d d

A

I3 I2 I4 I1 I1 I2 I4 I3 I3 I4 I1

B

C

Synchronisation inter-flux

Lorsqu’il s’agit des pr´esentations multim´edia plus complexes, contenant plusieurs flux, la synchro- nisation entre ces flux doit ˆetre aussi prise en compte. Par exemple, la diffusion d’un film ou d’une ´

emission TV contenant deux pistes, audio et vid´eo, n´ecessite la pr´esentation synchrone des deux flux r´esultants. La figure 4.5 illustre la correspondance ´etablie lors de l’acquisition entre ces deux flux : `a chaque image correspondent trois ´echantillons audio. Ce type de synchronisation est connu sous le nom de lip synchronisation ou tout simplement lip sync.

Dans un contexte r´eseau sans garanties (par exemple Internet) comme celui pr´esent´e dans la figure 4.5, certains flux peuvent ˆetre en retard par rapport aux autres. Ainsi, l’utilisateur du site C pourrait observer que les mouvements des l`evres de la pr´esentatrice TV ne correspondent pas aux mots ´ecout´es. Il est alors n´ecessaire de restituer chez le r´ecepteur les relations temporelles entre les deux flux, telles qu’elles ont ´et´e captur´ees `a la source.

d d d Internet <d >d <d

C

B

I1 I2 I3 I4 I1 I2 I3 I4 I3 I4 I1 échantillons audio

A

Fig. 4.5 – Exemples de d´esynchronisation inter-flux

De mani`ere plus g´en´erale, la synchronisation inter-flux consiste dans le respect des contraintes tem- porelles entre les unit´es d’acc`es issues des diff´erents flux. Les flux multim´edia peuvent ˆetre classifi´es en

flux maˆıtres et flux esclaves qui doivent ˆetre synchronis´es par rapport `a leurs maˆıtres. De mani`ere

g´en´erale, un flux qui est plus sensible aux d´esynchronisations intra-flux est choisi comme flux maˆıtre. Par exemple, dans le cas d’un contenu audiovisuel, le flux audio est consid´er´e maˆıtre et le flux vid´eo son esclave. Lorsqu’il n’existe aucune d´ependance entre les flux d’une pr´esentation multim´edia, chaque flux est d´elivr´e seulement sous les contraintes de synchronisation intra-flux.

La synchronisation des m´edia est ´etroitement li´ee `a la perception humaine. En cons´equence, il est utile de d´efinir certaines limites au-del`a desquelles la d´esynchronisation devient perceptible. Steinmetz pr´esente en [Ste96] les r´esultats d’une s´erie d’exp´erimentations sur la d´esynchronisation des m´edia vis-`a- vis de la perception humaine. Ces r´esultats peuvent ˆetre utilis´es comme des indicateurs pour la qualit´e d’une pr´esentation du point de vue de la synchronisation. Par exemple, la synchronisation lip sync doit ˆ

etre maintenue dans les limites±80ms. Par contre, lorsque la vid´eo est combin´ee avec une animation ou avec un texte juxtapos´e, elle devient moins sensible aux d´esynchronisations, les limites dans ces deux cas ´

etant de ±120ms et respectivement ±240ms.

Synchronisation de groupe

Pour une application multim´edia ex´ecut´ee dans un contexte de communication multicast, outre le besoin de synchronisation intra et inter-flux, il existe un nouveau type de synchronisation qui doit ˆetre pris en compte. Alors que la synchronisation intra et inter-flux pr´eserve les relations temporelles entre les unit´es d’acc`es au sein d’un flux et, respectivement, entre plusieurs flux appartenant `a la mˆeme source, la synchronisation de groupe concerne la pr´esentation synchrone et coh´erente des flux ´echang´es parmi tous les participants.

Les communications multicast se divisent en deux cat´egories distinctes :

1. Le mod`ele SSM (Single Source Multicast) fournit une s´emantique de 1 vers n. Il est plutˆot destin´e `a la diffusion du contenu puisqu’un seul membre peut ´emettre des donn´ees `a destination du groupe. De par sa d´efinition, le mod`ele SSM est utilis´e plutˆot par les applications multim´edia non interactives. Dans ce type de communication, tout comme dans le cas d’une communication point `a point, seules les synchronisations intra et inter-flux doivent ˆetre trait´ees.

2. Le mod`ele ASM (Any Source Multicast) offre une communication ouverte o`u chaque membre du groupe peut ˆetre `a la fois ´emetteur et r´ecepteur (communication dite de n vers m). Ceci est un mod`ele ad´equat pour les applications interactives, tout en ´etant le plus complexe.

Quelques exemples Parmi les applications n´ecessitant la mise en œuvre d’un m´ecanisme de synchro-

nisation de groupe, nous en citons deux : l’enseignement `a distance et le streaming interactif pr´esent´e pr´ec´edemmment dans la section 4.1.3. Pour l’enseignement `a distance, il est n´ecessaire de pr´esenter parall`element, `a tous les ´etudiants, le flux audio (transmis en direct) contenant les commentaires de l’enseignant et le flux vid´eo (enregistr´e) correspondant au contenu ´educatif. A ces deux flux peuvent s’ajouter, de mani`ere int´eractive, les flux audio issus des interventions des ´etudiants.

D’autres exemples sont les applications de t´el´econf´erence ainsi que le t´el´eorchestre pr´esent´e dans la figure 4.6. Dans une t´el´econf´erence, un groupe d’utilisateurs souhaitent avoir une r´eunion virtuelle. Cha- cun envoie ses propres flux audio/vid´eo et re¸coit les flux des autres membres du groupe. Id´ealement, `

a tout instant, tous les participants doivent avoir la mˆeme vue des flux ´echang´es. En r´eparti, il suffit d’assurer au moins une vue coh´erente `a chaque participant, conforme avec l’ordre d’interactions (inter- ventions des utilisateurs). Pour une application de t´el´eorchestre, un ensemble de musiciens et un chef d’orchestre, g´eographiquement repartis, jouent ensemble une pi`ece musicale pour une audience sur In- ternet. Dans ce cas, les contraintes sont plus strictes, les flux venant du chef d’orchestre doivent ˆetre pr´esent´es simultan´ement `a tous les musiciens.

Internet

Musicien Musicien

Audience Chef d’orchestre

Fig. 4.6 – Une application de t´el´eorchestre

Enfin, notre cas d’´etude, d´ecrit dans la section 4.1.3 (match de football), illustre les types de syn- chronisation qui viennent d’ˆetre ´evoqu´es, `a plusieurs niveaux :

– Synchronisation intra-flux pour les flux vid´eo et audio diffus´es respectivement depuis les sites A et B. En outre, si le flux vid´eo avait ´et´e comment´e depuis sa source `a travers un deuxi`eme flux audio, il aurait ´et´e n´ecessaire d’assurer la synchronisation inter-flux entre ces deux flux. Ces deux types de synchronisation sont souvent g´er´es au niveau de la couche collaboration dans le mod`ele coop´eratif d´ecrit dans la section 4.1.2.

– Synchronisation de groupe entre le flux vid´eo diffus´e depuis A et le flux audio diffus´e depuis le site B. Situ´ee au niveau de la couche coordination dans le mod`ele coop´eratif, la tˆache de synchronisation de groupe doit assurer que les flux soient pr´esent´es de mani`ere coh´erente pour empˆecher une d´elivrance incorrecte comme celle illustr´ee dans la figure 4.2.

Dans le document Supervision de contenus multimédia : adaptation de contenu, politiques optimales de préchargement et coordination causale de flux (Page 94-98)