что такое hls видео

Что такое hls видео

HLS (HTTP Live Streaming) — протокол, предназначенный для передачи мультимедиа (видео и аудио) по сети. Разработан в 2011 году компанией Apple.

Благодаря своим преимуществам, протокол HLS широко применяется провайдерами интернет-телевидения, а также онлайн-кинотеатрами, предоставляющими услуги «видео по запросу».

Преимущества HLS

Кроме того, для вещателей HLS прост в настройке, а его использование не предусматривает лицензионных сборов и отчислений.

Недостатки HLS

Основной недостаток протокола HLS проявляется при просмотре «живых» эфиров и заключается в отставании картинки, которую просматривает абонент на своём экране, от того, что происходит в реальности. Это связано с тем, что происходящее сначала при съёмке записывается, затем кодируется, передаётся через интернет на удаленные серверы и декодируется для последующего просмотра. На всё это, как правило, требуется порядка 20-60 секунд.

Как работает HLS

Трансляции по протоколу HLS осуществляются по принципу дробления потока на фрагменты.

Если трансляция медиа ведётся в режиме «по запросу», M3U-файл содержит ссылки сразу на все фрагменты фильма. В режиме «живой» трансляции (например, при просмотре классического телеканала) в M3U-файле есть только ссылки на несколько фрагментов, при каждом запросе клиентского проигрывателя к плейлисту его содержимое динамически обновляется, пополняясь новыми фрагментами.

Источник

Хранение видео в Yandex.Cloud

Если вам нужно добавить на свой сайт видео, то может возникнуть вопрос, где его хостить и как потом раздавать. В этом посте разберем варианты и рассмотрим примеры использования Yandex Object Storage.

Формат MP4 знаком, наверное, всем. Но если мы хотим показывать видео на сайте эффективно, то стоит задуматься: лучшее ли это решение для нашей задачи — просто выложить все видео одним файлом MP4?

Протокол HLS (HTTP Live Streaming) был предложен в 2009 году и к настоящему времени де-факто стал стандартом в области адаптивного видеостриминга.

HLS был разработан Apple как замена их собственной разработки QuickTime Streaming Server, а также как альтернатива другому популярному на тот момент протоколу — Real-Time Messaging Protocol (RTMP). Этот протокол, выпущенный Adobe в 2002 году, использовал технологию Flash, чтобы передавать видео с низкой задержкой через интернет. Не смотря на то, что Flash давно «умер», RTMP до сих пор остается популярным протоколом для видеотрансляций.

Что же такое HLS?

Хотя HLS не так широко известен, но он, наряду с MPEG-DASH и SRT, остается одним из главных протоколов, которые обеспечивают доставку видео- и аудиоконтента в современном интернете. Велики шансы, что вы пользуетесь им каждый день, даже не задумываясь об этом. Особенно если вы — пользователь экосистемы Apple.

Хотя HLS и был разработан в Apple, он широко поддерживается и на других платформах: Linux, Windows, смартфонах с Android и iOS, OTT-устройствах, Smart TV, а также в браузерах Google Chrome, Safari, Android Browser, Microsoft Edge, Chrome for Android и Opera Mobile. На части платформ поддержка нативная, в других же она реализована через JS-плееры.

Тот факт, что потоковая передача HLS обычно осуществляется через видеоплеер HTML5, делает HLS универсальным и широко совместимым. Его часто называют «HTML5-видео», что не совсем точно. Видеоплеер HTML5 просто совместим с HLS.

Что значит «протокол»?

HLS — это протокол потоковой передачи видео. Но что это означает? Возможно, вы слышали термин «кодек», но важно отметить, что потоковый протокол — это не кодек. Протокол — это более широкая категория.
Потоковый протокол — это стандартизированный метод передачи видеоконтента между устройствами. Протокол может предполагать использование определенного кодека (или кодеков), который будет использоваться для сжатия и распаковки видео- и аудиоконтента.
Например, HLS поддерживает множество популярных кодеков:

