तुमचा खासगी 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 असते।

रचना जाणीवपूर्वक ठरल्यावर ती एका ओळीत लिहा: मीडिया कोण आणतो, कोणत्या मार्गाने, आणि दर्शकाला काय मागण्याची परवानगी आहे। ते वाक्य स्ट्रीम प्रत्यक्षात कोणासाठी आहे यावरील बहुतेक भविष्यातील वाद मिटवते।