Стрим 60fps - не поддерживается?

[extr]

Пробуем транслировать rtmp поток через XSplit Broadcaster 1080p@60fps (bframes-0)
Через несколько минут воспроизведения появляются артефакты и лаги
На сервере в логах сыпется варнинг:

09:00:51,611 WARN        VideoProcessor - VideoProcessor-5fb6f8b2-d026-432e-b7f5-bac1d980aa0c Encoding fails to keep up with decoding and decoder coded video frames queue is about to overflow, keep decoding instead of dropping frames
, queueSize 300 maxQueueSize 300 encoderQueueSizeAllowed 5
09:00:51,615 WARN        VideoProcessor - VideoProcessor-5fb6f8b2-d026-432e-b7f5-bac1d980aa0c Encoding fails to keep up with decoding and decoder coded video frames queue is about to overflow, keep decoding instead of dropping frames
, queueSize 299 maxQueueSize 300 encoderQueueSizeAllowed 5
09:00:51,623 WARN        VideoProcessor - VideoProcessor-5fb6f8b2-d026-432e-b7f5-bac1d980aa0c Encoding fails to keep up with decoding and decoder coded video frames queue is about to overflow, keep decoding instead of dropping frames
, queueSize 298 maxQueueSize 300 encoderQueueSizeAllowed 5
09:00:51,629 WARN        VideoProcessor - VideoProcessor-5fb6f8b2-d026-432e-b7f5-bac1d980aa0c Encoding fails to keep up with decoding and decoder coded video frames queue is about to overflow, keep decoding instead of dropping frames
, queueSize 297 maxQueueSize 300 encoderQueueSizeAllowed 5
09:00:51,636 WARN        VideoProcessor - VideoProcessor-5fb6f8b2-d026-432e-b7f5-bac1d980aa0c Encoding fails to keep up with decoding and decoder coded video frames queue is about to overflow, keep decoding instead of dropping frames
, queueSize 296 maxQueueSize 300 encoderQueueSizeAllowed 5
09:00:51,642 WARN        VideoProcessor - VideoProcessor-5fb6f8b2-d026-432e-b7f5-bac1d980aa0c Encoding fails to keep up with decoding and decoder coded video frames queue is about to overflow, keep decoding instead of dropping frames
, queueSize 295 maxQueueSize 300 encoderQueueSizeAllowed 5
09:00:51,712 WARN        VideoProcessor - VideoProcessor-5fb6f8b2-d026-432e-b7f5-bac1d980aa0c Encoding fails to keep up with decoding and decoder coded video frames queue is about to overflow, keep decoding instead of dropping frames
, queueSize 300 maxQueueSize 300 encoderQueueSizeAllowed 5

Возможно ли как-то исправить положение?

 

[Max]

Добрый день.
Судя по приведенному логу, у вас работает транскодинг потока, и кодировщик не успевает закодировать все кадры, из-за чего растут очереди декодера. Проблему можно решить двумя способами:
1. Не использовать транскодинг для таких потоков (в случае проигрывания по WebRTC, не менять при проигрывании параметры потока, такие как разрешение, FPS, битрейт)
2. Если транскодинга не удается избежать (например, используется RTMP push на другой сервер, либо транскодинг на сервере включен принудительно, либо поток необходимо очистить от B-фреймов), необходимо заменить сервер на более мощный, из расчета одно ядро CPU на один входящий поток 1080p + минимум два ядра на все прочие задачи, памяти при этом желательно не менее 64 Гб.
В связи с этим уточните, пожалуйста, какой сервер у Вас используется, либо предоставьте к нему доступ на почту support@flashphoner.com, наши инженеры проверят параметры сервера и настройку WCS.

 

[extr]

В связи с этим уточните, пожалуйста, какой сервер у Вас используется, либо предоставьте к нему доступ на почту support@flashphoner.com, наши инженеры проверят параметры сервера и настройку WCS.

Max, это выделенный сервер для тестов, на нем нет нагрузки, железо не топовое, но один поток 60fps должен обрабатывать.
24 ядра Intel(R) Xeon(R) CPU E5-2620 v4, 16Гб по памяти 1Гб сеть.
Force transcoding disabling - конечно-же решает проблему, но это не выход.
По поводу доступа, переговорю с админами.

