En la primera parte, implementamos un CDN dinámico simple para transmitir transmisiones WebRTC a dos continentes y nos aseguramos de que los retrasos en dicho CDN sean realmente bajos, utilizando el temporizador de cuenta regresiva como ejemplo.
Sin embargo, además de la baja latencia, es importante proporcionar a los espectadores una buena calidad de transmisión, ya que pagan por ello. En la vida real, los canales entre los servidores Edge y los suscriptores pueden ser diferentes en ancho de banda y calidad. Por ejemplo, publicamos una transmisión con una resolución de 720p con una tasa de bits de 2 Mbps, y el usuario la reproduce en un teléfono inteligente Android usando una conexión 3G en el área de recepción insegura de la señal, y la resolución máxima a la que la imagen será suave, solo 360p con una tasa de bits de 400 Mbps .
Los dispositivos y navegadores utilizados por los espectadores son muy diferentes. Por ejemplo, publicamos una transmisión WebRTC usando el códec VP8 del navegador Chrome en una PC, y el visor reproduce la transmisión en Safari en el iPhone, que solo admite el códec H264. O viceversa, publicamos la transmisión RTMP de OBS Studio, codificando video en H264 y audio en AAC, y el cliente usa un navegador basado en Chromium, que solo admite VP8 o VP9 para video y opus para sonido.
También es posible que deba mejorar la calidad de la publicación original. Por ejemplo, distribuimos la transmisión desde la cámara IP en alguna reserva, la mayoría de las veces la imagen es estática, la cámara la da a una frecuencia de 1 cuadro por segundo. Al mismo tiempo, queremos que el espectador juegue 24 cuadros por segundo. ¿Qué sucede si es imposible reemplazar la cámara o cambiar su configuración?
En todos estos casos, se requerirá la transcodificación de la secuencia en el servidor, es decir, la decodificación de cada trama recibida y la codificación posterior con nuevos parámetros. Además, los parámetros que deben cambiarse a menudo solo se conocen en el lado del cliente. Veamos cómo es posible proporcionar transcodificación en CDN, equilibrando entre la calidad de transmisión y las cargas del servidor.
Transcodificación: ¿cómo, dónde y por qué?
Supongamos que conocemos los parámetros de flujo que el cliente quiere recibir. Por ejemplo, el espectador comenzó a reproducir una transmisión, y la cantidad de pérdidas de cuadros en las estadísticas de WebRTC nos dice que la resolución y la velocidad de bits deben reducirse hasta que el cliente haya cambiado de canal . En este caso, de forma predeterminada, la secuencia se transcodificará en el servidor Edge al que está conectado el visor.
Si el cliente no admite el códec utilizado al publicar la transmisión, puede asignar la transcodificación tanto al servidor perimetral como al servidor de origen.
Tanto eso como otro solo pueden ser una solución temporal, siempre que la configuración de los servidores Origin y / o Edge se haya elegido con un margen. La transcodificación siempre se realiza cuadro por cuadro, por lo que es muy exigente con los recursos del procesador. Entonces, un núcleo de procesador puede transcodificar un número muy pequeño de subprocesos:
Incluso si comenzamos un proceso de transcodificación para todos los suscriptores que requieren los mismos parámetros de transmisión de medios, es probable que varios espectadores con diferentes parámetros seleccionen todos los recursos del servidor.
Por lo tanto, la solución correcta sería seleccionar servidores especiales en el CDN para las tareas de transcodificación, y elegir la configuración del servidor en función de estas tareas.
Agregar nodos de transcodificador a CDN
Entonces, implementaremos un servidor en nuestro CDN con el rol de Transcodificador en los centros de datos europeos y americanos
Configuración de servidores transcodificadores:
cdn_enabled=true cdn_ip=t-eu1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder
- Transcodificador 1 EE. UU.
cdn_enabled=true cdn_ip=t-us1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder
Los parámetros de transcodificación de secuencias deben describirse en los servidores Edge como perfiles especiales en el archivo cdn_profiles.yml . Como ejemplo, considere tres perfiles predeterminados:
- transcodificación a una resolución de 640x360, 30 cuadros por segundo, se transmite un cuadro clave por cada 90 cuadros, códec de video H264 con codificador OpenH264, códec de audio Opus 48 kHz
-640x360: audio: codec : opus rate : 48000 video: width : 640 height : 360 gop : 90 fps : 30 codec : h264 codecImpl : OPENH264
- transcodificación a resolución 1280x720, códec de video H264 con codificador OpenH264, sin transcodificación de audio
-720p: video: height : 720 codec : h264 codecImpl : OPENH264
- transcodificando a una resolución de 1280x720, 30 cuadros por segundo, se transmite un cuadro clave por cada 90 cuadros, bitrate 2 Mbit / s, códec de video H264 usando el codificador OpenH264, sin transcodificación de audio
-720p-2Mbps: video: height : 720 bitrate : 2000 gop : 90 fps : 30 codec : h264 codecImpl : OPENH264
Publicamos la transmisión de test con una resolución de 720p en el o-eu1 y la reproducimos en e-eu1 , especificando el perfil en el nombre de la transmisión, por ejemplo, test-640x360
¡La secuencia está transcodificada!
Ahora podemos describir una serie de perfiles en los servidores Edge, por ejemplo -240p, -360p, -480p, y si en el lado del cliente, según las estadísticas de WebRTC, se diagnostica una gran cantidad de tramas perdidas, vuelva a solicitar automáticamente la transmisión con una resolución más baja.
Agrupar nodos CDN por continente
Ahora nuestros servidores Transcoder son iguales. Pero, ¿qué pasa si queremos transcodificar transmisiones por geografía: para los espectadores estadounidenses en América, para los espectadores europeos en Europa? Esto, por cierto, reducirá la carga en los canales transatlánticos, ya que en este caso solo las transmisiones originales irán desde los servidores de Origin EU a América y viceversa, y no todas las versiones transcodificadas.
En este caso, en la configuración de los nodos del transcodificador, debe especificar el grupo
cdn_enabled=true cdn_ip=t-eu1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder cdn_groups=EU
- Transcodificador 1 EE. UU.
cdn_enabled=true cdn_ip=t-us1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder cdn_groups=US
Además, el grupo debe agregarse a la configuración de los servidores Edge.
cdn_groups=EU
cdn_groups=US
Reinicie los nodos con la nueva configuración. Publicamos la transmisión de test con una resolución de 720p en el o-eu1 , reproducimos esta transmisión en e-eu1 con transcodificación
Asegúrese de que la transmisión se transcodifique a t-eu , para esto abrimos la página de estadísticas http://t-eu1.flashphoner.com:8081/?action=stat y vea el codificador y decodificador de video en la sección Native resources
Al mismo tiempo, no hay codificadores de video en t-us1 en las estadísticas
Más transcodificadores: equilibrio de carga
Digamos que el número de espectadores continúa creciendo, y las capacidades de un servidor Transcoder en el continente ya no son suficientes. Ok, agrega un servidor más
cdn_enabled=true cdn_ip=t-eu2.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder cdn_groups=EU
- Transcodificador 2 EE. UU.
cdn_enabled=true cdn_ip=t-us2.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder cdn_groups=US
Sin embargo, ahora nos enfrentamos al problema del equilibrio de carga en dos transcodificadores. Para no permitir todos los subprocesos a través de un servidor, limitaremos la carga promedio máxima permitida del procesador en los nodos del transcodificador
cdn_node_load_average_threshold=0.95
Cuando la carga promedio del procesador, dividida por el número de núcleos disponibles, alcanza este valor, el servidor dejará de aceptar solicitudes para transcodificar nuevos subprocesos.
También puede limitar la cantidad máxima de codificadores de video que se ejecutan simultáneamente
cdn_transcoder_video_encoders_threshold=10000
Cuando se alcanza esta cantidad, el servidor también dejará de aceptar solicitudes de transcodificación de secuencias, incluso si la carga del procesador todavía lo permite.
En cualquier caso, el servidor Transcodificador continuará distribuyendo a los servidores Edge aquellas transmisiones que ya están transcodificadas.
Final sigue
Por lo tanto, hemos implementado servidores dedicados para transcodificar transmisiones de medios en nuestra CDN y, por lo tanto, podemos proporcionar a nuestros televidentes la calidad de la transmisión en función de las capacidades de sus equipos y la calidad de los canales. Sin embargo, aún no abordamos el problema de restringir el acceso a los hilos. Lo consideraremos en la parte final.
Referencias
Baja transmisión de WebRTC de baja latencia CDN es una red de entrega de contenido basada en Web Call Server.