Una gran cantidad de apps para Android usan ExoPlayer. Como OEM, es importante garantizar que ExoPlayer funcione correctamente tanto en dispositivos nuevos como en plataformas nuevas para dispositivos existentes. En esta página, se describe la compatibilidad pruebas que recomendamos realizar antes de enviar un dispositivo o una plataforma de manera inalámbrica algunos de los modos de falla comunes que se encuentran cuando se ejecutan.
Cómo ejecutar las pruebas
Para ejecutar las pruebas de reproducción de ExoPlayer, primero consulta la versión más reciente de ExoPlayer desde GitHub. Luego, puedes ejecutar las pruebas desde la línea de comandos Android Studio
Línea de comandos
Desde el directorio raíz, compila e instala las pruebas de reproducción:
./gradlew :test-exoplayer-playback:installDebug
A continuación, ejecuta las pruebas de reproducción en el paquete GTS:
adb shell am instrument -w -r -e debug false \ -e package androidx.media3.test.exoplayer.playback.gts \ androidx.media3.test.exoplayer.playback.test/androidx.test.runner.AndroidJUnitRunner
Los resultados de la prueba aparecen en STDOUT.
Android Studio
Abre el proyecto de ExoPlayer, navega al módulo playbacktests y haz clic con el botón derecho
en la carpeta gts y ejecuta las pruebas. Los resultados de la prueba aparecen en el
Ejecutar ventana.
Modos de falla comunes
Algunos de los modos de falla comunes que se encuentran cuando se ejecuta la reproducción de ExoPlayer estas pruebas se describen a continuación, junto con la causa raíz probable en cada caso. Mié agregará a esta lista a medida que se descubran más modos de falla.
Marca de tiempo inesperada de presentación del búfer de video
Logcat contendrá un error similar al siguiente:
Caused by: java.lang.IllegalStateException: Expected to dequeue video buffer
with presentation timestamp: 134766000. Instead got: 134733000 (Processed
buffers since last flush: 2242).
Esta falla suele deberse a que el decodificador de video sometido a prueba se produce incorrectamente.
descartar, insertar o reordenar búferes. En el ejemplo anterior, la prueba
se espera que quite de la cola un búfer con la marca de tiempo de presentación 134766000 de
MediaCodec.dequeueOutputBuffer, pero descubrió que sacó de la cola un búfer con
La marca de tiempo de la presentación es 134733000. Te recomendamos que revises
implementación de codificador-decodificador cuando se encuentre con esta falla, en particular, que
administra correctamente los interruptores de resolución adaptable sin descartar ningún búfer.
Se descartaron demasiados búferes
Logcat contendrá un error similar al siguiente:
junit.framework.AssertionFailedError: Codec(DashTest:Video) was late decoding:
200 buffers. Limit: 25.
Esta falla es un problema de rendimiento, por lo que el decodificador de video sometido a prueba se la decodificación tardía de una gran cantidad de búferes. En el ejemplo anterior, ExoPlayer omitió 200 búferes porque estaban retrasados cuando se quitaron de la cola, para una prueba que impone un límite de 25. La causa más obvia es que el decodificador de video es demasiado lenta decodificación de búferes. Si las fallas solo ocurren para el subconjunto de pruebas que reproducen contenido protegido por Widevine, es probable que las operaciones para la desencriptación del búfer son demasiado lentas. Te recomendamos verificar el rendimiento estos componentes y analizar si se pueden realizar optimizaciones para acelerar y subirlos.
No se pudo autenticar la ventana nativa
Logcat contendrá un error similar al siguiente:
SurfaceUtils: native window could not be authenticated
ExoPlayerImplInternal: Internal runtime error.
ExoPlayerImplInternal: android.media.MediaCodec$CodecException: Error 0xffffffff
Este error indica que la plataforma no pudo configurar correctamente la configuración de bits.
Se agotó el tiempo de espera de la prueba
Logcat contendrá un error similar al siguiente:
AssertionFailedError: Test timed out after 300000 ms.
Este error suele deberse a una conectividad de red deficiente durante la prueba.
cuando se ejecute. Si el dispositivo parece tener una buena conectividad de red, es posible
que la prueba se bloquea y llama a un componente de la plataforma (como
MediaCodec, MediaDrm o AudioTrack). Inspecciona las pilas de llamadas de la
subprocesos en el proceso de prueba para establecer si este es el caso.