Задержка воспроизведения — еще один очень важный показатель качества воспроизведения. Компания ByteDance однажды предоставила данные: она снизила скорость задержки на 7,7%, а продолжительность задержки — на 9,8%, что привело к увеличению времени просмотра пользователем на 0,22%.

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

• скорость задержки,существования Было отставание в одном воспроизведении из Количество существующихпроигрываний Доля из в общем количестве воспроизведений.
• Среднее время задержки,Отношение общей продолжительности лагов видео, с которыми сталкиваются пользователи, к общему количеству лагов при просмотре видео.
• Количество зависаний за 100 секунд,По статистике зафиксировано 100 секунд воспроизведения.,Формула расчета：sum(Количество зависаний) / сумма(длительность воспроизведения(единица s)) * 100。
• Продолжительность стоп-кадра в 100 секунд (миллисекунды)：Статистикаизиграть 100s Сколько будет показано в видео? ms из Продолжительность задержки составляет,Формула расчета：sum(Продолжительность аромата(единица мс)) / sum(длительность воспроизведения(единицы с)) * 100。

Хотя все эти индикаторы отражают задержку воспроизведения, разница все равно довольно велика. Какой индикатор лучше выбрать?

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

• Лучшая ситуация: без лагов
• Ситуация немного хуже: меньше лагов и меньшее время одиночной задержки.
• Худший случай: больше времени задержки, время одной задержки короче, время одной задержки больше;
• В худшем случае: много лагов, а один лаг занимает много времени.

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

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

такотносительноскорость задержки、Среднее время задержкииКоличество зависаний за 100 секунд,Задержка сто секундВозможно, это лучше отражает чувства пользователей по поводу задержек.изиндикатор。因为一次играть中Застрял и остановился过 1 Один или несколько раз считается, что он застрял.,такскорость задержкиНе может быть очень хорошоиз反应出用户Застрял и остановилсяиз Сколько раз,Застрял и остановилсяиз Сколько времени。Количество зависаний за 100 секунд能反映用户Застрял и остановилсяизчастота,Однако это не отражает время задержки пользователя.

конечно,скорость задержки、Среднее время задержкииКоличество зависаний за 100 секундВсе еще можно использовать в качестве поддержкиизиндикаторы приходятсосредоточиться на。

Оптимизацию задержки воспроизведения можно условно разделить на несколько общих направлений:

• Контроль скорости кода
  • Адаптация скорости кода
  • H.265 Снижение битрейта
  • Мягкое редактирование Снижение битрейта
• Стратегия игрока
• Push-стримингконец Стратегия
• CDN Стратегия

Мы объясним меры оптимизации с этих направлений.

1. Контроль скорости кода

1.1. Адаптация скорости кода.

Ниже приведены некоторые меры контроля скорости кода:

• Потоковая передача H.265: по сравнению с H.264 скорость потокового кода снижается.
• Программное решение H.265: Улучшите покрытие потоков H.265 с низким битрейтом.
• Потоковая передача 540P: более низкая скорость потокового кода по сравнению с 720P.
• Ограничение скорости push-кода OBS: Уменьшите скорость push-кода OBS.
• Мягкое кодирование для принудительной потоковой передачи: по сравнению с жестким кодированием мягкое кодирование снижает скорость push-кода.
• Стратегия LAS/Broadcast Control: адаптивный выбор скорости передачи данных,существуют Уменьшайте битрейт воспроизведения, когда пользователь зависает.

Несмотря на то, что у нас есть вышеуказанные меры контроля скорости кода, мы обычно не можем применять один и тот же метод управления скоростью кода для всех пользователей. Например, что касается потоковой передачи, для пользователей, которые используют стабильную и высокую скорость сети Wi-Fi, мы можем воспроизводить потоки с высокой скоростью передачи данных и высоким разрешением; для пользователей, которые используют скорости сети 4G, которые склонны к дрожанию, мы можем; воспроизводить потоки с низким битрейтом и низким разрешением. Что касается потоковой передачи, мы можем рассчитать ACU комнаты прямой трансляции (общее время просмотра пользователей в комнате прямой трансляции/общее время нажатия комнаты прямой трансляции), чтобы оценить популярность и влияние комнаты прямой трансляции. якорей, мы можем использовать те, у которых более высокая скорость передачи кода, чтобы улучшить качество изображения. Для небольших якорей с большим объемом данных и рассредоточенной аудиторией мы можем соответствующим образом уменьшить скорость передачи потоковой передачи.

ссылка:

• Оценка пропускной способности[1]

1.2, коэффициент уменьшения кода H.265

H.265 имеет более высокую эффективность сжатия, чем H.264. Использование H.265 вместо H.264 может снизить скорость передачи данных, сохраняя при этом определенное качество изображения.

1.3. Мягкое снижение скорости кодирования.

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

2. Стратегия игрока

2.1. Используйте уровень воды в аудиобуфере для управления воспроизведением.

