वीडियो कॉल के लिए कौन से वीडियो कोडेक्स (नहीं) ब्राउज़र का उपयोग करते हैं?

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

कोडेक और चैनल चौड़ाई

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

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

1. पास # 1: वीडियो को सामान्य विशेषताओं के साथ भागों में विभाजित किया गया है: कार्रवाई एक ही पृष्ठभूमि, तेज या धीमे दृश्य, और पसंद पर होती है।
2. पास # 2: समय के साथ फ्रेम कैसे बदलते हैं और इस तरह की जानकारी प्राप्त करने के लिए, आपको कई फ्रेम की आवश्यकता होती है, इस पर कोडिंग और जानकारी के लिए आंकड़े एकत्र करें।
3. पास नंबर 3: प्रत्येक भाग अपनी स्वयं की कोडेक सेटिंग्स के साथ एन्कोड किया गया है और दूसरे चरण में प्राप्त जानकारी का उपयोग कर रहा है।

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

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

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

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

अब कोडेक्स के बारे में क्या?

• H.264 और VP8 वीडियो की गुणवत्ता और प्रयुक्त चैनल चौड़ाई के अनुपात के मामले में लगभग समान हैं;
• H.265 और VP9 भी मोटे तौर पर एक-दूसरे से मेल खाते हैं, पिछली पीढ़ी के कोडेक्स की तुलना में औसत 30% बेहतर परिणाम दिखाते हुए, प्रोसेसर लोड में 20% की वृद्धि के कारण;
• नया AV1 कोडेक, VP10, डाला और थोर का एक विस्फोटक मिश्रण, पिछली पीढ़ी के कोडेक की तुलना में बेहतर है जितना कि उनके पूर्ववर्तियों की तुलना में बेहतर है।

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

कोडेक और मीडिया इंजन: सब कुछ जटिल है

वीडियो कॉल और वीडियो कॉन्फ्रेंसिंग में पारंपरिक मीडिया के लगभग समान कार्य हैं। केवल प्राथमिकताएं पूरी तरह से अलग हैं:

1. यह प्रति सेकंड 30 फ्रेम लेता है (कोडेक गति)।
2. अन्तरक्रियाशीलता (न्यूनतम विलंब) के साथ प्रति सेकंड 30 फ्रेम की आवश्यकता होती है।

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

1. जब एक और आगंतुक सहकर्मी आता है तो आपको चैनल की चौड़ाई में छोटे बदलावों का अच्छी तरह से अनुभव करने की आवश्यकता होती है।
2. जब यह आगंतुक टॉरेंट डाउनलोड करना शुरू करता है, तो आपको कम से कम किसी तरह चैनल की चौड़ाई में मजबूत बदलावों का अनुभव करने की आवश्यकता होती है।
3. आपको घबराहट के बारे में चिंता करने की ज़रूरत है (प्राप्त पैकेटों के बीच यादृच्छिक देरी, जिसके कारण वे न केवल देरी कर सकते हैं, बल्कि उस गलत क्रम में पहुंच सकते हैं जिसमें उन्हें भेजा गया था)।
4. पैकेट नुकसान के बारे में चिंता करने की जरूरत है।

3.1। मीडिया इंजन के मुख्य कार्य

"प्रति सेकंड 30 फ्रेम" की क्या आवश्यकता है? इसका मतलब यह है कि मीडिया इंजन में कैमरा, माइक्रोफ़ोन साउंड से वीडियो कैप्चर करने के लिए 33 मिलीसेकंड है, इसे एक कोडेक से संपीड़ित करें, इसे RTP पैकेट में विभाजित करें, प्रेषित डेटा (SRTP = RTP + AES) को सुरक्षित रखें और इसे नेटवर्क (UDP या TCP) पर भेजें UDP के अधिकांश मामलों में)। यह सब भेजने की ओर है। और प्राप्त पक्ष पर - रिवर्स ऑर्डर में दोहराएं। चूंकि एन्कोडिंग आमतौर पर डिकोडिंग की तुलना में अधिक कठिन होता है, इसलिए भेजने का समय कठिन होता है।

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

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

3.2। मीडिया इंजन और सार्वजनिक नेटवर्क

चैनल की चौड़ाई में छोटे बदलाव

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

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

चैनल की चौड़ाई में बड़े बदलाव

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

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

घबराना और पैकेट खोना

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

