डब्ल्यूसीएस 5.2 की समीक्षा - वेबकास्ट और वेबकेम डेवलपर्स के लिए वेबआरटीसी सर्वर

ऐलिस एक अनुभवी पूर्ण स्टैक डेवलपर है, जो एक सप्ताह में php का उपयोग करके अपने पसंदीदा फ्रेमवर्क पर SAAS प्रोजेक्ट फ्रेमवर्क लिखने में सक्षम है। सामने के लिए, वह Vue.js. पसंद करती है

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

1) वे अपने उपयोगकर्ताओं को तृतीय-पक्ष संचारकों (Skype, Hangouts, आदि) को उधार नहीं देना चाहते हैं और उन्हें सेवा में बनाए रखना चाहते हैं।

2) अपने संचार की निगरानी करना चाहते हैं, जैसे कॉल इतिहास और साक्षात्कार परिणाम।

3) रिकॉर्ड कॉल (स्वाभाविक रूप से, रिकॉर्डिंग के बारे में दोनों पक्षों को सूचित करना)।

4) वे तृतीय-पक्ष सेवाओं की नीतियों और अपडेट पर निर्भर नहीं रहना चाहते हैं। हर कोई इस कहानी को जानता है: स्काइप अपडेट हो गया, और सब कुछ धुएं में उड़ गया ...

यह एक आसान काम की तरह लगता है। WebRTC तब आता है जब विषय पर googling, और ऐसा लगता है कि आप दो ब्राउज़रों के बीच एक सहकर्मी से सहकर्मी कनेक्शन व्यवस्थित कर सकते हैं, लेकिन अभी भी कुछ प्रश्न हैं:

1) STUN / TURN सर्वर कहाँ से प्राप्त करें?

2) क्या हम उनके बिना कर सकते हैं?

3) एक सहकर्मी से सहकर्मी WebRTC कॉल कैसे रिकॉर्ड करें?

4) अगर हमें कॉल में किसी तीसरे पक्ष को जोड़ने की आवश्यकता होती है, तो क्या होगा, उदाहरण के लिए, एक एचआर मैनेजर या नियोक्ता का कोई अन्य विशेषज्ञ?

यह पता चला है कि WebRTC और पीयर-टू-पीयर अकेले पर्याप्त नहीं हैं, और यह स्पष्ट नहीं है कि सेवा के आवश्यक वीडियो फ़ंक्शन लॉन्च करने के लिए यह सब क्या करना है।

लेख सामग्री

सर्वर और एपीआई

इन अंतरालों को बंद करने के लिए, सर्वर समाधान और पीयर-सर्वर-पीयर आर्किटेक्चर का उपयोग किया जाता है। वेब कॉल सर्वर 5.2 (इसके बाद - डब्ल्यूसीएस) सर्वर समाधानों में से एक है; यह एक विकास मंच है जो आपको इस तरह के वीडियो कार्यों को परियोजना में जोड़ने की अनुमति देता है और STUN / TURN और पीयर-टू-पीयर कनेक्शन स्थिरता के बारे में चिंता नहीं करता है।

उच्चतम स्तर पर, WCS एक जावास्क्रिप्ट एपीआई + सर्वर हिस्सा है। API का उपयोग ब्राउज़र की तरफ नियमित जावास्क्रिप्ट का उपयोग करने के लिए किया जाता है, और सर्वर मीडिया ट्रैफ़िक को संसाधित करता है, मीडिया ट्रैफ़िक के लिए एक स्टेटफ़ुल प्रॉक्सी के रूप में कार्य करता है।

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

उदाहरण के लिए, सर्वर पर स्ट्रीम प्रकाशित करना (सर्वर की ओर वेबकैम से स्ट्रीमिंग) ऐसा दिखता है:

वेब sdk

session.createStream({name:”stream123”}).publish(); 

Android एसडीके

 publishStream = session.createStream(streamOptions) publishStream.publish(); 

