WebRTC - ölçeklenebilir canlı yayın yayını / çok noktaya yayın


114

SORUN:

WebRTC bize eşler arası video / ses bağlantıları sağlar. P2p aramaları, hangout'lar için mükemmeldir. Peki ya yayın (birden çoğa, örneğin 1'den 10000'e)?

Diyelim ki bir yayıncımız "B" ve iki katılımcımız "A1", "A2". Elbette çözülebilir gibi görünüyor: B'yi A1'e ve sonra B'yi A2'ye bağlarız. Böylece B video / ses akışını doğrudan A1'e ve başka bir akışı A2'ye gönderir. B, akışları iki kez gönderir.

Şimdi 10000 katılımcı olduğunu düşünelim: A1, A2, ..., A10000. Bu, B'nin 10000 akış göndermesi gerektiği anlamına gelir. Her akış ~ 40KB / s'dir, bu da B'nin bu yayını sürdürmek için 400MB / s giden internet hızına ihtiyacı olduğu anlamına gelir. Kabul edilemez.

ORİJİNAL SORU (ESKİ)

Bunu bir şekilde çözmek mümkün mü, yani B bazı sunuculara yalnızca bir akış gönderiyor ve katılımcılar bu akışı bu sunucudan çekiyor mu? Evet, bu, bu sunucudaki çıkış hızının yüksek olması gerektiği anlamına gelir, ancak bunu koruyabilirim.

Ya da belki bu, WebRTC fikrini mahvetmek anlamına mı geliyor?

NOTLAR

Flash, son müşteriler için zayıf UX'e göre ihtiyaçlarım için çalışmıyor.

ÇÖZÜM (GERÇEKTEN DEĞİL)

26.05.2015 - Medya sunucularını hiç kullanmadığınız şu anda WebRTC için ölçeklenebilir yayın için böyle bir çözüm yok. Piyasada hibrit (farklı koşullara bağlı olarak p2p + sunucu tarafı) yanı sıra sunucu tarafı çözümleri de vardır.

Https://github.com/muaz-khan/WebRTC-Scalable-Broadcast gibi bazı gelecek vaat eden teknolojiler var, ancak bu olası sorunları yanıtlamaları gerekiyor: gecikme, genel ağ bağlantısı kararlılığı, ölçeklenebilirlik formülü (muhtemelen sonsuz ölçeklenebilir değiller) ).

ÖNERİLER

  1. Hem ses hem de video kodeklerini değiştirerek CPU / Bant Genişliğini azaltın;
  2. Bir medya sunucusu edinin.

3
"Ölçeklenebilir bir uygulama oluşturmanın tek yolu, sunucu tarafı çözümü kullanmaktır." Bu oldukça açık görünüyor ... WebRTC'ye gelince, hiçbir zaman büyük ölçekli yayınlar için tasarlanmamıştı. Bunun için çok noktaya yayını destekleyen bir şey kullanın veya İnternet üzerinden geçmeniz gerekiyorsa, sunucu tabanlı bire bir bağlantı, çünkü ISS'ler çok noktaya yayını yönlendirmez.
Koyu Falcon

1
Neden istemciden sunucuya WebRTC kullanmıyorsunuz? Sorun dağıtımdadır, çünkü istemcinin bağlantısı bunu kaldıramaz, bu nedenle sunucuya bir buhar gönderin ve oradan istemcilere yayın yapın. Bant genişliği pahalı olacak, ancak her kullanıcıya tek bir akış göndererek veya kullanıcının diğer kullanıcılara bir akış göndermesini sağlayamazsınız.
Koyu Falcon

1
Webrtc tabanlı p2p video dağıtımı yapmaya çalışan en az iki şirket var: affovi.com/rtcplayer.html - çoğunlukla canlı video için; ve peer5.com - çoğunlukla VOD için.
Svetlin Mladenov

1
@igorpavlov Kontrol etmek isteyebilirsiniz: github.com/muaz-khan/WebRTC-Scalable-Broadcast Sadece kromda çalışmasına rağmen henüz ses yayını yok.
Muaz Khan

4
Bir çeşit MCU olmadan bu ölçeklenebilirliğe ulaşmanın bir yolu yok. WebRTC, Eşler Arası olacak şekilde tasarlanmıştır. Yayıncınızı kesinlikle çarpmadan yayınlayamazsınız (her akış için benzersiz bir eş bağlantısı olan, stajyer, kodlanmakta olan başka bir akıştır). Medyayı eşler arası aktarmaya gelince, bu mümkün olabilir, ancak bu, daha sonra akışa eklenen her eş için ek gecikmeye neden olacaktır. Kalite ve ölçeklenebilirlik için, bir webrtc MCU sunucusuna sahip olmak tek gerçekçi çözümdür.
Benjamin Trent

