WebRTC - phát sóng luồng trực tiếp có thể mở rộng / đa hướng

VẤN ĐỀ:

WebRTC cung cấp cho chúng ta các kết nối video / âm thanh ngang hàng. Nó hoàn hảo cho các cuộc gọi p2p, hangout. Nhưng điều gì về phát sóng (một-nhiều, ví dụ, 1-10000)?

Giả sử chúng ta có một đài truyền hình "B" và hai người tham dự "A1", "A2". Tất nhiên nó có vẻ là có thể giải quyết được: chúng tôi chỉ cần kết nối B với A1 và sau đó B với A2. Vì vậy, B gửi trực tiếp luồng video / âm thanh tới A1 và một luồng khác tới A2. B gửi luồng hai lần.

Bây giờ hãy tưởng tượng có 10000 người tham dự: A1, A2, ..., A10000. Nó có nghĩa là B phải gửi 10000 luồng. Mỗi luồng là ~ 40KB / s có nghĩa là B cần tốc độ internet gửi đi 400MB / s để duy trì việc phát sóng này. Không thể chấp nhận được.

CÂU HỎI GỐC (OBSOLETE)

Có thể bằng cách nào đó để giải quyết điều này, vì vậy B chỉ gửi một luồng trên một số máy chủ và người tham dự chỉ cần kéo luồng này từ máy chủ này? Có, điều này có nghĩa là tốc độ gửi đi trên máy chủ này phải cao, nhưng tôi có thể duy trì nó.

Hoặc có thể điều này có nghĩa là làm hỏng ý tưởng WebRTC?

LƯU Ý

Flash không hoạt động theo nhu cầu của tôi theo UX kém cho khách hàng cuối.

GIẢI PHÁP (KHÔNG THỰC SỰ)

26.05.2015 - Không có giải pháp nào như vậy để phát sóng có thể mở rộng cho WebRTC tại thời điểm này, nơi bạn hoàn toàn không sử dụng máy chủ phương tiện. Có các giải pháp phía máy chủ cũng như kết hợp (p2p + phía máy chủ tùy thuộc vào các điều kiện khác nhau) trên thị trường.

Mặc dù có một số công nghệ đầy hứa hẹn như https://github.com/muaz-khan/WebRTC-Scalable-Broadcast nhưng chúng cần phải giải đáp những vấn đề có thể xảy ra: độ trễ, độ ổn định kết nối mạng tổng thể, công thức khả năng mở rộng (chúng có thể không phải là khả năng mở rộng vô hạn ).

ĐỀ XUẤT

1. Giảm CPU / Băng thông bằng cách tinh chỉnh cả codec âm thanh và video;
2. Nhận một máy chủ phương tiện.

Vì nó đã được đề cập khá nhiều ở đây, những gì bạn đang cố gắng làm ở đây không thể thực hiện được với WebRTC kiểu cũ, đơn giản (hoàn toàn là ngang hàng). Bởi vì như đã nói trước đó, các kết nối WebRTC thương lượng lại các khóa mã hóa để mã hóa dữ liệu, cho mỗi phiên. Vì vậy, đài truyền hình (B) của bạn thực sự sẽ cần tải lên luồng của mình nhiều lần khi có người tham dự.

Tuy nhiên, có một giải pháp khá đơn giản, hoạt động rất tốt: Tôi đã thử nghiệm nó, nó được gọi là WebRTC gateway. Janus là một ví dụ điển hình. Nó hoàn toàn là mã nguồn mở ( github repo tại đây ).

Điều này hoạt động như sau: đài truyền hình của bạn liên hệ với cổng (Janus) nói WebRTC . Vì vậy, có một thương lượng chính: B truyền một cách an toàn (các luồng được mã hóa) đến Janus.

Bây giờ, khi người tham dự kết nối, họ kết nối với Janus, một lần nữa: thương lượng WebRTC, khóa bảo mật, v.v. Từ bây giờ, Janus sẽ gửi lại luồng cho từng người tham dự.

Điều này hoạt động tốt vì người phát sóng (B) chỉ tải luồng của mình lên một lần cho Janus. Bây giờ Janus giải mã dữ liệu bằng cách sử dụng khóa riêng của nó và có quyền truy cập vào dữ liệu thô (đó là các gói RTP) và có thể gửi lại các gói đó cho mỗi người tham dự (Janus sẽ lo việc mã hóa cho bạn). Và vì bạn đặt Janus trên một máy chủ, nó có băng thông tải lên lớn, vì vậy bạn sẽ có thể phát trực tuyến cho nhiều người ngang hàng.

