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

वीडियो कॉल सेवा के लिए एक नई चुनौती एक पूरे परिवार या दुनिया के विभिन्न हिस्सों में स्थित दोस्तों के समूह या एक ही प्रोजेक्ट पर दूरस्थ रूप से काम करने वाले सहयोगियों को योजना बनाने के लिए इकट्ठा करना है।

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


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

लेख की रूपरेखा:

• इतिहास और डिवाइस कॉल।
• समूह कॉल पर एक-से-एक कॉल से संक्रमण।
• DIY समूह कॉल सेवा।
• कॉन्फ्रेंसिंग सर्वर: प्रतियोगियों का अन्वेषण करें और बेहतर करें।

इतिहास को बुलाओ

कॉल के लिए पहला प्रसिद्ध एप्लिकेशन, और वीडियो के साथ, Skype था, यह 2006 में दिखाई दिया। Odnoklassniki में, हमने 2010-2012 में एडोब से एक समाधान के आधार पर कॉल लॉन्च किया ... कुछ साल पहले हमने इसे वेबआरटीसी (इस लॉन्च के बारे में और अधिक) पर पूरी तरह से रीडिड किया था, पिछले साल हमने समूह कॉल जोड़े थे। इस संक्रमण पर लेख में चर्चा की जाएगी।

मुझे क्यों लगता है कि मैं आपको बता सकता हूं कि यह कैसे करना है? क्योंकि कॉल का उपयोग करने वाले हमारे मासिक दर्शक 10 मिलियन से अधिक हैं, और हमारे पास प्रति दिन 2 मिलियन से अधिक कॉल हैं । इसके अलावा, उनमें से आधे से अधिक मोबाइल प्लेटफार्मों के माध्यम से होते हैं।

समूह कॉल सबसे तेजी से बढ़ने वाली सेवा है, और हमारा लक्ष्य 100 एक साथ सम्मेलन प्रतिभागियों है। इतना क्यों? सबसे पहले, कभी-कभी आप अपने दोस्तों और सहपाठियों के साथ एक सुंदर शॉट साझा करना चाहते हैं या एक संगोष्ठी आयोजित करते हैं। दूसरे, भले ही आपको लगता है कि आपकी सेवा को किसी चीज़ की ज़रूरत नहीं है, सब कुछ बदल सकता है।

अब ऐसा लग सकता है कि 100 प्रतिभागियों के लिए वीडियो कॉन्फ्रेंस की जरूरत नहीं है, और पांच साल पहले उन्होंने मुझसे पूछा था कि हम 4K में वीडियो लॉन्च क्यों कर रहे हैं। अब एक 4K टीवी आम है, और हम 2014 में वापस तैयार थे।

बात समय से आगे की नहीं है। यदि आप एक अच्छी सेवा बनाना चाहते हैं, तो अपनी आवश्यकताओं को बढ़ाएँ।

यदि आप 50-100 लोगों के लिए अच्छी तरह से काम कर सकते हैं, तो 6-10 उपयोगकर्ताओं के लिए सब कुछ ठीक काम करेगा।

प्रत्येक कॉल सेवा में 4 अपेक्षाकृत स्वतंत्र घटक होते हैं:

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

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

इससे पहले कि आप सेवा पर काम करना शुरू करें, आपको आवश्यकताओं की पहचान करने की आवश्यकता है :

• जल्दी से एक कनेक्शन स्थापित करें ताकि कनेक्शन फोन के तुरंत बाद स्थापित हो जाए।
• उच्च कॉल गुणवत्ता ताकि वीडियो उखड़ न जाए और फ्रीज न हो।
• कॉल में प्रतिभागियों की संख्या , ताकि आप चैट में कॉल कर सकें, जिसमें 100 प्रतिभागियों तक।
• कॉल करने वालों के बीच कम विलंबता। Polycom के रूप में 1.3 s की लेटेंसी हमें शोभा नहीं देती है।

यहां विशिष्ट अर्थ दिए गए हैं जिनमें समूह कॉल के लिए ये आवश्यकताएं व्यक्त की गई हैं: कॉल की शुरुआत 1 सेकंड से अधिक नहीं; एक नेटवर्क जिसमें 300 केबीपीएस वीडियो काफी काम करता है; कॉल करने वाले से सुनने वाले के लिए विलंबता 0.5 सेकंड से अधिक नहीं; एक कॉल में 100 उपयोगकर्ता।

