WebRTC - स्केलेबल लाइव स्ट्रीम प्रसारण / मल्टीकास्टिंग

Question

संकट:

WebRTC हमें पीयर-टू-पीयर वीडियो / ऑडियो कनेक्शन देता है। यह पी 2 पी कॉल, हैंगआउट के लिए एकदम सही है। लेकिन प्रसारण के बारे में क्या है (उदाहरण के लिए, 1 से 10000 तक)?

कहते हैं कि हमारे पास एक ब्रॉडकास्टर "बी" और दो उपस्थित "ए 1", "ए 2" हैं। निश्चित रूप से यह सॉल्व करने योग्य लगता है: हम सिर्फ B को A1 से और फिर B को A2 से जोड़ते हैं। तो B, सीधे A1 में वीडियो / ऑडियो स्ट्रीम भेजता है और A2 को दूसरी स्ट्रीम देता है। B धाराएँ दो बार भेजता है।

अब कल्पना करते हैं कि 10000 उपस्थित हैं: A1, A2, ..., A10000। इसका मतलब है कि बी को 10000 स्ट्रीम भेजने होंगे। प्रत्येक स्ट्रीम ~ 40KB / s है जिसका मतलब है कि इस प्रसारण को बनाए रखने के लिए B को 400MB / s आउटगोइंग इंटरनेट स्पीड की आवश्यकता है। गवारा नहीं।

मूल प्रश्न (OBSOLETE)

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

या शायद इसका मतलब है WebRTC विचार को बर्बाद करना?

टिप्पणियाँ

Flash अंतिम ग्राहकों के लिए खराब UX के अनुसार मेरी जरूरतों के लिए काम नहीं कर रहा है।

समाधान (वास्तव में नहीं)

26.05.2015 - फिलहाल WebRTC के लिए स्केलेबल प्रसारण के लिए ऐसा कोई समाधान नहीं है, जहाँ आप मीडिया-सर्वरों का उपयोग बिल्कुल नहीं करते हैं। बाजार पर सर्वर-साइड समाधान के साथ-साथ हाइब्रिड (पी 2 पी + सर्वर-साइड अलग-अलग स्थितियों के आधार पर) हैं।

कुछ होनहार तकनीकें हैं, जैसे https://github.com/muaz-khan/WebRTC-Scalable-Broadcast लेकिन उन्हें उन संभावित मुद्दों का जवाब देने की आवश्यकता है: विलंबता, समग्र नेटवर्क कनेक्शन स्थिरता, स्केलेबिलिटी सूत्र (वे अनंत-स्केलेबल नहीं हैं) )।

सुझाव

1. ऑडियो और वीडियो कोडेक्स दोनों को मिलाकर सीपीयू / बैंडविड्थ घटाएं;
2. एक मीडिया सर्वर प्राप्त करें।

Comments

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

— डार्क फाल्कन

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

— डार्क फाल्कन

कम से कम दो कंपनियां हैं जिनके बारे में मुझे जानकारी है कि वे वी-बीटी-आधारित पी 2 पी वीडियो वितरण करने की कोशिश कर रही हैं: affovi.com/rtcplayer.html - ज्यादातर लाइव वीडियो के लिए; और peer5.com - ज्यादातर वीओडी के लिए।

— स्वेतलिन म्लादेनोव

@igorpavlov आप जांच कर सकते हैं: github.com/muaz-khan/WebRTC-Scalable-Broadcast हालांकि यह केवल क्रोम में काम करता है, और अभी तक कोई ऑडियो-प्रसारण नहीं है।

— मुज़ ख़ान

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

— बेंजामिन ट्रेंट

Answer 1

जैसा कि यह यहाँ बहुत कवर किया गया था, आप यहाँ जो करने की कोशिश कर रहे हैं वह सादे, पुराने जमाने की वेबआरटीसी (सख्ती से सहकर्मी से सहकर्मी) के साथ संभव नहीं है। क्योंकि जैसा कि पहले कहा गया था, WebRTC प्रत्येक सत्र के लिए डेटा को एन्क्रिप्ट करने के लिए एन्क्रिप्शन कुंजी को फिर से सेट करता है। तो आपके ब्रॉडकास्टर (B) को वास्तव में अपनी स्ट्रीम को अपलोड करने की आवश्यकता होगी क्योंकि इसमें कई बार उपस्थित होते हैं।

हालांकि, एक काफी सरल उपाय है, जो बहुत अच्छी तरह से काम करता है: मैंने इसका परीक्षण किया है, इसे वेबआरटीसी गेटवे कहा जाता है। जानूस इसका एक अच्छा उदाहरण है। यह पूरी तरह से खुला स्रोत है ( जीथब रेपो यहां )।

