Skype पासून WebRTC पर्यंत: आम्ही वेबद्वारे व्हिडिओ संप्रेषण कसे आयोजित केले

विमबॉक्स प्लॅटफॉर्मवर शिक्षक आणि विद्यार्थी यांच्यातील संवादाचा मुख्य मार्ग म्हणजे व्हिडिओ कम्युनिकेशन. आम्ही बर्‍याच काळापूर्वी स्काईप सोडला, अनेक तृतीय-पक्ष उपायांचा प्रयत्न केला आणि अखेरीस WebRTC - Janus-gateway संयोजनावर सेटल झालो. काही काळ आम्ही प्रत्येक गोष्टीत आनंदी होतो, पण तरीही काही नकारात्मक बाबी समोर येत राहिल्या. परिणामी, एक स्वतंत्र व्हिडिओ दिशा तयार केली गेली.

मी नवीन दिशेचे प्रमुख किरील रोगोव्हॉय यांना स्कायंग येथे व्हिडिओ कम्युनिकेशनच्या उत्क्रांतीबद्दल, शोधलेल्या समस्या, उपाय आणि आम्ही शेवटी वापरलेल्या क्रॅचबद्दल बोलण्यास सांगितले. आम्हाला आशा आहे की वेब ऍप्लिकेशनद्वारे स्वतः व्हिडिओ तयार करणार्‍या कंपन्यांसाठी हा लेख उपयुक्त ठरेल.

इतिहास एक बिट

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

स्कायंग शाळेसाठी, व्हिडिओ कम्युनिकेशन हा शिक्षक-विद्यार्थी संवादाचा नेहमीच प्राधान्याचा मार्ग राहिला आहे. सुरुवातीला, स्काईपचा वापर केला गेला होता, परंतु ते अनेक कारणांमुळे स्पष्टपणे समाधानकारक नव्हते, मुख्यतः लॉगच्या अभावामुळे आणि थेट वेब अनुप्रयोगामध्ये एकत्रीकरणाची अशक्यता. त्यामुळे आम्ही सर्व प्रकारचे प्रयोग केले.

वास्तविक, व्हिडिओ संप्रेषणासाठी आमच्या आवश्यकता अंदाजे खालील होत्या:
- स्थिरता;
- प्रति धडा कमी किंमत;
- धडे रेकॉर्डिंग;
- कोण किती बोलतो याचा मागोवा घेणे (आमच्यासाठी हे महत्वाचे आहे की विद्यार्थी धड्यांदरम्यान शिक्षकापेक्षा जास्त बोलतात);
- रेखीय स्केलिंग;
- UDP आणि TCP दोन्ही वापरण्याची क्षमता.

2013 मध्ये प्रथम टोकबॉक्स लागू करण्याचा प्रयत्न केला. सर्व काही चांगले होते, परंतु ते खूप महाग झाले - प्रति धडा 113 रूबल - आणि नफा खाल्ले.

त्यानंतर 2015 मध्ये वोक्सिमप्लांटचे एकत्रीकरण करण्यात आले. कोण किती बोलले याचा मागोवा घेण्यासाठी आम्हाला हे कार्य आवश्यक होते आणि त्याच वेळी समाधान खूपच स्वस्त होते: जर फक्त ऑडिओ रेकॉर्ड केला असेल तर प्रति धडा 20 रूबल खर्च येईल. तथापि, ते फक्त UDP द्वारे कार्य करते आणि TCP वर स्विच करू शकत नाही. तथापि, सुमारे 40% विद्यार्थ्यांनी त्याचा वापर केला.

एक वर्षानंतर, आमच्याकडे कॉर्पोरेट क्लायंट त्यांच्या स्वतःच्या विशिष्ट आवश्यकतांसह मिळू लागले. उदाहरणार्थ, सर्वकाही ब्राउझरद्वारे कार्य केले पाहिजे; कंपनी फक्त http आणि https उघडते; म्हणजे स्काईप किंवा UDP नाही. कॉर्पोरेट क्लायंट = पैसे, म्हणून ते टोकबॉक्समध्ये परतले, परंतु किंमतीची समस्या दूर झाली नाही.