Audio: AAC-LC, HE-AAC+ v1 & v2, xHE-AAC, Apple Lossless, FLAC

Video: H.265, H.264

Преимущества HLS

HLS предназначен для обеспечения надежности и динамической адаптации к сетевым условиям путем оптимизации (т. е. ухудшения или улучшения) воспроизведения видео для доступных скоростей интернета. Кроме того, он «заботится» о разных аспектах, которые связаны с доставкой видеоконтента зрителям:

Стриминг с адаптивным битрейтом (Adaptive Bitrate Streaming) — HLS подстраивает качество видео под текущую скорость интернет-канала. Это позволяет авторам предлагать несколько видеопотоков в разном качестве, а плееру переключаться между ними незаметно.

Пример среднего битрейта видео (Кбит/с), источник: Apple

Совместимость со многими устройствами — HLS гарантирует, что ваш видеоконтент будет воспроизводиться на любом устройстве, которое может запустить совместимый плеер (например, HTML5).

Субтитры — HLS поддерживает скрытые субтитры. Это позволяет авторам встроить несколько потоков субтитров (например, на разных языках).

Возможность менять аудио дорожку — HLS поддерживает несколько потоков аудио, между которыми можно переключаться.

Возможность вставлять рекламу — HLS использует для этого технологии VPAID и VAST.

Масштабирование — HLS обладает высокой масштабируемостью для доставки видеофайлов и потокового контента через глобальные сети доставки контента (CDN). В отличие от протокола RTMP, который работает совместно с Flash Player, HLS может легко масштабироваться для доставки с помощью обычных веб-серверов через CDN. Распределяя рабочую нагрузку по сети серверов, CDN приспосабливаются к всплескам вирусной аудитории и гораздо большим, чем ожидалось, живым аудиториям. CDN также помогают улучшить качество просмотра, кешируя аудио- и видеосегменты. Для сравнения, поддержка CDN для RTMP быстро снижается. RTMP также требует использования выделенного сервера потоковой передачи, что делает его более ресурсоемким для развертывания.

Защита от пиратства — реализуется через поддержку большого количества технологий DRM.

Вот более подробный пост про то, как можно ограничить доступ к видео при помощи шифрования AES-128.

Недостатки HLS

HLS имеет некоторые ограничения, но они связаны с конкретными проектными решениями, которые были приняты при разработке протокола.

Часть этих ограничений связана с задержкой. HLS ставит во главу угла комфорт пользователя, а не низкую задержку, поэтому live-контент, который транслируется с использованием протокола HLS, не является достаточно «живым». Зритель увидит его с задержкой до 30 секунд. Таким образом, HLS — не лучший выбор для таких приложений, как веб-конференции или управление устройствами, где необходимо видео в реальном времени (камеры и дроны). В этом случае лучше использовать более быстрый потоковый протокол, например WebRTC (Web Real-Time Communications).

Задержка в HLS возникает из-за того, что протокол разбивает видео на множество многосекундных фрагментов (сегментов), которые обычно имеют длительность 2–6 секунд. И поскольку протокол HLS также должен буферизировать несколько таких небольших сегментов одновременно, задержка может составлять десятки секунд. Однако если задержка или плохие сетевые условия не являются проблемой, то HLS — это протокол, который вам нужен.

Итак, почему стоит использовать именно HLS?

С HLS создатели контента могут подготовить версии своего видео для нескольких различных интернет-каналов и условий воспроизведения: 3G, 4G, LTE, медленный публичный Wi‑Fi, быстрый домашний интернет.

Различные поставщики CDN постепенно отказываются от поддержки RTMP, заявляя, что его развертывание становится слишком дорогим. Вместо этого набирают популярность такие протоколы, как HLS, SRT и MPEG-DASH.

Adobe перестал поддерживать технологию, на которую опирается RTMP. Поэтому однажды ваш процесс потоковой передачи RTMP станет технологически устаревшим и потеряет поддержку со стороны производителя. Это лишь вопрос времени.

HLS оптимизирует доставку аудио и видео на обширный спектр мобильных, настольных, планшетных и OTT-устройств.