यह निम्नानुसार काम करता है: आपका ब्रॉडकास्टर गेटवे (जानूस) से संपर्क करता है जो वेबआरटीसी बोलता है । इसलिए एक महत्वपूर्ण वार्ता है: बी, जानूस को सुरक्षित रूप से (एन्क्रिप्टेड स्ट्रीम) पहुंचाता है।

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

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

तो हाँ, यह करता है एक सर्वर शामिल है, लेकिन यह है कि सर्वर WebRTC बोलती है, और आप "स्वयं" यह: आप जानूस हिस्सा लागू ताकि आप डेटा भ्रष्टाचार या बीच में आदमी के बारे में चिंता की जरूरत नहीं है। जब तक आपके सर्वर से समझौता नहीं किया जाता है, तब तक। लेकिन ऐसा बहुत कुछ है जो आप कर सकते हैं।

आपको यह दिखाने के लिए कि इसका उपयोग करना कितना आसान है, जानूस में, आपके पास एक फ़ंक्शन incoming_rtp()(और incoming_rtcp()) है जिसे आप कॉल कर सकते हैं, जो आपको आरटी (सी) पी पैकेट के लिए एक संकेतक देता है। फिर आप इसे प्रत्येक सहभागी को भेज सकते हैं (वे sessionsउस Janus में संग्रहीत किए जाते हैं जो उपयोग करने में बहुत आसान है)। फ़ंक्शन के एक कार्यान्वयन के लिए यहां देखेंincoming_rtp() , नीचे दी गई कुछ पंक्तियों में आप देख सकते हैं कि पैकेट को सभी सहभागियों तक कैसे पहुंचाया जाए और यहां आप आरटीपी पैकेट को रिले करने के लिए वास्तविक फ़ंक्शन देख सकते हैं।

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

मज़े करो! आशा है कि मैंने मदद की।

Comments

क्या यह कहना सही है कि यह वर्तमान में सफारी में काम नहीं करता है (या कोई भी ब्राउज़र जो WebRTC का समर्थन नहीं करता है?)। क्या किसी को हाइब्रिड समाधान का पता है जहां आप वेबआरटीसी का उपयोग करके ब्राउज़र से सर्वर पर प्रसारित करते हैं फिर वीडियो को एचएलएस / एचडीएस (या आरटीएमपी) को एक पारंपरिक प्रसारण प्रणाली में फिट करने के लिए ट्रांसकोड करते हैं?

— बेन

@ हाँ, यह उन ब्राउज़रों के साथ काम नहीं करता है जो WebRTC का समर्थन नहीं करते हैं। वापस दिनों में (जब मैं यह लिखता हूं) सफारी स्पष्ट रूप से इसका समर्थन नहीं कर रहा था। हालाँकि आज मैंने जाँच नहीं की है। लेकिन मुझे अभी भी लगता है कि वे WebRTC का समर्थन नहीं करते (हालांकि पुष्टि की जा सकती है)। हाइब्रिड सिस्टम में इसका उपयोग करने के लिए, यह पूरी तरह से संभव है, वास्तव में यह वही है जो मैंने उस कंपनी के लिए किया था, जिस पर मैंने काम किया था; जैसा कि आपने कहा, मैंने ब्राउज़र से सर्वर तक प्रसारित किया और वहाँ से, मैंने फीड ट्रांसकोड करने के लिए एक GStreamer पाइपलाइन का निर्माण और प्लग किया। आप यह भी कर सकते हैं!

— nschoe

जित्ती के बारे में कोई विचार? क्या जिस्मि भी वही है?

— ishandutta2007

@nschoe क्या ऐसा करने के लिए वेबसोकेट का उपयोग करने से बेहतर है?

— नवगीत

आप वास्तव में बता रहे हैं कि SFU (सेलेक्टिव फ़ॉरवर्डिंग यूनिट) कैसे काम करता है। आप mediasoup के

— डिर्क वी

Answer 2

जैसा @MazazKhan ने ऊपर उल्लेख किया है:

https://github.com/muaz-khan/WebRTC-Scalable-Broadcast

क्रोम में काम करता है, और अभी तक कोई ऑडियो-प्रसारण नहीं है, लेकिन यह 1 समाधान लगता है।

एक स्केलेबल WebRTC सहकर्मी से सहकर्मी प्रसारण डेमो।

