WebRTC - skalowalna transmisja na żywo / multiemisja

PROBLEM:

WebRTC zapewnia nam połączenia wideo / audio peer-to-peer. Jest idealny do połączeń p2p, hangoutów. Ale co z nadawaniem (jeden do wielu, na przykład od 1 do 10000)?

Powiedzmy, że mamy nadawcę „B” i dwóch uczestników „A1”, „A2”. Oczywiście wydaje się, że da się to rozwiązać: po prostu łączymy B z A1, a następnie B z A2. Zatem B wysyła strumień wideo / audio bezpośrednio do A1, a inny strumień do A2. B wysyła strumienie dwukrotnie.

Teraz wyobraźmy sobie 10000 uczestników: A1, A2, ..., A10000. Oznacza to, że B musi wysłać 10000 strumieni. Każdy strumień ma ~ 40 KB / s, co oznacza, że ​​B potrzebuje wychodzącej prędkości Internetu 400 MB / s, aby utrzymać tę transmisję. Gorszący.

PYTANIE ORYGINALNE (NIEAKTUALNE)

Czy można to jakoś rozwiązać, więc B wysyła tylko jeden strumień na jakiś serwer, a uczestnicy po prostu pobierają ten strumień z tego serwera? Tak, to znaczy, że prędkość wychodząca na tym serwerze musi być wysoka, ale mogę ją utrzymać.

A może oznacza to zrujnowanie pomysłu WebRTC?

UWAGI

Flash nie działa na moje potrzeby, jak na słaby UX dla klientów końcowych.

ROZWIĄZANIE (NAPRAWDĘ)

26.05.2015 - W tej chwili nie ma takiego rozwiązania do skalowalnego nadawania dla WebRTC, w którym w ogóle nie używasz serwerów multimedialnych. Na rynku dostępne są rozwiązania serwerowe oraz hybrydowe (p2p + serwer w zależności od różnych warunków).

Jest jednak kilka obiecujących technologii, takich jak https://github.com/muaz-khan/WebRTC-Scalable-Broadcast, ale muszą oni odpowiedzieć na te możliwe problemy: opóźnienie, ogólną stabilność połączenia sieciowego, formułę skalowalności (prawdopodobnie nie są one nieskończenie skalowalne ).

PROPOZYCJE

1. Zmniejsz procesor / przepustowość, dostosowując kodeki audio i wideo;
2. Zdobądź serwer multimediów.

Ponieważ zostało to prawie omówione tutaj, to, co próbujesz tutaj zrobić, nie jest możliwe w przypadku zwykłego, staromodnego WebRTC (ściśle peer-to-peer). Ponieważ, jak powiedziano wcześniej, połączenia WebRTC renegocjują klucze szyfrowania w celu szyfrowania danych dla każdej sesji. Twój nadawca (B) będzie więc rzeczywiście musiał przesyłać swój strumień tyle razy, ile jest uczestników.

Jest jednak dość proste rozwiązanie, które działa bardzo dobrze: przetestowałem je, nazywa się bramą WebRTC. Janus jest dobrym przykładem. Jest to całkowicie otwarte oprogramowanie ( tutaj repozytorium github ).

Działa to w następujący sposób: Twój nadawca kontaktuje się z bramą (Janus), która mówi w WebRTC . Jest więc negocjacja klucza: B przesyła bezpiecznie (zaszyfrowane strumienie) do Janusa.

Teraz, kiedy uczestnicy łączą się, ponownie łączą się z Janusem: negocjacja WebRTC, zabezpieczone klucze itp. Od tej pory Janus będzie wysyłał strumienie do każdego z uczestników.

Działa to dobrze, ponieważ nadawca (B) przesyła swój strumień tylko raz, do Janusa. Teraz Janus dekoduje dane za pomocą własnego klucza i ma dostęp do surowych danych (czyli pakietów RTP) i może emitować te pakiety z powrotem do każdego uczestnika (Janus zajmie się szyfrowaniem za Ciebie). A ponieważ umieściłeś Janusa na serwerze, ma on świetną przepustowość wysyłania, więc będziesz mógł przesyłać strumieniowo do wielu peerów.

