This post is also available in: English (Anglais)

Une version mise-à-jour de ce post est disponible ici.

Vous avez dit WebRTC ? Rappelez-moi de quoi il s’agit

WebRTC est un ensemble d’APIs et de protocoles sur lesquels travaillent les organismes de standardisation W3C et IETF et qui sont intégrés dans les navigateurs internet. Avec WebRTC, les développeurs peuvent ajouter rapidement à leurs applications web des fonctionnalités de communication temps réel pair-à-pair audio, vidéo et transfert de données grâce à des APIs JavaScript standardisées.

Actuellement WebKit ne supporte pas ce nouveau standard de communication. L’objectf du projet webrtcinwebkit.org est d’ajouter à WebKit le support de la technologie WebRTC, en commençant pas le portage WebKit GTK+ (Linux), au moyen de l’implémentation d’OpenWebRTC. L’essentiel du support de WebRTC sera implémenté dans le noyau de WebKit, donc il sera disponible pour tous les portages de WebKit. Ceci permettra également l’intégration d’autres bibliothèques WebRTC telle que celle de webrtc.org. Un autre objectif du projet webrtc-in-webkit est de rendre plus facile pour Apple l’ajout du support de WebRTC dans Safari et dans les apps sur iOS au travers de l’environnement WebView.

Ce matin j’ai tweeté à propos d’Apple qui a fini par décider d’ajouter à Safari le support de WebRTC et depuis j’ai été submergé de questions, c’est pourquoi je me mets à écrire ce post.

Les efforts passés et présents

Comme vous le savez, Stefan H  de Ericson R&D et chef du groupe de travail sur WebRTC @ W3C et moi-même nous avons été à l’origine de l’initiative du projet WebRTC dans WebKit. Adam B., l’équipe d’OpenWebRTC (Stefan A., Robert S…), Igalia and Centricular (Sebastian D.) ont été les principaux contributeurs à l’effort de codage, avec de petites contributions apportées par deux stagiaires Français que j’ai encadrés, Yin Liu de l’INSA Lyon (contribution à la partie canal de données), et Adam Tiamou de Polytech Grenoble (utilisation de webrtc.org à la place de OpenWebRTC).

Récemment, le projet a poussé la plus grande partie des classes de base de Media Streams et GetUserMedia dans le noyau de WebKit (webcore), comme décrit dans ce post du mois de juillet 2015.

La fin du post donnait des indications sur ce qui restait à fournir :

« Some things still need more work, like the Constraints mechanism and the functionality to enumerate local devices, but the foundation is now up to date and testable. »

Les navigateurs et les portages

WebKit est un moteur de rendu de pages web pour les navigateurs internet. Dans la communauté WebKit, chaque navigateur construit sur WebKit est appelé un « portage ». Le projet webrtc-in-webkit utilise le portage Linux (webkitGTK+) pour tester les implémentations de toutes les couches, même si en théorie tout ce qui se trouve dans WebCore est réutilisable par tous les portages. Depuis juillet 2015, vous pouvez tester getUserMedia dans le navigateur Linux.

Safari sur Mac est un autre portage, de même que Safari sur iOS. Le code de la couche interface utilisateur du navigateur Safari n’est pas disponible, il n’est accessible qu’aux employés d’Apple. Cependant vous pouvez recompiler WebKit et indiquer à Safari d’utiliser la DLL obtenue pour la tester.

Suite à la publication en juillet 2015 du code de webrtc-in-webkit d’Adam d’Ericsson couvrant tout le mécanisme générique pour MediaStream, Apple a travaillé dur pour apporter au code source les parties spécifiques à Apple comme le montrent trois choses visibles dans les commits d’Apple (voir ici la liste des commits extraits jusqu’au 28 septembre 2015) :

• changements spécifiques à macOS et à iOS
  • /platform/mediastream/mac
  • /platform/mac-mavericks/
  • /platform/mac-yosemite/
• changements qui font usage de l’API AVFoundation (AVVideoCaptureSource.h)
• changements qui utilisent la compilation de projet d’Apple uniquement (WebCore.xcodeproj/project.pbxproj)

Qu’est-ce qui est implémenté par Apple exactement ?

Pour avoir une information sur les différences d’implémentation de WebRTC selon les navigateurs et les différentes couches, vous pouvez consulter ces transparents.

En gros, Apple a simplement implémenté tout le mécanisme spécifique pour supporter GetUserMedia et MediaStream sur macOS et iOS. Il s’agit du support pour énumérer et sélectionner les composants audio et vidéo disponibles, du support pour les flux média en tant que source des éléments DOM <audio> et <video>, du support pour l’acquisition (à travers AVFoundation), du support pour les captures de MediaStreams…

Bien entendu, ceci a nécessité une implémentation robuste qui respecte les différentes couches logicielles des navigateurs. La capture et la gestion des médias a besoin d’être effectuée au niveau du navigateur pour pouvoir permettre le partage de flux entre onglets et pour assurer la suppression de l’écho de manière globale. Le rendu des images doit avoir lieu à l’intérieur d’un onglet, isolé des autres onglets par un sandbox, aussi une attention toute particulière a été apportée aux différentes couches logicielles et à l’échange de messages entre chaque couche.

En bref, avec ce code, toutes les fonctionnalités de GetUserMedia et MediaStreams semblent avoir été implémentées dans les portages Mac de WebKit. Ainsi c’est presque la totalité des spécifications de l’API des matériels qui sont plus avancées que les spécifications de WebRTC (connection pair-à-pair).

J’espère que ceci trouvera prochainement son chemin jusqu’à Safari, ou au moins dans le WebView pour iOS fourni par Apple.

La prochaine étape sera l’implémentation de la connection pair-à-pair et du canal de données qui sont des éléments de la spécification principale de WebRTC, mais qui sont sont encore à venir.