WebRTC de Chrome 47: Grabación de medios, orígenes seguros y manejo de proxy

Sam Dutton

Chrome 47 incluye varias mejoras y actualizaciones importantes de WebRTC.

Graba videos desde tus apps web

La API de MediaStreamRecorder ha sido durante mucho tiempo la solicitud más popular de chromium.org, con más de 2,500 estrellas. Ahora se agregó la grabación de medios a Chrome detrás de la marca de funciones experimentales de la plataforma web, aunque, por el momento, solo está disponible para computadoras. Esto te permite grabar, reproducir o descargar videos. Hay una demostración simple en el repo de muestras de WebRTC, y puedes obtener más información en el anuncio de discuss-webrtc. En github.com/niklasenbom/RecordingApp, se encuentra disponible una app de Chrome de ejemplo para grabar videos a partir de capturas de pantalla. Estas son implementaciones nuevas, por lo que es posible que aún haya errores que corregir. Si encuentras problemas, infórmalos en los repositorios.

Captura de pantalla de la demostración de MediaRecorder en el repositorio de muestras de WebRTC en GitHub

Selección del dispositivo de salida de audio

Se lanzó MediaDevices.enumerateDevices(). En el problema 504280 de Chromium, se encuentran más detalles. Ahora puedes enumerar los dispositivos de salida de audio, además de los dispositivos de entrada de audio y video que MediaStreamTrack.getSources() ya proporciona. Puedes obtener más información sobre cómo usarla en esta actualización.

Compatibilidad de dispositivos en Windows

Ahora se agregó la compatibilidad con dispositivos de comunicación predeterminados en Windows. Esto significa que, cuando se enumeren los dispositivos de audio en Windows, habrá una entrada adicional para el dispositivo de comunicaciones cuyo ID será "communications".

Los IDs de dispositivo para el dispositivo de audio predeterminado (y las comunicaciones en Windows) ya no se generarán con hash (problema 535980). En cambio, se admiten dos IDs reservados, "default" y "communications", que son los mismos en todos los orígenes de seguridad. Las etiquetas de dispositivos se traducirán a la configuración regional del navegador, por lo que los desarrolladores no deben esperar que las etiquetas tengan un valor predeterminado. Se mejoró la precisión de la renderización de video propagando la marca de tiempo de captura hasta el algoritmo de renderización, donde se puede elegir la sincronización vertical correcta en función de esa marca de tiempo. En la plataforma de Windows, la marca de tiempo de captura también es más precisa en Chrome 47.

Manejo de proxy

Chrome 47 agrega una nueva preferencia para forzar el envío del tráfico de WebRTC a través de un servidor proxy local, si se configuró uno, lo que es importante para algunos usuarios que navegan a través de una VPN. Esto significa que la aplicación de WebRTC solo verá la dirección IP del proxy. Ten en cuenta que esto afectará el rendimiento de la aplicación y no funcionará en absoluto, a menos que la aplicación admita TURN/TCP o ICE-TCP. Pronto estará disponible una nueva versión de la extensión WebRTC Network Limiter que proporcionará una IU para esta preferencia. En Próximos pasos para WebRTC, encontrarás más información sobre la "fuga" de direcciones IP.

Extensión de Chrome WebRTC Network Limiter

… y mucho más

Se mejoró considerablemente la capacidad de procesamiento del canal de datos para las conexiones de latencia alta.

Lanzaremos gradualmente la compatibilidad con DTLS 1.2 en el período de Chrome 47.

Si bien en esta versión no se admiten VP9 ni H.264, se sigue trabajando en ellos y esperamos implementar la compatibilidad con VP9 y una versión inicial de H.264 (detrás de una marca) en Chrome 48.

Anuncios de servicio público

  • A partir de Chrome 47, las solicitudes getUserMedia() solo se permiten desde orígenes seguros: HTTPS o localhost.
  • Se quitó la compatibilidad con el canal de datos de RTP. Las aplicaciones restantes que aún usan canales de datos de RTP deben usar los canales de datos estándar.

Al igual que con todas las versiones, recomendamos a los desarrolladores que prueben Chrome en los canales Canary, Dev y Beta, y que informen los problemas que encuentren. La ayuda que recibimos es invaluable. Para obtener sugerencias sobre cómo presentar un buen informe de errores, consulta la página de errores de WebRTC.

Demostraciones

Más información