Więc tak, że nie wiążą się z serwerem, ale serwer mówi WebRTC, a ty „własne” go: wdrożyć część Janus, dzięki czemu nie trzeba się martwić o uszkodzenie danych lub mężczyzna w środku. No chyba, że ​​twój serwer jest zagrożony, oczywiście. Ale jest tak wiele, co możesz zrobić.

Aby pokazać ci, jak łatwo jest używać, w Janusie masz funkcję o nazwie incoming_rtp()(i incoming_rtcp()), którą możesz wywołać, która daje wskaźnik do pakietów rt (c) p. Możesz następnie wysłać go do każdego uczestnika (są one przechowywane w sessionstym formacie Janus, który jest bardzo łatwy w użyciu). Spójrz tutaj na jedną implementację incoming_rtp()funkcji , kilka linii poniżej możesz zobaczyć, jak przesyłać pakiety do wszystkich uczestników, a tutaj możesz zobaczyć rzeczywistą funkcję przekazywania pakietu rtp.

Wszystko działa całkiem dobrze, dokumentacja jest dość łatwa do odczytania i zrozumienia. Proponuję zacząć od „najdoskonalszego” przykładu, jest on najprostszy i możesz zrozumieć wewnętrzne działanie Janusa. Proponuję edytować plik testu echa, aby utworzyć własny, ponieważ jest dużo zbędnego kodu do napisania, więc równie dobrze możesz zacząć od pełnego pliku.

Baw się dobrze! Mam nadzieję, że pomogłem.

Jak @MuazKhan zauważył powyżej:

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

działa w chrome i nie ma jeszcze transmisji audio, ale wydaje się, że jest to pierwsze rozwiązanie.

Scalable WebRTC peer-to-peer demo.

Ten moduł po prostu inicjuje socket.io i konfiguruje go w taki sposób, że pojedyncza transmisja może być przekazywana nieograniczonej liczbie użytkowników bez problemów z przepustowością / wykorzystaniem procesora. Wszystko dzieje się peer-to-peer!

To zdecydowanie powinno być możliwe do wykonania.
Inni też są w stanie to osiągnąć: http://www.streamroot.io/

AFAIK, jedyną obecną implementacją, która jest istotna i dojrzała, jest Adobe Flash Player, który od wersji 10.1 obsługuje multiemisję p2p dla transmisji wideo peer to peer.

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

Nadawanie „skalowalne” nie jest możliwe w Internecie, ponieważ multiemisja IP UDP jest tam niedozwolona. Ale teoretycznie jest to możliwe w sieci LAN.
Problem z Websockets polega na tym, że nie masz dostępu do RAW UDP z założenia i nie będzie on dozwolony.
Problem z WebRTC polega na tym, że jego kanały danych używają formy SRTP, gdzie każda sesja ma własny klucz szyfrowania . Więc jeśli ktoś nie „wymyśli” lub API pozwoli na współdzielenie jednego klucza sesji pomiędzy wszystkimi klientami, multiemisja jest bezużyteczna.

Istnieje rozwiązanie dostarczania wspomaganego przez rówieśników, co oznacza, że ​​jest to podejście hybrydowe. Zarówno serwer, jak i rówieśnicy pomagają w dystrybucji zasobu. Takie podejście przyjęły peer5.com i peercdn.com .

Jeśli mówimy konkretnie o transmisji na żywo, będzie to wyglądać mniej więcej tak:

1. Nadawca wysyła wideo na żywo do serwera.
2. Serwer zapisuje wideo (zwykle również transkoduje je do wszystkich odpowiednich formatów).
3. Tworzę metadane dotyczące tego strumienia na żywo, zgodne z HLS, HDS lub MPEG_DASH
4. Konsumenci przeglądają odpowiednią transmisję na żywo, a odtwarzacz pobiera metadane i wie, które fragmenty filmu mają być następne.
5. W tym samym czasie konsument jest połączony z innymi konsumentami (przez WebRTC)
6. Następnie gracz pobiera odpowiedni fragment bezpośrednio z serwera lub od rówieśników.