रास्ते में क्या है?

जैसा कि आप जानते हैं, नेटवर्क में डेटा पैकेट में प्रेषित होता है: एक सॉकेट होता है, आप वहां डेटा स्ट्रीम भेजते हैं, सब कुछ उड़ जाता है, जैसे कि एक ब्लैक बॉक्स में, यह इकट्ठा होता है और काम करता है।

लेकिन नेटवर्क अलग हैं। कॉल के आधे मोबाइल नेटवर्क के माध्यम से किए जाते हैं, और वे हमेशा फ्रीवे की तरह नहीं दिखते हैं।

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

नेटवर्क सुविधाएँ

हम मुख्य विशेषताओं का विश्लेषण करेंगे जो नेटवर्क की गुणवत्ता का वर्णन करते हैं।

RTT

राउंड-ट्रिप का समय - सर्वर को क्लाइंट को डेटा भेजने और पावती प्राप्त करने के बीच का समय।

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

एक उदाहरण:

$ ping google.com 64 bytes from 173.194.73.139: icmp_seq=5 ttl=44 time=211.847 ms round-trip min/avg/max/stddev = 209.471/220.238/266.304/19.062 ms RTT = 220ms $ curl -o /dev/null -w "HTTP time taken: %{time_connect}\nHTTPS time taken: %{time_appconnect}\n" -s https://www.google.com HTTP time taken: 0.231 HTTPS time taken: 0.797 HTTP = 230ms HTTPS = 800ms 

RTT = 220ms के साथ, https के माध्यम से प्रतिक्रिया प्राप्त करने में 800 ms तक लगते हैं। इसलिए, यदि आपके पास एक वेब सॉकेट सुरक्षित कनेक्शन है, तो इस तरह के एक पिंग के साथ पूरा दूसरा चला जाएगा।

तालिका मोबाइल नेटवर्क में मापी गई हैंडशेक देरी को दर्शाती है ( इस रिपोर्ट में, मोबाइल नेटवर्क में अनुप्रयोगों के संचालन के बारे में अधिक विवरण)।

क्षमता

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

समस्या यह है कि मोबाइल नेटवर्क में बैंडविड्थ लगातार बदल रहा है । यदि यह तेजी से गिर गया, और डेटा एक ही बिटरेट के साथ प्रेषित होता है, तो वे स्पष्ट रूप से नुकसान से गुजरेंगे, और उपयोगकर्ता की कॉल "हैंग" होगी। इसके लिए संघर्ष भी करना होगा।

पैकेट का नुकसान

डेटा स्थानांतरित करते समय, पैकेट खो सकता है। इस मामले में, एक विकल्प है: या तो पैकेट का हिस्सा छोड़ दें और विकृतियां प्राप्त करें, या पैकेट को फिर से जमा करने की कोशिश करें और एक फ्रीज फ्रेम प्राप्त करें।

घबराना

तथ्य यह है कि पैकेट एक बार में समान रूप से नहीं आते हैं, लेकिन कुछ अंतराल पर बंडल पैकेट में होते हैं।


घबराना मापने के लिए आसान है:

 PING highload.ru (178.248.233.16): 56 data bytes icmp_seq=11 ttl=43 time=117.177 ms icmp_seq=12 ttl=43 time=132.868 ms icmp_seq=13 ttl=43 time=176.413 ms icmp_seq=14 ttl=43 time=225.981 ms 

पिंगानुली हाईलोडोव। कई बार (पिंग एक अस्थिर मूल्य है, यह औसत करना आवश्यक है), हमें औसत घबराना मिला: ((132-117)+(176-132)+(225-176)) / 3 = (14 + 44 + 79) / 3 = 46 ।

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

अर्थात्, वायरलेस नेटवर्क को चिह्नित करने के लिए, निम्न मूल्यों को जानना पर्याप्त है: आरटीटी (गोल-यात्रा समय); बैंडविड्थ BW (बैंडविड्थ); पैकेट हानि प्रतिशत; घबराना।

उपयोगकर्ता कैसा दिखता है?

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

