...

Поддерживаемые кодеки

• H.264
• VP8
• H265 (начиная со сборки 5.2.1579)
• AAC
• G.711
• Speex

Поддерживаемые платформы и браузеры

...

h264_check_and_skip_annexb=true

Краткое руководство по тестированию

Захват видеопотока с IP-камеры и трансляция в браузер

1. Для теста используем:

• демо-сервер demo.flashphoner.com;
• веб-приложение Player для захвата и воспроизведения потока

2. Откройте веб-приложение Player, укажите в поле "Stream" URL веб-камеры:

Image Removed

3. Нажмите кнопку "Start". Начнется трансляция захваченного потока.

Image Removed

4. Графики WebRTC internals:

Image Removed

Управление захватом видеопотока с IP-камеры при помощи REST API

Как правило, для захвата потока с IP-камеры достаточно указать URL-камеры в качестве имени потока при его создании. Однако, при необходимости, возможно управлять захватом RTSP-потока при помощи REST API.

Тестирование

1. Для теста используем:

• демо-сервер demo.flashphoner.com;
• браузер Chrome и REST-клиент для отправки запросов на сервер;
• веб-приложение Player для воспроизведения захваченного потока в браузере.

2. Откройте REST-клиент. Отправьте запрос /rtsp/startup, указав в параметрах URL веб-камеры:

Image Removed

3. Убедитесь, что поток захвачен сервером. Для этого отправьте запрос /rtsp/find_all:

Image Removed

Image Removed

4Начиная со сборки 5.2.946, данная опция удалена из настроек, и фреймы в AnnexB формате определяются и проигрываются автоматически.

Исключение аудио кодеков

В некоторых случаях, необходимо проиграть поток с камеры без аудио, либо исключить обработку аудио в некоторых кодеках, чтобы не транскодировать звук. Для этого предназначена настройка, перечисляющая кодеки, которые должны быть исключены при захвате потока с камер, например

rtsp_client_strip_audio_codecs=PCMA,PCMU

Данная настройка исключает кодеки PCMA (alaw) и PCMU (ulaw). Видео с камер, передающих звук в этих кодеках, будет проигрываться без аудио.

Кодеки исключаются на уровне SDP, по названиям.

Установка режима пакетизации H264

По умолчанию, согласно спецификации H264, если в SDP потока не указан явно режим пакетизации, он присваивается равным 0. Однако, некоторые RTSP камеры могут передавать поток, закодированный в режиме пакетизации 1, и при этом не указывать режим в SDP потока. Это приводит к включению транскодинга и снижению качества картинки в браузере Safari.

В сборке 5.2.820 добавлена возможность установить режим пакетизации по умолчанию для использования таких камер при помощи настройки

default_packetization_mode=1

Краткое руководство по тестированию

Захват видеопотока с IP-камеры и трансляция в браузер

1. Для теста используем:

• демо-сервер demo.flashphoner.com;
• веб-приложение Player для захвата и воспроизведения потока

2. Откройте веб-приложение Player, укажите в поле "Stream" URL веб-камеры и нажмите Start. Начнется воспроизведение потока в браузере:

Image Removed

5. Отправьте запрос /rtsp/terminate, указав в параметрах URL веб-камеры:

Image Removed

6. Воспроизведение потока прервется с ошибкой:

Image Removed

REST-вызовы

REST-запрос должен быть HTTP/HTTPS POST запросом в таком виде:

• HTTP: http://test.flashphoner.com:8081/rest-api/rtsp/startup
• HTTPS: https://test.flashphoner.com:8444/rest-api/rtsp/startup

Здесь:

• test.flashphoner.com - адрес WCS-сервера
• 8081 - стандартный REST / HTTP порт WCS-сервера
• 8444 - стандартный HTTPS порт
• rest-api - обязательная часть URL
• /rtsp/startup - используемый REST-метод

REST-методы и статусы ответа

...

REST-метод

...

Пример тела REST-запроса

...

Пример тела REST-ответа

...

Статусы ответа

...

Описание

...

/rtsp/startup

...

{
 "uri":"rtsp://myserver.com/live/myStream",
 "toStream": "myRTSPstream"
}

409 - Conflict

500 - Internal error

Извлечь RTSP-поток по указанному URL

...

/rtsp/find_all

:

Image Added

3. Нажмите кнопку "Start". Начнется трансляция захваченного потока.

Image Added