> используется RTMP push на другой сервер
Да используется, после старта как-раз начинается беда в лог.
Вопрос: можно какой-либо настойкой отключить транскодинг RTMP входа, при этом оставить транскодинг потоков WEBRTC?

 

[Max]

Вопрос: можно какой-либо настойкой отключить транскодинг RTMP входа, при этом оставить транскодинг потоков WEBRTC?

Сейчас транскодинг для ретрансляции любого потока как RTMP на другой сервер включается всегда, по этому поводу есть тикет WCS-2457, он не находится в числе приоритетных.

24 ядра Intel(R) Xeon(R) CPU E5-2620 v4, 16Гб по памяти 1Гб сеть.

Согласно спецификации Intel, у этого процессора 8 ядер, 16 потоков. Возможно, у Вас их несколько на сервере?

 

[Axel]

Сейчас транскодинг для ретрансляции любого потока как RTMP на другой сервер включается всегда, по этому поводу есть тикет WCS-2457, он не находится в числе приоритетных.

Очень хотелось бы, что бы приоритет поднялся, для нас это актуально.

 

[extr]

Сейчас транскодинг для ретрансляции любого потока как RTMP на другой сервер включается всегда, по этому поводу есть тикет WCS-2457, он не находится в числе приоритетных.

транскодинг - очень дорогая операция, в конкретном случае она не имеет смысла или я ошибаюсь?
Эксперимента ради я запустил трансляцию на ваш demo wcs5-eu и создал ретрансляцию на наш сервер
воспроизведение исходного потока выглядит лучше чем у нас.
а вот воспроизведение рестрансляции тормозит. (возможно проблема сети)
полагаю, на вашем сервере в логах нет варнингов на медленный кодировщик, верно?

Согласно спецификации Intel, у этого процессора 8 ядер, 16 потоков. Возможно, у Вас их несколько на сервере?

да несколько проц, 32 ядра на этой машине, я ошибси

 

[Max]

воспроизведение исходного потока выглядит лучше чем у нас.

Если Вы играете исходный поток (по WebRTC, или забираете по RTMP в VLC), транскодинга не будет, как максимум, будет транскодинг звука, а это значительно менее ресурсоемкая операция.

транскодинг - очень дорогая операция, в конкретном случае она не имеет смысла или я ошибаюсь?

Да, не имеет - вы публикуете RTMP H264 поток и ретранслируете такой же поток далее. В связи с этим, мы подняли приоритет тикета WCS-2457, чтобы убрать транскодинг там, где он не нужен.

 

[extr]

Если Вы играете исходный поток (по WebRTC, или забираете по RTMP в VLC), транскодинга не будет, как максимум, будет транскодинг звука, а это значительно менее ресурсоемкая операция.

Да, теперь осталось понять почему на нашем железе, страдает даже исходный поток. Отправил вам письмо.

Да, не имеет - вы публикуете RTMP H264 поток и ретранслируете такой же поток далее. В связи с этим, мы подняли приоритет тикета WCS-2457, чтобы убрать транскодинг там, где он не нужен.

Отлично.

 

[Max]

Добрый день.
Мы посмотрели Ваш сервер.
Рекомендуем выделить больше памяти под Java heap, с настройками по умолчанию будет часто работать сборщик мусора (GC), что приводит к остановке Java машины на время его работы и может затрагивать производительность. В вашем случае можно выделить 8 Гб, установив настройку в wcs-core.properties

-Xmx8g
-Xms8g

Также рекомендуем убрать настройки

rtmp_in_buffer_enabled=true
rtmp_in_buffer_initial_size=2000

из flashphoner.properties, т.к. в последних сборках в них нет необходимости
Кроме того, рекомендуем проверить канал от публикующей стороны (XSplit) до сервера с использованием iperf. Проверять нужно TCP канал, т.к. для публикации RTMP потока используется TCP. Пропускная способность канала должна превышать битрейт потока.
Если Вы забираете поток с сервера по WebRTC без транскодинга, канал до зрителя можно проверить по этой методике.

 

[extr]

Добрый день!
Внесение изменений в настройки по рекомендации, никак не повлияло на проблему.

Добрый день.
Кроме того, рекомендуем проверить канал от публикующей стороны (XSplit) до сервера с использованием iperf. Проверять нужно TCP канал, т.к. для публикации RTMP потока используется TCP. Пропускная способность канала должна превышать битрейт потока.
Если Вы забираете поток с сервера по WebRTC без транскодинга, канал до зрителя можно проверить по этой методике.