Vì vậy, có, nó không liên quan đến một máy chủ, nhưng máy chủ đó nói WebRTC, và bạn "sở hữu" nó: bạn thực hiện phần Janus, do đó bạn không cần phải lo lắng về tham nhũng dữ liệu hoặc người đàn ông ở giữa. Tất nhiên là trừ khi máy chủ của bạn bị xâm phạm. Nhưng có rất nhiều điều bạn có thể làm.

Để cho bạn thấy nó dễ sử dụng như thế nào, trong Janus, bạn có một hàm được gọi là incoming_rtp()(và incoming_rtcp()) mà bạn có thể gọi, cung cấp cho bạn một con trỏ đến các gói rt (c) p. Sau đó, bạn có thể gửi nó cho từng người tham dự (chúng được lưu trữ trong sessionsđó Janus rất dễ sử dụng). Hãy xem ở đây để biết một triển khai của incoming_rtp()hàm , một vài dòng bên dưới, bạn có thể thấy cách truyền các gói đến tất cả những người tham dự và ở đây bạn có thể thấy chức năng thực tế để chuyển tiếp một gói rtp.

Tất cả đều hoạt động khá tốt, tài liệu khá dễ đọc và dễ hiểu. Tôi khuyên bạn nên bắt đầu với ví dụ "echotest", nó là đơn giản nhất và bạn có thể hiểu được hoạt động bên trong của Janus. Tôi khuyên bạn nên chỉnh sửa tệp kiểm tra tiếng vang để tạo tệp của riêng bạn, vì có rất nhiều mã thừa để viết, vì vậy bạn cũng có thể bắt đầu từ một tệp hoàn chỉnh.

Chúc vui vẻ! Hy vọng tôi đã giúp.

Như @MuazKhan đã lưu ý ở trên:

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

hoạt động trong chrome và chưa có chương trình phát âm thanh, nhưng nó có vẻ là Giải pháp số 1.

Bản demo phát sóng ngang hàng WebRTC có thể mở rộng.

Mô-đun này chỉ cần khởi tạo socket.io và định cấu hình nó theo cách mà một chương trình phát sóng duy nhất có thể được chuyển tiếp qua người dùng không giới hạn mà không gặp bất kỳ vấn đề nào về băng thông / sử dụng CPU. Mọi thứ diễn ra ngang hàng!

Điều này chắc chắn sẽ có thể hoàn thành.
Những người khác cũng có thể đạt được điều này: http://www.streamroot.io/

AFAIK triển khai hiện tại duy nhất có liên quan và hoàn thiện là Adobe Flash Player, đã hỗ trợ phát đa hướng p2p để phát video ngang hàng kể từ phiên bản 10.1.

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

Không thể phát sóng "Khả năng mở rộng" trên Internet, vì không cho phép phát đa hướng IP UDP ở đó. Nhưng về lý thuyết, nó có thể được thực hiện trên mạng LAN.
Vấn đề với Websockets là bạn không có quyền truy cập RAW UDP theo thiết kế và nó sẽ không được phép.
Vấn đề với WebRTC là các kênh dữ liệu của nó sử dụng một dạng SRTP, trong đó mỗi phiên có khóa mã hóa riêng . Vì vậy, trừ khi ai đó "phát minh ra" hoặc một API cho phép một cách để chia sẻ một khóa phiên giữa tất cả các máy khách, thì multicast sẽ vô dụng.

Có giải pháp phân phối do đồng nghiệp hỗ trợ, nghĩa là cách tiếp cận là kết hợp. Cả máy chủ và đồng nghiệp đều giúp phân phối tài nguyên. Đó là cách tiếp cận mà peer5.com và peercdn.com đã thực hiện.

Nếu chúng ta đang nói cụ thể về phát sóng trực tiếp, nó sẽ giống như sau:

1. Đài truyền hình gửi video trực tiếp đến một máy chủ.
2. Máy chủ lưu video (thường cũng chuyển mã video sang tất cả các định dạng có liên quan).
3. Siêu dữ liệu về luồng trực tiếp này đang được tạo, tương thích với HLS hoặc HDS hoặc MPEG_DASH
4. Người tiêu dùng duyệt đến luồng trực tiếp có liên quan ở đó người chơi sẽ nhận được siêu dữ liệu và biết phần nào của video sẽ xem tiếp theo.
5. Đồng thời, người tiêu dùng đang được kết nối với những người tiêu dùng khác (thông qua WebRTC)
6. Sau đó, người chơi tải xuống đoạn liên quan trực tiếp từ máy chủ hoặc từ các đồng nghiệp.