उपाय - WebRTC आणि Janus

वापरण्याचा निर्णय घेतला पीअर-टू-पीअर व्हिडिओ कम्युनिकेशन WebRTC साठी ब्राउझर प्लॅटफॉर्म. हे कनेक्शन स्थापित करण्यासाठी, एन्कोडिंग आणि डीकोडिंग स्ट्रीम, ट्रॅक सिंक्रोनाइझ करण्यासाठी आणि नेटवर्क ग्लिच हाताळण्यासाठी गुणवत्ता नियंत्रणासाठी जबाबदार आहे. आमच्या भागासाठी, आम्ही कॅमेरा आणि मायक्रोफोनमधून प्रवाह वाचणे, व्हिडिओ काढणे, कनेक्शन व्यवस्थापित करणे, WebRTC कनेक्शन स्थापित करणे आणि त्यामध्ये प्रवाह प्रसारित करणे, तसेच कनेक्शन स्थापित करण्यासाठी क्लायंट दरम्यान सिग्नलिंग संदेश प्रसारित करणे सुनिश्चित करणे आवश्यक आहे (WebRTC स्वतःच वर्णन करते. डेटा स्वरूप, परंतु त्याची यंत्रणा हस्तांतरण नाही). क्लायंट NAT च्या मागे असल्यास, WebRTC STUN सर्व्हरला जोडते; जर हे मदत करत नसेल, तर सर्व्हरला टर्न करा.

आमच्यासाठी नियमित p2p कनेक्शन पुरेसे नाही, कारण तक्रारीच्या बाबतीत आम्हाला पुढील विश्लेषणासाठी धडे रेकॉर्ड करायचे आहेत. म्हणून आम्ही वेबआरटीसी प्रवाह रिलेद्वारे पाठवतो मीटेचो द्वारे जानस गेटवे. परिणामी, क्लायंटला एकमेकांचे पत्ते माहित नसतात, फक्त जानस सर्व्हरचा पत्ता पाहता; ते सिग्नल सर्व्हरचे कार्य देखील करते. Janus मध्ये आम्हाला आवश्यक असलेली अनेक वैशिष्ट्ये आहेत: क्लायंटने UDP अवरोधित केल्यास आपोआप TCP वर स्विच होते; UDP आणि TCP दोन्ही प्रवाह रेकॉर्ड करू शकतात; स्केलेबल इको चाचण्यांसाठी एक अंगभूत प्लगइन देखील आहे. आवश्यक असल्यास, Twilio मधील STUN आणि TURN सर्व्हर आपोआप जोडले जातात.

2017 च्या उन्हाळ्यात, आमच्याकडे दोन Janus सर्व्हर चालू होते, तसेच रेकॉर्ड केलेल्या कच्च्या ऑडिओ आणि व्हिडिओ फायलींवर प्रक्रिया करण्यासाठी एक अतिरिक्त सर्व्हर होता, जेणेकरुन मुख्यचे प्रोसेसर व्यापू नयेत. कनेक्ट करताना, जॅनस सर्व्हर विषम-सम आधारावर (कनेक्शन क्रमांक) निवडले गेले. त्या वेळी, हे पुरेसे होते, आमच्या भावनांनुसार, याने अंदाजे चौपट सुरक्षा मार्जिन दिले, अंमलबजावणीची टक्केवारी सुमारे 80 होती. त्याच वेळी, किंमत प्रति धडा ~2 रूबल, तसेच विकास आणि समर्थन कमी केली गेली.

व्हिडिओ कम्युनिकेशनच्या विषयाकडे परत येत आहे

