ओईएम की जांच

कई Android ऐप्लिकेशन, ExoPlayer का इस्तेमाल करते हैं. OEM के तौर पर, यह पक्का करना ज़रूरी है कि ExoPlayer, नए डिवाइसों और मौजूदा डिवाइसों के लिए नया प्लैटफ़ॉर्म बिल्ड. इस पेज पर बताया गया है कि यह सुविधा किन डिवाइसों पर काम करती है ऐसे टेस्ट जिन्हें हम किसी डिवाइस या प्लैटफ़ॉर्म के ओटीए की शिपिंग से पहले चलाने का सुझाव देते हैं, और उन्हें चलाते समय कुछ सामान्य गड़बड़ी वाले मोड का सामना करना पड़ा.

जांच करना

ExoPlayer के प्लेबैक टेस्ट को चलाने के लिए, सबसे पहले GitHub से जुड़ा ExoPlayer. इसके बाद, कमांड लाइन से जांच करें या Android Studio.

कमांड लाइन

रूट डायरेक्ट्री से, प्लेबैक टेस्ट बनाएं और इंस्टॉल करें:

./gradlew :test-exoplayer-playback:installDebug

इसके बाद, 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

परीक्षण परिणाम STDOUT में दिखाई देते हैं.

Android Studio

ExoPlayer प्रोजेक्ट खोलें, playbacktests मॉड्यूल पर जाएं और राइट क्लिक करें gts फ़ोल्डर में जाकर टेस्ट करें. जांच के नतीजे, Android Studio के विंडो चलाएं.

गड़बड़ी के सामान्य मोड

ExoPlayer पर वीडियो चलाने के दौरान, कुछ सामान्य गड़बड़ी वाले मोड का सामना करना पड़ रहा है नीचे सभी टेस्ट के बारे में बताया गया है. साथ ही, हर मामले में संभावित मूल वजह के बारे में भी बताया गया है. बुध गड़बड़ी वाले अन्य मोड का पता चलने पर, इस सूची में आइटम जोड़ दिए जाएंगे.

वीडियो बफ़र प्रज़ेंटेशन का अनचाहा टाइमस्टैंप

Logcat में, इससे मिलती-जुलती गड़बड़ी होगी:

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

यह गड़बड़ी अक्सर तब होती है, जब वीडियो डिकोडर की जांच गलत तरीके से की जाती है बफ़र को खारिज करना, डालना या उन्हें फिर से क्रम में लगाना. ऊपर दिए गए उदाहरण में, परीक्षण इस इमेज में, प्रज़ेंटेशन टाइमस्टैंप 134766000 के साथ बफ़र को हटाया जाएगा MediaCodec.dequeueOutputBuffer, लेकिन पाया कि इसने बफ़र को डिकोड कर दिया इसके बजाय, प्रज़ेंटेशन का टाइमस्टैंप 134733000. हमारा सुझाव है कि आप इस विफलता का सामना करते समय डिकोडर लागू करना, विशेष रूप से इससे कोई भी बफ़र ख़ारिज किए बिना, अडैप्टिव रिज़ॉल्यूशन के स्विच सही तरीके से हैंडल किए जा सकते हैं.

बहुत ज़्यादा बफ़र छोड़ दिए गए हैं

Logcat में, इससे मिलती-जुलती गड़बड़ी होगी:

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

यह गड़बड़ी, परफ़ॉर्मेंस से जुड़ी एक समस्या है. इसका मतलब है कि वीडियो डिकोडर की जांच की जा रही है बड़ी संख्या में बफ़र को समझने में देर हुई. ऊपर दिए गए उदाहरण में, ExoPlayer 200 बफ़र, क्योंकि सर्वर से हटाए जाने के बाद टेस्ट में देरी हुई जो 25 की सीमा लागू करता है. इसकी सबसे बड़ी वजह वीडियो डिकोडर है बफ़र को डिकोड करने में बहुत ज़्यादा समय लगता है. अगर गड़बड़ी सिर्फ़ जांच के सबसेट के लिए होती है, तो जो Widevine से सुरक्षित कॉन्टेंट चलाते हैं, तो हो सकता है कि प्लैटफ़ॉर्म ऑपरेशन बफ़र डिक्रिप्शन के लिए बहुत धीमी स्पीड है. हमारा सुझाव है कि आप . उन्हें ऊपर ले जाएं.

नेटिव विंडो की पुष्टि नहीं की जा सकी

Logcat में, इससे मिलती-जुलती गड़बड़ी होगी:

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

इस गड़बड़ी का मतलब है कि प्लैटफ़ॉर्म, सुरक्षा के लिए सही तरीके से सेट अप नहीं कर पा रहा है बिट फ़्लैग.

जांच का समय खत्म हो गया

Logcat में, इससे मिलती-जुलती गड़बड़ी होगी:

AssertionFailedError: Test timed out after 300000 ms.

आम तौर पर, ऐसा टेस्ट के दौरान इंटरनेट ठीक से काम न करने की वजह से होता है दौड़ना. अगर डिवाइस में इंटरनेट अच्छी तरह से कनेक्ट है, तो हो सकता है कि कि टेस्ट में एक प्लैटफ़ॉर्म कॉम्पोनेंट (जैसे कि MediaCodec, MediaDrm या AudioTrack). इसके कॉल स्टैक की जांच करें थ्रेड जो जांच प्रक्रिया में हैं, ताकि यह तय किया जा सके कि ऐसा है या नहीं.