В прямом эфире мы обнаружим, что поле длительности некоторых видео AVPacket пусто, но на самом деле оно длинное. Если мы используем водяной знак видео для запуска воспроизведения при буферизации данных, оно будет зависать. чтобы начать выход в эфир. Например: мы установили, что перед началом воспроизведения мы должны ждать 100 мс видеоданных. Поскольку продолжительность некоторых AV-пакетов видео равна нулю, при накоплении видеоданных длительностью 100 мс соответствующая фактическая длительность видео фактически превышает 100 мс. Это означает, что для начала трансляции требуется больше времени, чем ожидалось, что приведет к увеличению времени задержки на 100 секунд.

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

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

2.2. Стратегия динамической буферизации.

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

Вот введение Стратегия：Стратегия трехуровневого буферного уровня воды。

Уровень воды здесь соответствует времени буферизации видео или времени буферизации звука.

например,Уровень буферной воды третьего уровня можно установить на：500ms、1000ms、5000ms。

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

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

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

Может существовать стратегия постепенного обновления между уровнями буфера второго и третьего уровня. Например: после первого лага буферизация 1000ms видеоданные, а затем начать воспроизведение после второго стоп-кадра, буферизуя; 2 * 1000ms = 2000ms Видеоданные начинают воспроизводиться после третьего раза, после третьего стоп-кадра буферизации; 2 * 2000ms = 4000ms Видеоданные начинают воспроизводиться после четвертого стоп-кадра, буферизации; MIN(2 * 4000ms = 8000ms, 5000ms) = 5000ms Воспроизведение начинается после того, как последующие видеоданные будут буферизованы; 5000ms видеоданные перед началом воспроизведения.

2.3. Играйте на низкой скорости при низкой буферизации.

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

На рисунке ниже показана стратегия воспроизведения с двойной скоростью:

Стратегия воспроизведения с двойной скоростью

• max-play-rate и min-play-rate 表示играть器из最大играть速率и最低играть速率。Вообще говоря,Слишком низкая или слишком высокая скорость воспроизведения повлияет на качество просмотра видео. Вообще говоря,[0.9, 1.2] Это приемлемый диапазон, который можно определить путем тестирования в конкретных обстоятельствах.
• Когда продолжительность кэша [0, normal-low-cache) интервале, плеер использует замедленное воспроизведение. Среди них Когда продолжительность кэша [0, min-cache] интервал, плеер использует установленную наименьшую скорость воспроизведения min-play-rate играть.
• Когда продолжительность кэша [normal-low-cache, normal-high-cache] интервал, плеер играет нормально и скорость воспроизведения 1.0。
• Когда продолжительность кэша (normal-high-cache, limit-cache] интервале, плеер использует ускоренное воспроизведение. Среди них Когда продолжительность кэша [max-cache, limit-cache] интервал, плеер использует установленную максимальную скорость воспроизведения max-play-rate играть.limit-cache Верхний предел размера буфера проигрывателя.

2.4. Кэширование и предварительная загрузка коротких видео.

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

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

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

2.5. Установите тайм-аут задержки.

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

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

3. Стратегия продвижения

3.1. Потоковый терминал поддерживает выход из фонового режима для продолжения потоковой передачи.

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

• 1) Если вы продолжите собирать аудио после выхода из фонового режима, это может привести к проблемам с конфиденциальностью. Для решения этой проблемы вы можете выйти в фоновый режим, чтобы остановить сбор, но продолжайте отправлять приглушенные аудиоданные. Конечно, если продукт может выйти из фонового режима и продолжить сбор аудио, просто используйте возможности системы для продолжения сбора.
• 2) Вы не сможете продолжать собирать видео после выхода из фона. Если вы не загрузите видеоданные в это время, это может привести к ошибке. CDN iPlayer несовместим из-за проблемы. Потому что есть CDN ииграть器是需要检查视频数据,И выполнить некоторые функции на основе видеоданных и Стратегияиз. По этому вопросу,Вы можете отодвинуть последний кадр перед фоном.,И уменьшите частоту кадров соответствующим образом, чтобы уменьшить скорость кода Push-стримингиз.
• 3) Из-за длительного фонового времени сетевой запрос приложения может быть прерван системой или приложение может даже быть закрыто. Для решения этой проблемы вы можете попробовать некоторые решения для поддержания активности в фоновом режиме. Например, iOS может воспроизводить беззвучный звук, чтобы оставаться активным после выхода из фонового режима.

4. Стратегия CDN

4.1. Связь между эффектом оператора и длительностью 100-секундного замораживания.

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

4.2. Стратегия распространения данных CDN.

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

4.3. Оптимизация статуса CDN после отключения push-потока.

Некоторые поставщики CDN кэшируют одну или несколько последних GOP живого потока на узле, куда извлекается поток, а также настраивают период действия этого кэша (то есть, если нет запроса на получение этих данных в течение определенного период времени, кэш будет очищен по истечении таймаута) ).

Таким образом, даже если поток push-уведомлений был отключен, поток pull извлечет данные, кэшированные CDN, и начнет воспроизведение. Однако, поскольку эти данные ограничены, после завершения потребления CDN возвращает код состояния HTTP. окажет большее влияние.

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

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

Ссылки

[1]

Оценка пропускной способности: https://docs.google.com/document/d/1e3jVkZ6nxNWgCqTNibqV8uJcKo8d597XVl3nJkY7P8c/edit#heading=h.2zer3ifwclzq

- над -