Skype देखि WebRTC सम्म: हामीले कसरी वेब मार्फत भिडियो संचार व्यवस्थित गर्यौं

भिमबक्स प्लेटफर्ममा शिक्षक र विद्यार्थी बीचको सञ्चारको मुख्य माध्यम भिडियो सञ्चार हो। हामीले लामो समय पहिले स्काइप छोड्यौं, धेरै तेस्रो-पक्ष समाधानहरू प्रयास गर्यौं र अन्ततः WebRTC - Janus-gateway संयोजनमा बस्यौं। केही समय हामी सबै कुरामा खुसी थियौं, तर पनि केही नकारात्मक पक्षहरू बाहिर आउन थाले। नतिजाको रूपमा, एक अलग भिडियो निर्देशन सिर्जना गरिएको थियो।

मैले नयाँ दिशाका प्रमुख किरिल रोगोभोयलाई स्काइङमा भिडियो सञ्चारको विकास, पत्ता लागेका समस्याहरू, समाधानहरू र हामीले अन्ततः प्रयोग गर्ने बैसाखीको बारेमा कुरा गर्न आग्रह गरें। हामी आशा गर्दछौं कि लेख कम्पनीहरूका लागि उपयोगी हुनेछ जसले वेब अनुप्रयोग मार्फत आफ्नै भिडियो सिर्जना गर्दछ।

बिटको इतिहास

2017 को ग्रीष्ममा, Skyeng विकास प्रमुख, Sergey Safonov, Backend Conf मा हामीले कसरी "Skype छोड्यौं र WebRTC लागू गर्यौं" भन्ने बारे एउटा कथा बोले। इच्छुकहरूले भाषणको रेकर्डिङ यहाँ हेर्न सक्नुहुन्छ लिङ्क (~ 45 मिनेट), र यहाँ म यसको सारलाई संक्षिप्त रूपमा रूपरेखा गर्नेछु।

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

वास्तवमा, भिडियो सञ्चारका लागि हाम्रा आवश्यकताहरू लगभग निम्न थिए:
- स्थिरता;
- प्रति पाठ कम मूल्य;
- रेकर्डिङ पाठ;
- कसले कति बोल्छ भनेर ट्र्याक गर्दै (यो हाम्रो लागि महत्त्वपूर्ण छ कि विद्यार्थीहरूले पाठको समयमा शिक्षक भन्दा बढी बोल्छन्);
- रैखिक स्केलिंग;
- UDP र TCP दुबै प्रयोग गर्ने क्षमता।

पहिलो प्रयास 2013 मा Tokbox लागू गर्न को लागी थियो। सबै कुरा राम्रो थियो, तर यो धेरै महँगो भयो - प्रति पाठ 113 रूबल - र नाफा खायो।

त्यसपछि 2015 मा, Voximplant एकीकृत गरियो। यहाँ हामीलाई कसले कति बोल्यो ट्र्याक गर्न आवश्यक थियो, र एकै समयमा समाधान धेरै सस्तो थियो: यदि केवल अडियो रेकर्ड गरिएको थियो भने, यो प्रति पाठ 20 rubles खर्च हुन्छ। यद्यपि, यसले UDP मार्फत मात्र काम गर्‍यो र TCP मा स्विच गर्न सकेन। यद्यपि, लगभग 40% विद्यार्थीहरूले यसलाई प्रयोग गरे।

एक वर्ष पछि, हामीसँग कर्पोरेट ग्राहकहरू तिनीहरूको आफ्नै विशिष्ट आवश्यकताहरूसँग हुन थाले। उदाहरणका लागि, सबै कुरा ब्राउजर मार्फत काम गर्नुपर्छ; कम्पनीले http र https मात्र खोल्छ; अर्थात् स्काइप वा UDP छैन। कर्पोरेट ग्राहकहरू = पैसा, त्यसैले तिनीहरू टोकबक्समा फर्किए, तर मूल्यको समस्या हटेन।

