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

Sam Dutton

Chrome 47 enthält mehrere wichtige Verbesserungen und Updates für WebRTC.

Video aus Ihren Web-Apps aufnehmen

Die MediaStreamRecorder API ist mit über 2.500 Sternen schon lange die am häufigsten gewünschte Funktion auf chromium.org. Die Medienaufzeichnung wurde jetzt in Chrome hinter dem experimentellen Flag „Web Platform features“ hinzugefügt. Sie ist derzeit jedoch nur auf Computern verfügbar. So können Sie Videos aufzeichnen, wiedergeben oder herunterladen. Im WebRTC-Beispiel-Repository finden Sie eine einfache Demo. Weitere Informationen finden Sie in der discuss-webrtc-Ankündigung. Eine Beispiel-Chrome-App zum Aufzeichnen von Videos per Bildschirmaufnahme ist unter github.com/niklasenbom/RecordingApp verfügbar. Da es sich um brandneue Implementierungen handelt, können noch Fehler auftreten. Melden Sie Probleme bitte in den entsprechenden Repositories.

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

Auswahl des Audioausgabegeräts

MediaDevices.enumerateDevices() wurde veröffentlicht. Weitere Informationen Sie können jetzt zusätzlich zu den Audio- und Videoeingabegeräten, die MediaStreamTrack.getSources() bereits bereitstellt, auch Audioausgabegeräte auflisten. Weitere Informationen zur Verwendung

Geräteunterstützung unter Windows

Es wurde Unterstützung für das Standardkommunikationsgerät unter Windows hinzugefügt. Das bedeutet, dass bei der Auflistung von Audiogeräten unter Windows ein zusätzlicher Eintrag für das Kommunikationsgerät mit der ID „communications“ vorhanden ist.

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: „default“ und „communications“. Diese sind für alle Sicherheitsursprünge gleich. Gerätelabels werden in die Browsersprache übersetzt. Entwickler sollten daher nicht davon ausgehen, dass Labels einen bestimmten Wert haben. Die Genauigkeit des Video-Renderings wurde verbessert, indem der Aufnahme-Zeitstempel bis zum Rendering-Algorithmus weitergegeben wird, sodass der richtige VSync basierend darauf ausgewählt werden kann. Unter Windows ist der Erfassungszeitstempel in Chrome 47 ebenfalls genauer.

Proxy-Verarbeitung

In Chrome 47 wurde eine neue Einstellung hinzugefügt, mit der WebRTC-Traffic über einen lokalen Proxyserver gesendet werden kann, sofern ein solcher konfiguriert ist. Das ist für einige Nutzer wichtig, die über ein VPN surfen. Das bedeutet, dass die WebRTC-Anwendung nur die Proxy-IP-Adresse sieht. Dies beeinträchtigt die Anwendungsleistung und funktioniert nur, wenn die Anwendung TURN/TCP oder ICE-TCP unterstützt. Demnächst wird eine neue Version der WebRTC Network Limiter Extension veröffentlicht, die eine Benutzeroberfläche für diese Einstellung bietet. Weitere Informationen zum „Durchsickern“ von IP-Adressen finden Sie unter What's Next for WebRTC.

Chrome-Erweiterung „WebRTC Network Limiter“

…und mehr

Der Durchsatz des Datenkanals wurde für Verbindungen mit hoher Latenz erheblich verbessert.

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

Weder VP9 noch H.264 werden in dieser Version unterstützt. Wir arbeiten jedoch weiter daran und hoffen, in Chrome 48 Unterstützung für VP9 und eine erste Version von H.264 (hinter einem Flag) implementieren zu können.

Öffentliche Mitteilungen

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

Wie bei allen Releases empfehlen wir Entwicklern, Chrome in den Canary-, Entwickler- und Beta-Versionen auszuprobieren und alle gefundenen Probleme zu melden. Die Hilfe, die wir erhalten, ist unschätzbar wertvoll. Hinweise zum Erstellen eines guten Fehlerberichts finden Sie auf der WebRTC-Fehlerseite.

Demos

Weitere Informationen