मुझे पूरा देखें: मोबाइल प्लेटफॉर्म पर लाइव वीडियो का सबसे अधिक निचोड़

मोबाइल डिवाइस पर वीडियो चलाने का सबसे आसान तरीका सिस्टम पर मौजूदा खिलाड़ी के साथ लिंक को खोलना है, लेकिन यह हमेशा प्रभावी नहीं होता है।

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

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

सामग्री मोबियस सम्मेलन से अलेक्जेंडर टोबोल ( @alatobol ) और इवान ग्रिगोरिएव ( @ivan_a ) की रिपोर्ट के प्रतिलेख पर आधारित है।

प्रविष्टि

शुरुआत के लिए - Odnoklassniki में वीडियो के बारे में कुछ संख्या।

शिखर औसत दैनिक वीओडी (मांग पर वीडियो) यातायात प्रति सेकंड डेढ़ टेराबिट्स से अधिक है, और लाइव प्रसारण के लिए - प्रति सेकंड 3 से अधिक टेराबिट्स।

अब ओके में प्रति दिन 870 मिलियन से अधिक वीडियो दृश्य हैं, जिनमें से आधे से अधिक मोबाइल उपकरणों से हैं।



यदि आप स्ट्रीमिंग के इतिहास को देखते हैं, तो 2007 में YouTube पर एक मोबाइल वीडियो दिखाई दिया। हम बाद में इस ट्रेन पर रुक गए, लेकिन 2014-2015 में हमारे पास पहले से ही मोबाइल उपकरणों पर 4K वीडियो प्लेबैक था, और हाल के वर्षों में हम सक्रिय रूप से अपने खिलाड़ियों को विकसित कर रहे हैं। इसके बारे में और बातचीत चलेगी।

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

हम वीडियो के साथ काम करने के लिए एपीआई पर ध्यान नहीं देंगे, लेकिन अभी गहराई से गोता लगाएँ और यह पता लगाने की कोशिश करें कि अंदर क्या हो रहा है।



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

केपीआई खिलाड़ी के साथ शुरू करते हैं। हम उससे क्या चाहते हैं?

• तेजी से पहला फ्रेम। उपयोगकर्ता प्लेबैक की शुरुआत के लिए इंतजार नहीं करना चाहते हैं।
• बफरिंग का अभाव। किसी को भी धड़ में दौड़ना पसंद नहीं है।
• उच्च गुणवत्ता। जब अभी तक लगभग कोई 4K सामग्री नहीं थी, तो हमने पहले से ही 4K समर्थन "आउटगोइंग" बना दिया था: यदि आप इसके लिए खिलाड़ी को बंद करते हैं और प्रदर्शन का पता लगाते हैं, तो 1080p कमजोर उपकरणों पर भी पूरी तरह से खेलेंगे।
• UX आवश्यकताओं। हमें स्क्रॉल करते समय टेप में वीडियो चलाने की आवश्यकता होती है, और टेप के लिए हमें वीडियो को प्रीफ़ैच करने की आवश्यकता होती है।

इस तरह से कई समस्याएं हैं। 4K वीडियो के लिए स्ट्रीम बड़ी है, और हम मोबाइल उपकरणों पर काम करते हैं जहां नेटवर्क की समस्याएं हैं, विभिन्न उपकरणों पर वीडियो प्रारूपों और कंटेनरों की विभिन्न विशेषताएं हैं, और डिवाइस स्वयं भी एक समस्या बन सकते हैं।

आपको क्या लगता है कि वीडियो iOS या Android पर तेज़ी से शुरू होता है?

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



इसमें एक अति सूक्ष्म अंतर है कि हम उपयोगकर्ताओं के लिए औसत मापते हैं, और आईओएस उपकरणों की औसत शक्ति एंड्रॉइड की तुलना में अधिक है।

सामग्री का पहला भाग सैद्धांतिक होगा: हम सीखेंगे कि वीडियो क्या है और किसी भी लाइव प्लेयर की वास्तुकला कैसी दिखती है। और दूसरे भाग में, खिलाड़ियों की तुलना करते हैं और बात करते हैं कि कब अपना लिखना है।