HLS позволяет доставлять видео по запросу с помощью шифрования и аутентификации.

HLS значительно снижает затраты на CDN. При этом он обеспечивает только оптимальный битрейт для клиентской сети и избегает сценария «частичного воспроизведения и полной загрузки», который присущ прогрессивной потоковой передаче HTTP. Например, когда всё видео представлено одним файлом MP4.

Apple App Store требует, чтобы приложения с десятиминутным (и более) видео использовали HLS.

Практическая часть

Надеюсь, я смог вас убедить, что сегодня для распространения видеоконтента через интернет стоит смотреть в сторону HLS.

Давайте теперь на примере рассмотрим способ, как нам использовать объектное хранилище в Yandex.Cloud.

Object Storage — это решение для хранения больших объемов данных за относительно небольшие деньги. Оно идеально подходит для чего-то вроде видеофайлов, которые, как правило, имеют довольно большой объем. Доступ к файлам (или объектам, как их часто называют) осуществляется через HTTP(S), что делает Object Storage отличным решением для хранения и обслуживания ваших HLS-видео.

Для начала нам понадобится бакет в хранилище. Если у вас его нет, то вот инструкция, как его создать.

Подготовка видео

Если у вас уже есть видео в формате HLS, то смело переходите к следующему разделу.

Если же его нет, то вам понадобится утилита ffmpeg, при помощи которой вы сможете конвертировать видео и аудио во множество форматов, в том числе HLS.

Установка ffmpeg

Скачайте последнюю версию отсюда.

Откройте консоль в папке.

Выполните команду brew install ffmpeg

Вызовите ffmpeg — вы должны будете увидеть информацию о версии ffmpeg.

Видео для примера

Возьмем какой-нибудь видеофайл и посмотрим информацию о нем:

В консоли появится приблизительно следующее:

Конвертация

Подготовим команду для конвертации видео:

Теперь подробно разберем, что означают все эти ключи:

-i sample.mp4 — задает sample.mp4 в качестве входного файла.

-vf «scale=w=1280:h=720:force_original_aspect_ratio=decrease» — масштабирует видео до максимальных размеров в пределах заданного разрешения 1280×720 с сохранением соотношения сторон.

-ac:a:0 2 — указывает, что если в первом аудиопотоке (a:0) больше двух каналов, нужно смиксовать их в стереосигнал.

-profile:v main — устанавливает профиль кодека H.264 в main (это означает включение поддержки всех современных устройств). Подробнее в статье.

-crf 20 — Constant Rate Factor, высокоуровневая настройка качества.

2 сек) — это важно, влияет на корректную нарезку на сегменты.

-sc_threshold 0 — не создавать ключевые кадры при смене сцены.

-hls_time 4 — указывает длину сегмента в секундах. Реальная длина будет зависеть от ключевых кадров.

-hls_playlist_type vod — добавляет тег #EXT-X-PLAYLIST-TYPE:VOD и сохраняет все сегменты в плейлист.

-hls_segment_filename sample/720p_%03d.ts — явным образом задает имена файлов для сегментов.

Утилита ffmpeg поддерживает несколько входных и выходных файлов и все результаты могут быть сгенерированы параллельно одной длинной командой.

Очень важно, чтобы помимо параметров разрешения и битрейта команды были идентичны, тогда результаты будут правильно выровнены, то есть ключевые кадры будут установлены в нужных местах, чтобы обеспечить плавное переключение между ними «на лету».

Мы создадим четыре версии с разрешениями:

1080p 1920×1080 (original)

Мастер-плейлист

HLS-плеер должен знать, что существует несколько версий нашего видео, поэтому мы создаем мастер-плейлист HLS, чтобы указать их и сохранить вместе с другими плейлистами и сегментами в файл playlist.m3u8.

Как правильно выбрать битрейт

Битрейт зависит в основном от разрешения и типа контента. При установке слишком низкого битрейта пикселизация изображения будет особенно видна в тех областях, где происходит быстрое движение. Когда битрейт слишком высок, выходные файлы могут быть чрезмерно большими без дополнительного значения.