4. Графики WebRTC internals:

Image Added

Управление захватом видеопотока с IP-камеры при помощи REST API

Как правило, для захвата потока с IP-камеры достаточно указать URL-камеры в качестве имени потока при его создании. Однако, при необходимости, возможно управлять захватом RTSP-потока при помощи REST API.

Тестирование

1. Для теста используем:

• демо-сервер demo.flashphoner.com;
• браузер Chrome и REST-клиент для отправки запросов на сервер;
• веб-приложение Player для воспроизведения захваченного потока в браузере.

2. Откройте REST-клиент. Отправьте запрос /rtsp/startup, указав в параметрах URL веб-камеры:

Image Added

3. Убедитесь, что поток захвачен сервером. Для этого отправьте запрос /rtsp/find_all:

Image Added

Image Added

4. Откройте веб-приложение Player, укажите в поле "Stream" URL веб-камеры и нажмите Start. Начнется воспроизведение потока в браузере:

Image Added

5. Отправьте запрос /rtsp/terminate, указав в параметрах URL веб-камеры:

Image Added

6. Воспроизведение потока прервется с ошибкой:

Image Added

REST-вызовы

REST-запрос должен быть HTTP/HTTPS POST запросом в таком виде:

• HTTP: http://test.flashphoner.com:8081/rest-api/rtsp/startup
• HTTPS: https://test.flashphoner.com:8444/rest-api/rtsp/startup

Здесь:

• test.flashphoner.com - адрес WCS-сервера
• 8081 - стандартный REST / HTTP порт WCS-сервера
• 8444 - стандартный HTTPS порт
• rest-api - обязательная часть URL
• /rtsp/startup - используемый REST-метод

REST-методы и статусы ответа

{
 "uri": "rtsp://myserver.com/live/myStream",
"status": "PLAYING",
"toStream "localStreamName": "myRTSPstream"
}

{
"uri": "rtsp://myserver.com/live/myStream",
"status": "PLAYING",
"localStreamName": "myRTSPstream"
}

Параметры

{
"uri":"rtsp://myserver.com/live/myStream"
}

Параметры

...

Повторный захват потока с тем же URI

При попытке повторного захвата потока с тем же URI запрос /rtsp/startup вернет 409 Conflict. Если поток с камеры уже опубликован на сервере, необходимо подключаться к этому потоку.

Последовательность выполнения операций (Call Flow)

Ниже описана последовательность вызовов при использовании примера Player

...

По умолчанию, если параметр toStream не указан, имя формируется из URI потока. Если RTSP поток с таким URI уже был захвачен, или на сервере существует поток с указанным именем, в ответ на запрос сервер вернет 409 Conflict.

Если захваченному RSTP потоку назначено имя, этот поток может быть воспроизведен по имени в CDN (по умолчанию, для RTSP потоков эта функция недоступна, т.к. они захватываются локально).

Известные проблемы

...

5. Соединение с IP-камерой разрывается при ошибке в любом из треков (аудио или видео)

Симптомы: соединение с IP-камерой разрывается, если один из треков вернул ошибку 4**.
Решение: данное поведение включено по умолчанию. Однако, если единичные ошибки не являются критичными и не требуют прекращения трансляции, в файле flashphoner.properties необходимо указать не указан, имя формируется из URI потока. Если RTSP поток с таким URI уже был захвачен, или на сервере существует поток с указанным именем, в ответ на запрос сервер вернет 409 Conflict.

Если захваченному RSTP потоку назначено имя, этот поток может быть воспроизведен по имени в CDN (по умолчанию, для RTSP потоков эта функция недоступна, т.к. они захватываются локально).

Захват H265 RTSP  потока

В сборке 5.2.1579 добавлена возможность захвата RTSP потока, публикуемого камерой в кодеке H265. Для этого H265 должен быть добавлен в список поддерживаемых кодеков

codecs=opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,h264,vp8,flv,mpv,h265

и в списки исключений

codecs_exclude_sip=mpeg4-generic,flv,mpv,h265
codecs_exclude_sip_rtmp=opus,g729,g722,mpeg4-generic,vp8,mpv,h265
codecs_exclude_sfu=alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,flv,mpv,h265

Захваченный поток может быть проигран как WebRTC, RTMP, MSE, HLS с транскодингом и как RTSP без транскодинга

Проблема первого подписчика

