LINUX.ORG.RU

Снижается FPS захватываемой картинки X сервера без движения мыши

 , , ,


0

2

Есть виртуалка на KVM, на ней сервис, который через Nvidia FBC (framebuffer capture) получает видеобуфер с иксов и аппаратно упаковывает его в h.264 через NVENC. Почему-то, если ничего не делать, видимый FPS полученной картинки где-то в районе 20-25 при том, что на видюхе 45. Если двигать мышкой по экрану, всё резко становится плавнее, близко к норме. FBC исправно захватывает картинки с интервалом 22..30 мс, не зависит от движений мыши. Откуда может быть такая разница? Что-то в иксах? Куда смотреть, вообще непонятно.

Что-то еще на экране меняется? Или вы пытаетесь писать статичный экран, который перерисовывается не по system event, а по system timer и то, если вдруг так решит видеосистема?

PPP328 ★★★★★
()
Ответ на: комментарий от PPP328

Вообще я проверял на динамичных сценах (демки, фильмы). Там просто проседает FPS. Если вводить текст, всё ещё хуже, отображаются только пары вводимых символов. При этом по идее используется вызов FBC не блокирующий, так что он должен возвращать безусловно то, что на экране, в отличие от блокирующего варианта, который без изменения не возвращает буфер. Может, какая буферизация мешает?

olegkrutov ★★
() автор топика
Ответ на: комментарий от olegkrutov

Если вводить текст, всё ещё хуже, отображаются только пары вводимых символов.

X11 перерисовывает только измененные области, это позволяет экономить на ресурсах и трафике при пробросе. Ваша «динамическая картинка» меняется не средствами X11, поэтому события обновления нет. То, чем вы захватываете экран ориентируется на сигнал изменения экрана от X11.

PPP328 ★★★★★
()
Ответ на: комментарий от PPP328

А какими тогда средствами она меняется? И почему она не меняется, если ввести один символ, но меняется, если ввести два? В обычном терминале собственно. И почему всё отрабатывает, если непрерывно ездить мышью? Куда смотреть-то? И ещё непонятно, – если грабить экран не средствами FBC, а программно, таких проблем нет. То есть, получается, драйвер Nvidia+FBC что-то недорабатывают.

olegkrutov ★★
() автор топика
Ответ на: комментарий от olegkrutov

Ответы на все ваши вопросы это то, что я написал выше.

Событие перерисовки вызывается тогда, когда меняется контент на экране, которым заведуют иксы. Мышь, перемещение окон, ввод текста (с исключением когда его обрабатывает само приложение) - генерируют событие обновления. Если кто-то решил на какой-то канве САМ отрисовывать контент без использования средств иксов (ximage/xpixmap) то событие сгенерировано не будет.

Вы используете утилиты, которые не предназначены для записи highfps контента, отрисовываемого не средствами иксов.

PPP328 ★★★★★
()
Ответ на: комментарий от PPP328

То есть вы хотите сказать, что NVFBC берёт не некую результирующую поверхность и её захватывает, а что-то другое? Ведь захватывается оно регулярно, а изменений там нет. Я просто в дебрях иксов совсем не разбираюсь. Тогда получается, надо регулярно генерить какие-то события, заставляющие перерисовывать экран…

olegkrutov ★★
() автор топика
Ответ на: комментарий от olegkrutov

Смотрите, у вас на экране есть картинка, её отрисовывает Xserver.

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

У Xserver’а есть одно замечательное свойство - когда вы, например, перемещаете одно окно поверх второго перекрывая угол - сервер не отрисовывает оба окна целиком, только ту область, которая видима.

Когда вы вводите текст в поле ввода (которое обслуживается иксами, это важно. Есть еще кастомные контролы, которые может свой фреймворк рисовать), то иксы не перерисовывают всё окно. Зачем? Происходит только перерисовка активного контрола или даже его части.

Это позволяет при пробросе иксов передавать по сети не весь экран N раз в секунду, как делают VNC/rdp/teamviewer, а только сигнал о перерисовке контрола с новыми данными, по сути рендеря картинку у вас на клиенте.

Ваш драйвер, судя по всему ловит именно события redraw, которые имеют свойства x,y,w,h - область перерисовки. Т.е. если вы переместили мышку на 10 пикселей влево - вам прилетит событие перерисовки той области где она была и той области куда она прилетела. Сами по себе по умолчанию окна не перерисовываются - зачем? Это лишнее напряжение процессора и сети (в случае проброса).

Когда рисуются кастомные контролы иксы в этом вообще могут не участвовать напрямую. Они отдали область для отрисовки, дальше программа там сама себе господин. Это же касается мультимедиа контента.

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

Меня может поправить @Zubok, возможно я в чём-то не прав.

PPP328 ★★★★★
()
Последнее исправление: PPP328 (всего исправлений: 1)
Ответ на: комментарий от PPP328

Так ведь суть-то в том, что записывающее устройство – аппаратное, встроенное в видюху, нарочно предназначенное для захвата фреймбуфера. И оно взаимодействует с драйвером Nvidia, естественно. И оно имеет страшну пачку настроек, среди которых формирование дифф.карт для определения изменённых областей экрана, выдача нового кадра либо вот как раз по изменению, либо просто монотонно по таймауту, будь на экране хоть и ровно хотя бы одно и то же (если интересно, могу пдфку прислать с описанием API). Если бы это была какая-то левая приблуда… Всякие VmWare Horizon это в общем и используют, и по идее там нет такой проблемы.

olegkrutov ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.