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

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

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

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

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

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

(c)

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

HLS इंजन वीडियो डेटा स्ट्रीम करने के लिए AAC या MP264 ऑडियो स्ट्रीम के संयोजन में प्रसिद्ध H3 वीडियो कोडेक का उपयोग करता है। संपूर्ण ऑडियो और वीडियो डेटा स्ट्रीम को MPEG-TS ट्रांसपोर्ट कंटेनर में पैक किया गया है। HTTP प्रोटोकॉल के माध्यम से प्रसारण के लिए, स्ट्रीम में मौजूद जानकारी को m3u8 प्लेलिस्ट में वर्णित टुकड़ों में विभाजित किया गया है। और तभी ये टुकड़े, प्लेलिस्ट के साथ, HTTP के माध्यम से प्रसारित होते हैं। चंकिंग का मतलब स्वचालित रूप से सेकंड में देरी है। यह MPEG-TS कंटेनर की एक विशेषता है.

एचएलएस इंजन मल्टीबिट्रेट स्ट्रीम, लाइव/वीओडी का भी समर्थन करता है।

एचएलएस के मुख्य लाभ:

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

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

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

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

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

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

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

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

बढ़िया कटौती

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

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

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

एचएलएस के लाभ:

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

नुकसान:

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

एचएलएस के नुकसान हमारे लिए इसके फायदों से अधिक थे और हमें वैकल्पिक विकल्पों की तलाश करने के लिए मजबूर किया।

वेबआरटीसी क्या है

(c)

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

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

इस तकनीक की सुविधा और व्यापक क्षमताओं की सराहना सभी लोकप्रिय ब्राउज़रों के डेवलपर्स ने की है। WebRTC सपोर्ट वर्तमान में Mozilla Firefox, Opera, Google Chrome (और सभी Chromium-आधारित ब्राउज़रों) के साथ-साथ मोबाइल ऐप्स में भी उपलब्ध है। Android और आईओएस।

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

चयन की कठिनाई

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

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

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

यह ध्यान में रखते हुए कि अन्य एंटी-लैग कार्यान्वयनों की कार्यक्षमता अभी भी सीमित है और वे काफी खराब काम करते हैं, हमने WebRTC का उपयोग करने का निर्णय लिया।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

स्रोत: www.habr.com