До сборки 5.2.1760 RTSP потоки могли долго начинать играть у первого подписчика. Это было вызвано тем, что процесс подписчика стартовал позде процесса публикации, и мог пропускать первые ключевые кадры. В сборке 5.2.1760 это поведение изменено: процесс публикации стартует после процесса подписчика. При необходимости, можно вернуться к старому варианту при помощи настройки

agent_use_subscriber_listener=false

Исправление временных меток в потоке

В некоторых RTSP потоках временные метки могут идти не в нужном порядке, например, у двух кадров подряд может быть одинаковая метка. При проигрывании такого потока по WebRTC поток может долго не отображаться, и периодически давать серый фон. Для исправления таких временных меток, в сборке 5.2.1794 добавлена настройка

jitter_buffer_attempt_to_correct_broken_timestamp=true

В этом случае в клиентском логе будут сообщения

Non-monotonous timestamp in input stream; previous: 453424, current: 453424; changing to 453425. This may result in incorrect timestamps in the output

и проблемный поток будет играть нормально.

Известные проблемы

5. Соединение с IP-камерой разрывается при ошибке в любом из треков (аудио или видео)

Симптомы: соединение с IP-камерой разрывается, если один из треков вернул ошибку 4**.
Решение: данное поведение включено по умолчанию. Однако, если единичные ошибки не являются критичными и не требуют прекращения трансляции, в файле flashphoner.properties необходимо указать

rtsp_fail_on_error_track=false
rtp_force_synchronization=true

6. Символы в имени потока, недопустимые в URI, должны быть экранированы

Симптомы: RTSP-поток не воспроизводится с признаком ошибки 'Bad URI'
Решение: любые символы, недопустимые при указании URI, должны быть экранированы в имени потока, например

rtsp://hostname/c@@lstream/channel1

должен быть записан как

rtsp://hostname/c%40%40lstream/channel1

7. Некоторые камеры не поддерживают поле cnonce в заголовке сообщения при установке RTSP-соединения.

Симптомы: RTSP-поток играется в VLC, но не играется в WCS.

Решение: в файле flashphoner.properties установить настройку

rtsp_fail_on_error_track=false
rtp_force_synchronization=true

6. Символы в имени потока, недопустимые в URI, должны быть экранированы

Симптомы: RTSP-поток не воспроизводится с признаком ошибки 'Bad URI'
Решение: любые символы, недопустимые при указании URI, должны быть экранированы в имени потока, например

rtsp://hostname/c@@lstream/channel1

должен быть записан как

rtsp://hostname/c%40%40lstream/channel1

7. Некоторые камеры не поддерживают поле cnonce в заголовке сообщения при установке RTSP-соединения.

Симптомы: RTSP-поток играется в VLC, но не играется в WCS.

Решение: в файле flashphoner.properties установить настройку

rtsp_auth_cnonce=

с пустым значением.

8. Поток с некоторых камер не играет из-за нехватки буфера для записи RBSP

Симптомы: RTSP поток не играет, в серверном логе исключение

13:10:16,988 ERROR  BitstreamNormalizer - pool-56-thread-1 Failed to normalize SPS 674d002a95a81e0089f950
java.lang.RuntimeException: Failed to write sps rbsp

Решение: увеличить настройку размера буфера RBSP

rtsp_auth_cnonce=

с пустым значением.

8. Поток с некоторых камер не играет из-за нехватки буфера для записи RBSP

Симптомы: RTSP поток не играет, в серверном логе исключение

13:10:16,988 ERROR  BitstreamNormalizer - pool-56-thread-1 Failed to normalize SPS 674d002a95a81e0089f950
java.lang.RuntimeException: Failed to write sps rbsp

Решение: увеличить настройку размера буфера RBSP (по умолчанию 1.5)

h264_sps_rbsp_scale=2

9. Поток с некоторых камер теряет синхронизацию между аудио и видео

Симптомы: RTSP поток фризит либо не проигрывается по HLS (отдельные сегменты не записываются), в статистике для потока ненормально большое значение синхронизации

streams_synchronization=camera1/-21800;camera2/2079600704

Решение:  в сборках до 5.2.1775 увеличить буфер синхронизации для аудио и видео

audio_incoming_buffer_size=100
video_incoming_buffer_size=100

начиная со сборки 5.2.1775 увеличить интервал принудительной синхронизации для аудио и видео

video_force_sync_timeout=1000
audio_force_sync_timeout=1000