Чтобы выбрать правильный битрейт, нужно понимать его содержимое. Видео с резкими движениями, например запись спортивных или новостных событий, потребует более высокого битрейта, чтобы избежать пикселизации. А для контента с плавными движениями в кадре, например, музыкального концерта или интервью, будет достаточно низкого битрейта без видимых изменений качества.

Вот некоторые хорошие значения по умолчанию:

Загрузка данных

Настройка бакета

Для того чтобы видеоплееры могли получить доступ к видеофайлам, необходимо указать настройки CORS в бакете.

Это максимально широкое правило для примера.

Все готово

Если вы хотите ограничить круг сайтов, куда можно будет встраивать видео, то прочитайте этот пост.

Теперь можно выкладывать видео на свой сайт.

В пример я добавил минимальный контрол для переключения уровня качества.

Вот использованный плеер и react-обертка. А вот альтернативный плеер.

Итак, в чем же плюс?

Если вы откроете консоль, то увидите, что после того как браузер загрузил несколько первых сегментов видео, загрузка приостанавливается. Это позволяет нам экономить трафик в тех случаях, когда пользователь открыл страницу с видео, начал просмотр видео и остановился. В этом случае нам не нужно загружать весь видеофайл целиком. Мы можем вовремя остановиться, а потом, если это понадобится (пользователь продолжит воспроизведение), загрузить остальное.

Источник

HLS против RTMP — сухая статистика

Если кто-то решил сделать самостоятельно обработку, хранение и передачу видео для своего онлайн-проекта, а не использовать сайты вроде YouTube, он неизбежно приходит к вопросу о том, какой протокол передачи использовать для трансляции видео на устройства пользователей. Выбор невелик, т.к. есть ряд отраслевых стандартов, которые поддерживают те или иные устройства. Кроме того, выбор протокола во многом зависит от «класса» видео — живая трансляция или видео-по-запросу. От выбора протокола также зависит и выбор медиа-сервера, который будет двигателем вашей медиа-машины: будете ли ставить несколько разнородных серверов или построите сеть доставки на одном решении? Поэтому нужно взвесить всё и принимать решение исходя из критериев вашего бизнеса.

В общем, получается уравнение со многими неизвестными. Здесь немаловажна динамика процесса — а куда вообще идёт индустрия? Вдруг я вложусь в поддержку технологии, а она загнётся через год, ведь такое уже бывало. Или поставлю на модную технологию, а её никто не поддерживает?

Мы решили оценить, как менялась доля разных протоколов с течением времени — посмотреть в динамике весь процесс. Данные взяли за последний год.

Исходные данные

Для начала — кто мы такие, чтобы судить о долях рынка? Мы — разработчики веб-сервиса отчетности для медиа-серверов. На рынке работаем четвертый год и к нам приходят компании с разными инфраструктурами, разным количеством серверов и разными потребностями. Получается неплохой слепок состояния отрасли.

Мы сделали небольшой отчет, где можно выбирать диапазон дат и получать данные с графиком по количеству просмотров видео через разные протоколы.

Отчет также периодически обновляется у нас в блоге, он доступен по соответствующему тегу.

Поехали

Отчет за июнь/июль 2014 выглядит примерно так. Из 1.4 миллиарда просмотров больше половины — это HLS. На втором месте — RTMP с четвертью просмотров. RTSP — примерно шестая часть. Остальные находятся в районе статистической погрешности.

Что было год назад за тот же период? Ситуация почти зеркальная. RTMP — почти две трети, RTSP и HLS делят второе и третье места. Правда, и база для измерений была меньше почти в 3 раза — «всего» 500 миллионов просмотров. Серверов в нашем сервисе тоже было поменьше, конечно.

Пройдемся между этими двумя точками.

Итак, июнь — август 2014 года, 3 месяца лета. 800 миллионов просмотров, но доли такие же, август изменений не привнёс.

