ओईएम की जांच

ExoPlayer का इस्तेमाल, कई Android ऐप्लिकेशन करते हैं. ओईएम के तौर पर, यह पक्का करना ज़रूरी है कि 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) को कॉल करने के दौरान अटक गया हो. यह पता लगाने के लिए कि ऐसा हुआ है या नहीं, टेस्ट प्रोसेस में थ्रेड के कॉल स्टैक की जांच करें.