Yanıtlar:


66

Burada hemen hemen ele alındığı için, burada yapmaya çalıştığınız şey sade, eski moda WebRTC (kesinlikle eşler arası) ile mümkün değildir. Daha önce söylendiği gibi, WebRTC bağlantıları, her oturum için verileri şifrelemek üzere şifreleme anahtarlarını yeniden görüşür. Dolayısıyla, yayıncınızın (B) gerçekten de katılımcı sayısı kadar akışını yüklemesi gerekecektir.

Ancak, gayet iyi çalışan oldukça basit bir çözüm var: Test ettim, buna WebRTC ağ geçidi deniyor. Janus buna iyi bir örnek. Tamamen açık kaynaktır ( burada github repo ).

Bu şu şekilde çalışır: yayıncınız WebRTC konuşan ağ geçidi (Janus) ile iletişim kurar . Yani bir anahtar görüşme var: B güvenli bir şekilde (şifrelenmiş akışlar) Janus'a aktarıyor.

Şimdi, katılımcılar bağlandığında, Janus'a tekrar bağlanırlar: WebRTC anlaşması, güvenli anahtarlar, vb. Bundan sonra, Janus akışları her katılımcıya geri gönderecek.

Bu iyi çalışıyor çünkü yayıncı (B) akışını Janus'a yalnızca bir kez yüklüyor. Artık Janus kendi anahtarını kullanarak verilerin kodunu çözer ve ham verilere (yani o, RTP paketleri) erişebilir ve bu paketleri her bir katılımcıya geri gönderebilir (Janus sizin için şifrelemeyle ilgilenir). Ve Janus'u bir sunucuya koyduğunuz için, harika bir yükleme bant genişliğine sahip, böylece birçok eşe akış yapabileceksiniz.

Yani evet, yapar bir sunucu ile değil, bu sunucu WebRTC'yi konuşur ve onu siz "kendi": Eğer ortada veri bozulması veya adam hakkında endişe gerekmez böylece Janus kısmını uygulamaya. Tabii sunucunuzun güvenliği ihlal edilmediği sürece. Ama yapabileceğin çok şey var.

Size kullanımın ne kadar kolay olduğunu göstermek için, Janus'ta, çağırabileceğiniz incoming_rtp()(ve incoming_rtcp()) adında bir işleviniz vardır , bu size rt (c) p paketlerine bir işaretçi verir. Daha sonra bunu her katılımcıya gönderebilirsiniz ( sessionsJanus'un kullanımı çok kolay hale getirdiği bir yerde saklanırlar ). Fonksiyonun bir uygulaması için buraya bakınincoming_rtp() , aşağıda birkaç satır , paketleri tüm katılımcılara nasıl ileteceğinizi görebilir ve burada bir rtp paketini iletmek için gerçek işlevi görebilirsiniz.

Hepsi oldukça iyi çalışıyor, belgelerin okunması ve anlaşılması oldukça kolay. "Echotest" örneğiyle başlamanızı öneririm, bu en basitidir ve Janus'un iç işleyişini anlayabilirsiniz. Kendinizinkini oluşturmak için yankı test dosyasını düzenlemenizi öneririm, çünkü yazılacak çok fazla fazlalık kod var, bu yüzden tam bir dosyadan başlayabilirsiniz.

İyi eğlenceler! Umarım yardım etmişimdir.


1
Bunun şu anda Safari'de (veya WebRTC'yi desteklemeyen herhangi bir tarayıcıda) çalışmadığını söylemek doğru mu? Tarayıcıdan sunucuya WebRTC kullanarak yayın yaptığınız ve ardından videoyu geleneksel bir yayın sistemine sığacak şekilde HLS / HDS'ye (veya hatta RTMP) dönüştürdüğünüz karma bir çözüm bilen var mı?
Ben

