Чи прогресивний HTTP завантажує життєздатну альтернативу HLS / DASH / RTMP для забезпечення прямого відео?

Я працюю над веб-сайтом, який потребує передачі відео в прямому ефірі користувачам, і тому мені довелося обернутися голосом про стан жалості поточної технології веб-трансляції на основі браузера. Наразі найпопулярніші рішення для прямого трансляції мають проблеми сумісності; RTMP вимагає Flash, HLS тільки спочатку підтримується Safari і Chrome для Android, DASH НЕ спочатку підтримується в будь-якому місці і з допомогою dash.js вимагає Media Source Extensions , які ще не є широко підтримується.

Це призводить до питання, який мені здається очевидним: чи можна використовувати просте прогресивне завантаження як альтернативу протоколам на зразок HLS, RTMP та DASH, яким потрібна підтримка браузера або плагіни?

Ідея використання прогресивного завантаження для передачі живих медіа не є безпрецедентною; люди вже роблять це для аудіо. Такі інструменти, як liveCaster, дозволяють передавати аудіо в прямому ефірі MP3 через єдиний прогресивний відповідь HTTP, не потребуючи заздалегідь записаного MP3-файлу, а бібліотеки на зразок AmplitudeJS пішли з шляху, щоб додати функції, пов’язані з таким видом прямої трансляції аудіо .

Я не бачив жодних випадків використання цієї техніки в природі для відео , і я не можу сказати, чому. Схоже, це дозволить видалити шар безладної та складної проблеми сумісності браузера за відносно невеликі компроміси. (І сумісність все ще є величезною проблемою для прямого ефіру, навіть коли професіонали це роблять; якщо я спробую переглянути відео в прямому ефірі на iPlayer BBC в Firefox, це просто дає мені повідомлення про помилку, яке говорить мені про встановлення Flash.) Але ніхто не використовує ця техніка, і я ніколи не бачив, щоб ніхто, крім мене, згадував ідею .

Чому? Чи є фундаментальне обмеження, яке я не бачу, що унеможливить просто потік відеофайлів, таких як MP4, шляхом прогресивного завантаження під час його генерування та відтворення його в <video>елементі під час завантаження?

Ваше запитання справедливе і теоретично я думаю, що ви можете використовувати прогресивні завантаження для прямого трансляції відео. Насправді багато Інтернет-потокового відео, як YouTube тощо, вже використовують HTTP. Я припускаю, що ви суворо говорите про LIVE потокове, а не просто потокове.

Вам доведеться реалізовувати випадки використання прямого ефіру прямо зараз! У іншому випадку протоколи потокового передавання (RTMP тощо) роблять самі. Ось кілька причин віддати перевагу цим протоколам та архітектурі:

1. Змінна швидкість передачі бітів

Більшість потокових відео в прямому ефірі закодовані в VBR, і ваше відео доведеться швидко адаптуватися до мінливих перевантаженостей вашого клієнта. Таким чином, ваше відео може переключитися на кілька дозвіл за дуже короткий час, залежно від того, наскільки швидким або повільним є з'єднання з клієнтом.

За даними Вікіпедії

Він працює, визначаючи пропускну здатність користувача та ємність процесора в режимі реального часу і відповідно коригуючи якість відеопотоку

2. Живий контент

Найважливіший момент - трансляція в прямому ефірі означає живий контент. На відміну від прогресивного завантаження HTTP, ви не можете будь-коли завантажувати буфер. Користувач повинен бачити останній кадр, призначений для всього світу, і не може відставати.

3. Вимкнути пошук

Незначна проблема, але протокол конкретно не повинен дозволяти користувачеві шукати назад (і, очевидно, вперед). Це не слід контролювати лише на рівні відеоплеєра, а й на рівні мережі.

4. Часті відключення / ненадійні мережі

Мені дещо незрозуміло з цього приводу, але я знаю, що після того, як вхідне завантаження HTTP буде відключено, це може зайняти деякий час, щоб встановити ще одне рукостискання (навіть з keep-alive). Живі протоколи набагато швидше підключаються та відключаються через наступну точку ->

5. Затримка

HTTP по суті працює над TCP, що забезпечує гарантовану доставку пакетів. Порівняйте це з UDP, використовуваним у безлічі протоколів (особливо в іграх для багатокористувацьких ігор), де швидкість є пріоритетною перед гарантіями.

Детальніше дивіться тут -> https://en.wikipedia.org/wiki/Streaming_media#Protocols

6. Зміст копіювання

Більшість серверів живого потоку відповідатимуть лише на вміст поточного часу. Хоча все ще можливо скопіювати вміст прямих трансляцій, доводиться вдаватися до захоплення екрана і т. Д. Надання прогресивного завантаження HTTP робить завдання копіювання вмісту досить тривіальним (звідси стільки багатьох завантажувачів YouTube).

Тепер HTTP можна моделювати таким чином, щоб забезпечити більшість вищезазначених.

Ви вже згадували, що Apple HTTP Live Streaming (HLS) Apple наближається до того, що ви намагаєтесь досягти.

І в цій галузі проводяться активні дослідження, як зазначено тут -> http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=65749&PageNum=2

Я шукаю додаткову інформацію і оновлю цю відповідь.