80% मामलों में, अंतिम उपयोगकर्ता एक वायरलेस कनेक्शन का उपयोग करता है: यह या तो एक मोबाइल नेटवर्क या वाई-फाई है।



रूस में, पश्चिमी क्षेत्र और बड़े शहरों के बाहर, औसत नेटवर्क विशेषताएँ हैं: आरटीटी - 200 एमएस, बैंडविड्थ - 1.1 एमबीपीएस, पैकेट नुकसान - 0.6%, घबराना - 5ms।

हमने इन मूल्यों को नेटवर्क के प्रकारों से विभाजित किया और महसूस किया कि इस पर काम करना सीखना आवश्यक है।

विकास सुविधाओं को बुलाओ

बहुत से लोग भूल जाते हैं, लेकिन एलटीई और 3 जी असममित संचार चैनल हैं: डाउनलिंक हमेशा अपलिंक से अधिक होता है। प्रोटोकॉल के प्रकार के आधार पर, यह अनुपात 15/85 से 30/70 तक भिन्न हो सकता है। कॉल डिजाइन करते समय, यह महत्वपूर्ण है।

कैसे जांचें कि आपके ग्राहकों के पास कौन सा चैनल है?



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



नीचे पंक्ति: वायरलेस नेटवर्क लोकप्रिय और अस्थिर हैं।

• 80% से अधिक ग्राहक वायरलेस इंटरनेट का उपयोग करते हैं।
• वायरलेस सेटिंग्स गतिशील रूप से बदल रही हैं।
• वायरलेस नेटवर्क में पैकेट के नुकसान, घबराना, पुन: व्यवस्थित होने की उच्च दर होती है।
• 30/70 के अनुपात में असममित अपलिंक / डाउनलिंक चैनल।

कॉल

ज्ञान के इस भंडार के साथ, चलो समूह कॉल के कार्यान्वयन पर लौटते हैं। एक साधारण समूह कॉल के लिए एक एल्गोरिथ्म पर विचार करें, जिसे हम फिर परिष्कृत करते हैं।

चरण 1. ऐलिस बोरिस को कॉल करना चाहता है और उसे एक प्रस्ताव भेजता है, जिसमें वह वह सब कुछ रिपोर्ट करता है जो वह कर सकता है, जो प्रोटोकॉल, सेटिंग्स आदि का समर्थन करता है।

चरण 2. बोरिस ने ऐलिस को जवाब दिया, जिसके बाद एक परिवहन कनेक्शन स्थापित किया गया।

चरण 3. उसके बाद, ऑडियो / वीडियो डेटा का आदान-प्रदान शुरू होता है।

किसी भी कॉल की वास्तुकला नीचे दिए गए आरेख की तरह दिखती है।

हमेशा एक साझा सर्वर होता है, लेकिन जब कनेक्शन स्थापित हो जाता है, तो उपयोगकर्ता पहले ही पी 2 पी डेटा या तीसरे पक्ष के सर्वर के माध्यम से स्थानांतरित कर सकते हैं।

डेटा को एक कैमरे द्वारा कैप्चर किया जाता है जो इसे डिवाइस पर एनकोड करता है और इसे सॉकेट कनेक्शन पर भेजता है। वे नेटवर्क से गुजरते हैं, दूसरी तरफ कोडेक द्वारा खेले जाते हैं, और स्क्रीन पर प्रदर्शित होते हैं।

एल्गोरिथ्म के सभी चरणों पर विस्तार से विचार करें और 1-ऑन -1 कॉल से समूह कॉल पर स्विच करने का प्रयास करें।

सिग्नलिंग

कार्य: एक कॉल की रिपोर्ट करें और डेटा कनेक्शन स्थापित करें।

सब कुछ काफी सरल है:

• ऐलिस कॉल, एक अधिसूचना मोबाइल डिवाइस या ब्राउज़र पर बोरिस को भेजी जाती है।
• एक वेब सॉकेट या कोई अन्य कनेक्शन स्थापित है।
• इसके बाद, बातचीत होती है - एलिस और बोरिस सहमत हैं।
• जब हैंडसेट को एक डिवाइस पर उठाया जाता है, तो कॉल दूसरे पर स्वतः समाप्त हो जाती है।

