Проблемы с конвертацией из 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 мы добавили более подробное логирование старта записи. Рекомендуем обновить сервер до данной сборки. В случае, если проблема со стартом записи снова воспроизведется, дополнительные логи помогут понять причину.