что такое потоковое видео в интернете

5 фактов о потоковом видео и что это значит для маркетологов

Потоковое вещание стало основным источником потребления видео в США и во всем мире. В России тенденция набирает обороты вместе с распространением таких сервисов, как Kinopoisk или Ivi.ru. А агентство Reuters в сентябре 2019 года сообщило, что и Яндекс присоединяется к общемировой тенденции потокового видео и планирует запускать собственный сервис в рамках Яндекс.Дзена. Что маркетологам нужно знать в связи с этим? Делимся фактами в статье.

Для большинства из нас интернет уже является основным источником видео, которые мы смотрим.

В США потоковое вещание движется к точке насыщения. Такие сервисы, как Netflix, Amazon, Hulu и теперь Disney+ быстро набирают новых подписчиков. Потоковая передача становится основным источником потребления видео не только в США, но и во всем мире. Не говоря уже о том, что YouTube практически повсеместно распространен по всему миру.

1. Постепенный отказ от кабельного телевидения

Это может показаться очевидным, но потребители быстро отказываются от кабельного ТВ в пользу потоковой передачи. В 2018 году в США насчитывалось 33 миллиона таких пользователей, и ожидается, что к 2022 году это число вырастет до 55 миллионов.

Но в то время как отказ от кабеля становится нормой ускоренными темпами, все еще существует большое количество людей, которые не меняют свои привычки. Как правило, это старшее поколение.

Что это значит для маркетологов?

Если вы ориентируетесь на более молодую аудиторию, обратите внимание на то, что потоковые сервисы предлагают для привлечения аудитории. Кроме того, выделите бюджет видеорекламы на цифровые каналы.

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

2. Потоковое вещание приближается к точке насыщения внутри США, но не в России

57% американских потребителей имеют доступ хотя бы к одному потоковому сервису. Фактически, в среднем потребители подписываются на три потоковых сервиса.

Согласно данным Statista, рост Netflix в США был относительно ровным до 2019 года — около 60 миллионов подписчиков.

Отчасти это может быть связано с тем, что на рынке появляется все больше конкурентов. Disney+ — прекрасный пример, но многие подписчики Disney+, вероятно, также являются пользователями Netflix. Disney и BBC запускают совместное предприятие под названием BritBox. С запуском студиями собственных платформ Netflix теряет доступ к популярному контенту.

Эти данные показывают, что многие потоковые платформы растут, забирая абонентов с других платформ, а не рынок в целом растет.

В России перенасыщения пока точно не наблюдается и даже наоборот. Так, в 2018 году IAB провели исследование, в котором выяснили, что 61% российских пользователей признались, что стали больше смотреть потоковое видео.

Что это значит для маркетологов?

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

3. На международном уровне потоковое вещание по-прежнему быстро растет

На рынке США рост потокового видео не наблюдается. Однако, если взглянуть на вещи глобально, потоковое вещание все еще имеет некоторое пространство для роста на международных рынках.

Что это значит для маркетологов?

Если вы пытаетесь вывести свой бизнес на международный рынок с помощью видеорекламы, обратите особое внимание на привычки просмотра телевизора на местном рынке. Когда речь заходит о потоковой передаче, мир еще не догнал США.

4. Потоковое видео начинают потреблять через смартфоны, но телевизоры не стоит списывать со счетов

Смартфоны и планшеты занимают большую часть общего интернет-трафика в США — 63%.

Учитывая это, а также тот факт, что большая часть нисходящего интернет-трафика состоит из видеоконтента, можно ожидать, что вскоре большая часть потокового видео также будет использоваться на мобильных устройствах. Пока что 70% телезрителей получают доступ к потоковым услугам в основном через подключенное телевидение.

Что это значит для маркетологов?

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

5. YouTube лидирует, но Netflix занимает второе место

В то время как Netflix в США имеет огромную платную абонентскую базу, YouTube лидирует по количеству пользователей.

Интересно, что в то время как люди используют Netflix для просмотра телевизионных шоу и фильмов, YouTube используется в качестве источника информационного контента.

