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 de chromium.org, avec plus de 2 500 étoiles. Les enregistrements multimédias ont été ajoutés à Chrome avec l'indicateur des fonctionnalités expérimentales de la plate-forme Web, bien que cette fonctionnalité ne soit disponible que sur ordinateur pour le moment. Cela vous permet d'enregistrer, de lire ou de télécharger une vidéo. Une démonstration simple est disponible sur le dépôt d'exemples WebRTC. Pour en savoir plus, consultez l'annonce discuss-webrtc. Vous trouverez un exemple d'application Chrome permettant d'enregistrer une vidéo à partir d'une capture d'écran à l'adresse github.com/niklasenbom/RecordingApp. Il s'agit de nouvelles implémentations, et il est possible que des bugs persistent. Si vous rencontrez des problèmes, veuillez les signaler sur le dépôt.

Capture d'écran de la démonstration de MediaRecorder dans le dépôt d'exemples GitHub WebRTC

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

Publication d'MediaDevices.enumerateDevices(). Pour en savoir plus, consultez le problème Chromium 504280. 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 déjà fournis par MediaStreamTrack.getSources(). Vous trouverez plus d'informations sur son utilisation dans cette mise à jour.

Compatibilité des appareils sous Windows

La prise en charge des appareils de communication par défaut sous Windows a été ajoutée. Cela signifie que lors de l'énumération des appareils audio sous Windows, il existe une entrée supplémentaire pour l'appareil de communication dont l'ID est "communications".

Les ID de l'appareil audio par défaut (et les communications sous Windows) ne seront plus hachés (problème 535980). À la place, deux ID réservés, "default" (par défaut) et "communications" (communications) sont acceptés et identiques pour toutes les origines de sécurité. Les étiquettes des appareils sont traduites dans les paramètres régionaux du navigateur. Les développeurs ne doivent donc pas s'attendre à ce qu'ils aient une valeur prédéterminée. La précision du rendu vidéo a été améliorée en propageant l'horodatage de la capture jusqu'à l'algorithme de rendu, où le bon vsync peut être choisi en fonction de cela. 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 pour forcer l'envoi du trafic WebRTC via un serveur proxy local, s'il est configuré, ce qui est important pour certains utilisateurs naviguant via un VPN. Cela signifie que l'application WebRTC ne verra que l'adresse IP du proxy. Sachez que cela nuit aux performances de l'application et qu'elle 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 proposer une UI pour cette préférence. Vous trouverez plus d'informations sur les "fuites d'adresses IP" dans la section Étapes suivantes pour WebRTC.

Extension Chrome WebRTC Network Limiter

...et bien plus encore

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

Nous déploierons progressivement la compatibilité avec DTLS 1.2 au cours de la période Chrome 47.

Bien que les versions VP9 et H.264 ne soient pas prises en charge dans cette version, nous continuons à travailler sur celles-ci. Nous espérons intégrer la prise en charge du 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 qu'à partir d'origines sécurisées: HTTPS ou localhost.
  • Les canaux de données RTP ne sont plus acceptés. 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 dans les versions Canary, en développement et bêta, et à signaler les problèmes détectés. L'aide que nous recevons est inestimable. Pour savoir comment envoyer un rapport de bug de qualité, consultez la page de bug WebRTC.

Démonstrations

En savoir plus