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

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.

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.

@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!

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

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 .

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.

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

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

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.

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.

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.

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.

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ı .