🤛 🤕 🔴 वेबआरटीसी और वीडियो निगरानी: हमने कैमरों से वीडियो की देरी को कैसे हराया 🐃 🦖 🎍

क्लाउड-आधारित वीडियो निगरानी प्रणाली पर काम करने के पहले दिनों से, हमें एक समस्या का सामना करना पड़ा, जिसके बिना इविडॉन को समाप्त करना संभव था - यह हमारा एवरेस्ट था, इस पर चढ़ने से बहुत ऊर्जा लगती थी, लेकिन अब हमने अंत में क्रॉस प्लेटफॉर्म रीबस के मुकुट में एक बर्फ की कुल्हाड़ी मार दी।

इंटरनेट पर ऑडियो और वीडियो प्रसारित करने की प्रणाली उपकरण, वेब क्लाइंट और उनके द्वारा समर्थित मानकों पर निर्भर नहीं होनी चाहिए, और नेटवर्क एड्रेस ट्रांसलेटर और फायरवॉल होने पर भी सही ढंग से काम करती है। क्लाउड वीडियो निगरानी का उपयोगकर्ता सेवा का उपयोग करना चाहता है, भले ही वह एनालॉग कैमरों का उपयोग करता हो, और सबसे आधुनिक डिवाइस पर लाइव वीडियो प्रसारण देखना पसंद करता है।

यह बहुत महत्वपूर्ण है कि उपयोगकर्ता न्यूनतम विलंब के साथ वीडियो देखना चाहता है। ब्राउज़र में कम विलंबता वीडियो प्रदर्शित करने का लगभग एकमात्र तरीका WebRTC (वेब रीयल-टाइम संचार) का उपयोग करना है। WebRTC ब्राउज़रों में पीयर-टू-पीयर वीडियो और ऑडियो ट्रांसमिशन के लिए प्रौद्योगिकियों का एक सेट है, जो मूल रूप से कम विलंबता के साथ वीडियो स्ट्रीम को प्रसारित करने और खेलने के लिए डिज़ाइन किया गया है। इसके लिए, अन्य चीजों के बीच, यूडीपी प्रोटोकॉल का उपयोग किया जाता है।

आपको यह बताने से पहले कि नया इंजन उपयोगकर्ता को क्या देता है, हम आपको याद दिलाएंगे कि हम क्यों और क्यों एचएलएस तकनीकों का समर्थन करते हैं, और इसके लिए हमने क्या कदम उठाया।

एचएलएस इंजन: पेशेवरों और विपक्ष

( ग )

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

एचएलएस इंजन वीडियो स्ट्रीमिंग के लिए एएसी या एमपी 3 ऑडियो स्ट्रीम के संयोजन में प्रसिद्ध एच 264 वीडियो कोडेक का उपयोग करता है। संपूर्ण ऑडियो और वीडियो स्ट्रीम को MPEG-TS ट्रांसपोर्ट कंटेनर में पैक किया जाता है। HTTP के माध्यम से प्रसारण के लिए, स्ट्रीम में निहित जानकारी को m3u8 प्लेलिस्ट में वर्णित अंशों में विभाजित किया गया है। और उसके बाद ही, ये टुकड़े, प्लेलिस्ट के साथ, HTTP के माध्यम से प्रेषित होते हैं। टुकड़ों में विभाजित होने का अर्थ है, सेकंड में देरी। एमपीईजी-टीएस कंटेनर की ऐसी सुविधा।

HLS इंजन मल्टीबिट स्ट्रीम, लाइव / VOD को भी सपोर्ट करता है।

HLS के मुख्य लाभ:

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

इंजन की सभी सादगी के लिए, सब कुछ उतना आसान नहीं है जितना लगता है। मुख्य समस्या यह है कि तृतीय-पक्ष के खिलाड़ियों के डेवलपर्स समर्थित ऑडियो प्रारूपों के मामले में, उदाहरण के लिए, ऐप्पल की सिफारिशों से दूर चले गए हैं। विशेष रूप से, कई डेवलपर्स ने लोकप्रिय ऑडियो स्ट्रीम के साथ काम करने की क्षमता को जोड़ना शुरू किया: mpeg2 वीडियो, mpeg2 ऑडियो, आदि। नतीजतन, हमें विभिन्न खिलाड़ियों के लिए अलग-अलग प्लेलिस्ट प्रारूप बनाने थे।

लेकिन एचएलएस इंजन के साथ सबसे बड़ी समस्याओं में से एक डेटा ट्रांसफर में उच्च विलंबता है।

"ब्रेक" की उत्पत्ति

