Simulcast sera-t-il dans WebRTC 1.0 ?

This post is also available in: English (Anglais)

Les 9 et 10 septembre, une réunion commune intermédiaire des groupes de travail WebRTC et Device API du W3C s’est tenue au siège de Microsoft à Redmond.

Les réunions intermédiaires, également appelées réunions « face-à-face » (quand elles n’ont pas lieu en Chine…), sont des réunions plus petites et plus ciblées qui se déroulent entre les grandes réunions pleinières, avec un programme précis pour faire avancer les choses plus vite. Les réunions IETF (3 par an) sont longues et peuvent être épuisantes. Les réunions du W3C, ou plutôt « la réunion » sans ‘s’ puisque seul le TPAC est technique, sont aussi très longues, mais surtout elles n’ont lieu qu’une seule fois par an. Certains voudraient pouvoir prendre des décisions plus rapidement, notamment quand le programme déborde de nouvelles fonctionnalités demandées par WebRTC 1.0. Ces réunions intermédiaires permettent d’obtenir des retours d’expérience et de prendre des décisions qui sont difficiles voire impossible à prendre par e-mail.

Plus tôt cette année, le groupe de travail WebRTC est arrivé au bout du temps qui lui était alloué et a demandé une extension au W3C. L’extension a été accordée sous la condition que la convergence entre le travail du groupe WebRTC et celui du groupe ORTC devienne plus qu’une réalité. Erik L. (de Hookflash) est devenu un des présidents du nouveau groupe WebRTC et la convergence entre les spécifications a été accélérée.

Cette réunion était dédiée, en particulier, à mettre à jour la liste des fonctionnalités que nous devrions avoir dans la version 1.0 ou à laisser pour plus tard, afin d’avoir une vision claire avant TPAC (fin octobre au Japon), de telle sorte que la réunion du TPAC se résume à la validation des décisions prises et qu’elle s’achève avec une liste stable des fonctionnalités pour la version 1.0.

Beaucoup de nouvelles APIs ont été expérimentées au sein du groupe ORTC (qui était composé de nombreux membres du groupe WebRTC), et Peter T. de Google par exemple est venu avec beaucoup de propositions sur la manière de concevoir ces nouvelles APIs. Celles-ci n’étaient pas trop controversées, étaient relativement petites, et tout s’est bien passé. La plupart des sujets abordés et les présentations correspondantes sont maintenant disponibles ici.

Puis nous avons parlé de simulcast.

La discussion sur simulcast a été…  intéressante. Comment faire pour diffuser sur le fil un même contenu encodé à différentes résolutions et différents débits binaires n’était pas vraiment un problème, quasiment tout le monde est d’accord sur ce qui doit être fait (même si Microsoft et Cisco ont un peu argumenté sur ce sujet). Le but ultime n’a pas non plus été un réel sujet de discussion. tout le monde est d’accord que nous devrions viser  une JS API qui permettrait non seulement le simulcast, mais aussi le codage vidéo scalable (SVC) plus tard, et que cette nouvelle API approuvée un peu plus tôt fasse le boulot. La principale préoccupation était la masse de travail et les efforts devant être mis en œuvre pour l’inclure dans WebRTC 1.0 sans retarder encore plus la version finale.

Il y avait deux aspects à cela. Premièrement, comme le simulcast touche à presque toutes les couches, depuis le fil jusqu’à la signalisation, la masse de travail pour le tester et le débugger sera plus importante qu’à l’habitude et Google était préoccupé sur sa capacité à le finir avant la fin de l’année. Deuxièmement, et en lien avec le premier point, la discussion a porté sur la manière de gérer la signalisation du simulcast.

Ici, nous ne sommes pas en train de parler du Plan B contre le plan Unifié, qui touchent à comment gérer la signalisation de flux multiples dans une seule PeerConnection, mais nous traitons de simulcast, qui est un sous-cas des flux multiples où les flux ne sont pas indépendants les uns des autres mais des variations (différentes résolutions, différents nombres d’images par seconde) de la même source. Le point clé, ici, c’est que vous ne voulez pas que ce soit le navigateur qui traite chacun de ces flux indépendamment. Par exemple, vous ne voulez PAS que le contrôle de congestion de la bande passante du navigateur ou que l’algorithme d’adaptation de la bande passante du codec modifie séparément la résolution du flux. Ce que vous voulez, c’est que, pour s’adapter à une bande passante trop faible, ce soit d’abord la résolution la plus haute qui soit éliminée, voire même que la transmission de la vidéo soit totalement interrompue pour privilégier la transmission du son. Ceci est possible avec des flux multiples indépendants, c’est également possible (conceptuellement) avec simulcast car vous connaissez la dépendance entre les flux.

La principale question à propos de simulcast a porté sur l’intérêt pour WebRTC de réutiliser le travail fait dans le groupe de travail IETF MMUSIC. Ce groupe est en charge du format SDP et il travaille actuellement sur une proposition spécialement conçue pour le simulcast. Pour certains, cela semblerait étrange de ne pas l’utiliser et de refaire leur travail. Mozilla, qui aurait déjà mis cela en œuvre dans Firefox, était un fervent supporter de son utilisation. Pour d’autres, étant donnée l’histoire du groupe MMUSIC, cette proposition risquerait de prendre trop de temps pour arriver à maturité et devenir une spécification. Google était tout particulièrement réticent à ajouter une dépendance normative supplémentaire à la spécification WebRTC sans avoir ni un contrôle ni même une visibilité sur le délai potentiel qui pourrait en résulter. Mettre l’accent sur la date limite pour aboutir à la version 1.0 et ne pas la repousser, surtout d’un délai indéfini. Comme la prochaine réunion IETF doit avoir lieu APRÈS le W3C TPAC, la probabilité que cette question soit traitée à temps pour la version 1.0 est ramenée à 0.

Comme tout le monde était d’accord sur ce qui est la bonne chose à faire, et que la seule inconnue était la capacité du groupe de l’IETF à rendre sa proposition à temps, deux membres du groupe de travail W3C qui sont également présidents du groupe IETF Rtcweb, nommés J. Cullen de CISCO et H. Peter de Google , ont contacté leurs homologues à MMUSIC pour voir si MMUSIC était intéressé pour organiser une réunion intermédiaire suffisamment tôt pour permettre à cette spécification d’aboutir et de la sortir de la liste des préoccupations actives. La réponse de MMUSIC est positive et ils se sont engagés à accélérer le processus sur la spécification SDP de simulcast.

Le chemin restant à parcourir pour avoir simulcast dans webrtc 1.0 reste semé d’embûches. D’abord MMUSIC doit converger sur les spécifications sdp-multicast, avec, espérons-le, un retour d’espérience de la part du groupe WebRTC. Ensuite, le groupe WebRTC du W3C avait accepté d’avoir une réunion virtuelle avant TPAC (dernière semaine d’octobre), avec un retour d’expérience de MMUSIC en main pour décider si on donne le feu vert pour inclure simulcast dans la version 1.0. Finalement, c’est au TPAC que seront présentés les retours d’expérience des premières mises en œuvre de simulcast et que sera prise la décision finale à propos de l’incorporation de simulcast dans WebRTC 1.0. Tout cela dans 5 semaines 😉

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Time limit is exhausted. Please reload CAPTCHA.