वेळेवर समस्या ओळखण्यासाठी आणि दुरुस्त करण्यासाठी आम्ही विद्यार्थी आणि शिक्षकांच्या अभिप्रायाचे सतत निरीक्षण करतो. 2018 च्या उन्हाळ्यापर्यंत, तक्रारींमध्ये कॉल गुणवत्ता पहिल्या स्थानावर होती. एकीकडे, याचा अर्थ आम्ही इतर कमतरतांवर यशस्वीरित्या मात केली आहे. दुसरीकडे, तातडीने काहीतरी करणे आवश्यक होते: धडा खंडित झाल्यास, आम्ही त्याचे मूल्य गमावण्याचा धोका असतो, काहीवेळा पुढील पॅकेज खरेदी करण्याच्या खर्चासह, आणि जर प्रास्ताविक धड्यात व्यत्यय आला तर, आम्हाला संभाव्य क्लायंट गमावण्याचा धोका असतो. संपूर्णपणे

त्यावेळी आमचा व्हिडिओ कम्युनिकेशन MVP मोडमध्ये होता. सोप्या भाषेत सांगायचे तर, त्यांनी ते लॉन्च केले, ते कार्य केले, त्यांनी ते एकदा मोजले, ते कसे करायचे ते त्यांना समजले - चांगले, छान. ते कार्य करत असल्यास, त्याचे निराकरण करू नका. दळणवळणाच्या गुणवत्तेचा मुद्दा कोणीही मुद्दाम मांडला नाही. ऑगस्टपर्यंत, हे पुढे चालू शकत नाही हे स्पष्ट झाले आणि WebRTC आणि Janus मध्ये काय चूक आहे हे शोधण्यासाठी आम्ही एक वेगळी दिशा सुरू केली.

इनपुटवर, ही दिशा प्राप्त झाली: MVP सोल्यूशन, कोणतेही मेट्रिक्स नाहीत, कोणतेही लक्ष्य नाहीत, सुधारणेसाठी कोणतीही प्रक्रिया नाही, तर 7% शिक्षक संवादाच्या गुणवत्तेबद्दल तक्रार करतात (विद्यार्थ्यांवर कोणताही डेटा नव्हता).

एक नवीन दिशा चालू आहे

कमांड यासारखे काहीतरी दिसते:

• विभागाचे प्रमुख, जे मुख्य विकासक देखील आहेत.
• QA बदलांची चाचणी घेण्यास मदत करते, अस्थिर संप्रेषण परिस्थिती निर्माण करण्यासाठी नवीन मार्ग शोधते आणि समोरच्या ओळीतून समस्यांची तक्रार करते.
• विश्लेषक सतत तांत्रिक डेटामधील विविध सहसंबंध शोधतो, वापरकर्त्याच्या अभिप्रायाचे विश्लेषण सुधारतो आणि प्रयोगांचे परिणाम तपासतो.
• उत्पादन व्यवस्थापक संपूर्ण दिशा आणि प्रयोगांसाठी संसाधनांचे वाटप करण्यात मदत करतो.
• दुसरा विकसक प्रोग्रामिंग आणि संबंधित कार्यांमध्ये मदत करतो.

सुरुवातीला, आम्ही एक तुलनेने विश्वासार्ह मेट्रिक सेट केले ज्याने संप्रेषण गुणवत्तेचे मूल्यांकन (सरासरी दिवस, आठवडे, महिने) मधील बदलांचा मागोवा घेतला. त्या वेळी, हे शिक्षकांचे ग्रेड होते; नंतर विद्यार्थ्यांचे ग्रेड त्यांना जोडले गेले. मग त्यांनी काय चुकीचे काम करत आहे याविषयी गृहीतके बांधण्यास सुरुवात केली, ते दुरुस्त करा आणि गतिशीलतेतील बदल पहा. आम्ही कमी-हँगिंग फळासाठी गेलो: उदाहरणार्थ, आम्ही vp8 कोडेक vp9 ने बदलले, कामगिरी सुधारली. आम्ही जॅनस सेटिंग्जसह खेळण्याचा आणि इतर प्रयोग करण्याचा प्रयत्न केला - बहुतेक प्रकरणांमध्ये त्यांनी काहीही केले नाही.

