Arquitecturas del lado del cliente y WebRTC

Puede encontrar más información sobre WebRTC en Transmisión de medios hacia el este.

Vea los videos completos y otros aspectos destacados de Streaming Media West Connect en el canal de YouTube Streaming Media.

Lea la transcripción completa de este video:

Robert Reinhardt: Hablemos de los problemas de arquitectura del lado del cliente que puede encontrar con WebRTC y que no ha experimentado con otras arquitecturas. Como la mayoría de las aplicaciones más antiguas de las que estaba hablando, subastas de ganado y subastas de vino, todas eran RTMP, que era solo TCP. Esa era la única opción que teníamos. TCP puede retrasarse con el tiempo. No es que RTMP no tuviera sus problemas, pero cuando se trataba de puertos y acceso al firewall, era una ecuación más sencilla. Recuerdo todos esos. ¿Cuántos de ustedes recuerdan estos problemas cuando salió por primera vez RTMP? Cuando trabajaba para Schematic en Los Ángeles, una gran agencia que hacía proyectos para Disney, ABC y NBC, siempre que algo se basaba en RTMP, una peluca superior estaba detrás de un cortafuegos corporativo donde RTMP no estaba pasando.

Entonces, cuando comenzaron a cambiar a la transmisión HTTP desde RTMP, hizo una gran diferencia, porque HTTP atravesó la mayoría de los firewalls. Si no inspeccionaban los paquetes y miraban exactamente lo que venía a través de este puerto y el protocolo, pero WebRTC es una mezcla de TCP y UDP. UDP le dará la latencia más baja. Y si no se implementa correctamente TURN, UDP puede ser problemático. Si estoy en mi teléfono celular y detrás de una red asimétrica, entonces podría ser problemático ser parte de una sesión WebRTC en curso. Pero servidores vez ayudará a aliviar este. Sin embargo, algunos proveedores no tienen soporte TURN. Y eso es un problema. Por lo que desea asegurarse de que toma el cuidado apropiado.

Vendor Lockdown: WebRTC es una especificación que no tiene una sola implementación correcta. Y hablaré de eso en un momento. De hecho, destacaré algunos trabajos que el Dr. Alex Gouailliard hizo un poco de tracción para pasar a una implementación más consistente, al menos desde la perspectiva del cliente.

Velocidades en baudios adaptables: algunos navegadores admiten transferencias simultáneas. Y como mencioné, el VP8 SPC puede ser la opción futura. El SVC en general como concepto puede ser una opción. Si empezamos a verlo … Tienes que darte cuenta de que WebRTC se basa en los conceptos originales de P2P. Y así, los servidores, si es que estaban involucrados, eran simplemente servidores de negociación de IP aturdidos, y los clientes podían hablar P2P directamente entre sí.

Infraestructura sin servidor: si es un requisito, entonces solo tendrá tantas opciones cuando se trata de tratar de obtener calidad para alguien que no puede aceptar esa alta calidad, ¿qué puede hacer? Uh, ya sabes, si tu P2P es solo uno a uno, tienes más opciones aquí. Sin embargo, si está realizando sesiones P2P que involucran a más de una persona, más de dos partes, esto puede complicarse.

Acceso a la cámara y al micrófono: esto es más una cosa de UX, pero nuevamente, algo que tienes que jugar es como tener una aplicación flash. Muchos de los ejemplos que ve en el exterior que vienen con ejemplos de WebRTC deben cambiarse en la configuración de su navegador y la cámara y el micrófono. Por supuesto, puede exponer esto en JavaScript, pero es algo a lo que debe prestar atención. Selección de cámara, selección de micrófono, ajuste de sus propiedades.

Flash tenía su propia curva de aprendizaje. No diré que WebRTC sea aún más difícil, pero es una de mis quejas. A menudo trabajo con mis clientes, desarrolladores web y, no me malinterpretes si eres uno de ellos, que esperan que el SDK siempre lo sea. Pero tuve que hacer muchos desarrolladores donde no había SDK reales donde las cosas se hicieran fácilmente. Tenías que construir cosas desde cero y ActionScript. Tenías que trabajar con clases nativas y crear tu propia cosa.

Y hablaré de eso en el futuro. Descubrí que es probablemente uno de los mayores puntos de dolor cada vez que trabajo con desarrolladores web y WebRTC, es la captura obteniendo una captura de medios, obteniendo todos los parámetros correctamente con una tasa de bits y una velocidad de fotogramas. La implementación de estos controles puede ser un gran problema, simplemente porque lleva tiempo. Y si está acostumbrado a tener siempre un SDK que facilita las cosas. Y ya estás acostumbrado: “Mira, voy a un desarrollador de aplicaciones web. Sé cómo hacerlo X, Y y Z ”. Y comenzaste a hablar con ellos sobre la API de captura de medios. Luego, se desarrollarán especialidades especiales, pero si necesita comenzar y no tiene tiempo para pasar por estas curvas de aprendizaje, entonces podría influir en su decisión sobre cómo construir su próxima aplicación WebRTC.

Habilite JavaScript para ver los comentarios creados por Disqus.

Artículos relacionados

Transmisión única con WebRTC

El CTO VideoRx Robert Reinhardt analiza el surgimiento de WebRTC como una opción de baja latencia para la transmisión de uno a muchos y los desafíos de escalarlo en este clip de su presentación en Streaming Media West Connect.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *