Chrome 47 WebRTC: Medienaufzeichnung, sichere Quellen und Proxy-Handhabung

Dutton

Chrome 47 enthält mehrere wichtige WebRTC-Verbesserungen und -Updates.

Videos aus Web-Apps aufnehmen

Die MediaStreamRecorder API ist mit über 2.500 Sternen seit Langem die Top-Anfrage von chromium.org. Die Medienaufzeichnung wurde Chrome jetzt hinter der Markierung für experimentelle Webplattform-Funktionen hinzugefügt. Derzeit ist das allerdings nur für Desktop-Computer verfügbar. Damit kannst du Videos aufnehmen und abspielen oder herunterladen. Zum WebRTC-Beispiel-Repository gibt es eine einfache Demo. Mehr dazu erfahren Sie in der Diskussions-Webrtc-Ankündigung. Unter github.com/niklasenbom/RecordingApp finden Sie eine Chrome-Beispiel-App zum Aufzeichnen von Videos per Bildschirmaufnahme. Diese Implementierungen sind komplett neu und es kann noch Fehler geben, die behoben werden müssen. Wenn Probleme auftreten, melde sie bitte in den Repositories.

Screenshot der MediaRecorder-Demo im WebRTC-GitHub-Beispiel-Repository

Auswahl des Audioausgabegeräts

MediaDevices.enumerateDevices() wurde freigegeben. Weitere Informationen finden Sie unter Chromium-Problem 504280. Du kannst jetzt zusätzlich zu den bereits von MediaStreamTrack.getSources() bereitgestellten Audio- und Videoeingabegeräten eine Liste aller Audioausgabegeräte erstellen. Weitere Informationen zur Verwendung findest du in diesem Update.

Geräteunterstützung unter Windows

Unter Windows wurde jetzt eine Standardunterstützung für Kommunikationsgeräte hinzugefügt. Das bedeutet, dass bei der Aufzählung von Audiogeräten unter Windows ein zusätzlicher Eintrag für das Kommunikationsgerät vorhanden ist, dessen ID „Kommunikation“ lautet.

Geräte-IDs für das Standardaudiogerät (und die Kommunikation unter Windows) werden nicht mehr gehasht (Problem 535980). Stattdessen werden zwei reservierte IDs unterstützt, „Standard“ und „Kommunikation“, und sind für alle Sicherheitsursprünge identisch. Gerätelabels werden in die Browsersprache übersetzt. Daher sollten Entwickler nicht davon ausgehen, dass Labels einen vordefinierten Wert haben. Die Genauigkeit des Video-Renderings wurde verbessert, indem der Erfassungszeitstempel bis zum Rendering-Algorithmus an den Rendering-Algorithmus weitergegeben wurde. Dort kann dann das richtige Vsync-Verfahren ausgewählt werden. Auf der Windows-Plattform ist der Erfassungszeitstempel in Chrome 47 auch genauer.

Proxybehandlung

In Chrome 47 gibt es eine neue Einstellung, mit der WebRTC-Traffic über einen lokalen Proxyserver gesendet werden soll, sofern ein solcher konfiguriert ist. Dies ist für manche Nutzer, die über ein VPN surfen, wichtig. Das bedeutet, dass die WebRTC-Anwendung nur die Proxy-IP-Adresse sieht. Beachten Sie, dass dies die Leistung der Anwendung beeinträchtigt und nur dann funktioniert, wenn die Anwendung TURN/TCP oder ICE-TCP unterstützt. Demnächst gibt es eine neue Version der WebRTC Network Limiter Extension, die eine UI für diese Einstellung bietet. Weitere Informationen zum Verlust von IP-Adressen finden Sie unter Nächste Schritte für WebRTC.

Chrome-Erweiterung „WebRTC Network Limiter“

...und mehr

Der Datenkanaldurchsatz wurde für Verbindungen mit hoher Latenz stark verbessert.

Die Unterstützung für DTLS 1.2 wird im Zeitraum von Chrome 47 nach und nach eingeführt.

Auch wenn in dieser Version weder VP9 noch H.264 unterstützt werden, arbeiten wir weiter daran. Wir hoffen, die Unterstützung für VP9 und eine erste Version von H.264 (hinter einer Markierung) in Chrome 48 implementieren zu können.

Öffentliche Mitteilungen

  • Ab Chrome 47 sind getUserMedia()-Anfragen nur von sicheren Ursprüngen erlaubt: HTTPS oder localhost.
  • Die Unterstützung für RTP-Datenkanäle wurde entfernt. Alle verbleibenden Anwendungen, die noch RTP-Datenkanäle verwenden, sollten stattdessen die Standarddatenkanäle verwenden.

Wie bei allen Versionen empfehlen wir Entwicklern, Chrome in den Canary-, Entwickler- und Beta-Versionen auszuprobieren und etwaige Probleme zu melden. Die Hilfe, die wir erhalten, ist von unschätzbarem Wert. Hinweise zum Einreichen eines guten Fehlerberichts finden Sie auf der WebRTC-Fehlerberichtsseite.

Demos

Weitere Informationen