एक मीडिया सर्वर में WebRTC को लागू करना - अभ्यास और नीति

1. वास्तविक समय में ब्राउज़रों के लिए स्ट्रीमिंग - कोई समाधान नहीं। या है?

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

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

यहां आरटीएसपी है - बहुत सारे कंसोल और पेशेवर उपकरण इसे खेलते हैं, लेकिन ब्राउज़र नहीं खेलते हैं। यहाँ RTMP - Safari इसे iOS पर नहीं खेलना चाहता है और सभी Android इसे नहीं खेलते हैं। क्रोम इसे अविश्वास के रूप में प्रतिबंधित करता है। यहाँ MPEG2-TS है - ब्राउज़र इसे नहीं खेलते हैं। HTML5 मीडिया स्रोत एक्सटेंशन (MSE) - वीडियो सेगमेंट के लिए 5-10 सेकंड लंबा (यानी HLS / डैश के लिए) अच्छा है, लेकिन छोटे खंडों के लिए एक सेकंड से कम - हमेशा स्थिर नहीं, अलग-अलग ब्राउज़रों में अलग-अलग तरीके से काम करता है और फिर से iOS पर समर्थित नहीं है।

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

चलो "वास्तविक समय के करीब" की अवधारणा को परिभाषित करते हैं। यह वीडियो निगरानी के लिए 5 सेकंड से कम देरी और वीडियो कॉन्फ्रेंसिंग के लिए 1 सेकंड से भी कम है। एचएलएस प्रोटोकॉल की औसत देरी 20-30 सेकंड है। हो सकता है कि यह किसी तरह किंडरगार्टन के लिए उपयुक्त हो, लेकिन सुरक्षा वीडियो निगरानी, ​​वीडियो कॉन्फ्रेंसिंग और वेबिनार के लिए, एक और तकनीक की आवश्यकता है।

इसलिए, अब तक, 2017 की गर्मियों तक अधिक सटीक रूप से, वास्तविक समय में किसी भी डिवाइस पर किसी भी ब्राउज़र में ऑडियो-वीडियो प्रसारित करने के लिए कोई एकल मानक या प्रोटोकॉल नहीं था। इस स्थिति के कारण, हम इस लेख में बाद में विचार करेंगे। वे तकनीकी प्रकृति के नहीं हैं, ये कारण हैं। इस बीच, आइए देखें कि 2017 की गर्मियों में क्या हुआ, जो बहुत कम से कम है, लेकिन फिर भी एक ऐसी तकनीक प्रदान की गई है जो हमें उपरोक्त समस्याओं को हल करने की अनुमति देती है। यह तकनीक WebRTC है, इस संसाधन और सामान्य रूप से नेटवर्क पर इसके बारे में बहुत कुछ लिखा गया है। इसे अब पूरी तरह से नया नहीं कहा जा सकता है, और इस लेखन के समय, डब्ल्यू 3 सी वेबआरटीसी 1.0 को एक पूर्ण परियोजना मानता है। हम यहां पर बात नहीं करेंगे कि WebRTC क्या है; अगर पाठक इस तकनीक से परिचित नहीं है, तो हम हब या गूगल पर एक खोज करने और परिचित होने का सुझाव देते हैं,इसका उपयोग किस लिए किया जाता है और यह सामान्य शब्दों में कैसे काम करता है। यहां हम केवल यह कहते हैं कि यह तकनीक ब्राउज़र में पीयर-टू-पीयर संचार के लिए विकसित की गई थी, इसके साथ आप बिना किसी सर्वर के वीडियो चैट और वॉयस एप्लिकेशन को लागू कर सकते हैं - ब्राउज़र सीधे ब्राउज़र के साथ संचार करता है। WebRTC सभी उपकरणों पर सभी ब्राउज़रों द्वारा समर्थित है, और 2017 की गर्मियों में, Apple अंत में हमारे पास आया और इसे iOS पर अपनी सफारी में जोड़ दिया। यह वह घटना थी जिसने 2015 में शुरू होने वाले RTMP के सूर्यास्त के बाद से वेबआरटीसी को ब्राउज़रों के लिए वास्तविक समय की स्ट्रीमिंग के लिए सबसे सार्वभौमिक और आम तौर पर स्वीकृत तकनीक बना दिया।WebRTC सभी उपकरणों पर सभी ब्राउज़रों द्वारा समर्थित है, और 2017 की गर्मियों में, Apple अंत में हमारे पास आया और इसे iOS पर अपनी सफारी में जोड़ दिया। यह वह घटना थी जिसने 2015 में शुरू होने वाले RTMP के सूर्यास्त के बाद से वेबआरटीसी को ब्राउज़रों के लिए वास्तविक समय की स्ट्रीमिंग के लिए सबसे सार्वभौमिक और आम तौर पर स्वीकृत तकनीक बना दिया।WebRTC सभी उपकरणों पर सभी ब्राउज़रों द्वारा समर्थित है, और 2017 की गर्मियों में, Apple अंत में हमारे पास आया और इसे iOS पर अपनी सफारी में जोड़ दिया। यह वह घटना थी जिसने 2015 में शुरू होने वाले RTMP के सूर्यास्त के बाद से वेबआरटीसी को ब्राउज़रों के लिए वास्तविक समय की स्ट्रीमिंग के लिए सबसे सार्वभौमिक और आम तौर पर स्वीकृत तकनीक बना दिया।

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