एक भाग

क्या है वीडियो

सबसे बुनियादी के साथ शुरू करते हैं। वीडियो 60 या 24 चित्र प्रति सेकंड है।

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



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

कोडिंग एल्गोरिदम, ट्रांसफॉर्मेशन मैट्रिसेस, मोशन सर्च, और जैसे बहुत सारे हैं - यह कोडेक्स में भिन्न है।

कोडेक प्रदर्शन

क्लासिक एच .264 2003 से जाना जाता है और अच्छी तरह से विकसित हुआ है। हम इसकी प्रभावशीलता को आधार के रूप में लेंगे। वह हर जगह काम करता है और खेलता है। इसमें CPU / GPU (Android पर दोनों iOS पर) के लिए हार्डवेयर समर्थन है। इसका मतलब यह है कि या तो किसी प्रकार का विशेष कॉपीप्रोसेसर है जो इसे कोड कर सकता है, या अंतर्निहित निर्देश सेट जो आपको जल्दी से ऐसा करने की अनुमति देता है। औसतन, हार्डवेयर सपोर्ट 10x तक तेज परफॉर्मेंस देता है और बैटरी लाइफ बचाता है।

2010 में, Google से VP8 दिखाई दिया। दक्षता के संदर्भ में, यह H.264 से भिन्न नहीं है। खैर, वास्तव में कोडेक की प्रभावशीलता एक बहुत ही विवादास्पद चीज है। माथे में, इसे संपीड़ित करने के लिए मूल वीडियो के अनुपात के रूप में मापा जाता है, लेकिन यह स्पष्ट है कि अलग-अलग वीडियो कलाकृतियां हैं। इसलिए, हम मॉस्को स्टेट यूनिवर्सिटी से कोडेक्स की विस्तृत तुलना के लिए एक लिंक प्रदान करते हैं। लेकिन यहां हम खुद को इस तथ्य तक सीमित रखते हैं कि वीपी 8 एक सॉफ्टवेयर संगठन पर केंद्रित है, आप इसे अपने साथ कहीं भी खींच सकते हैं, और आमतौर पर इसका उपयोग एक कमबैक के रूप में किया जाता है अगर कोई मूल एच .264 समर्थन नहीं है।

2013 में, कोडेक्स की एक नई पीढ़ी दिखाई दी - H.265 (HEVC) और VP9। H.265 कोडेक 50% की दक्षता में वृद्धि देता है, लेकिन एंड्रॉइड वीडियो पर उन्हें एन्कोड नहीं किया जा सकता है, डिकोडर केवल 5.0++ के साथ दिखाई दिया। लेकिन iOS पर सपोर्ट है।

H.265 - VP9 के लिए एक विकल्प है। सभी समान, लेकिन Google द्वारा समर्थित। खैर, V9 YouTube है, और H.265 नेटफ्लिक्स है। तो प्रत्येक की अपनी ख़ासियतें हैं: एक आईओएस पर काम नहीं करेगा, दूसरे को एंड्रॉइड पर समस्याएं होंगी। अंत में, कई H.264 पर बने रहे।

भविष्य में, हमें AV1 कोडेक का वादा किया जाता है, इसमें पहले से ही एक सॉफ्टवेयर कार्यान्वयन है, और इसकी दक्षता 2013 के कोडेक की तुलना में 35% अधिक है। अब क्रोम और फ़ायरफ़ॉक्स में उपलब्ध है, और 2020 में Google हार्डवेयर समर्थन का वादा करता है - मुझे लगता है, सबसे अधिक संभावना है, हम सभी इसे स्थानांतरित करेंगे।

अंत में, उन्होंने हाल ही में H.266 / JVEC कोडेक की घोषणा करते हुए कहा कि सब कुछ बेहतर और तेज होगा।

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

सामान्य तौर पर, डिफ़ॉल्ट रूप से, हर कोई H.264 लेता है, और फिर विशिष्ट उपकरणों के लिए यह जटिल हो सकता है।

गुणवत्ता, संकल्प और बिटरेट

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

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



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

