👨🏽‍🔬 🖕 👦 हम अपना प्रोटोकॉल UDP के शीर्ष पर लिखते हैं 👈 ➗ 😼

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

लेकिन इस एप्लिकेशन में कई समस्याएं थीं, उदाहरण के लिए, प्रसारण में देरी, उच्च गुणवत्ता में प्रसारण देखने की अक्षमता आदि।

छह महीने बाद, 2016 की गर्मियों में, ओडनोकलास्निक ने अपना ओके लाइव स्ट्रीमिंग मोबाइल एप्लिकेशन लॉन्च किया, जिसमें उन्होंने इन समस्याओं को हल करने की कोशिश की।

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

उनकी रिपोर्ट के ट्रांसक्रिप्ट से, आप अन्य वीडियो स्ट्रीमिंग प्रोटोकॉल के बारे में जानेंगे, जो कि बारीकियों और क्या ट्रिक कभी-कभी आवश्यक हैं।

वे कहते हैं कि हमें हमेशा वास्तुकला और टीके से शुरू करना चाहिए - माना जाता है कि इसके बिना यह असंभव है! तो चलिए करते हैं।

वास्तुकला और टीके

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

अगला, हम संदर्भ की शर्तों पर आगे बढ़ते हैं। यदि आपके पास कोई ग्राहक है, तो आपके पास TK है। यदि आप एक सामाजिक नेटवर्क हैं, तो आपके पास TK नहीं है। इसे कैसे बनाया जाए?

आप निश्चित रूप से उपयोगकर्ताओं का साक्षात्कार कर सकते हैं और वे सब कुछ जान सकते हैं जो वे चाहते हैं। लेकिन यह इच्छाओं का एक पूरा गुच्छा होगा जो उन लोगों के साथ सहसंबंध नहीं रखते हैं जो वास्तव में आवश्यक हैं।

हमने इसके विपरीत जाने का फैसला किया और देखा कि उपयोगकर्ताओं को प्रसारण सेवा से क्या नहीं देखना है।

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

यह एक सामान्य स्ट्रीमिंग सेवा की तरह दिखता है। आइए देखें कि सामान्य के बजाय नियमित स्ट्रीमिंग सेवा करने के लिए क्या किया जा सकता है।

आप सभी स्ट्रीमिंग प्रोटोकॉल को देखकर शुरू कर सकते हैं, सबसे दिलचस्प का चयन करें और उनकी तुलना करें। लेकिन हमने इसे अलग तरीके से किया।

प्रतियोगियों के पास क्या है?

हमने प्रतिस्पर्धी सेवाओं की खोज करके शुरुआत की। पेरिस्कोप खोलें - उनके पास क्या है?

हमेशा की तरह, मुख्य बात वास्तुकला है।

पेरिस्कोप की प्रमुख इंजीनियर सारा हैदर लिखती हैं कि वे बैकएंड के लिए वोजा का इस्तेमाल करती हैं। यदि हम थोड़ा और लेख पढ़ते हैं, तो हम देखेंगे कि वे RTMP प्रोटोकॉल का उपयोग करके क्या स्ट्रीम करते हैं, और इसे RTMP या HLS में वितरित करते हैं। आइए देखें कि ये प्रोटोकॉल क्या हैं और ये कैसे काम करते हैं।

हम अपनी तीन मुख्य आवश्यकताओं पर पेरिस्कोप का परीक्षण करते हैं।

उनके पास एक स्वीकार्य स्टार्ट स्पीड (अच्छे नेटवर्क पर एक सेकंड से कम), लगभग 600 पीएक्स (एचडी नहीं) की एक निरंतर गुणवत्ता है , और एक ही समय में देरी 12 सेकंड तक हो सकती है ।

वैसे, प्रसारण में देरी को कैसे मापें?

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

आउच! वह थोड़ा पीछे है - लगभग 12 सेकंड।

