प्रकाशित करें और चलाएं
स्ट्रीमिंग वीडियो के क्षेत्र में सर्वर साइड पर WebRTC ऑपरेशन के दो मुख्य कार्य मौजूद हैं: प्रकाशन और खेल। प्रकाशन के मामले में, वीडियो स्ट्रीम वेब कैमरा से कैप्चर की जाती है और ब्राउज़र से सर्वर तक जाती है। खेलने के मामले में, धारा विपरीत दिशा में चलती है, सर्वर से ब्राउज़र तक, डिकोड किया जाता है और डिवाइस के स्क्रीन पर ब्राउज़र के एचटीएमएल 5 <video> तत्व में खेला जाता है।
यूडीपी और टीसीपी
वीडियो दो परिवहन प्रोटोकॉल के माध्यम से आगे बढ़ सकता है: टीसीपी या यूडीपी। यूडीपी के मामले में, एनएटी आरटीसीपी फीडबैक सक्रिय रूप से काम करता है, खोए हुए पैकेटों के बारे में जानकारी लेकर, जिसके कारण यूडीपी चैनल खराब होने का पता लगाने के लिए यह एक सरल कार्य है, यह निर्धारित करने के लिए एनएके (नेगेटिव एसीके) की गिनती करने के लिए उबला हुआ है। गुणवत्ता। जितने अधिक NACK और PLI (पिक्चर लॉस इंडिकेटर) फीडबैक होते हैं, उतने ही वास्तविक नुकसान होते हैं, और चैनल की गुणवत्ता कम होती है।
बिना NCP के टीसीपी
इस लेख में, हम टीसीपी प्रोटोकॉल पर अधिक ध्यान केंद्रित करने जा रहे हैं। जब टीसीआर पर WebRTC का उपयोग किया जाता है, तो NACK RTCP फीडबैक नहीं भेजे जाते हैं, और अगर उन्हें भेजा जाता है तो भी वे नुकसान की वास्तविक तस्वीर को नहीं दर्शाते हैं, और फीडबैक द्वारा चैनल की गुणवत्ता निर्धारित करना संभव नहीं लगता है। जैसा कि आमतौर पर ज्ञात है, टीसीपी गारंटीकृत वितरण वाला एक परिवहन प्रोटोकॉल है। इस कारण से, यदि चैनल गुणवत्ता शेष पैकेटों में खराब हो जाती है, तो नेटवर्क में हैं जो परिवहन प्रोटोकॉल के स्तर पर भेजे जाएंगे। जितनी जल्दी या बाद में उन्हें वितरित किया जाएगा, लेकिन उन नुकसानों के लिए एक एनएकेई उत्पन्न नहीं किया जाएगा क्योंकि वास्तव में कोई नुकसान नहीं हुआ था। नतीजतन, पैकेट देरी से अपने गंतव्य तक पहुंचेंगे। देरी से पैकेट केवल वीडियो फ्रेम में इकट्ठा नहीं होगा और डिपेक्टाइज़र द्वारा खारिज कर दिया जाएगा, जिसके परिणामस्वरूप उपयोगकर्ता इस तरह की तस्वीर देखेंगे, कलाकृतियों से भरा:
फीडबैक दिखाएगा कि सब कुछ ठीक है, लेकिन तस्वीर में कलाकृतियां होंगी। नीचे आप Wireshark ट्रैफ़िक के स्क्रीनशॉट देख सकते हैं जो संपीड़ित टीसीपी और यूडीपी चैनलों पर प्रकाशित धारा के व्यवहार के साथ-साथ Google Chrome आँकड़ों के स्क्रीनशॉट भी हैं। स्क्रीनशॉट में आप देख सकते हैं कि टीसीपी के मामले में, एनएके मीट्रिक यूडीपी के विपरीत नहीं बढ़ता है, भले ही चैनल की स्थिति बहुत खराब हो।
टीसीपी
यूडीपी
अगर यूडीपी है तो टीसीपी पर स्ट्रीम क्यों करें
यह एक उचित प्रश्न है। जवाब है, चैनल के माध्यम से बड़े प्रस्तावों को आगे बढ़ाने के लिए। उदाहरण के लिए, वीआर (वर्चुअल रियलिटी) के मामले में रिज़ॉल्यूशन स्ट्रीमिंग 4k से शुरू हो सकती है। इस तरह के एक संकल्प के साथ एक धारा को धक्का देना संभव नहीं है और लगभग 10 एमबीपीएस की एक बिटरेट के साथ एक नियमित चैनल में नुकसान के बिना, सर्वर यूडीपी पैकेट बाहर थूकता है और वे नेटवर्क में गुच्छों में खोना शुरू करते हैं, फिर शेष उनमें से भेजा जाना शुरू हो जाता है, और इसी तरह। बड़ी मात्रा में त्याग किए गए वीडियो पैकेट वीडियो को भ्रष्ट करते हैं, और शुद्ध परिणाम यह है कि गुणवत्ता बहुत खराब हो जाती है। यही कारण है कि टीसीपी पर वेबआरटीसी का उपयोग सामान्य प्रयोजन के नेटवर्क में वीडियो देने और उच्च संकल्पों के साथ किया जाता है, जैसे कि पूर्ण HD और 4k, ताकि संचार विलंबता में मामूली वृद्धि की कीमत पर नेटवर्क पैकेट के नुकसान का पता लगाया जा सके।
चैनल की गुणवत्ता निर्धारित करने के लिए RTT
इसलिए, आपको यह बताने के लिए कोई मीट्रिक नहीं है कि चैनल बहुत खराब स्थिति में है। कुछ डेवलपर्स RTT मीट्रिक पर भरोसा करने की कोशिश करते हैं, लेकिन यह सभी ब्राउज़रों में काम करने में सक्षम है, और सटीक परिणाम नहीं देता है।
नीचे आप कॉलस्टैट प्रोजेक्ट के अनुसार आरटीटी पर चैनल की गुणवत्ता की निर्भरता का एक उदाहरण पा सकते हैं
REMB- आधारित समाधान
हमने इस समस्या के लिए थोड़ा अलग तरीका अपनाने का फैसला किया है। सर्वर साइड पर काम करने वाला REMB है , जो आने वाली सभी धाराओं के लिए आने वाली बिटरेट की गणना करता है, माध्य से इसके विचलन की गणना करता है, और यह बताता है कि ब्राउज़र एक महत्वपूर्ण फैलाव के मामले में बिटरेट को कम करता है, RTCP पर विशेष REMB भेज रहा है। प्रोटोकॉल। ब्राउज़र ऐसे संदेश प्राप्त करता है और अनुशंसित मानों के लिए वीडियो एनकोडर की बिटरेट को कम करता है: यह है कि चैनल अधिभार और आने वाली स्ट्रीम गिरावट के खिलाफ सुरक्षा कैसे काम करती है। इस प्रकार, सर्वर साइड पर पहले से ही बिटरेट गणना तंत्र लागू किया गया है। फैलाव का औसत और निर्धारण कलमैन फिल्टर के माध्यम से किया गया है। यह उच्च सटीकता के साथ किसी भी समय वर्तमान बिटरेट प्राप्त करने और किसी भी महत्वपूर्ण विचलन को छानने की अनुमति देता है।
पाठक के मन में यह सवाल जरूर होगा, "इससे मुझे उस बिटरेट को जानने में कैसे मदद मिलेगी कि सर्वर इसमें आने वाली स्ट्रीम के लिए देख सकता है?" यह केवल आपको यह समझने देगा कि सर्वर में विटरेट मान के साथ वीडियो आ रहा है। जिनमें से यह निर्धारित करना संभव था। चैनल की गुणवत्ता का मूल्यांकन करने के लिए, एक और घटक की आवश्यकता होगी।
आगामी बिटरेट, और यह महत्वपूर्ण क्यों है
वेबआरटीसी स्ट्रीम को प्रकाशित करने के आंकड़े यह दर्शाते हैं कि वीडियो स्ट्रीम ब्राउज़र से क्या निकलता है। एक पुराने मजाक के रूप में, एक साइट व्यवस्थापक अपनी राइफल की जाँच करते समय कहता है, '' मेरी तरफ से, गोलियां बह गई हैं। समस्याएँ आपके पक्ष में हैं ... "चैनल की गुणवत्ता की जाँच के विचार में दो बिटरेट्स की तुलना करना शामिल है: 1) ब्राउज़र द्वारा भेजी गई बिटरेट, 2) सर्वर द्वारा वास्तव में प्राप्त बिटरेट।
साइट व्यवस्थापक गोलियों को निकालता है और उनकी तरफ से बाहर निकलने की गति की गणना करता है। सर्वर उस गति को परिकलित करता है जो वे इसके पक्ष में प्राप्त करते हैं। इस घटना के एक और भागीदार, टीसीपी है, यह एक सुपर हीरो है जो व्यवस्थापक और सर्वर के बीच में स्थित है और यादृच्छिक पर गोलियों को रोक सकता है। उदाहरण के लिए, यह 2 सेकंड के लिए 100 की 10 यादृच्छिक गोलियों को रोक सकता है, और फिर उन्हें फिर से उड़ने देगा। यही मैट्रिक्स हम यहां देख रहे हैं।
ब्राउज़र की तरफ, हम WebRTC के आँकड़ों से वर्तमान बिटरेट लेते हैं, फिर जावास्क्रिप्ट कार्यान्वयन में कलमन फ़िल्टर के साथ ग्राफ़ को सुचारू करते हैं, और प्रक्रिया के अंत में क्लाइंट ब्राउज़र बिटरेट का एक सुचारू संस्करण प्राप्त करते हैं। अब हमारे पास व्यावहारिक रूप से वह सब है जिसकी हमें आवश्यकता है: क्लाइंट बिटरेट बताता है कि ट्रैफ़िक ब्राउज़र से कैसे बाहर जाता है, और सर्वर बिटरेट हमें बताता है कि सर्वर द्वारा उस ट्रैफ़िक को कैसे देखा जाता है, और किस बिटरेट के साथ इसे प्राप्त किया जाता है। यह स्पष्ट है कि यदि क्लाइंट बिटरेट उच्च रहता है और क्लाइंट बिटरेट क्लाइंट बिटरेट के संबंध में सिकुड़ने लगता है, तो इसका मतलब है कि सभी गोलियां "लक्ष्य तक" नहीं पहुंची हैं, और सर्वर वास्तव में ट्रैफ़िक का हिस्सा नहीं देख सकता है इसे भेजा गया था। इस आधार पर, हम यह निष्कर्ष निकाल सकते हैं कि चैनल के साथ कुछ गलत है और यह संकेतक रंग को लाल में बदलने का समय है।
और वहाँ अधिक है
रेखांकन सहसंबद्ध होते हैं लेकिन वे एक-दूसरे के संबंध में थोड़े समय के लिए स्थानांतरित होते हैं। पूर्ण सहसंबंध के लिए ऐतिहासिक डेटा के खिलाफ उसी समय में क्लाइंट और सर्वर बिटरेट की तुलना करने के लिए रेखांकन को समय-समय पर करना आवश्यक है। वंशानुक्रम लगभग इस तरह दिखता है:
और यह एक समय-संरेखित ग्राफ़ जैसा दिखता है।
इसका परीक्षण करते हैं
हमारे पास करने के लिए थोड़ा सा बचा है, हमें केवल इसका परीक्षण करना है। चलो एक वीडियो स्ट्रीम प्रकाशित करें, इसे खोलें, और प्रकाशित बिट्रेट्स के ग्राफ को देखें: ब्राउज़र की तरफ और सर्वर की तरफ। रेखांकन व्यावहारिक रूप से एक परिपूर्ण मैच प्रदर्शित करता है। और यह संकेतक का नाम है, PERFECT।
फिर, चलो चैनल को भ्रष्ट करना शुरू करते हैं। ऐसा करने के लिए, हम निम्न नि: शुल्क टूल का उपयोग कर सकते हैं: विंडोज़ के लिए winShaper या MacOS के लिए नेटवर्क लिंक कंडीशनर । वे प्रीसेट मान के लिए चैनल को संपीड़ित करने की अनुमति देते हैं। उदाहरण के लिए, यदि हम जानते हैं कि 640x480 की एक धारा 1 एमबीपीएस की गति तक पहुंच सकती है, तो इसे 300 केबीएस तक संपीड़ित करें। ऐसा करते समय हमें यह नहीं भूलना चाहिए कि हम टीसीपी के साथ काम कर रहे हैं। आइए हमारे परीक्षण के परिणाम की जांच करें: रेखांकन में व्युत्क्रम सहसंबंध है, और संकेतक बीएडी के लिए फिसल रहा है। दरअसल, ब्राउज़र डेटा भेजना जारी रखता है और यहां तक कि नेटवर्क में ट्रैफ़िक के एक नए हिस्से को धकेलने का प्रयास भी बिटरेट बढ़ा रहा है। यह डेटा रेट्रांसमीटर के रूप में नेटवर्क में जमा हो जाता है और सर्वर तक पहुंचने में विफल रहता है, परिणामस्वरूप सर्वर एक उलटा चित्र प्रदर्शित करता है और कहता है कि बिट्रेट यह देख सकता है कि गिरा दिया गया है। दरअसल, यह बीएडी है।
हमने काफी परीक्षण किए हैं जो संकेतक के सही संचालन को दर्शाते हैं। उसी के परिणामस्वरूप हमारे पास एक ऐसी सुविधा है, जो उपयोगकर्ता को किसी भी समस्या के बारे में सूचित करना और तुरंत सूचित करना संभव बनाती है, जिसमें चैनल के साथ स्ट्रीम प्रकाशन और प्लेइंग (समान सिद्धांत द्वारा काम करना) दोनों के लिए कोई समस्या नहीं है। हाँ, यह सब उपद्रव इस हरे और लाल दीपक के लिए था, परफेक्ट-बीएडी। लेकिन अभ्यास से पता चलता है कि यह संकेतक बहुत महत्वपूर्ण है, और इसकी अनुपस्थिति, वर्तमान स्थिति को समझने में विफलता के साथ, एक वेबआरटीसी वीडियो स्ट्रीमिंग सेवा के एक साधारण उपयोगकर्ता के लिए बड़ी समस्याएं पैदा कर सकती है।
लिंक
WCS 5.2 वेब और मोबाइल एप्लिकेशन विकास के लिए एक स्ट्रीमिंग मीडिया सर्वर है
प्रकाशक और खिलाड़ी चैनल गुणवत्ता नियंत्रण
REMB - बैंडविड्थ नियंत्रण के लिए उपयोग किए जाने वाले अधिकतम अनुमानित बिटरेट
NACK - पैकेट खो नियंत्रण और पुनः संचार के लिए उपयोग किया जाने वाला नकारात्मक अभिग्रहण