Эту статью опубликовали технические специалисты ByteDance Ли Чэньгуан, Куан Цзяньсинь и Чэнь Цзяньпин. Эта статья была переработана и изменена.

1. Введение

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

В этой статье вы познакомитесь с оптимизацией и развитием технологии прямой трансляции видео со сверхмалой задержкой.

2. Серия статей

Данная статья является первой в серии статей 11 Глава, общий каталог этой серии выглядит следующим образом:

• 《Советы по технологиям видеотрансляций (1): демонстрация прямой трансляции видео на Facebook с миллионами интерактивных фанатов》
• 《Советы по технологии прямой трансляции видео (2): Как технология P2P снижает пропускную способность прямой трансляции видео в реальном времени на 75 %?》
• 《Советы по технологии прямой видеотрансляции (3): Обмен идеями реализации и техническими трудностями системы ответов на вопросы в прямом эфире в режиме реального времени.》
• 《Советы по технологии прямой трансляции видео (4): Впервые компания Kuaishou показала, как она может позволить миллионам зрителей смотреть прямую трансляцию одновременно и запускать ее за считанные секунды без задержек?》
• 《Советы по технологии прямой трансляции видео (5): Qiniu Cloud использует протокол QUIC для обеспечения прямой трансляции видео в реальном времени с нулевой задержкой.》
• 《Советы по технологии прямой трансляции видео (6): практика использования миллионов архитектур с высоким уровнем параллелизма для прямой трансляции вопросов в реальном времени на Sina Weibo》
• 《Советы по технологии прямой трансляции видео (7): Практика оптимизации в течение 400 мс после первого экрана прямой трансляции видео в реальном времени》
• 《Советы по технологии прямой трансляции видео (8): расшифрована технология прямой трансляции видео высокой четкости Taobao с малой задержкой》
• 《Советы по технологии прямой трансляции видео (9): Все аспекты проектирования серверной архитектуры десятков миллионов систем прямого вещания.》
• 《Советы по технологии прямой трансляции видео (10). Познакомьтесь с двухтактной архитектурой потоковой передачи, протоколами передачи и т. д. основных систем прямой трансляции видео в одной статье.》
• 《Советы по технологии прямой трансляции видео (11): Эволюция технологии прямой трансляции видео со сверхмалой задержкой》（* Эта статья）

3. Роль технологии прямого вещания с малой задержкой

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

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

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

На рисунке ниже отражено всестороннее рассмотрение роли технологии прямого вещания с малой задержкой с трехсторонней точки зрения: технология/продукт/операция. Влияние технологических изменений на положительный цикл всей экосистемы рассматривается с точки зрения комплексного внешнего воздействия; внутренние факторы.

4. Проблема задержки протокола RTMP в традиционной технологии прямого вещания.

Протокол RTMP является наиболее традиционным протоколом прямой трансляции. Якорь использует протокол RTMP для передачи видео- и аудиоданных в кодировке H.264/5 и AAC на сервер CDN поставщика облачных услуг для инкапсуляции и распространения. Сквозная задержка. обычно контролируется в пределах от 3 до 7 секунд.

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

В случае протокола RTMP:Чтобы справиться с задержкойуменьшать Обязательно сжимает буфер загрузки плеера,Это вызовет серьезные проблемы с задержкой,Это делает воспроизведение неудобным (задержка до 2 секунд).

5. Недостатки традиционной технологии прямого вещания в интерактивных сценариях реального времени.

1）таймлапс видеои Имеется существенная разница в задержке заградительного взаимодействия.,Проблема Взаимодействие контента чата не соответствует ритму изображения передачи видео:

2）Взаимодействие между аудиторией и ведущим простое.,Это односторонняя передача контента, и ее невозможно осуществить.приезжатьдвусторонний（существовать RTC не могут быть существенно решены до внедрения технологии).

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

