WebRTC - siaran langsung / multicasting yang dapat diskalakan

MASALAH:

WebRTC memberi kita koneksi video / audio peer-to-peer. Ini sempurna untuk panggilan p2p, hangout. Tetapi bagaimana dengan penyiaran (one-to-many, misalnya, 1-to-10000)?

Katakanlah kita memiliki penyiar "B" dan dua peserta "A1", "A2". Tentu saja tampaknya bisa dipecahkan: kita cukup menghubungkan B dengan A1 lalu B dengan A2. Jadi B mengirimkan aliran video / audio langsung ke A1 dan aliran lain ke A2. B mengirimkan aliran dua kali.

Sekarang bayangkan ada 10.000 peserta: A1, A2, ..., A10000. Artinya B harus mengirim 10.000 aliran. Setiap aliran ~ 40KB / dtk yang berarti B memerlukan kecepatan internet keluar 400MB / dtk untuk mempertahankan siaran ini. Tidak bisa diterima.

PERTANYAAN ASLI (TIDAK ADA)

Apakah mungkin untuk memecahkan masalah ini, jadi B hanya mengirim satu aliran di beberapa server dan peserta menarik aliran ini dari server ini? Ya, ini berarti kecepatan keluar di server ini harus tinggi, tetapi saya dapat mempertahankannya.

Atau mungkin ini berarti merusak ide WebRTC?

CATATAN

Flash tidak berfungsi untuk kebutuhan saya sesuai UX yang buruk untuk pelanggan akhir.

SOLUSI (TIDAK BENAR-BENAR)

26.05.2015 - Tidak ada solusi untuk penyiaran yang dapat diskalakan untuk WebRTC saat ini, di mana Anda tidak menggunakan server media sama sekali. Ada solusi sisi server serta hibrida (p2p + sisi server tergantung pada kondisi yang berbeda) di pasar.

Meskipun demikian, ada beberapa teknisi yang menjanjikan seperti https://github.com/muaz-khan/WebRTC-Scalable-Broadcast tetapi mereka perlu menjawab kemungkinan masalah tersebut: latensi, stabilitas koneksi jaringan secara keseluruhan, formula skalabilitas (mereka mungkin tidak dapat diskalakan tanpa batas. ).

SARAN

1. Kurangi CPU / Bandwidth dengan mengutak-atik codec audio dan video;
2. Dapatkan server media.

Karena sudah cukup banyak dibahas di sini, apa yang Anda coba lakukan di sini tidak mungkin dilakukan dengan WebRTC kuno yang biasa (secara ketat peer-to-peer). Karena seperti yang dikatakan sebelumnya, koneksi WebRTC menegosiasikan ulang kunci enkripsi untuk mengenkripsi data, untuk setiap sesi. Jadi, penyiar Anda (B) memang perlu mengupload alirannya sebanyak yang ada.

Namun, ada solusi yang cukup sederhana, yang bekerja dengan sangat baik: Saya telah mengujinya, ini disebut gateway WebRTC. Janus adalah contoh yang bagus. Ini sepenuhnya open source ( github repo di sini ).

Ini berfungsi sebagai berikut: penyiar Anda menghubungi gateway (Janus) yang menggunakan WebRTC . Jadi ada negosiasi kunci: B mentransmisikan dengan aman (aliran terenkripsi) ke Janus.

Sekarang, saat peserta terhubung, mereka terhubung ke Janus, lagi: Negosiasi WebRTC, kunci aman, dll. Mulai sekarang, Janus akan mengirimkan kembali aliran ke setiap peserta.

Ini berfungsi dengan baik karena penyiar (B) hanya mengupload alirannya satu kali, ke Janus. Sekarang Janus mendekode data menggunakan kuncinya sendiri dan memiliki akses ke data mentah (yaitu, paket RTP) dan dapat memancarkan kembali paket tersebut ke setiap peserta (Janus menangani enkripsi untuk Anda). Dan karena Anda meletakkan Janus di server, bandwidth unggahannya besar, sehingga Anda dapat melakukan streaming ke banyak peer.

