предисловие
Это резюме было написано в прошлом году, когда была моя очередь участвовать в еженедельном собрании компании по обмену технологиями. В то время компания с размахом готовилась к бизнесу прямых трансляций, я думал, что супервайзеру доверят важную задачу, поэтому перерыл кучу форумов и сделал простой технический шеринг. Позже бизнес прямого эфира взял на себя другой коллега, и я лишился возможности заниматься прямым эфиром, а жаль. Что ж, без лишних слов, давайте начнем нашу теоретическую главу~
техническое образование
2016 год — это первый год прямого вещания.Во-первых, из-за расширения и снижения цен основных поставщиков широкополосного доступа в ответ на общественное мнение, а во-вторых, в сектор прямого вещания влился большой капитал, что способствовало обновлению и повторение технологии. На рынке чаще всего используется протокол прямых трансляций HLS, запущенный Apple (изначально поддерживающий воспроизведение H5), конечно, есть RTMP, HTTP-FLV, RTP и т.д.
Форматы видеофайлов и протоколы прямой трансляции
Формат видеофайла
Формат видеофайла На самом деле мы часто называем его контейнерным форматом, то есть форматом, о котором чаще всего говорят в нашей общей жизни, форматом flv, mp4, ogg и т.д. Это можно понимать как размещение потока битов в определенном блоке в определенном порядке. Так в чем проблема выбрать другой формат для установки видео?
Ответ — нет проблем, но нужно уметь распаковывать коробку и уметь найти соответствующий декодер для ее расшифровки. Если посмотреть на это так, для таких форматов видео, как mp4, ogv, webm и т. д., пока у меня есть соответствующие декодеры и плееры, то проблем нет. Затем поместите битовый поток видео в бокс, если есть проблема с одним из сегментов, то конечный сгенерированный файл фактически непригоден для использования, потому что сам бокс неисправен.
Однако выше есть недоразумение, что я понимаю видео только как статический поток. Представьте, если видео нужно воспроизводить непрерывно, например, прямую трансляцию, прямую трансляцию и т. д. Здесь мы берем поток TS/PS для объяснения.
-
PS (программный поток): поток статических файлов
-
TS (транспортный поток): динамический файловый поток
Для двух вышеупомянутых форматов контейнеров битовый поток видео фактически обрабатывается по-разному.
- PS: Поместите готовый битовый поток видео в коробку и сгенерируйте фиксированный файл.
- ТС: Разложите полученные видео по разным коробкам. Конечным результатом является файл с несколькими ящиками.
В результате, если одна или несколько коробок повреждены, формат PS невозможно смотреть, а TS просто имеет эффекты пропуска кадров или мозаики. Конкретная разница между ними заключается в следующем: чем выше уровень отказоустойчивости видео, будет выбран TS, и чем ниже уровень отказоустойчивости видео, будет выбран PS.
Протокол прямой трансляции HLS
HTTP Live Streaming (сокращенно HLS) — это протокол потоковой передачи видео на основе HTTP. Это протокол прямой трансляции, предложенный Apple. В настоящее время как IOS, так и более поздние версии Android поддерживают HLS. Так что же такое ЗОЖ? Двумя основными частями HLS являются файлы .m3u8 и файлы воспроизведения .ts.
Протокол HLS основан на HTTP, и сервер, предоставляющий HLS, должен делать две вещи:
Кодирование: закодируйте изображение в формате H.263, закодируйте звук в MP3 или HE-AAC и, наконец, упакуйте его в контейнер MPEG-2 TS (Transport Stream);
Сегментация: разделите закодированный файл TS на небольшие файлы с суффиксом ts одинаковой длины и сгенерируйте индексный файл с открытым текстом .m3u8;
Браузер использует файлы m3u8. m3u8 очень похож на формат аудио списка m3u, можно просто считать, что m3u8 — это список воспроизведения, содержащий несколько файлов ts. Плеер воспроизводит один за другим по порядку, а затем запрашивает файл m3u8 после того, как все они будут воспроизведены, и получает список воспроизведения, содержащий последний файл ts для продолжения воспроизведения, и цикл начинается снова и снова. Весь процесс прямой трансляции состоит из постоянно обновляемого m3u8 и кучи мелких ts файлов, m3u8 должен обновляться динамически, а ts может идти в CDN.
Здесь мы сосредоточимся на процессе на стороне клиента. Прежде всего, причина, по которой прямая трансляция является прямой трансляцией, заключается в том, что ее содержание обновляется в режиме реального времени. Как осуществляется ЗОЖ?
Мы можем использовать HLS, чтобы включить его непосредственно в видео:
<video autoplay controls>
<source src="xxx.m3u8" type="application/vnd.apple.mpegurl" />
<p class="warning">Your browser doesn't support video</p>
</video>
Согласно приведенному выше описанию, на самом деле это запрос индексного файла .m3u8. Этот файл содержит описания файлов .ts, например:
После заполнения URL-адреса основного списка воспроизведения пользователь загрузит основной список воспроизведения только один раз. Затем проигрыватель решает, какой список воспроизведения мультимедиа (то есть дочерний файл m3u8) использовать в зависимости от текущей среды. Если во время воспроизведения условия воспроизведения пользователя изменятся, проигрыватель также переключит соответствующий список воспроизведения мультимедиа.
Разумеется, функции, поддерживаемые HLS, — это не просто фрагментированное воспроизведение (особенно подходящее для прямых трансляций), в него входят и другие должные функции.
-
Шифровать файлы ts с помощью HTTPS
-
быстрый/обратный
-
рекламная вставка
-
Переключение видео между разными разрешениями
Видно, что протокол HLS по сути представляет собой HTTP-запрос/ответ, поэтому он легко адаптируется и не подвержен влиянию брандмауэров. Но у него есть и ахиллесова пята: феномен отставания очень заметен. Если каждый ts разделить на 5 секунд, а один m3u8 поставить 6 индексов ts, то это принесет как минимум 30 секунд задержки. Если уменьшить длину каждого ts и уменьшить количество индексов в m3u8, задержка действительно уменьшится, но это приведет к более частой буферизации, а также экспоненциально возрастет нагрузка запросов на сервер. Поэтому мы можем найти компромиссную точку только в соответствии с реальной ситуацией.
Примечание. HLS поддерживает только браузеры Safari на стороне ПК. Как и в браузерах Chrome, тег видео HTML5 не может воспроизводить формат m3u8. Некоторые зрелые решения в Интернете можно использовать напрямую, например: шить-плеер, MediaElement, videojs-contrib -hls, jwplayer.
Протокол прямых трансляций RTMP
Протокол обмена сообщениями в реальном времени (сокращенно RTMP) — это набор протоколов видеотрансляции в реальном времени, разработанный Macromedia и теперь принадлежащий Adobe. Как и HLS, его можно применять к видео в реальном времени, разница в том, что RTMP на основе flash нельзя воспроизводить в браузерах iOS, но производительность в реальном времени лучше, чем у HLS. Поэтому этот протокол обычно используется для загрузки видеопотоков, то есть видеопотоки передаются на сервер.
Вот сравнение HLS и RTMP:
Протокол прямой трансляции HTTP-FLV
Подобно RTMP, HTTP-FLV предназначен для прямых потоков распространения в видеоформате FLV. Однако между ними есть большая разница.
- Непосредственно инициируйте длительное соединение и загрузите соответствующий файл FLV.
- Простая информация заголовка
Теперь на рынке HTTP-FLV чаще используется для воспроизведения. Однако, поскольку он не поддерживается на мобильных телефонах, HTTP-FLV H5 также является проблемой. Однако теперь flv.js может помочь высокоуровневым браузерам парсить через mediaSource. Использование HTTP-FLV также просто. Как и в случае с HLS, просто добавьте соединение:
<object type="application/x-shockwave-flash" src="xxx.flv"></object>
Базовая структура прямой трансляции
В настоящее время более зрелые продукты для прямой трансляции обычно используют серверную часть с H5 и Native (android, ios) для прямой трансляции, которая в основном представляет собой следующую процедуру:
-
Терминал видеозаписи: обычно устройство ввода аудио и видео на компьютере или камера или микрофон на мобильном терминале, в настоящее время в основном используется видео мобильного терминала.
-
Видеоплеер: это может быть плеер на компьютере, собственный плеер на мобильном телефоне, видеотег H5 и т. д. В настоящее время в основном используется собственный плеер на мобильном телефоне.
-
Сторона видеосервера: обычно это сервер nginx, который используется для приема источника видео, предоставленного стороной видеозаписи, и предоставления потоковых услуг стороне воспроизведения видео.
-
Заграждение в реальном времени, вы можете использовать webscoket для отправки и получения новых заграждений в реальном времени и их рендеринга.
-
Для браузеров, которые не поддерживают webscoket, их можно понизить только до длинных опросов или интерфейсных таймеров для отправки запросов для получения заграждения в реальном времени.
-
Анимация и обнаружение столкновений при рендеринге экрана пули (то есть экран пули не перекрывается) и т. д.
Решение для прямых трансляций H5
Используйте flv.js для прямых трансляций
- Введение
flv.js — проект с открытым исходным кодом от Bilibli. Он анализирует FLV-файлы и передает их собственным тегам HTML5 Video для воспроизведения аудио- и видеоданных, что позволяет браузерам воспроизводить FLV без Flash.
- Преимущество
Поскольку браузер использует аппаратное ускорение для собственного тега видео, производительность очень хорошая, и он поддерживает высокое разрешение. Поддерживается как запись, так и прямая трансляция. Удалите зависимость от Flash.
- зависит от браузера
Список совместимости функций браузера, от которых зависит flv.js
1. HTML5-видео
2. Расширения источников мультимедиа
3. Веб-сокет
4. HTTP FLV: выборка или потоковая передача
- принцип
flv.js делает только одну вещь: после получения аудио- и видеоданных в формате FLV он декодирует данные FLV с помощью собственного JS, а затем передает их собственному тегу HTML5 Video через API расширений источника мультимедиа. (HTML5 изначально поддерживает только формат mp4/webm, но не FLV)
Почему flv.js ходит по кругу, получает FLV с сервера, декодирует и конвертирует его, а потом скармливает тегу Video? Причины следующие:
1. Совместимость с текущими решениями для прямых трансляций. В настоящее время большинство аудио- и видеосервисов решений для прямых трансляций используют контейнерный формат FLV для передачи аудио- и видеоданных.
2. Формат контейнера FLV проще, чем формат MP4, и его быстрее и удобнее анализировать.
- Совместимое решение
Сторона ПК
1. Сначала используйте HTTP-FLV, потому что он имеет низкую задержку и хорошую производительность.1080P очень плавный.
2. Если flv.js не поддерживается, используйте Flash player для воспроизведения RTMP-потока. Совместимость с Flash хорошая, но низкая производительность отключена по умолчанию во многих браузерах.
3. Вы также можете использовать HLS, если не хотите использовать совместимость с Flash, но только Safari поддерживает HLS на стороне ПК.
мобильный
1. Сначала используйте HTTP-FLV, потому что у него низкая задержка, а производительности устройств, поддерживающих HTTP-FLV, достаточно для запуска flv.js.
2. HLS используется, если flv.js не поддерживается, но задержка HLS очень большая.
3. Если HLS не поддерживается, он не сможет вести прямую трансляцию, так как мобильный терминал не поддерживает Flash.
Ну все-таки это вводная глава теории.Если в будущем будет какая-то бизнес-практика, я ее обновлю.Чувствую, что дочитал до этого места.