समाधान - WebRTC र Janus

प्रयोग गर्ने निर्णय गरेको छ पियर-टू-पीयर भिडियो संचार WebRTC को लागि ब्राउजर प्लेटफर्म। यो जडान स्थापना गर्न, एन्कोडिङ र डिकोडिङ स्ट्रिमहरू, ट्र्याकहरू सिङ्क्रोनाइज गर्ने र नेटवर्क ग्लिचहरू ह्यान्डल गर्ने गुणस्तर नियन्त्रणको लागि जिम्मेवार छ। हाम्रो पक्षको लागि, हामीले क्यामेरा र माइक्रोफोनबाट स्ट्रिमहरू पढ्ने, भिडियो कोर्ने, जडान व्यवस्थापन गर्ने, WebRTC जडान स्थापना गर्ने र यसमा स्ट्रिमहरू प्रसारण गर्ने, साथै जडान स्थापना गर्न ग्राहकहरू बीच सिग्नलिङ सन्देशहरू प्रसारण गर्ने सुनिश्चित गर्नुपर्छ (WebRTC आफैंले मात्र वर्णन गर्दछ। डाटा ढाँचा, तर यसको संयन्त्र स्थानान्तरण होइन)। यदि ग्राहकहरू NAT पछि छन् भने, WebRTC ले STUN सर्भरहरू जडान गर्दछ; यदि यसले मद्दत गर्दैन भने, सर्भरहरू टर्न गर्नुहोस्।

नियमित p2p जडान हाम्रो लागि पर्याप्त छैन, किनकि हामी गुनासोहरूको अवस्थामा थप विश्लेषणको लागि पाठहरू रेकर्ड गर्न चाहन्छौं। त्यसैले हामी WebRTC स्ट्रिमहरू रिले मार्फत पठाउँछौं मीटेको द्वारा जानस गेटवे। नतिजाको रूपमा, ग्राहकहरू एक-अर्काको ठेगानाहरू जान्दैनन्, केवल जानस सर्भर ठेगाना हेरेर; यसले सिग्नल सर्भरको कार्यहरू पनि गर्दछ। जानससँग हामीलाई चाहिने धेरै सुविधाहरू छन्: यदि ग्राहकले UDP रोकेको छ भने स्वचालित रूपमा TCP मा स्विच हुन्छ; दुबै UDP र TCP स्ट्रिमहरू रेकर्ड गर्न सक्छ; स्केलेबल; त्यहाँ इको परीक्षणहरूको लागि निर्मित प्लगइन पनि छ। आवश्यक भएमा, Twilio बाट STUN र TURN सर्भरहरू स्वचालित रूपमा जडान हुन्छन्।

2017 को गर्मीमा, हामीसँग दुई जनास सर्भरहरू चलिरहेका थिए, साथै रेकर्ड गरिएका कच्चा अडियो र भिडियो फाइलहरू प्रशोधन गर्नका लागि अतिरिक्त सर्भरहरू थिए, ताकि मुख्यका प्रोसेसरहरू ओगट्न नपरोस्। जडान गर्दा, Janus सर्भरहरू बिजोर-विजन आधारमा (जडान नम्बर) चयन गरिएको थियो। त्यस समयमा, यो पर्याप्त थियो, हाम्रो भावना अनुसार, यसले लगभग चार गुणा सुरक्षा मार्जिन दियो, कार्यान्वयन प्रतिशत लगभग 80 थियो। एकै समयमा, मूल्य ~ 2 rubles प्रति पाठ, साथै विकास र समर्थनमा घटाइयो।

भिडियो संचार को विषय मा फर्किदै

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

