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?

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