Эту статью опубликовал Сан-Би, фронтенд-разработчик Mogujie. Первоначальное название было «Исследование облачной трансляции Mogujie в прямом эфире — начальная глава», которое было изменено.

1. Введение

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

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

2. Обзор архитектуры потокового вещания Mogujie

В настоящее время основной процесс двухтактной потоковой передачи в прямом эфире Mogujie опирается на службу определенной облачной прямой трансляции.

Cloud Live предоставляет два метода потоковой передачи:

• 1）Один из них — через интеграциюSDKПотоковая передача через（Для трансляции на мобильный телефон）；
• 2）Другой прошелRTMPПротокол передает поток на удаленный сервер.（используется дляPCВещание на конце вещания или профессиональное консольное оборудование）。

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

3. Двухтактная архитектура потока 1: двухтактный поток SDK производителя.

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

Логический принцип этой архитектуры двухтактного потока заключается в следующем:

• 1）Анкерная сторонаи Клиент устанавливает длительное соединение с фоном интерактивной прямой трансляции Cloud Live соответственно.；
• 2）Анкерная сторона通过UDTЧастный протокол передает аудио- и видеопотоки на фон интерактивной прямой трансляции.；
• 3）Фон интерактивной прямой трансляции принимает аудио- и видеопотоки и пересылает их.,Непосредственно доставляется клиенту, с которым установлено соединение.

Этот метод двухтактного потока имеет ряд преимуществ:

• 1）Просто нужно интегрировать в клиентSDK：Начать трансляцию через мобильный телефон,Требования к ведущим для начала вещания относительно низкие,Подходит для быстрого развертывания сервисов потокового вещания;
• 2）Интерактивный фон прямой трансляции только вперед：Нет транскодирования,Загрузка в CDN и другие дополнительные операции,Общая задержка относительно невелика;
• 3）Анкерная сторонаи Клиент может выступать инициатором загрузки аудио и видео.：Подходит для непрерывной пшеницы.、Сценарии, такие как видеоразговоры.

4. Двухтактная потоковая архитектура 2: обход принудительной потоковой передачи

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

Итак, возникает вопрос:если я хочу быть внутриH5、Смотрите прямые эфиры в мини программах и других сценариях,Нет возможности получить доступ к SDK,Что нужно сделать?

В настоящее время необходимо внедрить новую концепцию – обходной напорный поток.

Обход потоковой передачи относится к:Подключайте аудио- и видеопотоки к стандартным прямым трансляциям посредством преобразования протоколов. CDN в системе.

В настоящее время после включения обхода в Cloud Live аудио- и видеопотоки будут передаваться на серверную часть Cloud Live через серверную часть интерактивной прямой трансляции. Серверная часть Cloud Live отвечает за перекодирование полученных аудио- и видеопотоков в общий. Формат протокола и передача их в CDN. Таким образом, H5, small. Программа и другие терминалы могут передавать аудио- и видеопотоки в общем формате через CDN для воспроизведения.

В настоящее время типы протоколов, поддерживаемые обходом прямой трансляции Mogujie, включают HLS, FLV и RTMP, которые могут охватывать все сценарии воспроизведения. Эти протоколы будут подробно представлены в последующих главах.

5. Двухтактная потоковая архитектура 3: push-потоковая передача RTMP

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

Мы используем программы записи потокового мультимедиа, такие как OBS, для объединения нескольких потоков, записанных профессиональным оборудованием, и загрузки аудио- и видеопотоков на назначенный адрес push-уведомлений. Поскольку потоковая передача OBS использует протокол RTMP, мы называем этот тип потоковой передачи RTMP.

Сначала мы подаем заявку на push-адрес и секретный ключ в фоновом режиме прямой трансляции в облаке, настраиваем push-адрес и секретный ключ в программном обеспечении OBS, настраиваем параметры push и нажимаем кнопку push, OBS отправит push-адрес на соответствующий push-адрес через протокол RTMP. Адрес потока передает аудио- и видеопотоки.

Разница между этим методом push и методом push SDK заключается в том, что аудио- и видеопотоки напрямую передаются в фоновую облачную прямую трансляцию для перекодирования и загрузки в CDN. Не существует нисходящего метода прямой пересылки живого потока на конец пользователя. Поэтому по сравнению с SDK задержка push будет больше.

Таким образом, преимущества и недостатки потоковой передачи RTMP очевидны.

Основные преимущества:

• 1）Может быть подключен к профессиональным камерам прямого вещания.、микрофон,Общий эффект от прямой трансляции явно лучше, чем от мобильной трансляции;
• 2）OBSУже существует много зрелых плагинов,Например, ведущие могуджиэ в настоящее время используют помощника YY для выполнения некоторых косметических процедур.,А сама OBS уже поддерживает фильтры, зеленые экраны, многоканальный синтез видео и другие функции.,Функция более мощная, чем в мобильной версии.

Основные недостатки:

• 1）OBSСама конфигурация относительно сложна.,Требуется профессиональная поддержка оборудования,Требования к анкерам явно выше,Обычно для прямой трансляции требуется фиксированное место;
• 2）RTMPТребуется облачное перекодирование,А при локальной загрузке в OBS также будет настроена буферизация GOPи.,Задержка относительно долгая.

6. Архитектурное решение высокой доступности: взаимное резервное копирование в облаке.

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

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

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

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

7. Принцип декапсуляции потока видеоданных в реальном времени.

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

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

первый шаг:соглашение о решении。

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

Шаг второй:Декапсуляция。

После получения данных инкапсулированного формата вам необходимо выполнить операцию декапсуляции для извлечения данных сжатого потока аудио и данных сжатого видео соответственно. Обычно мы видим данные инкапсулированного формата, такие как MP4 и AVI. В прямых трансляциях мы сталкиваемся с более инкапсулированными данными. форматы: TS, FLV.

Шаг третий:Декодирование аудио и видео。

На данный момент мы получили сжатые данные кодирования аудио и видео.

Данные кодирования сжатия видео, которые мы часто слышим в нашей повседневной жизни, включают серии H.26X, серии MPEG и т. д., а знакомые нам форматы кодирования аудио включают MP3, ACC и т. д.

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

После получения сжатых данных вам необходимо декодировать сжатые аудио- и видеоданные, чтобы получить несжатые данные о цвете и несжатые данные выборки звука. Цветовые данные обычно известны как RGB, но в видео обычно используется формат цветовых данных YUV, который относится к определению значения цвета пикселя посредством яркости, оттенка и насыщенности. Данные выборки звука обычно используют PCM.

Шаг 4:Синхронное воспроизведение аудио и видео。

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

PS：Если вы все еще не совсем понимаете описанный выше процесс,Для дальнейшего чтения рекомендуется следующую серию статей:

1. 《Подробное объяснение технологии потоковой передачи аудио и видео в реальном времени на мобильных терминалах (1): Введение》
2. 《Подробное объяснение технологии мобильного аудио- и видеовещания в режиме реального времени (2): сборник》
3. 《Подробное объяснение технологии мобильного аудио- и видеовещания в режиме реального времени (3): Обработка》
4. 《Мобильный терминал Аудио и видео в реальном Подробное объяснение технологии прямого вещания (4): Кодирование и упаковка.》
5. 《Мобильный терминал Аудио и видео в реальном Подробное объяснение технологии потокового вещания (5): Push-стриминг и передача.》
6. 《Подробное объяснение технологии потоковой передачи аудио и видео в реальном времени на мобильных терминалах (6): оптимизация задержки.》

кроме того:Статьи о технологии аудио- и видеокодеков,Вы также можете подробно изучить следующие статьи:

1. Видеокодек：《Теоретический обзор》、《Введение в цифровое видео》、《основы кодирования》、《Введение в технологию прогнозирования》
2. 《Познакомьтесь с основной технологией кодирования видео H.264.》
3. 《Как начать изучать технологию аудиокодеков》
4. 《Введение в основы аудио и принципы кодирования》
5. 《Общие стандарты кодирования голосовой связи в реальном времени》
6. 《Особенности и преимущества кодирования видео в реальном времени H.264》、《Прошлое и настоящее кодирования видео H.264 и VP8》
7. 《Подробное объяснение принципов, эволюции и выбора применения аудиокодеков.》、《Нулевые основы: введение в самую популярную технологию кодирования видео в истории.》

8. Протокол передачи видео в реальном времени 1: HLS

Во-первых, давайте представим протокол HLS. HLS — это аббревиатура HTTP Live Streaming и представляет собой протокол передачи потокового мультимедиа в сети, предложенный Apple.

Из названия понятно:Этот набор протоколов основан наHTTPпротокол передан。

Говоря о протоколе HLS:Прежде всего нужно понимать, что данный протокол воспроизводится сегментами в виде фрагментов видео.,Формат фрагмента видео, используемый в протоколе, — TS.,Это формат упаковки, о котором мы упоминали ранее.

Прежде чем мы получим файл TS:Протокол сначала требует запросаM3U8форматировать файл,M3U8 — описательный индексный файл.,Описывает направление адреса ТС в определенном формате.,Мы опирались на то, что описано в файле M3U8.,Вы можете получить адрес CDN каждого файла TS.,Загрузив адрес ТС и воспроизведя его по сегментам, можно собрать полноценное видео.