तो, आखिरकार सब कुछ बन गया था? अकुना माटाटा और बालवाड़ी इस तरह के मीडिया सर्वर को होस्टिंग या एडब्ल्यूएस पर कहीं भी स्थापित करने में सक्षम होंगे, वहां प्रत्येक कैमरे से एक स्ट्रीम भेजेंगे, और वहां से यह पहले से ही माता-पिता के ब्राउज़रों को वितरित किया जाएगा, सभी एक से अधिक सेकंड की देरी के साथ। सामान्य तौर पर - हाँ, जीवन बेहतर हो रहा है। लेकिन समस्याएं हैं। और ये समस्याएँ इस तथ्य से संबंधित हैं कि WebRTC है, जैसा कि इस तरह के कार्यों के लिए दूर की कौड़ी थी, यह उनके लिए डिज़ाइन नहीं किया गया था और उनके लिए बिल्कुल उपयुक्त नहीं था। कोडेक संगतता के अलावा समस्याएं, मुख्य रूप से ऐसे मीडिया सर्वर की मापनीयता के साथ मौजूद हैं। यही है, एक ही समय में एक सर्वर कंप्यूटर से 100 माता-पिता की सेवा की जा सकती है, और 500 पहले से ही मुश्किल है। हालांकि नेटवर्क अनुमति देता है। और 100 कनेक्शन वाले सर्वर पर प्रोसेसर लोड को देखें - यह पहले से ही 90% के करीब है। ऐसा कैसे? सब के बाद, बस एक ध्वनि वीडियो भेजें।

उसी स्ट्रीम के साथ, यदि फ़्लैश प्लेयर को RTMP प्रोटोकॉल के माध्यम से भेजा जाता है, तो आप आसानी से एक सर्वर से 2000 एक साथ कनेक्शन का समर्थन कर सकते हैं। क्या WebRTC केवल 100 है?
क्यों? इसके दो कारण हैं: पहला, वेबआरटीसी प्रोटोकॉल बहुत अधिक कम्प्यूटेशनल रूप से महंगा है - वहाँ, उदाहरण के लिए, सभी डेटा एन्क्रिप्ट किया गया है, और इसमें बहुत अधिक प्रोसेसर समय लगता है। और दूसरा कारण, जिस पर हम और अधिक विस्तार से चर्चा करेंगे, वह है इसके निर्माता द्वारा प्रोटोकॉल का अत्यंत अकुशल कार्यान्वयन - Google, जो सर्वर, गेटवे और अन्य अनुप्रयोगों में अनुकूलन के लिए इस कार्यान्वयन के लिए स्रोत c ++ कोड प्रदान करता है जो WebTCTC का समर्थन करना चाहते हैं: webrtc.org/native-code

2 कारण Google की मूल WebRTC API और मीडिया सर्वर संगतता

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

आइए उन मुख्य बिंदुओं पर गौर करें जिनकी वजह से मीडिया सर्वरों के लिए WebRTC के Google कार्यान्वयन का उपयोग अत्यंत समस्याग्रस्त है।

2.A कोड होना चाहिए की तुलना में 10 गुना अधिक है और यह बेहद अक्षम है।

यह एक सिद्ध संख्या है। आरंभ करने के लिए, आप लगभग 5 गीगाबाइट कोड डाउनलोड करते हैं, जिनमें से केवल 500 मेगाबाइट वेबआरटीसी के लिए प्रासंगिक हैं। फिर आप अनावश्यक कोड से छुटकारा पाने की कोशिश करते हैं। आखिरकार, मीडिया सर्वर की जरूरतों के लिए आपको एन्कोडिंग / डिकोडिंग की आवश्यकता नहीं है; सर्वर को केवल सामग्री प्राप्त करनी चाहिए और इसे सभी को अग्रेषित करना चाहिए। जब आपने उन सभी अनावश्यक को हटा दिया जो आप कर सकते थे (और आप जितना चाहें उतना कम निकाल सकते हैं), आपके पास अभी भी 100 मेगाबाइट कोड है। यह एक राक्षसी आकृति है। यह वह है जो उससे 10 गुना बड़ा है।

