В серверном логе мы видим, что микшер был создан в 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 браузере. Также необходимо убедиться, что страница не сворачивается в фон во время трансляции. Просадка производительности на клиенте или сворачивание страницы при публикации с канваса могут приводить к фризам и потерям пакетов (с точки зрения сервера) даже при относительно чистом канале.
