समस्या का हल


"Cleartext HTTP ट्रैफ़िक की अनुमति नहीं है" वाली गड़बड़ियां ठीक करना

अगर आपका ऐप्लिकेशन, cleartext HTTP ट्रैफ़िक का अनुरोध करता है (यानी, http:// के बजाय https://), तो यह गड़बड़ी दिखेगी. ऐसा तब होता है, जब उसके नेटवर्क सुरक्षा कॉन्फ़िगरेशन में इसकी अनुमति नहीं होती. अगर आपका ऐप्लिकेशन, Android 9 (एपीआई लेवल 28) या इसके बाद के वर्शन को टारगेट करता है, तो डिफ़ॉल्ट कॉन्फ़िगरेशन में cleartext HTTP ट्रैफ़िक की सुविधा बंद होती है.

अगर आपके ऐप्लिकेशन को cleartext HTTP ट्रैफ़िक के साथ काम करना है, तो आपको ऐसे नेटवर्क सुरक्षा कॉन्फ़िगरेशन का इस्तेमाल करना होगा जिसमें इसकी अनुमति हो. ज़्यादा जानकारी के लिए, Android के नेटवर्क सुरक्षा से जुड़ा दस्तावेज़ देखें. सभी cleartext HTTP ट्रैफ़िक को चालू करने के लिए, अपने ऐप्लिकेशन के AndroidManifest.xml के application एलिमेंट में, android:usesCleartextTraffic="true" जोड़ें.

ExoPlayer का डेमो ऐप्लिकेशन, डिफ़ॉल्ट नेटवर्क सुरक्षा कॉन्फ़िगरेशन का इस्तेमाल करता है. इसलिए, इसमें cleartext HTTP ट्रैफ़िक की अनुमति नहीं है. ऊपर दिए गए निर्देशों का इस्तेमाल करके, इसे चालू किया जा सकता है.

"SSLHandshakeException", "CertPathValidatorException" और "ERR_CERT_AUTHORITY_INVALID" वाली गड़बड़ियां ठीक करना

SSLHandshakeException, CertPathValidatorException और ERR_CERT_AUTHORITY_INVALID तीनों गड़बड़ियां, सर्वर के एसएसएल सर्टिफ़िकेट में किसी समस्या की ओर इशारा करती हैं. ये गड़बड़ियां, सिर्फ़ ExoPlayer से जुड़ी नहीं हैं. ज़्यादा जानकारी के लिए, Android का एसएसएल से जुड़ा दस्तावेज़ देखें.

कुछ मीडिया फ़ाइलों में वीडियो के किसी भी हिस्से पर जाने की सुविधा क्यों नहीं होती?

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

अगर आपको वीडियो के किसी भी हिस्से पर जाने की सुविधा चाहिए, लेकिन आपके पास ऐसा मीडिया है जिसमें यह सुविधा नहीं है, तो हमारा सुझाव है कि आप अपने कॉन्टेंट को किसी ज़्यादा सही कंटेनर फ़ॉर्मैट में बदलें. MP3, ADTS, और AMR फ़ाइलों के लिए, वीडियो के किसी भी हिस्से पर जाने की सुविधा को चालू किया जा सकता है. इसके लिए, यह मान लिया जाता है कि फ़ाइलों में कॉन्टेंट की बिटरेट तय है. इसके बारे में यहां बताया गया है.

कुछ MP3 फ़ाइलों में वीडियो के किसी भी हिस्से पर जाने की सुविधा सटीक तरीके से काम क्यों नहीं करती?

वेरिएबल बिटरेट (वीबीआर) वाली MP3 फ़ाइलें, उन मामलों के लिए सही नहीं होती हैं जिनमें वीडियो के किसी भी हिस्से पर सटीक तरीके से जाने की सुविधा की ज़रूरत होती है. इसकी दो वजहें हैं:

  1. सटीक तरीके से वीडियो के किसी भी हिस्से पर जाने की सुविधा के लिए, कंटेनर फ़ॉर्मैट में हेडर में, सटीक टाइम-टू-बाइट मैपिंग होनी चाहिए. इस मैपिंग की मदद से, प्लेयर, वीडियो के किसी भी हिस्से पर जाने के लिए किए गए अनुरोध के समय को, उससे जुड़े बाइट ऑफ़सेट पर मैप कर सकता है. साथ ही, उस ऑफ़सेट से मीडिया के लिए अनुरोध करना, उसे पार्स करना, और उसे चलाना शुरू कर सकता है. MP3 में इस मैपिंग को तय करने के लिए उपलब्ध हेडर (जैसे, XING हेडर) अक्सर सटीक नहीं होते हैं.
  2. ऐसे कंटेनर फ़ॉर्मैट जिनमें सटीक टाइम-टू-बाइट मैपिंग नहीं होती है या जिनमें टाइम-टू-बाइट मैपिंग नहीं होती है, उनमें भी वीडियो के किसी भी हिस्से पर सटीक तरीके से जाने की सुविधा का इस्तेमाल किया जा सकता है. हालांकि, इसके लिए ज़रूरी है कि कंटेनर में स्ट्रीम में, सटीक सैंपल टाइमस्टैंप शामिल हों. इस मामले में, प्लेयर, वीडियो के किसी भी हिस्से पर जाने के लिए किए गए अनुरोध के समय को, उससे जुड़े बाइट ऑफ़सेट के सबसे सटीक अनुमान पर मैप कर सकता है. साथ ही, उस ऑफ़सेट से मीडिया के लिए अनुरोध करना शुरू कर सकता है. इसके बाद, पहले सटीक सैंपल टाइमस्टैंप को पार्स कर सकता है. साथ ही, सही सैंपल मिलने तक, वीडियो में बाइनरी सर्च की सुविधा का इस्तेमाल कर सकता है. माफ़ करें, MP3 में स्ट्रीम में, सटीक सैंपल टाइमस्टैंप शामिल नहीं होते हैं. इसलिए, इस तरीके का इस्तेमाल नहीं किया जा सकता.

इन वजहों से, वीबीआर वाली MP3 फ़ाइल में वीडियो के किसी भी हिस्से पर सटीक तरीके से जाने के लिए, पूरी फ़ाइल को स्कैन करना पड़ता है. साथ ही, प्लेयर में टाइम-टू-बाइट मैपिंग को मैन्युअल तरीके से बनाना पड़ता है. इस रणनीति को FLAG_ENABLE_INDEX_SEEKING, का इस्तेमाल करके चालू किया जा सकता है. इसे का इस्तेमाल करके, DefaultExtractorsFactory पर setMp3ExtractorFlagsकिया जा सकता है. ध्यान दें कि यह रणनीति, MP3 की बड़ी फ़ाइलों के लिए सही नहीं है. खास तौर पर, तब जब उपयोगकर्ता, वीडियो चलाने के तुरंत बाद, स्ट्रीम के आखिर के आस-पास जाने की कोशिश करता है. इसके लिए, प्लेयर को तब तक इंतज़ार करना पड़ता है, जब तक पूरी स्ट्रीम डाउनलोड और इंडेक्स न हो जाए. इसके बाद ही, वीडियो के किसी भी हिस्से पर जाने की सुविधा का इस्तेमाल किया जा सकता है. ExoPlayer में, हमने इस मामले में सटीक तरीके से वीडियो के किसी भी हिस्से पर जाने की सुविधा के बजाय, तेज़ी से वीडियो के किसी भी हिस्से पर जाने की सुविधा को ऑप्टिमाइज़ करने का फ़ैसला किया है. इसलिए, FLAG_ENABLE_INDEX_SEEKING डिफ़ॉल्ट रूप से बंद होती है.

अगर आपके पास, चलाए जा रहे मीडिया को कंट्रोल करने का विकल्प है, तो हमारा सुझाव है कि आप MP4 जैसे किसी ज़्यादा सही कंटेनर फ़ॉर्मैट का इस्तेमाल करें. हमें ऐसे किसी मामले के बारे में जानकारी नहीं है जिसमें MP3, मीडिया फ़ॉर्मैट का सबसे सही विकल्प हो.

मेरे वीडियो में, किसी भी हिस्से पर जाने की सुविधा धीरे-धीरे क्यों काम करती है?

जब प्लेयर, वीडियो में किसी नई जगह पर जाता है, तो उसे दो काम करने पड़ते हैं:

  1. बफ़र में, वीडियो के किसी भी हिस्से पर जाने के लिए की गई नई जगह से जुड़ा डेटा लोड करना. अगर यह डेटा पहले से बफ़र किया गया है, तो यह ज़रूरी नहीं है.
  2. वीडियो डिकोडर को फ़्लश करना और वीडियो के किसी भी हिस्से पर जाने के लिए की गई नई जगह से पहले के आई-फ़्रेम (कीफ़्रेम) से डिकोड करना. ऐसा इसलिए, क्योंकि वीडियो कंप्रेस करने के ज़्यादातर फ़ॉर्मैट में, इंट्रा-फ़्रेम कोडिंग का इस्तेमाल किया जाता है. यह पक्का करने के लिए कि वीडियो के किसी भी हिस्से पर जाने की सुविधा सटीक तरीके से काम करे (यानी, वीडियो ठीक उसी जगह से चलना शुरू हो जहां जाने के लिए अनुरोध किया गया है), पहले के आई-फ़्रेम और वीडियो के किसी भी हिस्से पर जाने के लिए की गई जगह के बीच के सभी फ़्रेम को डिकोड करना और तुरंत हटाना पड़ता है. इन्हें स्क्रीन पर नहीं दिखाया जाता.

(1) की वजह से होने वाली देरी को कम करने के लिए, प्लेयर की मदद से मेमोरी में बफ़र किए गए डेटा की मात्रा बढ़ाई जा सकती है या डेटा को डिस्क पर पहले से कैश किया जा सकता है.

(2) की वजह से होने वाली देरी को कम करने के लिए, वीडियो के किसी भी हिस्से पर जाने की सुविधा की सटीकता कम की जा सकती है. इसके लिए, ExoPlayer.setSeekParameters का इस्तेमाल किया जा सकता है. इसके अलावा, वीडियो को फिर से एनकोड करके, उसमें ज़्यादा बार आई-फ़्रेम शामिल किए जा सकते हैं . हालांकि, ऐसा करने से आउटपुट फ़ाइल का साइज़ बढ़ जाएगा.

MPEG-TS की कुछ फ़ाइलें क्यों नहीं चलती हैं?

MPEG-TS की कुछ फ़ाइलों में, ऐक्सेस यूनिट डिलिमिटर (एयूडी) शामिल नहीं होते हैं. डिफ़ॉल्ट रूप से, ExoPlayer, फ़्रेम की सीमाओं का पता लगाने के लिए, एयूडी पर निर्भर करता है. इसी तरह, MPEG-TS की कुछ फ़ाइलों में, आईडीआर कीफ़्रेम शामिल नहीं होते हैं. डिफ़ॉल्ट रूप से, ExoPlayer सिर्फ़ इन्हीं कीफ़्रेम को ध्यान में रखता है.

जब ExoPlayer से, MPEG-TS की ऐसी फ़ाइल चलाने के लिए कहा जाता है जिसमें एयूडी या आईडीआर कीफ़्रेम नहीं होते हैं, तो वह बफ़रिंग की स्थिति में अटक जाता है. अगर आपको ऐसी फ़ाइलें चलानी हैं, तो FLAG_DETECT_ACCESS_UNITS और FLAG_ALLOW_NON_IDR_KEYFRAMES का इस्तेमाल किया जा सकता है. इन फ़्लैग को set on a DefaultExtractorsFactory का इस्तेमाल करके सेट किया जा सकता है. इसके अलावा, the constructor का इस्तेमाल करके, इन्हें on a DefaultHlsExtractorFactory पर भी सेट किया जा सकता है.setTsExtractorFlags FLAG_DETECT_ACCESS_UNITS का इस्तेमाल करने से कोई साइड इफ़ेक्ट नहीं होता. हालांकि, एयूडी के आधार पर फ़्रेम की सीमा का पता लगाने की तुलना में, यह ज़्यादा महंगा होता है. FLAG_ALLOW_NON_IDR_KEYFRAMES का इस्तेमाल करने से, MPEG-TS की कुछ फ़ाइलें चलाने पर, वीडियो के किसी भी हिस्से पर जाने के तुरंत बाद और वीडियो चलने की शुरुआत में, कुछ समय के लिए विज़ुअल में गड़बड़ी हो सकती है.

MPEG-TS की कुछ फ़ाइलों में सबटाइटल क्यों नहीं मिलते?

MPEG-TS की कुछ फ़ाइलों में, CEA-608 ट्रैक शामिल होते हैं. हालांकि, इन्हें कंटेनर मेटाडेटा में नहीं बताया जाता. इसलिए, ExoPlayer इनका पता नहीं लगा पाता. DefaultExtractorsFactory को, संभावित सबटाइटल फ़ॉर्मैट की सूची देकर, मैन्युअल तरीके से सबटाइटल ट्रैक तय किए जा सकते हैं. इसमें, MPEG-TS स्ट्रीम में इनकी पहचान करने के लिए इस्तेमाल किए जा सकने वाले ऐक्सेसिबिलिटी चैनल भी शामिल हैं:

Kotlin

val extractorsFactory =
  DefaultExtractorsFactory()
    .setTsSubtitleFormats(
      listOf(
        Format.Builder()
          .setSampleMimeType(MimeTypes.APPLICATION_CEA608)
          .setAccessibilityChannel(accessibilityChannel)
          // Set other subtitle format info, such as language.
          .build()
      )
    )
val player: Player =
  ExoPlayer.Builder(context, DefaultMediaSourceFactory(context, extractorsFactory)).build()

Java

DefaultExtractorsFactory extractorsFactory =
    new DefaultExtractorsFactory()
        .setTsSubtitleFormats(
            ImmutableList.of(
                new Format.Builder()
                    .setSampleMimeType(MimeTypes.APPLICATION_CEA608)
                    .setAccessibilityChannel(accessibilityChannel)
                    // Set other subtitle format info, such as language.
                    .build()));
Player player =
    new ExoPlayer.Builder(context, new DefaultMediaSourceFactory(context, extractorsFactory))
        .build();

MP4/FMP4 की कुछ फ़ाइलें गलत तरीके से क्यों चलती हैं?

MP4/FMP4 की कुछ फ़ाइलों में, एडिट लिस्ट शामिल होती हैं. इनकी मदद से, सैंपल की सूचियों को स्किप करके, मूव करके या दोहराकर, मीडिया टाइमलाइन को फिर से लिखा जाता है. ExoPlayer, एडिट लिस्ट को लागू करने की सुविधा आंशिक रूप से देता है. उदाहरण के लिए, यह सिंक्रनाइज़ेशन सैंपल से शुरू होने वाले सैंपल के ग्रुप को डिले या दोहरा सकता है. हालांकि, यह उन एडिट के लिए ऑडियो सैंपल या प्रीरोल मीडिया को ट्रंकेट नहीं करता जो सिंक्रनाइज़ेशन सैंपल से शुरू नहीं होते हैं.

अगर आपको दिख रहा है कि मीडिया का कोई हिस्सा अचानक गायब हो गया है या दोहराया जा रहा है, तो Mp4Extractor.FLAG_WORKAROUND_IGNORE_EDIT_LISTS या FragmentedMp4Extractor.FLAG_WORKAROUND_IGNORE_EDIT_LISTS सेट करके देखें. ऐसा करने से, एक्सट्रैक्टर, एडिट लिस्ट को पूरी तरह से अनदेखा कर देगा. इन्हें का इस्तेमाल करके DefaultExtractorsFactory या setFragmentedMp4ExtractorFlags पर सेट किया जा सकता है.setMp4ExtractorFlags

एचटीटीपी रिस्पॉन्स कोड 301 या 302 की वजह से, कुछ स्ट्रीम क्यों नहीं चलती हैं?

एचटीटीपी रिस्पॉन्स कोड 301 और 302, दोनों रीडायरेक्शन की ओर इशारा करते हैं. इनके बारे में संक्षिप्त जानकारी, Wikipedia पर देखी जा सकती है. जब ExoPlayer कोई अनुरोध करता है और उसे स्टेटस कोड 301 या 302 वाला जवाब मिलता है, तो वह आम तौर पर रीडायरेक्ट को फ़ॉलो करता है और सामान्य तरीके से वीडियो चलाना शुरू कर देता है. डिफ़ॉल्ट रूप से, ऐसा सिर्फ़ क्रॉस-प्रोटोकॉल रीडायरेक्ट के लिए नहीं होता. क्रॉस-प्रोटोकॉल रीडायरेक्ट, एचटीटीपीएस से एचटीटीपी या इसके उलट (या कम मामलों में, प्रोटोकॉल के किसी अन्य पेयर के बीच) रीडायरेक्ट होता है. यह जांचने के लिए कि किसी यूआरएल की वजह से क्रॉस-प्रोटोकॉल रीडायरेक्ट होता है या नहीं, wget कमांड लाइन टूल का इस्तेमाल इस तरह किया जा सकता है:

wget "https://yourserver.example.com/test.mp3" 2>&1  | grep Location

आउटपुट कुछ इस तरह दिखना चाहिए:

Location: https://secondserver.example.net/test.mp3 [following]
Location: http://thirdserver.example.org/test.mp3 [following]

इस उदाहरण में, दो रीडायरेक्ट हैं. पहला रीडायरेक्ट, https://yourserver.example.com/test.mp3 से https://secondserver.example.net/test.mp3 पर है. दोनों एचटीटीपीएस हैं. इसलिए, यह क्रॉस-प्रोटोकॉल रीडायरेक्ट नहीं है. दूसरा रीडायरेक्ट, https://secondserver.example.net/test.mp3 से http://thirdserver.example.org/test.mp3 पर है. यह एचटीटीपीएस से एचटीटीपी पर रीडायरेक्ट करता है. इसलिए, यह क्रॉस-प्रोटोकॉल रीडायरेक्ट है. ExoPlayer, अपने डिफ़ॉल्ट कॉन्फ़िगरेशन में इस रीडायरेक्ट को फ़ॉलो नहीं करेगा. इसका मतलब है कि वीडियो नहीं चलेगा.

अगर ज़रूरत हो, तो अपने ऐप्लिकेशन में इस्तेमाल किए गए DefaultHttpDataSource.Factory इंस्टेंस को इंस्टैंशिएट करते समय, ExoPlayer को क्रॉस-प्रोटोकॉल रीडायरेक्ट को फ़ॉलो करने के लिए कॉन्फ़िगर किया जा सकता है. नेटवर्क स्टैक चुनने और उसे कॉन्फ़िगर करने के बारे में जानने के लिए, यहां जाएं.

UnrecognizedInputFormatException की वजह से, कुछ स्ट्रीम क्यों नहीं चलती हैं?

यह सवाल, वीडियो चलाने में होने वाली इन गड़बड़ियों से जुड़ा है:

UnrecognizedInputFormatException: None of the available extractors
(MatroskaExtractor, FragmentedMp4Extractor, ...) could read the stream.

इस गड़बड़ी की दो वजहें हो सकती हैं. इसकी सबसे आम वजह यह है कि आप DASH (mpd), HLS (m3u8) या SmoothStreaming (ism, isml) कॉन्टेंट चलाने की कोशिश कर रहे हैं. हालांकि, प्लेयर इसे प्रोग्रेसिव स्ट्रीम के तौर पर चलाने की कोशिश करता है. ऐसी स्ट्रीम चलाने के लिए, आपको ExoPlayer के संबंधित मॉड्यूल पर निर्भर रहना होगा. ऐसे मामलों में जहां स्ट्रीम यूआरआई, फ़ाइल के स्टैंडर्ड एक्सटेंशन के साथ खत्म नहीं होता है, वहां MediaItem.Builder के setMimeType में MimeTypes.APPLICATION_MPD, MimeTypes.APPLICATION_M3U8 या MimeTypes.APPLICATION_SS भी पास किया जा सकता है. इससे, स्ट्रीम का टाइप साफ़ तौर पर तय किया जा सकता है.

दूसरी वजह, जो कम मामलों में होती है, यह है कि ExoPlayer, उस मीडिया के कंटेनर फ़ॉर्मैट के साथ काम नहीं करता जिसे चलाने की कोशिश की जा रही है. इस मामले में, गड़बड़ी का होना सही है. हालांकि, कंटेनर फ़ॉर्मैट और टेस्ट स्ट्रीम की जानकारी शामिल करके, हमारे इश्यू ट्रैकरपर सुविधा का अनुरोध सबमिट किया जा सकता है. नया अनुरोध सबमिट करने से पहले, कृपया मौजूदा सुविधा के अनुरोध को खोजें.

कुछ डिवाइसों पर setPlaybackParameters ठीक से क्यों काम नहीं करता?

Android M और इससे पहले के वर्शन पर, अपने ऐप्लिकेशन का डीबग बिल्ड चलाने पर, आपको रुक-रुककर चलने की समस्या, सुनाई देने वाली गड़बड़ियां, और सीपीयू का ज़्यादा इस्तेमाल जैसी समस्याएं आ सकती हैं. setPlaybackParameters एपीआई का इस्तेमाल करते समय. ऐसा इसलिए होता है, क्योंकि Android के इन वर्शन पर चल रहे डीबग बिल्ड के लिए, इस एपीआई के लिए ज़रूरी ऑप्टिमाइज़ेशन बंद होता है.

ध्यान दें कि यह समस्या सिर्फ़ डीबग बिल्ड पर असर डालती है. यह रिलीज़ बिल्ड पर असर नहीं डालती है. इसके लिए, ऑप्टिमाइज़ेशन हमेशा चालू रहता है. इसलिए, एंड यूज़र को दी जाने वाली रिलीज़ पर इस समस्या का असर नहीं पड़ना चाहिए.

"Player is accessed on the wrong thread" वाली गड़बड़ियों का क्या मतलब है?

शुरू करने के लिए पेज पर, थ्रेडिंग के बारे में जानकारी देखें.

मैं "Unexpected status line: ICY 200 OK" वाली गड़बड़ी को कैसे ठीक करूं?

यह समस्या तब हो सकती है, जब सर्वर के जवाब में, एचटीटीपी के मुताबिक स्टेटस लाइन के बजाय, आईसीवाई स्टेटस लाइन शामिल हो. आईसीवाई स्टेटस लाइन को बंद कर दिया गया है. इसलिए, इनका इस्तेमाल नहीं किया जाना चाहिए. इसलिए, अगर आपके पास सर्वर को कंट्रोल करने का विकल्प है, तो आपको इसे अपडेट करके, एचटीटीपी के मुताबिक जवाब देना चाहिए. अगर ऐसा नहीं किया जा सकता, तो ExoPlayer OkHttp लाइब्रेरी का इस्तेमाल करने से समस्या हल हो जाएगी. ऐसा इसलिए, क्योंकि यह आईसीवाई स्टेटस लाइन को सही तरीके से हैंडल कर सकती है.

मैं यह क्वेरी कैसे करूं कि जो स्ट्रीम चल रही है वह लाइव स्ट्रीम है या नहीं?

प्लेयर के isCurrentWindowLive तरीके से क्वेरी की जा सकती है. इसके अलावा, यह जानने के लिए कि विंडो डाइनैमिक है या नहीं (यानी, समय के साथ अब भी अपडेट हो रही है), isCurrentWindowDynamic की जांच की जा सकती है.

जब मेरा ऐप्लिकेशन बैकग्राउंड में हो, तब ऑडियो कैसे चलता रहे?

जब आपका ऐप्लिकेशन बैकग्राउंड में हो, तब ऑडियो चलता रहे, इसके लिए यह तरीका अपनाएं:

  1. आपके पास फ़ोरग्राउंड सेवा चालू होनी चाहिए. इससे, सिस्टम, संसाधन खाली करने के लिए आपकी प्रोसेस को बंद नहीं करेगा.
  2. आपके पास WifiLock और WakeLock होना चाहिए. इनसे यह पक्का होता है कि सिस्टम, वाई-फ़ाई रेडियो और सीपीयू को चालू रखे. अगर ExoPlayer का इस्तेमाल किया जा रहा है, तो setWakeMode को कॉल करके, इसे आसानी से किया जा सकता है. इससे, सही समय पर ज़रूरी लॉक अपने-आप मिल जाएंगे और रिलीज़ हो जाएंगे.

यह ज़रूरी है कि लॉक रिलीज़ किए जाएं. अगर setWakeMode का इस्तेमाल नहीं किया जा रहा है, तो ऑडियो चलना बंद होने के तुरंत बाद, सेवा बंद कर दें.

ExoPlayer मेरे कॉन्टेंट के साथ काम क्यों करता है, लेकिन ExoPlayer Cast लाइब्रेरी क्यों नहीं?

ऐसा हो सकता है कि जिस कॉन्टेंट को चलाने की कोशिश की जा रही है वह CORS के साथ काम न करता हो. Cast फ़्रेमवर्क के लिए, कॉन्टेंट को चलाने के लिए, CORS के साथ काम करना ज़रूरी है.

कॉन्टेंट क्यों नहीं चलता, जबकि कोई गड़बड़ी नहीं दिखती?

ऐसा हो सकता है कि जिस डिवाइस पर कॉन्टेंट चलाया जा रहा है वह मीडिया सैंपल के किसी खास फ़ॉर्मैट के साथ काम न करता हो. इसकी पुष्टि आसानी से की जा सकती है. इसके लिए, अपने प्लेयर में EventLogger को लिसनर के तौर पर जोड़ें. इसके बाद, Logcat में इस लाइन को देखें:

[ ] Track:x, id=x, mimeType=mime/type, ... , supported=NO_UNSUPPORTED_TYPE

NO_UNSUPPORTED_TYPE का मतलब है कि डिवाइस, mimeType में तय किए गए मीडिया सैंपल फ़ॉर्मैट को डिकोड नहीं कर सकता. सपोर्ट किए गए सैंपल फ़ॉर्मैट के बारे में जानकारी पाने के लिए, Android के मीडिया फ़ॉर्मैट से जुड़ा दस्तावेज़ देखें. डिकोडिंग लाइब्रेरी को लोड करके, उसे वीडियो चलाने के लिए कैसे इस्तेमाल करूं? लेख भी काम का हो सकता है.

डिकोडिंग लाइब्रेरी को लोड करके, उसे वीडियो चलाने के लिए कैसे इस्तेमाल करूं?

  • ज़्यादातर डिकोडर लाइब्रेरी में, डिपेंडेंसी की जांच करने और उन्हें बनाने के लिए, मैन्युअल तरीके से कुछ चरण पूरे करने पड़ते हैं. इसलिए, पक्का करें कि आपने संबंधित लाइब्रेरी के README में दिए गए चरणों को पूरा कर लिया हो. उदाहरण के लिए, ExoPlayer FFmpeg लाइब्रेरी के लिए, libraries/decoder_ffmpeg/README.md में दिए गए निर्देशों का पालन करना ज़रूरी है. इसमें, उन सभी फ़ॉर्मैट के लिए डिकोडर चालू करने के लिए कॉन्फ़िगरेशन फ़्लैग पास करना शामिल है जिन्हें चलाना है.
  • जिन लाइब्रेरी में नेटिव कोड होता है उनके लिए, पक्का करें कि README में बताए गए Android NDK के सही वर्शन का इस्तेमाल किया जा रहा हो. साथ ही, कॉन्फ़िगरेशन और बिल्ड के दौरान दिखने वाली गड़बड़ियों पर नज़र रखें. README में दिए गए चरणों को पूरा करने के बाद, आपको हर सपोर्ट किए गए आर्किटेक्चर के लिए, लाइब्रेरी के पाथ की libs सबडायरेक्ट्री में .so फ़ाइलें दिखनी चाहिए.
  • डेमो ऐप्लिकेशन में लाइब्रेरी का इस्तेमाल करके, वीडियो चलाने की सुविधा आज़माने के लिए, बंडल किए गए डिकोडर चालू करना लेख देखें. अपने ऐप्लिकेशन से लाइब्रेरी का इस्तेमाल करने के निर्देशों के लिए, लाइब्रेरी का README देखें.
  • अगर DefaultRenderersFactory का इस्तेमाल किया जा रहा है, तो डिकोडर लोड होने पर, आपको Logcat में "Loaded FfmpegAudioRenderer" जैसी जानकारी वाला लॉग दिखेगा. अगर यह लॉग नहीं दिखता है, तो पक्का करें कि ऐप्लिकेशन में डिकोडिंग लाइब्रेरी की डिपेंडेंसी हो.
  • अगर आपको Logcat में LibraryLoader से, चेतावनी वाले लॉग दिखते हैं, तो इसका मतलब है कि लाइब्रेरी का नेटिव कॉम्पोनेंट लोड नहीं हो सका. अगर ऐसा होता है, तो जांचें कि आपने लाइब्रेरी के README में दिए गए चरणों को सही तरीके से पूरा किया है या नहीं. साथ ही, निर्देशों का पालन करते समय कोई गड़बड़ी तो नहीं हुई.

अगर आपको अब भी डिकोडिंग लाइब्रेरी का इस्तेमाल करने में समस्याएं आ रही हैं, तो कृपया Media3 इश्यू ट्रैकर में, हाल ही की कोई भी समस्या देखें. अगर आपको कोई नई समस्या सबमिट करनी है और वह लाइब्रेरी के नेटिव हिस्से को बनाने से जुड़ी है, तो कृपया README के निर्देशों को चलाने से मिला पूरा कमांड लाइन आउटपुट शामिल करें. इससे हमें समस्या की पहचान करने में मदद मिलेगी.

क्या मैं ExoPlayer की मदद से, YouTube के वीडियो सीधे चला सकता/सकती हूं?

नहीं, ExoPlayer, YouTube के वीडियो नहीं चला सकता. जैसे, https://www.youtube.com/watch?v=... फ़ॉर्मैट वाले यूआरएल. इसके बजाय, आपको YouTube iFrame Player API का इस्तेमाल करना चाहिए, यह Android पर YouTube वीडियो चलाने का आधिकारिक तरीका है.

वीडियो रुक-रुककर चल रहा है

ऐसा हो सकता है कि डिवाइस, कॉन्टेंट को तेज़ी से डिकोड न कर पाए. उदाहरण के लिए, अगर कॉन्टेंट की बिटरेट या रिज़ॉल्यूशन, डिवाइस की क्षमताओं से ज़्यादा है. ऐसे डिवाइसों पर अच्छी परफ़ॉर्मेंस पाने के लिए, आपको कम क्वालिटी वाला कॉन्टेंट इस्तेमाल करना पड़ सकता है.

अगर आपको Android 6.0 (एपीआई लेवल 23) से लेकर Android 11 (एपीआई लेवल 30) तक के किसी वर्शन पर चल रहे डिवाइस पर, वीडियो रुक-रुककर चलने की समस्या आ रही है, तो एसिंक्रोनस बफ़र क्यूइंग को चालू करके देखें. खास तौर पर, DRM से सुरक्षित या हाई-फ़्रेम-रेट वाला कॉन्टेंट चलाते समय.

अस्थिर एपीआई लिंट से जुड़ी गड़बड़ियां

Media3, एपीआई के कुछ हिस्से के लिए, बाइनरी फ़ाइल के साथ काम करने की सुविधा की गारंटी देता है. जिन हिस्सों के लिए, बाइनरी फ़ाइल के साथ काम करने की सुविधा की गारंटी नहीं दी जाती है उन्हें @UnstableApi से मार्क किया जाता है. इस अंतर को साफ़ तौर पर दिखाने के लिए, अस्थिर एपीआई सिंबल के इस्तेमाल से लिंट की गड़बड़ी जनरेट होती है. हालांकि, अगर उन्हें @OptIn से एनोटेट किया जाता है, तो ऐसा नहीं होता.

@UnstableApi एनोटेशन से, एपीआई की क्वालिटी या परफ़ॉर्मेंस के बारे में कोई जानकारी नहीं मिलती. इससे सिर्फ़ यह पता चलता है कि यह "एपीआई-फ़्रोज़न" नहीं है.

अस्थिर एपीआई लिंट से जुड़ी गड़बड़ियों को ठीक करने के लिए, आपके पास दो विकल्प हैं:

  • किसी ऐसे स्थिर एपीआई का इस्तेमाल करें जिससे वही नतीजा मिले.
  • अस्थिर एपीआई का इस्तेमाल जारी रखें और इस्तेमाल को @OptIn से एनोटेट करें. इसके बारे में आगे बताया गया है.
@OptIn एनोटेशन जोड़ना

Android Studio, एनोटेशन जोड़ने में आपकी मदद कर सकता है:

स्क्रीनशॉट: ऑप्ट-इन एनोटेशन जोड़ने का तरीका
दूसरी इमेज: Android Studio की मदद से, @androidx.annotations.OptIn एनोटेशन जोड़ना.

खास इस्तेमाल वाली साइटों को मैन्युअल तरीके से भी एनोटेट किया जा सकता है:

Kotlin

import androidx.annotation.OptIn
import androidx.media3.common.util.UnstableApi

@OptIn(UnstableApi::class)
fun functionUsingUnstableApi() { ... }

Java

import androidx.annotation.OptIn;
import androidx.media3.common.util.UnstableApi;

@OptIn(markerClass = UnstableApi.class)
private void methodUsingUnstableApis() { ... }

package-info फ़ाइल जोड़कर, पूरे पैकेज को ऑप्ट-इन किया जा सकता है:

Kotlin

// In your package-info.kt
@OptIn(UnstableApi::class)
package name.of.your.package

import androidx.annotation.OptIn
import androidx.media3.common.util.UnstableApi

Java

// In your package-info.java
@OptIn(markerClass = UnstableApi.class)
package name.of.your.package;

import androidx.annotation.OptIn;
import androidx.media3.common.util.UnstableApi;

पूरे प्रोजेक्ट को ऑप्ट-इन करने के लिए, उनकी lint.xml फ़ाइल में, लिंट की खास गड़बड़ी को दबाया जा सकता है:

 <?xml version="1.0" encoding="utf-8"?>
 <lint>
   <issue id="UnsafeOptInUsageError">
     <option name="opt-in" value="androidx.media3.common.util.UnstableApi" />
   </issue>
 </lint>

kotlin.OptIn एनोटेशन भी है. इसका इस्तेमाल नहीं किया जाना चाहिए. androidx.annotation.OptIn एनोटेशन का इस्तेमाल करना ज़रूरी है.