त्यो समयमा, हाम्रो भिडियो संचार अझै MVP मोड मा थियो। सरल शब्दमा भन्नुपर्दा, तिनीहरूले यसलाई सुरु गरे, यसले काम गर्यो, तिनीहरूले यसलाई एक पटक मापन गरे, तिनीहरूले यो कसरी गर्ने भनेर बुझे - राम्रो, राम्रो। यदि यसले काम गर्छ भने, यसलाई ठीक नगर्नुहोस्। सञ्चारको गुणस्तरको मुद्दालाई कसैले पनि जानाजानी सम्बोधन गरेनन्। अगस्ट सम्म, यो जारी हुन सक्दैन भन्ने कुरा स्पष्ट भयो, र हामीले WebRTC र Janus मा के गल्ती थियो भनेर पत्ता लगाउन एउटा छुट्टै निर्देशन सुरु गर्यौं।

इनपुटमा, यो दिशा प्राप्त भयो: एक MVP समाधान, कुनै मेट्रिकहरू, कुनै लक्ष्यहरू, सुधारको लागि कुनै प्रक्रियाहरू छैनन्, जबकि 7% शिक्षकहरूले सञ्चारको गुणस्तरको बारेमा गुनासो गर्छन् (विद्यार्थीहरूमा पनि कुनै डाटा थिएन)।

नयाँ दिशाको काम भइरहेको छ

आदेश यस्तो देखिन्छ:

• विभाग प्रमुख, जो मुख्य विकासकर्ता पनि हो।
• QA ले परिवर्तनहरू परीक्षण गर्न मद्दत गर्दछ, अस्थिर सञ्चार अवस्थाहरू सिर्जना गर्न नयाँ तरिकाहरू खोज्छ, र अगाडि लाइनबाट समस्याहरू रिपोर्ट गर्दछ।
• विश्लेषकले निरन्तर प्राविधिक डेटामा विभिन्न सहसंबंधहरू खोज्छ, प्रयोगकर्ता प्रतिक्रियाको विश्लेषण सुधार गर्दछ, र प्रयोगहरूको नतिजा जाँच गर्दछ।
• उत्पादन प्रबन्धकले समग्र दिशा र प्रयोगहरूको लागि स्रोतहरूको आवंटनमा मद्दत गर्दछ।
• दोस्रो विकासकर्ताले प्राय: प्रोग्रामिङ र सम्बन्धित कार्यहरूमा मद्दत गर्दछ।

सुरु गर्नको लागि, हामीले एक अपेक्षाकृत भरपर्दो मेट्रिक सेट अप गर्यौं जसले सञ्चार गुणस्तर मूल्याङ्कनमा परिवर्तनहरू ट्र्याक गर्छ (औसत दिन, हप्ता, महिना)। त्यसबेला, यी शिक्षकहरूबाट ग्रेडहरू थिए; पछि विद्यार्थीहरूबाट ग्रेडहरू थपियो। त्यसपछि तिनीहरूले गलत काम गरिरहेको बारे परिकल्पनाहरू निर्माण गर्न थाले, यसलाई सच्याउनुहोस्, र गतिशीलतामा परिवर्तनहरू हेर्नुहोस्। हामी कम झुण्डिएको फलको लागि गयौं: उदाहरणका लागि, हामीले vp8 कोडेकलाई vp9 ले बदल्यौं, प्रदर्शन सुधार भयो। हामीले जेनुस सेटिङहरूसँग खेल्न र अन्य प्रयोगहरू सञ्चालन गर्ने प्रयास गर्यौं - धेरै जसो केसहरूमा तिनीहरूले केहि पनि नेतृत्व गरेनन्।

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

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

एल्गोरिथ्म पुन: गरिएको छ: अब, जब प्रयोगकर्ताले हाम्रो प्लेटफर्म खोल्छ, हामी Ajax प्रयोग गरेर सबै सर्भरहरूमा उहाँबाट पिंगहरू सङ्कलन गर्छौं। जडान स्थापना गर्दा, हामी सानो रकमको साथ पिङ (शिक्षक-सर्भर र विद्यार्थी-सर्भर) को एक जोडी चयन गर्छौं। कम पिङ भनेको सर्भरमा कम नेटवर्क दूरी हो; छोटो दूरी भनेको प्याकेटहरू हराउने कम सम्भावना; भिडियो संचारमा प्याकेट हानि सबैभन्दा ठूलो नकारात्मक कारक हो। नकारात्मकताको अंश तीन महिनामा आधाले घट्यो (निष्पक्ष हुन, अन्य प्रयोगहरू यस समयमा गरिएको थियो, तर यसले लगभग निश्चित रूपमा सबैभन्दा बढी प्रभाव पारेको थियो)।