Сентябрь — ноябрь 2013. Начался новый сезон, HLS начал отъедать долю RTMP. Всего 1.1 миллиарда просмотров, у RTMP примерно половина от общего числа, HLS — четверть.

Декабрь 2013 — февраль 2014. 1.4 миллиарда просмотров, из них на HLS приходится уже больше 40%. RTMP и RTMP делят второе и третье место с четвертью доли. Олимпиада в Сочи дала прирост числа просмотров и одновременно заставила провайдеров вспомнить обо всех клиентах со всеми их экзотическими или старыми девайсами, которые понимают только RTSP — отсюда и скачок этого протокола.

Март — май 2014. 1.9 миллиарда просмотров и HLS уже безоговорочный лидер с более чем половиной рынка. RTMP уверенно держит четверть, остальные заняли те доли, которые мы видели на первой диаграмме.

Как это всё понимать?

HLS (HTTP Live Streaming) на сегодня стал стандартом де-факто в мире потоковой передачи видеоданных для потребительских устройств. Изначально сделанный для девайсов одной фруктовой компании, быстро набрал популярность на других устройствах — десктопах, STB, а также Андроидах — начиная с версии 4 они начали понимать этот протокол.

RTMP остается незаменим там, где требуется передача данных близко к реальному масштабу времени. HLS даёт некоторую задержку при соединении, чтобы скачать первый чанк с данными, а в случае с RTMP отображение начинается практически сразу. В целом, это наиболее совершенный протокол передачи медиа в реальном времени, несмотря на все неоднозначности в реализации (каждый новых вендор добавляет свои особенности), более трудоёмкое развёртывание и масштабирование относительно HLS.

RTSP по-прежнему используется как fallback для старых Андроидов.

Отдельно хочется сказать про MPEG-DASH — несмотря на все усилия индустрии, переход на него происходит со скрипом. Конечно, рано или поздно произойдет плавный переход со всех HTTP-based протоколов — HLS, HDS, SmoothStreaming — на него, но пока это лишь планы.

Интересна и доля Progressive download, на котором работает видео на немалом количестве сайтов. Технически очень простой, он позволяет начать раздачу видео-по-запросу практически безо всяких специальных медиа-серверов. Поскольку Вовза по этому протоколу не работает, его долю стало возможным отследить только по мере установки нашего Nimble Streamer на сервера клиентов. Текущие 20М+ просмотров за 2 месяца лета — не предел, и фактическая доля этого протокола совершенно точно выше. Хотя, у него есть и ограничения, которые оставляют ему относительно небольшую нишу.

Если есть вопросы по сбору данных или их интерпретации — задавайте.

Источник

Какой бывает HTML5-стриминг (и почему mp4-стриминга не существует)

Нередко клиенты спрашивают, умеет ли наш сервер «mp4-стриминг в HTML5». В 99% случаев спрашивающий не понимает о чём говорит. В этом сложно винить клиентов: из-за путаницы с терминами, технической сложности и большого разнообразия вариантов стриминга запутаться очень легко.

В этой статье мы расскажем, какой бывает HTML5-стриминг, какие варианты хорошие, и почему, чёрт побери, нельзя говорить «mp4-стриминг».

▍Термины

HTML5-видео — это когда вы вставляете в веб-страницу тег и указываете ему какой-то src. HTML5-стриминг — это то же HTML5-видео, но когда в src не готовый файл, а постоянно обновляющийся видеопоток. Ролик на Ютубе — это HTML5-видео, трансляция в Твитче — HTML5-стриминг.

Тегу неважно, как видеопоток формируется и передаётся, и сможет ли браузер его проиграть. Главное, чтобы в src была ссылка на какой-то видеопоток. Говоря техническим языком, спецификация ничего не говорит о том, какие протоколы, транспорты и кодеки поддерживаются в HTML5-видео.

