...
Для проведения онлайн-трансляций могут использоваться специальные аппаратные либо программные устройства видеозахвата (Live Encoder). Подобные устройства или программы захватывают видеопоток и отправляют его на сервер по протоколу RTMP.
Web Call Server 5.1 может принимать RTMP видеопоток с такого устройства или ПО (Wirecast, ffmpeg, OBS Studio, FMLE и т.п.) в кодеках H.264 + AAC или Sorenson Spark + Speex и раздавать этот видеопоток на браузеры и мобильные устройства.
...
- Прием входящих аудио / видеопотоков по протоколу RTMP
- Раздача полученного видеопотока на браузеры и платформы: любая из поддерживаемых WCS
- Использование технологий воспроизведения видеопотока: любая из поддерживаемых WCS
Поддержка кодеков
- Видео H.264 + аудио AAC
- Видео Sorenson Spark + аудио Speex 16 kHz
...
| Excerpt Include | ||||||
|---|---|---|---|---|---|---|
|
...
Контроль получения медиа данных по RTMP
В некоторых случаях, если RTMP-кодировщик не поддерживает отсылку Keep Alive пакетов, либо этот механизм отключен по другим причинам при помощи настройки
...
возникает необходимость контролировать RTMP-соединения и закрывать их, если в течение длительного времени не передается никаких данных. Для этого предусмотрены следующие настройки.
Таймаут на чтение данных
...
Контроль наличия медиа данных в потоке
Начиная со сборки 5.2.533, контроль наличия медиа данных в RTMP потоке включается при помощи настройки в файле flashphoner.properties:
| Code Block | ||
|---|---|---|
| ||
rtmp.serverflash_readrtp_socketactivity_timeoutenabled=120true |
Таймаут на чтение данных
Таймаут на чтение управляется при помощи следующих параметров в файле flashphoner.properties:
| Code Block | ||
|---|---|---|
| ||
rtmp.server_read_socket_timeout=120 |
В данном случае RTMP-соединение будет закрыто, если в течение 120 секунд из него не было принято никаких данных.
...
Отметим, что настройка поворота для ffmpeg указывается в градусах, при этом на сервер передается соответствующее значение поля orientation.
Известные проблемы
...
5. Некоторые функции RTMP не поддерживаются и будут игнорированы:
- FCSubscribe
- FCPublish
- FCUnpublish
- onStatus
- onUpstreamBase
- releaseStream
6. Не все RTMP-кодировщики поддерживают KeepAlive.
Симптомы: частые разрывы соединения при публикации потока с RTMP-кодировщика.
Решение: отключить KeepAlive для RTMP на сервере при помощи настройки в файле flashphoner.properties
| Code Block | ||||
|---|---|---|---|---|
| ||||
keep_alive.enabled=websocket,rtmfp |
7. При воспроизведении потока, публикуемого из RTMP-кодировщика, как HLS, могут наблюдаться фризы, если GOP не кратен частоте кадров публикуемого файла
Симптомы: при воспроизведении RTMP-потока как HLS наблюдаются фризы
...
Управление размером буфера при декодировании
Если RTMP поток публикуется программным кодировщиком с поддержкой аппаратного ускорения на GPU NVIDIA, и содержит B-фреймы, при проигрывании такого потока по RTMP или HLS в некоторых плеерах картинка подергивается. В связи с этим, в сборке 5.2.863 была добавлена настройка, которая задает максимальный размер буфера декодирования, передаваемый в SPS
| Code Block | ||
|---|---|---|
| ||
h264_sps_max_dec_frame_buffering=-1 |
По умолчанию, размер буфера не ограничен. Это убирает подергивания картинки, но может приводить к задержкам при излишней буферизации. В этом случае, можно ограничить буфер двумя кадрами (значение по умолчанию до сборки 5.2.863)
| Code Block | ||
|---|---|---|
| ||
h264_sps_max_dec_frame_buffering=2 |
или большим числом, чтобы убрать подергивания картинки и не допустить задержки.
Буферизация входящего RTMP потока
При публикации RTMP потока в большом разрешении, с высоким битрейтом при нестабильном канале поток может играть по WebRTC не плавно, с фризами или снижением FPS. Чтобы предотвратить такое поведение, необходимо буферизовать входящий поток
| Code Block | ||
|---|---|---|
| ||
rtmp_in_buffer_enabled=true |
Адаптивный буфер для входящего RTMP потока имеет следующие тонкие настройки:
| Параметр | Описание | Значение по умолчанию |
|---|---|---|
| rtmp_in_buffer_start_size | Исходный объем буфера, мс | 300 |
| rtmp_in_buffer_initial_size | Максимальный объем буфера, мс | 2000 |
| rtmp_in_buffer_max_bufferings_allowed | Максимальное количество увеличений буфера | -1 (не ограничено) |
| rtmp_in_buffer_polling_time | Периодичность проверки наличия данных в буфере, мс | 100 |
| rtmp_in_buffer_overflow_allowed_deviation | Максимально допустимая разность между минимальном и максимальным объемами буфера, мс | 1000 |
| rtmp_in_buffer_overflow_deviation_window | Размер окна, в течение которого отслеживается разность, мс | 30000 |
| rtmp_in_buffer_overflow_rate | Максимально допустимая частота переполнений буфера | 0.15 |
| rtmp_in_buffer_clear_threshold | При наполнении буфера до указанной величины, сбросить все данные, объем которых превышает максимальный, мс | 30000 |
Прекращение буферизации потока при ухудшении его характеристик
Если программному RTMP кодировщику не хватает производительности системы, на которой он запущен, или не хватает пропускной способности канала, метки времени в пакетах могут давать задержку относительно времени сервера. Буферизация такого потока будет давать периодические фризы при проигрывании. Поэтому в сборке 5.2.1311 добавлена настройка для отключения буферизации и пропуска полученного трафика напрямую в движок сервера
| Code Block | ||
|---|---|---|
| ||
rtmp_in_buffer_input_delay_threshold=0 |
По умолчанию, при включенной буферизации RTMP трафик будет всегда помещаться в буфер. Буферизация может быть отключена при достижении определенного значения задержки в миллисекундах
| Code Block | ||
|---|---|---|
| ||
rtmp_in_buffer_input_delay_threshold=3000 |
При этом буфер освобождается и переходит в статус PASSTHROUGH . Даже если задержка затем снизится, буфер останется в таком статусе. и поток не будет буферизоваться до окончания публикации.
Определение параметров публикуемого потока по метаданным или медиапакетам
По умолчанию, возможные параметры публикуемого RTMP потока определяются файлом настройки SDP. В сборке 5.2.1862 добавлена настройка, которая включает автоматическое определение параметров публикуемого потока по метаданным или по информации в медиапакетах
| Code Block | ||
|---|---|---|
| ||
flash_detect_metadata_by_traffic=true |
Настройка включена по умолчанию. В этом случае WCS корректирует SDP в соотвествии с полученными от публикующего клиента метаданными или, если их нет в течение 1 секунды, по информации из полученных медиапакетов.
Известные проблемы
| Excerpt Include | ||||||
|---|---|---|---|---|---|---|
|
5. Некоторые функции RTMP не поддерживаются и будут игнорированы:
- FCSubscribe
- FCPublish
- FCUnpublish
- onStatus
- onUpstreamBase
- releaseStream
6. Не все RTMP-кодировщики поддерживают KeepAlive.
Симптомы: частые разрывы соединения при публикации потока с RTMP-кодировщика.
Решение: отключить KeepAlive для RTMP на сервере при помощи настройки в файле flashphoner.properties
| Code Block | ||||
|---|---|---|---|---|
| ||||
keep_alive.enabled=websocket,rtmfp |
7. При воспроизведении потока, публикуемого из RTMP-кодировщика, как HLS, могут наблюдаться фризы, если GOP не кратен частоте кадров публикуемого файла
Симптомы: при воспроизведении RTMP-потока как HLS наблюдаются фризы
Решение: установить в параметрах кодировщика GOP равный или кратный частоте кадров публикуемого файла. Например, если публикуется файл с fps 25, необходимо указать GOP 50.
8. При воспроизведении потока, опубликованного из RTMP кодировщика, как WebRTC, звук в потоке низкого качества
Симптомы: при воспроизведении RTMP потока как WebRTC звук подходит для передачи речи, но не музыки
Решение: установить настройку битрейта кодирования в Opus в соответствии с битрейтом публикации звука, например
| Code Block | ||
|---|---|---|
| ||
opus.encoder.bitrate=160000 |
если звук в RTMP потоке публикуется с битрейтом 160 кбит/с.
9. При публикации RTMP потока H264+speex (например, при помощи Flash) большая нагрузка на процессор при транскодинге звука
Симптомы: большая нагрузка на процессор при транскодинге звука из speex в AAC или Opus
Решение: использовать нативную реализацию декодера speex
| Code Block | ||
|---|---|---|
| ||
use_speex_java_impl=false |
10. Поток с неподдерживаемым аудио или видео кодеком не может быть опубликован
Симптомы: RTMP поток c MP3 или AC3 аудио не публикуется, в логе сервера сообщения
| Code Block | ||
|---|---|---|
| ||
11:01:00,921 WARN ServerHandler - RTMP-pool-15-thread-1 Codecs not supported! audio: NoCodec, video: NoCodec |
Решение: перекодировать поток к поддерживаемым кодекам при публикации при помощи соответствующих настроек кодировщика