ओईएम की जांच

ExoPlayer का इस्तेमाल कई Android ऐप्लिकेशन करते हैं. 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).

आम तौर पर, यह गड़बड़ी तब होती है, जब जांच में शामिल वीडियो डिकोडर, बफ़र को गलत तरीके से हटाता है, डालता है या उनका क्रम बदलता है. ऊपर दिए गए उदाहरण में, जांच के दौरान MediaCodec.dequeueOutputBuffer से 134766000 के प्रज़ेंटेशन टाइमस्टैंप वाले बफ़र को हटाने की उम्मीद थी. हालांकि, ऐसा नहीं हुआ और 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) को कॉल करने में फंस गई हो. यह पता लगाने के लिए कि क्या ऐसा है, जांच की प्रोसेस में थ्रेड के कॉल स्टैक की जांच करें.