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

dark.seer1097

New Member
Добрый день.

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

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

Max

Administrator
Staff member
Добрый день.
Проанализировали присланные логи. Все проблемные потоки были остановлены до начала записи (для этих потокв не было сообщений в логе 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

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

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
Code:
ice_tcp_transport=true
Для того, чтобы клиент регулярно отправлял ключевые фреймы, можно включить периодический запрос на стороне сервера
Code:
periodic_fir_request=true
periodic_fir_request_interval=5000
Поскольку на сервере используется JDK 17, можно для уменьшения задержек в работе Java машины под нагрузкой включить сборщик мусора ZGC: Настройка Z Garbage Collector (ZGC)
 

dark.seer1097

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

dark.seer1097

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

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
 
Last edited:

Max

Administrator
Staff member
Здравствуйте

record_stop_timeout = 15

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

record_stop_timeout =60

в конфиге flashphoner.properties
 
Last edited:

dark.seer1097

New Member
Добрый день! Поставили 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

Administrator
Staff member
Добрый день.
Во всех этих случаях выглядит так, что от клиента не получен либо получен, но не разобран ключевой кадр, поэтому не стартовала запись.
Потоки 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. Выставить настройку, это позволит более четко определять ключевые кадры в потоке видео
Code:
h264_strict_kframe_detect=true
3. Мониторить текущие публикации по REST API: Мониторинг параметров потока при помощи REST API, развернуть Prometheus и Grafana для мониторинга статистики работы сервера: 10 важных метрик WebRTC стриминга и настройка мониторинга Prometheus +Grafana
4. Проверять, стартовала ли запись потока (создан ли файл MP4.tmp), если нет, пытаться стартовать запись принудительно: Запись потоков по требованию
 

Max

Administrator
Staff member
Заметили, что большая часть из потоков, которые не записались, опубликованы из приложения с использованием iOS SDK. Рекомендуем обновить версию до 2.6.122, у нас в примере Conference с этой версией на устройстве с iOS 17.2 проблема не воспроизводится.
Также рекомендуем вам исключить ретрансляцию в RTMP для записи.
Можно записывать потоки в MKV контейнер
Code:
record_formats=h264-mkv,vp8-mkv
а потом, после записи, конвертировать с помощью ffmpeg в контейнер MP4, если это необходимо.
В этом случае нагрузка на сервер снизится, т.к. уйдет излишний транскодинг.
 

Max

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

Max

Administrator
Staff member
Добрый день.
В очередных логах мы видим, что для всех потоков, которые не записались, в серверном логе не было сообщений о получении ключевого фрейма и создании файла записи. При этом поток 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.
Также за период, собранный в репорте, однократно была зафиксирована блокировка процессорного потока, отвечающего за запись файла на диск.
К сожалению, в репорте нет данных о системе
1714355635678.png

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

Max

Administrator
Staff member
Добрый день.
В очередных логах мы видим NullPointerException в клиентских логах тех потоков, в републикации которых не было звука. К сожалению, ваши отчеты не содержат номера сборки и настроек сервера, поэтому мы воспроизвели проблему с настройками по умолчанию и создали тикет WCS-4139.
Вы можете либо откатиться на сборку 5.2.1968, в которой данная проблема не воспроизводится, либо (рекомендуемый вариант) отказаться от републикации с транскодингом в MP4 и записывать все публикации в MKV
Code:
record_formats=h264-mkv,vp8-mkv
и после записи конвертировать с помощью ffmpeg в контейнер MP4, если это необходимо. В этом случае лучше обновиться до сборки 5.2.1987, в которой скрипт on_record_hook.sh запускается асинхронно, и допускает выполнение длительных операций.
Также настоятельно рекомендуем:
- собирать полный отчет
Code:
sudo ./report.sh --sysinfo --conf --stats --tar
- при отправке отвечта отписывать в этой теме
 

Max

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