टीसीपी पर सर्वर WebRTC चैनल गुणवत्ता संकेतक

प्रकाशित करें और चलाएं

वीडियो स्ट्रीमिंग में दो मुख्य सर्वर-साइड WebRTC विशेषताएं हैं: प्रकाशन और प्लेबैक। प्रकाशन के मामले में, वीडियो स्ट्रीम वेबकैम से कैप्चर की जाती है और ब्राउज़र से सर्वर तक जाती है। प्लेबैक के मामले में, धारा विपरीत दिशा में चलती है - सर्वर से ब्राउज़र तक, डिकोड किया जाता है और डिवाइस की स्क्रीन पर एचटीएमएल 5 <video> ब्राउज़र तत्व में वापस खेला जाता है।

यूडीपी और टीसीपी

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

बिना NCP के टीसीपी

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

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

टीसीपी

यूडीपी

और UDP होने पर आपको TCP पर स्ट्रीम करने की आवश्यकता क्यों है

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

चैनल की गुणवत्ता निर्धारित करने के लिए RTT

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

नीचे कॉलस्टेट परियोजना के संस्करण के अनुसार आरटीटी पर चैनल की गुणवत्ता की निर्भरता का एक चित्रण है

REMB समाधान

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

पाठक के मन में शायद यह सवाल होगा - "बिटकॉइन का ज्ञान क्या होगा जो सर्वर आने वाली स्ट्रीम पर देखता है?" इससे सर्वर पर बिटरेट के साथ वीडियो वास्तव में क्या प्रवेश कर रहा है, इसकी समझ मिलेगी, जिसका मूल्य निर्धारित किया गया था। चैनल की गुणवत्ता का मूल्यांकन करने के लिए, एक और घटक की आवश्यकता होती है।

आउटगोइंग बिटरेट और यह महत्वपूर्ण क्यों है

वेबआरटीसी स्ट्रीम को प्रकाशित करने के आंकड़े यह दर्शाते हैं कि वीडियो स्ट्रीम क्या ब्राउज़र से बाहर निकलता है। दाढ़ी वाले मजाक के रूप में: व्यवस्थापक, मशीन की जाँच: "मेरी तरफ से गोलियां उड़ गईं। समस्याएं आपकी तरफ हैं .. ”। चैनल की गुणवत्ता की जांच करने का विचार दो बिट दरों की तुलना करना है: 1) वह बिट दर जो ब्राउज़र 2 भेजता है) वह बिट दर जो सर्वर वास्तव में प्राप्त करता है।

व्यवस्थापक गोलियां चलाता है और घर पर उनके प्रस्थान की गति की गणना करता है। सर्वर उस गति की गणना करता है जिस पर उन्हें घर पर प्राप्त किया जाता है। इस घटना में एक और भागीदार है, टीसीपी एक सुपरहीरो है जो व्यवस्थापक और सर्वर के बीच में स्थित है और गोलियों को बेतरतीब ढंग से धीमा कर सकता है। उदाहरण के लिए, यह 2 सेकंड के लिए सौ में से 10 यादृच्छिक गोलियों को तोड़ सकता है, और फिर उन्हें फिर से उड़ने की अनुमति दे सकता है। यहाँ एक ऐसी मैट्रिक्स है।

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

अधिक आने के लिए

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

और यह एक समय-सिंक्रनाइज़ चार्ट की तरह दिखता है।

परीक्षण

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

अगला, हम चैनल को खराब करना शुरू करते हैं। ऐसा करने के लिए, आप विंडोज पर ऐसे " winShaper " टूल या MacOS पर " नेटवर्क लिंक कंडीशनर " का उपयोग कर सकते हैं। वे आपको चैनल को निर्धारित मूल्य पर चुटकी लेने की अनुमति देते हैं। उदाहरण के लिए, यदि हम जानते हैं कि 640x480 की धारा 1Mbps तक बढ़ सकती है, तो इसे 300 kbs तक चुटकी में बंद कर दें। उसी समय, हमें याद है कि हम टीसीपी के साथ काम कर रहे हैं। हम परीक्षा परिणाम की जांच करते हैं - रेखांकन उलटा सहसंबंध दिखाता है और संकेतक बीएडी में गिर जाता है। दरअसल, ब्राउज़र डेटा भेजना जारी रखता है और यहां तक ​​कि बिटरेट भी बढ़ाता है, जो नेटवर्क में ट्रैफ़िक के नए हिस्से को आगे बढ़ाने की कोशिश करता है। यह डेटा रिट्रांसमिशन के रूप में नेटवर्क पर बसता है और सर्वर तक नहीं पहुंचता है, परिणामस्वरूप, सर्वर विपरीत तस्वीर दिखाता है और कहता है कि यह जो बिट्रेट देखता है वह गिर गया है। वास्तव में बुरा।

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

संदर्भ

WCS 5.2 - वेब और मोबाइल वीडियो एप्लिकेशन विकसित करने के लिए एक मीडिया सर्वर

वेबआरटीसी चैनल गुणवत्ता नियंत्रण प्रलेखन प्रकाशन और प्लेबैक के लिए

REMB - सर्वर साइड बिटरेट प्रबंधन
NACK - सर्वर की ओर से खोए हुए पैकेट पर नियंत्रण