При воспроизведении видео по протоколу HLS:Сначала запросимM3U8документ,Если он предоставляется по требованию, вам нужно получить его только один раз во время инициализации, чтобы получить все точки среза TS.,Но если это прямой эфир, нужно постоянно опрашивать файл M3U8.,Получите новый фрагмент TS.

После получения M3U8:Можем посмотреть содержимое。Во-первых, давайте начнем с некоторой общей описательной информации.,Например, порядковый номер первого фрагмента, максимальная длительность фрагмента, общая длительность и т. д.,Далее идет список адресов, соответствующий конкретному ТС. Если это прямой эфир,Затем каждый раз, когда вы запрашиваете список TS в файле M3U8, он будет обновляться последними фрагментами прямой трансляции.,Для того, чтобы добиться эффекта прямой трансляции.

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

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

Во-вторых: формат воспроизведения фрагментов также упрощает вставку в видео рекламы и другого контента.

В сценариях прямой трансляции HLS также является широко используемым протоколом. Его самым большим преимуществом является благословение Apple, которая относительно хорошо продвигает этот протокол, особенно на мобильных терминалах. Введите адрес файла M3U8 в видео, и его можно будет воспроизвести напрямую. Большинство браузеров также могут поддерживать его после использования декодирования MSE на ПК. Однако из-за характеристик сегментированной загрузки задержка прямой трансляции относительно велика. Например, наш M3U8 имеет 5 файлов TS, и время воспроизведения каждого файла TS составляет 2 секунды. Тогда время воспроизведения файла M3U8 составляет 10 секунд, что означает, что ход прямой трансляции, воспроизводимый этим M3U8, составляет не менее 10 секунд. назад Это не подходит для прямых трансляций. Это относительно большой недостаток с точки зрения сценариев.

Формат инкапсуляции TS, используемый в HLS, формат кодирования видео обычно — H.264 или MPEG-4, а формат кодирования звука — AAC или MP3.

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

9. Протокол передачи живого видео 2: HTTP-FLV.

Протокол HTTP-FLV, как ясно видно из названия, представляет собой протокол, который передает формат инкапсуляции FLV через протокол HTTP.

FLV — это сокращение от Flash Video. Это метод пакетирования файлов небольшого размера, подходящий для передачи по сети. Формат кодирования видео FlV обычно — H.264, а кодирование звука — ACC или MP3.

HTTP-FLV использует длинное соединение HTTP во время прямой трансляции и доставляет пакетные данные FLV на запрашивающую сторону посредством блочной передачи.

Во время прямой трансляции мы можем получить фрагмент фрагментированных данных через адрес потоковой передачи протокола HTTP-FLV.

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

Первая — это информация заголовка:464C56КонвертироватьASCIIПосле того, как кодFLVтри персонажа,01 относится к номеру версии,После преобразования 05 в двоичный формат 6-й и 8-й биты обозначают наличие звука и видео соответственно.,09 представляет, сколько байтов занимает длина заголовка.

Далее следуют официальные аудио и видео данные:через один за другимFLV TAG инкапсулирован, и каждый TAG также имеет информацию заголовка, указывающую, является ли TAG аудиоинформацией, видеоинформацией или информацией сценария. Анализируя TAG, мы можем извлечь информацию о кодировании сжатия аудио и видео соответственно.

Формат FLV изначально не поддерживается в видео. Если мы хотим воспроизвести пакетный формат этого формата, нам необходимо использовать MSE для декодирования сжатой информации о кодировании фильма и телевидения. Поэтому браузер должен поддерживать формат FLV. MSE API. Поскольку передача HTTP-FLV представляет собой файловый поток, передаваемый через длинное соединение, браузеру необходимо поддерживать Stream IO или выборку, а требования совместимости к браузеру будут относительно высокими.

FLV намного лучше, чем HLS, для воспроизведения фрагментов с точки зрения задержки. В настоящее время кажется, что на задержку FLV в основном влияет длина GOP, установленная во время кодирования.

Вот краткое введение в Республиканскую партию:существоватьH.264Во время кодирования видео,Будут сгенерированы три типа кадров: I-кадр, B-кадр и P-кадр. I-кадры — это то, что мы обычно называем ключевыми кадрами.,Ключевые кадры включают полную внутрикадровую информацию.,Может использоваться непосредственно в качестве эталонного кадра для других кадров. B-кадр и P-кадр для меньшего сжатия данных.,Информация внутри кадра должна быть выведена из других кадров. Следовательно, длительность между двумя I-кадрами также можно рассматривать как минимальную длительность сегмента воспроизведения видео. Учитывая стабильность видео нажима,Нам также требуется, чтобы привязка установила фиксированную длину интервала ключевого кадра.,Обычно 1-3 секунды,Итак, помимо других факторов,Наша прямая трансляция также будет иметь задержку в 1-3 секунды во время воспроизведения.