देरी के कारणों का पता लगाने के लिए, हम वीडियो स्ट्रीमिंग को प्रोफाइल करते हैं।

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

मूल रूप से, विचार करने के लिए दो मुख्य मुश्किल बिंदु हैं:

वीडियो एन्कोडिंग / डिकोडिंग;
नेटवर्क प्रोटोकॉल ।

वीडियो एन्कोडिंग / डिकोडिंग

मैं कोडिंग के बारे में थोड़ा बताऊंगा। यदि आप लो लेटेंसी लाइव स्ट्रीमिंग करते हैं तो आप इसका सामना करेंगे।

वीडियो क्या है? यह फ्रेम का एक सेट है, लेकिन बिल्कुल सरल नहीं है। फ्रेम तीन प्रकार के होते हैं: I, P और B- फ्रेम:

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

इससे पता चलता है कि B- फ्रेम हानिकारक हैं । आइए उन्हें दूर करने का प्रयास करें।

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

कोडेक्स का काम ऊपर की स्लाइड में दिखाया गया है। इस उदाहरण में, वीडियो एक स्थिर चित्र है, इसका एन्कोडिंग डिस्क स्थान को बचाता है, क्योंकि लगभग कुछ भी नहीं बदलता है, और वीडियो बिटरेट कम है। परिवर्तन हो रहे हैं - एन्ट्रॉपी बढ़ रहा है, वीडियो बिटरेट बढ़ रहा है - डिस्क पर स्टोर करना बहुत अच्छा है।

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

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

4. और बैकएंड पर, आपको जेरोलेटेंसी कोडेक को H264 में जोड़ने की आवश्यकता है - यह आपको भविष्य के लिए फ़्रेम में निर्भरता नहीं बनाने की अनुमति देगा।

वीडियो ट्रांसफर प्रोटोकॉल

विचार करें कि उद्योग क्या स्ट्रीमिंग प्रोटोकॉल प्रदान करता है। मैंने सशर्त रूप से उन्हें दो प्रकारों में विभाजित किया:

स्ट्रीमिंग प्रोटोकॉल;
खंड प्रोटोकॉल।

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

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

प्रोटोकॉल पर अधिक विस्तार से विचार करें। चलो स्ट्रीमिंग प्रोटोकॉल के साथ शुरू करते हैं और पता लगाते हैं कि अगर हम प्रसारण स्ट्रीमिंग के लिए स्ट्रीमिंग प्रोटोकॉल का उपयोग करते हैं तो हम किन समस्याओं का सामना कर सकते हैं।

स्ट्रीमिंग प्रोटोकॉल

पेरिस्कोप RTMP का उपयोग करता है। यह प्रोटोकॉल 2009 में दिखाई दिया, और पहली बार एडोब ने इसे पूरी तरह से निर्दिष्ट नहीं किया। तब उन्हें इस बात को लेकर एक खास तरह की कठिनाई थी कि एडोब एक्सक्लूसिव तौर पर अपना सर्वर बेचना चाहता था। यानी RTMP का विकास काफी मुश्किल था। उनकी मुख्य समस्या यह है कि वह टीसीपी का उपयोग करते हैं , लेकिन किसी कारण से पेरिस्कोप ने उन्हें चुना।

यदि आप विस्तार से पढ़ते हैं, तो यह पता चलता है कि पेरिस्कोप दर्शकों की एक छोटी संख्या के साथ प्रसारण के लिए RTMP का उपयोग करता है। बस ऐसे प्रसारण, यदि आपके पास एक अपर्याप्त चैनल है, तो सबसे अधिक संभावना है कि आप देख नहीं पाएंगे।

एक विशिष्ट उदाहरण पर विचार करें। संचार का एक संकीर्ण चैनल वाला एक उपयोगकर्ता है जो आपका प्रसारण देख रहा है। आप कम बिटरेट के बारे में RTMP पर उससे सहमत हैं और व्यक्तिगत रूप से उसके लिए स्ट्रीम करना शुरू करते हैं।

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

