〇 Введение
-
1.4 RTMP push-поток
1.5 Взаимное резервное копирование в облаке
-
Введение и сценарий реализации протокола прямой трансляции
2.1 Декапсуляция протокола
2.2 HLS
2.3 HTTP-FLV
2.4 RTMP
2.5 MPEG-DASH
-
Практика строительства комнаты для прямых трансляций H5
3.1 Как выбрать оптимальный протокол
3.2 Играть на одном слое
1. Эволюция архитектуры облачных прямых трансляций
1.1 Обзор архитектуры облачной потоковой передачи в реальном времени
Якорь и клиент соответственно устанавливают долгосрочные соединения с интерактивным живым фоном облака в прямом эфире. Якорь толкает аудио и видео потоки к интерактивному живому фон через UDT Private Protocol, а интерактивный живой фоном получает аудио и видео. Поток и пересылает их и отправляет их непосредственно к клиенту, который установил соединение.
Такой способ отжима имеет ряд преимуществ:
1. Вам нужно только интегрировать SDK в клиент, и вы можете начать трансляцию через мобильный телефон.Требования к трансляции якоря относительно низкие, и он подходит для быстрого развертывания бизнеса прямых трансляций .
2. Интерактивный фон прямой трансляции выполняет только пересылку, никаких дополнительных операций, таких как транскодирование и загрузка в CDN, а общая задержка относительно невелика.
3. Средняя тема и пользователь могут использоваться в качестве инициатора аудио и видео, подходящих для сцен, таких как WAI, видеосессия.
1.3 Обводной проталкивающий поток
Я внедрил метод прямой трансляции push-pull через SDK мобильного телефона.Вроде бы сцена просмотра прямой трансляции в клиенте мобильного телефона решена.Тогда проблема грядет.Если я хочу смотреть прямую трансляцию трансляции в других сценариях типа Н5, апплета и т.п. нет Как получить доступ к SDK, что делать?
В настоящее время необходимо ввести новую концепцию – байпасный проталкивающий поток. Обход потоковой передачи означает подключение аудио- и видеопотоков к стандартной живой системе CDN посредством преобразования протокола. В настоящее время, после включения потоковой передачи в облаке, аудио- и видеопотоки будут передаваться в фоновую потоковую передачу в облаке через интерактивную фоновую потоковую передачу в реальном времени.Фоновая потоковая передача в облаке отвечает за транскодирование полученных аудио- и видеопотоков в общий протокол. формат и проталкивание их в CDN.Программа и другие терминалы могут вытягивать аудио- и видеопотоки в общем формате через CDN для воспроизведения.
В настоящее время существует три типа обхода Moujie Live Bypass: HLS, FLV и RTMP, которые могут охватывать все сценарии воспроизведения.Эти протоколы будут подробно представлены во втором разделе.
1.4 RTMP push-поток
С развитием бизнеса прямых трансляций некоторые ведущие постепенно разочаровываются в эффекте трансляции по мобильному телефону, а прямая трансляция электронной коммерции должна отображать продукты на экране с высокой точностью и должна транслироваться в прямом эфире через более высокое разрешение. Появилась технология потоковой передачи RTMP. мы используемOBSНапример, программы записи потокового мультимедиа объединяют несколько потоков, записанных профессиональным оборудованием, и загружают аудио- и видеопотоки на указанный адрес потоковой передачи.Поскольку потоковая передача OBS использует протокол RTMP, мы называем этот тип потоковой передачи RTMP push-потоком.
Сначала мы применим к Add Add Chusp Stream и Secret Key в предпосылке Cloud Live Breadcast, настройте адрес Push Stream и Secret Key в программное обеспечение OBS и отрегулируйте параметры Push Stream. Push Url нажимает аудио и видео и видео. Разница между этим методом потоковой передачи и потоковой передачей SDK состоит в том, что аудио- и видеопотоки непосредственно подталкиваются на фоне потокового потока облака для транскодирования и загрузки в CDN, и нет никакого метода ниже по потоку непосредственно подтолкнуть к клиенту. задержка будет дольше.
Подводя итог, можно сказать, что преимущества и недостатки потоковой передачи RTMP более очевидны.
Преимущества:
Недостатки:
Drive 2.rtmp нуждается в транскодировании и загрузка локальной конфигурации также в OBSGOPи буферизация, задержка относительно велика.
1.5 Взаимное резервное копирование в облаке
После того, как бизнес разовьется до определенного этапа, у нас также будут более высокие требования к стабильности бизнеса, например, когда есть проблема с сервисом поставщика облачных услуг, если у нас нет решения для резервного копирования, бизнес будет ждать, пока поставщик услуг восстановит прогресс. Поэтому появилось решение для взаимного резервного копирования в облаке.Взаимное резервное копирование в облаке относится к одновременному подключению служб прямой трансляции с несколькими поставщиками облачных услуг.Когда поставщик облачных услуг сталкивается с проблемой, он может быстро переключиться на сервисные узлы других поставщиков услуг, чтобы обеспечить что бизнес не пострадал.
В бизнесе прямых трансляций часто встречается низкая скорость нисходящего канала узла CDN поставщика услуг или проблемы с потоком в реальном времени, хранящимся на узле CDN.Такие проблемы носят региональный характер и их трудно устранить.Поэтому Текущие облачные решения взаимного резервного копирования в основном: Резервные узлы CDN. В настоящее время общий процесс push-потока Mogujie уже опирается на услуги исходной облачной платформы, поэтому мы полностью ретвитим на резервную облачную платформу в фоновом режиме облачной прямой трансляции.После получения прямой трансляции резервное облако будет перекодировать поток и загрузить его в систему CDN самого резервного облака, если возникает проблема с узлом CDN основной платформы, мы можем заменить потоковый адрес, выданный резервным облаком, на потоковый адрес резервного облака , чтобы дело можно было быстро починить и аудитория его не восприняла.
Во-вторых, введение протокола прямой трансляции и напольной сцены.
2.1 Декапсуляция протокола
Прежде чем представить протокол потоковой передачи, давайте сначала представим, что мы получаем часть данных из облака, и требуется несколько шагов для анализа требуемых окончательных аудио- и видеоданных.
В общем, есть четыре шага от получения данных до окончательного воспроизведения аудио и видео.
Первым шагом является распаковка протокола. Когда протокол инкапсулирован, он обычно содержит некоторую информацию описания заголовка или сигнальные данные. Эта часть данных не влияет на воспроизведение аудио и видео, поэтому нам нужно извлечь конкретное аудио. и данные формата инкапсуляции видео из него.Протоколы, которые мы обычно используем в прямых трансляциях, это HTTP и RTMP.
После получения данных инкапсулированного формата необходимо выполнить операцию декапсуляции и извлечь данные сжатого аудиопотока и данные сжатого видеопотока соответственно.Инкапсулированные данные формата, которые мы часто видим, такие как MP4 и AVI, в прямом эфире, мы подвергается большей инкапсуляции. Форматы: TS, FLV.
Здесь мы получили сжатые данные кодирования аудио и видео. Данные кодирования видео со сжатием, которые мы часто слышим каждый день, включают серию H.26X и серию MPEG и т. д., а форматы кодирования аудио включают MP3, ACC и т. д., с которыми мы знакомы. Причина, по которой мы видим так много форматов кодирования, заключается в том, что различные организации предложили свои собственные стандарты кодирования и будут запускать несколько новых предложений одно за другим, но из-за проблем с продвижением и оплатой в настоящее время не так много основных форматов кодирования. После получения сжатых данных необходимо декодировать сжатые аудио- и видеоданные, чтобы получить несжатые данные о цвете и несжатые данные выборки звука. Данные о цвете имеют знакомый нам RGB, но формат данных о цвете, обычно используемый в видео, — YUV, который относится к определению значения цвета пикселя по яркости, оттенку и насыщенности. PCM обычно используется для данных звуковых семплов.
Наконец, нам нужно сравнить временные шкалы аудио и видео и отправить декодированные аудио и видео данные на графическую карту и звуковую карту для синхронного воспроизведения.
2.2 HLS
Во-первых, давайте представим протокол HLS. HLS — это аббревиатура от HTTP Live Streaming.Это протокол сетевой передачи потокового мультимедиа, предложенный Apple.Из названия очевидно, что этот набор протоколов передается на основе протокола HTTP. Когда дело доходит до протокола HLS, нам сначала нужно понять, что этот протокол воспроизводится сегментами в виде видеофрагментов.Формат видеофрагмента, используемый в протоколе, — это TS, который является форматом инкапсуляции, о котором мы упоминали ранее. Перед тем, как мы получим файл TS, протокол сначала требует запросить файл в формате M3U8.M3U8 — это индексный файл описания, который описывает точку адреса TS в определенном формате.Мы можем получить каждый сегмент в соответствии с содержимым, описанным в файле Файл M3U8. Адрес CDN файла TS. Путем загрузки адреса TS и воспроизведения сегментами можно объединить полное видео.
Использование протокола HLS для воспроизведения видео сначала запросит файл M3U8.Если это по запросу, вам нужно получить его только один раз во время инициализации, чтобы получить все точки среза TS, но если это прямая трансляция, вам нужно постоянно опрашивать файл M3U8 для получения новых фрагментов TS. Получив M3U8, мы можем ознакомиться с содержимым.Во-первых, некоторая общая информация описания, такая как серийный номер первого сегмента, максимальная продолжительность и общая продолжительность сегмента и т. д., а затем список адресов, соответствующий конкретного TS, если это прямая трансляция, то каждый раз, когда вы запрашиваете список TS в файле M3U8, он будет обновляться последним фрагментом прямой трансляции, чтобы добиться эффекта прямой трансляции.
HLS, формат воспроизведения фрагментов, больше подходит для воспроизведения по запросу, и некоторые крупные видеосайты также используют этот протокол в качестве решения для воспроизведения. Во-первых, функция воспроизведения фрагментов особенно удобна для горячего переключения четкости видео и многоязычности при воспроизведении по запросу. Например, когда мы воспроизводим видео, мы изначально выбираем воспроизведение видео со стандартным разрешением. Когда мы просматриваем половину видео и чувствуем, что оно недостаточно четкое, нам нужно изменить его на ультра-разрешение. В это время мы нужно только заменить файл M3U8 стандартной четкости на файл M3U8 сверхвысокой четкости.Когда мы играем, когда будет достигнут следующий узел TS, видео будет автоматически заменено сверхчетким файлом TS, и нет необходимости повторно -инициализировать видео. Во-вторых, форма воспроизведения фрагментов также позволяет легко вставлять в видео рекламу и другой контент.
В сцене прямых трансляций HLS также является широко используемым протоколом. Его самым большим преимуществом является благословение боссов Apple. Это хорошая реклама для этого набора протоколов, особенно для мобильных терминалов. Передача адреса файла M3U8 в видео может прямое воспроизведение, для ПКMSEБольшинство браузеров также могут поддерживать его после декодирования. Однако из-за особенности фрагментарной загрузки задержка прямого эфира относительно велика, например, у нас 5 TS-файлов в одном M3U8, и время воспроизведения каждого TS-файла составляет 2 секунды, тогда время воспроизведения одного M3U8 файл составляет 10 секунд, то есть ход прямой трансляции этого воспроизведения M3U8 произошел не менее 10 секунд назад, что является большим недостатком для сценариев прямой трансляции.
Формат инкапсуляции HLS TS, используемый в формате кодирования видео, обычно является H.264 или MPEG-4, или формат аудиокодирования AAC MP3. Множество композиции Packtet фиксированной длины, обычно 188 байт, и каждая головка имеет полезную нагрузку композиции PackTet, голова содержит некоторые идентификаторы, сообщения об ошибках и другое информационный пакет на основе местоположения, полезная нагрузка может быть просто понята как аудио и видео, но на самом деле Также есть два нижних пакета после того, как пакет может получить декодированные аудио и видеоданные в кодированный поток.
2.3 HTTP-FLV
Протокол HTTP-FLV, как это может быть четко видно из имени, представляет собой протокол, который передает формат инкапсуляции FLV через протокол HTTP. FLV - это аббревиатура Flash Video, которое является методом пакета с небольшим размером файла и подходит для передачи в сети. Формат кодирования видео FLV обычно является H.264, и кодировка звука - это Acc или MP3.
In live, we can pull by pulling HTTP-FLV stream protocol address to the data section chunked, to open the file can be read in hexadecimal file stream, packet structure, and FLV by contrast, can be found in the data that we FLV required данные.首先开头是头部信息，464C56转换ASCII码后是FLV三个字符，01指的是版本号，05转换为2进制后第6位和第8位分别代表是否存在音频和视频，09代表头部长度占了几个字节。后续就是正式的音视频数据，是通过一个个的FLV TAG进行封装，每一个TAG也有头部信息，标注这个TAG是音频信息、视频信息还是脚本信息。我们通过解析TAG就可以分别提取音视频的压缩编码信息。
MSEMSEэтот API. Поскольку передача HTTP-FLV осуществляется в форме передачи файлового потока через длинное соединение, браузер должен поддерживать Stream IO или выборку, а требования совместимости для браузера будут относительно высокими.
FLV намного лучше, чем HLS, для воспроизведения фрагментов с точки зрения задержки.В настоящее время кажется, что задержка FLV в основном зависит от длины GOP, установленной во время кодирования. Вот краткое введение в GOP В процессе кодирования видео H.264 генерируются три типа кадров: I-кадр, B-кадр и P-кадр. I-кадр — это то, что мы обычно называем ключевым кадром.Ключевой кадр включает в себя полную внутрикадровую информацию и может непосредственно использоваться в качестве эталонного кадра для других кадров. Чтобы уменьшить размер данных, B-кадры и P-кадры должны извлекать информацию в кадрах из других кадров, поэтому продолжительность между двумя I-кадрами также можно рассматривать как минимальную продолжительность сегмента воспроизведения видео. Учитывая стабильность видео-пуша, мы также требуем, чтобы хост установил фиксированную длину интервала ключевых кадров, обычно 1-3 секунды, поэтому, помимо других факторов, наша прямая трансляция также будет иметь задержку 1-3 секунды во время воспроизведение.
2.4 RTMP
Фактически протокол RTMP можно отнести к тому же типу, что и протокол HTTP-FLV. Все их форматы пакетов — FlV, но протокол передачи, используемый HTTP-FLV, — это HTTP, а поток RTMP pull использует RTMP в качестве протокола передачи. RTMP — это набор протоколов передачи сообщений в реальном времени, созданный ADOBE на основе TCP, который часто используется в сочетании с проигрывателями Flash.
Преимущества и недостатки протокола RTMP очевидны: во-первых, как и у HTTP-FLV, задержка относительно небольшая, во-вторых, его стабильность очень хорошая и подходит для длительного воспроизведения, поскольку он заимствует мощные функции Flash-плеера во время воспроизведение, даже если одновременно открыто несколько потоков. Воспроизведение также может гарантировать, что страница не зависнет, что очень удобно для мониторинга и других сценариев.
Тем не менее, Flash player в настоящее время находится в ситуации, когда веб-сторона оттеснена стеной, а основные браузеры постепенно говорят, что они больше не поддерживают плагин Flash player.Использование его на MAC может немедленно превратить компьютер в железная плита для шашлыка, которая потребляет много ресурсов. На мобильном терминале H5 практически полностью не поддерживается, и его самая большая проблема — совместимость.
2.5 MPEG-DASH
Протокол MPEG-DASH относится к новым технологиям и, как и HLS, воспроизводится путем нарезки видео. Предыстория его поколения заключается в том, что в первые дни крупные компании разрабатывали свои собственные наборы протоколов, такие как HLS от Apple, MSS от Microsoft, HDS от Adobe, поэтому пользователям приходится страдать от проблем совместимости нескольких наборов пакетов протоколов. Итак, большие ребята собрались вместе, интегрировали предыдущие решения протоколов потокового мультимедиа от разных компаний и создали новый протокол.
Поскольку это тот же протокол для воспроизведения нарезанных видео, DASH имеет те же преимущества и недостатки, что и HLS. Он может поддерживать переключение нескольких скоростей передачи видео и нескольких звуковых дорожек между фрагментами. Он больше подходит для воспроизведения по запросу. сервисы, но в прямом эфире еще большая задержка. .
3. Практика строительства комнаты прямого вещания H5
3.1 Как выбрать оптимальный протокол
Протокол прямой трансляции — это очень важные два момента, и уже упоминалось, низкая задержка и лучшая совместимость.
Во-первых, с точки зрения задержки, без учета потребления и транскодирования диска вниз по линии, а MPEG-DASH HLS по сокращенной длине временного интервала, задержка 10 секунд, значительная задержка в теории RTMP и FLV, в 2 3 секунды, поэтому HLS≈DASH> RTMP≈FLV с точки зрения задержки.
С точки зрения совместимости HLS> FLV> RTMP, Dash Project из-за некоторых исторических причин, и повторяется позиционирование и HLS, временно не проводил тщательный тест на его совместимость, он был выдвинут выбран.
hls.jsа такжеflv.jsВыполняя декодирование игры, оба через внутренние библиотекиMSEЧтобы выполнить декодирование, сначала извлеките соответствующие данные аудио- и видеофрагментов в соответствии с форматом инкапсуляции видео, создайте SourceBuffer для аудио и видео в MediaSource и передайте закодированные аудио- и видеоданные в SourceBuffer. оставшееся декодирование и выравнивание аудио и видео работают, и, наконец, MediaSource заменяет src в теге Video на объект MediaSource для воспроизведения.
При оценке среды воспроизведения мы можем ссылаться наflv.jsМетод внутреннего суждения, позвонивMSEМетод суждения и способ имитации суждения по запросуMSEи доступен ли StreamIO.
window.MediaSource && window.MediaSource.isTypeSupported('video/mp4; codecs="avc1.42E01E,mp4a.40.2"'); // 判断MediaSource是否被浏览器支持，H.264视频编码和Acc音频编码是否能够被支持解码
Если в случае не поддерживается FLV Player, вам необходимо понизить в HLS, на этот раз на этот раз среда браузера должна определить, обычно не требуется мобильный терминал, мобильный терминалhls.jsпройти черезMSEЧтобы воспроизвести с помощью декодирования, прямо передайте адрес M3U8 в src видео; если это сторона ПК, оценитеMSEЕсть ли в наличии, используйте, если естьhls.jsДекодировать воспроизведение.
Эти интерпретации могут быть оценены заранее по их собственной логике, чтобы вытащить CDN соответствующей библиотеки декодирования, вместо того, чтобы ждать загрузки сторонней библиотеки и использовать внутренний метод сторонней библиотеки для оценки, так что, когда выбирая библиотеку декодирования, можно выбрать все библиотеки.Все снесены для повышения скорости загрузки.
3.2 Играть на одном слое
Поставщики электроэнергии нуждаются в живой и интерактивной части работы зрителя, чем традиционные живые, все больше и больше, поэтому, когда дизайн продукта многих функциональных модулей уменьшит пространство, занимаемое подвеской над живым видео. На этот раз придется столкнуться с хронической проблемой мобильного терминала игрока — играть одним и тем же слоем. Проблемы с воспроизведением со слоем относятся к странице мобильного терминала H5, ядру некоторых браузеров, чтобы улучшить взаимодействие с пользователем, метка видео будет заменена собственным угнанным проигрывателем, что приведет к тому, что другие элементы не могут быть закрыты поверх проигрывателя. Например, мы хотим увеличить окно чата над игроком в студии, окно чата с помощью абсолютного позиционирования, чтобы улучшить z-индекс, размещенный над игроком, в тесте на ПК это совершенно нормально. Но, в конце концов, некоторые из мобильных браузеров, видеоплееров были заменены родными, родными элементами более высокого уровня, чем наши общие элементы, в результате чего окно чата при фактическом отображении в проигрывателе ниже.
Чтобы решить эту проблему, мы должны сначала разделить ее на несколько сценариев. Прежде всего, в системе iOS тег видео будет автоматически воспроизводиться в полноэкранном режиме при нормальных обстоятельствах, но iOS 10 и выше уже предоставляют такое же свойство слоя видео.Мы можем добавить playsinline/webkit-playsinline к тегу видео, чтобы решить проблему. большинство браузеров в системе iOS.Та же проблема слоя,остальные браузеры с младшими версиями системы и некоторыми контейнерами веб-просмотра в приложении (например, Weibo), упомянутые выше свойства не работают, и вызывается сторонняя библиотека.iphone-inline-videoБольшинство оставшихся проблем можно решить.
На стороне Android большинство встроенных контейнеров веб-просмотра приложений на базе Tencent используют ядро X5.Ядро X5 заменит видео собственным настраиваемым проигрывателем для улучшения некоторых функций. X5 также предоставляет набор решений на том же уровне (Спецификация доступа к проигрывателю того же уровня H5), а запись атрибута того же уровня X5 в тег видео также может реализовать встроенное воспроизведение в ядре X5. Однако свойства одного и того же уровня X5 не одинаковы в каждой версии X5 (например, режим полноэкранного воспроизведения X5 необходимо использовать в более низкой версии X5, чтобы гарантировать, что видео, воспроизводимое MSE, воздействует на тот же слой), вам нужно обратить внимание, чтобы различать версии.