WebRTC - การถ่ายทอดสดสตรีม / มัลติคาสติ้งที่ปรับขนาดได้

ปัญหา:

WebRTC ช่วยให้เราสามารถเชื่อมต่อวิดีโอ / เสียงแบบเพียร์ทูเพียร์ เหมาะสำหรับการโทรแบบ p2p แฮงเอาท์ แต่สิ่งที่เกี่ยวกับการแพร่ภาพ (หนึ่งต่อกลุ่มเช่น 1 ต่อ 10,000)?

สมมติว่าเรามีผู้ออกอากาศ "B" และผู้เข้าร่วมสองคน "A1", "A2" แน่นอนว่ามันดูเหมือนจะแก้ได้: เราแค่เชื่อม B กับ A1 แล้วก็ B กับ A2 ดังนั้น B จึงส่งสตรีมวิดีโอ / เสียงโดยตรงไปยัง A1 และสตรีมอื่นไปยัง A2 B ส่งสตรีมสองครั้ง

ลองนึกภาพว่ามีผู้เข้าร่วม 10,000 คน: A1, A2, ... , A10000 หมายความว่า B ต้องส่งสตรีม 10,000 สตรีม แต่ละสตรีมมีค่า ~ 40KB / s ซึ่งหมายความว่า B ต้องการความเร็วอินเทอร์เน็ตขาออก 400MB / s เพื่อรักษาการออกอากาศนี้ รับไม่ได้

คำถามเดิม (เลิกใช้แล้ว)

เป็นไปได้หรือไม่ที่จะแก้ปัญหานี้ดังนั้น B จึงส่งสตรีมเพียงครั้งเดียวในบางเซิร์ฟเวอร์และผู้เข้าร่วมเพียงแค่ดึงสตรีมนี้จากเซิร์ฟเวอร์นี้ ใช่หมายความว่าความเร็วขาออกบนเซิร์ฟเวอร์นี้จะต้องสูง แต่ฉันสามารถรักษาได้

หรืออาจหมายถึงการทำลายแนวคิด WebRTC?

หมายเหตุ

Flash ไม่ทำงานตามความต้องการของฉันเนื่องจาก UX ที่ไม่ดีสำหรับลูกค้าปลายทาง

วิธีแก้ปัญหา (ไม่ใช่จริงๆ)

26.05.2015 - ไม่มีวิธีแก้ปัญหาดังกล่าวสำหรับการออกอากาศที่ปรับขนาดได้สำหรับ WebRTC ในขณะนี้ซึ่งคุณไม่ได้ใช้เซิร์ฟเวอร์สื่อเลย มีโซลูชันฝั่งเซิร์ฟเวอร์เช่นเดียวกับไฮบริด (ฝั่งเซิร์ฟเวอร์ p2p + ขึ้นอยู่กับเงื่อนไขที่แตกต่างกัน) ในตลาด

มีเทคโนโลยีที่น่าสนใจบางอย่างเช่นhttps://github.com/muaz-khan/WebRTC-Scalable-Broadcastแต่พวกเขาต้องการที่จะตอบปัญหาที่เป็นไปได้เหล่านี้: เวลาแฝงความเสถียรของการเชื่อมต่อเครือข่ายโดยรวมสูตรความสามารถในการปรับขนาด (อาจไม่สามารถปรับขนาดได้ไม่สิ้นสุด )

คำแนะนำ

1. ลด CPU / แบนด์วิดท์โดยการปรับแต่งทั้งตัวแปลงสัญญาณเสียงและวิดีโอ
2. รับเซิร์ฟเวอร์สื่อ

ตามที่กล่าวไว้ในที่นี้ค่อนข้างมากสิ่งที่คุณพยายามทำที่นี่จึงเป็นไปไม่ได้กับ WebRTC แบบเก่า (แบบเพียร์ทูเพียร์อย่างเคร่งครัด) เนื่องจากตามที่ได้กล่าวไว้ก่อนหน้านี้การเชื่อมต่อ WebRTC จะเจรจาต่อรองคีย์การเข้ารหัสใหม่เพื่อเข้ารหัสข้อมูลสำหรับแต่ละเซสชัน ดังนั้นผู้ออกอากาศของคุณ (B) จะต้องอัปโหลดสตรีมหลาย ๆ ครั้งตามที่มีผู้เข้าร่วม

อย่างไรก็ตามมีวิธีแก้ปัญหาที่ค่อนข้างง่ายซึ่งใช้งานได้ดี: ฉันได้ทดสอบแล้วเรียกว่าเกตเวย์ WebRTC เจนัสเป็นตัวอย่างที่ดี เป็นโอเพ่นซอร์สอย่างสมบูรณ์ ( github repo ที่นี่ )