आईओएस एसडीके

 FPWCSApi2Stream *stream = [session createStream:options error:&error]; if(![stream publish:&error]) { //published without errors } 

नतीजतन, हम न केवल एक वेब एप्लिकेशन को लागू कर सकते हैं, बल्कि Google Play और ऐप स्टोर के लिए वीडियो स्ट्रीमिंग समर्थन के साथ पूर्ण-अप अप भी कर सकते हैं। यदि हम शीर्ष स्तर के चित्र में मोबाइल एसडीके जोड़ते हैं, तो हमें यह मिलेगा:

आने वाली धाराएँ

स्ट्रीमिंग सर्वर, जो डब्ल्यूसीएस है, आने वाली धाराओं के साथ शुरू होता है। कुछ वितरित करने के लिए, हमारे पास यह होना चाहिए। दर्शकों को वीडियो स्ट्रीम वितरित करने के लिए, यह आवश्यक है कि ये स्ट्रीम सर्वर में प्रवेश करें, इसकी रैम से गुजरें, और नेटवर्क कार्ड के माध्यम से बाहर निकलें। इसलिए, पहला सवाल जो हमें मीडिया सर्वर के साथ खुद को परिचित करते समय पूछना चाहिए, वह यह है कि धाराओं को स्वीकार करने के लिए बाद के उपयोग के प्रोटोकॉल और प्रारूप क्या हैं। WCS के मामले में, ये निम्नलिखित प्रौद्योगिकियाँ हैं: WebRTC, RTMP, RTSP, VOD, SIP / RTP।

प्रत्येक प्रोटोकॉल का उपयोग विविध ग्राहकों द्वारा किया जा सकता है। उदाहरण के लिए, न केवल ब्राउज़र से स्ट्रीम WebRTC के माध्यम से प्रवेश कर सकती है, बल्कि किसी अन्य सर्वर से भी। नीचे दी गई तालिका में आने वाले यातायात के संभावित स्रोत हैं।

यदि हम आने वाले ट्रैफ़िक के स्रोतों से गुज़रते हैं, तो हम निम्नलिखित जोड़ सकते हैं:

आने वाली WebRTC

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

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

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

आवक rtmp

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

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

आवक rtsp

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

आवक वोद

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

आवक एसआईपी / आरटीपी

SIP सत्र के अंदर आने वाले RTP ट्रैफ़िक को प्राप्त करने के लिए, हमें थर्ड-पार्टी SIP गेटवे के साथ कॉल सेट करना होगा। यदि कनेक्शन सफलतापूर्वक स्थापित किया गया है, तो ऑडियो और / या वीडियो ट्रैफ़िक एसआईपी गेटवे से जाएगा, जिसे डब्ल्यूसीएस की तरफ आने वाली स्ट्रीम में लपेटा जाएगा।

बहती धाराएँ

सर्वर को स्ट्रीम प्राप्त करने के बाद, हम अनुरोध पर एक या कई दर्शकों को प्राप्त स्ट्रीम को दोहरा सकते हैं। दर्शक खिलाड़ी या अन्य डिवाइस से एक स्ट्रीम का अनुरोध करता है। ऐसी धाराओं को आउटगोइंग या "दर्शक स्ट्रीम" कहा जाता है, क्योंकि इस तरह की धाराओं के सत्र हमेशा दर्शक / खिलाड़ी की ओर से शुरू किए जाते हैं। प्लेबैक प्रौद्योगिकियों के सेट में निम्नलिखित प्रोटोकॉल / प्रारूप शामिल हैं: WebRTC, RTMP, RTSP, MSE और HLS।

निवर्तमान WebRTC

इस मामले में, वेब एसडीके, एंड्रॉइड एसडीके और आईओएस एसडीके खिलाड़ी के लिए एपीआई के रूप में कार्य करते हैं। WebRTC स्ट्रीम खेलने का एक उदाहरण इस प्रकार है:

वेब sdk

 session.createStream({name:”stream123”}).play(); 

Android एसडीके

 playStream = session.createStream(streamOptions); playStream.play(); 

आईओएस एसडीके

 FPWCSApi2Stream *stream = [session createStream:options error:nil]; if(![stream play:&error]) { //published without errors } 

यह प्रकाशन API के समान है, जिसमें एकमात्र अंतर है कि स्ट्रीम के बजाय। अप्रकाशित (), stream.play () को खेलना कहा जाता है।

एक तृतीय-पक्ष WCS सर्वर खिलाड़ी हो सकता है, जिसे निर्देश दिया जाएगा कि वे पुल विधि का उपयोग करके किसी अन्य सर्वर से WebRTC के माध्यम से स्ट्रीम उठाएं या CDN के अंदर स्ट्रीम चुनें।

निवर्तमान rtmp

यहां मुख्य रूप से RTMP खिलाड़ी होंगे - दोनों जाने-माने Flash Player और डेस्कटॉप और मोबाइल एप्लिकेशन जो RTMP प्रोटोकॉल का उपयोग करते हैं, प्राप्त करते हैं और RTMP स्ट्रीम खेलते हैं। इस तथ्य के बावजूद कि फ्लैश ने ब्राउज़र को छोड़ दिया, उसने RTMP प्रोटोकॉल रखा, जिसका व्यापक रूप से वीडियो प्रसारण के लिए उपयोग किया जाता है, और ब्राउज़रों में मूल समर्थन की कमी अन्य क्लाइंट अनुप्रयोगों में इस काफी सफल प्रोटोकॉल के उपयोग को नहीं रोकती है। यह ज्ञात है कि Android और iOS पर मोबाइल अनुप्रयोगों के लिए VR खिलाड़ियों में RTMP का व्यापक रूप से उपयोग किया जाता है।

निवर्तमान आरपीएसपी

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

निवर्तमान mse

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

आउटगोइंग हल्स

यहां, WCS HLS सर्वर या वेब सर्वर के रूप में कार्य करता है जो HLS (HTTP लाइव स्ट्रीमिंग) का समर्थन करता है। एक बार सर्वर पर आने वाली स्ट्रीम दिखाई देने पर, एक .m3u8 HLS प्लेलिस्ट उत्पन्न होती है, जो HTTP अनुरोध के जवाब में खिलाड़ी को दी जाती है। प्लेलिस्ट यह बताती है कि खिलाड़ी को कौन सा वीडियो सेगमेंट डाउनलोड और प्रदर्शित करना चाहिए। खिलाड़ी वीडियो सेगमेंट डाउनलोड करता है और इसे ब्राउज़र पेज पर, मोबाइल डिवाइस पर, डेस्कटॉप पर, एप्पल टीवी सेट-टॉप बॉक्स में और जहाँ भी एचएलएस सपोर्ट का दावा किया जाता है, उसे प्ले करता है।

आवक और जावक

कुल में, हमारे पास 5 इनकमिंग और आउटगोइंग स्ट्रीम प्रकार हैं। वे तालिका में सूचीबद्ध हैं:

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

अब, आइए वर्णन करते हैं कि धाराओं के साथ क्या क्रियाएं की जा सकती हैं।

आने वाली धारा हेरफेर

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

स्ट्रीम opeartions में शामिल हैं:

- रिकॉर्डिंग

- एक स्नैपशॉट ले रहा है

- मिक्सर में एक धारा जोड़ने

- धारा पारगमन

- वॉटरमार्क जोड़ना

- एक एफपीएस फिल्टर जोड़ना

- 90, 180, 270 डिग्री से छवि रोटेशन

आने वाली स्ट्रीम रिकॉर्डिंग

शायद सबसे समझने योग्य और अक्सर सामना किए जाने वाले फ़ंक्शन। दरअसल, कई मामलों में, धाराओं को रिकॉर्डिंग की आवश्यकता होती है: वेबिनार, अंग्रेजी पाठ, परामर्श, आदि।

रिकॉर्डिंग को विशेष अनुरोध के साथ वेब एसडीके या रीस्ट एपीआई के साथ शुरू किया जा सकता है:

 /stream/startRecording {} 

परिणाम फ़ाइल सिस्टम में एक mp4 फ़ाइल के रूप में सहेजा जाता है।

एक स्नैपशॉट ले रहा है

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

WCS सर्वर स्नैपशॉट प्राप्त करने के लिए REST विधि का समर्थन करता है:

 /stream/snapshot 

मिक्सर में एक धारा जोड़ना

दर्शकों को समाप्त करने के लिए प्रदर्शन के लिए दो या दो से अधिक स्रोतों से एक छवि को एक में जोड़ा जा सकता है। इस प्रक्रिया को मिश्रण कहा जाता है। मूल उदाहरण: 1) एक चित्र में स्क्रीन पर कई कैमरों से वीडियो निगरानी। 2) वीडियोकांफ्रेंसिंग, जहां प्रत्येक उपयोगकर्ता को एक स्ट्रीम मिलती है, जिसमें संसाधनों को बचाने के लिए बाकी को मिलाया जाता है। मिक्सर को REST API के माध्यम से नियंत्रित किया जाता है और वीडियो कॉन्फ्रेंस बनाने के लिए ऑपरेशन का MCU मोड है।

