पहले दर्शक की समस्या, या वेबआरटीसी वीडियो की कठिन रूपांतरण एचएलएस में बदल जाती है

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

ब्राउज़र न केवल हाइपरटेक्स्ट है, बल्कि एक स्ट्रीमर भी है

ब्राउज़रों ने लंबे समय तक खिलाड़ियों का अधिग्रहण किया है, लेकिन एक वीडियो एनकोडर और कहानी को स्ट्रीमिंग के साथ अलग है। अब नवीनतम संस्करण के लगभग किसी भी ब्राउज़र में आप एन्कोडिंग, स्ट्रीमिंग, डिकोडिंग और प्लेबैक के लिए मॉड्यूल पा सकते हैं। ये फ़ंक्शन जावास्क्रिप्ट एपीआई के माध्यम से उपलब्ध हैं, और कार्यान्वयन को वेब रियल टाइम कम्युनिकेशंस या वेबआरटीसी कहा जाता है। ब्राउज़रों में निर्मित यह लाइब्रेरी काफी कुछ कर सकती है: एक अंतर्निहित, आभासी या यूएसबी कैमरा से वीडियो कैप्चर करें, H.264, VP8, VP9 कोडक के साथ संपीड़ित करें, इसे SRTP प्रोटोकॉल के माध्यम से नेटवर्क पर भेजें, अर्थात। एक सॉफ्टवेयर वीडियो स्ट्रीमर एनकोडर के रूप में कार्य करता है। नतीजतन, हम एक ब्राउज़र देखते हैं जिसमें हुड के नीचे ffmpeg या gstreamer के समान है, जो वीडियो को अच्छी तरह से संपीड़ित करता है, आरटीपी पर स्ट्रीम करता है और वीडियो स्ट्रीम निभाता है।

WebRTC आपको जावास्क्रिप्ट में विभिन्न प्रकार के स्ट्रीमिंग मामलों को लागू करने की स्वतंत्रता देता है:

• रिकॉर्डिंग और बाद में वितरण के लिए ब्राउज़र से सर्वर तक स्ट्रीम स्ट्रीम करें
• सहकर्मी से सहकर्मी की धाराओं वितरित करने के लिए
• किसी अन्य उपयोगकर्ता की स्ट्रीम खेलें और अपना स्वयं का वीडियो भेजें (वीडियो चैट)
• सर्वर द्वारा अन्य प्रोटोकॉल परिवर्तित करें, उदाहरण के लिए RTMP, RTSP, आदि, और WebRTC के रूप में ब्राउज़र में खेलते हैं

परिष्कृत प्रवाह नियंत्रण स्क्रिप्ट इस तरह दिख सकती है:

//      session.createStream({name:”mystream”}).publish(); //   session.createStream({name:”mystream”}).play(); 

एचएलएस काम करता है जहां वेबआरटीसी काम नहीं करता है

WebRTC ब्राउज़रों के नवीनतम संस्करणों में काम करता है, हालाँकि, इसके दो निम्न कारक हैं: 1) सभी उपयोगकर्ता ब्राउज़र को समय पर अपडेट नहीं करते हैं और तीन साल तक किसी भी तरह के क्रोम पर बैठ सकते हैं। 2) सप्ताह में लगभग एक बार अपडेट जारी किया जाता है और नए ब्राउज़र, वेबव्यू, साथ ही अन्य ग्राहक और तत्काल संदेशवाहक जो इंटरनेट पर सर्फ कर सकते हैं। कहने की जरूरत नहीं है, उनमें से सभी को WebRTC का समर्थन नहीं है, और यदि ऐसा है, तो यह काफी कम हो सकता है। देखिए अब कैसे हैं हालात:

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

प्रारंभ में, एचएलएस की कल्पना वास्तविक समय की धाराओं के लिए नहीं की गई थी। वास्तव में, HTTP पर वीडियो का समय क्या हो सकता है? HLS का कार्य वीडियो को टुकड़ों में काटना और एक-एक करके डाउनलोड करके, बिना रुके, खिलाड़ी को सुचारू रूप से वितरित करना है। एचएलएस खिलाड़ी एक कड़ाई से गठित और चिकनी वीडियो स्ट्रीम की उम्मीद करता है। और यहाँ एक संघर्ष उत्पन्न होता है, क्योंकि इसके विपरीत, WebRTC, वास्तविक समय की आवश्यकताओं और कम विलंब के कारण खुद को पैकेट खोने की अनुमति दे सकता है और एक अस्थायी FPS / GOP और एक चर बिट दर - स्ट्रीम की भविष्यवाणी और गतिशीलता के संदर्भ में HLS के बिल्कुल विपरीत हो सकता है।