ผลงานนี้เป็นดังนี้: รายชื่อโฆษกของคุณเกตเวย์ (เจนัส) ซึ่งพูด WebRTC ดังนั้นจึงมีการเจรจาที่สำคัญ: B ส่ง (สตรีมที่เข้ารหัส) อย่างปลอดภัยไปยัง Janus

ตอนนี้เมื่อผู้เข้าร่วมเชื่อมต่อพวกเขาจะเชื่อมต่อกับ Janus อีกครั้ง: การเจรจา WebRTC คีย์ที่ปลอดภัยเป็นต้นจากนี้ไป Janus จะส่งกระแสข้อมูลกลับไปยังผู้เข้าร่วมแต่ละคน

วิธีนี้ใช้งานได้ดีเนื่องจากผู้ออกอากาศ (B) อัปโหลดสตรีมเพียงครั้งเดียวไปยัง Janus ตอนนี้ Janus ถอดรหัสข้อมูลโดยใช้คีย์ของตัวเองและสามารถเข้าถึงข้อมูลดิบ (นั่นคือแพ็กเก็ต RTP) และสามารถส่งแพ็กเก็ตเหล่านั้นกลับไปยังผู้เข้าร่วมแต่ละคนได้ (Janus ดูแลการเข้ารหัสให้คุณ) และเนื่องจากคุณวาง Janus บนเซิร์ฟเวอร์จึงมีแบนด์วิดท์การอัปโหลดที่ยอดเยี่ยมดังนั้นคุณจึงสามารถสตรีมไปยังเครื่องเพียร์จำนวนมากได้

ดังนั้นใช่มันไม่เกี่ยวข้องกับเซิร์ฟเวอร์ แต่เซิร์ฟเวอร์ที่พูด WebRTC และคุณ "ตัวเอง" มัน: คุณใช้ส่วนเจนัสเพื่อให้คุณไม่ต้องกังวลเกี่ยวกับความเสียหายของข้อมูลหรือคนที่อยู่ตรงกลาง แน่นอนเว้นแต่เซิร์ฟเวอร์ของคุณจะถูกบุกรุกแน่นอน แต่มีหลายสิ่งที่คุณสามารถทำได้

เพื่อแสดงให้คุณเห็นว่าการใช้งานนั้นง่ายเพียงใดใน Janus คุณมีฟังก์ชันที่เรียกว่าincoming_rtp()(and incoming_rtcp()) ที่คุณสามารถเรียกได้ซึ่งจะให้ตัวชี้ไปยังแพ็กเก็ต rt (c) p จากนั้นคุณสามารถส่งไปยังผู้เข้าร่วมแต่ละคน (พวกเขาจะถูกเก็บไว้ในsessionsที่ Janus ใช้งานง่ายมาก) ดูที่นี่สำหรับหนึ่งในการดำเนินงานของincoming_rtp()ฟังก์ชั่น , คู่สายด้านล่างคุณสามารถดูวิธีการส่งแพ็คเก็ตที่จะเข้าร่วมประชุมทั้งหมดและที่นี่คุณสามารถดูฟังก์ชั่นที่เกิดขึ้นจริงในการถ่ายทอดแพ็คเก็ต RTP

ทุกอย่างใช้งานได้ดีเอกสารประกอบค่อนข้างอ่านและเข้าใจง่าย ฉันขอแนะนำให้คุณเริ่มต้นด้วยตัวอย่างที่ "ดีที่สุด" ซึ่งเป็นวิธีที่ง่ายที่สุดและคุณสามารถเข้าใจการทำงานภายในของเจนัสได้ ฉันขอแนะนำให้คุณแก้ไขไฟล์ทดสอบเสียงสะท้อนเพื่อสร้างเป็นของคุณเองเนื่องจากมีโค้ดซ้ำซ้อนจำนวนมากที่ต้องเขียนดังนั้นคุณอาจเริ่มจากไฟล์ที่สมบูรณ์

มีความสุข! หวังว่าฉันจะช่วย

ดังที่ @MuazKhan ระบุไว้ข้างต้น:

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

ทำงานในโครเมี่ยมและยังไม่มีการแพร่ภาพเสียง แต่ดูเหมือนว่าจะเป็นโซลูชันแรก

การสาธิตการออกอากาศแบบเพียร์ทูเพียร์ WebRTC ที่ปรับขนาดได้