मिक्सर में एक धारा जोड़ने के लिए बाकी आदेश:

 /mixer/startup 

स्ट्रीम ट्रांसकोडिंग

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

इस्तेमाल किया विधि:

 /transcoder/startup 

एक वॉटरमार्क जोड़ना

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

एक एफपीएस फिल्टर जोड़ना

कुछ मामलों में, यह आवश्यक है कि स्ट्रीम में एक समान FPS (फ्रेम प्रति सेकंड) हो। यह काम में आ सकता है अगर हम धारा को Youtube या Facebook जैसे किसी तृतीय-पक्ष संसाधन में पुन: प्रवाहित करें या इसे संवेदनशील HLS खिलाड़ी के साथ खेलें। फ़िल्टरिंग के लिए ट्रांसकोडिंग की भी आवश्यकता होती है, इसलिए अपने सर्वर की शक्ति का ठीक से आकलन करना सुनिश्चित करें और यदि इस तरह के ऑपरेशन की योजना बनाई जाए तो प्रति स्ट्रीम 2 कोर तैयार करें।

90, 180, 270 डिग्री से छवि रोटेशन

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

आने वाली धाराओं का प्रबंधन

स्वचालित - कॉन्फ़िगरेशन आमतौर पर सेटिंग्स में सर्वर साइड पर सेट होता है।

