Для проведения онлайн-трансляций могут использоваться специальные аппаратные либо программные устройства видеозахвата (Live Encoder). Подобные устройства или программы захватывают видеопоток и отправляют его на сервер по протоколу RTMP.
Web Call Server может принимать RTMP видеопоток с такого устройства или ПО (Wirecast, ffmpeg, OBS Studio, FMLE и т.п.) в кодеках H.264 + AAC или Sorenson Spark + Speex и раздавать этот видеопоток на браузеры и мобильные устройства.
Ниже приводится последовательность выполнения операций при трансляции RTMP потока на WCS сервер с внешнего источника вещания (Live Encoder)
Обработка параметров, указанных в URL потокаПри публикации или воспроизведении RTMP-потока на WCS, в URL потока могут быть указаны параметры RTMP-соединения и параметры потока:
Здесь
WCS-сервер передает указанные параметры бэкенд-серверу в REST hook, в поле
Эту возможность можно использовать, например, для авторизации клиента на бэкенд-сервере при публикации или воспроизведения RTMP-потока на WCS. Передача параметров соединения как параметров потокаВ некоторых случаях возникает необходимость передать параметры соединения, например, параметры авторизации, как параметры потока, например
Эта возможность включается настройкой
В этом случае вышеприведенный пример RTMP URL будет аналогичен следующему
|
В некоторых случаях, если RTMP-кодировщик не поддерживает отсылку Keep Alive пакетов, либо этот механизм отключен по другим причинам при помощи настройки
keep_alive.algorithm=NONE |
возникает необходимость контролировать RTMP-соединения и закрывать их, если в течение длительного времени не передается никаких данных. Для этого предусмотрены следующие настройки.
Начиная со сборки 5.2.533, контроль наличия медиа данных в RTMP потоке включается при помощи настройки в файле flashphoner.properties:
flash_rtp_activity_enabled=true |
Таймаут на чтение управляется при помощи следующих параметров в файле flashphoner.properties:
rtmp.server_read_socket_timeout=120 |
В данном случае RTMP-соединение будет закрыто, если в течение 120 секунд из него не было принято никаких данных.
Таймаут на запись управляется при помощи следующего параметра
rtmp.server_write_socket_timeout=120 |
В данном случае RTMP-соединение будет закрыто, если в течение 120 секунд в него не было отправлено никаких данных.
Таймаут на чтение и запись управляется при помощи следующего параметра
rtmp.server_socket_timeout=120 |
В данном случае RTMP-соединение будет закрыто, если в течение 120 секунд из него не было принято и в него не было отправлено никаких данных.
При публикации RTMP потока на WCS, можно повернуть изображение, отправив необходимые RTMP-метаданные. Это может быть полезным для изменения ориентации картинки на лету при публикации потока с мобильного источника.
Для того, чтобы повернуть изображение на указанный угол, клиент должен прислать серверу RTMP-метаданные с полем 'orientation'. Поле может принимать следующие значения:
Значение поля | Угол поворота в градусах |
0 | 0 |
1 | 90 |
2 | 180 |
3 | 270 |
Изображение поворачивается по часовой стрелке.
Поворот изображения по метаданным включается при помощи следующей настройки в файле flashphoner.properties:
video_filter_enable_rotate=true |
Отметим, что поворот изображения работает только при использовании транскодирования.
1. Для теста используем:
2. Откройте приложение Flash Streaming. Введите имя потока test, укажите желаемые параметры публикации потока
3. Нажмите Login, затем Start. Начнется публикация потока
4. Откройте в другой вкладке или в другом браузере приложение Player, воспроизведите поток test
5. В приложении Flash Player нажмите кнопку 180 в разделе Rotate camera. В приложении Player отобразится изображение, повернутое на 180 градусов по часовой стрелке
Отправка метаданных для поворота изображения реализована в приложении Flash Player следующим образом:
private function rotate(degree:Number):void { var metaDataObj:Object = new Object(); switch(degree) { case 0: Logger.info("rotate camera to 0"); metaDataObj.orientation = 0; break; case 90: Logger.info("rotate camera to 90"); metaDataObj.orientation = 1; break; case 180: Logger.info("rotate camera to 180"); metaDataObj.orientation = 2; break; case 270: Logger.info("rotate camera to 270"); metaDataObj.orientation = 3; break; default: metaDataObj.orientation = 0; break; } sendMetaData(metaDataObj); } private function sendMetaData(data:Object):void{ if (publishStream != null) { publishStream.send("@setDataFrame", "onMetaData", data); } } |
Обратите внимание, что отправляется не угол, а соответствующее значение поля orientation.
RTMP кодировщик ffmpeg дает возможность отправить метаданные ориентации изображения серверу при помощи ключей командной строки:
ffmpeg -i input.mp4 -metadata:s:v rotate=90 -vcodec copy -acodec copy -strict -2 -f flv rtmp://test1.flashphoner.com:1935/live/stream_ffmpeg |
Отметим, что настройка поворота для ffmpeg указывается в градусах, при этом на сервер передается соответствующее значение поля orientation.
Если RTMP поток публикуется программным кодировщиком с поддержкой аппаратного ускорения на GPU NVIDIA, и содержит B-фреймы, при проигрывании такого потока по RTMP или HLS в некоторых плеерах картинка подергивается. В связи с этим, в сборке 5.2.863 была добавлена настройка, которая задает максимальный размер буфера декодирования, передаваемый в SPS
h264_sps_max_dec_frame_buffering=-1 |
По умолчанию, размер буфера не ограничен. Это убирает подергивания картинки, но может приводить к задержкам при излишней буферизации. В этом случае, можно ограничить буфер двумя кадрами (значение по умолчанию до сборки 5.2.863)
h264_sps_max_dec_frame_buffering=2 |
или большим числом, чтобы убрать подергивания картинки и не допустить задержки.
При публикации RTMP потока в большом разрешении, с высоким битрейтом при нестабильном канале поток может играть по WebRTC не плавно, с фризами или снижением FPS. Чтобы предотвратить такое поведение, необходимо буферизовать входящий поток
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 добавлена настройка для отключения буферизации и пропуска полученного трафика напрямую в движок сервера
rtmp_in_buffer_input_delay_threshold=0 |
По умолчанию, при включенной буферизации RTMP трафик будет всегда помещаться в буфер. Буферизация может быть отключена при достижении определенного значения задержки в миллисекундах
rtmp_in_buffer_input_delay_threshold=3000 |
При этом буфер освобождается и переходит в статус PASSTHROUGH
. Даже если задержка затем снизится, буфер останется в таком статусе. и поток не будет буферизоваться до окончания публикации.
По умолчанию, возможные параметры публикуемого RTMP потока определяются файлом настройки SDP. В сборке 5.2.1862 добавлена настройка, которая включает автоматическое определение параметров публикуемого потока по метаданным или по информации в медиапакетах
flash_detect_metadata_by_traffic=true |
Настройка включена по умолчанию. В этом случае WCS корректирует SDP в соотвествии с полученными от публикующего клиента метаданными или, если их нет в течение 1 секунды, по информации из полученных медиапакетов.
5. Некоторые функции RTMP не поддерживаются и будут игнорированы:
6. Не все RTMP-кодировщики поддерживают KeepAlive.
Симптомы: частые разрывы соединения при публикации потока с RTMP-кодировщика.
Решение: отключить KeepAlive для RTMP на сервере при помощи настройки в файле flashphoner.properties
keep_alive.enabled=websocket,rtmfp |
7. При воспроизведении потока, публикуемого из RTMP-кодировщика, как HLS, могут наблюдаться фризы, если GOP не кратен частоте кадров публикуемого файла
Симптомы: при воспроизведении RTMP-потока как HLS наблюдаются фризы
Решение: установить в параметрах кодировщика GOP равный или кратный частоте кадров публикуемого файла. Например, если публикуется файл с fps 25, необходимо указать GOP 50.
8. При воспроизведении потока, опубликованного из RTMP кодировщика, как WebRTC, звук в потоке низкого качества
Симптомы: при воспроизведении RTMP потока как WebRTC звук подходит для передачи речи, но не музыки
Решение: установить настройку битрейта кодирования в Opus в соответствии с битрейтом публикации звука, например
opus.encoder.bitrate=160000 |
если звук в RTMP потоке публикуется с битрейтом 160 кбит/с.
9. При публикации RTMP потока H264+speex (например, при помощи Flash) большая нагрузка на процессор при транскодинге звука
Симптомы: большая нагрузка на процессор при транскодинге звука из speex в AAC или Opus
Решение: использовать нативную реализацию декодера speex
use_speex_java_impl=false |
10. Поток с неподдерживаемым аудио или видео кодеком не может быть опубликован
Симптомы: RTMP поток c MP3 или AC3 аудио не публикуется, в логе сервера сообщения
11:01:00,921 WARN ServerHandler - RTMP-pool-15-thread-1 Codecs not supported! audio: NoCodec, video: NoCodec |
Решение: перекодировать поток к поддерживаемым кодекам при публикации при помощи соответствующих настроек кодировщика