¿Qué códecs de video (no) usan los navegadores para las videollamadas?

Una solicitud típica de soporte técnico de Voximplant: "¿Por qué una llamada de video entre dos Chrome se ve mejor que una llamada de video entre MS Edge y una aplicación nativa de iOS?" Los colegas suelen responder neutrales, "porque los códecs". Pero nosotros, la gente de TI, somos curiosos. Incluso si no estoy desarrollando un nuevo Skype para web, leer "qué tipo de navegador puede" y cómo dividen un video en varias transmisiones de diferente calidad enriquece la imagen del mundo y ofrece un tema nuevo para discutir en la sala de fumadores. Apareció con éxito el artículo del Dr. Alex, ampliamente conocido en círculos estrechos (con la mejor explicación del término "motor de medios" por todo lo que he visto), un poco de nuestra experiencia, un par de noches en el "Dial", ¡y una traducción adaptada para Habr está esperando debajo del corte!

Códecs y ancho de canal

Cuando se habla de códecs de video, la mayoría de las veces discuten el equilibrio de calidad y ancho del canal utilizado. Y les gusta ignorar los problemas de carga del procesador y cómo transmitir técnicamente el video. Bastante razonable si estamos discutiendo la codificación de un video ya grabado.

Después de todo, si tiene un video terminado, entonces no hay mucha diferencia, se comprimirá un par de minutos, un par de horas o incluso un par de días. Cualquier costo de procesador y memoria estará justificado, ya que esta es una inversión única, y luego puede distribuir el video a millones de usuarios. Los mejores códecs de video comprimen el video en varios pasos:

1. Pase n. ° 1: el video se divide en partes con características comunes: la acción tiene lugar en el mismo fondo, escena rápida o lenta, y similares.
2. Pase # 2: Recopile estadísticas para la codificación e información sobre cómo cambian los marcos con el tiempo (para obtener dicha información, necesita varios marcos).
3. Pase No. 3: Cada parte está codificada con su propia configuración de códec y utilizando la información obtenida en el segundo paso.

La transmisión es un asunto completamente diferente. Nadie esperará hasta el final de un podcast, transmisión o show antes de comenzar a codificar el video. Codificar y enviar de inmediato. Vive en él y dirige que el retraso mínimo se vuelve más importante.

Al usar medios físicos, discos DVD o Blu-ray, el tamaño del video es fijo y el códec se enfrenta a la tarea de garantizar la máxima calidad para un tamaño determinado. Si el video se distribuye a través de la red, entonces la tarea del códec es preparar dichos archivos para obtener la máxima calidad con un ancho de canal fijo o el ancho mínimo del canal con una calidad fija, si necesita reducir el precio. En este caso, los retrasos de la red pueden ignorarse y almacenarse en el lado del cliente durante tantos segundos de video como sea necesario. Pero para la transmisión, no hay una necesidad particular de corregir el tamaño o la calidad, el códec tiene una tarea diferente: reducir los retrasos a cualquier costo.

Finalmente, los creadores de códecs durante mucho tiempo tuvieron en cuenta solo un caso de uso: en la computadora del usuario, se reproduce un solo video. Que, además, casi siempre se puede decodificar por las fuerzas de un chip de video. Luego estaban las plataformas móviles. Y luego WebRTC, para garantizar la latencia mínima de la cual los desarrolladores realmente querían usar los servidores de la Unidad de reenvío selectivo.

El uso de códecs para videollamadas es tan diferente del uso tradicional cuando se reproducen videos que comparar códecs "de frente" no tiene sentido. Cuando se compararon VP8 y H.264 en los albores de WebRTC, una de las discusiones más candentes fue sobre la configuración del códec: hacerlos "realistas" con redes poco confiables o "ideales" para la máxima calidad de video. Los luchadores por la "comparación de códec limpio" argumentaron con toda seriedad que los códecs deberían compararse sin considerar la pérdida de paquetes, la fluctuación de fase y otros problemas de red.