Jadi ya, ini memang melibatkan server, tetapi server tersebut menggunakan WebRTC, dan Anda "memilikinya": Anda menerapkan bagian Janus sehingga Anda tidak perlu khawatir tentang kerusakan data atau orang di tengah. Yah, kecuali server Anda dikompromikan, tentu saja. Tetapi ada banyak hal yang dapat Anda lakukan.

Untuk menunjukkan kepada Anda betapa mudahnya menggunakannya, di Janus, Anda memiliki fungsi yang disebut incoming_rtp()(dan incoming_rtcp()) yang dapat Anda panggil, yang memberi Anda penunjuk ke paket rt (c) p. Anda kemudian dapat mengirimkannya ke setiap peserta (mereka disimpan di sessionsJanus membuatnya sangat mudah digunakan). Lihat di sini untuk satu implementasi incoming_rtp()fungsi , beberapa baris di bawah ini Anda dapat melihat bagaimana mengirimkan paket ke semua peserta dan di sini Anda dapat melihat fungsi sebenarnya untuk menyampaikan paket rtp.

Semuanya bekerja dengan cukup baik, dokumentasinya cukup mudah dibaca dan dipahami. Saya sarankan Anda mulai dengan contoh "echotest", ini yang paling sederhana dan Anda bisa memahami cara kerja Janus. Saya sarankan Anda mengedit file uji gema untuk membuatnya sendiri, karena ada banyak kode yang berlebihan untuk ditulis, jadi sebaiknya Anda mulai dari file lengkap.

Selamat bersenang-senang! Semoga saya membantu.

Seperti yang disebutkan @MuazKhan di atas:

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

berfungsi di chrome, dan belum ada siaran audio, tetapi tampaknya ini adalah Solusi pertama.

Demo penyiaran peer-to-peer WebRTC yang Skalabel.

Modul ini hanya menginisialisasi socket.io dan mengkonfigurasinya sedemikian rupa sehingga siaran tunggal dapat diteruskan melalui pengguna yang tidak terbatas tanpa masalah penggunaan bandwidth / CPU. Semuanya terjadi peer-to-peer!

Ini pasti bisa diselesaikan.
Orang lain juga dapat mencapai ini: http://www.streamroot.io/

AFAIK satu-satunya implementasi saat ini yang relevan dan matang adalah Adobe Flash Player, yang telah mendukung p2p multicast untuk penyiaran video peer to peer sejak versi 10.1.

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

Penyiaran "Scalable" tidak dimungkinkan di Internet, karena multicasting IP UDP tidak diperbolehkan di sana. Tapi secara teori itu mungkin di LAN.
Masalah dengan Websockets adalah Anda tidak memiliki akses ke RAW UDP dengan desain dan itu tidak akan diizinkan.
Masalah dengan WebRTC adalah saluran datanya menggunakan bentuk SRTP, di mana setiap sesi memiliki kunci enkripsi sendiri . Jadi, kecuali seseorang "menemukan" atau API mengizinkan cara untuk berbagi satu kunci sesi antara semua klien, multicast tidak berguna.

Ada solusi pengiriman dengan bantuan teman sebaya, yang berarti pendekatannya hibrid. Baik server dan rekan membantu mendistribusikan sumber daya. Itulah pendekatan yang diambil peer5.com dan peercdn.com .

Jika kita berbicara secara khusus tentang siaran langsung, tampilannya akan seperti ini:

1. Penyiar mengirimkan video langsung ke server.
2. Server menyimpan video (biasanya juga mentranskodekannya ke semua format yang relevan).
3. Metadata tentang streaming langsung ini sedang dibuat, kompatibel dengan HLS atau HDS atau MPEG_DASH
4. Konsumen melihat-lihat live streaming yang relevan, di sana pemutar mendapatkan metadata dan mengetahui potongan video mana yang akan didapatkan berikutnya.
5. Pada saat yang sama konsumen terhubung dengan konsumen lain (melalui WebRTC)
6. Kemudian pemain mengunduh potongan yang relevan baik langsung dari server atau dari rekan.