यह मॉड्यूल बस सॉकेट.आईओ को इनिशियलाइज़ करता है और इसे इस तरह से कॉन्फ़िगर करता है कि सिंगल ब्रॉडकास्ट असीमित उपयोगकर्ताओं पर बिना किसी बैंडविड्थ / सीपीयू के उपयोग के मुद्दों से रिलेटेड हो सकता है। सब कुछ होता है पीयर-टू-पीयर!

यह निश्चित रूप से पूरा करना संभव होना चाहिए।
दूसरों को भी यह हासिल करने में सक्षम हैं: http://www.streamroot.io/

Comments

यह सामान मेरे लिए थोड़ा अलग है। इस विचार पर कोई अपडेट या विचार?

— igorpavlov

भी, यह किसी भी तरह विलंबता समस्याओं को हल करता है? उदाहरण के लिए, Peer1, Peer5 से बातचीत करता है और Peer2 अंततः कनेक्शन खो देता है। या यह वास्तुकला केवल लैन के लिए अच्छा है?

— igorpavlov

इसके अलावा, क्या स्ट्रीमरोट Peer5 के समान है?

— igorpavlov

Answer 3

AFAIK इस का एकमात्र वर्तमान कार्यान्वयन है जो प्रासंगिक और परिपक्व है Adobe Flash Player, जिसने पीयर 2 के लिए पीयर टू पीयर वीडियो प्रसारण के बाद से p2p मल्टीकास्ट का समर्थन किया है।

http://tomkrcha.com/?p=1526 ।

Comments

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

— igorpavlov

अधिक सहमत नहीं हो सका।

— टॉम

खराब ऑक्स के अलावा, क्या यह समाधान होगा? सर्वर कम?

— रूबो77

Answer 4

इंटरनेट पर "स्केलेबल" प्रसारण संभव नहीं है, क्योंकि आईपी यूडीपी मल्टीकास्टिंग की अनुमति नहीं है। लेकिन सिद्धांत रूप में यह एक लैन पर संभव है।
Websockets के साथ समस्या यह है कि आपके पास डिज़ाइन द्वारा RAW UDP तक पहुँच नहीं है और इसे अनुमति नहीं दी जाएगी।
WebRTC के साथ समस्या यह है कि यह डेटा चैनल SRTP के एक रूप का उपयोग करता है, जहाँ प्रत्येक सत्र की अपनी एन्क्रिप्शन कुंजी होती है। इसलिए जब तक कि कोई "इन्वेंट" या एपीआई एक तरह से सभी क्लाइंट के बीच एक सत्र की कुंजी साझा करने की अनुमति नहीं देता , तब तक मल्टीकास्ट बेकार है।

Comments

लेकिन चैट पहले से ही WebRTC के साथ काम करते हैं, इसलिए हर कोई हर संदेश देखता है, इसलिए एक-से कई को वीडियो के लिए भी काम करना चाहिए

— rubo77

@ rubo77 वीडियो संदेश के साथ भेजे गए डेटा की दर और मात्रा की तुलना में पाठ संदेश के साथ भेजा गया डेटा बिल्कुल भी नहीं है। तो चैट में आसानी से एक बार में अधिक उपयोगकर्ता waayy को शामिल कर सकते हैं

— डिर्क वी

Answer 5

पीयर-असिस्टेड डिलीवरी का समाधान है, जिसका अर्थ है कि दृष्टिकोण हाइब्रिड है। सर्वर और साथियों दोनों संसाधन वितरित करने में मदद करते हैं। यह दृष्टिकोण peer5.com और peercdn.com ने लिया है।

यदि हम लाइव प्रसारण के बारे में विशेष रूप से बात कर रहे हैं तो यह कुछ इस तरह दिखाई देगा:

1. ब्रॉडकास्टर लाइव वीडियो को सर्वर पर भेजता है।
2. सर्वर वीडियो को बचाता है (आमतौर पर इसे सभी संबंधित प्रारूपों में ट्रांसकोड करता है)।
3. इस लाइव स्ट्रीम के बारे में मेटाडेटा बनाया जा रहा है, जो HLS या HDS या MPEG_DASH के साथ संगत है
4. उपभोक्ता संबंधित लाइव स्ट्रीम में ब्राउज़ करते हैं, वहां प्लेयर को मेटाडेटा मिलता है और यह पता चलता है कि वीडियो के अगले हिस्से को कौन सा हिस्सा प्राप्त करना है।
5. उसी समय उपभोक्ता को अन्य उपभोक्ताओं (WebRTC के माध्यम से) से जोड़ा जा रहा है
6. फिर खिलाड़ी संबंधित चंक को सर्वर से या साथियों से सीधे डाउनलोड करता है।