एचएलएस में उच्च देरी का मुख्य कारण इस तथ्य में निहित है कि प्रोग्रामर ने उच्चतम गुणवत्ता वाली तस्वीर प्राप्त करने के लिए एक इंजन बनाया। इसलिए, उपयोग किए गए फ़्रेम अंतराल और प्लेबैक बफर के आकार के पैरामीटर बस लाइव वीडियो प्रसारण आयोजित करने के लिए उपयुक्त नहीं हैं। इस वजह से, वीडियो अनुक्रम के प्रसारण में अधिक उच्च विलंब होता है, जो 5-7 सेकंड हो सकता है।

एक तरफ, यह एक बिट है, उदाहरण के लिए, जो वीडियो होस्टिंग सर्वर से फिल्म देखते हैं। लेकिन वीडियो निगरानी प्रणाली के लिए, फुटेज के प्रसारण में देरी बहुत महत्वपूर्ण हो सकती है।

यदि आप एक कार्यालय का निरीक्षण कर रहे हैं, जहां कर्मचारी एक घंटे में एक बार मॉनिटर से आते हैं, तो 5 सेकंड की देरी मायने नहीं रखती है। लेकिन लोगों ने शिकायत करना शुरू कर दिया, उदाहरण के लिए, एक फुटबॉल मैच का प्रसारण करते समय, गोजोओल पहले से ही चैट में लिखा गया था, लेकिन यह वीडियो पर नहीं है :)। हमारे पास पहले से ही कई कस्टम मामले हैं जहां Ivideon को स्काइप को लगभग बदलना चाहिए।

क्या एचएलएस में देरी को हराना संभव है? इस सवाल का जवाब नौसिखिए व्यवधान से पहले एक व्याख्यान में एक अनुभवी चूहे सेनानी द्वारा एक भाषण की तरह लगता है: "चूहों को अलग नहीं किया जा सकता है, लेकिन उनकी संख्या एक उचित न्यूनतम तक कम हो सकती है।" तो एचएलएस में देरी के साथ, इसे शून्य पर हटाने से काम नहीं चलेगा, लेकिन बाजार पर ऐसे समाधान हैं जो देरी को काफी कम कर सकते हैं।

उथला कट

इंजन का एक और नुकसान डेटा ट्रांसफर के लिए छोटे आकार की फ़ाइलों का उपयोग है। ऐसा लगेगा कि यह बुरा है?

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

एचएलएस प्रौद्योगिकी के सभी पेशेवरों और विपक्षों को संक्षेप में संक्षेप में बताएं।

HLS के लाभ:

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

नुकसान:

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

एचएलएस के नुकसान ने हमारे लिए इसके लाभों को पछाड़ दिया और हमें वैकल्पिक विकल्पों की तलाश करने के लिए मजबूर किया।

WebRTC क्या है?

( ग )

WebRTC को Google द्वारा 2011 में ब्राउज़र और मोबाइल एप्लिकेशन के बीच न्यूनतम विलंबता के साथ वीडियो और ऑडियो स्ट्रीम करने के लिए विकसित किया गया था। इसके लिए, मानक यूडीपी प्रोटोकॉल और विशेष प्रवाह नियंत्रण एल्गोरिदम का उपयोग किया जाता है। आज यह एक ओपन सोर्स प्रोजेक्ट है, यह Google द्वारा सक्रिय रूप से समर्थित है और विकसित हो रहा है।

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

सभी लोकप्रिय ब्राउज़रों के डेवलपर्स द्वारा इस तकनीक की सुविधा और महान क्षमताओं की सराहना की गई। आज WebRTC समर्थन मोज़िला फ़ायरफ़ॉक्स, ओपेरा, Google क्रोम (और क्रोमियम पर आधारित सभी ब्राउज़र), साथ ही एंड्रॉइड और आईओएस के लिए मोबाइल अनुप्रयोगों में लागू किया गया है।

अपने सभी निस्संदेह लाभों के साथ, WebRTC के कई महत्वपूर्ण नुकसान हैं।

चुनने में कठिनाई

वेबआरटीसी नेटवर्किंग के मामले में बहुत अधिक जटिल है क्योंकि यह पी 2 पी के बारे में है। डिबग करना, परीक्षण करना मुश्किल है, यह अप्रत्याशित रूप से व्यवहार कर सकता है। इस मामले में, हमें NAT और फ़ायरवॉल को दूर करने की आवश्यकता है, हमें उन नेटवर्क में काम प्रदान करने की आवश्यकता है जहां UDP अवरुद्ध है।