1
@Ben evet, WebRTC'yi desteklemeyen tarayıcılarda çalışmıyor. Eskiden (bunu yazdığımda) Safari bunu açıkça desteklemiyordu. Bugün ancak kontrol etmedim. Ancak yine de WebRTC'yi desteklemediklerini düşünüyorum (yine de onaylanacak). Hibrit bir sistemde kullanmak ise tamamen mümkün, aslında çalıştığım şirket için yaptığım buydu; dediğin gibi, tarayıcıdan sunucuya yayın yapıyorum ve oradan beslemeyi dönüştürmek için bir GStreamer ardışık düzeni oluşturdum ve bağladım. Bunu da yapabilirsiniz!
nschoe

jitsi hakkında bir fikrin var mı? jitisi de aynı mı?
ishandutta2007

@nschoe Bu, aynısını yapmak için websocket kullanmaktan daha mı iyi?
Navigator

Aslında bir SFU'nun (Seçmeli Yönlendirme Birimi) nasıl çalıştığını açıklıyorsunuz. Aynı şeyi mediasoup
Dirk V

11

@MuazKhan'ın yukarıda belirttiği gibi:

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

Chrome'da çalışıyor ve henüz ses yayını yok, ancak 1. Çözüm gibi görünüyor.

Ölçeklenebilir bir WebRTC eşler arası yayın demosu.

Bu modül, soket.io'yu basitçe başlatır ve tek bir yayının, herhangi bir bant genişliği / CPU kullanım sorunu olmaksızın sınırsız kullanıcı üzerinden aktarılabileceği şekilde yapılandırır. Her şey eşler arası gerçekleşir!

görüntü açıklamasını buraya girin

Bunu kesinlikle tamamlamak mümkün olmalıdır.
Diğerleri de bunu başarabilir: http://www.streamroot.io/


1
Bu şeyler benim için biraz modası geçmiş görünüyor. Bu fikirle ilgili herhangi bir güncelleme veya düşünce var mı?
igorpavlov

Ayrıca, gecikme sorunlarını yine de çözüyor mu? Örneğin, Peer1 Peer5 ile konuşur ve Peer2 sonunda bağlantıyı kaybeder. Yoksa bu mimari sadece LAN için mi iyi?
igorpavlov

Ayrıca Streamroot, Peer5'e benzer mi?
igorpavlov

7

AFAIK, bunun ilgili ve olgun olan tek güncel uygulaması, sürüm 10.1'den bu yana uçtan uca video yayını için p2p çoklu yayını destekleyen Adobe Flash Player'dır.

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


1
İnsanlar teknolojiyi öldürmez. Teknoloji, özellikle mikrofona / kameraya izin verirken çok zayıf UX sağlayarak kendini öldürüyor. Getusermedia'nın kazandığı yer burasıdır.
igorpavlov

Daha fazla anlaşamadım.
Tom

Kötü ux dışında, çözüm bu mu? Sunucu az mı?
rubo77

6

IP UDP çoklu yayına burada izin verilmediğinden, İnternette "ölçeklenebilir" yayın mümkün değildir. Ancak teorik olarak bir LAN üzerinde mümkündür.
Websockets ile ilgili sorun, tasarım gereği RAW UDP'ye erişiminizin olmaması ve buna izin verilmemesidir.
WebRTC ile ilgili sorun, veri kanallarının her oturumun kendi şifreleme anahtarına sahip olduğu bir SRTP biçimi kullanmasıdır . Biri "icat etmediği" veya bir API paylaşmanın bir yoluna izin vermediği sürece tüm istemciler arasında bir oturum anahtarını , çoklu yayın işe yaramaz.


1
ancak sohbetler zaten WebRTC ile çalışıyor, bu nedenle herkes her mesajı görüyor, bu nedenle bire çoğuna video için de bir şekilde çalışmalı
rubo77

@ rubo77 Metin mesajıyla gönderilen veriler, video akışlarıyla gönderilen verilerin hızı ve miktarıyla karşılaştırıldığında hiçbir şey değildir. Böylece sohbetler aynı anda daha fazla kullanıcıyı kolayca içerebilir
Dirk V

5

Eş destekli teslimatın çözümü vardır, yani yaklaşım hibrittir. Hem sunucu hem de eşler, kaynağın dağıtılmasına yardımcı olur. Peer5.com ve peercdn.com'un benimsediği yaklaşım budur .

