Czy progresywne pobieranie HTTP jest realną alternatywą dla HLS / DASH / RTMP do zapewniania wideo na żywo?

Pracuję nad witryną, która musi przesyłać strumieniowo wideo na żywo do użytkowników, i jako taki musiałem rozejrzeć się po żałosnym stanie obecnej technologii strumieniowego przesyłania wideo w przeglądarce. Najpopularniejsze obecnie rozwiązania transmisji strumieniowej na żywo mają problemy ze zgodnością; RTMP wymaga Flasha, HLS jest obsługiwany tylko natywnie w Safari i Chrome na Androida, DASH nie jest natywnie obsługiwany nigdzie, a używanie dash.js wymaga rozszerzeń Media Source , które nie są jeszcze szeroko obsługiwane.

To prowadzi do pytania, które wydaje mi się oczywiste: czy można zastosować proste pobieranie progresywne jako alternatywę dla protokołów takich jak HLS, RTMP i DASH, które wymagają obsługi przeglądarki lub wtyczek?

Pomysł wykorzystania progresywnego pobierania do przesyłania strumieniowego mediów na żywo nie jest bezprecedensowy; ludzie już to robią dla dźwięku. Narzędzia takie jak liveCaster umożliwiają strumieniowe przesyłanie audio MP3 na żywo za pomocą pojedynczej progresywnej odpowiedzi HTTP bez potrzeby uprzednio nagranego pliku MP3, a biblioteki takie jak AmplitudeJS zrobiły wszystko , aby dodać funkcje związane z tego rodzaju transmisją audio na żywo .

Nie widziałem żadnych wystąpień tej techniki wykorzystywane w środowisku naturalnym dla filmu , choć i nie mogę powiedzieć dlaczego. Wygląda na to, że usunąłby warstwę niechlujnych i trudnych problemów ze zgodnością przeglądarki po stosunkowo niewielkim kompromisie. (A kompatybilność jest nadal ogromnym problemem dla streamingu na żywo, nawet gdy robią to profesjonaliści; jeśli spróbuję oglądać wideo na żywo na iPlayer BBC w Firefoksie, to po prostu wyświetli mi komunikat o błędzie z informacją, żebym zainstalował Flash.) Jednak nikt nie używa tę technikę i nigdy nie widziałem, żeby ktokolwiek wspominał o tym pomyśle poza mną.

Dlaczego? Czy jest jakieś podstawowe ograniczenie, którego nie widzę, które uniemożliwiałoby po prostu przesyłanie strumieniowe pliku wideo takiego jak MP4 poprzez stopniowe pobieranie podczas jego generowania i odtwarzanie go w <video>elemencie podczas pobierania?

— Mark Amery
źródło

Czy nie można użyć biblioteki javascript HLS (np. Hls.js tutaj: github.com/video-dev/hls.js/tree/master ), aby dodać obsługę HLS w różnych przeglądarkach na swojej stronie? Myślę, że może nie istniało, kiedy zadałeś to pytanie pierwotnie ... ale teraz tak jest. :)

— stuckj

Twoje pytanie jest prawidłowe i teoretycznie myślę, że możesz używać progresywnego pobierania plików do przesyłania strumieniowego wideo na żywo. W rzeczywistości wiele strumieniowych filmów online, takich jak YouTube itp., Korzysta już z HTTP. Zakładam, że ściśle mówisz o streamingu LIVE, a nie tylko streamingu.

Musisz jednak samodzielnie wdrożyć przypadki użycia transmisji na żywo! Które inaczej protokoły przesyłania strumieniowego (RTMP itp.) Robią same. Oto kilka powodów, dla których wolisz te protokoły i architekturę:

1. Zmienna szybkość transmisji

Większość strumieniowych transmisji wideo na żywo jest zakodowanych w VBR, a Twoje wideo będzie musiało szybko dostosować się do zmieniających się ograniczeń sieci klienta. Dzięki temu Twój film może zmieniać wiele rozdzielczości w bardzo krótkim czasie, w zależności od tego, jak szybkie lub wolne jest połączenie klienta.

Według Wikipedii

Działa poprzez wykrywanie przepustowości użytkownika i mocy procesora w czasie rzeczywistym oraz odpowiednie dostosowywanie jakości strumienia wideo

2. Treści na żywo