दुस-या टप्प्यावर, एक गृहीतक उदयास आले: WebRTC हे पीअर-टू-पीअर सोल्यूशन आहे आणि आम्ही मध्यभागी सर्व्हर वापरतो. कदाचित समस्या येथे आहे? आम्ही खोदणे सुरू केले आणि आतापर्यंतची सर्वात लक्षणीय सुधारणा आढळली.

त्या क्षणी, ऐवजी मूर्ख अल्गोरिदम वापरून पूलमधील सर्व्हर निवडला गेला: प्रत्येकाचे स्वतःचे "वजन" होते, चॅनेल आणि शक्तीवर अवलंबून, आणि आम्ही वापरकर्त्याला सर्वात मोठ्या "वजन" शिवाय पाठवण्याचा प्रयत्न केला. वापरकर्ता भौगोलिकदृष्ट्या कुठे आहे याकडे लक्ष देणे. परिणामी, सेंट पीटर्सबर्गमधील शिक्षक सायबेरियातील विद्यार्थ्याशी मॉस्कोमार्गे संवाद साधू शकले, सेंट पीटर्सबर्गमधील आमच्या जानस सर्व्हरद्वारे नाही.

अल्गोरिदम पुन्हा केले गेले आहे: आता, जेव्हा वापरकर्ता आमचे प्लॅटफॉर्म उघडतो, तेव्हा आम्ही त्याच्याकडून Ajax वापरून सर्व सर्व्हरवर पिंग गोळा करतो. कनेक्शन स्थापित करताना, आम्ही सर्वात कमी रकमेसह पिंग्सची जोडी (शिक्षक-सर्व्हर आणि विद्यार्थी-सर्व्हर) निवडतो. कमी पिंग म्हणजे सर्व्हरला कमी नेटवर्क अंतर; कमी अंतर म्हणजे पॅकेट गमावण्याची कमी संभाव्यता; व्हिडिओ कम्युनिकेशनमध्ये पॅकेट लॉस हा सर्वात मोठा नकारात्मक घटक आहे. नकारात्मकतेचा वाटा तीन महिन्यांत निम्म्याने घसरला (न्यायपूर्वक सांगायचे तर, यावेळी इतर प्रयोग केले गेले, परंतु याचा परिणाम नक्कीच झाला).

आम्‍ही नुकतीच आणखी एक उघड नसलेली, परंतु वरवर पाहता महत्त्वाची गोष्ट शोधली: जाड चॅनेलवर एका शक्तिशाली जनस सर्व्हरऐवजी, पातळ बँडविड्थ असलेले दोन सोपे असणे चांगले. एकाच वेळी अनेक खोल्या (संवाद सत्रे) भरण्याच्या आशेने आम्ही शक्तिशाली मशीन्स विकत घेतल्यावर हे स्पष्ट झाले. सर्व्हरची बँडविड्थ मर्यादा असते, जी आम्ही खोल्यांच्या संख्येमध्ये अचूकपणे अनुवादित करू शकतो - आम्हाला माहित आहे की किती उघडल्या जाऊ शकतात, उदाहरणार्थ, 300 Mbit/s वर. सर्व्हरवर अनेक खोल्या उघडल्याबरोबर, लोड कमी होईपर्यंत आम्ही नवीन क्रियाकलापांसाठी ते निवडणे थांबवतो. कल्पना अशी होती की, एक शक्तिशाली मशीन विकत घेतल्यावर, आम्ही चॅनेल जास्तीत जास्त लोड करू, जेणेकरून शेवटी ते प्रोसेसर आणि मेमरीद्वारे मर्यादित असेल, बँडविड्थद्वारे नाही. परंतु असे दिसून आले की काही खुल्या खोल्या (420) नंतर, प्रोसेसर, मेमरी आणि डिस्कवरील भार अद्याप मर्यादेपासून खूप दूर असूनही, तांत्रिक समर्थनावर नकारात्मकता येऊ लागते. वरवर पाहता, जानुसमध्ये काहीतरी बिघडत आहे, कदाचित तेथे देखील काही निर्बंध आहेत. आम्ही प्रयोग सुरू केले, बँडविड्थ मर्यादा 300 वरून 200 Mbit/s पर्यंत कमी केली आणि समस्या दूर झाल्या. आता आम्ही कमी मर्यादा आणि वैशिष्ट्यांसह एकाच वेळी तीन नवीन सर्व्हर खरेदी केले आहेत, आम्हाला वाटते की यामुळे संवादाच्या गुणवत्तेत स्थिर सुधारणा होईल. अर्थात, आम्ही तिथे काय चालले आहे हे शोधण्याचा प्रयत्न केला नाही; आमच्या कुंचल्या सर्व काही आहेत. आमच्या बचावात, असे म्हणूया की त्या क्षणी दाबण्याची समस्या शक्य तितक्या लवकर सोडवणे आवश्यक होते आणि ते सुंदरपणे न करणे; याशिवाय, आमच्यासाठी जॅनस हा C मध्ये लिहिलेला ब्लॅक बॉक्स आहे, त्याच्याशी टिंकर करणे खूप महाग आहे.

