क्यामेरा स्ट्रिम प्रकाशित गर्ने: 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

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

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