पैकेट लॉस आमतौर पर रि-फॉरवर्डिंग (RTX) से लड़ा जाता है। यदि प्रेषक के पास एसएफयू के साथ अच्छा संचार है, तो सर्वर एक खोए हुए पैकेट का अनुरोध कर सकता है, इसे पुनः प्राप्त कर सकता है और अभी भी 33 मिलीसेकंड को पूरा कर सकता है। यदि नेटवर्क कनेक्शन अविश्वसनीय है (0.01% से अधिक पैकेट हानि), तो हमें जटिल नुकसान के काम के एल्गोरिदम की आवश्यकता है, जैसे कि एफईसी ।

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

अब कौन से ब्राउज़र समर्थन करते हैं

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

Kat से पहले, एक तालिका जिसकी तुलना पूरी तरह से होती है, जो समर्थन करती है, लेकिन सामान्य तौर पर, सब कुछ काफी सरल है। आमतौर पर एज को हर कोई नजरअंदाज कर देता है। चुनाव सफारी के मोबाइल संस्करण और अच्छी वीडियो गुणवत्ता का समर्थन करने के बीच है। iOS सफारी केवल H.264 वीडियो कोडेक का समर्थन करता है, जबकि libwebrtc केवल VP8 कोडेक्स (विभिन्न फ्रेम दर के साथ अलग-अलग स्ट्रीम) और VP9 (SVC समर्थन) के साथ simulcast की अनुमति देता है। लेकिन आप देशी एप्लिकेशन बनाकर iOS पर libwebrtc को पढ़ और उपयोग कर सकते हैं। फिर, सिमुलकास्ट के साथ, सबकुछ ठीक हो जाएगा और उपयोगकर्ताओं को अस्थिर इंटरनेट कनेक्शन के साथ उच्चतम संभव वीडियो गुणवत्ता प्राप्त होगी। कुछ उदाहरण:

• हाइफ़ाइव - एच .264 सिमुलकास्ट (लिबवेब्र्टक) और डॉल्बी के साउंड कोडेक्स के साथ इलेक्ट्रॉन (क्रोमियम) पर एक डेस्कटॉप एप्लिकेशन;
• एटलसियन - सिमुलकास्ट के लिए रिएक्टिव नेटिव और लिबवेब्रेटक पर क्लाइंट द्वारा एक दिलचस्प समाधान;
• सिम्फनी - डेस्कटॉप के लिए इलेक्ट्रॉन, मोबाइल उपकरणों के लिए रिएक्टिव नेटिव, और सिमुलकास्ट वहाँ समर्थित है और वहाँ + अतिरिक्त सुरक्षा सुविधाएँ जो बैंक चाहते हैं के साथ संगत हैं;
• Tokbox - VP8 मोबाइल SDK में सिमुलकास्ट के साथ, libvbrtc में libvpx के पैच किए गए संस्करण का उपयोग करें।

भविष्य

यह पहले से ही स्पष्ट है कि सफारी में कोई वीपी 8 और वीपी 9 नहीं होगा (एज के विपरीत, जो वीपी 8 का समर्थन करता है)।

हालाँकि Apple ने WebRTC में H.265 को शामिल करने का समर्थन किया है, हालिया समाचार और कई परोक्ष संकेत "अगली बड़ी बात" के रूप में AV1 को इंगित करते हैं। बाकी लेख के विपरीत, यह मेरी निजी राय है। डेटा ट्रांसमिशन AV1 के लिए युक्ति पहले से ही तैयार है, लेकिन काम अभी भी कोडेक पर चल रहा है। अब एनकोडर के संदर्भ कार्यान्वयन में प्रति सेकंड एक दुखद 0.3 फ्रेम दिखाई देता है। प्री-कंप्रेस्ड कंटेंट को खेलते समय यह कोई समस्या नहीं है, लेकिन रियलटाइम कम्युनिकेशंस पर अभी तक लागू नहीं है। इस बीच, आप फ़ायरफ़ॉक्स में AV1 वीडियो चलाने की कोशिश कर सकते हैं, हालांकि यह RTC से संबंधित नहीं है। बिटमोइन टीम से कार्यान्वयन, जिसने एमपीईजी-डीएएचएस विकसित किया और वीडियो के साथ काम करने के लिए अगली पीढ़ी के बुनियादी ढांचे के निर्माण में 30 मिलियन निवेश प्राप्त किया।