बरं, प्रक्रियेत आम्ही:

• सर्व्हरवर आणि क्लायंटवर अद्यतनित करता येणारी सर्व अवलंबित्वे अद्यतनित केली (हे देखील प्रयोग होते, आम्ही परिणामांचे परीक्षण केले);
• विशिष्ट प्रकरणांशी संबंधित सर्व ओळखल्या जाणार्‍या दोषांचे निराकरण केले, उदाहरणार्थ, जेव्हा कनेक्शन सोडले आणि स्वयंचलितपणे पुनर्संचयित केले गेले नाही;
• आम्ही व्हिडिओ कम्युनिकेशनच्या क्षेत्रात काम करणार्‍या कंपन्यांसोबत बर्‍याच बैठका घेतल्या आणि आमच्या समस्यांशी परिचित आहोत: गेम स्ट्रीमिंग, वेबिनार आयोजित करणे; आम्हाला उपयुक्त वाटणारी प्रत्येक गोष्ट आम्ही प्रयत्न केला;
• ज्यांच्याकडून सर्वाधिक तक्रारी आल्या त्या शिक्षकांच्या हार्डवेअर आणि संप्रेषण गुणवत्तेचा तांत्रिक आढावा घेतला.

प्रयोग आणि त्यानंतरच्या बदलांमुळे शिक्षकांमधील संवादाबाबत असमाधान जानेवारी 7,1 मध्ये 2018% वरून जानेवारी 2,5 मध्ये 2019% पर्यंत कमी करणे शक्य झाले.

पुढे काय

आमचा विमबॉक्स प्लॅटफॉर्म स्थिर करणे हा कंपनीच्या २०१९ साठीच्या मुख्य प्रकल्पांपैकी एक आहे. आम्हाला आशा आहे की आम्ही गती राखण्यात सक्षम होऊ आणि यापुढे शीर्ष तक्रारींमध्ये व्हिडिओ संप्रेषण दिसणार नाही. आम्‍ही समजतो की या तक्रारींमध्‍ये एक लक्षणीय भाग वापरकर्त्‍यांच्‍या संगणक आणि इंटरनेटमध्‍ये लॅग्जशी संबंधित आहे, परंतु आम्‍ही हा भाग निश्चित करून बाकीचे निराकरण केले पाहिजे. बाकी सर्व काही तांत्रिक समस्या आहे, असे दिसते की आपण त्यास सामोरे जाण्यास सक्षम असावे.