Google के WebRTC कार्यान्वयन का उपयोग करना बहुत मुश्किल है। यहां तक कि एक पूरी कंपनी है जो एसडीके विधानसभा सेवाएं प्रदान करती है। साथ ही, Google से कार्यान्वयन को हमारे सिस्टम के साथ एकीकृत करना बहुत मुश्किल था, ताकि यह सभी वीडियो को ट्रांसकोड न करे।

हालांकि, हम लंबे समय से उपयोगकर्ताओं को एक पूर्ण "लाइव" वीडियो अनुक्रम के साथ काम करने का अवसर देना चाहते हैं और घटनाओं से स्वयं स्क्रीन पर छवि के अंतराल को कम कर सकते हैं। इसके अलावा, हम PTZ कैमरों के उपयोग को और अधिक आरामदायक बनाने की इच्छा रखते थे, जहां देरी महत्वपूर्ण है।

यह देखते हुए कि अब तक लैग के खिलाफ लड़ाई के अन्य कार्यान्वयन सीमित कार्यक्षमता हैं और उल्लेखनीय रूप से बदतर हैं, हमने WebTCTC का उपयोग करने का निर्णय लिया।

हमने क्या किया है?

WebRTC प्लेटफ़ॉर्म को ठीक से लागू करना आसान काम नहीं है। कोई भी मिसकैरेज या अशुद्धि इस तथ्य को जन्म दे सकती है कि वीडियो दृश्यों के प्रसारण में देरी न केवल अन्य प्लेटफार्मों की तुलना में घटती है, बल्कि बढ़ती भी है।

WebRTC को सही ढंग से काम करने के लिए, सबसे पहले, वेब वीडियो के साथ काम करने के लिए स्टैक का तकनीकी आधुनिकीकरण करना आवश्यक है। जो हमने किया।

सबसे पहले, हमने वेबसोकेट के शीर्ष पर WebRTC सिग्नलिंग प्रोटोकॉल सर्वर को लागू किया, और webrtc.org SDK पर आधारित क्लाउड में WebRTC सहकर्मी सर्वर को भी तैनात किया। इसका कार्य क्लाइंट वेबआरटीसी साथियों को वीडियो ट्रांसफरिंग के बिना H.264 + Opus / G.711 प्रारूप में वीडियो स्ट्रीम वितरित करना है।

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

तथ्य यह है कि डिफ़ॉल्ट रूप से WebRTC उचित कॉन्फ़िगरेशन, समर्थन और स्रोत और क्लाइंट अनुप्रयोगों के बीच वास्तविक समय वीडियो संचार को तोड़ने के लिए आवश्यक सिग्नलिंग प्रोटोकॉल प्रदान नहीं करता है।

और सिग्नलिंग तकनीक को स्वतंत्र रूप से लागू करने के लिए, हमें कई वेब प्रोटोकॉल (वेब्सोसेट, वेबआरटीसी) के समर्थन के साथ अपने स्वयं के सिग्नल सर्वर को विकसित करने की आवश्यकता थी। और वास्तविक समय, वीडियो प्रबंधन और कई अन्य मापदंडों में सत्र और सूचनाओं को सुरक्षित रूप से प्रबंधित करने की क्षमता के साथ भी।

हमने पी 2 पी के कारण देरी को कम करके पी 2 पी की सीमाओं को पार कर लिया, लेकिन यूडीपी और प्रवाह नियंत्रण के कारण देरी को कम करना। यह भी WebRTC में एम्बेडेड है, क्योंकि मुख्य उपयोग-केस ब्राउज़र के माध्यम से p2p वार्तालाप है।

मोबाइल क्लाइंट में, हमने webrtc.org SDK का उपयोग करके खिलाड़ी को लागू किया है, क्योंकि इसमें केवल प्रवाह नियंत्रण को सही ढंग से लागू किया गया है, सभी ज्ञात फ़ॉरवर्ड एरर करेक्शन (FEC) योजनाएं हैं, और सभी ब्राउज़रों के लिए पैकेट को फिर से भेजने की व्यवस्था सही ढंग से लागू की गई है। यह भी महत्वपूर्ण है कि एसडीके webrtc.org Google द्वारा सक्रिय रूप से विकसित किया गया है।

WebRTC को लागू करने का परिणाम क्या है?

कैमरों से लाइव वीडियो देखने के लिए, हमने अपने खाते में WebRTC पर आधारित एक नया अनुकूलित खिलाड़ी जोड़ा। यह हाई-स्पीड वीडियो फुटेज प्रदान करता है और देखने के समय बढ़ने के साथ विलंब संचय की समस्या को पूरी तरह से समाप्त करता है।

