Проблема с двойным подключением к сокету.

[Ilya K.]

Проверяли на версиях 5.2.940, 5.2.968


Воспроизводится постоянно.
Суть проблемы - каждая вторая публикация потока не попадает в миксер
Шаги для воспроизведения:

Первый этап
Ведущий публикует поток по своему stream_id
Слушатель подключается к миксеру по общему stream_id
У слушателя видно трансляцию ведущего, все работает

Второй этап
Ведущий обновляет страницу (или уходит и возвращается на страницу по какой либо причине), повторно публикуется поток
У слушателя при попытке подключиться к миксеру возвращается ошибка «Failed to add stream to proxy»
Через некоторое время (примерно 1 минута) у слушателя возвращается ошибка «Session does not exist»

Третий этап
Ведущий снова обновляет страницу и публикует поток
Слушатель подключается к миксеру по общему stream_id
У слушателя видно трансляцию ведущего, все работает

Далее идет чередование этапов 2 и 3 с четкой периодичностью один за другим

Миксер создаётся через REST API, класс указывается com.flashphoner.media.mixer.video.presentation.CenterNoPaddingGridLayout

Требуется ли дополнительная информация?

 

[Max]

Добрый день.
Проблема по описанному сценарию не воспроизводится в сборке 5.2.970 c настройками сервера по умолчанию:
1. Публикуем поток test1 (предполагаем, что это ведущий) в примере Two Way Streaming или Media Devices
2. Создаем микшер запросом

curl --data "{\"uri\":\"mixer://m1\",\"localStreamName\":\"m1",\"mixerLayoutClass\":\"com.flashphoner.media.mixer.video.presentation.CenterNoPaddingGridLayout\"}" -X POST -H 'Content-type: application/json' -s http://localhost:8081/rest-api/mixer/startup

3. Добавляем поток ведущего в микшер запросом

curl --data "{\"uri\":\"mixer://m1\",\"remoteStreamName\":\"test1\"}" -X POST -H 'Content-type: application/json' -s http://localhost:8081/rest-api/mixer/add

4. Играем выходной поток микшера m1 в примере Player (подключился слушатель)
5. Обновляем страницу, с которой публикуется поток test1. У слушателя играет черный квадрат.
6. Заново публикуем поток test1 и добавляем его в микшер
7. Если до публикации прошло меньше минуты (mixer_idle_timeout по умолчанию), у слушателя играет микшер с потоком ведущего без переподключения.
8. Если до публикации прошло более минуты (mixer_idle_timeout по умолчанию), микшер останавливается. В этом случае создаем микшер, подключаем слушателя, у него поток микшера играет.
В связи с этим, просим уточнить, правильно ли мы поняли кейс, либо уточнить этапы воспроизведения: какие примеры используются, с какими настройками сервера.
Также просим собрать отчет, как описано здесь, включая дебаговые клиентские логи, и выслать, используя эту форму.

 

[Ilya K.]

Отправил отчет с версии 5.2.940. Пока проблематично собрать с более новой.

 

[Max]

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

mixer_lossless_video_processor_enabled=true

поскольку она отключает микширование реального времени, и последующие твики по многопоточной доставке и границам отставания и опережения входящих потоков относительно времени микшера не работают
- рекомендуем убрать настройку

encoder_priority=FF,OPENH264

поскольку реализация кодирования FF не включена в поставку WCS и доступна только Enterprise клиентам.
Что касается самой проблемы, выглядит так, что микшер слишком быстро создается после его остановки. Вот запись об остановке медиасессии микшера

12:01:21,329 INFO          MediaSession - DISCONNECT-CLIENT-pool-6-thread-3 'f1076814-4965-4f70-b554-744f503ab977' has been terminated

А это запись о попытке создания по REST (неуспешной) и попытке добавления потока в микшер (также неуспешной)

12:01:21,341 INFO         RestApiRouter - HTTPS-pool-5-thread-2 Use controller class com.flashphoner.rest.server.rest_v2.RestMixerStreamController with path /rest-api/mixer/startup
12:01:21,341 ERROR ixerStreamController - HTTPS-pool-5-thread-2 startup exception localStreamName '2158kA5lCM0NVgEgcwL' already exists
12:01:21,354 INFO         RestApiRouter - HTTPS-pool-5-thread-3 Use controller class com.flashphoner.rest.server.rest_v2.RestMixerStreamController with path /rest-api/mixer/add
12:01:21,354 ERROR ixerStreamController - HTTPS-pool-5-thread-3 pull exception Mixer not found

Как видно, не все ресурсы, связанные с микшером, успели освободиться, и имя выходного потока микшера считается занятым. Вероятно, ответ на REST API запросы не проверяется.
Рекомендуем следующее:
1. Повторно создавать микшер через 1 секунду после остановки (если принято решение пересоздать микшер. задержка уже не имеет большого значения)
2. Проверять на стороне, подающей REST API запрос, статус ответа
Кроме того, непонятно, почему при проблемах с потоком (возможно, при проблемах с публикацией своего потока) ведущий пересоздает микшер, если достаточно перепубликовать сам поток ведущего в этот же микшер (который при остановке потока ведущего продолжит работать еще 60 секунд). Учитывая разрешение и битрейт выходного потока микшера (1080p, 5 Мбит/с) проблемы могут быть также не с самим потоком микшера, а с каналом клиента, играющего этот поток. То есть, если ведущий контролирует поток визуально, у него может не хватать канала на публикацию и проигрывание, и решение о перезапуске всего микшера в этом случае выглядит неверным.
Также отметим, что при вышеуказанных параметрах микшера на один микшер требуется минимум 2 ядра CPU. Таким образом, на сервере одновременно может работать не более трех микшеров.