Làm theo mô hình như vậy có thể tiết kiệm tới ~ 90% băng thông của máy chủ tùy thuộc vào tốc độ bit của luồng trực tiếp và liên kết cộng tác của người xem.

tuyên bố từ chối trách nhiệm: tác giả đang làm việc tại Peer5

Các bậc thầy của tôi tập trung vào sự phát triển của giao thức phát trực tiếp cdn / p2p kết hợp sử dụng WebRTC. Tôi đã xuất bản kết quả đầu tiên của mình tại http://bem.tv

Mọi thứ đều là mã nguồn mở và tôi đang tìm kiếm những người đóng góp! :-)

Câu trả lời từ Angel Genchev có vẻ đúng, tuy nhiên, có một kiến ​​trúc lý thuyết, cho phép phát sóng với độ trễ thấp qua WebRTC. Hãy tưởng tượng B (đài truyền hình) phát trực tiếp đến A1 (người tham dự 1). Sau đó A2 (người tham dự 2) kết nối. Thay vì phát trực tuyến từ B sang A2, A1 bắt đầu phát trực tuyến video được nhận từ B sang A2. Nếu A1 ngắt kết nối thì A2 bắt đầu nhận từ B.

Kiến trúc này có thể hoạt động nếu không có độ trễ và thời gian chờ kết nối. Vì vậy, về mặt lý thuyết thì đúng, nhưng về mặt thực tế thì không.

Hiện tại tôi đang sử dụng giải pháp phía máy chủ.

Có một số giải pháp có sẵn trên thị trường cho giải pháp có thể mở rộng WebRTC. Họ cung cấp độ trễ thấp, phát trực tuyến webrtc có thể mở rộng. Đây là một số mẫu. Janus , Jitsi , Wowza , Red5pro , Ant Media Server

Tôi là nhà phát triển cho Ant Media Server , chúng tôi cung cấp cả phiên bản cộng đồng và doanh nghiệp bao gồm cả Android và iOS SDK. Hãy cho chúng tôi biết nếu chúng tôi có thể giúp bạn bằng cách nào đó.

Bạn đang mô tả việc sử dụng WebRTC với yêu cầu một-nhiều. WebRTC được thiết kế để phát trực tuyến ngang hàng, tuy nhiên, có những cấu hình sẽ cho phép bạn hưởng lợi từ độ trễ thấp của WebRTC trong khi phân phối video đến nhiều người xem.

Bí quyết là không đánh thuế máy khách phát trực tuyến với mọi người xem và như bạn đã đề cập, có một máy chủ phương tiện "chuyển tiếp". Bạn có thể tự xây dựng điều này nhưng thành thật mà nói, giải pháp tốt nhất thường là sử dụng một thứ gì đó như sản phẩm Truyền trực tuyến WebRTC của Wowza .

Để phát trực tiếp hiệu quả từ điện thoại, bạn có thể sử dụng GoCoder SDK của Wowza nhưng theo kinh nghiệm của tôi, SDK nâng cao hơn như StreamGears hoạt động tốt nhất.

Tôi đang phát triển hệ thống phát sóng WebRTC bằng Kurento Media Server . Kurento Hỗ trợ một số loại giao thức phát trực tuyến như RTSP, WebRTC, HLS. Nó hoạt động tốt về thời gian thực và mở rộng quy mô.

Do đó, Kurento hiện không hỗ trợ RTMP được sử dụng trong Youtube hoặc Twitch. Một trong những vấn đề với tôi là số lượng người dùng đồng thời với điều này.

Hy vọng nó sẽ giúp.

Vì peer1 chỉ người ngang hàng gọi getUserMedia () tức là peer1 tạo ra một phòng.

1. Vì vậy, peer1 nắm bắt phương tiện và bắt đầu phòng.
2. peer2 tham gia phòng và nhận luồng (dữ liệu) từ peer1 và cũng mở kết nối song song có tên là "peer2-connection"
3. Khi peer3 tham gia vào phòng và nhận luồng (dữ liệu) từ peer2 và cũng mở kết nối song song có tên là 'peer3-connection ", v.v.

Quá trình này liên tục khi nhiều đồng đẳng được kết nối với nhau.

Do đó, bằng cách này, một chương trình phát sóng duy nhất có thể được truyền qua người dùng không giới hạn mà không gặp bất kỳ vấn đề nào về băng thông / CPU.

Cuối cùng, tất cả những gì ở trên là tài liệu tham khảo từ Link .