В целом, половина пользователей YouTube используют платформу, чтобы узнать, как делать то, что они не делали раньше. Это означает, что половина пользователей вводит запрос «как» в поиск на платформе.

В России Youtube также в списке лидеров, но вот тройка выглядит несколько иначе.

Что это значит для маркетологов?

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

Вывод

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

Источник

Что такое потоковая передача мультимедиа?

Потоковая передача — это непрерывная передача аудио или видеофайлов с сервера клиенту. Проще говоря, потоковая передача — это то, что происходит, когда потребители смотрят телевизор или слушают подкасты на подключенных к интернету устройствах. При потоковой передаче медиафайл, воспроизводимый на клиентском устройстве, хранится удаленно и передается через интернет в течение нескольких секунд.

В чем разница между потоковой передачей и загрузкой?

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

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

Как работает потоковая передача мультимедиа?

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

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

Как протокол UDP улучшает потоковую передачу?

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

Большая часть интернета использует TCP или протокол управления передачей. Этот транспортный протокол предусматривает тщательное взаимное подтверждение для открытия соединения. Как только соединение открыто, и два коммутирующих устройства передают пакеты назад и вперед, TCP гарантирует, что передача надежна, что все пакеты поступают в порядке.

Для потоковой передачи скорость намного важнее надежности. Например, если кто-то смотрит эпизод телешоу онлайн, не каждый пиксель должен присутствовать на каждом кадре эпизода. Пользователь предпочел бы иметь смотреть эпизод на нормальной скорости, чем сидеть и ждать каждый бит данных, которые будут доставлены. Поэтому, несколько потерянных пакетов данных не является огромной проблемой, и именно поэтому потоковая передача использует UDP.

Если TCP похож на службу доставки пакетов, которая требует, чтобы получатель подписал его, то UDP похож на службу доставки, которая оставляет пакеты на переднем крыльце, не стуча в дверь, чтобы получить подпись. Служба доставки TCP теряет меньше пакетов, но служба доставки UDP работает быстрее, так как пакеты могут быть выгружены, даже если их никто не подписывает.

Потоковая передача и буферизация

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

Какие факторы замедляют стриминг?

На стороне пользователя:

Как сделать потоковую передачу быстрее?

Потоковая передача подвержена тем же задержкам и снижению производительности, что и другие виды веб-контента. Поскольку потоковое содержимое хранится в другом месте, расположение хостинга имеет большое значение, как и в случае с любым типом содержимого, доступного через интернет. Если пользователь в Нью-Йорке пытается выполнить потоковую передачу с сервера Netflix в Лос Гатос, видеоконтент должен будет пересечь 3000 миль, чтобы достичь пользователя, и видео придется потратить много времени на буферизацию или может даже не воспроизводиться вообще. По этой причине Netflix и другие поставщики потоковой передачи широко используют распределенные сети доставки контента (CDN), хранящие контент в местах по всему миру, которые намного ближе к пользователям.

CDN оказывают огромное положительное влияние на производительность потоковой передачи. Cloudflare Stream Delivery использует сеть CDN Cloudflare для хранения видеоконтента во всех точках присутствия Cloudflare по всему миру. В результате сокращается задержка для времени запуска видео и уменьшается буферизация.

Источник

Потоковое видео: что это такое?

Дата публикации: 2018-02-01

От автора: поскольку все больше и больше клиентов используют сети с высокой пропускной способностью, потоковое видео стало нормой в Интернете. Социальные медиа, веб-сайты и потоковые сервисы, такие как YouTube и Netflix, передаются прямо на ваш телефон. Исследование показало, что видео повышает взаимодействие с клиентами, поэтому мы должны ожидать, что количество видео в Интернете и на мобильных устройствах будет продолжать расти быстрыми темпами. Но что нужно для хорошего воспроизведения видео? И (возможно, что более важно), как вы можете реализовать хорошее воспроизведение видео, которое также очень высокоэффективно? В этой статье я сосредоточусь на нескольких способах оптимизации потоковой передачи HTTP Live Streaming (HLS) для улучшения доставки. Эти передовые методы также применяются к форматам MPEG-DASH и другим потоковым форматам и ни в коем случае не являются исчерпывающим списком, а просто представляют собой способы повышения производительности потоковой передачи видео.

