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

Discussion in 'Web Call Server 5' started by extr, Mar 3, 2020.

  1. extr

    extr New Member

    Пробуем транслировать rtmp поток через XSplit Broadcaster 1080p@60fps (bframes-0)
    Через несколько минут воспроизведения появляются артефакты и лаги
    На сервере в логах сыпется варнинг:
    Code:
    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
    Возможно ли как-то исправить положение?
  2. Max

    Max Administrator Staff Member

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

    extr New Member

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

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

    Max Administrator Staff Member

    Сейчас транскодинг для ретрансляции любого потока как RTMP на другой сервер включается всегда, по этому поводу есть тикет WCS-2457, он не находится в числе приоритетных.
    Согласно спецификации Intel, у этого процессора 8 ядер, 16 потоков. Возможно, у Вас их несколько на сервере?
    Last edited: Mar 4, 2020
  5. Axel

    Axel New Member

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

    extr New Member

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

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

    Max Administrator Staff Member

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

    extr New Member

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

    Max Administrator Staff Member

    Добрый день.
    Мы посмотрели Ваш сервер.
    Рекомендуем выделить больше памяти под Java heap, с настройками по умолчанию будет часто работать сборщик мусора (GC), что приводит к остановке Java машины на время его работы и может затрагивать производительность. В вашем случае можно выделить 8 Гб, установив настройку в wcs-core.properties
    Code:
    -Xmx8g
    -Xms8g
    
    Также рекомендуем убрать настройки
    Code:
    rtmp_in_buffer_enabled=true
    rtmp_in_buffer_initial_size=2000
    
    из flashphoner.properties, т.к. в последних сборках в них нет необходимости
    Кроме того, рекомендуем проверить канал от публикующей стороны (XSplit) до сервера с использованием iperf. Проверять нужно TCP канал, т.к. для публикации RTMP потока используется TCP. Пропускная способность канала должна превышать битрейт потока.
    Если Вы забираете поток с сервера по WebRTC без транскодинга, канал до зрителя можно проверить по этой методике.
  10. extr

    extr New Member

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

    Max Administrator Staff Member

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

    Max Administrator Staff Member

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

    extr New Member

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

    extr New Member

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

    Max Administrator Staff Member

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

    extr New Member

    Добрый день!
    Все верно, запускается 4 потока на ABR транскод (240p, 480p, 720p, 1080p)
    У него особо настраивать нечего для снижения потребления, libx264, superfast
    Мне кажется это немного странным, сторонний кодировщик успевает, а кодировщик на wcs не совсем.
    Свободные ресурсы ведь еще имеются (LA:5 ~20%)

    Спасибо.
  17. Max

    Max Administrator Staff Member

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

    extr New Member

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

    Max Administrator Staff Member

  20. extr

    extr New Member

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

Share This Page