वैसे, इस बिंदु पर, कई कहेंगे - एन्कोडिंग / डिकोडिंग की आवश्यकता कैसे नहीं है? AAC से Opus और इसके विपरीत ट्रांसकोडिंग के बारे में क्या? VP9-> H264 ट्रांसकोडिंग के बारे में क्या? यदि आप सर्वर पर ऐसे ट्रांसकोडिंग करने जा रहे हैं, तो आप 5 एक साथ कनेक्शन भी नहीं खींच सकते। यदि यह वास्तव में आवश्यक है, तो ट्रांसकोडिंग एक मीडिया सर्वर द्वारा नहीं, बल्कि किसी अन्य प्रोग्राम द्वारा की जानी चाहिए।

लेकिन चलो फूला हुआ कोड की समस्या पर वापस जाएं और इसे स्पष्ट करें। आपको क्या लगता है कि पहले से ही संपीड़ित वीडियो फ़्रेम भेजने पर फ़ंक्शन कॉल स्टैक की गहराई क्या है? सेंड या सेंड फंक्शन (WSASend / WSASendTo) के विंडोस पर एक कॉल? नहीं, बेशक, कुछ और काम किए जाने की जरूरत है। WebRTC के मामले में, आपको RTP प्रोटोकॉल पर फ्रेम को पैक करना होगा और इसे एन्क्रिप्ट करना होगा, जो कुल मिलाकर हमें SRTP प्रोटोकॉल देता है। पैकेट क्षति के मामले में फ्रेम को बचाने के लिए आवश्यक है ताकि इसे बाद में फिर से भेजा जा सके। इसमें कितने c ++ ऑब्जेक्ट और थ्रेड शामिल होने चाहिए?

यहां बताया गया है कि वेबआरटीसी 61



यह कैसे करता है : जैसा कि आप इस स्क्रीनशॉट से देख सकते हैं, जिस क्षण से हम वेबआरटीसी को संपीड़ित फ्रेम खिलाते हैं, जब तक हम इसे Paced_Sender ऑब्जेक्ट कतार में नहीं डालते, कॉल स्टैक गहराई 8 (!) है और 7 ऑब्जेक्ट शामिल हैं।

फिर एक अलग थ्रेड (थ्रेड) PacedSender कतार से हमारे फ्रेम को खींचता है और इसे आगे की प्रक्रिया के लिए भेजता है:



और अंत में, हम चरण 4 में आए, जहां पहले से ही आरटीपी-पैक और एन्क्रिप्टेड फ्रेम नेटवर्क पर भेजे जाने के लिए कतार पर निर्भर करता है, जो दूसरे धागे में लगा हुआ है। इस बिंदु पर, कॉल स्टैक (PacedSender थ्रेड पर) की गहराई 7 है, और 3 और नई वस्तुएं शामिल हैं। भेजने में व्यस्त थ्रेड अंतिम WSASend / WSASendTo को 3-4 नेस्टेड फ़ंक्शन कॉल के बाद भी कॉल करेगा और इसमें 3-4 और नए ऑब्जेक्ट शामिल होंगे।

इसलिए, हमने 3 धागे देखे, जिनमें से प्रत्येक एक बहुत अच्छा काम करता है। ऐसे सिस्टम को प्रोग्राम करने वाले हर व्यक्ति को इस बात का अंदाजा होता है कि इस तरह की चीजें कैसे की जाती हैं और वास्तव में क्या करने की जरूरत है। हमारे अनुमानों के अनुसार, कम से कम 90% वस्तुएं और कोड यहां अतिरंजित हैं और ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के सिद्धांतों का उल्लंघन करते हैं।

2. बी 4-5 धागे प्रति कनेक्शन आवंटित किए जाते हैं

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

2.c एसिंक्रोनस सॉकेट्स विंडोज़ संदेशों के माध्यम से काम कर रहा है

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

2. डी निष्कर्ष

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

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

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

3. सब कुछ इतना दुखी क्यों है

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

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

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