โมดูลนี้เพียงแค่เริ่มต้น socket.io และกำหนดค่าในลักษณะที่สามารถถ่ายทอดเดี่ยวผ่านผู้ใช้ที่ไม่ จำกัด โดยไม่มีปัญหาการใช้แบนด์วิดท์ / CPU ทุกอย่างเกิดขึ้นแบบ peer-to-peer!

สิ่งนี้น่าจะทำได้อย่างแน่นอน
คนอื่น ๆ ก็สามารถทำได้เช่นกัน: http://www.streamroot.io/

AFAIK การใช้งานในปัจจุบันเพียงอย่างเดียวที่เกี่ยวข้องและเป็นผู้ใหญ่คือ Adobe Flash Player ซึ่งรองรับ p2p multicast สำหรับการแพร่ภาพวิดีโอแบบเพียร์ทูเพียร์ตั้งแต่เวอร์ชัน 10.1

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

การแพร่ภาพแบบ "ปรับขนาดได้" บนอินเทอร์เน็ตไม่สามารถทำได้เนื่องจากไม่อนุญาตให้มีการกระจายสัญญาณ IP UDP ที่นั่น แต่ในทางทฤษฎีเป็นไปได้บน LAN
ปัญหาของ Websockets คือคุณไม่สามารถเข้าถึง RAW UDP โดยการออกแบบและจะไม่ได้รับอนุญาต
ปัญหาของ WebRTC คือช่องข้อมูลใช้รูปแบบของ SRTP ซึ่งแต่ละเซสชันมีคีย์เข้ารหัสของตัวเอง ดังนั้นถ้าไม่มีใคร "ประดิษฐ์" หรือ API อนุญาตให้แชร์คีย์เซสชันหนึ่งคีย์ระหว่างไคลเอนต์ทั้งหมดมัลติคาสต์ก็ไม่มีประโยชน์

มีวิธีแก้ปัญหาของการจัดส่งแบบเพื่อนซึ่งหมายความว่าแนวทางนี้เป็นแบบไฮบริด ทั้งเซิร์ฟเวอร์และเพียร์ช่วยกระจายทรัพยากร นั่นเป็นแนวทางที่peer5.comและpeercdn.comได้ดำเนินการ

หากเรากำลังพูดถึงการถ่ายทอดสดโดยเฉพาะจะมีลักษณะดังนี้:

1. โฆษกส่งวิดีโอถ่ายทอดสดไปยังเซิร์ฟเวอร์
2. เซิร์ฟเวอร์จะบันทึกวิดีโอ (โดยปกติจะแปลงเป็นรูปแบบที่เกี่ยวข้องทั้งหมดด้วย)
3. กำลังสร้างข้อมูลเมตาเกี่ยวกับสตรีมแบบสดนี้ซึ่งเข้ากันได้กับ HLS หรือ HDS หรือ MPEG_DASH
4. ผู้บริโภคเรียกดูสตรีมแบบสดที่เกี่ยวข้องที่นั่นผู้เล่นจะได้รับข้อมูลเมตาและรู้ว่าส่วนใดของวิดีโอที่จะได้รับต่อไป
5. ในขณะเดียวกันผู้บริโภคก็เชื่อมต่อกับผู้บริโภครายอื่น (ผ่าน WebRTC)
6. จากนั้นผู้เล่นจะดาวน์โหลดส่วนที่เกี่ยวข้องโดยตรงจากเซิร์ฟเวอร์หรือจากเพื่อน

การทำตามโมเดลดังกล่าวสามารถประหยัดแบนด์วิดท์ของเซิร์ฟเวอร์ได้ถึง 90% ขึ้นอยู่กับบิตเรตของสตรีมแบบสดและการอัปลิงค์ร่วมกันของผู้ชม

ข้อจำกัดความรับผิดชอบ: ผู้เขียนทำงานที่ Peer5

ผู้เชี่ยวชาญของฉันมุ่งเน้นไปที่การพัฒนาโปรโตคอลสตรีมมิงแบบสด cdn / p2p แบบไฮบริดโดยใช้ WebRTC ฉันได้เผยแพร่ผลลัพธ์แรกของฉันที่http://bem.tv

ทุกอย่างเป็นโอเพ่นซอร์สและฉันกำลังมองหาผู้มีส่วนร่วม! :-)