10. Протокол передачи видео в реальном времени 3: RTMP.

RTMPСоглашение действительно может бытьHTTP-FLVСоглашения однотипные.。

Все их форматы пакетов — FlV, но протокол передачи, используемый HTTP-FLV, — HTTP, а потоковая передача RTMP использует RTMP в качестве протокола передачи.

RTMP — это набор протоколов передачи сообщений в реальном времени, разработанный Adobe на основе TCP и часто используемый совместно с Flash-плеерами.

Преимущества и недостатки протокола RTMP весьма очевидны.

Основными преимуществами протокола RTMP являются:

• 1）первыйиHTTP-FLVТакой же,Задержка относительно низкая;
• 2）Во-вторых, его стабильность очень хорошая.,Подходит для длительного воспроизведения (за счет использования Flash во время воспроизведения) Мощная функция проигрывателя гарантирует, что страница не зависнет, даже если одновременно воспроизводится несколько потоков, что очень удобно для мониторинга и других сценариев).

Однако в настоящее время все пользователи сети отвергают Flash-плеер. Основные браузеры постепенно заявили, что они больше не поддерживают плагин Flash-плеера. Использование его на MAC может мгновенно превратить компьютер в железную тарелку для барбекю. , который потребляет много ресурсов. Что касается мобильных устройств, H5 практически вообще не поддерживается, и его самая большая проблема — совместимость.

11. Протокол передачи видео в реальном времени 4: MPEG-DASH.

Протокол MPEG-DASH является новой силой. Как и HLS, он воспроизводится путем нарезки видео.

Предыстория его создания заключалась в том, что на заре у крупных компаний был свой собственный набор протоколов. Например, Apple запустила HLS, Microsoft запустила MSS, а Adobe запустила HDS. В результате пользователям приходится сталкиваться с проблемами совместимости нескольких наборов инкапсуляции протоколов.

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

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

12. Как выбрать оптимальный протокол передачи живого видео

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

Сначала рассмотрим с точки зрения задержки:Не учитывает облачное транскодирование и потребление восходящего и нисходящего каналов.,HLSиMPEG-DASH сокращает продолжительность среза на,Задержка составляет около 10 секунд. Теоретически RTMP и FLV имеют одинаковую задержку;,существовать2-3Второй。因此существовать延时方面HLS ≈ DASH > RTMP ≈ FLV。

С точки зрения совместимости:HLS > FLV > RTMP и DASH были исключены из выбора по некоторым историческим причинам проекта, а также потому, что их позиционирование совпадает с HLS. Их совместимость еще не проводилась.

В итоге:Мы можем динамически судить об окружающей среде,Выберите протокол с наименьшей задержкой, доступный в вашей текущей среде. Общая стратегия — отдать приоритет HTTP-FLV.,Используйте HLS в качестве запасного варианта,В некоторых сценариях особых требований переключитесь на RTMP с помощью ручной настройки.

Для HLSиHTTP-FLV:Мы можем напрямую использовать hls.js и flv.js Для декодирования и воспроизведения эти две библиотеки выполняют внутреннее декодирование через MSE. Сначала извлеките соответствующие данные фрагментов аудио и видео в соответствии с форматом инкапсуляции видео и создайте SourceBuffers для аудио и видео соответственно в MediaSource. После подачи закодированных аудио и видео данных в SourceBuffer SourceBuffer выполнит оставшееся декодирование и выравнивание аудио и видео. Наконец, MediaSource заменяет src в теге Video на MediaSource. объект для игры.

существовать判断播放环境时我们可以参照flv.jsвнутреннее суждение,Определите, доступны ли MSE и StreamIO, вызвав метод оценки MSE и моделируя запросы:

// Определите, поддерживается ли MediaSource браузером и может ли поддерживаться и декодироваться кодирование видео H.264 и кодирование аудио Acc. window.MediaSource && window.MediaSource.isTypeSupported('video/mp4; codecs="avc1.42E01E,mp4a.40.2"');

Если воспроизведение FLV не поддерживается:Нужно понизить версию доHLS,На данный момент вам необходимо определить, находится ли среда браузера на мобильной стороне.,Мобильные терминалы обычно не требуют hls.js Для воспроизведения через декодирование MSE достаточно указать адрес M3U8 в источнике видео. Если это сторона ПК, определите, доступен ли MSE, и если доступен, используйте hls.js для декодирования и воспроизведения.

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

