ORTC dans Edge – Êtes-vous prêt pour le tsunami ?

[post original : septembre 2015]

Mon twitter est en feu ! C’est une des nouvelles les plus attendues dans l’écosystème, et pour beaucoup, mais pas tous, elle est arrivée bien plus tôt que prévu.

I. Historique et contexte

Plus tôt cette année, en parlant à la conférence WebRTC de NTT à Tokyo, j’ai cité ORTC comme une possibilité pour 2015 (voir transparents numéros #17 et #30). Plus tard, à la réunion WebRTC en juin à San Francisco hébergée par TokBox, j’ai répété cette prédiction qui correspondait à ce que tout le monde pensait (autour de 1:45). La sortie de l’API GetUserMedia, plus tôt, en mai, aurait dû être un indice. Je me trompais.

Pendant les mois d’août et de septembre, de plus et plus d’indices dans l’écosystème nous signalaient une livraison (plus) rapide de ORTC dans Edge. Beaucoup de questions restaient ouvertes : quel codec sera utilisé, à quel point l’API d’ORTC sera proche de l’API de WebRTC-NV, etc. Actuellement, quelques-unes de ces questions sont toujours sans réponse. En septembre, il est devenu clair que tout était fait et prêt, ce qui a ravi quelques développeurs, mais certains membres du comité de standardisation l’étaient moins. Ça doit commencer à donner du sens au fait que j’ai choisi de passer une semaine à Redmond avant la réunion W3C :-).

II. Les faits

Le 18 septembre 2015, Microsoft a annoncé la disponibilité d’ORTC pour les membres du Microsoft Insider Program. Ils l’ont annoncé à beaucoup d’endroits, mais principalement sur les blogs Windows/Edge et Office/Skype. Sur la page officielle de Microsoft, une démo avec Twilio était disponibe. Le même jour, des posts sur le blog webrtchacks et à d’autres endroits très visibles ont commencé à apparaître. Très clairement, certains étaient dans la confidence, comme l’a laissé transparaître leur langage corporel quand le sujet est arrivé sur la table au Kranky geek show.

Quand ce post a été écrit, SimpleRTC (avec sa  démo supportant uniquement l’audio et Chrome pour l’instant) et ortc-adapter de Twilio permettaient déjà l’interopérabilité entre WebRTC et ORTC.

Comme annoncé par Bernard Aboba au Kranky & Geek show, et comme je l’ai signalé sur le fil de discussion correspondant de la mailing list webrtc-discuss, Microsoft prévoit de proposer d’abord sa propre version de 264 SVC, appelée 264UC. Pour les développeurs de média hardcore qui connaissent déjà 264 AVC/SVC et veulent voir la différence avec 264UC, allez ici. Ensuite c’est H.264 standard (AVC) qui sera supporté pour assurer l’interopérabilité avec Firefox et Chrome. Actuellement 264 est déjà supporté par la bibliothèque libwebrtc à travers les API des OS pour WebRTC dans ChromeOS, Android et iOS , il n’y a que Chrome pour ordinateur de bureau qui ne le supporte pas, ce qui fait l’objet d’un bug ouvert et déjà affecté. En bref, ils travaillent dessus au moment où je vous parle et des patchs sont déjà disponibles.

current Skype design – ORTC

Dans l’intervalle, Microsoft prévoit d’utiliser un serveur média pour transcoder entre les différentes variétés de H.264, comme illustré ci-dessus.

III. Conséquences et discussion

A. À court terme

Premièrement et avant toute chose, allez lire l’article du webrtchacks pour avoir une rapide vue d’ensemble de ce dont vous aurez besoin pour réaliser un simple appel 1:1. Prenez une aspirine et revenez ici.