Odnoklassniki में कॉल प्लेटफ़ॉर्म विभिन्न ग्राहकों और परिवहन का समर्थन करता है। वे सभी किसी प्रकार के सर्वर के करीब हैं, जो कॉल को कॉल करने और संदेशों को अग्रेषित करने में लगा हुआ है।

सर्वर क्रैश या अपडेट की स्थापना के मामले में, एक निरंतर भंडारण होता है जिसमें सभी संदेश रिकॉर्ड किए जाते हैं। सर्वर की हानि के मामले में, आप आसानी से एक दूसरे पर स्विच कर सकते हैं। यह है कि चिड़ियाघरकीपर क्या करता है।

एकमात्र कठिनाई बिल्कुल एक बार है । हम दो बार कुछ संदेश लागू नहीं करना चाहते हैं। यह समस्या बस हल हो गई है: सभी संदेशों में एक सीरियल नंबर है - दो बार एक भी संदेश नहीं आएगा।

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

समूह को पी 2 पी सिग्नलिंग आसानी से समाप्त हो गया है।

वही प्रस्ताव और उत्तर एलिस अब न केवल बोरिस को भेजती है, बल्कि डिमा को भी भेजती है। वे उन्हें प्राप्त करते हैं, सहमत होते हैं, उनके बीच डेटा विनिमय चैनल दिखाई देते हैं।

ऑडियो / वीडियो

एक समूह कॉल के साथ सामना करने और यह समझने के लिए कि प्रौद्योगिकियों की क्या आवश्यकता है, हमें थोड़ी बात करनी होगी कि वीडियो क्या है।

वीडियो 24 या 60 फ्रेम प्रति सेकंड है। उन्हें संपीड़ित करने के लिए, कोडेक्स का उपयोग किया जाता है। कोडेक्स का मुख्य सार यह है कि हर कुछ फ्रेम में एक संदर्भ फ्रेम (जैसे जेपीईजी) होता है, और मध्यवर्ती फ्रेम परिवर्तन के माध्यम से निर्धारित किए जाते हैं।

ऊपर की तस्वीर में, मशीन के साथ पहला फ्रेम संदर्भ एक है, और अगले फ्रेम में, केवल परिवर्तन (मशीन का आंदोलन) एन्कोड किया गया है, और अगली बार भी केवल परिवर्तन।

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

कॉल के लिए उपयोग किए जाने वाले सबसे लोकप्रिय कोडेक्स H.264 और VP8 हैं । H.264 अच्छा है क्योंकि यह हर जगह कड़ी मेहनत करता है और बैटरी नहीं खाता है। लेकिन आमतौर पर फोन पर एक एनकोडर (एनकोडर) और 4 डिकोडर। बाकी सभी चीज़ों के लिए, आपको सॉफ़्टवेयर VP8 की आवश्यकता होती है, जो एक अच्छी बैटरी की खपत करता है। यह समूह कॉल के लिए H.264 के लिए प्राथमिकता को बदलने के लायक है (यह कैसे करना है पर लिंक देखें)।

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

ऑडियो कोडेक्स

ऑडियो के लिए विभिन्न विरासत कोडेक्स हैं, जैसे कि G711। ओपस कोडेक बहुत लोकप्रिय है - यह कम बिट्रेट और उच्च दोनों पर एन्कोडिंग समस्या को हल करता है, क्योंकि इसके अंदर स्काइप से एसआईएलके और संगीत के लिए सीईएलटी कोडेक शामिल हैं।

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

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

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

मीडिया पैथोलॉजी डेटा

यह समझने के लिए कि टोपोलॉजी कैसे काम करती है, उनके पास क्या विशेषताएं हैं, आपको यह समझने की आवश्यकता है कि एक वीडियो कोडेक कैसे नुकसान से बचाता है।

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

जाहिर है, संदर्भ फ्रेम बनाना अक्सर महंगा होता है क्योंकि बिटरेट बढ़ रहा है। इसलिए, लगभग सभी कॉल सेवाएं किसी भी तरह से नुकसान के मामले में एक संदर्भ फ्रेम का अनुरोध करने की क्षमता का समर्थन करती हैं। WebRTC में, इसे पूर्ण INTRA-फ़्रेम कहा जाता है।