13. Как решить проблему однослойного воспроизведения

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

Проблемы с однослойным воспроизведением:是指существовать移动端H5на странице,Чтобы улучшить взаимодействие с пользователем, некоторые ядра браузеров,Заменить тег видео на угнанный родной плеер,В результате другие элементы не могут прикрыть игрока.

Например, мы хотим добавить окно чата над игроком в комнате прямой трансляции и разместить окно чата над игроком, подняв z-индекс за счет абсолютного позиционирования. Тест на ПК проходит совершенно нормально. Однако в некоторых мобильных браузерах видео заменяется собственным проигрывателем. Уровень собственного элемента выше, чем у наших обычных элементов, в результате чего окно чата фактически отображается под проигрывателем.

Чтобы решить эту проблему, мы должны сначала разделить ее на несколько сценариев.

Впервые в системе iOS:В обычных обстоятельствахvideoЯрлык будет автоматически воспроизводиться в полноэкранном режиме.,Однако iOS10 или более поздняя версия изначально предоставляют тот же атрибут слоя видео.,Мы добавляем playsinline/webkit-playsinline к тегу видео, чтобы решить ту же проблему слоев, что и большинство браузеров в системе iOS.,Остальные браузеры низкой версии системы и некоторые контейнеры веб-просмотра в приложениях (например, Weibo).,Использование атрибутов, упомянутых выше, не работает.,Вызов сторонней библиотеки iphone-inline-video может решить большую часть оставшихся проблем.

На стороне Android:Большинство на базе TencentAPPвстроенныйwebviewКонтейнеры используютсяX5Ядро,X5Ядро будетvideoЗамена родного настроенного плеера облегчила улучшение некоторых функций.。X5Он также предоставляет набор решений на том же уровне.（ПрограммаОфициальная ссылка на документНевозможно открыть）,Запись атрибута того же слоя X5 в тег видео также может включить встроенное воспроизведение в ядре X5. Однако одни и те же свойства слоя X5 ведут себя по-разному в каждой версии X5 (например, в более ранних версиях X5 вам необходимо использовать полноэкранный режим воспроизведения X5, чтобы гарантировать, что один и тот же слой видео, воспроизводимый MSE, вступит в силу),Нужно обратить внимание на различие версий.

В приложении Могуджие,Текущая интегрированная версия ядра X5 относительно старая.,При использовании MSE параметры того же слоя X5 не вступят в силу. Но если интегрировать новую версию ядра X5,Необходимо провести регрессионное тестирование на большом количестве онлайн-страниц.,Стоимость относительно высокая,Поэтому предлагается компромиссное решение. Добавив параметр переключения в URL-адрес страницы,После того, как контейнер прочитает параметры, он понизит версию ядра X5 до родного ядра браузера системы.,这样可以существовать解决浏览器视频同层问题的同时也将Ядро变动的影响范围控制существовать单个页面当中。（Эта статья была синхронизирована Опубликовано в：http://www.52im.net/thread-3922-1-1.html）

14. Статьи по теме

[1] Мобильный терминал Аудио и видео в реальном Подробное объяснение технологии прямого вещания (4): Кодирование и упаковка.

[2] Мобильный терминал Аудио и видео в реальном Подробное объяснение технологии потокового вещания (5): Push-стриминг и передача.

[3] Практический обмен информацией по обеспечению прямой трансляции аудио и видео в реальном времени с разрешением 1080P и задержкой менее 500 миллисекунд.

[4] Краткое обсуждение технических моментов разработки платформы прямых видеотрансляций в реальном времени.

[5] Технология системного чата в прямом эфире (7): Практика по сложному архитектурному проектированию массовых сообщений чата в комнате прямой трансляции.

[6] От 0 до 1: Практическое совместное использование технологий прямой трансляции аудио и видео в реальном времени с тысячами людей онлайн (видео + PPT) [Загрузка вложения]

[7] Особенности и преимущества кодирования видео в реальном времени H.264

[8] Прошлое и настоящее кодирования видео H.264 и VP8

[9] Нулевые основы: введение в самую популярную технологию кодирования видео в истории.

[10] Основы кодирования видеокодека

[11] Начало работы с нуля: полный перечень базовых знаний в области аудио- и видеотехнологий реального времени.

[12] Необходим для просмотра аудио и видео в реальном времени: быстро освоите 11 основных понятий, связанных с видеотехнологиями.

[13] Введение в аудио- и видеотехнологии реального времени для начинающих.