इस तरह के एक मॉडल के बाद लाइव स्ट्रीम की बिटरेट और दर्शकों के सहयोगी अपलिंक के आधार पर सर्वर की बैंडविड्थ के ~ 90% तक की बचत हो सकती है।

अस्वीकरण: लेखक Peer5 पर काम कर रहा है

Comments

धन्यवाद। मुझे peer5 के बारे में पता है और यह एक बहुत ही आकर्षक समाधान है। हालांकि, इस सवाल का उद्देश्य एक समाधान बिल्कुल सर्वर-कम (केवल STUN / TURN की अनुमति है) खोजना था।

— igorpavlov

Answer 6

मेरे स्वामी वेबआरटीसी का उपयोग करके हाइब्रिड सीडीएन / पी 2 पी लाइव स्ट्रीमिंग प्रोटोकॉल के विकास पर केंद्रित हैं। मैंने अपना पहला परिणाम http://bem.tv पर प्रकाशित किया है

सब कुछ खुला स्रोत है और मैं योगदानकर्ताओं की तलाश कर रहा हूं! :-)

Comments

क्या आप किसी भी तरह के सर्वर साइड सॉफ्टवेयर थोड़े MCU का उपयोग करते हैं?

— igorpavlov

मैं वास्तव में rtcio लोगों से कुछ सर्वर साइड कंपोनेंट्स का उपयोग कर रहा हूं: github.com/rtc-io

— flavioribeiro

ऐसा लगता है कि आप सिग्नलिंग के लिए उनके घटकों का उपयोग करते हैं। सर्वर साइड वीडियो स्ट्रीमिंग के बारे में कैसे? या आप समाधान बिल्कुल पी 2 पी है?

— igorpavlov

आपको @igorpavlov को जवाब देने में लंबे समय तक देरी के लिए खेद है, मैं वीडियो को खंडित करने के लिए EvoStream का उपयोग कर रहा हूं और मैं एक वीडियो स्रोत पा रहा हूं और Elemental encoder का उपयोग करके EvoStream की ओर इशारा करता हूं।

— फ्लेवरियोबिरो 22

यह एक मीडिया सर्वर प्रदाता है। अधिक कुशल? शायद। यह वही है जो मैं देख रहा हूँ? नंबर

— igorpavlov 22

Answer 7

एंजेल गेंशेव का उत्तर सही प्रतीत होता है, हालांकि, एक सैद्धांतिक वास्तुकला है, जो वेबआरटीसी के माध्यम से कम विलंबता प्रसारण की अनुमति देता है। बी (ब्रॉडकास्टर) ए 1 की कल्पना करें (सहभागी 1)। फिर A2 (सहभागी 2) जोड़ता है। B से A2 की स्ट्रीमिंग के बजाय, A1, B से A2 तक प्राप्त किया जा रहा वीडियो स्ट्रीमिंग करना शुरू कर देता है। यदि A1 डिस्कनेक्ट हो जाता है तो A2, B से प्राप्त करना शुरू कर देता है।

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

फिलहाल मैं सर्वर साइड सॉल्यूशन का उपयोग कर रहा हूं।

Comments

सर्वर साइड समाधान में धारा की गति के बारे में क्या? कृपया बाँटें।

— user2003356

सर्वर साइड समाधान का मतलब है? आपने क्या इस्तेमाल किया? यह मेरे शोध के लिए मददगार होगा। कृपया बाँटें। धन्यवाद।

— user2003356

सर्वर साइड सॉल्यूशन का मतलब है टोकोबॉक्स द्वारा ओपेंथोक। मैं उन्हें विज्ञापित नहीं करता हूं, बाजार पर ऐसे समाधान के टन हैं, लेकिन मैं इस एक के साथ रहता हूं। यह एक मीडिया सर्वर की तरह काम कर रहा है। PS बहु-पार्टी संचार से आपका क्या अभिप्राय है? मुझे नहीं मिला।

— igorpavlov

@igorpavlov क्या आप उन कंपनियों की सूची दे सकते हैं जो सर्वर साइड वेबट्रक प्रदान करती हैं? मैं केवल Flashphoner और Opentok को जानता हूं। धन्यवाद

— रामिल अमेरज़ान्योव

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

— बेंजामिन ट्रेंट

Answer 8

WebRTC स्केलेबल समाधान के लिए बाजार में कुछ समाधान उपलब्ध हैं। वे कम विलंबता, स्केलेबल वेब्र्टक स्ट्रीमिंग प्रदान करते हैं। यहाँ कुछ नमूने हैं। जानूस , Jitsi , Wowza , Red5pro , चींटी मीडिया सर्वर

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