Протокол — это то, как два участника видеосвязи (почти всегда это клиент и сервер) обмениваются данными с целью получения данных. Клиентом называют того, кто приходит к серверу и инициирует сессию связи. Видеопоток может течь от сервера к клиенту (тогда это обычное проигрывание) или от клиента к серверу (тогда это публикация). Даже когда гигантский шкаф, жрущий электричество как многоквартирный дом приходит к маленькой IP-камере, то она будет сервером, а этот шкаф клиентом.

Протокол обычно подразумевает хотя бы команду Play (начать проигрывание), но иногда есть и расширенные варианты: пауза, продолжение, публикация, перемотка и т. п.

Примеры протоколов: RTSP, RTMP, HTTP, HLS, IGMP.

Транспорт, или транспортный контейнер, или контейнер — это то, как сжатое видео упаковывается в байты для передачи от одного участника к другому (по какому-то протоколу).
Примеры контейнеров: MPEG-TS, RTMP, RTP.

Кодек — многозначный термин. Здесь он означает способ сжать сырое видео. Разница между кодеком и транспортом в том, что кодек — это про подготовку видео, а транспорт — про передачу видео по протоколу. Видео, сжатое одним кодеком, можно пересылать по разными протоколам и разными транспортами. Большинство видеостриминговых серверов не залезают глубже кодированного видео и оперируют только протоколами и транспортами.

Примеры кодеков: h264, aac, mp3.

Итак, в спецификации HTML5 не описаны протоколы, транспорты и кодеки. Поэтому авторы браузеров сами выбирают, что поддерживать, а под «HTML5-стримингом» подразумевают разные вещи.

При этом есть комбинации, которые поддерживаются значительной частью браузеров. Рассмотрим самые перспективные.

HLS — это h264-видео и aac- или mp3-аудио, упакованное в транспорт MPEG-TS. Поток разбивается на сегменты, описанные в m3u8-плейлистах, и раздается по HTTP. HLS поддерживает мультибитрейтные потоки, Live/VOD. Вариант очень простой, но в то же время имеет много деталей, из-за чего на разных устройствах работает по-разному.

Разработали HLS в Эппле, поэтому изначально он работал только в Сафари на iOS и MacOS. Даже Сафари на Windows не умел играть HLS (когда еще была версия под Win).

Тем не менее, сейчас HLS умеют проигрывать все телевизионные приставки и даже почти все устройства на Андроиде.

Но не всё гладко. Производители сторонних плееров плюнули на стандарт Эппла в части донесения разных аудиодорожек и добавили проигрывание всего что есть в обычном MPEG-TS: mpeg2 video, mpeg2 audio и т. п. Из-за этого приходится отдавать разные форматы плейлистов для разных плееров.

▍MPEG-DASH

MPEG-DASH — обычно это h264/h265-видео и aac-аудио, упакованное в транспорт mp4, или vp8/vp9, упакованное в WebM, хотя стандарт и не привязан к конкретным кодекам, протоколам и транспортам. Как и в HLS, поток может разбиваться на сегменты, но это необязательно. Вместо плейлистов — MPD-манифест в XML.

MPEG-DASH во многом похож на HLS. Возможно, он даже популярнее, ведь такие гиганты как Ютуб и Нетфликс уже несколько лет используют его как основной способ раздачи контента.

MPEG-DASH хорош тем, что в большинстве браузеров работает нативно, через MSE (о том, что это такое, — чуть ниже). Для него даже нет реализации на Флеше — это честный, бескомпромиссный HTML5.
Определенно, MPEG-DASH — самый настоящий HTML5-стриминг, за ним будущее.

Когда стало ясно, что Флеш всё-таки умрёт (после сотни ложных похорон), ребром встал вопрос о том, что придёт ему на смену. Хорошо было бы получить в браузерах возможность проигрывать видео по качеству и удобству близко к тому, что умеет Флеш (а он это делает всё-таки хорошо).

Во Флеше давно появился очень удобный механизм для универсального проигрывания разных вариантов — appendBytes. Суть в том, что пользовательский код сам как хочет скачивает кадры сжатого видео, упаковывает в оговоренный контейнер (с Флешем это flv) и засовывает в видеопроигрыватель. Т. е. протокол и транспорт реализуются в пользовательском коде, запускаемом в браузере.