जानकारी की मूल राशि के साथ एन्कोडेड वीडियो की बिटरेट कैसे तुलना करती है? एक 4K स्क्रीन पर, हम लगभग 6 Gb / s जानकारी खेल सकते हैं (यदि आप सभी पिक्सेल और उनकी आवृत्ति 60 फ्रेम प्रति सेकंड पर गिनते हैं), जबकि कोडेक बिटरेट 50 एमबी / एस हो सकता है। यही है, कोडेक वीडियो को 100 गुना तक संकुचित करता है।

वितरण तकनीक

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



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

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

क्या खंड वितरण दिखता है: हम मौजूदा वीडियो को खंडों में काटते हैं, उनके साथ ऑडियो और वीडियो के लिए हेडर, एमपीईजी-टीएस और MP4 परिवहन के उदाहरण के साथ। फोन पर हम इस बात की जानकारी देते हैं कि सेगमेंट कहां और किस गुणवत्ता के लिए है, और यह प्रकट समय-समय पर अद्यतन किया जा सकता है।

ऐतिहासिक रूप से, Apple एचएलएस और एंड्रॉइड के माध्यम से डीएएस के माध्यम से वितरित करता है। आइए देखें कि वे कैसे भिन्न हैं।

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



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



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



नेटवर्क ओवरहेड और पार्सिंग जटिलता जोड़ें: यदि आप क्रोम में DASH और HLS में 4K खेलने का प्रयास कर रहे हैं, तो आप उस अंतर को महसूस करेंगे जब आपका कंप्यूटर HLS पैकेट के साथ "बंद" हो जाता है।

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



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

यहाँ एक छोटी प्लेट है, जिसमें से क्या चुनना है:



HLS में, ऐतिहासिक रूप से समर्थित वीडियो कोडेक केवल H.264 हैं, MPEG-DASH में आप किसी को भी हिला सकते हैं। एचएलएस की मुख्य समस्या शुरुआत में एक अतिरिक्त दौर की यात्रा है, यह 4.0 के साथ आईओएस और एंड्रॉइड दोनों पर अच्छा खेलता है। और DASH मुख्य रूप से Google (Chrome और Android) द्वारा समर्थित है और इसे iOS पर नहीं चलाया जा सकता है।

खिलाड़ी वास्तुकला

हमने वीडियो को अधिक या कम सॉर्ट किया, अब देखते हैं कि कोई भी खिलाड़ी कैसा दिखता है।



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

खिलाड़ी की सामान्य वास्तुकला:



एक नेटवर्क हिस्सा है, एक सॉकेट, जहां डेटा आता है।

उसके बाद - एक डीमुल्टिप्लेक्सर या किसी प्रकार की चीज जो परिवहन (HLS / DASH) से ऑडियो और वीडियो स्ट्रीम प्राप्त करती है। वह उन्हें उपयुक्त कोडेक्स में भेजता है।

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

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

और इनपुट पर एक लोड नियंत्रण होता है, जो डेटा को लोड करता है और बफर को नियंत्रित करता है।

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



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



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

क़ीमत लगानेवाला

एडैपिंग करते समय, खिलाड़ी 2 मुख्य मापदंडों पर निर्भर करता है: नेटवर्क की गति और डेटा बफर।

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



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

अधिक दबाव से सुरक्षा

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

ऐसी स्थिति होती है जब नेटवर्क प्लेबैक के दौरान सुस्त हो जाता है या संसाधन बैकएंड पर निकल जाते हैं। जब खिलाड़ी प्लेबैक शुरू करता है, तो यह पकड़ना शुरू कर देता है।

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

पहला सरल तरीका जो हम, ज़ाहिर है, उपयोग सर्वर पर थ्रॉटलर है। वह समझता है कि यातायात समाप्त हो जाता है, गुणवत्ता कम हो जाती है और जानबूझकर ग्राहकों को धीमा कर देता है ताकि बहुत झटका न लगे।



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

खिलाड़ी

IOS में, केवल देशी AVPlayer है, लेकिन Android पर एक विकल्प है। एक देशी MediaPlayer है, लेकिन एक खुला स्रोत जावा-आधारित ExoPlayer है जो एप्लिकेशन "उनके साथ लाते हैं।" उनके पेशेवरों और विपक्ष क्या हैं?