सबसे सरल टोपोलॉजी आपके सभी वीडियो को अन्य सभी कॉन्फ्रेंस प्रतिभागियों को भेजना है।

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

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

न्यूनतम देरी के साथ वीडियो और ऑडियो परिवहन या वितरित करें

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

यदि पैकेट में एक पैकेट गायब है, तो आप वीडियो पर 24 फ़्रेमों में से एक को स्वतंत्र रूप से छोड़ सकते हैं, लेकिन टीसीपी आपको तब तक प्राप्त करने की अनुमति नहीं देगा, जब तक आप खोए हुए को नहीं भेजते। टीसीपी पर वीडियो डिलीवर करना बेहद अक्षम है। ऐसे कार्यों के लिए UDP की अनुशंसा की जाती है, और सभी कॉल सेवाएँ इसका उपयोग करती हैं।

यह लेख दोनों प्रोटोकॉल की सभी विशेषताएं प्रदान करता है और बताता है कि सभी स्ट्रीमिंग यूडीपी पर क्यों काम करती हैं। आज के विषय के हिस्से के रूप में, यह जानना हमारे लिए पर्याप्त है कि यूडीपी हर जगह उपलब्ध नहीं है, यह 3% नेटवर्क में काम नहीं करता है।

सामान्य तौर पर, उपयोगकर्ता अपने बीच पी 2 पी कनेक्शन स्थापित कर सकते हैं।

यह सबसे अधिक लाभदायक है, क्योंकि अगर हम नोवोसिबिर्स्क में एक-दूसरे को बुलाते हैं, तो सीधे संवाद करना बेहतर है और अतिरिक्त सर्वर का उपयोग नहीं करना है जो लाभ प्रदान करेगा।

लेकिन NAT मौजूद है, और 97% से अधिक उपयोगकर्ता अब इसके पीछे स्थित हैं - कुछ के पास बाहरी IP हैं। एक तरफ, यह समस्या जल्द या बाद में आईपीवी 6 द्वारा हल की जाएगी। वैसे, रूस में, एमटीएस इसे लॉन्च करने वाला पहला था। अब वे पूरी तरह से आईपीवी 6 का समर्थन करते हैं, और उनके सभी ग्राहकों के पास सफेद आईपी हैं।

NAT के माध्यम से टूट सकता है, के माध्यम से नहीं टूट सकता है, और फिर आपको सर्वर के माध्यम से फ़ॉलबैक का उपयोग करना होगा। NAT के माध्यम से कैसे टूटना है, इस पर एक लेख भी है।

परिवहन और फ्रेम के बीच घबराना बफर

हम आगे बढ़ते हैं। अब हमें घबराहट के प्रभाव को समतल करने के लिए जिटर बफर की आवश्यकता है

हम लगातार कुछ देरी के साथ फ़्रेम दिखाना शुरू करते हैं और इस बीच हम बफर में एक ही अंतराल पर फ़्रेम को लाइन करते हैं।

बफर गतिशील रूप से बढ़ता है।

यदि फ्रेम खो गया है, और तस्वीर जमी हुई है, तो बफर बढ़ जाता है, और फिर हम पहले से ही इस आकार के बफर के साथ काम कर रहे हैं।

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

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

साँस छोड़ते - सिद्धांत खत्म हो गया है!

ठीक है

समूह कॉल से पहले, हमारे पास पी 2 पी कॉल थे, वेबआरटीसी पुस्तकालय का उपयोग किया गया था, वेब और मोबाइल क्लाइंट एकत्र किए गए थे, सिग्नलिंग लिखा गया था।

प्रतियोगी विश्लेषण

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

सबसे दिलचस्प बात देरी का निर्धारण करना है। हम इसे इस तरह से करते हैं: टाइमर चालू करें, वीडियो शूट करना शुरू करें, कॉल करें।

100 एमएस - कैमरा देरी से वीडियो के लेंस से टकराता है, इससे पहले कि यह फोन के मैट्रिक्स पर खींचा गया हो। उसके बाद, वीडियो नेटवर्क पर भेजा जाता है, और हमें कॉल में पहले से ही 310 एमएस की देरी दिखाई देती है।

