¿Cómo realiza WeChat transmisiones en vivo en tiempo real y videos de miniprogramas bajo demanda? ¿Cuáles son las dificultades?
En el futuro, los servidores de streaming de medios avanzarán hacia una arquitectura de sistema altamente distribuida, que estará distribuida geográficamente pero, lógicamente, tendrá una única imagen de sistema. En el futuro, habrá dispositivos de almacenamiento en red de alto rendimiento, por un lado, y dispositivos de procesamiento y control de protocolos altamente inteligentes, por el otro. Esta será una buena dirección para la futura expansión de los servidores de medios de transmisión, y WeChat también es una plataforma muy prometedora, especialmente el desarrollo de transmisión en vivo de mini programas de WeChat.
Entonces, ¿puede el miniprograma WeChat actual realizar la función de transmisión en vivo? La respuesta es: sí. Hay dos modos de transmisión de video en vivo. Uno es transmisión en vivo unidireccional, distribuida a través de CDN, con bajo costo y retraso de 1 a 3 segundos. El mini programa se puede manejar a través del modo En vivo. El otro es la transmisión interactiva en vivo (Migu), que requiere un retraso relativamente bajo, por debajo de 500 ms, y el mini programa puede lograrlo a través del modo RTC.
Pero, de hecho, todavía quedan varios puntos que deben superarse para implementar la función de transmisión en vivo del mini programa:
El primero es que el retraso debe ser lo suficientemente bajo. Si el retraso unidireccional no puede ser inferior a 500 milisegundos, no se puede garantizar la experiencia interactiva de las videollamadas.
El segundo es la cancelación de eco. Porque cuando el usuario A y el usuario B tienen una videollamada, la voz del usuario A será capturada y enviada al usuario B. Después de un cierto retraso, el usuario A escuchará un eco, lo que tiene un gran impacto en la experiencia de la llamada. se requiere.
El tercero es la suavidad sin retrasos. ¿Por qué debería ser suave? Debido a que existen requisitos de latencia ultrabaja, la suavidad y la latencia son requisitos técnicos contradictorios. Si la latencia es lo suficientemente baja, el búfer de fluctuación debe ser lo suficientemente pequeño. De esta manera, la fluctuación de la red aparecerá fácilmente, lo que dará como resultado imágenes demasiado rápidas. o demasiado lento. O retrasado.
Entonces echemos un vistazo a las tres dificultades técnicas anteriores:
1) Baja latencia, básicamente hay tres tipos de enlaces que introducen retrasos: adquisición y renderizado, codificación y decodificación. , transmisión de red. La primera categoría es el proceso de recopilación y renderizado, que tiene un retraso relativamente grande, especialmente para el renderizado. Actualmente, casi ningún sistema móvil puede garantizar un retraso del 100% de 50 milisegundos. La segunda categoría es el proceso de codificación y decodificación, especialmente la codificación y decodificación de audio, que es codificación directa, que a su vez provocará un retraso. Algunas codificaciones y decodificaciones de audio pueden incluso provocar un retraso de 200 milisegundos. La tercera categoría es la transmisión de red. En las redes de transmisión en tiempo real, el retraso de la transmisión de ida y vuelta puede alcanzar menos de 50 milisegundos. En este caso, la captura, renderización, decodificación y codificación se implementan en el terminal.
2) La cancelación de eco pertenece al preprocesamiento de voz 3A y debe realizarse en el enlace de preprocesamiento e implementarse en el terminal.
3) El almacenamiento en búfer de fluctuación se implementa en el extremo receptor. El intervalo de tiempo entre los paquetes de datos enviados por el extremo emisor está determinado por el almacenamiento en búfer de fluctuación en el extremo receptor.
En resumen, las tres dificultades técnicas anteriores se implementan en el terminal, por lo que el terminal es muy importante. Nuestro servidor de medios de transmisión EasyDSS se puede integrar en mini programas WeChat para transmisión en vivo y también puede evitar grandes retrasos y ecos. Es adecuado para escenarios como transmisión en vivo de mini programas en aulas y la industria de la seguridad.
El servidor de medios de transmisión EasyDSS puede proporcionar servicios integrales de transcodificación, bajo demanda, transmisión en vivo y reproducción en diferido, lo que simplifica enormemente el trabajo de desarrollo e integración. Las funciones bajo demanda incluyen principalmente: carga, transcodificación y distribución. Las funciones de transmisión en vivo incluyen principalmente: transmisión y grabación en vivo. La transmisión en vivo admite entrada RTMP y salida de distribución RTMP/HLS/HTTP-FLV, admite longitud de almacenamiento, recuperación y descarga personalizadas; Proporciona ricas interfaces de desarrollo secundarias basadas en encapsulación JSON y llamadas HTTP. Proporcionar garantías de seguridad como autenticación de reproducción y autenticación push. Proporcionar configuración de gestión de permisos relacionados y de usuarios.