स्ट्रीम रिले

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

रिलेयिंग को निम्नलिखित प्रोटोकॉल में से एक का उपयोग करके लागू किया जा सकता है: WebRTC, RTMP, SIP / RTP। तालिका उस दिशा को दिखाती है जिसमें धारा को रिले किया जा सकता है।

वेबआरटीसी रिले

यदि किसी कारण से किसी अन्य सर्वर पर स्ट्रीम को उपलब्ध करना आवश्यक है, तो एक स्ट्रीम को दूसरे WCS सर्वर पर रिले किया जा सकता है। रिले को REST API के माध्यम से / पुश विधि द्वारा किया जाता है। इस तरह के REST अनुरोध के प्राप्त होने पर, WCS निर्दिष्ट सर्वर से जुड़ जाता है और सर्वर-सर्वर स्ट्रीम को प्रकाशित करता है। उसके बाद, धारा किसी अन्य मशीन पर प्लेबैक के लिए उपलब्ध हो जाती है।

 /pull/push 

- REST विधि का उपयोग किया

RTMP रिलेइंग

WebRTC रिले के साथ के रूप में, दूसरे सर्वर पर RTMP रिले करना भी संभव है। अंतर केवल रिले प्रोटोकॉल में होगा। RTMP रिलेइंग / पुश के माध्यम से भी प्रदर्शन किया जाता है और स्ट्रीम को थर्ड-पार्टी RTMP सर्वर और RTMP इनसेस्ट का समर्थन करने वाली सेवाओं में स्थानांतरित करने की अनुमति देता है: Youtube, Facebook स्ट्रीमिंग, आदि। इस प्रकार, WebRTC स्ट्रीम को RTMP में रिले किया जा सकता है। हम आरटीपीपी या वीओडी, आरटीएमपी के लिए, सर्वर में प्रवेश करने वाली किसी भी अन्य धारा को रिले कर सकते हैं।