L’API d’ORTC est plus complexe, et comme elle est de plus bas niveau, vous devez définir beaucoup plus de choses que ce que demande l’API WebRTC pour aboutir au même cas d’usage. Les avantages de cette API ne deviennent évident que pour des cas plus complexes comme la manipulation de codecs, les connections avec des serveurs média, les conférences a plusieurs avec une seule peer-connection, le simulcast, les codecs SVC… Pour beaucoup, ça devient juste absurde et superflu. Dans ce cas, utilisez un shim comme ortc-adapter de twillio. Il est très probable, dans une première étape, que la majorité des fournisseurs mettent à jour leur JS SDK dans les semaines à venir pour faire juste ça. Note : ça ne marchera que pour l’audio, donc préparez quelques aspirines pour les développeurs web qui vont devoir gérer tous les navigateurs et tous les média.

Si vous utilisez un plugin pour Internet Explorer, assurez-vous que votre marché en a besoin. Le marché d’entreprise devrait en avoir besoin car il est prisonnier des vieilles versions d’Internet Explorer, mais les sites internet sociaux et classiques peuvent s’en passer. De plus, les deux principaux plugins restent bloqués sur des versions anciennes des spécifications (avant les promesses et d’autres choses qui ont été ajoutées il y a environ 6 mois), et ne montrent aucun signe de préparatifs pour supporter les 30 nouveaux objets créés par l’API ORTC et WebRTC NV .

B. À moyen/long terme

Il y a deux questions principales que vous devez vous poser pour le long terme.

  1. Suis-je limité de quelque manière que ce soit par les API WebRTC ?

Si vous avez déjà tout ce que vous voulez, utilisez juste un shim. Si vous êtes limité en termes de contrôle de réseau (sécurité ou bande passante), codec, nombre de flux, etc, alors ORTC ou WebRTC NV va vous apporter quelque chose. Si vous utilisez un serveur média, il y a aussi de grandes chances que les nouvelles API vous soient bénéfiques.

2. À quel point WebRTC et ORTC sont-elles convergentes ?

C’est la question clé. Si j’attend, ces problèmes d’interopérabilité vont-ils devenir plus simple ou même disparaître ? En tous cas, beaucoup de développeurs JS acceptent un certain degré d’incompatibilité, mais l’incompatibilité sur le fil n’est pas quelque chose que vous pourrez traiter au niveau de JS, donc nous avons ici un réel problème.

Les premiers exemples et démos semblent indiquer que l’interopérabilité est déjà une réalité, du moins en ce qui concerne la signalisation, API et l’audio. Tant que Microsoft ne supportera pas H.264, l’interopérabilité pour la vidéo restera un point d’interrogation.

Finalement, je ne connait personne qui ait consulté les API WebRTC / WebRTC NV / ORTC pour vérifier à quel point elles sont vraiment différentes. Mon sentiment est qu’elles sont suffisamment proches pour que la magie JS les fasse disparaître, mais je ne l’ai pas encore testé.

IV Conclusion