Özellikle canlı yayından bahsediyorsak, şuna benzeyecektir:

  1. Yayıncı, canlı videoyu bir sunucuya gönderir.
  2. Sunucu videoyu kaydeder (genellikle videoyu ilgili tüm biçimlere dönüştürür).
  3. Bu canlı akışla ilgili HLS, HDS veya MPEG_DASH ile uyumlu bir meta veri oluşturuluyor
  4. Tüketiciler oradaki ilgili canlı yayına göz atar, oynatıcı meta verileri alır ve videodan sonraki hangi parçaların alınacağını bilir.
  5. Aynı zamanda tüketici diğer tüketicilere bağlanmaktadır (WebRTC aracılığıyla)
  6. Ardından, oynatıcı ilgili parçayı doğrudan sunucudan veya eşlerden indirir.

Böyle bir modeli takip etmek, canlı akışın bit hızına ve izleyicilerin işbirliğine dayalı yukarı bağlantısına bağlı olarak sunucunun bant genişliğinin ~% 90'ına kadar tasarruf sağlayabilir.

feragatname: yazar Peer5'te çalışıyor


Teşekkür ederim. Peer5'i biliyorum ve oldukça çekici bir çözüm buluyorum. Ancak, bu sorunun amacı kesinlikle sunucusuz bir çözüm bulmaktı (yalnızca STUN / TURN'a izin verilir).
igorpavlov

5

Uzmanlarım, WebRTC kullanarak hibrit bir cdn / p2p canlı akış protokolü geliştirmeye odaklanmıştır. İlk sonuçlarımı http://bem.tv adresinde yayınladım

Her şey açık kaynak ve katkıda bulunanlar arıyorum! :-)


Herhangi bir MCU türü sunucu tarafı yazılım kullanıyor musunuz?
igorpavlov

Aslında rtcio kullanıcılarından bazı sunucu tarafı bileşenlerini kullanıyorum: github.com/rtc-io
flavioribeiro

1
Sinyal için bileşenlerini kullanıyor gibisin. Sunucu tarafı video akışına ne dersiniz? Yoksa çözümünüz kesinlikle P2P mi?
igorpavlov

@igorpavlov'u yanıtlamadaki uzun gecikme için özür dilerim, videoları bölümlemek için EvoStream kullanıyorum ve bir video kaynağını döngüye alıyorum ve Elemental kodlayıcı kullanarak EvoStream'i işaret ediyorum.
flavioribeiro

Bir medya sunucusu sağlayıcısıdır. Daha verimli? Muhtemelen. Aradığım bu mu? Hayır.
igorpavlov

2

Angel Genchev'in cevabı doğru gibi görünüyor, ancak WebRTC üzerinden düşük gecikmeli yayına izin veren teorik bir mimari var. B'nin (yayıncı) A1'e (katılımcı 1) akışını hayal edin. Ardından A2 (katılımcı 2) bağlanır. B'den A2'ye akış yerine A1, B'den A2'ye alınan video akışına başlar. A1 bağlantısı kesilirse A2, B'den almaya başlar.

Bu mimari, herhangi bir gecikme ve bağlantı zaman aşımı yoksa çalışabilir. Yani teorik olarak doğru, ama pratik olarak değil.

Şu anda sunucu tarafı çözümü kullanıyorum.


Sunucu tarafı çözümündeki akış hızı ne durumda? Lütfen paylaşın.
user2003356

Sunucu tarafı çözüm demek? Ne kullandın Araştırmam için faydalı olacaktır. Lütfen paylaşın. Teşekkürler.
user2003356

Sunucu tarafı çözüm, Tokbox tarafından Opentok anlamına gelir. Onların reklamını yapmıyorum, piyasada tonlarca bu tür çözüm var, ancak buna bağlı kalıyorum. Bir medya sunucusu gibi çalışıyor. PS Çok partili iletişimle neyi kastediyorsunuz? Ben anlamadım
igorpavlov

@igorpavlov sunucu tarafı webrtc sağlayan firmaların listesini verebilir misiniz? Ben sadece Flashphoner ve Opentok'u tanıyorum. Teşekkürler
Ramil Amerzyanov

Bunun gerçekten ölçeklenip ölçeklenmeyeceğini merak ediyorum. BÜYÜK gruplarda (1000+) gecikme ile ilgili ölçeklendirme sorunları olacağından eminim, ancak yalnızca 5-10 varsa, oldukça iyi çalışacağını düşünürdüm, ancak akran zincirinin ortasında biri varsa biraz süslü ayak çalışması gerekirdi. "Tek bir zincir ise, sonraki tüm akranları terk edip yeniden bağlamak BÜYÜK bir kafa üstü olacaktır. İkili / üçlü ağaç yapısı kullanmak daha iyi olabilir.
Benjamin Trent