हमने इस समस्या को ठीक करने का निर्णय लिया। हमने RTMP के लिए प्रत्येक क्लाइंट के लिए व्यक्तिगत रूप से अलग किया जा सकता है, अर्थात, सर्वर के साथ स्ट्रीमर बातचीत करते हैं, उच्चतम संभव गुणवत्ता पर स्ट्रीम करते हैं, और प्रत्येक क्लाइंट उस गुणवत्ता को प्राप्त करता है जो नेटवर्क इसे अनुमति देता है।

वाह!

लेकिन फिर भी, हमारे पास TCP पर RTMP है, और किसी ने भी कतार की शुरुआत को रोकने से हमारा बीमा नहीं किया है।

यह आंकड़ा में चित्रित किया गया है: हमें ऑडियो और वीडियो फ़्रेम प्राप्त होते हैं, आरएमएमपी उन्हें पैक करता है, शायद वे उन्हें किसी तरह मिलाते हैं, और वे नेटवर्क पर उड़ जाते हैं।

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

स्ट्रीमिंग में टीसीपी प्रोटोकॉल का उपयोग करने के साथ एक और समस्या है।

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

हमारे पास कोई बफर प्रबंधन नहीं है, कोई प्राथमिकता नहीं है, इसलिए टीसीपी स्ट्रीमिंग के लिए बेहद अनुपयुक्त है ।

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

1.1 एमबीपीएस ट्रैफ़िक;
0.1% पैकेट नुकसान;
300 एमएस औसत आरटीटी।

और अगर आप कुछ क्षेत्रों और विशिष्ट ऑपरेटरों को देखते हैं, तो उनके पास औसत दैनिक पैकेट हानि प्रतिशत 3% से अधिक है , और 600 एमएस से आरटीटी सामान्य है।

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

पैकेट में 0.001% पैकेट खोने से भी थ्रूपुट में 30% की कमी होती है। यही है, हमारे उपयोगकर्ता यादृच्छिक पैकेट हानि के साथ नेटवर्क में टीसीपी प्रोटोकॉल की अक्षमता के कारण चैनल का 30% तक उपयोग नहीं करते हैं।

कुछ क्षेत्रों में, पैकेट का नुकसान 1% तक पहुंच जाता है, फिर उपयोगकर्ता के पास बैंडविड्थ का लगभग 10% हिस्सा होता है।

इसलिए, हम टीसीपी नहीं करेंगे ।

आइए देखें कि यूडीपी से स्ट्रीमिंग की दुनिया में और क्या है।

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

उनकी मुख्य समस्या यह है कि वे नुकसान की उपेक्षा करते हैं । सभी अजीब स्थितियों के साथ, वह बस गिरता है।

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

RTP स्ट्रीमिंग UDP पर डेटा संचारित करने के लिए मूल प्रोटोकॉल है। नीचे स्लाइड पर दाईं ओर एक्सटेंशन और RFC का एक सेट है जिसे कॉल के लिए इस प्रोटोकॉल को अनुकूलित करने के लिए WebRTC में लागू किया जाना था। सिद्धांत रूप में, आप कुछ ऐसा करने की कोशिश कर सकते हैं - आरटीपी को एक्सटेंशन का एक सेट डायल करें और यूडीपी स्ट्रीमिंग प्राप्त करें। लेकिन यह बहुत मुश्किल है ।

दूसरी समस्या यह है कि यदि आपका कोई ग्राहक किसी एक्सटेंशन का समर्थन नहीं करता है, तो प्रोटोकॉल काम नहीं करेगा।

खंड प्रोटोकॉल

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

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

खंडित स्ट्रीमिंग का एक और उदाहरण एचएलएस है ।

एमपीईजी-डैश Google से एक समाधान है, यह एंड्रॉइड में अच्छी तरह से काम करता है, और ऐप्पल समाधान पुराना है, इसमें कुछ निश्चित नुकसान हैं।

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

