Proceso de reproducción común
Análisis del proceso principal del jugador.
El proceso de reproducción del reproductor es similar al proceso de transmisión, pero se invierte el orden. El terminal de transmisión primero recopila audio y video, codifica y encapsula audio y video, y los procesa de acuerdo con el protocolo de medios de transmisión para finalmente obtener el flujo de salida. El reproductor analiza y desencapsula el flujo de entrada para obtener paquetes de audio (como AAC) y paquetes de video (como H.264, H.265), y los decodifica para obtener cuadros de audio PCM y cuadros de video YUV. Finalmente, el reproductor debe renderizar y reproducir el video y el audio a través del módulo de sincronización de audio y video, y finalmente presentárselo al usuario.
A partir del análisis del modelo de subprocesos, el subproceso central del motor de reproducción generalmente se puede dividir en " subproceso de decapsulación (subproceso de lectura) ", " subproceso de decodificación de audio/video " y " subproceso de reproducción de audio/video ". es mejor para el motor de reproducción y las aplicaciones de la capa superior Con la cooperación, el motor de reproducción generalmente mantiene un "hilo de mensajes" para informar a la capa superior, como "código de error de falla de reproducción, tiempo de reproducción del primer cuadro de video/audio, datos estadísticos durante reproducción (como el primer cuadro que consume mucho tiempo, tasa de código de audio/video, número de cuadro de recepción de audio y video/segundo, número de cuadro de decodificación de audio y video/segundo, número de cuadro de reproducción de audio y video/segundo, tiempos de congelación de reproducción, duración de congelación de reproducción , diferencia de reloj de sincronización de audio y video, etc.)".
Se puede ver en el modelo de subprocesos que los subprocesos centrales del motor de reproducción son un modelo productor-consumidor muy significativo. Este modelo puede utilizar de manera eficiente las ventajas del paralelismo multinúcleo de la CPU y, a través de una administración razonable del búfer de medios, puede resistir la fluctuación de la red y la decodificación hasta cierto punto, y evitar congelamientos frecuentes.
Los problemas comunes durante el proceso de reproducción se centran principalmente en problemas como la imposibilidad de reproducir, la falta de sonido o imagen, la pantalla borrosa, la congelación y el alto retraso . Por lo general, el enlace de solución de problemas se lleva a cabo al revés por el lado de la reproducción. A continuación analizaremos algunos problemas comunes durante la reproducción de transmisiones en vivo en base a algunos casos que hemos acumulado en nuestro trabajo.
La resolución es demasiado pequeña para causar una falla de decodificación de hardware
Fenómeno: comentarios de los clientes de que durante la transmisión en vivo, la pantalla se congela repentinamente, pero el sonido es normal.
Análisis: a través del análisis del registro de reproducción y el volcado de la transmisión de video, descubrimos que cuando ocurrió el problema, el reproductor estaba usando la decodificación de hardware de Android y la resolución de la transmisión de video extraída cambió (1080p->16p). consultando los datos La causa principal es que el códec MediaCodec de Android admite una variedad de resoluciones que varían de un dispositivo a otro. Puede verlo viendo /vendor/etc/media_codecs_xxx.xml en el dispositivo, como media_codecs_mediatek_video.xml del dispositivo "M2006C3LC", la descripción de decodificación de H264 es la siguiente, la resolución compatible con "OMX.MTK.VIDEO .DECODER.AVC" El rango es (64*64) - (2048*1088), por lo que puede haber algunos problemas impredecibles al analizar videos con una resolución de 16*16.
Experiencia práctica: capacidades del hardware de Android para la adaptación
1. En comparación con los dispositivos IOS, los dispositivos Android están más fragmentados . Adaptarse a las diferentes capacidades de los diferentes modelos puede reducir en gran medida los problemas similares anteriores. Afortunadamente, la interfaz MediaCodec proporciona a los desarrolladores una interfaz de consulta de capacidad relativamente completa, como algunas interfaces provistas en MediaCodecInfo.VideoCapabilities:
public Range<Integer> getBitrateRange ()
public Range<Integer> getSupportedFrameRates ()
public Range<Integer> getSupportedHeights ()
public boolean isSizeSupported (int width, int height)
...Esta parte de la interfaz proporcionada por MediaCodec puede ayudarnos a elegir mejor si usar un decodificador duro o un decodificador suave de acuerdo con la capacidad del dispositivo al inicializar el códec/decodificador, y evitar fallas de decodificación y retrocesos causados por problemas de capacidad del dispositivo tanto como sea posible. pregunta En cuanto a la codificación, incluye principalmente si se admite MediaFormat, si se admite Perfil/Nivel, si se admite la resolución de codificación, si se admite la velocidad de bits de codificación, si se admite la velocidad de fotogramas de codificación, si se supera el número de instancias de codificación. el rango máximo admitido, etc. El extremo de decodificación es similar al extremo de codificación.
2. Mantenga una lista negra: Habilitar la codificación/descodificación del hardware de video puede reducir la carga de la CPU hasta cierto punto y mejorar el rendimiento del video.Sin embargo, debido a la grave fragmentación de Android, los fabricantes de dispositivos implementan muchas capacidades de codificación y decodificación de MediaCodec. es difícil lograr consistencia en el rendimiento. De nuestros casos anteriores, podemos encontrar que las capacidades de codificación y decodificación del hardware de algunos modelos son muy pobres, y no se puede encontrar la causa raíz del bajo rendimiento, por lo que podemos optar por utilizar una lista negra. para mantenimiento.
3. Mejore el mecanismo de solución blanda alternativa de decodificación de hardware: problemas de decodificación de hardware relativamente comunes, como la decodificación de hardware lleva mucho tiempo, errores de API de decodificación de hardware, etc. Los errores informados por la llamada de interfaz MediaCodec son generalmente relativamente fáciles de capturar, y puede use la información de error capturada Lleve a cabo la discriminación, retroceda el procesamiento de decodificación de software para errores clave o informe a la capa de aplicación para su procesamiento, pero no se informa ningún error en la llamada de interfaz, pero el problema del tiempo de decodificación prolongado seguirá afectando en gran medida la experiencia del usuario , por lo que para el caso de un tiempo de decodificación excesivo, también es necesario retroceder e informar a la capa de aplicación.
El problema de desenfoque de la pantalla causado por la actualización incorrecta de los parámetros sps/pps
Fenómeno: durante la prueba de nuestro proyecto, nos encontramos con el problema de que el hardware decodificaba la pantalla borrosa en escenas como pk.
Análisis: después de nuestras pruebas, descubrimos que la solución suave no causa una pantalla borrosa, pero la decodificación del hardware causará una pantalla borrosa. Al usar ffmpeg dump para analizar los datos del flujo de código del extremo receptor, descubrimos que cuando ocurre la pantalla borrosa , el sps/pps del video ha cambiado, y el problema es muy grave. Está claro que es un problema típico de decodificación de pantalla borrosa causado por una actualización incorrecta de sps/pps.
Experiencia práctica: en circunstancias normales, los sps/pps generalmente no cambian durante un solo impulso de transmisión estable. Generalmente, cuando cambia la resolución de video, el motor de reproducción ijk original está en el módulo de decodificación de hardware. Admite actualizaciones de sps/pps al cambiar de resolución . Sin embargo, el negocio de algunos terminales de transmisión puede ser más complicado, ya que implica el cambio dinámico de codificadores, etc., lo que también provocará cambios en sps/pps cuando la resolución permanece sin cambios. Por lo tanto, desde la perspectiva de la versatilidad, cada vez que se recibe la información del encabezado del video, debe compararse con la información del encabezado del video actual y actualizarse a tiempo cuando se produzcan cambios, para evitar problemas como pantallas borrosas.
Problemas de pantalla borrosa causados por fotogramas clave faltantes y fotogramas de referencia faltantes
Fenómeno: la pantalla se ve borrosa y se recupera después de un período de tiempo.
Análisis: mediante el análisis del volcado del flujo de código, encontramos que no hay ningún problema con el flujo de código. Posteriormente, mediante el análisis del registro, identificamos la causa raíz del problema: "La pantalla de decodificación está borrosa debido a la pérdida del marco de referencia" .
Experiencia práctica: los problemas de Huaping a menudo ocurren en escenas como marcos clave faltantes y marcos de referencia faltantes. En cualquier momento, después de la codificación y antes de la decodificación, no se recomienda descartar cuadros de video, de lo contrario, puede causar problemas de pantalla borrosa al final de la decodificación. En la escena de transmisión en vivo, para eliminar el retraso acumulado, algunos jugadores optarán por descartar algunos cuadros no decodificados en el búfer de cuadros.En este caso, una estrategia más razonable es descartar un GOP completo, o usar la doble velocidad. El método de reproducción se utiliza para ponerse al día con el retraso, y la estrategia de doble velocidad se detiene cuando el retraso cumple con los requisitos de la transmisión en vivo. Además, para evitar en la medida de lo posible problemas de pantalla borrosa causados por tales problemas, la detección de fotogramas clave debe realizarse en escenarios como la primera transmisión, la desconexión y reconexión de la red, y la decodificación debe comenzar desde el fotograma clave.
Problemas de reproducción inesperados causados por cambiar las operaciones de audio y video en el extremo de transmisión
Fenómeno: durante la prueba del proyecto, el audio y el video en el extremo de reproducción dejaron de reproducirse repentinamente.
Análisis: al analizar el flujo de código en el extremo receptor, descubrimos que el flujo de medios de audio se detuvo repentinamente durante la transmisión en vivo. A través de la investigación, descubrimos que el extremo de transmisión admite la función de apagado dinámico de los flujos de medios de audio/video. Esta función hará que el flujo de medios de audio o video del extremo receptor se interrumpa repentinamente y entre en conflicto con la lógica existente del extremo de reproducción, lo que dará como resultado algunos problemas impredecibles.
Experiencia práctica: si el extremo de transmisión admite el cierre dinámico de transmisiones de audio y video, es relativamente difícil adaptar el reproductor. Generalmente, los escenarios que deben adaptarse incluyen, entre otros: "Escena de audio seguida de video" , Escenarios como "Audio primero seguido de video" , "Interrupción repentina de transmisión de video" , "Interrupción repentina de transmisión de audio" y otros escenarios. Es relativamente más fácil para el lado de la reproducción adaptarse a escenarios donde aumentan las transmisiones de audio y video. Solo necesita detectar dinámicamente la cantidad de transmisiones de medios en el módulo de desencapsulación para determinar si se agregaron nuevas transmisiones. Sin embargo, para escenarios donde el audio / los flujos de medios de video se interrumpen repentinamente Es muy difícil de adaptar. Por un lado, como motor de reproducción general, no interactúa con la lógica de señalización del final del flujo. Por otro lado, la escena puede tener muchas lógicas comunes con el reproductor, como la sincronización de audio y video (audio síncrono de video, video síncrono de audio), lógica de almacenamiento en búfer, etc. tienen conflictos serios y causan problemas. Por ejemplo, la estrategia de sincronización predeterminada del extremo de reproducción general es audio síncrono de video, pero cuando la transmisión de audio se interrumpe repentinamente, debemos percibir que la transmisión de audio en el extremo de inserción se ha detenido. Cierre y ajuste la estrategia de sincronización de audio y video del reproductor. Por lo tanto, es difícil ser compatible con estas escenas desde la perspectiva del reproductor, pero desde la perspectiva del final de la transmisión, puede optar por agregar fotogramas silenciosos/datos de video de video falso cuando la transmisión de medios de audio/video está cerrada, de modo que el flujo de medios puede garantizarse La continuidad, por lo que es compatible con la mayoría de los reproductores del lado de la transmisión.
Además, también hemos encontrado en la práctica que en el escenario donde las transmisiones de audio/video se activan y desactivan dinámicamente al final de la transmisión, incluso si el extremo de reproducción es compatible, si el servidor o el fabricante de CDN lo admiten será una gran pregunta. marca, especialmente en la aplicación En el escenario donde el protocolo hls extrae flujos, porque en comparación con otros protocolos de transmisión, el protocolo hls también implica la lógica de corte en el lado del servidor, y es probable que la lógica de corte hls del servidor o del fabricante de CDN no es compatible con la operación de cambio de audio y video.
El video o el audio no se pueden decodificar debido a que falta el encabezado de audio/video
Fenómeno: comentarios de los clientes de que una determinada transmisión de video se puede extraer a través de rtmp, pero no se puede extraer a través de hls.
Análisis: al obtener la dirección del flujo de origen del cliente, pruebe el rendimiento de la transmisión rtmp y hls a través de ffplay respectivamente.Entre ellos, la transmisión hls no tiene sonido y no se ha analizado la información de audio.El análisis del flujo de código de la transmisión rtmp Volcado Se puede ver que aunque el audio se puede reproducir normalmente, falta la información del encabezado del audio.
Experiencia práctica: El problema causado por la falta de encabezados de video/audio no se puede resolver mediante la adaptación del extremo de reproducción, y el problema puede estar oculto y ser difícil de encontrar. El extremo de transmisión debe verificar si es correcto en cada caso de complemento. Encabezados de pronunciación/video Se envía información de encabezado de audio y video, como cambios de configuración de audio y video, desconexión y reconexión de la red, reenvío y otros escenarios.
Excepción de reproducción causada por marcas de tiempo discontinuas
Fenómeno: el audio y el video no están sincronizados o están atascados.
Análisis: las anomalías de las marcas de tiempo se pueden dividir aproximadamente en dos categorías. La primera categoría es que las marcas de tiempo de audio y video no están sincronizadas, es decir, el lapso es grande. La segunda categoría es el problema de rastrear las marcas de tiempo de audio y video, como dts /pts de repente a partir de 0. En circunstancias normales, para evitar situaciones tales como atascos cuando ocurren tales anomalías, el final de la transmisión será compatible con escenarios con marcas de tiempo discontinuas.La solución general puede incluir la caída de cuadros o el abandono de la estrategia original de sincronización del reloj de acuerdo con su reproducción respectiva. Reproducir a intervalos Aunque esta solución puede continuar reproduciéndose cuando las marcas de tiempo de audio y video son anormales, puede causar problemas como audio y video no sincronizados y bloqueos.
Experiencia práctica: el lado de la reproducción de este problema puede ser compatible hasta cierto punto, pero la causa raíz es que el lado de la transmisión debe garantizar la sincronización de las marcas de tiempo de audio y video.
Herramientas de uso común para analizar problemas
-
ffmpeg, ffplay, ffprobe flujo de código Volcar/transmitir reproducción de medios/ver información de medios, etc.
-
El analizador elecard analiza el contenido del flujo de código.
-
mediaInfo Análisis de formato de información de archivos multimedia.
-
flvAnalyser analiza la información de encapsulación del formato FLV.
-
YUV Eye reproduce datos YUV.