Chrome 47 WebRTC: enregistrement multimédia, origines sécurisées et gestion des proxys

Sam Dutton

Chrome 47 inclut plusieurs améliorations et mises à jour importantes de WebRTC.

Enregistrer des vidéos depuis vos applications Web

L'API MediaStreamRecorder est depuis longtemps la requête la plus populaire sur chromium.org, avec plus de 2 500 étoiles. L'enregistrement multimédia a été ajouté à Chrome derrière le commutateur "Experimental Web Platform features", mais il n'est disponible que sur ordinateur pour le moment. Cela vous permet d'enregistrer, de lire ou de télécharger des vidéos. Une démo simple est disponible dans le dépôt d'exemples WebRTC. Pour en savoir plus, consultez l'annonce discuss-webrtc. Un exemple d'application Chrome permettant d'enregistrer des vidéos à partir de captures d'écran est disponible sur github.com/niklasenbom/RecordingApp. Il s'agit d'implémentations entièrement nouvelles. Il est donc possible que des bugs subsistent. Veuillez signaler les problèmes que vous rencontrez dans les dépôts.

Capture d'écran de la démo MediaRecorder sur le dépôt d'exemples WebRTC GitHub

Sélection du périphérique de sortie audio

MediaDevices.enumerateDevices() a été publié. Pour en savoir plus, consultez le problème 504280 de Chromium. Vous pouvez désormais énumérer les périphériques de sortie audio en plus des périphériques d'entrée audio et vidéo que MediaStreamTrack.getSources() fournit déjà. Pour en savoir plus sur son utilisation, consultez cet article.

Appareils compatibles sous Windows

La prise en charge du périphérique de communication par défaut sur Windows a été ajoutée. Cela signifie que lors de l'énumération des périphériques audio sous Windows, une entrée supplémentaire sera ajoutée pour le périphérique de communication, dont l'ID sera "communications".

Les ID d'appareil pour le périphérique audio par défaut (et les communications sur Windows) ne seront plus hachés (problème 535980). En revanche, deux ID réservés, "default" et "communications", sont acceptés et sont identiques pour toutes les origines de sécurité. Les libellés des appareils seront traduits dans la langue du navigateur. Les développeurs ne doivent donc pas s'attendre à ce que les libellés aient une valeur prédéterminée. La précision du rendu vidéo a été améliorée en propageant le code temporel de capture jusqu'à l'algorithme de rendu, où la bonne synchronisation verticale peut être choisie en fonction de celui-ci. Pour la plate-forme Windows, l'horodatage de la capture est également plus précis dans Chrome 47.

Gestion des proxys

Chrome 47 ajoute une nouvelle préférence permettant de forcer le trafic WebRTC à transiter par un serveur proxy local, si un serveur est configuré. Cette fonctionnalité est importante pour certains utilisateurs qui naviguent via un VPN. Cela signifie que l'application WebRTC ne verra que l'adresse IP du proxy. Sachez que cela nuira aux performances de l'application et ne fonctionnera pas du tout, sauf si l'application est compatible avec TURN/TCP ou ICE-TCP. Une nouvelle version de l'extension WebRTC Network Limiter sera bientôt disponible pour fournir une interface utilisateur pour cette préférence. Pour en savoir plus sur la "fuite" d'adresses IP, consultez What's Next for WebRTC.

Extension Chrome WebRTC Network Limiter

…et bien plus

Le débit du canal de données a été considérablement amélioré pour les connexions à latence élevée.

Nous allons déployer progressivement la prise en charge de DTLS 1.2 dans Chrome 47.

Bien que ni VP9 ni H.264 ne soient pris en charge dans cette version, nous continuons à travailler sur ces formats. Nous espérons implémenter la prise en charge de VP9 et d'une version initiale de H.264 (derrière un indicateur) dans Chrome 48.

Messages d'intérêt public

  • À partir de Chrome 47, les requêtes getUserMedia() ne sont autorisées que depuis des origines sécurisées : HTTPS ou localhost.
  • La compatibilité avec le canal de données RTP a été supprimée. Toutes les applications restantes qui utilisent encore des canaux de données RTP doivent utiliser les canaux de données standards à la place.

Comme pour toutes les versions, nous encourageons les développeurs à essayer Chrome sur les canaux Canary, Dev et Bêta, et à signaler tout problème rencontré. L'aide que nous recevons est inestimable. Pour savoir comment rédiger un bon rapport de bug, veuillez consulter la page sur les bugs WebRTC.

Démonstrations

En savoir plus