अल्ट्रा-कम विलंबता (और WebRTC!) वाले ब्राउज़र के माध्यम से वीडियो स्ट्रीमिंग

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

नेटवर्क डेटा: अलार्म अलग से, वीडियो अलग से

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

सिग्नलिंग प्रोटोकॉल और सिग्नलिंग ट्रांसपोर्ट के बीच अंतर

सिग्नलिंग प्रोटोकॉल उस भाषा को परिभाषित करता है जिसके साथ ब्राउज़र और वीडियो ट्रांसमिशन में अन्य प्रतिभागी खोज और हैंडशेक पर सहमत होंगे। यह वीओआईपी या वेबआरटीसी में खोज के लिए एसआईपी हो सकता है, और यह हैंडशेक के लिए प्रस्ताव / उत्तर के साथ है। बहुत समय पहले, Flash ने RTMP / AMF का उपयोग किया था। और यदि वांछित है, तो वेबआरटीसी के लिए, आप एसआईपी नहीं, बल्कि असामान्य जेएसईपी का उपयोग कर सकते हैं।

एक ही स्टैक से सिग्नलिंग ट्रांसपोर्ट प्रोटोकॉल, लेकिन कम: यह है कि सिग्नलिंग प्रोटोकॉल पैकेट भौतिक रूप से कैसे प्रसारित होगा। परंपरागत रूप से, फ्लैश + एसआईपी के लिए, टीसीपी या यूडीपी का उपयोग किया जाता था, लेकिन अब वेबआरटीसी + एसआईपी बंडल में, वेबसॉकेट तेजी से पाए जाते हैं। WebSockets परिवहन प्रोटोकॉल उन ब्राउज़र में टीसीपी आला पर कब्जा कर लेता है जहां आप "शुद्ध" टीसीपी और यूडीपी सॉकेट का उपयोग नहीं कर सकते हैं।

एक पूर्ण सिग्नलिंग स्टैक अब लोकप्रिय रूप से "SIP ऑन वेब सॉकेट्स", "JSEP ऑन वेब सॉकेट्स", अप्रचलित "SIP TCP / UDP के शीर्ष पर" या प्राचीन "RTMP का हिस्सा" जैसे वाक्यांशों के साथ वर्णित है।

प्रोग्रामर एंग्लिज़्म: मीडिया कोडेक

अधिकांश वीडियो स्ट्रीमिंग प्रोटोकॉल एक या अधिक कोडेक्स से बंधे होते हैं। कैमरे से प्राप्त वीडियो को फ्रेम द्वारा संसाधित किया जाता है। और नेटवर्क समस्याएं, जैसे कि कम बैंडविड्थ, पैकेट हानि, या उनके बीच देरी, प्रत्येक फ्रेम के लिए कोडेक सेटिंग्स द्वारा हल की जाती हैं। समय में नेटवर्क की समस्याओं के बारे में जानने के लिए, हम परिवहन प्रोटोकॉल तंत्र (RTP / RTCP) और बैंडविड्थ आकलन तंत्र (REMB, परिवहन-सीसी, TIMBR) का उपयोग करते हैं। फ्लैश वीडियो के साथ मूलभूत समस्याओं में से एक यह था कि आरटीएमपी न तो कर सकता था, इसलिए चैनल बैंडविड्थ बंद होने पर वीडियो बस खेलना बंद हो गया।

एक और एंग्लिसिज्म: मीडिया स्ट्रीमिंग प्रोटोकॉल

परिवहन प्रोटोकॉल द्वारा नेटवर्क पर भेजे गए छोटे पैकेट में वीडियो स्ट्रीम को विभाजित करने का तरीका निर्धारित करता है। आमतौर पर, स्ट्रीमिंग प्रोटोकॉल अभी भी नेटवर्क समस्याओं से निपटने के लिए तंत्र प्रदान करता है: पैकेट हानि और देरी। जीटर बफर, रिट्रांसमिशन (आरटीसी), रिडंडेंसी (RED) और फॉरवर्ड एरर करेक्शन (FEC)।

मीडिया ट्रांसफर प्रोटोकॉल