2

WebRTC ölçeklenebilir çözümü için piyasada mevcut bazı çözümler vardır. Düşük gecikmeli, ölçeklenebilir webrtc akışı sağlarlar. İşte bazı örnekler. Janus , Jitsi , Wowza , Red5pro , Ant Media Sunucusu

Ant Media Server için geliştiriciyim , android ve iOS SDK dahil hem topluluk hem de kurumsal sürüm sağlıyoruz. Size bir şekilde yardımcı olabileceğimizi bize bildirin.


1

Bire çok gereksinimiyle WebRTC kullanmayı tanımlıyorsunuz. WebRTC, eşler arası akış için tasarlanmıştır, ancak birçok izleyiciye video sunarken WebRTC'nin düşük gecikmesinden yararlanmanızı sağlayacak yapılandırmalar da vardır.

İşin püf noktası, akış istemcisini her izleyiciyle vergilendirmemek ve sizin de belirttiğiniz gibi bir "aktarım" ortam sunucusuna sahip olmaktır. Bunu kendiniz oluşturabilirsiniz, ancak dürüst olmak gerekirse en iyi çözüm genellikle Wowza'nın WebRTC Akış ürünü gibi bir şey kullanmaktır. .

Bir telefondan verimli bir şekilde akış sağlamak için Wowza'nın GoCoder SDK'sını kullanabilirsiniz, ancak benim deneyimime göre StreamGears gibi daha gelişmiş bir SDK en iyi sonucu verir.


1

Kurento Media Server'ı kullanarak WebRTC yayın sistemi geliştiriyorum . Kurento, RTSP, WebRTC, HLS gibi çeşitli akış protokollerini destekler. Gerçek zamanlı ve ölçeklendirme açısından da işe yarar.

Dolayısıyla Kurento, şu anda Youtube veya Twitch'te kullanılan RTMP'yi desteklemiyor. Benimle ilgili sorunlardan biri, bununla eşzamanlı kullanıcı sayısı.

Umarım yardımcı olur.


0

Peer1 yalnızca getUserMedia () 'yı çağıran eş olduğundan, yani peer1 bir oda oluşturur.

  1. Böylece peer1 medyayı yakalar ve odayı başlatır.
  2. peer2 odaya katılır ve peer1'den akışı (veri) alır ve ayrıca "peer2-bağlantı" olarak adlandırılan paralel bağlantıyı açar
  3. Peer3 odaya katıldığında ve peer2'den akış (veri) aldığında ve ayrıca 'peer3-bağlantı "olarak adlandırılan paralel bağlantıyı açın vb.

Bu süreç, birçok akran birbirine bağlandıkça devam eder.

Böylelikle tek bir yayın, herhangi bir bant genişliği / CPU kullanım problemi olmaksızın sınırsız kullanıcı üzerinden aktarılabilir.

Son olarak, yukarıda yer alan tüm referanstır Bağlantı .


1
Bu yaklaşımdan daha önce bahsedilmişti, ancak gerçek dünyada işe yaramayabilir. Peer3 olarak, Peer2'nin bant genişliği performansını neden önemsemeliyim? Elbette, Peer2 zincirden ayrılırsa Peer3, Peer1'e geri dönebilir, ancak bu tonlarca akış kesintisine, yeniden bağlantılara vb. Neden olur. Zincirde ne kadar ileride olursam, o kadar çok acı çekeceğim. Yani, evet, LAN üzerinde çalışabilir, ama muhtemelen budur.
igorpavlov

Paralel yayın bant genişliğini dikkate almaz ve eğer bağlantı peer3'ten peer1'e peer2 üzerinden bir kez kurulursa ve o zaman peer2 geri dönüşü olursa, peer3, peer1'e bağlı kalır.
susan097

Anladığımdan emin değilim. Aslında bağlantıya atıfta bulunmuyordum, şimdi bakmama izin verin. Bu bağlantı github.com/muaz-khan/WebRTC-Scalable-Broadcast'in "Nasıl çalışır?" Bölüm. Bu görüntü size açık bir şekilde Peer5'in bağlantısının kesildiğini, Peer8,9 ve 10'un yayından koptuğunu söyler. Peer2 veya Peer6'ya bağlanmaları gerekecek, ancak bu gecikmelere neden olacaktır. Ayrıca, bu projenin ne katkısı ne de etkinliği var.
igorpavlov
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.