तीनों की तुलना करें:



अनुकूली स्ट्रीमिंग के मामले में, एक्सोप्लेयर DASH / HLS की भूमिका निभाता है और अन्य प्रोटोकॉल के लिए कई विस्तार योग्य मॉड्यूल हैं, जबकि AVPlayer खराब हो रहा है।

ऑपरेटिंग सिस्टम संस्करणों के लिए समर्थन, सिद्धांत रूप में, हर जगह सभी को सूट करता है।

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

मूल खिलाड़ियों के बगफिक्स के साथ एक समस्या है। ExoPlayer के मामले में, आप बस इसे अपने एप्लिकेशन के नए संस्करण में रोल करते हैं, लेकिन देशी AVPlayer और MediaPlayer में बग केवल अगले OS रिलीज़ में ठीक किया जाएगा। हम इस दर्द से भर गए: iOS 8.01 में हमारा वीडियो खराब तरीके से चलने लगा, iOS 8.02 में पूरे पोर्टल ने काम करना बंद कर दिया, 8.03 में सब कुछ फिर से काम कर गया। और इस मामले में हम पर कुछ भी निर्भर नहीं था, हम बस बैठ गए और Apple के अगले संस्करण की प्रतीक्षा कर रहे थे।

एक्सोप्लेयर टीम ऑडियो के मामले में ऊर्जा की खपत की अक्षमता के बारे में बात करती है। Google से सामान्य अनुशंसाएँ हैं: ऑडियो चलाने के लिए, MediaPlayer का उपयोग करें, बाकी सब के लिए Exo।

समझा जाता है, हम Android पर वीडियो के लिए डैश के साथ ExoPLayer, और iOS पर HLS के साथ AVPlayer का उपयोग करेंगे।

त्वरित पहला फ्रेम

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

बफर का आकार

अब बफ़र्स के साथ व्यवहार करते हैं। हमारे पास न्यूनतम मात्रा में डेटा है जिसे हमें खेलना शुरू करने से पहले डाउनलोड करना होगा। AVPlayer में, इस मान को AVPlayerItem तरजीही फ़ोरवर्डबफ़र अवधि का उपयोग करके कॉन्फ़िगर किया गया है।



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



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

मूल गुण

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

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

और Android पर, इसके लिए एक DefaultBandwidthMeter पैरामीटर है। यह एक मान देता है कि यह आपके बैंड के डिफ़ॉल्ट बैंडविड्थ पर विचार करता है।



यह कैसे काम करता है: कोड में स्थिरांक की एक बड़ी तालिका है, और पैरामीटर सरल हैं - देश (क्षेत्र) और कनेक्शन का प्रकार (वाई-फाई, 2 जी, 3 जी, 4 जी)। अर्थ क्या हैं? उदाहरण के लिए, यदि आपके पास वाई-फाई है और यूएसए में स्थित है, तो आपका प्रारंभिक बैंडविड्थ 5.6 एमबीपीएस है। और अगर 3G 700 kbps है।

यह देखा जा सकता है कि, Google के अनुमानों के अनुसार, रूस में 4 जी अमेरिका की तुलना में 2-3 गुना तेज है।

, — , . , , , , .

, , , , . , ( Android ).

(seek), , . , , , .



, , - . iOS, , , , ( , , ).

ExoPlayer 2.7.0 , , « ». . , .



( , ), - , Android prepare(mediaSource), seekTo(). , , , . — :



, ( , ), . ( 100 ), , .

iOS , Android legacy-.
TextureView. , , , , UI. — .

SurfaceView. , . Android- . YouTube , .

GLSurfaceView — . , .



: , ExoPlayer, 23%. «» 10%. 4% . 4% — , .

: Android

• MediaPlayer , ExoPlayer
• start, seek, swap
• ,
• view

: iOS

iOS :

• RTT HLS AVPlayer
• AVPlayer#pause
• — , iOS

DASH-, « live-». :

• cURL GCDAsyncSocket
• AVAssetReader,
• CADisplayLink
• AVSampleBufferDisplayLayer

, . 28%, «» 6%. , HLS DASH 100 /, 6%.

