WebRTC - siaran langsung / multicasting yang dapat diskalakan


114

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.

3
"Satu-satunya cara untuk membuat aplikasi yang dapat diskalakan adalah dengan menggunakan solusi sisi server." Tampaknya cukup jelas ... Adapun WebRTC, tidak pernah dimaksudkan untuk siaran berskala besar. Gunakan sesuatu yang mendukung multicast untuk itu, atau jika Anda harus pergi melalui Internet, koneksi satu-ke-satu berbasis server, karena ISP tidak merutekan multicast.
Dark Falcon

1
Mengapa tidak menggunakan WebRTC dari klien ke server? Masalahnya ada dalam distribusi, di mana koneksi klien tidak dapat menanganinya, jadi kirim satu uap ke server dan streaming ke klien dari sana. Bandwidth akan menjadi mahal, tetapi Anda tidak dapat menyiasati baik mengirimkan satu aliran ke setiap pengguna atau meminta pengguna mengirim aliran ke pengguna lain.
Dark Falcon

1
Setidaknya ada dua perusahaan yang saya ketahui mencoba melakukan pengiriman video p2p berbasis webrtc: affovi.com/rtcplayer.html - kebanyakan untuk video langsung; dan peer5.com - kebanyakan untuk VOD.
Svetlin Mladenov

1
@igorpavlov Anda mungkin ingin memeriksa: github.com/muaz-khan/WebRTC-Scalable-Broadcast Meskipun hanya bekerja di chrome, dan belum ada siaran audio.
Muaz Khan

4
Tidak ada cara untuk mencapai skalabilitas itu tanpa MCU. WebRTC dirancang untuk menjadi Peer-to-Peer. Anda tidak dapat menyiarkan darinya tanpa benar-benar membanting penyiar Anda (dengan koneksi peer unik untuk setiap aliran, yang magang, adalah aliran lain yang sedang dikodekan). Sedangkan untuk merelai media dari peer-to-peer, itu mungkin saja, tetapi tentu saja, ini akan menimbulkan latensi tambahan untuk setiap peer yang ditambahkan ke streaming nanti. Untuk kualitas, dan skalabilitas, memiliki server MCU webrtc adalah satu-satunya solusi yang realistis.
Benjamin Trent

Jawaban:


66

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.


1
Benarkah mengatakan ini tidak berfungsi di Safari saat ini (atau browser apa pun yang tidak mendukung WebRTC?). Adakah yang tahu tentang solusi hybrid di mana Anda menyiarkan dari Browser ke server menggunakan WebRTC lalu mentranskode video ke HLS / HDS (Atau bahkan RTMP) agar sesuai dengan sistem siaran tradisional?
Ben

1
@Ben ya itu tidak berfungsi dengan browser yang tidak mendukung WebRTC. Dulu (ketika saya menulis ini) Safari jelas tidak mendukung ini. Namun hari ini saya belum memeriksanya. Tapi saya masih berpikir mereka tidak mendukung WebRTC (untuk dikonfirmasi). Sedangkan untuk menggunakannya dalam sistem hybrid, ini sangat mungkin, sebenarnya inilah yang saya lakukan untuk perusahaan tempat saya bekerja; seperti yang Anda katakan, saya menyiarkan dari browser ke server dan dari sana, saya membangun dan menyambungkan pipeline GStreamer untuk mentranskode feed. Anda juga dapat melakukan ini!
nschoe

ada ide tentang jitsi? apakah jitisi juga sama?
ishandutta2007

@nschoe Apakah ini lebih baik daripada menggunakan websocket untuk melakukan hal yang sama?
Navigateur

Anda sebenarnya sedang menjelaskan cara kerja SFU (Unit Penerusan Selektif). Anda dapat melakukan hal yang sama dengan mediasoup
Dirk V

11

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!

masukkan deskripsi gambar di sini

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


1
Hal ini tampaknya agak ketinggalan jaman bagi saya. Adakah pembaruan atau pemikiran tentang ide ini?
igorpavlov

Juga, apakah itu menyelesaikan masalah latensi? Misalnya, Peer1 berbicara dengan Peer5 dan Peer2 akhirnya kehilangan koneksi. Atau apakah arsitektur ini hanya bagus untuk LAN?
igorpavlov

Juga, apakah Streamroot mirip dengan Peer5?
igorpavlov

7

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 .


1
Orang tidak mematikan teknologi. Teknologi ini membunuh dirinya sendiri dengan menyediakan UX yang sangat buruk, terutama saat mengizinkan mikrofon / kamera. Di situlah getusermedia menang.
igorpavlov

Sangat setuju.
Tom