यदि आप विस्तार से और भी अधिक देखते हैं, तो प्रत्येक खंड के अंदर MPEG2-TS है। यह प्रोटोकॉल भी उपग्रह के लिए बनाया गया था, इसका पैकेट का आकार 188 बाइट्स है । इस आकार में वीडियो पैक करना बहुत असुविधाजनक है, खासकर क्योंकि आप इसे हर समय एक छोटे हेडर के साथ आपूर्ति करते हैं।

वास्तव में, यह न केवल सर्वरों के लिए मुश्किल है, जो कि 40 जीबी ट्रैफ़िक को संसाधित करने के लिए 26 मिलियन पैकेट एकत्र करने चाहिए, लेकिन क्लाइंट पर यह भी मुश्किल है। इसलिए, जब हमने MPEG-डैश पर iOS प्लेयर को फिर से लिखा, तो हमने कुछ प्रदर्शन लाभ भी देखे।

लेकिन Apple अभी भी खड़ा नहीं है। 2016 में, उन्होंने अंत में घोषणा की कि उनके पास एचएलएस में एमपीईजी 4 से एक टुकड़ा निकालने का अवसर है। तब उन्होंने इसे केवल डेवलपर्स के लिए जोड़ने का वादा किया था, लेकिन ऐसा लगता है कि अब macOS और iOS के लिए समर्थन दिखाई देना चाहिए।

यही है, ऐसा लगता है कि टुकड़ा स्ट्रीमिंग सुविधाजनक है - आओ, वांछित टुकड़ा लें, संदर्भ फ्रेम से शुरू करें - यह काम करता है।

माइनस: यह स्पष्ट है कि जिस संदर्भ फ्रेम से आपने शुरुआत की है वह वह फ्रेम नहीं है जो अब स्ट्रीम करता है। इसलिए, हमेशा देरी होती है ।

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

देरी बनाम कठिनाई

आइए सभी उपलब्ध प्रोटोकॉलों को देखें और उन्हें दो मापदंडों द्वारा क्रमबद्ध करें:

वे प्रसारण और दर्शक के बीच में जो विलंबता देते हैं;
जटिलता (कठिनाई)।

प्रोटोकॉल की गारंटी में देरी जितनी कम होती है, उतना ही जटिल होता है।

हम क्या चाहते हैं?

हम निजी या सार्वजनिक प्रसारण के आधार पर पैकेटों के वैकल्पिक एन्क्रिप्शन के विकल्प के साथ, P2P संचार के लिए तुलनीय देरी के साथ 1 से एन स्ट्रीमिंग के लिए एक यूडीपी प्रोटोकॉल बनाना चाहते हैं।

अन्य विकल्प क्या हैं? आप प्रतीक्षा कर सकते हैं, उदाहरण के लिए, जब Google अपना QUIC जारी करता है।

मैं आपको बताऊंगा कि यह क्या है? Google टीसीपी के प्रतिस्थापन के रूप में Google QUIC का स्थान ले रहा है - एक तरह का टीसीपी 2.0। यह 2013 से विकसित किया गया है, अब इसमें कोई विनिर्देश नहीं है, लेकिन यह Google क्रोम में पूरी तरह से उपलब्ध है, और मुझे लगता है कि वे कभी-कभी कुछ उपयोगकर्ताओं को इसे देखने के लिए चालू करते हैं कि यह कैसे काम करता है। सिद्धांत रूप में, आप सेटिंग्स में जा सकते हैं, QUIC चालू कर सकते हैं, किसी भी Google साइट पर जा सकते हैं और UDP के माध्यम से यह संसाधन प्राप्त कर सकते हैं।

हमने निर्णय लिया कि जब तक वे सभी निर्दिष्ट न करें, तब तक प्रतीक्षा करें और अपना निर्णय दर्ज करें।

प्रोटोकॉल आवश्यकताएँ:

मल्टीथ्रेडिंग , अर्थात् , हमारे पास कई धाराएँ हैं - नियंत्रण, वीडियो, ऑडियो।
एक वैकल्पिक वितरण गारंटी - नियंत्रण धारा में 100% गारंटी है, जिस वीडियो की हमें कम से कम आवश्यकता है - हम वहां फ्रेम को गिरा सकते हैं, हम अभी भी ऑडियो पसंद करेंगे।
धाराओं का प्राथमिकताकरण - ताकि ऑडियो आगे बढ़े, और प्रबंधक आम तौर पर उड़ गए।
वैकल्पिक एन्क्रिप्शन : या तो सभी डेटा, या केवल हेडर और महत्वपूर्ण डेटा।

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

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

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

डिज़ाइन

आइए यूडीपी प्रोटोकॉल लिखना शुरू करें, लेकिन पहले आंकड़ों को देखें।

ये मोबाइल नेटवर्क पर हमारे आँकड़े हैं। यह देखा जा सकता है कि औसत इंटरनेट मेगाबिट से थोड़ा अधिक है, लगभग 1% का पैकेट नुकसान सामान्य है, और 600 एमएस के क्षेत्र में आरटीटी - 3 जी पर, ये सिर्फ औसत मूल्य हैं।

हम प्रोटोकॉल लिखते समय इस पर ध्यान केंद्रित करेंगे - चलो!

यूडीपी प्रोटोकॉल

हम सॉकेट यूडीपी खोलते हैं, हम डेटा निकालते हैं, हम पैक करते हैं, हम भेजते हैं। हम कोडेक से दूसरा पैक लेते हैं, हम अभी भी भेजते हैं। सब कुछ बहुत अच्छा लगने लगा है!

लेकिन हमें निम्न चित्र मिलता है: यदि हम बेतरतीब ढंग से यूडीपी पैकेटों को सॉकेट में भेजना शुरू करते हैं, तो आंकड़ों के अनुसार, 21 वें पैकेट द्वारा संभावना है कि यह केवल 85% तक पहुंच जाएगा। यही है, पैकेट नुकसान पहले से ही 15% होगा, जो अच्छा नहीं है। इसे ठीक करने की जरूरत है।

यह मानक के रूप में तय किया गया है। दृष्टांत पैकर के बिना जीवन को दर्शाता है और पेसर के साथ जीवन।

पेसर एक ऐसी चीज है जो समय में पैकेट फैलाती है और उनके नुकसान को नियंत्रित करती है; अब यह देखा जाता है कि पैकेट का नुकसान क्या है, इस पर निर्भर करता है कि यह चैनल की गति को बढ़ाता है।

जैसा कि हम याद करते हैं, मोबाइल नेटवर्क के लिए, 1-3% पैकेट नुकसान आदर्श है। तदनुसार, हमें किसी तरह इस के साथ काम करना चाहिए। अगर हम पैकेज खो देते हैं तो क्या होगा?

पुनर्संचरित

टीसीपी में, जैसा कि आप जानते हैं, एक तेज रिट्रांसमिट एल्गोरिथ्म है: हम एक पैकेट भेजते हैं, दूसरा, अगर पैकेट खो जाता है, तो थोड़ी देर बाद (रिट्रांसमीटर अवधि) हम उसी पैकेट को भेजते हैं।

क्या फायदे हैं? कोई समस्या नहीं, कोई अतिरेक नहीं है, लेकिन एक माइनस है - कुछ रिट्रांसमिट अवधि ।

यह बहुत सरल प्रतीत होता है: कुछ समय बाद आपको पैकेज को दोहराने की आवश्यकता होती है यदि आपको इस पर पुष्टि नहीं मिली है। तार्किक रूप से, यह पिंग टाइम के बराबर समय हो सकता है। ping — , RTT time , , .

, , , , jitter: ping-. , , 46 . jitter — 50.

. RTT , , acknowledge . , RFC6298, TCP , .