एक स्पष्ट दृष्टिकोण - वेबआरटीसी डेकैकेटाइजेशन (एसआरटीपी) और एचएलएस के बाद के रूपांतरण , देशी एप्पल एचएलएस खिलाड़ी में काम नहीं कर सकते हैं या फ्रिज़ के साथ उत्पादन के लिए अनुपयुक्त रूप में काम कर सकते हैं। यहां के मूल खिलाड़ी का मतलब एक ऐसा खिलाड़ी है जो Apple iOS Safari, Mac OS Safari, Apple TV में उपयोग किया जाता है।

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

देशी खिलाड़ियों में फ्रिज़ के खिलाफ लड़ाई

इस प्रकार, एचएलएस में प्रत्यक्ष और ईमानदार वेबआरटीसी डेकैकेटाइजेशन और पैकेटाइजेशन आमतौर पर काम नहीं करता है। वेब कॉल सर्वर (WCS) स्ट्रीमिंग वीडियो सर्वर में, हम समस्या को दो तरीकों से हल करते हैं, और हम तीसरे को विकल्प के रूप में पेश करते हैं:

1) ट्रांसकोडिंग।

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

2) एचएलएस की आवश्यकताओं के तहत मक्खी पर वेबआरटीसी प्रवाह का अनुकूलन और संरेखण।

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

3) WebRTC के बजाय धारा स्रोत के रूप में RTMP का उपयोग करें।

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

ऊपर वर्णित सभी तीन विधियों का परीक्षण और काम किया जाता है, इसलिए कार्य की शर्तों के आधार पर चुनने का अवसर है।

सीडीआर पर एचएलएस को वेबआरटीसी

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

समस्या पहले से ही थोड़ी अधिक पहचानी गई है, और यह समस्या आमतौर पर देशी खिलाड़ियों में उत्पन्न होती है: आईओएस सफारी, मैक ओएस सफारी, एप्पल टीवी। देशी से हमारा मतलब है कि एक खिलाड़ी जो टैग में प्लेलिस्ट के url के प्रत्यक्ष संकेत के साथ काम करता है, उदाहरण के लिए, <video src="https://host/test.m3u8"/> । जैसे ही खिलाड़ी ने एक प्लेलिस्ट का अनुरोध किया, और यह क्रिया वास्तव में एचएलएस स्ट्रीम खेलने में पहला कदम है, सर्वर को तुरंत, बिना किसी देरी के, एचएलएस वीडियो सेगमेंट बाहर भेजना शुरू करना चाहिए। यदि सर्वर तुरंत सेगमेंट देना शुरू नहीं करता है, तो खिलाड़ी तय करता है कि उसे धोखा दिया गया और उसने खेलना बंद कर दिया। फिर से, यह व्यवहार Apple के मूल HLS खिलाड़ियों के लिए विशिष्ट है, लेकिन हम उपयोगकर्ताओं को यह नहीं बता सकते - "कृपया iPhone Mac और Apple TV का उपयोग HLS स्ट्रीम चलाने के लिए न करें", उपयोगकर्ता समझ नहीं पाएंगे।

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

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

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

लेकिन अंत तक नहीं

ऐसा लगता है कि सब कुछ महान काम करता है। CDN कार्य कर रहा है, HLS स्ट्रीम एज एज सर्वर से ली गई हैं और पहले कनेक्ट करने की समस्या हल हो गई है। और यहां एक और नुकसान है - हम प्रीलोडर को 16: 9 के निश्चित पहलू अनुपात में देते हैं, और सीडीएन में किसी भी प्रारूप की धाराएं शामिल हो सकती हैं: 16: 9, 4: 3, 2: 1 (वीआर वीडियो)। और यह एक समस्या है, क्योंकि यदि आप खिलाड़ी को 16: 9 प्रारूप में प्रीलोडर देते हैं, और ऑर्डर की गई धारा 4: 3 प्रारूप में होगी, तो देशी खिलाड़ी फिर से फ्रेज का इंतजार करता है।

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

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

परिणाम

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

संदर्भ

वेब कॉल सर्वर - वेबआरटीसी सर्वर

कम विलंबता WebRTC स्ट्रीमिंग सीडीएन - डब्ल्यूसीएस आधारित सीडीएन

HLR पर WebRTC और RTMP वीडियो स्ट्रीम चलाएं - स्ट्रीम को विभिन्न स्रोतों से HLS में परिवर्तित करने के लिए सर्वर कार्य करता है