वीडियो स्ट्रीम REST कॉल का उपयोग करके किसी अन्य RTMP सर्वर से संबंधित है।

 /push/startup 

- REST कॉल का उपयोग किया

SIP / RTP रिले

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

अन्य एपीआई कमांड:

 /call/inject_stream/startup 

सर्वर को एक सीडीएन सामग्री प्रसंस्करण नेटवर्क से जोड़ना

आमतौर पर, एक सर्वर में सीमित मात्रा में संसाधन होते हैं। इसलिए, बड़े ऑनलाइन प्रसारण के लिए जहां दर्शक हजारों और दसियों हज़ार के लिए मायने रखता है, स्केलिंग आवश्यक है। कई WCS सर्वरों को एक CDN सामग्री वितरण नेटवर्क में जोड़ा जा सकता है। आंतरिक रूप से, CDN स्ट्रीमिंग के दौरान कम विलंबता बनाए रखने के लिए WebRTC के माध्यम से काम करेगा।

सर्वर को निम्न भूमिकाओं में से एक में कॉन्फ़िगर किया जा सकता है: उत्पत्ति, किनारा, या ट्रांसकोडर। उत्पत्ति प्रकार के सर्वर ट्रैफ़िक प्राप्त करते हैं और इसे एज सर्वर पर वितरित करते हैं, जो दर्शकों को स्ट्रीम वितरित करने के लिए जिम्मेदार हैं। यदि कई प्रस्तावों में एक धारा तैयार करना आवश्यक है, तो ट्रांसकोडर नोड्स को योजना में शामिल किया जाता है, जो ट्रांसकोडिंग धाराओं के संसाधन-खपत मिशन को लेते हैं।

संक्षेप में देना

WCS 5.2 ब्राउज़र और मोबाइल उपकरणों के लिए रियलटाइम ऑडियो और वीडियो समर्थन के साथ एप्लिकेशन विकसित करने के लिए एक सर्वर है। विकास के लिए चार एपीआई दिए गए हैं: वेब एसडीके, आईओएस एसडीके, एंड्रॉइड एसडीके, रीस्ट एपीआई। हम पांच प्रोटोकॉल का उपयोग कर सर्वर को वीडियो स्ट्रीम प्रकाशित (फीड) कर सकते हैं: WebRTC, RTMP, RTSP, VOD, SIP / RTP। सर्वर से, हम पांच प्रोटोकॉल का उपयोग करके खिलाड़ियों के साथ स्ट्रीम खेल सकते हैं: WebRTC, RTMP, RTSP, MSE, HLS। धाराओं को नियंत्रित किया जा सकता है और रिकॉर्डिंग, स्नैपिंग स्लाइसिंग, मिक्सिंग, ट्रांसकोडिंग, वॉटरमार्क जोड़ने, एफपीएस को फ़िल्टर करने और वीडियो को मोबाइल उपकरणों पर प्रसारित करने जैसे कार्यों से गुजरना पड़ता है। धाराएं WebRTC और RTMP प्रोटोकॉल के माध्यम से अन्य सर्वरों में रिले की जा सकती हैं, साथ ही SIP सम्मेलनों में पुनर्निर्देशित की जा सकती हैं। सर्वर को सामग्री वितरण नेटवर्क में जोड़ा जा सकता है और वीडियो स्ट्रीम की एक मनमानी संख्या को संसाधित करने के लिए बढ़ाया जा सकता है।

ऐलिस को सर्वर के साथ काम करने के लिए क्या पता होना चाहिए