4）существоватьпрямая трансляцияи В сценарии интерактивной прямой трансляции, где сосуществуют несколько сценариев.,Якорь использует традиционный RTMP для продвижения потока при обнаружении сцены PK с непрерывной пшеницей.,Возникнет проблема переключения между принудительной потоковой передачей/локальным соединением и интеграцией пшеницы/соединением с сервером и интеграцией пшеницы.,Такое изменение сцены вызовет мгновенные проблемы с зависанием аудитории. Если вы используете технологию прямого вещания на основеwebRTC, решение для прямого вещания со сверхнизкой задержкой.,Эту проблему слияния логики push-to-Lianmai можно решить дружественным способом, приезжая (нужно только изменить логику распределения канала потока пересылки-подписки сервера).,Не требует обходного планирования потоков push-медиаданных).

6. Разница между прямой трансляцией со сверхнизкой задержкой и стандартной прямой трансляцией

6.1 Прямая трансляция со сверхнизкой задержкой

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

Такие сценарии, как прямые трансляции электронной коммерции и прямые трансляции событий, характеризуются высокой степенью параллелизма и низкой задержкой. Задержка традиционных прямых трансляций в 3–20 секунд не может удовлетворить их потребности, но требования к взаимодействию в реальном времени не так хороши, как эти. Для типичных аудио и видео в реальном времени, таких как приложения для видеоконференций, нет необходимости уменьшать задержку до менее 400 мс.

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

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

6.2 Различия в протоколах транспортного уровня

Оптимизация надежности на основе протокола UDP обеспечивает основу для слабых сетевых противодействий.

Традиционные прямые трансляции, такие как FLV/RTMP, используют протокол TCP (или протокол QUIC). TCP — это надежный протокол передачи, который жертвует передачей в реальном времени в обмен на целостность данных.

В слабой сетевой среде соединение «трехстороннее рукопожатие» перед передачей данных приведет к большой задержке.

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

Аудио- и видеопродукты реального времени (например, прямая трансляция RTM со сверхнизкой задержкой) часто используют протокол UDP, а уровень протокола и уровень алгоритма оптимизируются поверх этого для повышения надежности и логики передачи.

Статьи по теме можно прочитать:

1. 《Введение в сетевое программирование для ленивых (V): быстро понять, почему UDP иногда имеет преимущества перед TCP.》
2. 《Техническая грамотность: новое поколение протоколов сетевого транспортного уровня с малой задержкой на основе UDP. Подробное объяснение QUIC.》
3. 《Неизвестное сетевое программирование (6): глубоко понимать протокол UDP и эффективно его использовать.》
4. 《Неизвестное сетевое программирование (7): Как сделать ненадежный UDP надежным?》

6.3 Оптимизация протокола UDP

Протокол UDP часто встречается в практических приложениях вместе с протоколом RTP/RTCP.

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

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

7. Эволюция самого протокола RTM

a=extmap:18 "http://www.webrtc.org/experiments/rtp-hdrext/decoding-timestamp" a=extmap:19 "uri:webrtc:rtc:rtp-hdrext:video:CompositionTime" a=extmap:21 uri:webrtc:rtc:rtp-hdrext:video:frame-seq-range a=extmap:22 uri:webrtc:rtc:rtp-hdrext:video:frame-type a=extmap:23 uri:webrtc:rtc:rtp-hdrext:video:reference-frame-timestamp a=extmap:27 uri:webrtc:rtc:rtp-hdrext:audio:aac-config

RTP использует заголовок частного расширения RTP для передачи значения DTS/CTS. Каждый пакет данных RTP передает значение DTS кадра через заголовок расширения RFC5285-Header-Extension. Первый пакет RTP и пакет VPS/SPS/PPS каждого кадра. передать RFC5285. Заголовок расширения Header-Extension содержит значение CTS кадра, а временная метка текущего кадра вычисляется через PTS = DTS + CTS. Используется для обеспечения быстрой синхронизации аудио и видео, а также точной синхронизации аудио и видео логики управления воспроизведением проигрывателя.