इवीडॉन क्लाउड सेवा में WebRTC समर्थन को लागू करने के बाद, हम आत्मविश्वास से कह सकते हैं कि अब हमारे ग्राहक पूर्ण लाइव वीडियो देख सकते हैं। अब फुटेज को प्रसारित करने में देरी एक सेकंड से अधिक नहीं होती है! तुलना के लिए, पिछले एचएलएस इंजन ने 5-7 सेकंड की देरी के साथ वीडियो वितरण प्रदान किया। वीडियो प्रदर्शन की गति में अंतर बहुत महत्वपूर्ण है, और उपयोगकर्ता हमारी वीडियो सेवा के साथ काम करने के तुरंत बाद इसे नोटिस करेगा।

जैसा कि हमने उम्मीद की थी, नए खिलाड़ी के कार्यान्वयन ने हमें कैमरे के साथ पीटीजेड और आवाज संचार की जवाबदेही बढ़ाने की अनुमति दी।

केवल एक सूक्ष्म बिंदु है जिस पर हम ध्यान आकर्षित करना चाहते हैं। नया WebRTC खिलाड़ी अभी भी परीक्षण मोड में है। और यही कारण है कि हम इसे डिफ़ॉल्ट रूप से अपने सभी ग्राहकों से नहीं जोड़ते हैं। लेकिन आप कैमरा सेटिंग्स में संबंधित आइटम को सक्षम करके इसे स्वयं सक्रिय कर सकते हैं (इसके लिए आपको अपने व्यक्तिगत खाते में जाने की आवश्यकता है)।

Ivideon सेवा में WebRTC कार्यान्वयन की विशेषताएं

WebRTC वर्तमान में अभी भी एक प्रायोगिक तकनीक है। इसका समर्थन अभी तक सभी ब्राउज़रों और उपयोगकर्ता उपकरणों में सही ढंग से लागू नहीं किया गया है, और सभी कैमरों में भी नहीं।

यह इस तथ्य की व्याख्या करता है कि हमने अभी तक सभी उपयोगकर्ताओं के लिए वेबआरटीसी प्लेयर को डिफ़ॉल्ट डिफ़ॉल्ट नहीं बनाया है।

अभी के लिए, हम केवल Google Chrome ब्राउज़र में WebRTC का उपयोग करने की सलाह देते हैं। फ़ायरफ़ॉक्स और सफारी के हाल के संस्करण भी इस तकनीक का समर्थन करते हैं, लेकिन, दुर्भाग्य से, अभी भी अस्थिर हैं।

हमने अभी तक मोबाइल उपकरणों पर ब्राउज़रों के लिए WebRTC समर्थन लागू नहीं किया है। अब, यदि आप मोबाइल डिवाइस से लॉग इन करते हैं और WebRTC को सक्रिय करते हैं, तो यह मोड काम नहीं करेगा। हालाँकि, Android और iOS के लिए WebRTC हमारे मोबाइल एप्लिकेशन में है।

और हमारी सेवा में वेबआरटीसी कार्यान्वयन की सुविधाओं के बारे में कहानी का समापन करते हुए, हम दो और सूक्ष्म बिंदुओं पर ध्यान देते हैं।

सबसे पहले, प्रौद्योगिकी वास्तविक समय में लाइव वीडियो प्रसारित करने पर केंद्रित है। इसलिए, यदि आपके चैनल की बैंडविड्थ वीडियो प्रसारण के लिए पर्याप्त नहीं है, तो आप फ़्रेम में एक गिरावट (एचएलएस के साथ, आप वीडियो लुप्त होती और बढ़ी हुई देरी को नोटिस करेंगे, जबकि फ़्रेम बाहर नहीं जाएंगे), लेकिन वीडियो अभी भी वास्तविक समय में प्रसारित किया जाएगा।

दूसरे, चूंकि तकनीक को वास्तविक समय में लाइव वीडियो के साथ काम करने के लिए डिज़ाइन किया गया है, इसलिए हम इसका उपयोग संग्रहीत वीडियो डेटा के साथ काम करने के लिए नहीं करते हैं।

अन्य सेवा परिवर्तन

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

यहां उन परिवर्तनों का एक संक्षिप्त सारांश है जो हमारे क्लाउड-आधारित वीडियो निगरानी प्रणाली और व्यक्तिगत खाते में आपकी प्रतीक्षा कर रहे हैं। देखते रहो और देखते रहो!

वेबआरटीसी और वीडियो निगरानी: हमने कैमरों से वीडियो की देरी को कैसे हराया