Najważniejsze jest to, że transmisja na żywo oznacza treści na żywo . W przeciwieństwie do pobierania progresywnego HTTP, nie można buforować w żadnym momencie. Użytkownik musi zobaczyć najnowszą ramkę przeznaczoną dla całego świata i nie może pozostać w tyle.

3. Wyłącz wyszukiwanie

Drobny problem, ale protokół nie powinien zezwalać użytkownikowi na wyszukiwanie do tyłu (i oczywiście do przodu). Powinno to być kontrolowane nie tylko na poziomie odtwarzacza wideo, ale także na poziomie sieci.

4. Częste odłączenia / zawodna sieć

Nie jestem pewien co do tego punktu, ale wiem, że kiedy połączenie przychodzące HTTP zostanie odłączone, ustanowienie kolejnego uzgadniania (nawet z keep-alive) może trochę potrwać . Protokoły na żywo łączą się i rozłączają znacznie szybciej ze względu na następny punkt ->

5. Opóźnienie

HTTP z natury działa przez TCP, co zapewnia gwarantowane dostarczanie pakietów. Porównaj to z UDP stosowanym w wielu protokołach (szczególnie w grach wieloosobowych na żywo), w których szybkość jest ważniejsza niż gwarancje.

Więcej informacji można znaleźć tutaj -> https://en.wikipedia.org/wiki/Streaming_media#Protocols

6. Kopiowanie treści

Większość serwerów transmisji na żywo reaguje tylko na aktualną zawartość. Mimo że nadal można kopiować zawartość strumieni na żywo, należy skorzystać z przechwytywania ekranu itp. Dawanie progresywnego pobierania HTTP sprawia, że zadanie kopiowania treści jest dość proste (stąd tak wielu tylu pobierających YouTube).

Teraz można modelować HTTP, aby zapewnić większość z powyższych.

Wspomniany przez ciebie HTTP HTTP Streaming na żywo (HLS) firmy Apple jest najbliższy temu, co próbujesz osiągnąć.

I prowadzone są aktywne badania w tej dziedzinie, jak podano tutaj -> http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=65749&PageNum=2

Szukam więcej informacji i zaktualizuję tę odpowiedź.

— Gaurav Ramanan
źródło

Wydaje się niewłaściwe podawanie opóźnienia jako wady korzystania z progresywnego pobierania HTTP, biorąc pod uwagę, że głównymi konkurentami są DASH i HLS, które dostarczają segmenty wideo za pośrednictwem wielu kolejnych żądań HTTP. Nie znam wszystkich szczegółów protokołów, ale zakładam, że to drugie podejście wymaga minimalnego opóźnienia o długości co najmniej stosowanej długości segmentu, podczas gdy przy podejściu progresywnego pobierania nie ma teoretycznego minimalnego opóźnienia - niższe opóźnienie powinno być ogłoszenie Vantage postępowego podejścia do pobrania, prawda?

— Mark Amery

Ponadto niektóre inne obawy - takie jak wyszukiwanie i odzyskiwanie po rozłączeniu - to problemy, które dotyczą w równym stopniu implementacji JavaScript DASH, ale dash.js prawdopodobnie je pokonuje. Wyobrażam sobie, że można je pokonać w przypadku odtwarzacza progresywnego poprzez kradzież wszelkich rozwiązań wymyślonych przez programistów dash.js.

— Mark Amery

@MarkAmery Jeśli porównasz DASH i HLS, to tak, myślę, że jest porównywalny. Ale jeśli porównasz to z niektórymi starszymi protokołami korzystającymi z UDP, HTTP traci ręce! Nawet jeśli widzisz, że obecnie wiele systemów czasu rzeczywistego jest budowanych przy użyciu Websockets i unika HTTP ze względu na problemy z opóźnieniami.

— Gaurav Ramanan

Łatwość kopiowania treści jest jednak prawdziwą wadą w stosunku do dash.js i HLS. I nie jestem pewien, w jaki sposób można zastosować strumienie o zmiennej przepływności przy pobieraniu progresywnym, chociaż spodziewam się, że byłoby to możliwe z odrobiną przebiegłości.

— Mark Amery

@MarkAmery Jeśli chodzi o transmisję strumieniową w czasie rzeczywistym i na żywo, musimy wziąć pod uwagę wydajność, a nie tylko możliwość. Zajmę się DASH, ale zastanawiam się, czy istnieją testy porównawcze, które pokazują porównania wydajności między protokołami przesyłania strumieniowego a odzyskiwaniem HTTP po rozłączeniu.

— Gaurav Ramanan