डिवाइस पर सीपीयू उपयोग को मापने के लिए मत भूलना। IOS 12 के साथ शुरू करना, यह व्यवस्थित रूप से करना संभव हो गया, लेकिन हम पुराने तरीके से पाइरोमीटर का उपयोग करते हैं।

निम्नलिखित परिणाम मिले:

व्हाट्सएप और आईसीक्यू में अधिकतम 4 कॉल प्रतिभागी हैं, स्काइप में 25 (स्काइप फॉर बिजनेस 250) और हैंगआउट और जूम में से प्रत्येक में 100 प्रतिभागी हैं। Hangouts में लगभग 35 सदस्य होते थे, और अब वह 100+ सेक्शन में कूद गया।

ज़ूम में थोड़ी देर की देरी होती है, लेकिन Hangouts में बैटरी की अधिक खपत होती है। यह मुझे प्रतीत हुआ कि ज़ूम में बेहतर गुणवत्ता है, लेकिन ऐसे लेख हैं जो विपरीत कहते हैं - यह एक व्यक्तिपरक मीट्रिक है।

कुछ सेवाएं खुले WebRTC का उपयोग करती हैं, अन्य मालिकाना प्रोटोकॉल का उपयोग करती हैं। लेकिन यह स्पष्ट है कि आप नीचे किस तरह के परिवहन का उपयोग करते हैं, कॉल में प्रतिभागियों की संख्या को प्रभावित नहीं करता है। 100 कॉल के साथ और अपने स्वयं के प्रोटोकॉल (ज़ूम) के साथ, और WebRTC (हैंगआउट) के साथ समाधान हैं।

2 से एन तक स्केल

एक दिलचस्प मामले पर विचार करें: एक असममित चैनल के साथ एक ग्राहक है, इनपुट 3 Mbit / s, आउटपुट 1.5 Mbit / s, पैकेट हानि 0.6%, घबराना 50 ms। 1.5 एमबीपीएस की बिटरेट के साथ एचडी (1280x720) में वीडियो है और 600 केबीपीएस पर 640x360 (चलो एलओडब्ल्यू कॉल करें) के संकल्प के साथ वीडियो है। हम शांत वीडियो प्रसारित करना चाहते हैं।

मामले में दो लोग पी 2 पी कहते हैं, तो सब कुछ सरल है। उनके पास पर्याप्त इनपुट नेटवर्क है, आउटपुट नेटवर्क काफी कसकर है, क्योंकि चैनल असममित है, और कोडेक्स के साथ कोई समस्या नहीं है - सभी कोड मुक्त हैं।

जब हम समूह कॉल करना शुरू करते हैं, तो हमें सभी को फिर से जोड़ने की आवश्यकता होती है। टोपोलॉजी का सबसे सरल संस्करण मेष है या "सभी के लिए।"

यह बहुत अच्छा है कि मध्यवर्ती सर्वरों की आवश्यकता नहीं है, लेकिन यह ऐसी विशेषताओं वाले ग्राहकों के लिए आपके वीडियो को सभी को देने के लिए समस्याग्रस्त हो रहा है। और यदि ग्राहक वीडियो को अकेले किसी को वितरित नहीं कर सकता है, तो आपको गुणवत्ता कम करने की आवश्यकता है, क्योंकि आम धारा सभी के लिए एन्कोडेड है।

इस मामले में, 5 प्रतिभागियों के लिए, न तो 3 और न ही 4 एमबीपीएस पर्याप्त है।

इसलिए, व्हाट्सएप में एक ग्रुप कॉल में अधिकतम 4 प्रतिभागी होते हैं, और जब तक वे मेष का उपयोग करते हैं, तब तक नहीं रहेगा।

एक अन्य विकल्प सर्वर पर पूरी तस्वीर एकत्र करना है । यह क्लाइंट के लिए सबसे अधिक लाभदायक है: इसका सर्वर से एक कनेक्शन है, सर्वर तस्वीर को इकट्ठा करता है, क्लाइंट इसे वापस प्राप्त करता है।

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

अगला टोपोलॉजी - एंड मिक्सिंग - इन देरी से बचने के लिए सर्वर पर एक सामान्य तस्वीर एकत्र नहीं करने का सुझाव देता है, लेकिन बस पैकेट फेंकता है।

