आपकी निजी 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 होती है।

व्यवस्था जानबूझकर चुनी गई हो जाने पर उसे एक पंक्ति में लिखें: मीडिया कौन लाता है, किस पथ से, और दर्शक को क्या माँगने की अनुमति है। वही वाक्य स्ट्रीम वास्तव में किसके लिए है, इस पर होने वाली अधिकांश भविष्य की बहसें तय कर देता है।