Расширенное поведение головы порядковый номер начала/конца кадра:Если первые несколько пакетов первого кадра потеряны,Затем вы можете быстро инициировать повторную передачу в соответствии с начальным порядковым номером, чтобы ускорить передачу первого кадра, если последние несколько пакетов текущего кадра потеряны;,Затем можно быстро инициировать повторную передачу на основе конечного порядкового номера кадра.,уменьшатьзадерживать,Уменьшить отставание.

Расширенное ношение головытип рамы：Если правильный тип кадра переносится и анализируется,Клиенту не нужно анализировать metadata ;В то же время при слабой сети клиент может пропустить B Прямое декодирование кадров P кадров, ускоряя кадры и уменьшая потенциальное заикание.

Расширенное ношение головы P Информация о кадре опорного кадра:Если возникла ситуация со слабой сетью,Затем клиент может отслеживать взаимосвязь опорного кадра и соответствующую ему временную метку, указанную в заголовке расширения.,перепрыгни B декодирование кадров , уменьшите вероятность застревания.

Чтобы ускорить взаимодействие сигнализации, CDN может напрямую возвращать клиенту поддерживаемые возможности аудио и видео, не запрашивая медиа-информацию, при определенных условиях, в настоящее время описание мультимедиа SDP не будет включать конкретные детали конфигурации аудио и видео. На уровне звука AnswerSDP в настоящее время не содержит информации заголовка, необходимой для декодирования AAC; в настоящее время нам необходимо использовать режим расширенного заголовка RTP для переноса конфигурации AAC, чтобы клиент мог самостоятельно анализировать и обрабатывать при получении. Пакет RTP для завершения действия декодирования, что уменьшает объем информации. Увеличьте время взаимодействия и улучшите вероятность успешного получения трафика.

Часть реализации стандарта сигнализации miniSDP (Douyin).

Сигнализация CDN возвращается в источник асинхронно.

RTP содержит компоненты заголовка расширения.

8. Трансплантация протокола WebRTC в плеер прямых трансляций

Прямая трансляция RTM с малой задержкой основана на технологии WebRTC. Создание двухточечной передачи на основе стандарта WebRTC обычно включает следующие шаги:

• 1）Обе стороны общения должны провести консультации со СМИ.,Подробная спецификация сеанса — взаимодействие SDP (протокол описания сеанса);
• 2）с последующим интерактивным согласованием сетевого адреса（Запрос реального узла IP Адрес) Подготовиться к построению канала передачи СМИ;
• 3）Когда вышеуказанные условия будут подготовлены, будет выполнен последний шаг. Peer to Peer Одноранговая передача медиаданных.

Клиент-серверная часть сигнализации разрабатывается независимо и использует стандартный режим сообщений SDP. Часть передачи мультимедиа использует платформу WebRTC с открытым исходным кодом и самостоятельно разработанный Byte движок аудио и видео в реальном времени для передачи мультимедиа.

9. Трансформация и модернизация протокола сигнализации RTC.

Протокол сжатия MiniSDP:https://github.com/zhzane/mini_sdp。

Стандартный SDP относительно длинный (около 5–10 КБ), что не способствует быстрой и эффективной передаче. В сценарии прямой трансляции это особенно повлияет на время первого кадра.

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

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

10. Асинхронная оптимизация передачи сигналов RTM в CDN с возвратом к источнику.

Сократите время взаимодействия сигнализации RTM и сократите время рендеринга первого кадра потоковой передачи RTM.

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

Как показано ниже слева:При асинхронном возврате к источнику,Сервер больше не ждет результата возврата к источнику и возвращает напрямую. ОтветSDP, возвращение к исходной точке и WebRTC Процесс установления соединения выполняется одновременно.

Как показано справа:ждатьприезжать WebRTC Соединение устанавливается успешно, данные возвращаются в источник и немедленно распространяются. RTP данные.

