कैमरा स्ट्रीम प्रकाशित करना: RTSP और HLS एक ही किनारा नहीं

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

VPN स्रोत का पथ ठीक करता है, दर्शक का नहीं

टनल के ज़रिए कैमरे के लैन से जुड़ा एक VPS कैमरे तक उसके निजी पते पर पहुँच सकता है, और यह वाकई उपयोगी है। इसका मतलब है कि कैमरे को अपना कोई इनबाउंड पोर्ट नहीं चाहिए और घरेलू राउटर बंद रहता है। यह आपको यह नहीं बताता कि कोई दर्शक कौन सी भाषा बोलेगा। डेस्कटॉप प्लेयर, ब्राउज़र, फ़ोन और स्मार्ट टीवी अलग-अलग प्रोटोकॉल का समर्थन करते हैं, और हर एक की TLS, प्रमाणीकरण और कोडेक के बारे में अपनी अपेक्षाएँ हैं।

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

RTSP एक बातचीत है, एक पोर्ट नहीं

RTSP सत्र नियंत्रण ले जाता है: क्लाइंट विवरण माँगता है, एक या अधिक मीडिया ट्रैक सेट करता है और फिर चलाता है। मीडिया का परिवहन स्वयं उसी सेटअप के दौरान तय होता है, इसीलिए प्रोटोकॉल को एक फ़ॉरवर्ड किए गए TCP पोर्ट से अच्छी तरह नहीं समझाया जा सकता। वही बातचीत वह हिस्सा है जिसे लोग फ़ायरवॉल नियमों की तुलना करते समय छोड़ देते हैं।

एंडपॉइंट के आधार पर RTP अलग UDP पोर्ट पर आ सकता है या नियंत्रण कनेक्शन में बुना जा सकता है। केवल 554 आगे भेजने वाला और बाकी के काम करने का अनुमान लगाने वाला रिले आमतौर पर ऐसा सत्र बनाता है जो जुड़ता है, एक ट्रैक की सूचना देता है और फिर कुछ नहीं दिखाता। इसके लिए नियम लिखने से पहले जाँचें कि आपका कैमरा वास्तव में कौन सा परिवहन तय करता है। निजी तरफ़ का कैप्चर इसका जवाब एक मिनट में दे देता है, और अनुमान लगाना एक शाम का नुकसान है।

छोटे, ज्ञात दर्शक वर्ग के लिए जिसके पास संगत प्लेयर हों, जानबूझकर कॉन्फ़िगर किया गया RTSP रिले सही उत्तर हो सकता है। सीमित करें कि यह किस स्रोत से खींच सकता है और रिले पर प्रमाणीकरण माँगें। अपने परीक्षण किए गए प्लेयर लिख लें, क्योंकि VLC में चलने वाली RTSP स्ट्रीम ब्राउज़र में फिर भी विफल हो सकती है।

HLS एक प्लेलिस्ट और संसाधन है

HLS दर्शक एक प्लेलिस्ट लाता है, फिर वे मीडिया सेगमेंट लाता है जिनके नाम वह प्लेलिस्ट बताती है। HLS विनिर्देश उसी संसाधन मॉडल को परिभाषित करता है, और महत्वपूर्ण परिचालन विवरण यह है कि प्लेलिस्ट अन्य URL का संदर्भ देती हैं। सापेक्ष संदर्भ प्लेलिस्ट के स्थान के सापेक्ष हल होते हैं, इसलिए पथ बदलने वाले प्रॉक्सी को उन्हें लगातार बदलना होगा।

यदि कैमरा पहले से उपयोगी HLS परोसता है, तो एक सार्वजनिक फ़्रंटएंड उन प्लेलिस्ट और सेगमेंट अनुरोधों को टनल से आगे भेज सकता है। ऐप्लिकेशन द्वारा बनाई गई कुंजियों, रीडायरेक्ट और URL पर ध्यान दें। निजी होस्ट की ओर इशारा करने वाला कोई भी निरपेक्ष URL उसी पल टूट जाता है जब लैन के बाहर का कोई दर्शक उसका अनुसरण करता है। सापेक्ष पथ ही वे हैं जो प्रॉक्सी के पुनर्लेखन से बचते हैं, इसलिए जहाँ भी आप उत्पन्न आउटपुट नियंत्रित करते हैं वहाँ उन्हें प्राथमिकता दें।

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

अपलिंक की योजना इस आधार पर बनाएँ कि वितरण कहाँ होता है। एक निजी इनजेस्ट जो सार्वजनिक मीडिया सेवा को खिलाता है, हर उस दर्शक से बिल्कुल अलग व्यवहार करता है जो अपनी स्ट्रीम टनल से खींचता है। दूसरा पैटर्न आमतौर पर भरे हुए घरेलू कनेक्शन और ऐसे कैमरे पर खत्म होता है जो बेतरतीब ढंग से विफल दिखता है।

प्रमाणीकरण उस किनारे पर रखें जिसे आप प्रकाशित करते हैं

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

VPN और कैमरे की प्रशासनिक अनुमतियाँ प्रकाशन पथ से अलग रखें। ऐसा VPS जो स्ट्रीम खींचने के लिए कैमरे के वेब इंटरफ़ेस तक पहुँच सकता है, वही मशीन भी नहीं होना चाहिए जो उस इंटरफ़ेस को उजागर करे। दर्शक वर्ग को कभी कैमरे का पता नहीं जानना चाहिए।

फिर उन दो सिरों की जाँच करें जो आपने वास्तव में बनाए, बजाय यह मानने के कि श्रृंखला काम करती है:

$ ffprobe -v error -rtsp_transport tcp rtsp://10.50.0.9:554/stream1
$ curl -sI https://stream.example.net/live/index.m3u8
HTTP/2 200
content-type: application/vnd.apple.mpegurl

निजी स्रोत की सफल जाँच और सार्वजनिक किनारे पर प्लेलिस्ट की सफल प्राप्ति डिज़ाइन के अलग-अलग आधे साबित करती हैं। उन्हें अलग-अलग परखें। उसी तरह के क्लाइंट से प्लेबैक जो आपका दर्शक वर्ग इस्तेमाल करता है, एकमात्र परीक्षण है जो पूरी श्रृंखला को कवर करता है।

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