Проблемы с конвертацией из webm в mp4 и c сохранением записи стрима.

[dark.seer1097]

Добрый день.

1) Первая проблема: есть стримы, записи которых не сохраняются после их окончания. Мы видим их в логе, есть записи стримов у нас в базе, но они не сохраняются в папку на сервере.

2) Вторая проблема: не для всех стримов работает конвертация из webm в mp4.

 

[Max]

Добрый день.
Проанализировали присланные логи. Все проблемные потоки были остановлены до начала записи (для этих потокв не было сообщений в логе Init output writer):
98172-31046_F1857B4E-480F-4FEE-B13E-B17ED132E4F3 - публикация была остановлена клиентом раньше, чем стартовала запись
98175-2919_7479b2c1-5b25-4611-b246-a9cb0c79ef2c - публикация была остановлена клиентом раньше, чем стартовала запись
98222-1622_3a3d5116-753d-4699-99cf-d2566ab1d6c6 - этот поток остановился по разрыву websocket соединения публикующим клиентом, поэтому был остановлен republished RTMP поток, который, в свою очередь, должен был быть записан
98186-1612_3700f2f9-682d-43a3-a074-1120487d589e - публикация была остановлена клиентом, что привело к остановке republished RTMP поток, который, в свою очередь, должен был быть записан
98144-22427_d8010bc8-dbc9-471f-b557-78e78a92e526- публикация была остановлена клиентом, что привело к остановке republished RTMP поток, который, в свою очередь, должен был быть записан
Итого проблемы, скорее всего, на стороне публикующего клиента для этих потоков, например, плохой канал до сервера.
Также рекомендуем, если нет необходимости играть записанные потоки непосредственно в браузере, записывать их в MKV контейнер, что позволит избежать транскодинга VP8 в H264 и снизить нагрузку на сервер: Поддержка контейнеров MP4, WebM, MKV

 

[Max]

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

144423-2917_08228150-b941-4daf-90cd-1bac438e6742: от публикующего клиента нет ключевых фреймов в ответ на запрос от сервера, поток был остановлен через 25 секунд после начала публикации
144422-45583_A861A2E4-901F-4DF9-888C-4A33DEBCBD3D: соединение разорвано клиентом сразу после публикации
144117-1610_2fd03667-8b8e-497b-a724-a4977cd1835d: был остановлен клиентом через 6 секунд после начала публикации
143859-1619_745a80d4-bb90-4612-9b4a-6686955b2a65: в клиентском логе есть упоминания о потерянных пакетах, поток был остановлен клиентом через 28 секунд после начала публикации

Для всех этих потоков в серверном логе нет упоминаний об инициализации записи MP4 контейнера Init output writer.
Для исключения потерь пакетов между клиентом и сервером можно переключиться на TCP транспорт для WebRTC

ice_tcp_transport=true

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

periodic_fir_request=true
periodic_fir_request_interval=5000

Поскольку на сервере используется JDK 17, можно для уменьшения задержек в работе Java машины под нагрузкой включить сборщик мусора ZGC: Настройка Z Garbage Collector (ZGC)

 

[dark.seer1097]

Добрый день. Выполним Ваши рекомендации и посмотрим на результат. Спасибо

 

[dark.seer1097]

Добрый день. Изменили настройки согласно рекомендациям выше, но постоянная проблема все равно остается после недельного тестирования. Многие стримы не сохраняются на сервере.

147963-3830_4DF2CA3C-28B1-43C4-B046-FC8C597EAFC3 - Не сохранился стрим на сервере
147958-30894_3848e954-74f5-4b1f-abb6-66c59eadc937 - Не сохранился стрим на сервере
147956-31015_739c36a1-2da0-4bd5-8f29-31fccb3377c5 - Не сохранился стрим на сервере
147946-134714_2f9cb341-12b1-42d5-894c-8f6db4ff92f2 -Не сохранился стрим на сервере
147877-1609_c27615d3-5892-47eb-bcaa-587ef295bae6 - Не отработала конвертация из webm -> mp4

 

[Max]

Здравствуйте

record_stop_timeout = 15

Все инциденты связанные с несохранением стрима на сервере, связаны с этой настройкой.
Попробуйте поднять значение до 60 секунд

record_stop_timeout =60

в конфиге flashphoner.properties

 

[dark.seer1097]

Добрый день! Поставили record_stop_timeout = 60 и протестировали неделю с данным конфигом. Ситуация стала чуть лучше, но все равно еще до 10% стримов не сохраняются на сервере либо не отрабатывает конвертация.

153258-109001_56E7222C-9DB3-4781-A7E9-95C55BB4F76D - Не сохранился стрим на сервере
153206-1992_09A4BCE6-2562-43A0-AD58-8B6BA19E49B8 - Не сохранился стрим на сервере
153249-1845_f2a26693-69e9-4005-9c23-fd0c8fc4abdb - Не сохранился стрим на сервере
153230-6091_2f34ebb2-6a66-4101-a82b-6574f7ef9e24 - Не сохранился стрим на сервере
153213-134713_51F76D1E-F0F7-4A80-91FC-1805EF23A727 - Не сохранился стрим на сервере
153196-134713_4E770074-C2F1-4198-9FD3-908FDC186E3E - Не сохранился стрим на сервере
153041-3827_A19B43F0-E6A3-4138-BC29-946992AA082A - Не сохранился стрим на сервере
153041-3827_100A887B-AA5D-4715-9020-28598F739C99 - Не сохранился стрим на сервере
153127-2923_baad5ce7-65bc-47c3-a6f8-d67fabed5dda - Не сохранился стрим на сервере
153115-1609_74712c6a-719a-4b10-a8f7-959b364673e8 Не отработала конвертация из webm -> mp4

 