मुख्य अडचण अशी आहे की गुणवत्ता सुधारणे खरोखर कोणत्या स्तरावर शक्य आहे हे आपल्याला माहित नाही. ही कमाल मर्यादा शोधणे हे मुख्य काम आहे. म्हणून, दोन प्रयोग नियोजित होते:

1. लढाऊ परिस्थितीत नियमित p2p सह Janus द्वारे व्हिडिओची तुलना करा. हा प्रयोग आधीच केला गेला आहे, आमच्या सोल्यूशन आणि p2p मध्ये सांख्यिकीयदृष्ट्या महत्त्वपूर्ण फरक आढळला नाही;
2. चला फक्त व्हिडिओ कम्युनिकेशन सोल्यूशन्सवर पैसे कमवणाऱ्या कंपन्यांकडून (महाग) सेवा पुरवू आणि त्यांच्याकडून असलेल्या नकारात्मकतेची तुलना सध्याच्या एकाशी करू.

हे दोन प्रयोग आम्हाला साध्य करण्यायोग्य ध्येय ओळखण्यास आणि त्यावर लक्ष केंद्रित करण्यास अनुमती देतील.

याव्यतिरिक्त, अशी अनेक कार्ये आहेत जी नियमितपणे सोडविली जाऊ शकतात:

• आम्ही व्यक्तिनिष्ठ पुनरावलोकनांऐवजी संप्रेषण गुणवत्तेचे तांत्रिक मेट्रिक तयार करतो;
• येणाऱ्या अपयशांचे अधिक अचूकपणे विश्लेषण करण्यासाठी, ते नेमके केव्हा आणि कोठे घडले हे समजून घेण्यासाठी आणि त्या क्षणी कोणकोणत्या असंबंधित घटना घडल्या हे समजून घेण्यासाठी आम्ही अधिक तपशीलवार सत्र लॉग बनवतो;
• आम्ही धड्याच्या आधी स्वयंचलित कनेक्शन गुणवत्ता चाचणी तयार करतो आणि क्लायंटला त्याच्या हार्डवेअर आणि चॅनेलमुळे होणारी नकारात्मकता कमी करण्यासाठी कनेक्शनची व्यक्तिचलितपणे चाचणी करण्याची संधी देखील देतो;
• आम्‍ही खराब स्थितीत, व्हेरिएबल पॅकेट लॉस इ. सह व्हिडिओ कम्युनिकेशन लोड चाचण्या विकसित करू आणि आयोजित करू;
• दोष सहिष्णुता वाढवण्यासाठी आम्ही समस्यांच्या बाबतीत सर्व्हरचे वर्तन बदलतो;
• स्काईपप्रमाणेच, त्याच्या कनेक्शनमध्ये काही चूक असल्यास आम्ही वापरकर्त्याला चेतावणी देऊ, जेणेकरून त्याला समजेल की समस्या त्याच्या बाजूने आहे.

एप्रिलपासून, व्हिडीओ कम्युनिकेशन डायरेक्शन स्कायंगमध्ये एक पूर्ण वाढ झालेला स्वतंत्र प्रकल्प बनला आहे, जो केवळ विमबॉक्सचा भाग नसून स्वतःच्या उत्पादनाशी संबंधित आहे. याचा अर्थ असा आहे की आम्ही वर लोक शोधू लागलो आहोत पूर्णवेळ मोडमध्ये व्हिडिओसह कार्य करणे. बरं, नेहमीप्रमाणे आम्ही खूप चांगले लोक शोधत आहोत.

आणि अर्थातच, आम्ही व्हिडिओ कम्युनिकेशन्ससह काम करणाऱ्या लोकांशी आणि कंपन्यांशी सक्रियपणे संवाद साधत आहोत. जर तुम्हाला आमच्यासोबत अनुभवाची देवाणघेवाण करायची असेल तर आम्हाला आनंद होईल! टिप्पणी द्या, संपर्कात रहा - आम्ही प्रत्येकाला उत्तर देऊ.

स्त्रोत: www.habr.com