11. Оптимизация зависаний рендеринга видео (100-секундные зависания уменьшены в среднем на 4 секунды)

Увеличьте время просмотра на душу населения, измените стратегию кадрирования/декодирования механизма RTC, запретите потерю кадров RTC в режиме с малой задержкой и улучшите зависания при рендеринге видео в реальном времени.

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

Если RTM хочет уменьшить отставание и получить преимущества Qoe, необходимо настроить стратегию управления трансляцией, а точки изменения логики настройки:

1）Убедитесь, что декодирование не занимает много времени из-за мягкого или жесткого декодирования. dequeuinputbuffer Подожди других api Блокировка операции jitterbuffer уровень ядра имеет уровень обязательной логики синхронизации аудио и видео для обеспечения воспроизведения аудио и видео;

2）В то же время верхний уровеньсуществовать Модуль сети мониторингаи Длина буфера модуля декодирования,Имеется соответствующая резервная логика:

• a. Считается, что жесткое решение невозможно решить, слишком много dec_cache_frames, будет сообщено об ошибке, и оно будет понижено до мягкого решения;
• б. исключение jitterbuffer: слишком много кэшированных списков кадров, что вызывает ненормальную логику проигрывателя, сообщает об ошибке и снова извлекает поток.

12. Оптимизация логики управления трансляцией RTM.

Чтобы улучшить проникновение мобильного просмотра и вещания, решение унифицированного ядра RTC изначально несовершенно (требуется много времени для инициализации аппаратного декодера MediaCodec). Перенесите модуль декодирования видео RTM из ядра RTC в ядро ​​воспроизведения TTMP, повторно используя модуль декодирования видео FLV (MediaCodec позволяет избежать повторной инициализации). Значительно сокращает время рендеринга первого кадра на платформе Android и повышает вероятность успешной потоковой передачи.

Основная логика RTC:

Улучшена логика управления трансляцией ядра RTM:

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

[1] Подробное объяснение TCP/IP - Глава 11 · UDP: Протокол пользовательских датаграмм

[2] Подробное объяснение TCP/IP - Глава 17·TCP: Протокол управления передачей

[3] Начало работы с нулевыми основами: на основе WebRTC с открытым исходным кодом реализована функция аудио- и видеочата в реальном времени от 0 до 1.

[4] Вводное изучение аудио и видео в реальном времени: краткий анализ технических принципов и использования проекта с открытым исходным кодом WebRTC.

[5] Краткое введение в WebRTC с нулевым фундаментом: основные понятия, ключевые технологии, различия с WebSocket и т. д.

[6] Изучите RFC3550: базовые знания протокола передачи данных RTP/RTCP в реальном времени.

[7] Исследование технологии потокового мультимедиа в реальном времени на основе протокола передачи данных RTMP (полный текст статьи)

[8] Техническая грамотность: новое поколение протоколов сетевого транспортного уровня с малой задержкой на основе UDP. Подробное объяснение QUIC.

[9] Делаем Интернет быстрее: Tencent делится техническим опытом использования протокола QUIC нового поколения

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

[11] Основные теории разработки аудио и видео в реальном времени: как сэкономить трафик? Прогнозирующая технология, лежащая в основе сжатия видео высокого уровня

[12] Подробное объяснение технологии прямой трансляции аудио и видео в реальном времени на мобильных терминалах (1): открытие

[13] Технология системного чата в прямом эфире (9): техническая практика десятков миллионов прямых трансляций в режиме реального времени.

[14] Лучшие практики серверной архитектуры комнат для онлайн-аудио и видео прямых трансляций (видео + PPT) [Загрузка вложения]

[15] Важная информация о технологии прямой трансляции видео: понимание двухтактной архитектуры потоковой передачи, протоколов передачи и т. д. основных систем прямой трансляции видео в одной статье.

（Эта Статья уже опубликована в：http://www.52im.net/thread-4587-1-1.html）