तपाईंको निजी HLS स्ट्रिम तपाईंका दर्शकका लागि होइन, तपाईंकै लागि लोड हुन्छ

तपाईं ल्यापटपमा पृष्ठ जाँच्नुहुन्छ, प्लेयर सुरु हुन्छ, र टिकट बन्द हुन्छ। अर्को छेउको दर्शकले त्यही पृष्ठ खोल्छ र कहिल्यै नसकिने घुम्ने सूचक पाउँछ। सामान्य व्याख्या यो दिइन्छ कि VPN सर्भरमा छ, त्यसैले प्लेब्याक काम गर्नुपर्छ — तर प्लेलिस्ट माग्ने घटक ब्राउजर हो, र यसको आफ्नै नेटवर्क मार्ग छ। निजी पहुँच भएको सर्भरमा इम्बेड गरिएको पृष्ठ त्यो पहुँच यसलाई लोड गर्ने जोसुकैलाई सापट दिँदैन।

यो http://10.5.5.9:8080/live/stream.m3u8 जस्तो HLS स्रोत चलाउने विद्यमान ASP.NET पृष्ठबारे हो; यो उदाहरणात्मक निजी ठेगाना हो। दुई व्यवस्था काम गर्छन्; तीमध्ये एउटा सम्भवतः तपाईंले बनाएको होइन।

भ्रम: लोड हुने पृष्ठले मिडिया मार्ग प्रमाणित गर्छ

त्यो पृष्ठको 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 हो।

व्यवस्था जानाजान छानिएपछि यसलाई एक हरफमा लेख्नुहोस्: मिडिया कसले ल्याउँछ, कुन मार्गबाट, र दर्शकले के माग्न पाउँछ। त्यो वाक्यले स्ट्रिम वास्तवमा कसका लागि हो भन्ने भविष्यका अधिकांश बहस टुंग्याउँछ।