Terlepas dari UX yang buruk, apakah ini solusinya? Server lebih sedikit?
rubo77

6

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.


1
tetapi obrolan sudah berfungsi dengan WebRTC, jadi semua orang melihat setiap pesan, jadi pesan satu-ke-banyak juga harus berfungsi untuk video
rubo77

@ rubo77 Data yang dikirim dengan pesan teks tidak seberapa dibandingkan dengan kecepatan dan jumlah data yang dikirim dengan aliran video. Jadi obrolan dapat dengan mudah berisi lebih banyak pengguna sekaligus
Dirk V

5

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


Terima kasih. Saya tahu tentang peer5 dan menganggapnya sebagai solusi yang cukup menarik. Namun, tujuan dari pertanyaan ini adalah untuk menemukan solusi yang benar-benar tanpa server (hanya STUN / TURN yang diizinkan).
igorpavlov

5

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! :-)


Apakah Anda menggunakan perangkat lunak sisi server sejenis MCU?
igorpavlov

Saya sebenarnya menggunakan beberapa komponen sisi server dari rtcio people: github.com/rtc-io
flavioribeiro

1
Sepertinya Anda menggunakan komponennya untuk memberi sinyal. Bagaimana dengan streaming video sisi server? Atau solusi Anda benar-benar P2P?
igorpavlov

maaf atas penundaan yang lama dalam menjawab Anda @igorpavlov, saya menggunakan EvoStream untuk menyegmentasikan video dan saya memutar sumber video dan menunjuk ke EvoStream menggunakan encoder Elemental.
flavioribeiro

Ini adalah penyedia server media. Lebih efisien? Mungkin. Apakah itu yang saya cari? Tidak.
igorpavlov

2

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.


Bagaimana dengan kecepatan streaming dalam solusi sisi server? Tolong bagikan.
pengguna2003356

Solusi sisi server artinya? Apa yang kamu gunakan? Ini akan membantu penelitian saya. Tolong bagikan. Terima kasih.
pengguna2003356

Solusi sisi server berarti Opentok oleh Tokbox. Saya tidak mengiklankannya, ada banyak solusi seperti itu di pasar, tetapi saya tetap menggunakan yang ini. Ini bekerja seperti server media. PS Apa yang Anda maksud dengan komunikasi multi-pihak? Saya tidak mengerti.
igorpavlov

@igorpavlov Bisakah Anda memberikan daftar perusahaan yang menyediakan webrtc sisi server? Saya hanya tahu Flashphoner dan Opentok. Terima kasih
Ramil Amerzyanov

Saya akan penasaran untuk melihat apakah ini benar-benar akan meningkat. Pasti akan ada masalah penskalaan dengan latensi pada grup BESAR (1000+) tetapi jika hanya ada 5-10, saya membayangkan itu akan bekerja dengan cukup baik tetapi beberapa pekerjaan kaki yang mewah akan diperlukan jika seseorang di tengah rantai "rekan" "meninggalkan dan menghubungkan kembali semua rekan berikutnya jika itu hanya satu rantai akan menjadi BESAR di atas kepala. Mungkin lebih baik menggunakan struktur pohon biner / terner.
Benjamin Trent

2

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.


1

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.


1

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.


0

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 .


1
Pendekatan ini sudah disebutkan, tetapi mungkin tidak berhasil di dunia nyata. Sebagai Peer3, mengapa saya harus peduli dengan kinerja bandwidth Peer2? Tentu saja, Peer3 dapat beralih ke Peer1 jika Peer2 meninggalkan rantai, tetapi hal itu akan menyebabkan banyak sekali gangguan aliran, sambungan ulang, dll. Semakin jauh saya dalam rantai, semakin saya menderita. Jadi, ya, mungkin berfungsi di LAN, tapi mungkin itu saja.
igorpavlov

Penyiaran paralel tidak menangani bandwidth dan jika setelah koneksi dibuat dari peer3 ke peer1 melalui peer2 dan kemudian peer2 fallback, peer3 tetap terhubung ke peer1.
susan097

Saya tidak yakin saya mengerti. Saya sebenarnya tidak mengacu pada tautan, sekarang izinkan saya merujuk. Link ini github.com/muaz-khan/WebRTC-Scalable-Broadcast memiliki gambar di "Bagaimana cara kerjanya?" bagian. Gambar ini dengan jelas memberi tahu Anda bahwa sekali, katakanlah Peer5 terputus, Peer8,9 dan 10 terputus dari siaran. Mereka harus terhubung ke Peer2 atau Peer6, tetapi itu akan menyebabkan kelambatan. Selain itu, proyek ini tidak memiliki kontributor maupun aktivitas.
igorpavlov
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.