कॅमेरा स्ट्रीम प्रकाशित करणे: 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

खाजगी स्रोताची यशस्वी तपासणी आणि सार्वजनिक काठावर प्लेलिस्टची यशस्वी प्राप्ती रचनेचे वेगवेगळे अर्धे सिद्ध करतात। त्या वेगळ्या तपासा। तुमचा दर्शकवर्ग वापरतो तशाच प्रकारच्या क्लायंटमधून प्लेबॅक ही एकमेव चाचणी आहे जी संपूर्ण शृंखला व्यापते।

शेवटी तुमच्याकडे प्रत्येक दुव्याला उद्देश असलेली शृंखला असते: खाजगी स्रोत, मर्यादित इनजेस्ट, निवडलेली पॅकेजिंग, अधिकृत दर्शक प्रवेश। यातील कोणताही दुवा ऐच्छिक नाही, आणि कोणताही पोर्ट उघडल्याने तयार होत नाही।