Обычно фризы связаны с проблемами с каналом либо на стороне публикации. либо на стороне проигрывания. Проигрыванием целиком и полностью занимается браузер, если он перестает получать картинки, будет фриз, если он получает пакеты, но картинка не меняется, это тоже будет выглядеть как фриз, но браузер об этом ничего не сообщит.
Статусы потока присылаются сервером. Если сервер определит, например, что пакеты с медиа трафиком перестали приходить от паблишера, он остановит публикацию, в этом случае подписчику придет FAILED. Если websocket соединение с подписчиком разорвется, клиент также выставит статус FAILED.
Есть механизм контроля качества канала на стороне паблишера и подписчика, необходимо его настроить. Подробности здесь. Протестировать можно в примере Media Devices, как описано здесь.
Такие проблемы обычно видны в клиентских дебаговых логах. Например, можно выяснить, есть ли потери пакетов, если сверять sequence number каждого пакета и отслеживать пропуски. Но это не предназначено для использования в продакшне.
Структура и содержимое клиентских логов описаны здесь. Логи делятся по датам, на каждую клиентскую сессию создается отдельный подкаталог в каталоге с текущей датой.
Клиентские логи предназначены для разработчиков. Если вы собираете отчет, как описано здесь, мы анализируем эти логи.
В абсолютном большинстве случаев фризы связаны с качеством канала паблишера и/или подписчика. Основные рекомендации:
1. Настроить мониторинг качества канала на клиенте
2. При получении CONNECTION_QUALITY.BAD на стороне паблишера перезапускать публикацию с меньшим разрешением и битрейтом (например, снижать с 720p, 1500 kbps на 360p, 500 kbps), на стороне подписчика останавливать проигрывание и запускать заново.
3. Для снижения потерь использовать TCP транспорт на клиенте:
Code:
session.createStream({
name: streamName,
display: localVideo,
...
transport: "TCP"
}).on(STREAM_STATUS.PUBLISHING, function (stream) {
...
}).publish();