¿Qué pasa con los códecs ahora?

• H.264 y VP8 son aproximadamente iguales en términos de la relación de calidad de video y ancho de canal utilizado;
• H.265 y VP9 también se corresponden aproximadamente entre sí, mostrando en promedio un 30% mejores resultados en comparación con los códecs de la generación anterior debido a un aumento en la carga del procesador en un 20%;
• El nuevo códec AV1, una mezcla explosiva de VP10, daala y thor, es mejor que los códecs de la generación anterior tanto como los mejores que sus predecesores.

Y ahora una sorpresa: a todos no les importan estas diferencias cuando se trata de videollamadas y videoconferencias. Lo más importante es cómo juega el códec en un equipo con el resto de la infraestructura. Los desarrolladores están preocupados por lo que se llama el nuevo término motor de medios : cómo un navegador o aplicación móvil captura video, lo codifica / decodifica, lo divide en paquetes RTP y se ocupa de problemas de red (¿recuerda el video de nuestro artículo anterior de harast ? motor - nota del traductor). Si el codificador no puede funcionar con una fuerte disminución en el ancho del canal o mantener establemente 20 cuadros por segundo, si el decodificador no puede funcionar con la pérdida de un paquete de red, ¿qué diferencia hace qué tan bien el códec comprime el video? Es fácil ver por qué Google patrocina la investigación de Stanford sobre la mejor interacción entre el códec y la red. Este es el futuro de las comunicaciones de video.

Códecs y motor de medios: todo es complicado

Las videollamadas y las videoconferencias tienen casi las mismas tareas que los medios convencionales. Solo las prioridades son completamente diferentes:

1. Toma 30 cuadros por segundo (velocidad de códec).
2. Necesita 30 cuadros por segundo con interactividad (retraso mínimo).

También tenemos Internet entre los participantes, cuya calidad solo podemos adivinar. Por lo general es peor. Por lo tanto:

1. Debe experimentar pequeños cambios en el ancho del canal cuando otro visitante viene al coworking.
2. Al menos, de alguna manera, debe experimentar fuertes cambios en el ancho del canal cuando este visitante comienza a descargar torrents.
3. Debe preocuparse por el jitter (demoras aleatorias entre los paquetes recibidos, debido a que no solo pueden retrasarse, sino que llegan en el orden incorrecto en el que se enviaron).
4. Necesita preocuparse por la pérdida de paquetes.

3.1. Tareas principales del motor de medios

¿Qué significa "necesita 30 cuadros por segundo"? Esto significa que el motor de medios tiene 33 milisegundos para capturar video de la cámara, sonido del micrófono, comprimirlo con un códec, dividirlo en paquetes RTP, proteger los datos transmitidos (SRTP = RTP + AES) y enviarlos a través de la red (UDP o TCP , en la gran mayoría de los casos UDP). Todo esto está en el lado de envío. Y en el lado receptor, repita en el orden inverso. Como la codificación suele ser más difícil que la decodificación, el lado emisor tiene más dificultades.

En el aspecto técnico, el objetivo de "30 cuadros por segundo" se puede lograr con retrasos. Y cuanto mayor sea el retraso, más fácil será lograr el objetivo: si codifica en el lado de envío no varios cuadros a la vez, sino varios a la vez, puede ahorrar significativamente en el ancho del canal (los códecs comprimen mejor varios cuadros al analizar los cambios entre todos ellos, y no solo entre actual y anterior). Al mismo tiempo, el retraso entre la recepción de la transmisión de video de la cámara y el envío a través de la red aumenta en proporción al número de cuadros almacenados en el búfer, además la compresión se vuelve más lenta debido a cálculos adicionales. Muchos sitios usan este truco, declarando el tiempo de respuesta entre el envío y la recepción de paquetes de red entre participantes en videollamadas. El retraso en la codificación y decodificación, son silenciosos.