Каким образом проблема канала, может повлиять на rtmp-push поток (без ретрансляции исходный поток воспроизводится прекрасно)?
Я не думаю что проблема в канале XSplit > WCS, ретрансляция идет localhost. Собака зарыта где-то в транскодинге...
Приемник ретрансляции тоже запускает транскодинг на этой машине.
Не смотря на то, что ресурсов достаточно, скорость кодировщика падает именно на WCS.
Если ретрансляция запускается на другую машину то проблема уходит. Какое-то нарушение изоляции

 

[Max]

По отключению транскодинга мы работаем в рамках тикета WCS-2457.
Просим дать нам возможность публиковать на сервер RTMP поток, в настоящее время мы этого сделать не можем с диагнозом "Operation not permitted". Другой вариант - опубликуйте поток на сервер в режиме 24x7. Это требуется для того, чтобы мы могли запускать ретрансляцию и наблюдать за поведением сервера.

 

[Max]

Мы опубликовали поток 1080p 60fps на Ваш сервер из XSplit 3.9 и запустили ретрансляцию на кодировщик. Поток от кодировщика воспроизводится в VLC плавно, устойчивый рост очередей не наблюдается как по данным статистики, так и в логах сервера, при этом нагружено, как правило, одно ядро CPU.
Пожалуйста, уточните следующее:
- какие настройки XSplit используются Вами при воспроизведении проблемы?
- какой контент публикуется из XSplit (экран, ролик, RTSP камера)?
- какими еще задачами, кроме WCS и кодировщика, загружен сервер во время тестов?
Если ответы содержат конфиденциальную информацию, можете направить их на support@flashphoner.com

 

[extr]

Добрый день, отправил письмом

 

[extr]

Добрый день!
Max, удалось воспроизвести проблему или нет?

 

[Max]

Добрый день.
Мы воспроизвели проблему, когда републиковали поток из WCS на Ваш кодировшик в режиме кодирования в 1080p. В этом случае Ваш кодировщик сильно нагружает CPU (вчетверо больше, чем занимает WCS при транскодировании потока, вещаемого с указанными Вами параметрами). Если републиковать поток, не указывая профиль кодирования, либо републиковать поток на сам WCS, рост очередей не наблюдается, потоки, как входящий, так и транскодированный, играют плавно (с учетом канала до оконечного устройства, на котором запущен VLC)
Таким образом, рекомендации будут следующими:
1. Настраивать Ваш кодировщик, чтобы снизить потребление процессора
2. Выносить Ваш кодировщик на отдельный сервер

 

[extr]

Добрый день!

вчетверо больше, чем занимает WCS при транскодировании потока, вещаемого с указанными Вами параметрами

Все верно, запускается 4 потока на ABR транскод (240p, 480p, 720p, 1080p)

1. Настраивать Ваш кодировщик, чтобы снизить потребление процессора

У него особо настраивать нечего для снижения потребления, libx264, superfast
Мне кажется это немного странным, сторонний кодировщик успевает, а кодировщик на wcs не совсем.
Свободные ресурсы ведь еще имеются (LA:5 ~20%)

Спасибо.

 

[Max]

Добрый день.

У него особо настраивать нечего для снижения потребления, libx264, superfast

В этом случае можно еще попробовать запускать WCS с повышенным приоритетом при помощи nice или развести WCS и кодировщик по ядрам через CPU affinity.
Если это не поможет, тогда только выносить тяжелый транскодинг на отдельный сервер.
Или еще один вариант - транскодировать поток при помощи самого WCS, создавая транскодеры по соответствующим профилям при помощи REST API

 

[extr]

> Если это не поможет, тогда только выносить тяжелый транскодинг на отдельный сервер.
Скорее всего будем рассматривать близкие варианты
> Или еще один вариант
Думал про этот вариант, но запинка в том что кодировщик пушит новые потоки rtmp дальше, возможно это как-то через REST API?

 

[Max]

Ретрансляция видеопотока на другой RTMP-сервер.

 

[extr]

Ретрансляция видеопотока на другой RTMP-сервер.

Да, таким образом пушим поток на кодировшик. Предлагаете запустить вашего кодировщика через api, а затем опять же через api запустить пуш потоков (которые получаются на выходе кодировщика)?
Скорее всего будем изолировать на разное железо. Спасибо.