jitter. jitter ping 15%. , retransmit period , , 20% , RTT.

retransmit. acknowledge . , , . retransmit period, . , .

, retransmit . , , packet loss 5%, 400 , 400 1 packet-drop, , retransmit period , .

, . , , acknowledge . , — , , speculative retransmit .

retransmit, .

. , Forward Error Correction ? , , XOR. , , .

! round trip, .

, , ? XOR — , Reed-Solomon, Fountain codes .. : K , N , N .

!

, , , Forward Error Correction negative acknowledgement.

NACK

, parity protection ( ) , .

NACK:

, negative acknowledgement, .
FEC.

, :

, FEC + NACK;
, Fast retransmit.

, .

, , ( ). , , 11 , 60-80 . , , .

6 .

, , . , . , Wi-Fi 22 5 , 3G 34 8 .

: , 90% packet loss 10 , gap 25 , — FEC + NACK Fast retransmit?

, , , Google, QUIC 2013 , Forward Error Correction , , . 2015 .

FEC + NACK, .

, .

, , c :

1 / ;
1% packet loss;
300 RTT;
1 000 — ;
1 000 .

10 . packet loss 1% 1 000 10. — 100 1 — , 2 , .

, . 500- , 10 .

:

500 Forward Error Correction. , .
NACK, , .
Fast Retransmit, .

Forward Error Correction , — gap 200-300 .

Fast Retransmit

: , 10 , , , retransmit period , .

, retransmit period 350 , packet gap — 25-30 , 100. , , retransmit , .

, .

UDP , .

, , p/b-. . , .

, , , , , , 0,5 .

, , , , p/b, , , .

MTU

चूंकि हम स्वयं प्रोटोकॉल लिख रहे हैं, इसलिए हमें आईपी विखंडन से निपटना होगा। मुझे लगता है कि बहुत से लोग इस बारे में जानते हैं, लेकिन सिर्फ मामले में, मैं आपको संक्षेप में बताऊंगा।

हमारे पास एक सर्वर है, यह नेटवर्क में कुछ पैकेट भेजता है, वे राउटर में आते हैं और इसके स्तर पर MTU (अधिकतम ट्रांसमिशन यूनिट) उस पैकेट के आकार से कम हो जाता है जो आ गया है। यह पैकेट को बड़े और छोटे (यहां 1100 और 400 बाइट्स) में विभाजित करता है और भेजता है।

सिद्धांत रूप में, कोई समस्या नहीं है, यह सब क्लाइंट पर इकट्ठा होगा और काम करेगा। लेकिन अगर हम 1 पैकेट खो देते हैं, तो हम सभी पैकेट छोड़ देते हैं, साथ ही हमें पैकेट हेडर के लिए अतिरिक्त लागत मिलती है। इसलिए, यदि आप अपना प्रोटोकॉल लिख रहे हैं, तो यह एमटीयू की मात्रा में काम करने के लिए आदर्श है।

इसे कैसे गिना जाए?

वास्तव में, Google परेशान नहीं करता है, अपने QUIC में लगभग 1200 बाइट्स रखता है और इसका चयन नहीं करता है, क्योंकि तब IP विखंडन सभी पैकेटों को इकट्ठा करेगा।

हम बिल्कुल वैसा ही करते हैं - पहले हम कुछ डिफ़ॉल्ट आकार निर्धारित करते हैं और पैकेट भेजना शुरू करते हैं - इसे उन्हें खंडित करने दें।

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

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

वास्तव में, यह कभी-कभी बदल जाता है। हम हैरान थे, लेकिन वाई-फाई, आदि को बदलने की प्रक्रिया में एमटीयू बदल रहा है। बेहतर है कि इस समानांतर प्रक्रिया को न रोका जाए और समय-समय पर एमटीयू को सही किया जाए।

दुनिया में उच्च MTU वितरण। हमें पोर्टल पर लगभग 1100 बाइट्स मिले।

