Долгое получение видеопотока 4К от камеры Axis

[kodmis]

Здравствуйте,

Подскажите, какие настройки поменять на сервере или камере, чтобы видеопоток открывался быстрее. Сейчас при тестировании в примере client2/examples/demo/streaming/player/player.html после нажания кнопки Play видеопоток отображается через 20-25 секунд. Камера, сервер и плейер в одной локальной сети. Камера AXIS Q3518 Fixed Dome Network Camera.

Приложен лог сообщения обмена браузер-сервер из devTools chrome.

 

[Max]

Добрый день,

Попробуйте в настройках H.264 на камере задать интервал ключевых кадров (keyframe interval или gop) - например, 60 или 30.

 

[kodmis]

Спасибо. Буду искать такую настройку в софте камеры. С ходу не нашел:

 

[kodmis]

Кстати, при запуске плейера с просмотром видео неожиданно на сервере запускается транскодер :

-----Transcoding info-----
transcoding_video_decoding_resolutions=3840x2160/1
transcoding_video_decoding_average_time=3840x2160/70.0
transcoding_video_decoding_max_time=3840x2160/70
transcoding_video_decoding_average_queue_size=3840x2160/123.0
transcoding_video_decoding_max_queue_size=3840x2160/123
transcoding_video_decoding_load=182476800
transcoding_video_encoding_resolutions=0x0/1
transcoding_video_encoding_average_time=0x0/0.0
transcoding_video_encoding_max_time=0x0/0
transcoding_video_encoding_average_queue_size=0x0/0.0
transcoding_video_encoding_max_queue_size=0x0/0
transcoding_video_encoding_load=0

 

[kodmis]

И еще. Если при тех же настройках видеокамеры с помощью WEB SDK создавать поток с указанием разрешения, то видео на странице отображатеся мгновенно:

const options = {
        name: streamConfig.url,
        constraints: {
          audio: false,
          video: {
            width: 3840,
            height: 2160
          }
        },
        display: document.getElementById(streamContainerId)
      };

      stream = session
        .createStream(options)
        .on(window.config.STREAM_STATUS.PENDING, (stream) => {
          const video = document.getElementById(stream.id());
          if (!video.hasListeners) {
            video.hasListeners = true;
            video.addEventListener('resize', (event) => window.resizeVideo(event.target));
            if (window.config.AUTO_RESIZE) {
              window.addEventListener('resize', () => window.resizeVideo(video));
            }
          }

Приложен лог сообщения обмена браузер-сервер из devTools chrome при указании требуемого разрешения.
Правда при этом запускается транскодер и на сервере процесс с java съедает до 300% CPU. Поэтому указания разрешения для плейера хочется избежать:

-----Transcoding info-----
transcoding_video_decoding_resolutions=3840x2160/1
transcoding_video_decoding_average_time=3840x2160/77.0
transcoding_video_decoding_max_time=3840x2160/77
transcoding_video_decoding_average_queue_size=3840x2160/300.0
transcoding_video_decoding_max_queue_size=3840x2160/300
transcoding_video_decoding_load=190771200
transcoding_video_encoding_resolutions=0x0/1;3840x2160/1
transcoding_video_encoding_average_time=0x0/0.0;3840x2160/57.0
transcoding_video_encoding_max_time=0x0/0;3840x2160/57
transcoding_video_encoding_average_queue_size=0x0/0.0;3840x2160/0.0
transcoding_video_encoding_max_queue_size=0x0/0;3840x2160/0
transcoding_video_encoding_load=190771200

 

[Max]

Кстати, при запуске плейера с просмотром видео неожиданно на сервере запускается транскодер :

Если Вы не указываете явно разрешение для плеера, и не устанавливали настройку

disable_streaming_proxy=true

то транскодинг запускаться не должен. Проверьте, пожалуйста, количество кодировщиков на странице статистики WCS http://wcs:8081/?action=stat

native_resources.video_encoders=0

Если это значение отличается от 0, то транскодинг видео есть.

Правда при этом запускается транскодер и на сервере процесс с java съедает до 300% CPU. Поэтому указания разрешения для плейера хочется избежать:

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

Спасибо. Буду искать такую настройку в софте камеры. С ходу не нашел:

Возможно, настройка P-кадры задает количество P-кадров между двумя I-кадрами (которые и есть ключевые)
Также рекомендуем установить явно частоту кадров (не 0, а 25 или 30) и ограничить битрейт исходящего потока (для 4K достаточно 7-10 Мбит/с).

 

[kodmis]

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

Я понимаю, что при указании требуемого разрешения в плейере запускается транскодинг. Поэтому не указываю разрешение при проигрывании, чтобы не нагружать впустую сервер. Я привел пример проигрывания с разрешением, чтобы продемонстрировать, что при этом видеопоток от камеры 4К отображается на странице мгновенно... в отличии от предыдущего примера с демо плейером, в котором разрешение при проигрывании не указывается, но поток на странице отображается спустя 25 секунд после нажатия кнопки play.

Поэкспериментирую с указанными вами настройками камеры, о результатах сообщу.

 

[Max]

Поэкспериментирую с указанными вами настройками камеры, о результатах сообщу.

Если изменение настроек не даст результата, нам потребуется SSH доступ к серверу и доступ к RTSP потоку камеры. Отправить доступы к серверу можно через эту форму, доступ к потоку камеры через эту форму.

 

[kodmis]

Спасибо за помощь. Изменение настроек камеры не помогло. Помог переход на WebRTC через TCP при воспроизведении. Проблема с долгим получение потока наблюдалась при дефолтном UDP транспорте. На TCP же и фризы пропали и поток отображается практически мгновенно после начала воспроизведения.
При настройке WebRTC через TCP ориентировался на статью в документации: https://docs.flashphoner.com/pages/viewpage.action?pageId=9241525 . В ней упоминаются параметры ice_tcp_send_buffer_size , ice_tcp_receive_buffer_size , ice_tcp_channel_high_water_mark и ice_tcp_channel_low_water_mark с магическими числами . Подскажите заклинание, которое поможет рассчитать эти числа. Исходные данные: 16 вебкамер 4К по RTSP и до 10 клиентов по WebRTC в локальной сети плюс отправка в CDN; клиент может проигрывать от одного до 16 потоков с камер.

 

[Max]

В ней упоминаются параметры ice_tcp_send_buffer_size , ice_tcp_receive_buffer_size , ice_tcp_channel_high_water_mark и ice_tcp_channel_low_water_mark с магическими числами . Подскажите заклинание, которое поможет рассчитать эти числа. Исходные данные: 16 вебкамер 4К по RTSP и до 10 клиентов по WebRTC в локальной сети плюс отправка в CDN; клиент может проигрывать от одного до 16 потоков с камер.

Эти параметры не рекомендуется менять, они выбраны по умолчанию именно для случая стриминга 4K потоков и относятся к буферизации отправляемых и принимаемых пакетов на стороне сервера.
Исходя из приведенных исходных данных, пропускная способность локальной сети должна быть не ниже 10 Гбит/с на стороне сервера и не ниже 1 Гбит/с на стороне клиентов. Например, если битрейт одного потока составляет 5 Мбит/с, 16 потоков выберут 90 Мбит/с. Канал до внешней CDN должен быть не менее 500 Мбит/с.

 

[kodmis]

Про параметры понятно. Про требования к сети непонятно. У меня не складывается связь между потребляемым клиентом трафиком и требуемой пропускной смопсобность сети у клиента. Как вы перешли от " битрейт одного потока составляет 5 Мбит/с, 16 потоков выберут 90 Мбит/с. " к "пропускная способность локальной сети должна быть не ниже 10 Гбит/с на стороне сервера и не ниже 1 Гбит/с на стороне клиентов " ?

 

[Max]

Про требования к сети непонятно. У меня не складывается связь между потребляемым клиентом трафиком и требуемой пропускной смопсобность сети у клиента. Как вы перешли от " битрейт одного потока составляет 5 Мбит/с, 16 потоков выберут 90 Мбит/с. " к "пропускная способность локальной сети должна быть не ниже 10 Гбит/с на стороне сервера и не ниже 1 Гбит/с на стороне клиентов " ?

Поскольку мы оцениваем пропускную способность локальной сети, предположим, что среда передачи полностью прозрачна, и определим минимально необходимую пропускную способность адаптера. Как правило, физические сетевые адаптеры выпускаются со следующей максимальной пропускной способностью: 100 Мбит/с (в широкой доступности таких уже нет), 1 Гбит/с, 10 Гбит/с.
На стороне клиента: 16 потоков фактически выбирают 100 Мбит/с, поэтому на клиенте нужно ставить следующий адаптер в линейке, т.е. 1 Гбит/с
На стороне сервера: один клиент выбирает 100 Мбит/с, планируется до 10 клиентов, итого уже 1 Гбит/с требуется только под клиентские подключения. Плюс захватить собственно 16 RTSP потоков (еще 100 Мбит/с), плюс отдать эти же потоки каким-то образом (например, по RTMP) во внешнюю CDN (еще 100 Мбит/с). Получается, что на сервере нужно ставить адаптеры 10 Гбит/с.
В реальных условиях канал между камерой и сервером, между клиентом и сервером, между сервером и точкой входа внешней CDN нужно оценивать от точки до точки, измеряя пропускную способность при помощи iperf, например, по этой методике. Поскольку для 4К потоков используется TCP, то и измерять нужно по TCP (пример приведен для UDP, который используется в WebRTC по умолчанию).
Измерив реальную пропускную способность канала, можно, например, снизить битрейт публикации под канал.

 

[kodmis]

2Max, спасибо!