डेवलपर को लिनक्स का उपयोग करने में सक्षम होना चाहिए। कमांड लाइन में निम्नलिखित कमांड के कारण भ्रम नहीं होना चाहिए:

 tar -xvzf wcs5.2.tar.gz 

 cd wcs5.2 

 ./install.sh 

 tail -f flashphoner.log 

 ps aux | grep WebCallServer 

 top 

वेब विकास की बात आने पर वनीला जावास्क्रिप्ट को भी जानना होगा।

 //publishing the stream session.createStream({name:'mystream'}).publish(); //playing the stream session.createStream({name:'mystream'}).play(); 

बैक-एंड के साथ काम करने की क्षमता भी काम आ सकती है।

WCS न केवल REST API के माध्यम से नियंत्रण आदेश प्राप्त कर सकता है, बल्कि हुक भी भेज सकता है - यानी उस पर होने वाली घटनाओं के बारे में सूचनाएं। उदाहरण के लिए, जब एक ब्राउज़र या मोबाइल एप्लिकेशन से कनेक्शन स्थापित करने की कोशिश की जा रही है, तो WCS / कनेक्ट हुक को ट्रिगर करेगा, और जब कोई स्ट्रीम चलाने की कोशिश करेगा, तो यह playStream हुक को ट्रिगर करेगा। इसलिए, डेवलपर को बैक एंडर के जूते में थोड़ा चलना होगा, जो हुक बनाने के लिए एक साधारण REST क्लाइंट और एक छोटा REST सर्वर बनाने में सक्षम है।

अन्य एपीआई उदाहरण

 /rest-api/stream/find_all 

- सर्वर पर स्ट्रीम को सूचीबद्ध करने के लिए REST API का उदाहरण

बाकी हुक उदाहरण

 https://myback-end.com/hook/connect 

- बैकएंड साइड पर REST हुक / कनेक्ट प्रोसेसिंग।

लिनक्स, जावास्क्रिप्ट, रीस्ट क्लाइंट / सर्वर - तीन तत्व जो वीडियो स्ट्रीम के साथ काम करने वाले डब्ल्यूसीएस प्लेटफॉर्म पर उत्पादन सेवा विकसित करने के लिए पर्याप्त हैं।

मोबाइल एप्लिकेशन विकसित करने के लिए क्रमशः Android और iOS के लिए जावा और ऑब्जेक्टिव-सी के ज्ञान की आवश्यकता होगी।

स्थापना और लॉन्च

आज WCS को जल्दी से लॉन्च करने के तीन तरीके हैं:

1) Ubuntu 16.x LTS या Ubuntu 18.x LTS आदि इंस्टॉल करें। अपने Centos7 पर। या प्रलेखन से लेख द्वारा निर्देशित किया जाएगा।

या

2) अमेज़ॅन ईसी 2 पर तैयार छवि प्राप्त करें।

या

3) डिजिटल महासागर पर सर्वर तैयार छवि प्राप्त करें ।

और स्ट्रीमिंग वीडियो सुविधाओं के साथ एक रोमांचक परियोजना विकास शुरू करें।

समीक्षा लेख काफी बड़ा निकला। इसे पढ़ने के लिए धैर्य के लिए धन्यवाद।

एक अच्छी स्ट्रीमिंग है!

लिंक

WCS 5.2 - WebRTC सर्वर

स्थापना और लॉन्च

स्थापना और लॉन्च WCS
Amazon EC2 पर तैयार छवि लॉन्च करें
DigitalOcean पर सर्वर से तैयार छवि लॉन्च करें

एसडीके

प्रलेखन वेब एसडीके
प्रलेखन Android एसडीके
प्रलेखन iOS एसडीके

मामले

आने वाली धाराएँ
बहती धाराएँ
धाराओं का प्रबंधन
स्ट्रीम रिले
कम विलंबता WebRTC स्ट्रीमिंग के लिए CDN

प्रलेखन

प्रलेखन वेब कॉल सर्वर 5.2