OEM-Tests

ExoPlayer wird von einer Vielzahl von Android-Apps verwendet. Als OEM ist es wichtig, dass ExoPlayer sowohl auf neuen Geräten als auch auf neuen Plattform-Builds für vorhandene Geräte ordnungsgemäß funktioniert. Auf dieser Seite werden Kompatibilitätstests beschrieben, die wir vor dem Versand eines Geräts oder Plattform-OTA empfehlen. Außerdem werden einige häufige Fehlermodi beschrieben, die bei der Ausführung auftreten können.

Tests ausführen

Wenn Sie die Wiedergabetests von ExoPlayer ausführen möchten, sehen Sie sich zuerst die neueste Version von ExoPlayer auf GitHub an. Sie können die Tests dann über die Befehlszeile oder über Android Studio ausführen.

Befehlszeile

Erstellen und installieren Sie die Wiedergabetests im Stammverzeichnis:

./gradlew :test-exoplayer-playback:installDebug

Führe als Nächstes die Wiedergabetests im GTS-Paket aus:

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

Die Testergebnisse werden in STDOUT angezeigt.

Android Studio

Öffnen Sie das ExoPlayer-Projekt, gehen Sie zum Modul playbacktests, klicken Sie mit der rechten Maustaste auf den Ordner gts und führen Sie die Tests aus. Die Testergebnisse werden im Fenster „Ausführen“ von Android Studio angezeigt.

Häufige Fehlermodi

Einige der häufigsten Fehlermodi, die beim Ausführen von ExoPlayer-Wiedergabetests auftreten, werden unten zusammen mit der jeweiligen wahrscheinlichen Ursache beschrieben. Diese Liste wird ergänzt, sobald weitere Fehlermodi erkannt werden.

Unerwarteter Zeitstempel für die Zwischenspeicherung des Videos

Logcat enthält einen Fehler wie den folgenden:

Caused by: java.lang.IllegalStateException: Expected to dequeue video buffer
with presentation timestamp: 134766000. Instead got: 134733000 (Processed
buffers since last flush: 2242).

Dieser Fehler wird meistens dadurch verursacht, dass der zu testende Videodecoder Zwischenspeicher falsch verworfen, eingefügt oder neu geordnet wird. Im obigen Beispiel wurde für den Test erwartet, dass ein Zwischenspeicher mit dem Präsentationszeitstempel 134766000 von MediaCodec.dequeueOutputBuffer aus der Warteschlange entfernt wurde. Stattdessen wurde jedoch ein Puffer mit dem Präsentationszeitstempel 134733000 aus der Warteschlange entfernt. Wir empfehlen, bei diesem Fehler die Decoder-Implementierung zu prüfen. Insbesondere sollten Sie darauf achten, dass adaptive Auflösungswechsel korrekt verarbeitet werden, ohne Zwischenspeicher zu verwerfen.

Zu viele gelöschte Puffer

Logcat enthält einen Fehler wie den folgenden:

junit.framework.AssertionFailedError: Codec(DashTest:Video) was late decoding:
200 buffers. Limit: 25.

Dieser Fehler ist ein Leistungsproblem, bei dem der zu testende Videodecoder eine große Anzahl von Zwischenspeichern spät decodiert wurde. Im obigen Beispiel hat ExoPlayer 200 Puffer gelöscht, da sie zum Zeitpunkt der Ausgliederung aus der Warteschlange zu spät gekommen waren. Dies ist ein Test mit einem Grenzwert von 25. Die offensichtlichste Ursache ist, dass der Videodecoder die zu langsamen Decodierungspuffer enthält. Wenn die Fehler nur für die Teilmenge von Tests auftreten, die geschützte Widevine-Inhalte wiedergeben, sind die Plattformvorgänge für die Zwischenspeicherentschlüsselung wahrscheinlich zu langsam. Wir empfehlen, die Leistung dieser Komponenten zu prüfen und zu prüfen, ob Optimierungen vorgenommen werden können, um sie zu beschleunigen.

Natives Fenster konnte nicht authentifiziert werden

Logcat enthält einen Fehler wie den folgenden:

SurfaceUtils: native window could not be authenticated
ExoPlayerImplInternal: Internal runtime error.
ExoPlayerImplInternal: android.media.MediaCodec$CodecException: Error 0xffffffff

Dieser Fehler ist ein Hinweis darauf, dass die Plattform das sichere Bit-Flag nicht korrekt gesetzt hat.

Zeitüberschreitung beim Test

Logcat enthält einen Fehler wie den folgenden:

AssertionFailedError: Test timed out after 300000 ms.

Dieser Fehler wird meistens durch eine schlechte Netzwerkverbindung während des Testlaufs verursacht. Wenn das Gerät eine gute Netzwerkverbindung hat, kann es sein, dass der Test beim Aufrufen einer Plattformkomponente wie MediaCodec, MediaDrm oder AudioTrack hängt. Prüfen Sie die Aufrufstacks der Threads im Testprozess, um festzustellen, ob das der Fall ist.