не сохранилось видео микшированного потока.

Ilya K.

Member
Здравствуйте. Не сохранился микшированный поток.
Сервер работал в обычном режиме, сохранился только лог из папки server. Можно ли по нему что-то понять или предположить?
Отправляю логи отчетом. Имя потока начинается на "4852". Не сохранился именно микшированный.
Версия сервера - 5.2.1054
 
Last edited:

Max

Administrator
Staff member
Добрый день.
Сессий с микшером, который начинается с указанного сочетания цифр, в логе как минимум две. В одной из них видно. что велась запись потока микшера и отдельно потока скриншаринга. Проблем по логам для этой сессии не видно.
Во время второй сессии, встречаются такие сообщения:
Code:
08:19:35,402 WARN  ileRecordAudioBuffer - CommonFileRecorderThread-5 Full buffer and no video packets, dropping packets
08:19:35,402 WARN  ileRecordAudioBuffer - CommonFileRecorderThread-5 Full buffer and no video packets, dropping packets
08:19:35,452 WARN  ileRecordAudioBuffer - CommonFileRecorderThread-5 Full buffer and no video packets, dropping packets
08:19:35,465 WARN  ileRecordAudioBuffer - CommonFileRecorderThread-5 Full buffer and no video packets, dropping packets
Это может означать, при единственном потоке в микшере, что в этом потоке есть проблемы с видеосоставляющей, а именно с синхронизацией между аудио и видео. В этом случае могут помочь эти настройки
Code:
audio_incoming_buffer_size=100
video_incoming_buffer_size=100
Кроме того, мы видим в логе исключение при завершении записи
Code:
08:21:31,572 WARN          FileRecorder - DISCONNECT-CLIENT-pool-6-thread-613 Exception while closing writer: 
java.util.concurrent.TimeoutException
    at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:204)
    at com.flashphoner.media.output.ffmpeg.FileRecorder.getRecordedFiles(Unknown Source)
    at com.flashphoner.media.B.G.getRecordedFiles(Unknown Source)
    at com.flashphoner.media.B.B.B.onSessionShutdown(Unknown Source)
    at com.flashphoner.media.B.G.K(Unknown Source)
    at com.flashphoner.media.B.G.stop(Unknown Source)
    at com.flashphoner.server.client.MediaWCSClient.internalTerminatePublishStreamAndSession(Unknown Source)
    at com.flashphoner.server.client.MediaWCSClient.close(Unknown Source)
    at com.flashphoner.server.client.handler.wcs4.WCS4Handler.disconnectSync(Unknown Source)
    at com.flashphoner.server.client.handler.wcs4.WCS4Handler.lambda$disconnectAsync$0(Unknown Source)
    at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1764)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
    at java.base/java.lang.Thread.run(Thread.java:832)
Это может означать либо нехватку ресурсов CPU (но нет данных по его загрузке на этот момент, как и о конфигурации сервера), либо низкую производительность дисковой подсистемы. В этом случае рекомендуем увеличить число потоков, используемых для записи (по умолчанию используются 4 потока), например
Code:
file_recorder_thread_pool_max_size=8
Отметим, что количество потоков не должно превышать количество ядер CPU
Также, для снижения нагрузки на CPU во время записи, рекомендуем записывать моно звук
Code:
record_audio_codec_channels=1
Кроме того, рекомендуем перенести каталог для записей на RAM-диск. Расположение каталога для записей и для временных файлов задается настройками
Code:
record_dir=/ramdrive
record_tmp_dir=/ramdive
Здесь /ramdrive - точка монтирования RAM-диска. Копировать записи в место для постоянного хранения можно при помощи скрипта on_record_hook.sh
 

Ilya K.

Member
Здравствуйте. Отправляю еще один файл отчета. Стрим длился 26 минут, записалось только 1 минута. Микшированный поток - 117130yWOqHMZINiVByrJ
На данный момент пока не поменяли
Code:
record_dir=/ramdrive
record_tmp_dir=/ramdive
Нагрузки на дисковую систему не наблюдается.
Остальное поправили.
Посмотрите, пожалуйста.
 

Max

Administrator
Staff member
В серверном логе мы видим, что микшер был создан в 12:21:33,953 по времени сервера и остановлен в 12:22:29,992, тогда же остановилась и его запись. Обратите внимание, что следующий микшер с тем же именем Вы попытались создать в 12:22:30,014 (менее чем через 100 мс), и ресурсы, связанные с предыдущим экземпляром, не успели освободиться.
При следующем успешном создании микшера в 12:22:34,089 рекордер был создан в 12:22:34,193, затем остановился в 12:22:38,978 с ошибкой
Error while feeding writer, поэтому следующий микшер с таким же именем не был записан. Одновременно с этим велась запись потока, который был в этот момент один в микшере, и эта запись давала ошибки вида Non monotonic audio time -2:-1. Возможно, проблемы с входящим потоком (например, отсутствие аудио и видео данных) привело к фризу на выходе микшера, что и вызвало ошибку при передаче медиаданных микшера в рекордер.
Рекомендуем следующее:
1. Увеличить количество ядер CPU на сервере, где фиксируются проблемы, хотя бы до 8. С Вашими параметрами микшера, к сожалению, нельзя гарантировать стабильную работу на 4 ядрах, которые используются сейчас.
2. Пересмотреть последовательность выполнения операций: ресурсы освобождаются и выделяются не мгновенно, поэтому необходимо либо использовать таймауты не менее 1 секунды между посылками REST API запросов на создание микшера, добавление в микшер потоков, остановку микшера, либо, предпочтительно, контролировать состояние микшера по REST API /mixer/find_all. Этот способ дает возможность узнать также, добавлен ли уже поток в микшер, поскольку возвращает список идентификаторов медиасессий входящих потоков, см пример здесь. По REST API можно контролировать и то, ведется ли запись микшера или любого другого потока, и при необходимости рестартовать запись.
3. Проверить, что пропускной способности каналов участников хватает для публикуемых потоков. Поскольку Вы используете транспорт TCP по умолчанию, можно проверять пропускную способность при помощи iperf. По ссылке приведены примеры тестирования по UDP, чтобы проверять TCP канал, достаточно опустить ключ -u:
Code:
iperf3 -c wcs -p 5201 -t 120
4. При просмотре записи, мы обратили внимание, что на видео накладывается надпись, причем это делается не на стороне WCS. Если Вы накладываете надпись на стороне клиента, используя Canvas Streaming, нужно убедиться, что производительности ПК участника для этого хватает: проверить нагрузку на CPU и GPU в Chrome браузере. Также необходимо убедиться, что страница не сворачивается в фон во время трансляции. Просадка производительности на клиенте или сворачивание страницы при публикации с канваса могут приводить к фризам и потерям пакетов (с точки зрения сервера) даже при относительно чистом канале.
 
Top