Исследование: что делает хороший поток?

Ответ: зависит от разных факторов. Клиенты демонстрируют различное поведение для разных типов потоков. Это интуитивно имеет смысл — если вы сидите и смотрите телешоу или фильм (более 15 минут), вы будете более терпеливыми, чем, если это будет видео с котом, едущем на Roomba.

Я рассмотрю 3 основных показателя качества видео, которые необходимо учитывать.

Задержка запуска: время от нажатия воспроизведения до тех пор, как начнётся поток.

Столбцы. В буфере устройства видео не остается, и воспроизведение останавливается.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Качество видео: сколько пикселей на экране в любой момент времени.

Эти показатели сильно зависят от того, насколько быстро видео можно транспортировать по сети. В исследовательской работе Akamai обнаружено, что после 2 секунд задержки запуска клиенты начинают отказываться со скоростью 5,8% за дополнительную секунду. Они также считают, что более длинные (и более многочисленные) торможения приводят к отказу. Наконец, видео высокого качества более приятно смотреть, поэтому важно избегать пиксельного и низкого качества видео.

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

Скриншоты в этой статье взяты из AT & T Video Optimizer, бесплатного инструмента, который собирает сетевые захваты на вашем мобильном устройстве. Он оценивает сетевой трафик против

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

Как мы можем обеспечить быструю и регулярную доставку видео?

Первое, что вы могли заметить, — это столбец идентификатора, который немного не соответствует порядку. Существуют значения 1-7, но список начинается с 3. Каждый идентификатор отображает полосу пропускания, разрешение и аудио и видео кодеки, используемые для создания потока.

Запуск видео

Первым битрейтом, указанным в манифесте, является качество видео, которое первоначально запросит пользователь. Если этот список был последовательным, видеопоток начался бы с очень низкого качества 1 (128 × 320 @ 193 KBPS). С положительной стороны, 193 KBPS будет загружаться очень быстро в большинстве сетей.

Если бы порядок был отменен, начальное качество видео было бы чрезвычайно высоким (676 × 1024 3.6 MBPS). И хотя большое качество видео важно, это может привести к очень большой задержке запуска в сети с пропускной способностью менее 3,6 МБ.

Лучшая практика № 1: Чтобы сбалансировать начальное качество видео и задержку запуска, поместите поток средней полосы пропускания / качества в качестве первого выбора, чтобы сбалансировать быструю загрузку / запуск видео и начальное качество видео.

Проигрывание видео

После того, как плеер начнет загружать видео сегменты (2-8 сек фрагментов видео для воспроизведения), проигрыватель будет измерять скорость загрузки. Если он подсчитает, что сеть может обеспечить видео более высокого качества достаточно быстро, он попытается загрузить более качественную версию видео. И наоборот, если сеть работает медленнее, она снизится до более низкого качества видео, чтобы обеспечить постоянный поток. Каждый раз при изменении качества видео загружается манифест для нового потока, и видео может начать загрузку новой версии.

Video Optimizer может отслеживать количество сегментов в буфере локального устройства и отчитывается количество буферизованного видео в секундах и МБ во время сбора данных:

Если любое из этих чисел достигает 0, на устройстве больше нет видеозаписи, и видео будет остановлено.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Используя функцию «Затухание сети» в «Оптимизаторе видео», я изменил пропускную способность сети с 5 Мбайт до 1 Мбит / с в среднем потоке, и мы видим, что видеопроигрыватель начинает запрашивать более качественные видео сегменты, снижая с 1,5 МБПС и в конечном итоге устанавливая 500 КБ.