Depuis août, il était évident pour beaucoup que cela allait arriver. Dans ma plus récente présentation (publique), ma dernière diapositive était claire (diapositive #12) : ORTC est une super API, et elle est nécessaire pour beaucoup de cas d’utilisations, mais beaucoup de vendeurs ne sont pas prêts pour le tsunami et la masse de travail nécessaire pour supporter tout ça.

Ma prévision était et reste que l’écosystème WebRTC PaaS va rétrécir de 25% (en nombre de compagnies) car les plus petites sont déjà très très maigres, dans un marché ou la traction reste l’exception et où le financement reste difficile à trouver. Les vendeurs de plugins pour Internet Explorer seront encore plus impactés, du fait que le marché devient plus petit, et ils vont avoir besoin de différentes sources de traction pour espérer récupérer de l’argent. Nous vivons des temps intéressants.

La guerre pour les talents webrtc

Dans le petit monde du logiciel innovant (Bay Area Fever), les financements ne sont pas difficile à trouver. Il y a beaucoup d’argent autour, BEAUCOUP! Autour de 23% de tout les financements aux USA (47+ milliards) venaient, l’année dernière, de compagnies de SF.

La valeur n’est pas tant associé au capital, mais aux compétences des gens qui vont récupérer ce capital et  faire en sorte que la valeur financière originale soit multipliée. Le capital n’a de valeur que le jour où vous le récupérez, les compétences de l’équipe ont une valeur pour le futur de la compagnie.

L’ingénieur et le chercheur en moi se sent comme à la maison. Si vous faites une différence, vous n’êtes pas un simple employé qui fait son boulot et récupère son salaire, vous êtes quelqu’un qui prends un financement d’un demi million et le transforme en quelque chose qui vaut 20+ millions.

Les chefs intelligents savent ça très bien. Le talent est la clé de la crédibilité, de l’execution et de l’évaluation. Ce n’est pas une surprise que la course aux talents dans la vallée soit devenue une guerre. (ici, ici, ici ). Cela est bon et sain. Les clauses de non concurrence sont par ailleurs illégales en Californie, pour protéger les talents, qui seraient prives d’opportunités. Le temps où Apple et ses concurrents se mettaient d’accord pour ne pas se « piquer » les talents les uns les autres est révolu.

Dans un post précédent, j’ai pointé du doigt certains produits et/ou individus dans l’écosystème webrtc que j’estimais etre exceptionnels. Ca ne surprendra aucun lecteur que l’un des ingénieurs les plus en vu, le numéro un des chercheurs webrtc, hors google et mozilla, Philippe Hancke, ait sauté le pas et ai rejoint Tokbox.

Je voudrais bien croire qu’il a eu peur quand je lui ai dit que nous, à Citrix, allions contester sa suprématie de chercheur en 2016, et qu en reaction il s’est associé avec le numéro 2, je pense que la raison est toute autre. Tokbox a, aujourd’hui, le WebRTC PaaS le plus mature, avec une visibilité totale et en temps réel sur tout ce qui se passe, le genre de visibilité qui permettra à un ingénieur remarquable de faire la différence, ce qui est important pour lui et donc fait rentrer de l’argent, ce qui est important pour Tokbox.

Dans tous les cas, dans la guerre qui se déroule à S.F., illustrée par example au travers de la guerre du sponsoring (je te sponsorise ton event si tu ne laisse pas l autre parler) entre twilio et tokbox pour les événements webrtc en 2015, Tokbox a définitivement gagné cette bataille.

Sérieux coup de chaleur pour WebRTC en Asie ce mois-ci.

Les points chauds pour WebRTC sont saisonniers.

La majorité des nouvelles sur WebRTC nous viennent des USA. Rencontres, événements, développements, levees de fond, tout pointe vers les Etats Unis d’Amérique, avec aussi une poignée de compagnies qui se battent pour que cela arrive un peu plus au nord ( salut à mes amis canadiens de hookflash, priologic, …). Plus récemment l’excellente conférence IIT’s Real-Time organisé simultanément avec tad hack mini a placé le centre de gravité de l’écosystème WebRTC à Chicago.

Régulièrement, le centre d’attention de la communauté webrtc se deplace en europe, habituellement Londres, ou a la conférence annuelle a Paris.

Il est nettement plus rare pour l’Asie de devenir, meme temporairement, le centre d’intérêt pour le petit monde de WebRTC. Malgrès les efforts de la brillante et pionnier Silvia Pfieffer et autres passionnés de webrtc à Sydney, ou la ténacité des japonnais: webrtc hackers de Tokyo, les activités liées a WebRTC en asie restent morcelées, chaque écosystème local ou national se limitant a ses  propres rencontres webrtc.

Nécessitant a la fois une belle collision entre les règles de rotation pour le lieux des meetings IETF, les dates des-dits meetings, et l’intérêt des sponsors industriels de gros événements commerciaux, faire de l’Asie le centre d’intérêt pour webrtc est beau qu’une éclipse (et à peu près aussi rare). Devinez quoi: Nous avons une éclipse ce mois-ci!

Le Japon démarre la fête ( 23 Oct~6 Nov)

Tous mes amis japonnais sont excités, depuis deux semaines non stop, le Japon sera le lieu de passage WebRTC:

  • Le 23 Octobre, pour la 18e édition de leur « HTML5 study meeting », techbuzz japan va se concentrer sur la dernière version de JS (ES6) et webrtc pour les communications en temps réel (en japonais),
  • La dernière semaine d’octobre (26~30), le meeting W3C TPAC, le meeting W3C le plus important de l’année, aura lieu a Sapporo au Japon. Moitié prix pour les nouveaux participants qui se rendront la semaine suivante au meeting IETF! Cela devrait finalement donner naissance aux spécifications les plus attendues de webrtc 1.0 pendant la session dédiée a webrtc les 29 et 30 octobre, avec un peu de chance, cela pourrait inclure simulcast (la plupart en anglais).
  • Le premier jour, il y aura une conférence sur le développement W3C à Sapporo (26 Octobre) (ici).
  • L’original « tokyo webrtc meetup #10 » le 29 Octobre (en japonnais) A ETE REMPLACE par l’événement du 4 Novembre.
  • Après un week-end passé à se remettre de ces discussions intenses, des APIs abstraites et de l’abus de sushis ( ou passé à profiter des folles soirées de l’halloween japonnais),le 94e meeting IETF aura lieu a Yokohama au Japon. Beaucoup de chance, comme d’habitude, pour cette semaine bien remplie, avec la session du groupe rtcweb le 3 et le 5. (la plupart en anglais).
  • Co-localisé avec IETF, mais ouvert à tous, le 4, un événement spécial prendra place en langue anglaise et va présenter les développements locaux. Google va présenter son plan de marche (un bis de la présentation de l’excentrique geek show), Citrix fournira des explications sur leur usage de webRTC, et plus: (en anglais avec des traducteurs japonnais)(ici).

La Chine suit en force (10~11 Nov)

Mes amis chinois sont encore plus excités quand à la première de la Conféfence WebRTC et infos vient à Pékin les 10 et 11 novembre! Plus orienté sur le business que la précédente, une piste spécifique sur la langue chinoise et une sur l’université (exécuté par les habituels Dan et Alan, co-auteurs de « the reference webrtc book, utilisé dans les cours des universités américaines, le couple le plus connu de l’industrie de webrtc).

La conférence prendra place dans le district de HaiDan (shopping de composants électroniques, quelqu’un?), plus spécifiquement à ZongGuancun, qui n’est pas simplement  la Silicon Valleyde Pékin (université numéro 1 et 2 de chine +  centres Oracle, Google, … ), mais est aussi à quelques blocs du principal quartier Coréen et du quartier étudiant de WuDaoKU avec tous les beaux restaurants pas cher, les karaokés et les clubs. Choisissez votre votre solution culinaire à Lushen regardant le croisement, et descendez de deux marches pour arriver au principal club de Pékin (il n’y a qu’en chine qu’un club peut s’appeler « propaganda »). Si les scènes de vies ne sont pas pour vous, vous êtes a quelques dollars en taxi du Summer Palace qui est à voir, pendant la journée.

Le grand finish à Singapour (12~22 Nov)

Mes amis singapouriens sont extatiques, alors que la JSConf.asia revient à Singapour cette année ( les 19 et 20 Novembre), avec une multitude de choses et événements annexes, de grands speakers, tout visible sous la Dev Fest Asia, étirant la fête des développeurs du web du 12 au 22 novembre. A part Monsieur Thomas Gorissen, l’organisateur ( et consultant pour skylink.io) « himself », plusieurs autres discutions webRTC/webaudio apparaissent au travers de l’agenda comme celle de Paul Adenot de Mozilla. Plus sur les intervenants sur le blog de l’événement.

Choisissez votre événement et venez rejoindre la fête, alors que la chaleur de webrtc frappe l’Asie ce mois-ci.

Modifications (patch) quasi automatiques de libwebrtc

I. Introduction

La plupart des logiciels utilisant libwebrtc ont besoin de pouvoir la modifier pour rajouter des fonctionnalités. Certain vendeurs, comme TokBox, vont  changer les paramètres (flags) de compilation de libvpx par example, pour activer le mode d’encodage par couche (SVC) de VP8 dans leurs SDKs mobiles, our avoir une meilleure qualité video. D’autres, tel que Voxeet, vont ajouter des codecs audio supplémentaires, dans leur cas pour emuler de l’audio 3D et reproduire le positionnement des participants dans une conference. Beaucoup, y compris pristine.io, vont vouloir ajouter H.264 pour etre compatibles avec les cartes graphiques de plus d’ordinateurs et de telephones.

Quel que soit le but, chacun aura besoin d’être capable de modifier de façon cohérente le code source d’une bibliothèque qui change souvent, tout en s’assurant que le nombre de patchs et la manière de les appliquer reste gérable dans le temps.

De plus, comme il s’agit d’un code public, il y a des patchs qu’on va proposer et qui profiteront à tous, mais certains utilisateurs pourraient vouloir créer leurs propres patchs privés et les garder pour eux par se différencier. L’architecture de la méthode de gestion des patchs doit permettre cela.

Finalement, juste pour le plaisir, je voulais disposer d’un mécanisme me permettant d’avoir rapidement des patchs à partir du processus de revue et d’integration de nouvelle fonctionnalistes de Google pour profiter de ces nouvelles fonctionnalités de libwebrtc avant même qu’elles n’apparaissent dans Chrome (ou pour tester ces patchs avec mon système).

Dans ce post, nous allons proposer une manière simple, mais efficace, pour aboutir à ce résultat.

II. Mise en œuvre

1. Commandes spécifiques CMake que nous allons utiliser

CMake dispose de la commande add_subdirectory(). Cette commande permet de parcourir l’arborescence du dossier mentionné en argument et à traiter tous les fichiers CMakeLists.txt qu’y s’y trouvent.

  1. add_subdirectory(Patches)

En conditionnant l’appel à cette commande vous pouvez concevoir une belle structure de dossier pour gérer vos patchs, par example selon le type de plateforme :

  1. if( APPLE )
  2.     add_subdirectory( mac )
  3. elseif( WIN32 )
  4.     add_subdirectory( win )
  5. endif()

2. Création des patchs et conditions spécifiques à libwebrtc

Le code source de libwebrtc est un patchwork de bibliothèques indépendantes qui sont récupérées en fonction des entrees dans le fichier DEPS a la racine. Bien que gclient ait une option pour générer des patchs globaux, nous préférons simplement utiliser git. Ainsi, chaque patch que vous générez est applicable à une arborescence git spécifique et vous devez savoir à quel endroit (racine du patch) l’appliquer.

Nous avons créé une macro CMake pour aider à automatiser cela :

  1. set_webrtc_patch_target(
  2.     GIT_APPLY_CMD
  3.     APPLY_DIR
  4.     PATCH
  5.     DEPENDS_ON_TARGET
  6. )

L’option DEPENDS_ON_TARGET nous permet d’être sûr que les patchs sont appliqués après le téléchargement du code.

Le GIT_APPLY_COMMAND apporte de la flexibilité à la commande git que vous utilisez. Certains vont préfèrer l’approche « git diff » / « git apply », alors que d’autres préfèreront « git format-patch » / « git am ». Dans notre cas nous gardons les choses simples :

  1. set(
  2.     GIT_APPLY_CMD
  3.     git apply –ignore-space-change –ignore-whitespace
  4. )

3. Comment exécuter une commande clean/undo

Le problème avec les patchs, c’est qu’ils laissent l’arborescence du code source modifie, ce que git n’aime pas.

Quand on utilise git, une façon de retourner à un état propre est faire un reset : « git reset –hard -q« . Cela ramènera tous les fichiers suivis par git dans un état propre, mais peut laisser des fichiers non suivis par git dans l’arborescence, par exemple si vous ajoutez de nouveaux fichiers ou si vous en supprimez d’autres. « git clean -qfdx »est donc nécessaire si vous voulez vous assurer que l’arborescence du code source est revenue dans l’état que vous souhaitez. Le code ressemble à ça :

  1. set( GIT_RESET_CMD git_reset –hard -q )
  2. set( GIT_CLEAN_CMD git clean -qfdx )

De plus, vous devez savoir à quel endroit de l’arborescence appliquer ces commandes, donc vous devez noter tous les répertoires où des patchs ont été appliqués. Pour chaque patch, nous allons ajouter dans une liste le répertoire auquel il s’applique. Quand le moment sera venu d’annuler l’application du patch, nous utiliserons cette liste :

  1. list(REMOVE_DUPLICATES PATCHED_DIRS) # enlève les doublons
  2. add_custom_target(
  3.     UNPATCH_ALL
  4.     ${CMAKE_COMMAND} -E touch dummy.phony
  5. )
  6. foreach( dir ${PATCHED_DIRS} )
  7.   add_custom_command(
  8.     TARGET                                UNPATCH_ALL           POST_BUILD
  9.     COMMAND                         ${GIT_RESET_CMD}
  10.     COMMAND                         ${GIT_CLEAN_CMD}
  11.    WORKING_DIRECTORY   ${WebRTC_SOURCE_DIR}/${dir}
  12.    COMMENT                          « Unpatching ${dir} »
  13.  )
  14. endforeach()

4. Comment intégrer mes patchs privés/propriétaires ?

Avec la commande add_subdirectory() les choses sont relativement simples. Le code ci-dessous vérifie s’il existe un sous-répertoire « PvtPatches » et s’il y en a un, rentre dedans. Vous pouvez utiliser les sous-arborescences git, ou la méthode de votre choix, pour avoir dans votre copie locale un tel répertoire, avec un CMakeFiles copié (hum… largement inspiré) de celui dans Patches et tout sera pour le mieux.

  1. if(EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/PvtPatches)
  2.     add_subdirectory(pvtPatches)
  3. endif()

Notez qu’une attention particulière a été portée à la variable qui contient la liste des répertoires sur lesquels appliquer la commande de reset et de nettoyage, pour que vous puissiez la modifier de l’intérieur des sous-répertoires et qu’elle reste valide. L’option « CACHE » vous assure de la cohérence à travers tout le projet quel que soit le répertoire source. L’option « INTERNAL » est ici pour pour s’assurer que cette variable n’apparaîtra pas dans l’interface graphique qui est distribuée avec CMake.

  1. set( PATCHED_DIRS «  » CACHE INTERNAL « Internal variable. »)

Bien entendu, vous êtes susceptible de devoir relancer l’outil de génération de compilation après avoir appliqué les patchs :

  1. python /src/webrtc/build/gyp_webrtc.py

III. Conclusion

Vous avez vu dans ce post comment installer un système de patchs simple pour libwebrtc. Bien sûr, ce ne serait pas complet sans quelques examples. Nous laissons a titre d exercice pour le lecteur, l’intégration de quelques patchs Google :

  • support pour openH264 (patch)
  • support pour les rendus d’images AVFoundation pour Mac (patch)

Cheers.

Alex

Tableau de bord « tout au vert », un bug à la fois

I. Introduction

Les bibliothèques précompilées pour la version stable de WebRTC (celles utilisées dans Chrome) ont été souvent réclamées dans la mailing list, mais jusqu’à maintenant personne ne s’est attelé à la tâche de les générer. Un des buts de ce blog est de fournir ces bibliothèques afin de réduire la barrière d’entrée pour ceux qui voudraient construire au-dessus de WebRTC.

Comme je préparais les bibliothèques sous Linux, je suis à nouveau tombé sur le test défaillant que j’ai mentionné dans un post précédent:

« La première erreur semble être liée à une mauvaise allocation mémoire. C’est là que vous réalisez que lancer la compilation sur la plus petite instance possible de Linux dans AWS était probablement une mauvaise idée. Ce problème devrait disparaître lorsque je lancerais le build bot de Linux sur une instance plus grosse. La deuxième erreur est plus subtile, et je ne peux pas la comprendre juste à partir des « logs ». Lorsque j’aurais installé une instance de compilation plus puissante pour Linux, je débuggerais directement dessus. »

En ce qui me concerne, avoir ne serait-ce qu’un seul test défaillant n’est pas acceptable. J’ai donc creusé plus profond. Voici la compilation avant les changements.

II. Investigations

Entre-temps, j’ai déplacé le build bot vers une plus grosse instance (c3.2x). Effectivement, la première erreur, qui était bien un problème d’allocation mémoire provoqué par une instance trop petite, a disparu sans que j’ai eu à m’en occuper.

La deuxième erreur était liée aux tests de partage d’écran, ce qui n’est pas une surprise puisque nous travaillons sur une machine virtuelle sans affichage.

Les tests originaux sont lancés par l’intermédiaire d’un contrôleur de tests écrit en Python. Le code de ce contrôleur, qui est séparé de libwebrtc, peut être trouvé ici. Le fichier principal est ici. Là encore, il s’agit d’un code venant de Chrome qui contient tout un tas de choses inutiles pour tester la version autonome de WebRTC (Chrome sandbox…).

Il fait aussi beaucoup de bonnes choses en terme de vérification de ce qui n’a pas été couvert par les tests précédents, dont certains ont pu échouer. Il y a de nombreuses étapes supplémentaires améliorant la stabilité et le robustesse des tests, ce n’est donc pas si mal.

Pour faire simple, pour résoudre le problème de l’absence d’écran sur une machine virtuelle, vous avez seulement à installer Xvfb et openbox :

  1. sudo apt-get install xvfb
  2. sudo apt-get install openbox

puis définir un affichage, le créer, et démarrer le gestionnaire de fenêtres openbox avant de lancer votre test (le code ci-dessous est conçu pour rester au plus proche des conditions de test de Google).

  1. export DISPLAY=:9
  2. Xvbf :9 -screen 0 1024x768x24 -ac -dpi 96&
  3. openbox&

Maintenant tous les tests passent !

III. Conclusion

Garder son tableau de bord « tout au vert » est de la plus haute importance. Si le tableau de bord a des voyants au rouge, ça signifie que vous développez les yeux bandés. Garder son tableau de bord « tout au vert » est un défi quotidien. Cela peut être perçu comme trop fastidieux d’avoir à y porter autant d’attention et d’efforts, mais c’est il s’agit en fait du filet de sécurité pour les développeurs qui vous permet de vous concentrer uniquement sur le développement.

Les avantages apportés par CMake ici sont doubles : d’une part abaisser la barrière d’entrée, et d’autre part fournir un tableau de bord collaboratif.

Encore une fois, certains peuvent estimer que les outils de compilation de Chrome, aussi bons et avancés qu’ils soient, sont une surenchère dans le but de produire seulement la libwebrtc autonome. Je crois que cela ralentit l’adoption et la contribution à WebRTC puisqu’il faut d’abord devenir un développeur Chromium, et pour celà la pente d’apprentissage est très raide.

Dans tous les cas, vous pouvez maintenant télécharger les bibliothèques et les en-têtes testés et précompilés pour Linux, Mac ou Windows depuis la page « Tools« . Si ce que vous désirez est juste de développer une application par-dessus libwebrtc qui fonctionne avec le dernier Chrome stable, vous avez tout ce qu’il vous faut maintenant.

Certaines personnes demandent des fonctionnalités qui ne sont pas, ou pas encore, dans WebRTC. Dans un prochain post, j’expliquerais comment faire pour appliquer sans effort un patch à libwebrtc dans le cadre du processus décrit précédemment.

Faites vous plaisir.