Para que las videollamadas parezcan una comunicación personal, los creadores de los servicios de comunicación rechazan todas las configuraciones y los perfiles de códec que pueden crear demoras. Resulta una degradación de los códecs modernos a la compresión cuadro por cuadro. Al principio, tal situación despertó el rechazo y las críticas de los desarrolladores de códecs. Pero los tiempos han cambiado, y ahora los códecs modernos, además de los preajustes tradicionales "tamaño mínimo" y "calidad máxima" han agregado un conjunto de configuraciones de "tiempo real". Y al mismo tiempo, "compartir pantalla" también es para videollamadas (tiene sus propios detalles: gran resolución, imagen ligeramente cambiante, la necesidad de una compresión sin pérdidas, de lo contrario el texto flotará).

3.2. Motor de medios y redes públicas

Pequeños cambios en el ancho del canal

Anteriormente, los códecs no podían cambiar la tasa de bits: al comienzo de la compresión, tomaban la tasa de bits objetivo como una configuración y luego emitían un número fijo de megabytes de video por minuto. En aquellos viejos tiempos, las videollamadas y las videoconferencias eran la gran cantidad de redes locales y ancho de banda redundante. Y en caso de problemas, se llamó al nombre del administrador, que fijó la reserva del ancho del canal en tsiska.

El primer cambio evolutivo fue la tecnología de "tasa de bits adaptativa". El códec tiene muchas configuraciones que afectan la velocidad de bits: resolución de video, una ligera disminución en fps de 30 a 25 cuadros por segundo, cuantización de la señal de video. El último en esta lista es el "engrosamiento" de la transición entre colores, cuyos ligeros cambios apenas son perceptibles para el ojo humano. La mayoría de las veces, el principal "ajuste" para la tasa de bits adaptativa fue precisamente la cuantización. Y el motor de medios le dijo al códec sobre el ancho del canal.

Grandes cambios en el ancho del canal

El mecanismo de velocidad de bits adaptable ayuda al motor de medios a continuar transmitiendo video con pequeños cambios en el ancho del canal. Pero si su colega comenzó a descargar torrents y el canal disponible se sumergió dos o tres veces, entonces la tasa de bits adaptativa no ayudará. Disminuir la resolución y la velocidad de fotogramas ayudará. Lo último es preferible, ya que nuestros ojos son menos sensibles a la cantidad de fotogramas por segundo que a la resolución del video. Por lo general, el códec comienza a omitir uno o dos fotogramas, reduciendo la velocidad de fotogramas de 30 a 15, o incluso a 10.

Detalle importante: el motor de medios omitirá fotogramas en el lado de envío. Si tenemos una videoconferencia para varios participantes o transmisión, y el remitente no tiene un problema de red, entonces un "enlace débil" empeorará la calidad del video para todos los participantes. En esta situación, un montón de ayudas de transmisión simultánea (el lado emisor regala varias transmisiones de video de diferente calidad a la vez) y SFU (Unidad de reenvío selectivo, el servidor brinda a cada participante una videoconferencia o transmite una transmisión de la calidad deseada). Algunos códecs tienen la capacidad de crear varias transmisiones de transmisión simultánea, SVC que se complementan entre sí: los clientes con el canal más débil reciben una transmisión de calidad mínima, los clientes con un mejor canal reciben la misma transmisión más la primera "actualización", los clientes con un canal aún mejor Ya hay dos flujos de "actualización" y así sucesivamente. Este método le permite no transferir los mismos datos a múltiples transmisiones y ahorra aproximadamente el 20% del tráfico en comparación con la codificación de varias transmisiones de video completas. También simplifica el funcionamiento del servidor: no es necesario cambiar los flujos, es suficiente no transferir paquetes con una "actualización" a los clientes. Sin embargo, cualquier códec se puede usar para transmisión simultánea, es una característica del motor de medios y la organización de paquetes RTP, no un códec.