हामीले भर्खरै अर्को गैर-स्पष्ट, तर स्पष्ट रूपमा महत्त्वपूर्ण कुरा पत्ता लगायौं: बाक्लो च्यानलमा एउटा शक्तिशाली जेनुस सर्भरको सट्टा, पातलो ब्यान्डविथको साथ दुईवटा सरल हुनु राम्रो हुन्छ। हामीले एकै समयमा धेरै कोठाहरू (सञ्चार सत्रहरू) क्र्याम गर्ने आशामा शक्तिशाली मेसिनहरू किने पछि यो स्पष्ट भयो। सर्भरहरूको ब्यान्डविथ सीमा हुन्छ, जसलाई हामीले कोठाको सङ्ख्यामा सही रूपमा अनुवाद गर्न सक्छौं - हामीलाई थाहा छ कतिवटा खोल्न सकिन्छ, उदाहरणका लागि, ३०० Mbit/s मा। सर्भरमा धेरै कोठाहरू खुल्ला हुने बित्तिकै, लोड कम नभएसम्म हामी यसलाई नयाँ गतिविधिहरूको लागि छनौट गर्न रोक्छौं। विचार यो थियो कि, एक शक्तिशाली मेसिन किनेपछि, हामी यसलाई अधिकतममा च्यानल लोड गर्नेछौं, ताकि अन्तमा यो प्रोसेसर र मेमोरी द्वारा सीमित हुनेछ, ब्यान्डविथ द्वारा होइन। तर यो बाहिर भयो कि खुल्ला कोठा (300) को निश्चित संख्या पछि, प्रोसेसर, मेमोरी र डिस्क मा लोड अझै पनि सीमा देखि धेरै टाढा छ भन्ने तथ्यको बावजुद, नकारात्मकता प्राविधिक समर्थन मा पुग्न सुरु हुन्छ। जानुस भित्र केहि नराम्रो हुँदैछ, सायद त्यहाँ पनि केही प्रतिबन्धहरू छन्। हामीले प्रयोग गर्न थाल्यौं, ब्यान्डविथ सीमा 420 बाट 300 Mbit/s मा घटायो, र समस्याहरू हट्यो। अब हामीले कम सीमा र विशेषताहरूसँग एकैचोटि तीनवटा नयाँ सर्भरहरू किनेका छौं, हामीलाई लाग्छ कि यसले सञ्चारको गुणस्तरमा स्थिर सुधार ल्याउनेछ। निस्सन्देह, हामीले त्यहाँ के भइरहेको छ भनेर पत्ता लगाउन प्रयास गरेनौं; हाम्रो बैसाखी सबै कुरा हो। हाम्रो प्रतिरक्षामा, भनौं कि त्यो क्षणमा दबाइको समस्यालाई सकेसम्म चाँडो समाधान गर्न आवश्यक थियो, र यसलाई सुन्दर ढंगले गर्नु हुँदैन; यसबाहेक, हाम्रो लागि जानस C मा लेखिएको ब्ल्याक बक्स हो, यसलाई टिंकर गर्न धेरै महँगो छ।

खैर, प्रक्रियामा हामी:

