Рассинхронизация аудио и видео

[evgeniy.mukhin]

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

 

[Max]

Добрый день.
К сожалению, Вы предоставили логи только за более позднее время, чем указано в комментариях к отчету. В дальнейшем просим указывать имя проблемного потока, чтобы можно было идентифицировать его в логах.
Заикание с последующим рассинхроном обычно говорит о проблемах в канале пользователя, в таких случаях рекомендуется снижать разрешение и битрейт публикации. Если на канале пользователя есть потери, которые не может компенсировать даже использование TCP транспорта, можно рекомендовать пользователю сменить канал, например, с мобильной сети на проводную.
Также настоятельно рекомендуем убрать из flashphoner.properties следующие настройки:

rtp_paced_sender=true
rtp_paced_sender_initial_rate=200000
rtp_paced_sender_increase_interval=50
rtp_paced_sender_k_up=0.9

В данный момент наличие этих настроек приводит к большому объемы вывода в клиентские логи, при этом многопоточная доставка потока подписчикам, которая у Вас включена
streaming_distributor_subgroup_enabled=true
более эффективна, чем rtp_paced_sender
Кроме того, поскольку у Вас включен TCP транспорт по умолчанию, рекомендуем отключить использование TCP NIO

ice_tcp_nio=false

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

 

[evgeniy.mukhin]

Понял, спасибо большое

 

[Ilya K.]

Здравствуйте. Высылаю отчет. Также наблюдается рассинхрон после 10-й минуты (со слов тех, кто проводил тестирование). Визуально выглядит следующим образом: исходные потоки сначала проигрываются нормально, после следуют фризы видео, звук при этом воспроизводится нормально. Какое-то время может наблюдаться рассинхронизация, после видео догоняет звук в "ускоренной перемотке". Здесь имеются ввиду исходные, не микшированные потоки. Есть подозрение на то, что веб-интерфейс нашего приложения довольно нагружен, параллельно исследуем это, хотели бы также получить ваш комментарий по отчету.

 

[Max]

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

Это типичные симптомы потерь или недостаточной пропускной способности канала. Рекомендации остаются те ми же, что и ранее:
- использование TCP для предотвращения потерь
- снижение разрешения и битрейта публикации (например, 320x240, 200 кбит/с)
Если ни то, ни другое не помогает для отдельных клиентов, этим клиентам рекомендуем сменить канал (2G,3G на 4G/LTE, LTE на Wi-Fi, Wi-Fi на проводное подключение) и/или провайдера (в одном и том же месте 4G от одного оператора может давать худшие показатели, чем от другого).
Отметим также, что ваш отчет слишком велик. Например, если публикация идет по TCP, т.к. мы в этом случае не можем его расшифровать, поэтому достаточно только клиентских дебаговых логов. Но в комментария к отчету желательно указывать имена проблемных потоков, чтобы мы могли идентифицировать логи, относящиеся именно к этим потокам.

 

[Ilya K.]

Здравствуйте. Отправил ссылку на еще один отчет. Имя потока, в котором периодически наблюдается ускоренная прокрутка - 1171305LWJCldnYW5rtXf

 

[Max]

К сожалению, в логах не найдено потока с таким именем:

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

 

[Ilya K.]

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

 

[Max]

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

Мы тоже это предположили и ответили в этой теме. Действительно, канвас может как давать нагрузку на клиента, так и давать лаги и фризы при сворачивании окна или даже при выводе поверх него другого окна.

 

[Ilya K.]

Здравствуйте. Сейчас кейс не совсем тот же, что и был. Хотели бы уточнить, на чьей именно стороне проблема. Логи отправляю. Имена потоков начинаются с 5996. (как минимум один микшированный - 5996THMtkg3SGW5U8x5, исходный - 5996kJIakvMp3ggxawK) В этом случае отрисовка в Canvas отключена. Примерно с 6:50 начинаются фризы, периодически появляется рассинхронизация аудио и видео. Со временем фризи только усиливаются.

 

[Max]

Добрый день.
Проверили логи. По логам, выглядит так: в 06:53:07,247 клиент, публикующий поток 5996kJIakvMp3ggxawK, закрыл websocket соединение по keep alive таймауту:

06:53:07,247 INFO             WSClients - WSClientsKeepaliveThread-50 Websocket ping/pong timeout us detected. Removing channel and disconnect client. channel: [...], handler=com.flashphoner.server.client.handler.DelegateHandler@1f74e119, closed=false, pageUrl='null', countUnansweredPing=11} countUnansweredPing: 11

Это означает, что в течение 50 секунд подряд от клиента не было ответов на ping запросы сервера. И, как правило. это означает серьезные проблемы с каналом клиента.
Затем поток был выведен из микшера в связи с остановкой, и через минуту был остановлен сам микшер согласно настройке mixer_idle_timeout, поскольку других потоков в микшере не было.
Ситуация повторилась в 07:04:27,717
Итого: у публикующего клиента основного потока в микшере явные проблемы с каналом, возможно, пропускной способности не хватает. Такое можно отследить заблаговременно, если контролировать метрики потока, такие, как VIDEO_RATE, VIDEO_NACK, VIDEO_LOST. Метрики можно собирать в Prometheus:

http://WCS_address:8081/?action=stat&format=prometheus&groups=publish_streams[/ICODE]
О том, как настроить сбор метрик в Prometheus+Grafana, читайте здесь: [URL='https://flashphoner.com/10-vazhnyh-metrik-webrtc-striminga-i-nastrojka-monitoringa-prometheus-grafana/?lang=ru']10 важных метрик WebRTC стриминга и настройка мониторинга Prometheus +Grafana[/URL]