Некоторые стримы не сохраняются

[Vadimmiras]

Добрый день!

В продолжении темы - сейчас переработал сервер, теперь в iops и в цпу не упираемся, озу достаточно, примонтирован HDD в /records/, сейчас пишется примерно 2-5 стримов единовременно, нагрузка совсем небольшая, тюнинг произведен, но все равно некоторые стримы не сохраняются.

Вообще задача стоит такая - с помощью флешфонера захватывать поток с камеры и сохранять, к стримам не подключаются, стримы длиной от минуты до 40, в среднем минут 5-10, никак не разберусь, почему флешфонер не пишет ~1-2% стримов, так же бывает не отправляет unpublished, в общем работает с перебоями.

Прошу помочь разобраться и решить проблему, в репорте доступ дал.

 

[Max]

Добрый день.

никак не разберусь, почему флешфонер не пишет ~1-2% стримов

В прошлой теме мы нашли узкие места в производительности сервера. Если не записываются 1-2% опубликованных потоков, это говорит уже о проблемах не с производительностью, а с публикацией.
Поэтому рекомендации будут следующими:
1. Обеспечить регулярное получение ключевых кадров от паблишера, т.к. запись потока может стартовать только после получения очередного ключевого кадра, и при значительном интервале между ними часть данных в начале публикации просто не будет записана. Если публикация идет по WebRTC, этого можно добиться настройками сервера:

periodic_fir_request=true
periodic_fir_request_interval=2000

2. Проверить канал от паблишера до сервера. Если на канале есть потери, переключиться на использование TCP для публикации:

session.createStream({
    name: streamName,
    display: localVideo,
    ...
    transport: "TCP"
}).on(STREAM_STATUS.PUBLISHING, function (stream) {
...
}).publish();

так же бывает не отправляет unpublished

Это также может говорить о проблемах с каналом. Например, если разорвалась websocket сессия, то на стороне клиента будет получено событие STREAM_STATUS.FAILED. UNPUBLISHED клиент получит только в том случае, если он остановил публикацию при помощи Stream.stop().
Также можно при проблемах с каналом снизить разрешение/битрейт публикации, например, с 1024x768 до 640x480
3. Убедиться, что на стороне паблишера не заблокированы исходящие соединения на порты из диапазона media_port_from-media_port_to, в этом случае публикация завершается с ошибкой Failed by ICE timeout (и события UNPUBLISHED не будет, как и в примере выше). Клиенту можно рекомендовать использовать другую сеть или другого мобильно оператора
4. Периодически, от версии к версии, браузер Adroid Firefox начинает давать проблемы с синхронизацией аудио и видео, в этом случае поток публикуется, но не может быть записан, либо запись может быть испорчена, т.к. не получается корректно синхронизировать две дорожки в потоке. Поэтому Android Firefox не рекомендуется использовать для публикации потоков, которые могут быть записаны.

 

[Vadimmiras]

1 и 2 сделал, но кажется, что проблема не в соединении, а в моменте, когда видео начинает кодироваться (имею в виду из .tmp в .mp4), потому что сам стрим в .tmp создается и пишется (возможно не отследил, что и не пишется, но вроде смотрел - .tmp был на месте, но не записался)

Так же в паблишере при нажатии на "стоп" вызывается Stream.stop(), статус FAILED тоже обработан, при этом ничего вообще в принципе не сохраняю, просто выдается алерт с последующей перезагрузкой страницы.

Дело в том, что при UNPUBLISHED я записываю данные стрима в бд, то есть срабатывает все таки нужный ивент, но потом на сервере я файла не вижу, так же не срабатывает on_record_hook.sh, туда тоже зацепился

С Firefox принял, спасибо за информацию.

 

[Max]

1 и 2 сделал, но кажется, что проблема не в соединении

На сервер в логах много записей о том, что соединение закрыто на стороне клиента

Дело в том, что при UNPUBLISHED я записываю данные стрима в бд, то есть срабатывает все таки нужный ивент, но потом на сервере я файла не вижу, так же не срабатывает on_record_hook.sh, туда тоже зацепился

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

enable_extended_logging=true
client_log_level=debug

Сбор дампа необходимо начинать до публикации потока.
Отчет нужно отправить при помощи этой формы, указав имя проблемного потока

 

[Vadimmiras]

На сервер в логах много записей о том, что соединение закрыто на стороне клиента

Да, таких я отбрасываю, это скорее всего люди с плохим каналом, и я так понимаю, что при этом не приходит UNPUBLISHED, а значит, что мы их не учитываем вообще

Соберите отчет

Окей, как соберу - пришлю, спасибо.