एन्क्रिप्शन

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

यदि प्रसारण निजी है, तो हम सभी डेटा का एन्क्रिप्शन भी जोड़ सकते हैं।

पैकेट को स्वतंत्र रूप से AES-256 के साथ एन्क्रिप्ट किया गया है, ताकि पैकेट ड्रॉप आगे पैकेट एन्क्रिप्शन को प्रभावित न करे।

प्राथमिकता

याद रखें, हम प्रोटोकॉल से अधिक प्राथमिकता चाहते थे।

हमारे पास मेटाडेटा, ऑडियो और वीडियो फ्रेम हैं, हम उन्हें सफलतापूर्वक नेटवर्क पर भेजते हैं। फिर हमारा नेटवर्क नरक में जलता है और लंबे समय तक काम नहीं करता है - हम समझते हैं कि हमें पैकेट छोड़ने की जरूरत है।

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

यूडीपी के बारे में अतिरिक्त बान

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

स्लाइड पर, कई बार यूडीपी के माध्यम से सर्वर से क्लाइंट तक पहुंचना संभव नहीं था।

कई संशयवादियों का कहना है कि राउटर को इस तरह से डिज़ाइन किया गया है कि एनएटी अनबाइंडिंग मुख्य रूप से यूडीपी मार्गों को भीड़ देता है। लेकिन ऊपर से पता चलता है कि अगर कीप-अलाइव या पिंग 30 सेकंड से कम है, तो 99% की संभावना के साथ क्लाइंट तक पहुंचना संभव होगा।

दुनिया में मोबाइल उपकरणों पर यूडीपी की उपलब्धता

Google 6% कहता है, लेकिन यह पता चला है कि 7% मोबाइल उपयोगकर्ता UDP का उपयोग नहीं कर सकते हैं । इस मामले में, हम अपने सुंदर प्रोटोकॉल को प्राथमिकता, एन्क्रिप्शन और सब कुछ के साथ छोड़ देते हैं, केवल टीसीपी पर।

UDP पर, VOIP अब WebRTC, Google QUIC पर काम करता है, और कई खेल UDP पर काम करते हैं। इसलिए, मुझे विश्वास नहीं होगा कि यूडीपी मोबाइल उपकरणों पर बंद हो जाएगा।

परिणामस्वरूप, हम:

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

हमारे ओके लाइव मोबाइल एप्लिकेशन में देरी कैमरा स्कैनर के कामों की तुलना में 25 एमएस - 10 एमएस है, लेकिन यह इतना डरावना नहीं है।
वेबकास्टिंग केवल 690 ms - स्थान की देरी को दर्शाता है!

Odnoklassniki पर और क्या स्ट्रीम कर सकते हैं

मोबाइल उपकरणों से हमारे OKMP प्रोटोकॉल को स्वीकार करता है;
RTMP और WebRTC स्वीकार कर सकते हैं;
एचएलएस, एमपीईजी-डैश इत्यादि को बाहर करता है।

यदि आप सावधान थे, तो आपने देखा कि मैंने कहा था कि हम, उदाहरण के लिए, उपयोगकर्ता से WebRTC और इसे RTMP में परिवर्तित कर सकते हैं।

एक अति सूक्ष्म अंतर है। वास्तव में, WebRTC एक पैकेट-उन्मुख प्रोटोकॉल है और OPUS ऑडियो कोडेक का उपयोग करता है। आप RTMP में OPUS का उपयोग नहीं कर सकते।

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

यह हमारे अंदर कैसा दिखता है?

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

लोहे के लिए, हमारे पास निम्नलिखित हैं:

मैं आपको दोष सहिष्णुता के बारे में थोड़ा और बताऊंगा:

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

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

हम जल्दी से दोष सहिष्णुता का परीक्षण करेंगे। हम संपूर्ण डेटा सेंटर के गायब होने के तुरंत बाद शुरू करते हैं।

क्या होगा?