Answer 9

आप एक से कई आवश्यकता के साथ WebRTC का उपयोग करने का वर्णन कर रहे हैं। WebRTC को पीयर-टू-पीयर स्ट्रीमिंग के लिए डिज़ाइन किया गया है, हालांकि ऐसे कॉन्फ़िगरेशन हैं जो आपको कई दर्शकों को वीडियो वितरित करते समय WebRTC की कम विलंबता से लाभ देंगे।

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

एक फोन से कुशलता से स्ट्रीम करने के लिए आप Wowza के GoCoder SDK का उपयोग कर सकते हैं लेकिन मेरे अनुभव में एक और अधिक उन्नत SDK जैसे कि स्ट्रीमगैस सबसे अच्छा काम करता है।

Answer 10

मैं Kurento मीडिया सर्वर का उपयोग कर WebRTC प्रसारण प्रणाली विकसित कर रहा हूँ । Kurento कई तरह के स्ट्रीमिंग प्रोटोकॉल का समर्थन करता है जैसे RTSP, WebRTC, HLS। यह वास्तविक समय और स्केलिंग के रूप में अच्छी तरह से काम करता है।

इसलिए, Kurento RTMP का समर्थन नहीं करता है जो कि Youtube या Twitch में उपयोग किया जाता है। मेरे साथ एक समस्या यह है कि इसके साथ उपयोगकर्ता समवर्ती की संख्या है।

आशा है कि यह मदद करेगा।

Answer 11

चूंकि peer1 केवल सहकर्मी है जो getUserMedia () को आमंत्रित करता है यानी peer1 एक कमरा बनाता है।

1. तो, peer1 मीडिया को पकड़ता है और कमरा शुरू करता है।
2. peer2 कमरे से जुड़ता है और peer1 से स्ट्रीम (डेटा) प्राप्त करता है और "peer2- कनेक्शन" के नाम से समानांतर कनेक्शन भी खोलता है
3. जब पीयर 3 कमरे से जुड़ता है और पीयर 2 से स्ट्रीम (डेटा) प्राप्त करता है और समानांतर कनेक्शन को 'पीयर 3-कनेक्शन' के रूप में भी नामांकित करता है।

यह प्रक्रिया निरंतर होती है क्योंकि कई सहकर्मी एक दूसरे से जुड़ जाते हैं।

इसलिए, इसके द्वारा एकल प्रसारण को असीमित उपयोगकर्ताओं को बिना किसी बैंडविड्थ / सीपीयू की समस्याओं के स्थानांतरित किया जा सकता है।

अंत में, उपरोक्त सभी लिंक से संदर्भ है ।

Comments

यह दृष्टिकोण पहले ही उल्लेख किया गया था, लेकिन यह वास्तविक दुनिया में काम नहीं कर सकता है। Peer3 के रूप में, मुझे Peer2 के बैंडविड्थ प्रदर्शन की परवाह क्यों करनी चाहिए? बेशक, पीयर 3 पीयर 1 को गिर सकता है यदि पीयर 2 श्रृंखला छोड़ देता है, लेकिन इससे टन की रुकावट, पुन: संयोजन आदि हो जाएंगे। आगे मैं श्रृंखला में हूं, और अधिक मैं पीड़ित हूं। तो, हाँ, लैन पर काम कर सकता है, लेकिन शायद यही है।

— igorpavlov

समानांतर प्रसारण बैंडविड्थ का ध्यान नहीं रखता है और यदि एक बार peer3 के कनेक्शन की स्थापना peer2 के माध्यम से peer1 और इस तरह से कि peer2 की वापसी हो जाती है, तो peer3 peer1 से जुड़ा रहता है।

— सुसान ०

मुझे यकीन नहीं है कि मैं समझता हूं। मैं वास्तव में लिंक का जिक्र नहीं कर रहा था, अब मुझे संदर्भ दें। यह लिंक github.com/muaz-khan/WebRTC-Scalable-Broadcast में "यह कैसे काम करता है?" अनुभाग। यह छवि आपको स्पष्ट रूप से बताती है कि एक बार, मान लें कि Peer5 डिस्कनेक्ट, Peer8,9 और 10 प्रसारण से डिस्कनेक्ट हो गए हैं। उन्हें Peer2 या Peer6 से कनेक्ट करने की आवश्यकता होगी, लेकिन यह लैग का कारण होगा। साथ ही, इस परियोजना में न तो योगदान है, न ही गतिविधि।

— igorpavlov