Podążanie za takim modelem może zaoszczędzić do ~ 90% przepustowości serwera w zależności od szybkości transmisji na żywo i wspólnego łącza w górę widzów.

zastrzeżenie: autor pracuje w Peer5

Moi mistrzowie koncentrują się na rozwoju hybrydowego protokołu transmisji strumieniowej na żywo cdn / p2p przy użyciu WebRTC. Pierwsze wyniki opublikowałem pod adresem adresem http://bem.tv

Wszystko jest open source i szukam współpracowników! :-)

Odpowiedź udzielona przez Angel Genchev wydaje się być poprawna, jednak istnieje teoretyczna architektura, która umożliwia transmisję z niskim opóźnieniem przez WebRTC. Wyobraź sobie, że B (nadawca) przesyła strumieniowo do A1 (uczestnik 1). Następnie A2 (uczestnik 2) łączy. Zamiast przesyłania strumieniowego z B do A2, A1 rozpoczyna przesyłanie strumieniowe wideo z B do A2. Jeśli A1 się rozłączy, A2 zacznie odbierać od B.

Ta architektura może działać, jeśli nie ma opóźnień i limitów czasu połączenia. Więc teoretycznie jest to słuszne, ale nie praktycznie.

W tej chwili korzystam z rozwiązania po stronie serwera.

Na rynku dostępnych jest kilka rozwiązań skalowalnych WebRTC. Zapewniają niskie opóźnienia i skalowalne przesyłanie strumieniowe webrtc. Oto kilka próbek. Janus , Jitsi , Wowza , Red5pro , Ant Media Server

Jestem programistą dla Ant Media Server , dostarczam zarówno wersję dla społeczności, jak i dla przedsiębiorstw, w tym Android i iOS SDK. Daj nam znać, jeśli możemy Ci jakoś pomóc.

Opisujesz używanie WebRTC z wymogiem „jeden do wielu”. WebRTC jest przeznaczony do przesyłania strumieniowego peer-to-peer, jednak istnieją konfiguracje, które pozwolą Ci skorzystać z małego opóźnienia WebRTC podczas dostarczania wideo do wielu widzów.

Sztuczka polega na tym, aby nie obciążać klienta przesyłania strumieniowego każdą przeglądarką i, jak wspomniałeś, mieć „przekaźnikowy” serwer multimediów. Możesz to zbudować samodzielnie, ale szczerze mówiąc, najlepszym rozwiązaniem jest często użycie czegoś takiego jak produkt Wowza do przesyłania strumieniowego WebRTC .

Aby wydajnie przesyłać strumieniowo z telefonu, możesz użyć GoCoder SDK firmy Wowza, ale z mojego doświadczenia wynika, że bardziej zaawansowany pakiet SDK, taki jak StreamGears, działa najlepiej.

Rozwijam system transmisji WebRTC przy użyciu serwera Kurento Media Server . Kurento Obsługuje kilka rodzajów protokołów przesyłania strumieniowego, takich jak RTSP, WebRTC, HLS. Działa również w czasie rzeczywistym i skalowaniu.

W związku z tym Kurento nie obsługuje RTMP, który jest teraz używany w YouTube lub Twitch. Jednym z problemów ze mną jest liczba użytkowników jednocześnie z tym.

Mam nadzieję, że to pomoże.

Ponieważ peer1 jest tylko peerem, który wywołuje getUserMedia (), tj. Peer1 tworzy pokój.

1. Tak więc peer1 przechwytuje multimedia i rozpoczyna pokój.
2. peer2 dołącza do pokoju i pobiera strumień (dane) z peer1, a także otwiera połączenie równoległe o nazwie „peer2-connection”
3. Kiedy peer3 dołącza do pokoju i pobiera strumień (dane) z peer2, a także otwiera połączenie równoległe o nazwie „peer3-connection” i tak dalej.

Ten proces jest ciągły, ponieważ wielu rówieśników łączy się ze sobą.

W związku z tym pojedyncza transmisja może zostać przekazana nieograniczonej liczbie użytkowników bez żadnych problemów z przepustowością / wykorzystaniem procesora.

Wreszcie, wszystko powyżej zawarte jest odniesieniem z Link .