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