• सर्भर र क्लाइन्ट दुबैमा अद्यावधिक गर्न सकिने सबै निर्भरताहरू अपडेट गरियो (यी पनि प्रयोगहरू थिए, हामीले नतिजाहरू निगरानी गर्यौं);
• विशेष केसहरूसँग सम्बन्धित सबै पहिचान गरिएका बगहरू फिक्स गरियो, उदाहरणका लागि, जब जडान घट्यो र स्वचालित रूपमा पुनर्स्थापना भएन;
• हामीले भिडियो संचारको क्षेत्रमा काम गर्ने कम्पनीहरूसँग धेरै बैठकहरू आयोजना गर्यौं र हाम्रा समस्याहरूसँग परिचित छौं: स्ट्रिमिङ गेमहरू, वेबिनारहरू आयोजना गर्ने; हामीले हामीलाई उपयोगी लाग्ने सबै प्रयास गरे;
• सबैभन्दा धेरै गुनासो आएका शिक्षकहरूको हार्डवेयर र सञ्चार गुणस्तरको प्राविधिक समीक्षा गरे।

प्रयोगहरू र त्यसपछिका परिवर्तनहरूले शिक्षकहरू बीचको सञ्चारमा असन्तुष्टिलाई जनवरी 7,1 मा 2018% बाट जनवरी 2,5 मा 2019% कम गर्न सम्भव बनायो।

अब के

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

मुख्य कठिनाई भनेको गुणस्तर सुधार गर्न वास्तवमा कुन स्तरमा सम्भव छ भनेर हामीलाई थाहा छैन। यो छत पत्ता लगाउनु मुख्य काम हो। तसर्थ, दुई प्रयोग योजना गरिएको थियो:

1. युद्ध अवस्थाहरूमा नियमित p2p सँग Janus मार्फत भिडियो तुलना गर्नुहोस्। यो प्रयोग पहिले नै गरिएको छ, हाम्रो समाधान र p2p बीच कुनै सांख्यिकीय रूपमा महत्त्वपूर्ण भिन्नता फेला परेन;
2. भिडियो संचार समाधानहरूमा विशेष रूपमा पैसा कमाउने कम्पनीहरूबाट (महँगो) सेवाहरू आपूर्ति गरौं, र तिनीहरूबाट रहेको नकारात्मकताको मात्रालाई अवस्थितसँग तुलना गरौं।

यी दुई प्रयोगहरूले हामीलाई प्राप्त गर्न सकिने लक्ष्य पहिचान गर्न र त्यसमा ध्यान केन्द्रित गर्न अनुमति दिनेछ।

थप रूपमा, त्यहाँ धेरै कार्यहरू छन् जुन नियमित रूपमा हल गर्न सकिन्छ:

• हामी व्यक्तिपरक समीक्षाको सट्टा सञ्चार गुणस्तरको प्राविधिक मेट्रिक सिर्जना गर्छौं;
• हामी असफलताहरूलाई अझ सटीक रूपमा विश्लेषण गर्न, कहिले र कहाँ ठ्याक्कै घट्यो, र त्यस क्षणमा के-कस्ता असंबद्ध घटनाहरू घट्यो भनेर बुझ्नको लागि हामी थप विस्तृत सत्र लगहरू बनाउँछौं;
• हामी पाठ अघि एक स्वचालित जडान गुणस्तर परीक्षण तयार गर्छौं, र ग्राहकलाई आफ्नो हार्डवेयर र च्यानलको कारण नकारात्मकताको मात्रा कम गर्न म्यानुअल रूपमा जडान परीक्षण गर्ने अवसर पनि दिन्छौं;
• हामी कमजोर अवस्थामा, चल प्याकेट हराउने, आदि सहित थप भिडियो संचार लोड परीक्षणहरू विकास र सञ्चालन गर्नेछौं;
• हामी त्रुटि सहिष्णुता वृद्धि गर्न समस्या को मामला मा सर्भर को व्यवहार परिवर्तन;
• हामी प्रयोगकर्तालाई चेतावनी दिनेछौं यदि उसको जडानमा केहि गडबड छ भने, स्काइपले जस्तै, जसले गर्दा उसले समस्या उसको पक्षमा छ भनेर बुझ्दछ।

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

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

स्रोत: www.habr.com