সমস্যা সমাধান

"ক্লিয়ারটেক্সট HTTP ট্র্যাফিক অনুমোদিত নয়" ত্রুটিগুলি ঠিক করা হচ্ছে

এই ত্রুটিটি তখনই ঘটবে যখন আপনার অ্যাপটি ক্লিয়ারটেক্সট HTTP ট্র্যাফিকের অনুরোধ করে (অর্থাৎ, http:// এর পরিবর্তে https:// ) যখন এর নেটওয়ার্ক সিকিউরিটি কনফিগারেশন এটির অনুমতি দেয় না। যদি আপনার অ্যাপটি Android 9 (API লেভেল 28) বা তার উচ্চতর ভার্সনকে টার্গেট করে, তাহলে ডিফল্ট কনফিগারেশন দ্বারা ক্লিয়ারটেক্সট HTTP ট্র্যাফিক অক্ষম করা হয়।

যদি আপনার অ্যাপটিকে cleartext HTTP ট্র্যাফিকের সাথে কাজ করতে হয়, তাহলে আপনাকে এমন একটি নেটওয়ার্ক সিকিউরিটি কনফিগারেশন ব্যবহার করতে হবে যা এটির অনুমতি দেয়। বিস্তারিত জানার জন্য অ্যান্ড্রয়েডের নেটওয়ার্ক সিকিউরিটি ডকুমেন্টেশন দেখুন। সমস্ত cleartext HTTP ট্র্যাফিক সক্ষম করতে, আপনি কেবল আপনার অ্যাপের AndroidManifest.xml এর application উপাদানে android:usesCleartextTraffic="true" যোগ করতে পারেন।

ExoPlayer ডেমো অ্যাপটি ডিফল্ট নেটওয়ার্ক সিকিউরিটি কনফিগারেশন ব্যবহার করে, তাই এটি ক্লিয়ারটেক্সট HTTP ট্র্যাফিকের অনুমতি দেয় না। আপনি উপরের নির্দেশাবলী ব্যবহার করে এটি সক্ষম করতে পারেন।

"SSLHandshakeException", "CertPathValidatorException" এবং "ERR_CERT_AUTHORITY_INVALID" ত্রুটিগুলি ঠিক করা হচ্ছে

SSLHandshakeException , CertPathValidatorException এবং ERR_CERT_AUTHORITY_INVALID এই সব ত্রুটি সার্ভারের SSL সার্টিফিকেটের সাথে একটি সমস্যা নির্দেশ করে। এই ত্রুটিগুলি ExoPlayer-এর জন্য নির্দিষ্ট নয়। আরও বিস্তারিত জানার জন্য Android-এর SSL ডকুমেন্টেশন দেখুন।

কিছু মিডিয়া ফাইল কেন খোঁজা যায় না?

ডিফল্টরূপে, ExoPlayer এমন মিডিয়াতে seeking সমর্থন করে না যেখানে প্লেয়ারের জন্য সঠিক seek অপারেশন করার একমাত্র পদ্ধতি হল সম্পূর্ণ ফাইল স্ক্যান করা এবং সূচী করা। ExoPlayer এই ধরনের ফাইলগুলিকে অনাকাঙ্ক্ষিত বলে মনে করে। বেশিরভাগ আধুনিক মিডিয়া কন্টেইনার ফর্ম্যাটে seeking এর জন্য মেটাডেটা থাকে (যেমন একটি নমুনা সূচক), একটি সুনির্দিষ্ট seek অ্যালগরিদম থাকে (উদাহরণস্বরূপ, Ogg এর জন্য ইন্টারপোলেটেড বাইসেকশন অনুসন্ধান), অথবা নির্দেশ করে যে তাদের কন্টেন্ট ধ্রুবক বিটরেট। এই ক্ষেত্রে ExoPlayer দ্বারা দক্ষ seek অপারেশন সম্ভব এবং সমর্থিত।

যদি আপনার অনুসন্ধানের প্রয়োজন হয় কিন্তু আপনার কাছে অপ্রয়োজনীয় মিডিয়া থাকে, তাহলে আমরা আপনার কন্টেন্টকে আরও উপযুক্ত কন্টেইনার ফরম্যাটে রূপান্তর করার পরামর্শ দিচ্ছি। MP3, ADTS এবং AMR ফাইলের জন্য, আপনি এখানে বর্ণিত ফাইলগুলির একটি ধ্রুবক বিটরেট আছে এই ধারণার অধীনে অনুসন্ধান সক্ষম করতে পারেন।

কিছু MP3 ফাইলে অনুসন্ধান কেন ভুল?

পরিবর্তনশীল বিটরেট (VBR) MP3 ফাইলগুলি এমন ব্যবহারের ক্ষেত্রে মৌলিকভাবে অনুপযুক্ত যেখানে সঠিক অনুসন্ধানের প্রয়োজন হয়। এর দুটি কারণ রয়েছে:

  1. সঠিক অনুসন্ধানের জন্য, একটি কন্টেইনার ফর্ম্যাট আদর্শভাবে একটি হেডারে একটি সুনির্দিষ্ট সময়-থেকে-বাইট ম্যাপিং প্রদান করবে। এই ম্যাপিং একজন প্লেয়ারকে সংশ্লিষ্ট বাইট অফসেটে অনুরোধকৃত অনুসন্ধানের সময় ম্যাপ করতে এবং সেই অফসেট থেকে মিডিয়া অনুরোধ, পার্সিং এবং প্লে করা শুরু করতে দেয়। দুর্ভাগ্যবশত, MP3 তে এই ম্যাপিং নির্দিষ্ট করার জন্য উপলব্ধ হেডারগুলি (যেমন XING হেডার) প্রায়শই অস্পষ্ট থাকে।
  2. যেসব কন্টেইনার ফরম্যাটে সঠিক টাইম-টু-বাইট ম্যাপিং (অথবা যেকোনো টাইম-টু-বাইট ম্যাপিং) থাকে না, সেক্ষেত্রে যদি কন্টেইনারে স্ট্রীমে অ্যাবসোলিউট স্যাম্পল টাইমস্ট্যাম্প থাকে, তাহলেও সঠিক সিক করা সম্ভব। এই ক্ষেত্রে, প্লেয়ার সংশ্লিষ্ট বাইট অফসেটের সর্বোত্তম অনুমানের জন্য সিক টাইম ম্যাপ করতে পারে, সেই অফসেট থেকে মিডিয়া অনুরোধ করা শুরু করতে পারে, প্রথম অ্যাবসোলিউট স্যাম্পল টাইমস্ট্যাম্প পার্স করতে পারে এবং সঠিক নমুনা না পাওয়া পর্যন্ত মিডিয়াতে একটি নির্দেশিত বাইনারি অনুসন্ধান কার্যকরভাবে সম্পাদন করতে পারে। দুর্ভাগ্যবশত MP3 স্ট্রীমে অ্যাবসোলিউট স্যাম্পল টাইমস্ট্যাম্প অন্তর্ভুক্ত করে না, তাই এই পদ্ধতিটি সম্ভব নয়।

এই কারণে, VBR MP3 ফাইলে সঠিক অনুসন্ধান করার একমাত্র উপায় হল সম্পূর্ণ ফাইলটি স্ক্যান করা এবং প্লেয়ারে ম্যানুয়ালি একটি টাইম-টু-বাইট ম্যাপিং তৈরি করা। এই কৌশলটি FLAG_ENABLE_INDEX_SEEKING ব্যবহার করে সক্রিয় করা যেতে পারে, যা setMp3ExtractorFlags ব্যবহার করে DefaultExtractorsFactory এ সেট করা যেতে পারে। মনে রাখবেন যে এটি বড় MP3 ফাইলগুলিতে ভালভাবে স্কেল করে না, বিশেষ করে যদি ব্যবহারকারী প্লেব্যাক শুরু করার কিছুক্ষণ পরেই স্ট্রিমের শেষের দিকে অনুসন্ধান করার চেষ্টা করে, যার জন্য প্লেয়ারকে এটি ডাউনলোড না হওয়া পর্যন্ত অপেক্ষা করতে হয় এবং অনুসন্ধান করার আগে পুরো স্ট্রিমটি সূচীবদ্ধ করতে হয়। ExoPlayer-এ, আমরা এই ক্ষেত্রে গতির চেয়ে সঠিকতার জন্য অপ্টিমাইজ করার সিদ্ধান্ত নিয়েছি এবং তাই FLAG_ENABLE_INDEX_SEEKING ডিফল্টরূপে অক্ষম করা আছে।

যদি আপনি যে মিডিয়া চালাচ্ছেন তা নিয়ন্ত্রণ করেন, তাহলে আমরা দৃঢ়ভাবে পরামর্শ দিচ্ছি যে আপনি আরও উপযুক্ত কন্টেইনার ফর্ম্যাট ব্যবহার করুন, যেমন MP4। এমন কোনও ব্যবহারের ঘটনা নেই যেখানে MP3 মিডিয়া ফর্ম্যাটের সেরা পছন্দ।

আমার ভিডিওতে খোঁজা কেন ধীর?

যখন প্লেয়ারটি একটি ভিডিওতে একটি নতুন প্লেব্যাক অবস্থান খুঁজছে তখন তাকে দুটি জিনিস করতে হবে:

  1. নতুন প্লেব্যাক অবস্থানের সাথে সম্পর্কিত ডেটা বাফারে লোড করুন (যদি এই ডেটা ইতিমধ্যেই বাফার করা থাকে তবে এটি প্রয়োজনীয় নাও হতে পারে)।
  2. বেশিরভাগ ভিডিও কম্প্রেশন ফরম্যাটে ব্যবহৃত ইন্ট্রা-ফ্রেম কোডিংয়ের কারণে, নতুন প্লেব্যাক পজিশনের আগে ভিডিও ডিকোডারটি ফ্লাশ করুন এবং আই-ফ্রেম (কীফ্রেম) থেকে ডিকোডিং শুরু করুন। সিক সঠিক কিনা তা নিশ্চিত করার জন্য (অর্থাৎ, প্লেব্যাকটি সিক পজিশনে ঠিক শুরু হয়), পূর্ববর্তী আই-ফ্রেম এবং সিক পজিশনের মধ্যে থাকা সমস্ত ফ্রেম ডিকোড করতে হবে এবং অবিলম্বে বাতিল করতে হবে (স্ক্রিনে দেখানো ছাড়াই)।

(1) দ্বারা প্রবর্তিত ল্যাটেন্সি প্লেয়ার দ্বারা মেমরিতে বাফার করা ডেটার পরিমাণ বাড়িয়ে অথবা ডিস্কে ডেটা প্রাক-ক্যাশে করে কমানো যেতে পারে।

(2) দ্বারা প্রবর্তিত ল্যাটেন্সিটি ExoPlayer.setSeekParameters ব্যবহার করে seek এর নির্ভুলতা হ্রাস করে, অথবা আরও ঘন ঘন I-ফ্রেম (যার ফলে একটি বৃহত্তর আউটপুট ফাইল তৈরি হবে) পেতে ভিডিওটি পুনরায় এনকোড করে হ্রাস করা যেতে পারে।

কিছু MPEG-TS ফাইল কেন চলতে ব্যর্থ হয়?

কিছু MPEG-TS ফাইলে অ্যাক্সেস ইউনিট ডিলিমিটার (AUD) থাকে না। ডিফল্টরূপে, ExoPlayer সস্তায় ফ্রেমের সীমানা সনাক্ত করতে AUD-এর উপর নির্ভর করে। একইভাবে, কিছু MPEG-TS ফাইলে IDR কীফ্রেম থাকে না। ডিফল্টরূপে, ExoPlayer দ্বারা বিবেচনা করা হয় এমন একমাত্র ধরণের কীফ্রেম।

AUD বা IDR কীফ্রেমবিহীন MPEG-TS ফাইল চালানোর জন্য বলা হলে ExoPlayer বাফারিং অবস্থায় আটকে যাবে বলে মনে হবে। যদি আপনার এই ধরনের ফাইল চালানোর প্রয়োজন হয়, তাহলে আপনি যথাক্রমে FLAG_DETECT_ACCESS_UNITS এবং FLAG_ALLOW_NON_IDR_KEYFRAMES ব্যবহার করে এটি করতে পারেন। এই ফ্ল্যাগগুলি setTsExtractorFlags ব্যবহার করে DefaultExtractorsFactory তে অথবা constructor ব্যবহার করে DefaultHlsExtractorFactory তে সেট করা যেতে পারে। AUD-ভিত্তিক ফ্রেম সীমানা সনাক্তকরণের তুলনায় গণনামূলকভাবে ব্যয়বহুল হওয়া ছাড়া FLAG_DETECT_ACCESS_UNITS ব্যবহারের কোনও পার্শ্বপ্রতিক্রিয়া নেই। কিছু MPEG-TS ফাইল চালানোর সময় প্লেব্যাকের শুরুতে এবং seeks-এর পরপরই FLAG_ALLOW_NON_IDR_KEYFRAMES ব্যবহারের ফলে অস্থায়ী ভিজ্যুয়াল দুর্নীতি হতে পারে।

কিছু MPEG-TS ফাইলে সাবটাইটেল পাওয়া যায় না কেন?

কিছু MPEG-TS ফাইলে CEA-608 ট্র্যাক থাকে কিন্তু কন্টেইনার মেটাডেটাতে সেগুলি ঘোষণা করে না, তাই ExoPlayer সেগুলি সনাক্ত করতে অক্ষম। আপনি DefaultExtractorsFactory তে প্রত্যাশিত সাবটাইটেল ফর্ম্যাটের একটি তালিকা প্রদান করে যেকোনো সাবটাইটেল ট্র্যাক ম্যানুয়ালি নির্দিষ্ট করতে পারেন, যার মধ্যে MPEG-TS স্ট্রীমে সেগুলি সনাক্ত করতে ব্যবহার করা যেতে পারে এমন অ্যাক্সেসিবিলিটি চ্যানেলগুলিও অন্তর্ভুক্ত রয়েছে:

কোটলিন 

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()

জাভা 

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 তে setMp4ExtractorFlags অথবা setFragmentedMp4ExtractorFlags ব্যবহার করে সেট করা যেতে পারে।

HTTP রেসপন্স কোড 301 বা 302 দিয়ে কিছু স্ট্রিম কেন ব্যর্থ হয়?

HTTP রেসপন্স কোড 301 এবং 302 উভয়ই রিডাইরেকশন নির্দেশ করে। সংক্ষিপ্ত বিবরণ উইকিপিডিয়ায় পাওয়া যাবে। যখন ExoPlayer একটি অনুরোধ করে এবং স্ট্যাটাস কোড 301 বা 302 সহ একটি প্রতিক্রিয়া পায়, তখন এটি সাধারণত রিডাইরেক্ট অনুসরণ করে এবং স্বাভাবিকভাবে প্লেব্যাক শুরু করে। ডিফল্টভাবে এটি ঘটে না এমন একটি ক্ষেত্রে হল ক্রস-প্রোটোকল রিডাইরেক্ট। একটি ক্রস-প্রোটোকল রিডাইরেক্ট হল এমন একটি রিডাইরেক্ট যা HTTPS থেকে HTTP-তে বা তদ্বিপরীত (অথবা কম সাধারণভাবে, অন্য জোড়া প্রোটোকলের মধ্যে) পুনঃনির্দেশ করে। আপনি wget কমান্ড লাইন টুল ব্যবহার করে একটি URL ক্রস-প্রোটোকল রিডাইরেক্ট করে কিনা তা পরীক্ষা করতে পারেন:

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, এবং তাই এটি একটি ক্রস-প্রোটোকল পুনঃনির্দেশনা নয়। দ্বিতীয় পুনঃনির্দেশটি https://secondserver.example.net/test.mp3 থেকে http://thirdserver.example.org/test.mp3 এ। এটি HTTPS থেকে HTTP এ পুনঃনির্দেশনা করে এবং একইভাবে একটি ক্রস-প্রোটোকল পুনঃনির্দেশনাও। ExoPlayer তার ডিফল্ট কনফিগারেশনে এই পুনঃনির্দেশনা অনুসরণ করবে না, যার অর্থ প্লেব্যাক ব্যর্থ হবে।

যদি আপনার প্রয়োজন হয়, তাহলে আপনি ExoPlayer কে আপনার অ্যাপ্লিকেশনে ব্যবহৃত DefaultHttpDataSource.Factory ইনস্ট্যান্স ইন্সট্যান্ট করার সময় ক্রস-প্রোটোকল রিডাইরেক্ট অনুসরণ করার জন্য কনফিগার করতে পারেন। এখানে নেটওয়ার্ক স্ট্যাক নির্বাচন এবং কনফিগার করার বিষয়ে জানুন।

UnrecognizedInputFormatException-এর সাথে কিছু স্ট্রিম কেন ব্যর্থ হয়?

এই প্রশ্নটি নিম্নলিখিত ফর্মের প্লেব্যাক ব্যর্থতার সাথে সম্পর্কিত:

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

এই ব্যর্থতার দুটি সম্ভাব্য কারণ রয়েছে। সবচেয়ে সাধারণ কারণ হল আপনি DASH (mpd), HLS (m3u8), অথবা SmoothStreaming (ism, isml) কন্টেন্ট চালানোর চেষ্টা করছেন, কিন্তু প্লেয়ার এটিকে একটি প্রগতিশীল স্ট্রিম হিসেবে চালানোর চেষ্টা করছে। এই ধরনের স্ট্রিম চালানোর জন্য, আপনাকে সংশ্লিষ্ট ExoPlayer মডিউলের উপর নির্ভর করতে হবে। যেসব ক্ষেত্রে স্ট্রিম URI স্ট্যান্ডার্ড ফাইল এক্সটেনশন দিয়ে শেষ হয় না, সেখানে আপনি MimeTypes.APPLICATION_MPD , MimeTypes.APPLICATION_M3U8 অথবা MimeTypes.APPLICATION_SS পাস করে MediaItem.Builder এর setMimeType পারেন যাতে স্পষ্টভাবে স্ট্রিমের ধরণ নির্দিষ্ট করা যায়।

দ্বিতীয়, খুব কম দেখা যায় এমন কারণ হল, ExoPlayer আপনার পছন্দের মিডিয়ার কন্টেইনার ফর্ম্যাটটি সমর্থন করে না। এই ক্ষেত্রে, ব্যর্থতাটি যেমনটি আশা করা হচ্ছে তেমনই কাজ করছে, তবে আমাদের ইস্যু ট্র্যাকারে একটি ফিচার অনুরোধ জমা দিতে দ্বিধা করবেন না, যার মধ্যে কন্টেইনার ফর্ম্যাট এবং একটি পরীক্ষামূলক স্ট্রিম সম্পর্কিত বিশদ অন্তর্ভুক্ত থাকবে। নতুন একটি জমা দেওয়ার আগে অনুগ্রহ করে বিদ্যমান ফিচার অনুরোধটি অনুসন্ধান করুন।

কিছু ডিভাইসে setPlaybackParameters সঠিকভাবে কাজ করে না কেন?

Android M এবং তার আগের ভার্সনে আপনার অ্যাপের ডিবাগ বিল্ড চালানোর সময়, setPlaybackParameters API ব্যবহার করার সময় আপনার কর্মক্ষমতা হ্রাস, শ্রবণযোগ্য আর্টিফ্যাক্ট এবং উচ্চ CPU ব্যবহারের অভিজ্ঞতা হতে পারে। কারণ এই API-এর জন্য গুরুত্বপূর্ণ একটি অপ্টিমাইজেশন Android-এর এই ভার্সনগুলিতে চলমান ডিবাগ বিল্ডগুলির জন্য অক্ষম করা আছে।

এটা মনে রাখা গুরুত্বপূর্ণ যে এই সমস্যাটি শুধুমাত্র ডিবাগ বিল্ডগুলিকে প্রভাবিত করে। এটি রিলিজ বিল্ডগুলিকে প্রভাবিত করে না , যার জন্য অপ্টিমাইজেশন সর্বদা সক্ষম থাকে। তাই আপনি শেষ ব্যবহারকারীদের জন্য যে রিলিজগুলি প্রদান করেন সেগুলি এই সমস্যার দ্বারা প্রভাবিত হওয়া উচিত নয়।

"প্লেয়ার ভুল থ্রেডে অ্যাক্সেস করা হয়েছে" ত্রুটির অর্থ কী?

শুরু করার পৃষ্ঠায় থ্রেডিং সম্পর্কে একটি নোট দেখুন।

"অপ্রত্যাশিত স্ট্যাটাস লাইন: ICY 200 ঠিক আছে" কীভাবে ঠিক করব?

এই সমস্যাটি তখনই হতে পারে যখন সার্ভারের প্রতিক্রিয়ায় HTTP-সম্মতিপূর্ণ লাইনের পরিবর্তে ICY স্ট্যাটাস লাইন থাকে। ICY স্ট্যাটাস লাইনগুলি বন্ধ করে দেওয়া হয়েছে এবং ব্যবহার করা উচিত নয়, তাই যদি আপনি সার্ভার নিয়ন্ত্রণ করেন তবে HTTP-সম্মতিপূর্ণ প্রতিক্রিয়া প্রদানের জন্য এটি আপডেট করা উচিত। যদি আপনি এটি করতে অক্ষম হন তবে ExoPlayer OkHttp লাইব্রেরি ব্যবহার করলে সমস্যার সমাধান হবে, কারণ এটি ICY স্ট্যাটাস লাইনগুলি সঠিকভাবে পরিচালনা করতে সক্ষম।

যে স্ট্রিমটি চালানো হচ্ছে তা লাইভ স্ট্রিম কিনা তা আমি কীভাবে জিজ্ঞাসা করতে পারি?

আপনি প্লেয়ারের isCurrentWindowLive পদ্ধতিটি জিজ্ঞাসা করতে পারেন। এছাড়াও, আপনি isCurrentWindowDynamic পরীক্ষা করে দেখতে পারেন যে উইন্ডোটি গতিশীল কিনা (অর্থাৎ, সময়ের সাথে সাথে এখনও আপডেট হচ্ছে)।

আমার অ্যাপটি ব্যাকগ্রাউন্ডে থাকা অবস্থায় আমি কীভাবে অডিও প্লে করতে থাকব?

আপনার অ্যাপটি ব্যাকগ্রাউন্ডে থাকাকালীন অডিও প্লেব্যাক অব্যাহত রাখতে এই পদক্ষেপগুলি অনুসরণ করুন:

  1. আপনার একটি চলমান ফোরগ্রাউন্ড পরিষেবা থাকা প্রয়োজন। এটি সিস্টেমকে রিসোর্স খালি করার জন্য আপনার প্রক্রিয়াটি বন্ধ করতে বাধা দেয়।
  2. আপনার একটি WifiLock এবং একটি WakeLock ধরে রাখা দরকার। এগুলি নিশ্চিত করে যে সিস্টেমটি WiFi রেডিও এবং CPU-কে জাগ্রত রাখে। setWakeMode কল করে ExoPlayer ব্যবহার করে এটি সহজেই করা যেতে পারে, যা সঠিক সময়ে প্রয়োজনীয় লকগুলি স্বয়ংক্রিয়ভাবে অর্জন করবে এবং ছেড়ে দেবে।

অডিও আর বাজানো বন্ধ হওয়ার সাথে সাথে লকগুলি (যদি setWakeMode ব্যবহার না করেন) খুলে দেওয়া এবং পরিষেবাটি বন্ধ করে দেওয়া গুরুত্বপূর্ণ।

কেন ExoPlayer আমার কন্টেন্ট সাপোর্ট করে কিন্তু ExoPlayer Cast লাইব্রেরি সাপোর্ট করে না?

এটা সম্ভব যে আপনি যে কন্টেন্টটি চালানোর চেষ্টা করছেন তা CORS সক্ষম নয়। কাস্ট ফ্রেমওয়ার্কের জন্য কন্টেন্টটি চালানোর জন্য 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 ইউটিউব থেকে ভিডিও চালাতে পারবে না, যেমন https://www.youtube.com/watch?v=... ফর্মের URL। পরিবর্তে, আপনার YouTube IFrame Player API ব্যবহার করা উচিত, যা অ্যান্ড্রয়েডে ইউটিউব ভিডিও চালানোর অফিসিয়াল উপায়।

ভিডিও প্লেব্যাক তোতলানো হচ্ছে

উদাহরণস্বরূপ, যদি কন্টেন্ট বিটরেট বা রেজোলিউশন ডিভাইসের ক্ষমতার চেয়ে বেশি হয়, তাহলে ডিভাইসটি কন্টেন্টটি যথেষ্ট দ্রুত ডিকোড করতে সক্ষম নাও হতে পারে। এই ধরনের ডিভাইসে ভালো পারফরম্যান্স পেতে আপনাকে নিম্নমানের কন্টেন্ট ব্যবহার করতে হতে পারে।

যদি আপনি এমন কোনও ডিভাইসে ভিডিও তোতলানোর অভিজ্ঞতা পান যা Android 6.0 (API লেভেল 23) থেকে Android 11 (API লেভেল 30) পর্যন্ত Android এর একটি সংস্করণ চালাচ্ছে, বিশেষ করে যখন DRM সুরক্ষিত বা উচ্চ-ফ্রেম-রেট কন্টেন্ট চলছে, তাহলে আপনি অ্যাসিঙ্ক্রোনাস বাফার কিউয়িং সক্ষম করার চেষ্টা করতে পারেন।

অস্থির API লিন্ট ত্রুটি

Media3 API পৃষ্ঠের একটি উপসেটের জন্য বাইনারি সামঞ্জস্যের নিশ্চয়তা দেয়। যে অংশগুলি বাইনারি সামঞ্জস্যের নিশ্চয়তা দেয় না সেগুলিকে @UnstableApi দিয়ে চিহ্নিত করা হয়। এই পার্থক্যটি স্পষ্ট করার জন্য, অস্থির API প্রতীকগুলির ব্যবহার একটি লিন্ট ত্রুটি তৈরি করে যদি না সেগুলি @OptIn দিয়ে টীকা করা হয়।

@UnstableApi টীকাটি API-এর গুণমান বা কর্মক্ষমতা সম্পর্কে কিছুই বোঝায় না, শুধুমাত্র এই বিষয়টি বোঝায় যে এটি "API-ফ্রোজেন" নয়।

অস্থির API লিন্ট ত্রুটিগুলি পরিচালনা করার জন্য আপনার কাছে দুটি বিকল্প রয়েছে:

  • একই ফলাফল অর্জনকারী একটি স্থিতিশীল API ব্যবহারে স্যুইচ করুন।
  • অস্থির API ব্যবহার চালিয়ে যান এবং @OptIn দিয়ে ব্যবহারটি টীকা করুন, যেমনটি পরে দেখানো হয়েছে।
@OptIn অ্যানোটেশন যোগ করুন

অ্যান্ড্রয়েড স্টুডিও আপনাকে টীকাটি যোগ করতে সাহায্য করতে পারে:

স্ক্রিনশট: অপটিন অ্যানোটেশন কীভাবে যোগ করবেন
চিত্র ২ : অ্যান্ড্রয়েড স্টুডিওর সাথে একটি @androidx.annotations.OptIn অ্যানোটেশন যোগ করা হচ্ছে।

আপনি কোটলিনে নির্দিষ্ট ব্যবহারের সাইটগুলি ম্যানুয়ালি টীকা করতে পারেন:

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

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

এবং জাভাতেও:

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

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

একটি 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 অ্যানোটেশন ব্যবহার করা গুরুত্বপূর্ণ।