[Max]

Добрый день.
Во всех этих случаях выглядит так, что от клиента не получен либо получен, но не разобран ключевой кадр, поэтому не стартовала запись.
Потоки 153249-1845_f2a26693-69e9-4005-9c23-fd0c8fc4abdb, 153041-3827_A19B43F0-E6A3-4138-BC29-946992AA082A, 153041-3827_100A887B-AA5D-4715-9020-28598F739C99 были остановлены через 6-7 секунд с момента начала публикации, поэтому и могли быть записаны вообще.
Также отметим, что для некоторых H264 потоков принудительно вызывается ретрансляция в RTMP с транскодингом к 480p, хотя это не нужно, и так MP4 запишется.
Рекомендации следующие:
1. Откатить сборку WCS до 5.2.1877, т.к. в сборках, начиная с 5.2.1883, обнаружена регрессия, приводящая к утечке памяти при публикации большого количества WebRTC потоков
2. Выставить настройку, это позволит более четко определять ключевые кадры в потоке видео

h264_strict_kframe_detect=true

3. Мониторить текущие публикации по REST API: Мониторинг параметров потока при помощи REST API, развернуть Prometheus и Grafana для мониторинга статистики работы сервера: 10 важных метрик WebRTC стриминга и настройка мониторинга Prometheus +Grafana
4. Проверять, стартовала ли запись потока (создан ли файл MP4.tmp), если нет, пытаться стартовать запись принудительно: Запись потоков по требованию

 

[Max]

Заметили, что большая часть из потоков, которые не записались, опубликованы из приложения с использованием iOS SDK. Рекомендуем обновить версию до 2.6.122, у нас в примере Conference с этой версией на устройстве с iOS 17.2 проблема не воспроизводится.
Также рекомендуем вам исключить ретрансляцию в RTMP для записи.
Можно записывать потоки в MKV контейнер

record_formats=h264-mkv,vp8-mkv

а потом, после записи, конвертировать с помощью ffmpeg в контейнер MP4, если это необходимо.
В этом случае нагрузка на сервер снизится, т.к. уйдет излишний транскодинг.

 

[Max]

Добрый день.
В сборке 5.2.1933 мы добавили более подробное логирование старта записи. Рекомендуем обновить сервер до данной сборки. В случае, если проблема со стартом записи снова воспроизведется, дополнительные логи помогут понять причину.

 

[Max]

Добрый день.
В очередных логах мы видим, что для всех потоков, которые не записались, в серверном логе не было сообщений о получении ключевого фрейма и создании файла записи. При этом поток 190499-150046_6E72F232-92E0-4827-BBAD-EA62E4606F4B был остановлен через 8 секунд после начала публикации, остальные потоки публиковались по 30-40 секунд. Для потока 190348-84232_B09536FE-46C1-43CC-95BF-3ADD9C35AA84 в клиентском логе зафиксированы проблемы с метками времени и сбросы разрешения, что говорит о плохом качестве канала. Для потока 190240-149726_a2c095a7-82d1-472c-8927-74a8628a32e6 была запущена ретрансляция, хотя исходный поток был опубликован в кодеке H264.
Также за период, собранный в репорте, однократно была зафиксирована блокировка процессорного потока, отвечающего за запись файла на диск.
К сожалению, в репорте нет данных о системе

Однако, с учетом сценария использования (ретрансляция потокв как RTMP на тот же сервер с принудительным транскодированием в 480p), можно предположить, что производительсти CPU может не хватать для транскодинга видео, а дисковой подсистемы - для записи.
Рекомендации:
1. Обновить WCS до последней актуальной сборки
2. Взять сервер с большим числом ядер CPU, чем тот, что используется сейчас
3. Использовать SSD для записи
4. Исключить транскодинг: например, записывать потоки в MKV контейнер

record_formats=h264-mkv,vp8-mkv

и после записи конвертировать с помощью ffmpeg в контейнер MP4, если это необходимо. Нужно учесть, что конвертация при помощи ffmpeg требует значительных ресурсов CPU, поэтому следует взять либо сервер с большим числом ядер, либо вынести конфертацию на отдельный сервер.

 

[Max]

Добрый день.
В очередных логах мы видим NullPointerException в клиентских логах тех потоков, в републикации которых не было звука. К сожалению, ваши отчеты не содержат номера сборки и настроек сервера, поэтому мы воспроизвели проблему с настройками по умолчанию и создали тикет WCS-4139.
Вы можете либо откатиться на сборку 5.2.1968, в которой данная проблема не воспроизводится, либо (рекомендуемый вариант) отказаться от републикации с транскодингом в MP4 и записывать все публикации в MKV

record_formats=h264-mkv,vp8-mkv

и после записи конвертировать с помощью ffmpeg в контейнер MP4, если это необходимо. В этом случае лучше обновиться до сборки 5.2.1987, в которой скрипт on_record_hook.sh запускается асинхронно, и допускает выполнение длительных операций.
Также настоятельно рекомендуем:
- собирать полный отчет

sudo ./report.sh --sysinfo --conf --stats --tar

- при отправке отвечта отписывать в этой теме

 

[Max]

Добрый день.
По тикету WCS-4139: проблема с отсутствием звука в потоках, републикованных как RTMP, исправлена в сборке 5.2.1989.