Jitter y pérdida de paquetes

Las pérdidas son las más difíciles de combatir. La fluctuación de fase es un poco más simple: simplemente cree un búfer en el lado de recepción para recopilar paquetes tardíos y confusos. No es un búfer demasiado grande, de lo contrario, puede romper en tiempo real y convertirse en un video de YouTube en búfer.

La pérdida de paquetes generalmente se combate con reenvío (RTX). Si el remitente tiene una buena comunicación con la SFU, el servidor puede solicitar un paquete perdido, recuperarlo y aún así cumplir 33 milisegundos. Si la conexión de red no es confiable (más de 0.01% de pérdida de paquetes), entonces necesitamos algoritmos de trabajo de pérdida complejos, como FEC .

La mejor solución hasta ahora es usar códecs SVC. En este caso, para recibir al menos algo de video, solo se necesitan paquetes de "referencia" con un flujo de calidad mínima, estos paquetes son menos, por lo tanto, es más fácil reenviarlos, esto es suficiente para "sobrevivir" incluso con una red muy pobre (más del 1% de pérdida de paquetes). Si Simulcast + SFU le permite lidiar con el hundimiento del canal, entonces Simulcast con la ayuda del códec SVC + SFU resuelve problemas de ancho de canal y paquetes perdidos.

¿Qué navegadores soportan ahora?

Firefox y Safari usan el Media Engine de Google y actualizan libwebrtc de vez en cuando. Lo hacen con mucha menos frecuencia que Chrome, cuya nueva versión se lanza cada 6 semanas. De vez en cuando, comienzan a quedarse muy atrás, pero luego se sincronizan nuevamente. Con la excepción del soporte para el códec VP8 en Safari. Ni siquiera preguntes.

Antes de kat, una tabla con una comparación completa de quién apoya qué, pero en general, todo es bastante simple. Edge generalmente es ignorado por todos. La elección es entre admitir la versión móvil de Safari y una buena calidad de video. Safari de iOS solo es compatible con el códec de video H.264, mientras que libwebrtc solo permite la transmisión simultánea con códecs VP8 (transmisiones diferentes con diferentes velocidades de cuadros) y VP9 (soporte SVC). Pero puede leer y usar libwebrtc en iOS creando una aplicación nativa. Luego, con la transmisión simultánea, todo estará bien y los usuarios recibirán la mejor calidad de video posible con una conexión a Internet inestable. Algunos ejemplos

• Highfive : una aplicación de escritorio en Electron (Chromium) con transmisión simultánea H.264 (libwebrtc) y códecs de sonido de Dolby;
• Attlasian : una solución interesante del cliente en React Native y libwebrtc para simulcast;
• Symphony : Electron para el escritorio, React Native para dispositivos móviles y transmisión simultánea compatible con funciones de seguridad adicionales compatibles con lo que los bancos desean;
• Tokbox : VP8 con transmisión simultánea en el SDK móvil, use la versión parcheada de libvpx en libwebrtc.

El futuro

Ya está claro que no habrá VP8 y VP9 en Safari (a diferencia de Edge, que admite VP8).

Aunque Apple apoyó la inclusión de H.265 en WebRTC, las noticias recientes y una serie de signos indirectos apuntan a AV1 como la "próxima gran cosa". A diferencia del resto del artículo, esta es mi opinión personal. La especificación para la transmisión de datos AV1 ya está lista, pero aún se está trabajando en el códec. Ahora la implementación de referencia del codificador muestra unos tristes 0.3 cuadros por segundo. Esto no es un problema cuando se reproduce contenido precomprimido, pero aún no es aplicable a las comunicaciones en tiempo real. Mientras tanto, puedes intentar reproducir videos AV1 en Firefox, aunque esto no está relacionado con RTC. Implementación del equipo de bitmovin, que desarrolló MPEG-DASH y recibió 30 millones de inversión en la creación de la infraestructura de próxima generación para trabajar con video.