(Кроме того, можно подумать: если пропускная способность сети составляет 1 Мбайт, то почему 800 KBPS-видео плохо транслируется? Оказывается, есть два потока: один для видео и аудио — поток размером 128 Кбайт. Плеер определил, что 928 килобайт (+ накладные, + аналитика) были слишком приближены к 1024 KBPS и понизил видео. В этом случае можно было бы сделать аргумент за то, что более низкое качество звуковой дорожки, чтобы гарантировать, что более высокое разрешение видео воспроизводится. Кроме того, Лучшая практика: Качество звука (отдельный поток или встроенный в видеопоток) влияет на общую скорость передачи видео).

Очевидно, что несколько битрейтов помогут обеспечить хорошее видео. Примеры, показанные выше, имеют кодировки с изменениями битрейта, которые увеличиваются в довольно регулярные интервалы. Это означает, что небольшие изменения пропускной способности сети будут лишь незначительно влиять на качество видео на экране. Сравните это с рекомендуемым списком битрейтов, который я обнаружил в Интернете:

Представьте, что вы просматриваете видео, закодированное на мобильном устройстве с пропускной способностью 1,4 Мбайт. Единственный возможный вариант — ID 1, а это означает, что любой из пользователей 3G будет видеть только видео с самым низким качеством видео. Кроме того, разница в качестве видео между потоками 1 и 2, вероятно, значительна. Если видео перемещается между битрейтами 1 и 2 несколько раз, изменение качества видео, скорее всего, будет очевидным для конечного пользователя. Этот набор кодировок не очень подходит для потоковой передачи данных на мобильных устройствах.

Лучшая практика № 2: Доступны несколько битрейтов с регулярными интервалами между качествами. Это помогает обеспечить плавное прогрессирование качества видео и предотвратить значительные изменения качества видео.

Видеоплееры отличаются своей агрессивностью, чтобы улучшить качество видео. Некоторые видеопроигрыватели, почувствовав более высокую пропускную способность, начнут процесс замены сегмента — где видео сегменты, уже загруженные с более низким качеством, загружаются снова с более высоким качеством. Это приводит к тому, что один и тот же сегмент загружается более одного раза, но поскольку он улучшает отображаемое видео, я считаю его компромиссным, который обычно оценивается. Например, в таблице ниже сегменты 111-112 изначально загружаются с качеством 0. Плеер регистрирует всплеск пропускной способности и оценивает, что эти 2 сегмента можно заменить и повторно загружать по качеству 2. Однако плеер также довольно агрессивный, загружая 112 третий время в качестве 4. В целом для 4-секундного сегмента 112. потребляется

2 МБ данных. Это может считаться слишком агрессивным — поскольку он тратит большой объем данных.

Мы также видели примеры «замены обратного сегмента», когда плеер загружает более качественную версию после того, как уже имеет более качественную версию на устройстве. В этом случае сегменты 134-134 загружаются с качеством 4 (1,6 MBPS), а затем загружаются с качеством 1 (447 KBPS):

По крайней мере, если качество 4 воспроизводится конечному пользователю,

370 КБ будет потрачено впустую (сумма качественных 1 сегментов). Если воспроизводится качество 1,

1,3 МБ данных теряется, и пользователю предоставляется ухудшенное воспроизведение видео.

Лучшая практика № 3: если ваш видеопроигрыватель агрессивно продвигается к высокоскоростному видео, убедитесь, что замена сегмента только улучшает качество видео. Мониторинг использования данных замены сегмента для ваших пользователей (в Video Optimizer это сообщается как избыточность).

Для видео с несколькими высокими потоками битрейта агрессивный алгоритм битрейта может привести к увеличению количества остановок. Если локальный буфер составляет 30 МБ, но поток работает с 8 Мбайт / с, то локальная локация может быть только 2-3 секунды. Внезапное изменение пропускной способности, вероятно, приведет к остановке, прежде чем сеть и сервер смогут отреагировать.

Лучшая практика # 4: при потоковой передаче видео с высоким битрейтом убедитесь, что буфер устройства может поддерживать много секунд видео для учета внезапных изменений пропускной способности. Альтернатива: ограничить максимальные битрейты для устройств с ограниченной памятью.

Вывод:

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

Автор: Doug Sillars

Редакция: Команда webformyself.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Источник

Какой бывает 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-стриминг».

Источник