iOS :

• start seek
• HLS over Fragmented mp4
• DASH-

, .

:

, , .

• ( mp4)
• (ExoPlayer, AVPlayer)
• firstFrame, seek, emptyBuffer
• ( )
• - , . 4, : performance, , .

— .

:

, ?



API . API iOS Android, — , .

: - wrapper , POSIX-, , .

?

• जल्दी शुरू करो

?

• bandwidth
• (N x RTT, RTT)

— . , , .

: , , . — low latency.

, — . .

— 4K. , , . , 30 , . , .

, , , . ( 100 ).

- , , .

. 100 , . , 300 kbps FullHD- 480p, FullHD . , : , , overhead-. .

:



, , . , - , , .

MediaCodec VideoToolbox ( ). Server Transcoder.

— , .

, . , , reliability — ( ), throughput — ( ) low latency — ( ).



, . , - .

, : RTMP WebRTC — , OKMP — .

, RTMP TCP, — UDP.

RTMP

वह क्या देता है? एक निश्चित तरीके से, यह एक मानक है जो सभी सेवाओं - YouTube, Twitch, Flash, OK द्वारा समर्थित है। वे इसका उपयोग करते हैं ताकि उपयोगकर्ता लाइव स्ट्रीम अपलोड कर सकें। यदि आप किसी तृतीय-पक्ष सेवा के लिए लाइव स्ट्रीम स्ट्रीम करना चाहते हैं, तो आपको सबसे अधिक RTMP के साथ काम करना होगा।

एक टेप ड्राइव से एक खिलाड़ी को प्राप्त करने में हम जो न्यूनतम देरी कर रहे हैं वह 300 एमएस है, लेकिन यह ठीक मौसम में एक आदर्श नेटवर्क में है। जब हमारे पास एक वास्तविक नेटवर्क होता है, तो देरी आमतौर पर 2-3 सेकंड तक बढ़ती है, और यदि नेटवर्क के साथ सब कुछ खराब है, तो यह सेकंड के दसियों तक बढ़ सकता है।

RTMP मक्खी पर रिज़ॉल्यूशन और बिट रेट बदलने का समर्थन करता है (उल्लिखित अन्य प्रोटोकॉल समान हैं, लेकिन RTMP के बारे में गलत जानकारी है कि मक्खी पर कोई बदलाव नहीं होता है)।

टकसालों में से: टीसीपी पर निर्मित (हम बाद में बताएंगे कि यह क्यों खराब है), देरी अनियंत्रित है।

यदि आप त्रिकोण को देखते हैं, तो RTMP कम विलंबता देने में सक्षम नहीं होगा। यह प्राप्त किया जा सकता है, लेकिन गारंटी नहीं है।

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



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



एक दृष्टांत के रूप में, रेखा अवरुद्ध समस्या का प्रमुख है। यह न केवल स्ट्रीमिंग में, बल्कि कई अन्य मामलों में भी पाया जाता है।

यह क्या है हमारे पास शुरू में खाली रिसीवर बफर है। हम कहीं से डेटा प्राप्त कर रहे हैं: बहुत सारे डेटा और बहुत सारे आईपी पैकेट। हमें पहला IP पैकेट प्राप्त हुआ, और रिसीवर पर recv () विधि का उपयोग करके हम इस पैकेट को घटा सकते हैं, डेटा प्राप्त कर सकते हैं, खो सकते हैं, रेंडर कर सकते हैं। लेकिन तभी अचानक दूसरा पैकेट खो गया। आगे क्या होता है?

एक खोए हुए आईपी पैकेट को पुनर्प्राप्त करने के लिए, टीसीपी को पुन: प्रस्तुत करना होगा। ऐसा होने के लिए, आपको आरटीटी खर्च करने की आवश्यकता है, जबकि रिट्रांसमिशन भी खो सकता है, और हम चक्रों में जाएंगे। यदि कई पैकेज हैं, तो यह निश्चित रूप से होगा।

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

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



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

