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

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

Max

Administrator
Staff member
Добрый день.
К сожалению, Вы предоставили логи только за более позднее время, чем указано в комментариях к отчету. В дальнейшем просим указывать имя проблемного потока, чтобы можно было идентифицировать его в логах.
Заикание с последующим рассинхроном обычно говорит о проблемах в канале пользователя, в таких случаях рекомендуется снижать разрешение и битрейт публикации. Если на канале пользователя есть потери, которые не может компенсировать даже использование TCP транспорта, можно рекомендовать пользователю сменить канал, например, с мобильной сети на проводную.
Также настоятельно рекомендуем убрать из flashphoner.properties следующие настройки:
Code:
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
Code:
ice_tcp_nio=false
Это позволит снизить потребление нативной (не Java) памяти, а также предотвратит возможный рост нагрузки на CPU на сервере, где нет публикаций.
 

Ilya K.

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

Max

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

Ilya K.

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

Max

Administrator
Staff member
К сожалению, в логах не найдено потока с таким именем:
1635907893221.png

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

Ilya K.

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

Max

Administrator
Staff member
Здравствуйте. Странно, по идее должен был сохраниться. Провели исследование, сделали вывод, что при использовании Canvas подобное поведение наблюдается довольно часто. Похоже, проблема в этом.
Мы тоже это предположили и ответили в этой теме. Действительно, канвас может как давать нагрузку на клиента, так и давать лаги и фризы при сворачивании окна или даже при выводе поверх него другого окна.
 

Ilya K.

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

Max

Administrator
Staff member
Добрый день.
Проверили логи. По логам, выглядит так: в 06:53:07,247 клиент, публикующий поток 5996kJIakvMp3ggxawK, закрыл websocket соединение по keep alive таймауту:
Code:
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:
Code:
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]
 
Top