इसलिए, चूंकि स्ट्रीमिंग-शिमिंग के बिना इसे प्राप्त करना काफी संभव है, इसलिए इसे निजी व्यवसाय की दया पर छोड़ दिया जाता है। जो इसे अपने हितों में विकसित करता है, न कि उपभोक्ता के हितों में। यह उपभोक्ता के हितों में कैसे नहीं है? लेकिन आपूर्ति और मांग के बारे में क्या? उपभोक्ता को क्या चाहिए, फिर व्यवसाय की पेशकश करेगा? लेकिन यह पेश नहीं करता है। सभी उपभोक्ता चिल्ला रहे हैं - Google, WebRTC में AAC ऑडियो का समर्थन करता है, लेकिन Google कभी भी ऐसा नहीं करेगा, हालांकि यह सिर्फ करने के लिए खर्च करता है। Apple पूरी तरह से एक लानत नहीं देता है और न ही अपने गैजेट में बहुत जरूरी स्ट्रीमिंग तकनीकों से कुछ भी लागू करता है। क्यों? हां, क्योंकि हमेशा व्यापार वह नहीं करता है जो उपभोक्ता को चाहिए। वह ऐसा नहीं करता है जब वह एक एकाधिकारवादी हो और उपभोक्ता को खोने का डर न हो। फिर व्यवसाय अपनी स्थिति मजबूत करने में व्यस्त है। इसलिए Google ने हाल के वर्षों में साउंड कोडेक्स के निर्माताओं का एक समूह खरीदा।और अब यह ओपस ऑडियो को धक्का देता है, और पूरी दुनिया को AAC-> ओपस को वेबआरटीसी से मिलान करने के लिए मजबूर करता है, क्योंकि सभी तकनीक लंबे समय से एएसी ऑडियो पर स्विच कर चुकी हैं। Google इसे इस तथ्य से उचित ठहराता है कि AAC एक प्रदत्त तकनीक है, और ओपस स्वतंत्र है। लेकिन वास्तव में, यह एक मानक के रूप में अपनी प्रौद्योगिकी स्थापित करने के लिए किया जाता है। जैसा कि ऐप्पल ने एक बार अपने मनहूस एचएलएस के साथ किया था, जिसे हम प्यार करते थे, या जैसा कि एडोब ने अपने गैर जिम्मेदार आरएमएमपी प्रोटोकॉल के साथ पहले भी किया था। गैजेट और ब्राउज़र अभी भी विकसित करने के लिए काफी तकनीकी रूप से कठिन चीजें हैं, यहां से एकाधिकार प्राप्त होता है, यहां से, जैसा कि वे कहते हैं, चीजें हैं। और डब्ल्यू 3 सी और आईईटीएफ को एक ही एकाधिकारवादियों द्वारा प्रायोजित किया जाता है, इसलिए "चलो तकनीकी रूप से सही और मजबूत तकनीक बनाते हैं ताकि लोग इसका उपयोग कर सकें और सबकुछ ठीक हो" और ऐसा कभी नहीं होगा।लेकिन यह होना चाहिए था।

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

4. मीडिया सर्वर के बारे में थोड़ा सा जो WebRTC

Wowza, Flashphoner, Kurento, Flussonic, Red5 Pro, Unreal Media Server को लागू करता है - ये कुछ ऐसे मीडिया सर्वर हैं जो WebRTC का समर्थन करते हैं। वे ब्राउज़र से सर्वर पर वीडियो का प्रकाशन प्रदान करते हैं और सर्वर से वेबआरटीसी के माध्यम से ब्राउज़र में वीडियो प्रसारित करते हैं।

इस लेख में वर्णित समस्याएं, अलग-अलग तरीकों से और सफलता की अलग-अलग डिग्री के साथ, इन सॉफ्टवेयर उत्पादों में हल की जाती हैं। उनमें से कुछ, उदाहरण के लिए, Kurento और Wowza, सर्वर में सीधे ऑडियो-वीडियो ट्रांसकोडिंग करते हैं, अन्य, उदाहरण के लिए, Unreal Media Server, खुद को ट्रांसकोड नहीं करते हैं, लेकिन इसके लिए अन्य प्रोग्राम प्रदान करते हैं। कुछ सर्वर, जैसे कि Wowza और Unreal Media Server, एक सेंट्रल टीसीपी और UDP पोर्ट के माध्यम से सभी कनेक्शनों पर स्ट्रीमिंग का समर्थन करते हैं, क्योंकि WebRTC स्वयं प्रत्येक कनेक्शन के लिए एक अलग पोर्ट आवंटित करता है, इसलिए प्रदाता को फ़ायरवॉल में कई पोर्ट खोलने पड़ते हैं, जिससे सुरक्षा समस्याएं होती हैं।

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