DNS उपयोगकर्ता किसी अन्य अपलोड सर्वर का अगला आईपी लेगा।
इस समय तक, चिड़ियाघरकीपर समझ जाएगा कि उस डेटा केंद्र में सर्वर की मृत्यु हो गई है, और दूसरे के लिए सर्वर का टुकड़ा करना होगा।
डाउनलोड-सर्वर यह पता लगाएगा कि अब इस स्ट्रीम के परिवर्तन के लिए कौन जिम्मेदार है और इसे वितरित करेगा।

सिद्धांत रूप में, यह सब न्यूनतम देरी के साथ होगा।

उत्पाद में प्रोटोकॉल का उपयोग करना

हमने ओके लाइव स्ट्रीमिंग मोबाइल ऐप बनाई। यह पूरी तरह से पोर्टल के साथ एकीकृत है। वहां के उपयोगकर्ता संचार कर सकते हैं, लाइव प्रसारण का संचालन कर सकते हैं, प्रसारण का एक नक्शा है, लोकप्रिय प्रसारणों की एक सूची है - सामान्य तौर पर, आप जो चाहें वह सब कुछ कर सकते हैं।

हमने FullHD में प्रसारण की क्षमता भी जोड़ी है। आप एंड्रॉइड डिवाइस पर एंड्रॉइड पर एक एक्शन कैमरा कनेक्ट कर सकते हैं।

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

यही है, वास्तव में, न्यूनतम देरी के साथ दो आने वाली धाराएं सार्वजनिक कॉन्फ्रेंसिंग का एक निश्चित प्रारूप प्रदान करती हैं।

वास्तव में, हम 2 सेकंड में कहीं मिले - एक दूसरा वहाँ और दूसरा वापस। याद रखें कि "ट्रॉली" जो मैंने लेख की शुरुआत में बात की थी - अब यह 2 विशाल ट्रकों की तरह दिखता है। टीवी प्रसारण के लिए, कैमरे से हटाने के लिए और बस 1-2 एस की देरी के साथ सब कुछ मिलाएं पूरी तरह से सामान्य है।

वास्तव में, हम वर्तमान आधुनिक टीसीपी के साथ तुलनीय कुछ पुन: पेश करने में कामयाब रहे।

लाइव प्रसारण वर्तमान प्रवृत्ति है। पिछले एक साल और ओके पोर्टल पर डेढ़, वे तीन गुना (ओके लाइव एप्लिकेशन की मदद के बिना नहीं) हैं।

सभी प्रसारण डिफ़ॉल्ट रूप से दर्ज किए जाते हैं। हमारे पास प्रति दिन लगभग 50 हज़ार धाराएँ हैं, यह प्रति दिन लगभग 17 टेराबाइट ट्रैफ़िक उत्पन्न करती है, लेकिन सामान्य तौर पर पोर्टल पर सभी वीडियो प्रति माह डेटा की एक पेटाबाइट के बारे में उत्पन्न करते हैं।

हमें क्या मिला:

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

आपने क्या सीखा:

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

हाईलोड + ++ साइबेरिया में, अलेक्जेंडर टोबोल ने ओके कॉल सेवा के बारे में बात करने का वादा किया है, यह जानना दिलचस्प होगा कि इस लेख में क्या चर्चा की गई थी, जिसे लागू किया गया था और जिसे फिर से पूरी तरह से लागू किया जाना था।

एक ही खंड में, रिपोर्ट विशेष विषयों पर नियोजित हैं:

सीडीएन नोड्स के संचालन पर विस्तृत आंकड़े एकत्र करने के लिए सिस्टम पर यूजीन रॉसिंस्की ( ivi )।
एंटोन रुसाकोवा ( सगाई ) अपने स्वयं के बिलिंग का उपयोग किए बिना भुगतान प्रणालियों के एकीकरण पर।

हम अपना प्रोटोकॉल UDP के शीर्ष पर लिखते हैं