यही है, इस टोपोलॉजी में सर्वर केवल एक रिले है जो डेटा स्थानांतरित करता है।

सब कुछ थोड़ा बेहतर हो रहा है: उपयोगकर्ता कॉल में अन्य सभी प्रतिभागियों की धाराओं को प्राप्त करता है और केवल एक बार अपना खुद का भेजता है। लेकिन फिर से समस्याएं हैं:

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

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

विपक्ष टोपोलॉजी:

• मेष - अधिकतम 4 सदस्य।
• केंद्रीकृत - ट्रांसकोडिंग के साथ और घबराना के साथ समस्याएं।
• अंतिम मिश्रण - गुणवत्ता सीमा और तूफान संदर्भ फ़्रेम।

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

Hangouts ने एंड मिक्सिंग के साथ चाल चली।

प्रत्येक ग्राहक पर दो एनकोडर लॉन्च किए जाते हैं: उच्च गुणवत्ता में H.264, और निम्न गुणवत्ता में VP8। तदनुसार, अच्छे इंटरनेट वाले उपयोगकर्ताओं के लिए, सर्वर उच्च-गुणवत्ता वाले वीडियो को प्रसारित करता है, जिनके पास खराब इंटरनेट है, यह बदतर है, और खराब गुणवत्ता सबसे खराब नेटवर्क के लिए अनुकूल है। दो गुण अच्छे हैं, लेकिन यह ग्राहकों और बैटरी की खपत से अतिरिक्त यातायात है। लेकिन घबराना बफर नहीं है

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

, : - , H.264, ( ) End mixing . centralized-, , , , .

, : . , , , , - . , .

.

, , , latency . , , , , . centralized, , , jitter- . , , .

«», . 100, 50, 20 . .

— , 5 . . : , , , — .

«» , , , — . : , - , fps. , — . - , . , .

Mesh 3-4 latency, , Mesh. , HD End mixing, a SD — centralized.

Zoom.

, - , Zoom , WebRTC. WebRTC , .

.

CPU , . — , , , , CPU , . , .

: , , .

screen sharing . screen sharing, , . screen sharing . , fps — , , .

. — centralized, , . , .

, , , . , , .

, , - . .

Packet pacing

-, UDP- . UDP pacing. UDP- , .

, UDP , 21 100%. — .

pacing? , ( ) — , . , , , , , , - .

:

• pacing, .
• pacing, , , , .

: , pacing , —.

packet pacing?

, ( ) , , - . ( ), , , .

— packet loss , pacing.

MTU

TCP , MTU. UDP, , MTU — , .

MTU 1500, MTU 1100, . , , , , , ( ). , MTU .

TCP , . , MTU: - , , , MTU. , MTU, , .

.

, : , , . 98% 1350. MTU = 1350 , , 2% — , .

WebRTC SACK, NACK, FEC. .

, 1–3% — , .

WebRTC negative acknowledgement (NACK).

, , - , .

, TCP acknowledgement, selective acknowledgement. negative acknowledgement , FEC (Forward Error Correction).

, SACK, NACK, FEC, .

FEC , , . : , , . , , — .

FEC — XOR, , , . , - .

, . , , , FEC-. , , , , .

, , . , :

• 90% 500 /.
• — 3-4, Mesh End mixing.
• — 27 (, ).

Check List

:

• Packet pacing.
• MTU discovery.
• .
• C .

, signalling, WebRTC, , , - .

, :

• Packet loss: , packet pacing, FEC, MTU.
• : back pressure , FEC-.
• Jitter jitter buffer, latency.
• RTT: , signaling.

WebRTC — . RTP, , , . WebRTC .

, Zoom, Skype Line, . . . , , UDP- ( , WebRTC), . , , . , Google STADIA.

STADIA — , . WebRTC, , . Google WebRTC. WebRTC SRTP WebRTC QUIC. , , .

QUIC, . Chrome c Android Google YouTube, TCP — QUIC UDP Google. 30% QUIC/UDP.

QUIC 20-30%, TCP. - QUIC , .

निष्कर्ष

, . , : signaling; / ; . , , .

?

• , - , .
• , .

/ .

, , — . , latency, . , ! - :)

HighLoad++ . ( ) , 6-7 2020 . , .