मान लें कि हमारे पास 4 एमबीपीएस की विशिष्ट गति वाला एक नेटवर्क है। हमने 250 KB का एक सॉकेट आकार चुना (अपनी गति से 0.5 सेकंड के लिए)। अचानक, नेटवर्क 10 बार विफल हुआ - यह एक सामान्य स्थिति है। हमारे पास 400 केबीपीएस है। बफर जल्दी से आधे सेकंड में भर गया, और केवल उसी क्षण हम समझते हैं कि हमें नीचे स्विच करने की आवश्यकता है।



लेकिन अब समस्या यह है कि हमारे पास 250 केबी बफर है जो 5 सेकंड के लिए प्रसारित किया जाएगा। हम पहले से ही पूरी तरह से पीछे हैं: हमें पहले पुराने डेटा को हटाने की जरूरत है, और उसके बाद ही नए और रूपांतरित लोग रियलटाइम के साथ पकड़ बनाएंगे।

क्या करें? यहां हमारा "समझौता त्रिकोण" सिर्फ प्रासंगिक है।

• हम प्रेषक बफर को कम कर सकते हैं, 0.5 सेकंड के बजाय - 0.1 सेकंड। लेकिन हम बैंडविड्थ खो रहे हैं, क्योंकि हम अक्सर "घबराएंगे" और नीचे स्विच करेंगे। इसके अलावा, टीसीपी इस तरह से काम करता है कि यदि आप एक प्रेषक बफर को आरटीटी से छोटा रखते हैं, तो आप चैनल के पूर्ण बैंडविड्थ का उपयोग नहीं कर सकते हैं, यह कई बार कम हो जाएगा।
• हम रिसीवर बफर बढ़ा सकते हैं। एक बड़े बफर के साथ, डेटा आता है, हम बफर के भीतर कुछ अनियमितताओं को सुचारू कर सकते हैं। लेकिन, निश्चित रूप से, हम कम विलंबता खो रहे हैं, क्योंकि हम तुरंत 5 सेकंड का बफर सेट करते हैं।
• हम पुराने डेटा को आक्रामक रूप से छोड़ सकते हैं। टीसीपी में, इसके लिए एकमात्र विकल्प कनेक्शन को तोड़ना और इसे फिर से बनाना है। हम विश्वसनीयता खो देते हैं, क्योंकि इस समय खिलाड़ी के पास दिखाने के लिए कुछ नहीं है।

WebRTC

यह एक C ++ पुस्तकालय है जो पहले से ही अनुभव को ध्यान में रखता है और UDP के शीर्ष पर चलता है। IOS, Android के तहत बनाता है, ब्राउज़र में बनाया गया है, HTML5 का समर्थन करता है। चूंकि यह पी 2 पी कॉल के लिए कैद है, इसलिए देरी 0.1-1 सेकंड है।



Minuses की: यह एक अखंड पुस्तकालय है जिसमें विरासत की बहुतायत है जिसे हटाया नहीं जा सकता है। इसके अलावा, पी 2 पी कॉल पर ध्यान केंद्रित करने के कारण, यह कम विलंबता को प्राथमिकता देता है। ऐसा लगता है कि हम यह चाहते थे, लेकिन इसके लिए वह अन्य मापदंडों का त्याग करती है। और प्राथमिकताएं बदलने के लिए कोई सेटिंग्स नहीं हैं।

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

क्या चुनें - RTMP या WebRTC? हमने दोनों प्रोटोकॉल लागू किए और विभिन्न परिदृश्यों में उनका परीक्षण किया। ग्राफ पर, WebRTC में देरी कम है, लेकिन कम थ्रूपुट है, जबकि RTMP के विपरीत है। और उनके बीच एक छेद है।

और हम एक ऐसा प्रोटोकॉल बनाना चाहते थे जो इस छेद को पूरी तरह से कवर करे और वेबआरटीसी और आरटीएमपी मोड दोनों में काम कर सके। उन्होंने इसे OKMP नाम दिया और बनाया।

OKMP

यह यूडीपी के लिए एक लचीला प्रोटोकॉल है।

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