Mengikuti model seperti itu dapat menghemat hingga ~ 90% bandwidth server bergantung pada bitrate streaming langsung dan uplink kolaboratif pemirsa.

disclaimer: penulis bekerja di Peer5

Master saya berfokus pada pengembangan protokol streaming langsung cdn / p2p hybrid menggunakan WebRTC. Saya telah mempublikasikan hasil pertama saya di http://bem.tv

Semuanya open source dan saya mencari kontributor! :-)

Jawaban dari Angel Genchev tampaknya benar, namun, ada arsitektur teoretis, yang memungkinkan penyiaran latensi rendah melalui WebRTC. Bayangkan B (penyiar) melakukan streaming ke A1 (peserta 1). Kemudian A2 (peserta 2) terhubung. Alih-alih mengalirkan dari B ke A2, A1 mulai mengalirkan video yang diterima dari B ke A2. Jika A1 terputus maka A2 mulai menerima dari B.

Arsitektur ini dapat berfungsi jika tidak ada latensi dan waktu tunggu koneksi habis. Jadi secara teoritis memang benar, tetapi tidak secara praktis.

Saat ini saya menggunakan solusi sisi server.

Ada beberapa solusi yang tersedia di pasar untuk solusi terukur WebRTC. Mereka menyediakan streaming webrtc dengan latensi rendah dan skalabel. Berikut beberapa contoh. Janus , Jitsi , Wowza , Red5pro , Ant Media Server

Saya pengembang untuk Ant Media Server , kami menyediakan edisi komunitas dan perusahaan termasuk Android dan iOS SDK juga. Beri tahu kami jika kami dapat membantu Anda.

Anda menjelaskan menggunakan WebRTC dengan persyaratan satu-ke-banyak. WebRTC dirancang untuk streaming peer-to-peer, namun ada konfigurasi yang memungkinkan Anda memanfaatkan latensi rendah WebRTC saat mengirimkan video ke banyak penonton.

Triknya adalah dengan tidak membebani klien streaming dengan setiap pemirsa dan, seperti yang Anda sebutkan, memiliki server media "relai". Anda dapat membangunnya sendiri tetapi sejujurnya solusi terbaik sering kali menggunakan sesuatu seperti produk Streaming WebRTC Wowza .

Untuk melakukan streaming secara efisien dari ponsel Anda dapat menggunakan GoCoder SDK Wowza tetapi menurut pengalaman saya, SDK yang lebih canggih seperti StreamGears bekerja paling baik.

Saya sedang mengembangkan sistem penyiaran WebRTC menggunakan Kurento Media Server . Kurento Mendukung beberapa jenis protokol streaming seperti RTSP, WebRTC, HLS. Ia bekerja dengan baik dalam hal waktu nyata dan penskalaan.

Karenanya, Kurento tidak mendukung RTMP yang digunakan di Youtube atau Twitch sekarang. Salah satu masalah saya adalah jumlah pengguna yang bersamaan dengan ini.

Semoga membantu.

Karena peer1 hanyalah peer yang memanggil getUserMedia (), misalnya, peer1 membuat ruang.

1. Jadi, peer1 menangkap media dan memulai ruang.
2. peer2 bergabung dengan ruangan dan mendapatkan aliran (data) dari peer1 dan juga membuka koneksi paralel bernama "peer2-connection"
3. Ketika peer3 bergabung dengan ruangan dan mendapatkan aliran (data) dari peer2 dan juga membuka koneksi paralel bernama 'peer3-connection "dan seterusnya.

Proses ini terus berlanjut karena banyak rekan terhubung satu sama lain.

Oleh karena itu, dengan ini satu siaran dapat ditransfer melalui pengguna tanpa batas tanpa masalah penggunaan bandwidth / CPU.

Terakhir, semua yang terkandung di atas adalah referensi dari Link .