MSE (Media Sources Extensions) — это расширение спецификации HTML5, которое позволяет делать то же, что делает appendBytes во Флеше. К сожалению, MSE намного сложнее как в понимании, так и в реализации.

MPEG-DASH, созданный на его базе, ещё хитрее, поэтому работать с ними то ещё удовольствие: тонны XML, парсинг бинарных контейнеров в Яваскрипте, непродуманные на этапе дизайна вопросы нарезки на сегменты — всё как мы любим, всё что нужно для единой безглючной реализации во всех браузерах.

Интересно, что MSE работает не только с MPEG-DASH, но и с HLS. Существует реализация hls.js, которая скачивает HLS-плейлисты, скачивает MPEG-TS-сегменты, перепаковывает их в нужный для MSE формат и играет через MSE. Эппл даже сделала шаг в сторону совместимости с MPEG-DASH — использование mp4-контейнеров в HLS.

К концу 2017 года Флеш скорее всего умрёт окончательно, и уже сегодня можно смело начинать проект с MPEG-DASH.

▍WebRTC

Во Флеше была сделана годная попытка в одной технологии реализовать и риалтайм-общение, и массовый броадкастинг. К сожалению, в HTML5 так не вышло. Для просмотра трансляций у нас есть MSE, а для видеозвонков — WebRTC.

WebRTC — это SIP в браузере: способ организовать аудио- и видеоканал и канал данных между двумя браузерами при посредничестве сервера.

Технология не предназначена для стриминга, но в принципе может и его, так что было бы неправильно забыть про него. WebRTC тоже считается HTML5, потому что вроде как ничего кроме Яваскрипта в браузере не требует. Зато требует наличия последних версий обоих популярных браузеров, а с Эджем пока вообще не совместимо.

Путаницу в понимании WebRTC вносит его использование в торрент-доставке телевидения. Суть в том, что браузеры через WebRTC организуют сеть каналов данных, а дальше по этой сети раздаются HLS- или MSE-сегменты видео, а проигрывание происходит через Флеш или MSE. Т. е. WebRTC — для доставки, MSE — для проигрывания. Важно не путать это с использованием WebRTC для проигрывания видео.

▍Так что там с mp4-стримингом?

Любой современный браузер скорее всего сможет по протоколу HTTP запросить файл, упакованный в транспорт mp4 и содержащий внутри видео, сжатое кодеком h264/aac. И даже попытаться проиграть его. Это самый удобный, понятный и стандартный вариант проигрывания файлов. Лежит себе файлик на диске, nginx его отдает. Код, проигрывающий mp4 в браузерах достаточно хорош. Например, он умеет даже скачивать куски видео по необходимости (в отличие от Флеш-плеера, который скачивает видео целиком).

Вокруг h264 сложилось немало шумихи по поводу его «закрытости» и «несвободности». Так что есть «открытая» альтернатива, которую форсит Гугл — видеокодеки vp8 и vp9, упакованные в транспорт WebM. WebM — это подмножество транспорта mkv (a. k. a. Матрёшка), который очень похож на mp4 по сути, но отличается от него своей «бинарностью».

Именно отсюда растут ноги у такого явления как «mp4-стриминг», который устроен как WebM. Дело в том что в обычном mp4 в самом начале указывается размер всего контейнера. Поэтому, если мы хотим отдать по обычному mp4 прямой эфир, у нас ничего не получится. А чтобы всё-таки получилось и можно было создавать mp4 без фиксированного конца, придуман следующий ход: сначала пишется mp4 без кадров, а потом в конце подписываются блоками по несколько секунд фрагменты с кадрами. Это называется mp4 fragmented, или mp4 streaming.

По сути это никакой не стриминг, а костыль, позволяющий создать его видимость. Mp4 — отличный формат для скачивания видео, но негодный для стриминга, так что про него можно просто забыть и никогда не использовать термин «mp4-стриминг».

Источник