Chrome 47 zawiera kilka istotnych ulepszeń i aktualizacji WebRTC.
Nagrywanie filmów z aplikacji internetowych
MediaStreamRecorder API od dawna jest najpopularniejszym żądaniem na chromium.org, które ma ponad 2500 gwiazdek. Nagrywanie multimediów zostało dodane do Chrome za flagą eksperymentalnych funkcji platformy internetowej, ale na razie jest dostępne tylko na komputerach. Dzięki temu możesz nagrywać i odtwarzać filmy oraz je pobierać. Proste demo znajdziesz w repozytorium próbek WebRTC, a więcej informacji znajdziesz w ogłoszeniu na discuss-webrtc. Przykładowa aplikacja Chrome do nagrywania filmów z przechwytywania ekranu jest dostępna na stronie github.com/niklasenbom/RecordingApp. Są to zupełnie nowe implementacje, więc mogą w nich występować błędy. Jeśli napotkasz problemy, zgłoś je w repozytoriach.

Wybór wyjściowego urządzenia audio
MediaDevices.enumerateDevices() została opublikowana. Więcej informacji znajdziesz w zgłoszeniu 504280 dotyczącym Chromium. Oprócz urządzeń wejściowych audio i wideo, które są już dostępne w MediaStreamTrack.getSources(), możesz teraz wyliczać urządzenia wyjściowe audio. Więcej informacji o tym, jak z niej korzystać, znajdziesz w tym artykule.
Obsługa urządzeń w systemie Windows
Dodaliśmy obsługę domyślnego urządzenia komunikacyjnego w systemie Windows. Oznacza to, że podczas wyliczania urządzeń audio w systemie Windows pojawi się dodatkowy wpis dotyczący urządzenia komunikacyjnego, którego identyfikator będzie miał wartość „communications”.
Identyfikatory urządzeń domyślnych urządzeń audio (i komunikacji w systemie Windows) nie będą już szyfrowane (problem 535980). Zamiast tego obsługiwane są 2 zarezerwowane identyfikatory: „default” i „communications”. Są one takie same we wszystkich źródłach zabezpieczeń. Etykiety urządzeń zostaną przetłumaczone na język przeglądarki, więc programiści nie powinni oczekiwać, że będą miały z góry określoną wartość. Poprawiliśmy dokładność renderowania wideo, przekazując sygnaturę czasową rejestrowania do algorytmu renderowania, w którym na jej podstawie można wybrać odpowiednią synchronizację pionową. W przypadku platformy Windows sygnatura czasowa przechwytywania jest też dokładniejsza w Chrome 47.
Obsługa serwera proxy
W Chrome 47 dodaliśmy nowe ustawienie, które wymusza wysyłanie ruchu WebRTC przez lokalny serwer proxy (jeśli jest skonfigurowany). Jest to ważne dla niektórych użytkowników przeglądających internet za pomocą sieci VPN. Oznacza to, że aplikacja WebRTC będzie widzieć tylko adres IP serwera proxy. Pamiętaj, że wpłynie to negatywnie na wydajność aplikacji i nie będzie działać, jeśli nie obsługuje ona protokołów TURN/TCP lub ICE-TCP. Wkrótce pojawi się nowa wersja rozszerzenia WebRTC Network Limiter, która będzie zawierać interfejs użytkownika do obsługi tego ustawienia. Więcej informacji o „wyciekaniu” adresów IP znajdziesz w artykule What's Next for WebRTC (w języku angielskim).

...i wiele więcej.
Znacznie poprawiliśmy przepustowość kanału danych w przypadku połączeń o dużym opóźnieniu.
Obsługę DTLS 1.2 będziemy stopniowo wdrażać w okresie Chrome 47.
W tej wersji nie obsługujemy ani VP9, ani H.264, ale nadal nad tym pracujemy. Mamy nadzieję, że w Chrome 48 wprowadzimy obsługę VP9 i wstępną wersję H.264 (za flagą).
reklamy społeczne;
- Od Chrome 47 żądania
getUserMedia()są dozwolone tylko z bezpiecznych źródeł: HTTPS lub localhost. - Usunięto obsługę kanału danych RTP. Wszystkie pozostałe aplikacje, które nadal korzystają z kanałów danych RTP, powinny używać standardowych kanałów danych.
Podobnie jak w przypadku wszystkich wersji zachęcamy deweloperów do wypróbowania Chrome na kanałach Canary, deweloperskim i beta oraz zgłaszania wszelkich znalezionych problemów. Otrzymana pomoc jest nieoceniona. Wskazówki dotyczące zgłaszania błędów znajdziesz na stronie błędów WebRTC.
Przykłady
- MediaRecorder
enumerateDevices():
Więcej informacji
- Stan implementacji MediaRecorder
- Wersja robocza rekomendacji Media Capture and Streams: MediaDevices
- Audio Output Devices API
- Aktualizacja WebRTC