पहले दर्शक समस्या, या WebRTC वीडियो स्ट्रीम को HLS में परिवर्तित करने की कठिनाइयाँ

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

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

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

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

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

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

//Launching broadcast from browser to server session.createStream({name:”mystream”}).publish(); //Playing broadcast by the browser session.createStream({name:”mystream”}).play(); 

HLS वह कार्य करता है जहाँ WebRTC काम नहीं करता है

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

लेकिन अभी तक पूरी तरह से हल नहीं हुआ है

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

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

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

सारांश

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

लिंक

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

कम विलंबता WebRTC स्ट्रीमिंग के लिए CDN - WCS आधारित CDN

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