คำตอบจาก Angel Genchev ดูเหมือนจะถูกต้อง แต่มีสถาปัตยกรรมทางทฤษฎีที่ช่วยให้การออกอากาศเวลาแฝงต่ำผ่าน WebRTC ลองนึกภาพ B (ผู้ออกอากาศ) สตรีมไปที่ A1 (ผู้เข้าร่วม 1) จากนั้น A2 (ผู้เข้าร่วม 2) เชื่อมต่อ แทนที่จะสตรีมจาก B ไป A2 A1 จะเริ่มสตรีมวิดีโอที่ได้รับจาก B ถึง A2 ถ้า A1 ตัดการเชื่อมต่อ A2 จะเริ่มรับจาก B

สถาปัตยกรรมนี้สามารถทำงานได้หากไม่มีเวลาแฝงและหมดเวลาการเชื่อมต่อ ดังนั้นในทางทฤษฎีมันถูกต้อง แต่ไม่ใช่ในทางปฏิบัติ

ในขณะนี้ฉันใช้โซลูชันฝั่งเซิร์ฟเวอร์

มีโซลูชันบางอย่างในตลาดสำหรับโซลูชันที่ปรับขนาดได้ของ WebRTC มีเวลาแฝงต่ำสตรีมมิ่ง webrtc ที่ปรับขนาดได้ นี่คือตัวอย่างบางส่วน Janus , Jitsi , Wowza , Red5pro , Ant Media Server

ฉันเป็นนักพัฒนาสำหรับAnt Media Serverเรามีทั้งรุ่นชุมชนและองค์กรรวมถึง Android และ iOS SDK ด้วย โปรดแจ้งให้เราทราบหากสามารถช่วยคุณได้

คุณกำลังอธิบายโดยใช้ WebRTC ที่มีข้อกำหนดแบบหนึ่งต่อกลุ่ม WebRTC ได้รับการออกแบบมาสำหรับการสตรีมแบบเพียร์ทูเพียร์อย่างไรก็ตามมีการกำหนดค่าที่จะช่วยให้คุณได้รับประโยชน์จากเวลาแฝงต่ำของ WebRTC ในขณะที่ส่งวิดีโอไปยังผู้ชมจำนวนมาก

เคล็ดลับคืออย่าเก็บภาษีไคลเอนต์สตรีมมิงกับผู้ชมทุกคนและเช่นเดียวกับที่คุณกล่าวถึงมีเซิร์ฟเวอร์สื่อ "รีเลย์" คุณสามารถสร้างสิ่งนี้ได้ด้วยตัวเอง แต่จริงๆแล้วทางออกที่ดีที่สุดคือการใช้ผลิตภัณฑ์ WebRTC Streamingของ Wowzaสินค้า

ในการสตรีมอย่างมีประสิทธิภาพจากโทรศัพท์คุณสามารถใช้ GoCoder SDK ของ Wowza ได้ แต่จากประสบการณ์ของฉัน SDK ขั้นสูงกว่าเช่นStreamGears จะทำงานได้ดีที่สุด

ฉันกำลังพัฒนาระบบกระจายเสียง WebRTC โดยใช้ไฟล์ Kurento Media ServerServer Kurento รองรับโปรโตคอลการสตรีมหลายประเภทเช่น RTSP, WebRTC, HLS ทำงานได้ดีทั้งในรูปแบบเรียลไทม์และการปรับขนาด

ดังนั้น Kurento จึงไม่รองรับ RTMP ที่ใช้ใน Youtube หรือ Twitch ในตอนนี้ ปัญหาอย่างหนึ่งของฉันคือจำนวนผู้ใช้พร้อมกันกับสิ่งนี้

หวังว่ามันจะช่วยได้

เนื่องจาก peer1 เป็นเพียงเพียร์ที่เรียกใช้ getUserMedia () เช่น peer1 สร้างห้อง

1. ดังนั้น peer1 จึงจับสื่อและเริ่มห้อง
2. peer2 เข้าร่วมห้องและรับสตรีม (ข้อมูล) จาก peer1 และเปิดการเชื่อมต่อแบบขนานที่ชื่อ "peer2-connection"
3. เมื่อ peer3 เข้าร่วมห้องและรับสตรีม (ข้อมูล) จาก peer2 และเปิดการเชื่อมต่อแบบขนานที่ชื่อ "peer3-connection" เป็นต้น

กระบวนการนี้ดำเนินไปอย่างต่อเนื่องเนื่องจากเพียร์จำนวนมากเชื่อมต่อกัน

ด้วยเหตุนี้การออกอากาศรายการเดียวจึงสามารถถ่ายโอนไปยังผู้ใช้ได้ไม่ จำกัด โดยไม่มีปัญหาการใช้แบนด์วิดท์ / CPU

สุดท้ายทั้งหมดที่อยู่ข้างต้นเป็นข้อมูลอ้างอิงจากการเชื่อมโยง