यह क्या देता है? सबसे पहले, इसने हमें चैनलों को प्राथमिकता देने का अवसर दिया। हम कह सकते हैं कि नियंत्रण चैनल की उच्च प्राथमिकता है, ध्वनि मध्यम है, और वीडियो कम है। वीडियो घबराना और असमान वीडियो वितरण को छिपाने के लिए आसान है, और उपयोगकर्ता को ऑडियो के अप्रिय हकलाने की तुलना में वीडियो समस्याओं से कम समस्याएं हैं।



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

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

उदाहरण के लिए, ऑडियो के लिए, यह 1 सेकंड है, और वीडियो के लिए, 0.5 सेकंड। दहलीज अलग क्यों है? यह एक और प्राथमिकता तंत्र है। चूंकि यह हमारे लिए अधिक महत्वपूर्ण है कि ऑडियो सुचारू है, हम सबसे पहले वीडियो को छोड़ना शुरू करते हैं।

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



बेशक, यदि आप यूडीपी में अपने प्रोटोकॉल को लिखने का फैसला करते हैं, तो आप कुछ समस्याओं के साथ आएंगे। टीसीपी का उपयोग करके, हमें ऐसे तंत्र मिलते हैं जो हमें खुद यूडीपी पर लिखने होंगे:

• पैकटेटिंग / डिपैकिटाइज़िंग। आपको लगभग 1.5 KB के पैकेट में डेटा को काटने की जरूरत है ताकि वे MTU नेटवर्क में फिट हो सकें।
• पुन: क्रम। आप एक क्रम में पैकेट भेजते हैं, और उन्हें रास्ते में फिर से व्यवस्थित किया जाता है और दूसरे में आते हैं। इसे दूर करने के लिए, आपको पैकेज संख्या के साथ अनुक्रम सेट करना होगा, और उन्हें रिसीवर पर पुनर्व्यवस्थित करना होगा।
• घाटा। बेशक, नुकसान हैं। जब नुकसान होता है, तो रिसीवर को प्रेषक को अलग से बताना होगा कि "मुझे ये पैकेट मिले, लेकिन ये नहीं मिले", और प्रेषक को लापता पैकेट को फिर से भेजना चाहिए। या उन्हें गिरा दो।
• प्रवाह नियंत्रण यदि प्राप्तकर्ता डेटा प्राप्त नहीं करता है, तो उस गति के साथ नहीं रहता है जिसके साथ हम इसे हिलाते हैं, डेटा खोना शुरू हो सकता है, हमें इस स्थिति को संसाधित करना होगा। टीसीपी के मामले में, भेजने वाले सॉकेट को अवरुद्ध किया जाएगा, और यूडीपी के मामले में इसे अवरुद्ध नहीं किया जाएगा, आपको खुद समझना होगा कि रिसीवर डेटा प्राप्त नहीं कर रहा है, और भेजे गए डेटा की मात्रा को कम करें।
• भीड़ नियंत्रण। इसी तरह की बात, केवल इस मामले में नेटवर्क की मृत्यु हो गई। यदि हम मृत नेटवर्क को पैकेट भेजते हैं, तो हम न केवल हमारे कनेक्शन को नष्ट कर देंगे, बल्कि पड़ोसी को भी नष्ट कर देंगे।
• एन्क्रिप्शन। एन्क्रिप्शन की देखभाल करने की आवश्यकता है
• ... और भी बहुत कुछ

OKMP बनाम RTMP

जब हमने RTMP के बजाय OKMP का उपयोग करना शुरू किया तो हमें क्या मिला?

• OKLive बिटरेट में औसत वृद्धि 30% है।
• जीटर (असमान पैकेट आगमन का माप) - 0% (औसतन समान)।
• जिटर ऑडियो - -25%
• जिटर वीडियो - 40%

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

स्ट्रीमिंग के लिए एक प्रोटोकॉल कैसे चुनें

यदि आपको निम्न विलंबता की आवश्यकता है - WebRTC

यदि आप बाहरी सेवाओं के साथ काम करना चाहते हैं, तो तृतीय पक्ष सेवाओं पर वीडियो प्रकाशित करें, आपको RTMP का उपयोग करना होगा।

यदि आप अपनी स्क्रिप्ट के अनुरूप एक प्रोटोकॉल चाहते हैं - तो अपना स्वयं का कार्यान्वयन करें।