कैमरे से प्राप्त वीडियो को छोटे पैकेट में विभाजित करने के बाद, उन्हें नेटवर्क पर प्रसारित किया जाना चाहिए। इसके लिए उपयोग किया जाने वाला परिवहन प्रोटोकॉल सिग्नलिंग के समान है, लेकिन चूंकि "पेलोड" पूरी तरह से अलग है, इसलिए कुछ प्रोटोकॉल दूसरों की तुलना में बेहतर हैं। उदाहरण के लिए, टीसीपी पैकेट की पुनरावृत्ति प्रदान करता है, लेकिन यह स्टैक के लिए मूल्य नहीं जोड़ता है, क्योंकि इसी तरह के तंत्र (RTX / RED / FEC) पहले से ही स्ट्रीमिंग प्रोटोकॉल में हैं। लेकिन टीसीपी को फिर से भेजने में देरी एक स्पष्ट दोष है जो यूडीपी के पास नहीं है। लेकिन यूडीपी को "टोरेंट के लिए प्रोटोकॉल" के रूप में अवरुद्ध करने की प्रथा है।

प्रोटोकॉल और नेटवर्क पोर्ट का विकल्प पहले "हार्डकॉन्डिंग" द्वारा तय किया गया था, लेकिन अब हम वेबआरटीसी में आईसीई जैसे प्रोटोकॉल का उपयोग करते हैं, जो आपको प्रत्येक विशिष्ट कनेक्शन में बंदरगाहों और परिवहन पर सहमत होने की अनुमति देता है। निकट भविष्य में, क्विक प्रोटोकॉल (यूडीपी के साथ पिछड़े संगत) का उपयोग करना संभव है, जिस पर आईईटीएफ द्वारा सक्रिय रूप से चर्चा की गई है और गति और विश्वसनीयता में टीसीपी और यूडीपी पर फायदे हैं। अंत में, हम MPEG-DASH और HLS जैसे मीडिया स्ट्रीमिंग प्रोटोकॉल का उल्लेख कर सकते हैं, जो HTTP को ट्रांसपोर्ट के रूप में उपयोग करते हैं और HTTP / 2.0 के परिचय से लाभान्वित होंगे।

मीडिया ट्रांसमिशन सुरक्षा

कुछ इंजन नेटवर्क पर ट्रांसमिशन के दौरान डेटा की सुरक्षा करते हैं: या तो मीडिया स्ट्रीम या ट्रांसपोर्ट लेयर के पैकेटों को स्वयं ही स्ट्रीम करता है। इस प्रक्रिया में एन्क्रिप्शन कुंजी का बहुत हस्तांतरण शामिल है, जिसके लिए अलग प्रोटोकॉल का उपयोग किया जाता है: WebRTC में वीओआईपी और DTLS में SDES। उत्तरार्द्ध का एक फायदा है, क्योंकि डेटा के अलावा, यह एन्क्रिप्शन कुंजी के प्रसारण की भी सुरक्षा करता है।

मुझे इस सब के बारे में क्या परेशान करता है

कुछ डेवलपर्स, जैसे कि इस लेख के लेखक, विशुद्ध रूप से WebSocket और QUIC प्रोटोकॉल उसी स्तर पर डालते हैं, जैसे WebRTC, Flash या HLS। मेरे लिए, ऐसा समूह अजीब लगता है, क्योंकि अंतिम तीन प्रोटोकॉल स्ट्रीमिंग मीडिया के बारे में एक कहानी है। WebSocket या QUIC का उपयोग करने से पहले एन्कोडिंग और पैकेटीकरण होता है। Google का संदर्भ WebRTC कार्यान्वयन (libwebrtc / chrome) और Microsoft का ORTC परिवहन प्रोटोकॉल के रूप में QUIC का उपयोग करता है।

समान रूप से आश्चर्यजनक एचटीएस और एमपीईजी-डैश जैसे HTTP- आधारित प्रोटोकॉल के लिए एक अनुकूलन के रूप में HTTP / 2.0 के उल्लेख की कमी है। और उल्लिखित CMAF HLS और MPEG-DASH के लिए फ़ाइल प्रारूप से अधिक कुछ नहीं है, लेकिन उनका प्रतिस्थापन बिल्कुल नहीं है।

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

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