И еще такой вопрос - про масштабирование origin-edge понятно, а вот как промасштабироваться, если будет нагрузка по одновременным стримам? Подойдет ли инструкцияпо настройке автобалансировщика AWS под мою задачу?

 

[Max]

Подойдет ли инструкцияпо настройке автобалансировщика AWS под мою задачу?

Должна подойти. CDN у Вас нет, нужно просто настроить балансировку по загрузке процессора. Но придется сделать собственный образ, чтобы подмонтировать HDD для записей в инстансы, и использовать его как шаблон конфигурации для запуска инстансов в балансировщике.

 

[Vadimmiras]

Должна подойти.

В таком случае я думаю отправлять сразу в дропбокс файл при записи, свой образ то все равно буду создавать, правда пока не ясен вопрос с letsencrypt, т.к. серты сгенерированы им и по крону каждый месяц добавляются автоматом в флешфонер, и по идее мне не нужно все это в образе. Ну тут буду думать, спасибо

 

[Vadimmiras]

Отчет нужно отправить при помощи этой формы, указав имя проблемного потока

Все бы хорошо, но отчет получился на 600мб, к сожалению полностью не отправить. До этого давал доступ по ssh, возможно через подключение зайти посмотреть? Имя проблемного стрима оставил в репорте

 

[Max]

По клиентским логам, публикация проблемного потока продолжалась в течение 2 секунд

06:02:55,305 DEBUG         MediaSession - API-ASYNC-pool-13-thread-4275 mediaProvider=WebRTC
06:02:55,305 DEBUG         MediaSession - API-ASYNC-pool-13-thread-4275 MediaSession: a5751800-d3e8-11eb-8ed4-e1a46d317d62. Acquired audioPort: 27678
06:02:55,305 DEBUG              Session - API-ASYNC-pool-13-thread-4275 preInit port:27678 secured:true rtspMux:true
06:02:55,305 DEBUG              Session - API-ASYNC-pool-13-thread-4275 Audio:  port - 27678
06:02:55,305 DEBUG         MediaSession - API-ASYNC-pool-13-thread-4275 MediaSession: a5751800-d3e8-11eb-8ed4-e1a46d317d62. Acquired videoPort: 27682
06:02:55,305 DEBUG              Session - API-ASYNC-pool-13-thread-4275 preInit port:27682 secured:true rtspMux:true
06:02:55,305 DEBUG              Session - API-ASYNC-pool-13-thread-4275 Video:  port - 27682
...
06:02:57,979 INFO  stractRtpRtcpSession - API-ASYNC-pool-13-thread-4276 RtpSession with id a5751800-d3e8-11eb-8ed4-e1a46d317d62 terminated.
06:02:57,979 INFO      RtpVideoStreamer - API-ASYNC-pool-13-thread-4276 stop
06:02:57,979 INFO        RtpVideoPlayer - API-ASYNC-pool-13-thread-4276 stop
06:02:57,979 DEBUG         VideoSession - API-ASYNC-pool-13-thread-4276 a5751800-d3e8-11eb-8ed4-e1a46d317d62 has been terminated
06:02:57,979 DEBUG         MediaSession - API-ASYNC-pool-13-thread-4276 stopMsrpSession null
06:02:57,979 INFO          MediaSession - API-ASYNC-pool-13-thread-4276 'a5751800-d3e8-11eb-8ed4-e1a46d317d62' has been terminated
06:03:00,335 DEBUG    AbstractWCSClient - DISCONNECT-CLIENT-pool-6-thread-6922 Release client

При этом видео пакетов было получено значительно меньше, чем пакетов аудио. Ключевых фреймов не было ни одного, также не было синхронизации аудио-видео, поэтому запись не стартовала. Причина завершения сессии - закрытие со стороны клиента:

2021-06-23 06:02:53;/95.82.***.**:21443/172.31.0.113:8443-5db5bec1-59e9-447e-a6cf-f3865472c5d0;DISCONNECTED;Normal disconnect;6;

Если для публикации используется TCP, это исключает потери, но, скорее всего, пропускной способности канала от клиента до сервера не хватает. чтобы пропихнуть видео (обычно ключевые фреймы по размерам больше, чем промежуточные). В таких случаях рекомендуем следующее:
- сменить сеть на более качественную (LTE на Wi-Fi, Wi-Fi на проводное подключение, 3G и 2G не рекомендуем использовать вообще)
- снизить разрешение и битрейт публикации до минимального, например 320x180, 100 кбит/с

Все бы хорошо, но отчет получился на 600мб, к сожалению полностью не отправить.

В таких случаях можно выложить отчет на облачное файлохранилище и дать на него ссылку в комментариях к форме.
При сборе отчетов просим также переключать серверные логи в info.