আপনার ব্যক্তিগত HLS স্ট্রিম আপনার জন্যই লোড হয়, দর্শকদের জন্য নয়
পেজটি লোড হয় কারণ আপনার সার্ভার ক্যামেরা পর্যন্ত পৌঁছায়; ব্রাউজার তবুও প্লেলিস্টটি এনে দেয়। কে অনুরোধটি করে তা ঠিক করুন, তারপর চেইনটি যাচাই করুন।
আপনি ল্যাপটপে পেজটি পরীক্ষা করেন, প্লেয়ার শুরু হয়, আর টিকিট বন্ধ হয়ে যায়। অন্যপ্রান্তের দর্শক একই পেজ খুলে এমন একটি স্পিনার পান যা কখনো শেষ হয় না। সাধারণত যে ব্যাখ্যা দেওয়া হয় তা হলো VPN সার্ভারে আছে, তাই প্লেব্যাক কাজ করার কথা — কিন্তু প্লেলিস্টটি চাওয়া উপাদানটি হলো ব্রাউজার, আর তার নিজের নেটওয়ার্ক পথ আছে। ব্যক্তিগত অ্যাক্সেসযুক্ত সার্ভারে এমবেড করা পেজ সেই অ্যাক্সেসটি যিনি এটি লোড করেন তাঁকে ধার দেয় না।
এটি একটি বিদ্যমান ASP.NET পেজ সম্পর্কে যা HLS উৎস চালায়, যেমন http://10.5.5.9:8080/live/stream.m3u8, যা একটি উদাহরণমূলক ব্যক্তিগত ঠিকানা। দুটি বিন্যাস কাজ করে; তাদের একটি সম্ভবত আপনি যা বানিয়েছেন তা নয়।
ভ্রান্ত ধারণা: পেজ লোড হওয়া মিডিয়া পথ প্রমাণ করে
সেই পেজের HTML আসে আপনার ওয়েব সার্ভার থেকে, আপনার ওয়েব সার্ভারের যে পথই থাকুক। প্লেলিস্ট ও সেগমেন্টগুলো আসে মিডিয়া উৎস থেকে, অনুরোধকারী উপাদানের যে পথই থাকুক। যখন প্লেয়ারটি দর্শকের ব্রাউজারে চলে, তখন এরা দুটি আলাদা ক্লায়েন্ট, দুটি আলাদা উৎস ঠিকানা এবং প্রায়ই দুটি আলাদা ব্যর্থতার ডোমেইন। প্রথমটি সফল হতে দেখা দ্বিতীয়টি সম্পর্কে কিছুই বলে না।
আপনার পরীক্ষা আসলে যা প্রমাণ করেছে তা দেখতে যতটা সরু ছিল তার চেয়েও সরু: আপনার মেশিন একই সময়ে পাবলিক পেজ ও ব্যক্তিগত মিডিয়া হোস্ট — দুটোতেই পৌঁছাতে পারে। দর্শকের মেশিন কখনোই পরীক্ষার অংশ ছিল না।
প্লেলিস্ট এরপর কী চায়
RFC 8216 সেগমেন্ট তালিকাভুক্ত মিডিয়া প্লেলিস্টকে অন্য প্লেলিস্ট তালিকাভুক্ত মাস্টার প্লেলিস্ট থেকে আলাদা করে, এবং আপেক্ষিক URI-গুলোকে সেই প্লেলিস্টের URI-র সাপেক্ষে সমাধান করে যা সেগুলো ধারণ করে। এই নিয়মটিই মানুষ এড়িয়ে যায়। একটি .m3u8 ফাইল সফলভাবে আনা কোনো প্লেব্যাক পরীক্ষা নয়, কারণ যে ফাইলটি এনেছেন তা একটি সূচি, মিডিয়া নয়।
প্লেয়ার যেভাবে করে সেভাবেই চেইনটি অনুসরণ করুন: নির্বাচিত প্লেলিস্ট খুলুন, তারপর এটি যে রিসোর্সগুলোর নাম দেয় সেগুলো চান, তারপর যেকোনো রিডাইরেক্ট অনুসরণ করুন। অ্যাক্সেসযোগ্য ওয়েব সার্ভার দিয়ে পরিবেশিত প্লেলিস্টও দর্শককে অপ্রাপ্য ব্যক্তিগত ঠিকানায় পাঠাতে পারে। একইভাবে, আপেক্ষিক প্লেলিস্টকে ভিন্ন URL-এ সরালে তার এন্ট্রিগুলো যে ভিত্তির সাপেক্ষে সমাধান হয় তা বদলে যায়, আর তাই প্রথম দৃশ্যমান URL পুনর্লিখন করে ওখানেই থেমে গেলে সাধারণত বৈধ দেখতে এমন প্লেলিস্ট তৈরি হয় যা চালানো যায় না।
সরাসরি দেখা: দর্শকের পথ দরকার
দর্শকদের যদি সরাসরি মিডিয়া হোস্টে পৌঁছাতে হয়, তবে তাদের ডিভাইসে দরকার অনুমোদিত VPN বা অন্য ব্যক্তিগত পথ, যে নামগুলো আপনি সত্যিই ব্যবহার করেছেন সেগুলো সমাধান করা DNS, সেই গন্তব্যগুলোতে পৌঁছানোর অনুমতি, এবং মিডিয়া সেবা যে অথেন্টিকেশনই চায় তা। প্রতিটি জিনিস সার্ভারে নয়, দর্শকের ডিভাইসে যাচাই করুন। VPN প্রোফাইল ইনস্টল করা কিন্তু সংযুক্ত নয় এমন ফোনের ব্রাউজার একটি সাধারণ ও সম্পূর্ণ পুনরুৎপাদনযোগ্য ব্যর্থতা।
এই বিন্যাস উৎসকে ব্যক্তিগত রাখে এবং অ্যাক্সেসের দাবিটি দর্শকদের ওপর ঠেলে দেয়। এটি প্রযুক্তিগত যতটা, ততটাই নীতিগত সিদ্ধান্ত, তাই এর চারপাশে নকশা করার আগে নিশ্চিত করুন যে প্রত্যেক অভীষ্ট দর্শককে সেই পথ ধরে রাখার অনুমতি আছে।
সার্ভার-সাইড সরবরাহ: একটি নিয়ন্ত্রিত প্রবেশবিন্দু
বিকল্পটি হলো একটি অনুমোদিত মিডিয়া ফ্রন্টএন্ড যা উৎসটি তার ব্যক্তিগত পথে এনে কেবল দর্শকের মুখোমুখি রিসোর্সগুলো পুনঃপ্রকাশ করে। প্লেলিস্ট, সেগমেন্ট এবং যেকোনো কী রিসোর্স সেই একক প্রবেশবিন্দুর সঙ্গে সামঞ্জস্যপূর্ণ রাখুন, নইলে প্লেয়ার পুনর্লিখিত প্লেলিস্ট ফ্রন্টএন্ড দিয়ে আর সেগমেন্টগুলো সরাসরি এমন ঠিকানা থেকে আনবে যেখানে দর্শক পৌঁছাতে পারে না।
সেই ফ্রন্টএন্ডে উৎস ও অনুমোদিত পথগুলো সীমিত করুন। ব্যবহারকারীর দেওয়া ইচ্ছামতো URL একটি উপকারী প্রক্সিকে আপনার অভ্যন্তরীণ নেটওয়ার্কের অবাধ আনয়নকারীতে পরিণত করে, যা এমন স্ট্রিমের চেয়ে অনেক খারাপ সমস্যা যা চলবে না। পরে স্ট্রিং যাচাই করার বদলে উৎস ও পথের প্রিফিক্সকে অনুমোদিত তালিকায় রাখুন।
বিদ্যমান HLS উৎসের জন্য প্রথমে দেখুন নিয়ন্ত্রিত ফরওয়ার্ডিং যথেষ্ট কি না; মাঝখানে VPN থাকার অর্থ ট্রান্সকোডিং আবশ্যক নয়। তারপর প্রকৃত ব্রাউজার ও কোডেক সমন্বয় যাচাই করুন, কারণ পৌঁছানো যায় এমন প্রতিক্রিয়া আর সমর্থিত ফরম্যাট আলাদা দুটি শর্ত। উৎসের TLS, অথেন্টিকেশন ও ব্রাউজার নিরাপত্তার দাবিগুলো অক্ষত রাখুন — এমবেড করা প্লেয়ার সেগুলো থেকে ছাড় নয়।
URL নয়, চেইন পরীক্ষা করুন
যে উপাদান সত্যিই প্রতিটি অনুরোধ করবে তার থেকেই যাচাইগুলো চালান, এবং প্রতিটি ধাপকে তার নিজস্ব ফলাফল হিসেবে ধরুন:
curl -s http://10.5.5.9:8080/live/stream.m3u8
curl -s -o /dev/null -w '%{http_code}\n' http://10.5.5.9:8080/live/segment-000123.tsতারপর এটি দর্শকের নিজের ব্রাউজারে অভীষ্ট স্ট্রিম দিয়ে পুনরাবৃত্তি করুন, আপনার ডেস্কের পরীক্ষামূলক প্যাটার্ন দিয়ে নয়। পেজ লোড, প্লেলিস্ট লোড, সেগমেন্ট আনা এবং অনুমোদন ব্যর্থতা — এই চারটি আলাদা ফলাফল, এবং ঠিক করা বলা আগে চারটিই দেখা চাই। পুরোনো উদাহরণ একটি স্ট্রিম এভাবে চালিয়েছিল বলে পুরোনো ব্রাউজার প্লাগইন ইনস্টল করবেন না; সাধারণত যে অংশটি অনুপস্থিত তা হলো দর্শকের পথ বা স্বাক্ষরবিহীন সেগমেন্ট URL।
বিন্যাসটি সচেতন হয়ে গেলে এক লাইনে লিখে রাখুন: কে মিডিয়া আনবে, কোন পথে, এবং দর্শক কী চাইতে পারবে। সেই বাক্যটিই স্ট্রিমটি আসলে কার জন্য তা নিয়ে ভবিষ্যতের বেশিরভাগ বিতর্ক মিটিয়ে দেয়।