6.0.34-6.0.42 - аппаратное ускорение h264 на Raspberry и Intel

[aka]

Аппаратное ускорение h264 AVC444.

Кодек создает заметную нагрузку на процессоры сервера (до 30% на всех шести ядрах Core i5 для одного клиента при просмотре FullHD видео). Если все ядра сервера перегружены, видео может искажаться. Аппаратное ускорение на сервере работает, если сервер работает на физическом железе. В последних HyperV Майкрософт прекратила поддержку RemoteFX 3D Video Adapter, аппаратное ускорение в виртуальных серверах теперь под вопросом...

В WTware по умолчанию включено. Если будет неправильно рисовать, отключить строкой "graphic=disable-h264" в конфиге терминала.

Update 2024 года: теперь по умолчанию включено. Всё, описанное здесь, работает само, если используется свежий сервер и свежая версия втвари. Отключать на сервере там, где раньше включали, или на терминале graphic = disable-h264-fullscreen

На серверах по умолчанию отключено. Надо включать руками, в gpedit.msc здесь:

h264_1.png (54.77 КБ) 156268 просмотров

Сжимается вся графика одинаковым кодеком, не только видео. Поэтому видео идёт значительно лучше, а с деловой графикой могут случаться сюрпризы. Картинка-тест для h264:

h264_crash_test_800.png (7.51 КБ) 153624 просмотра

Картинку надо скачать и открыть в штатном MS Paint. Не приближать, только 100% зум. Если в RDP сессии используется сжатие h264, то и на втвари, и в mstsc.exe появятся спецэффекты. Лучше всего оно выглядит на 2019 сервере без аппаратного ускорения видео на сервере. В 2019 без аппаратного ускорения видео на сервере широко распиареный AVC444 просто отключен, работает AVC420, под AVC420 эту картинку заметно размоет. На 2016 сервере и на 2019 с аппаратным ускорением видео будет работать AVC444, и он будет работать меееедленно. Можно успеть рассмотреть, чем AVC420 (быстро, но размоет эту картинку) отличается от AVC444 (меееедленно, но восстановит всё, что испортил AVC420).

WTware Changelog на эту тему:

В 6.0.34 появилось на Raspberry. На Raspberry можно смотреть видео по RDP! Ничего похожего раньше не было. WTware единственный RDP клиент, который умеет показывать годное видео на Raspberry по RDP с аппаратным h264.

В 6.0.38 появилось на x86 и UEFI. Для чипов Intel должно работать аппаратное ускорение, для AMD будет позже, но уже сейчас заработает программное, которое тоже вполне шустро.

В 6.0.42 заработало определение пропускной способности сети ("bandwidthautodetect:i:1" в .rdp файле). Если сеть позволяет, сервер отдаёт больше трафика (видел до 30 мегабит на клиента), и качество картинки в некоторых сценах заметно улучшается.

В 6.2.36 настройка сервера для 2019 и 2022 серверов больше не нужна, втварь по умолчанию будет показывать h264. Выключить - настройкой graphic= в конфиге втвари или в настройке сервера на скриншоте установить Disabled.

[Dim-soft]

а какие плюсы ?

[aka]

Графика быстрее рисуется. Видео плавнее. Я минусов по сравнению с нынешним кодеком не вижу.

[Barvinok]

Как по логу понять, что оно работает?
Можно ли удалённо сравнить производительность, нагрузку на CPU, GPU?

[aka]

В логе такая строка означает, что втварь предлагает серверу работать по h264:

Код: Выделить всё

Advertice h264 AVC444.

Если этой строки нет, значит что-то не нравится втвари (старая версия, не малина, bpp=16).

Если сервер соглашается работать по h264, то в логе появится:

Код: Выделить всё

[MMAL] Init h264 decoder for 1312x768 stream.

[Barvinok]

Значит работает. Супер.
Можно во время работы узнать fps?

[aka]

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

[Barvinok]

А вот и первые ласточки.
Четвёртая малина с двумя мониторами.
После обновления вылезла ошибка "Недостаточно памяти, напишите gpu_mem=128".
Написал, перегрузил.
Теперь ошибка "TCP/IP connection lost. Network failure?"
При этом я подключаюсь к терминалу и в браузере и по VNC.

[aka]

После обновления вылезла ошибка "Недостаточно памяти, напишите gpu_mem=128".

config.txt на SD карте свой, не тот что записал конфигуратор?

Сломался от второго экрана. Сейчас будет новая версия.

[Barvinok]

Родной, конфигураторный. Ничего не менял, только добавил gpu_mem=128

[aka]

В родном конфигураторном должно было быть "gpu_mem=96", моей малине этого на два экрана по 1920x1080 хватало. Любопытно, почему твоя ругалась.

Выложил 6.0.36. Попробуй пожалуйста на двух экранах.

[Barvinok]

Всё одно затребовал gpu_mem=128.
После внесения - работает.

[Barvinok]

В родном конфигураторном должно было быть "gpu_mem=96"

Я такого не видел.
Обновляю через браузер.

Пошла обратная связь от пользователей.
Переключения окон приложений (Alt+Tab или просто мышкой) или скрол происходят не гладко. Сначала секунду все окна в размыты (как в пикселях), потом чётко.
Видео отправлю письмом.

[aka]

В родном конфигураторном должно было быть "gpu_mem=96"

Обновляю через браузер.

Понял. Обновление не меняет конфиги, меняются только бинарные файлы. config.txt остался старый.

Сначала секунду все окна в размыты (как в пикселях), потом чётко.
Видео отправлю письмом.

Не вижу на этом видео "потом четко". Все размыто.

По идее так и задумано, кодек быстро кидает черновую картинку и понемногу уточняет. Люди ругаются?

[KudrC]

Перестал работать VLC, на версии 5.8.32 работает на версии 6.0.34 показывает первый кадр и зависает, конкретно пытался выводить видео с камеры в конфиге такие настройки :

clienthostname=StafOfice_QUEUE
video=intel(U)
display=1920x1080, VGA
infobox=always, shutdown, reboot
user= список пользователей; --new--
M2_display=1280x720, HDMI
connection
next screen
connection
next screen
connection
M2_next screen
connection
application=vlc
vlc_cmdline=rtsp://192.168.2.38:7447/bfb6a216-61d2-31e4-8bfe-744b38d1ae81_0
M2_next screen
connection
server= сервер для подключения
user= один пользователь с паролем для автоподключения

[aka]

Попробуй video=modesetting(U).

[Barvinok]

Не вижу на этом видео "потом четко". Все размыто.
По идее так и задумано, кодек быстро кидает черновую картинку и понемногу уточняет. Люди ругаются?

Снято на телефон, но люди сильно ругались.
На обычном кодеке же всё хорошо, почему h264 так не умеет?
Пришлось его выключить

[KudrC]

Попробуй video=modesetting(U).

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

[KudrC]

А вообще нужно всё же как то сообщать, что в новой версии "трогалось", изменялось и добавлялось, не нужно прям расписывать, достаточно по блокам функциональности история тоже не нужна достаточно начать с любой версии....

[aka]

в понедельник попробую новую версию отпишусь...

Лог покажи.

А вообще нужно всё же как то сообщать, что в новой версии "трогалось", изменялось и добавлялось

Между 6.0.34 и 6.0.36 обновилось линуксовое ядро. Всего на единичку, ничего глобального, рутинное поддержание актуальной версии ядра, ядер в втвари три разных (x86, UEFI, малина), все три постоянно обновляются. Changelog одного только ядра, обновившегося на одну только единичку - больше двух тысяч строк: https://cdn.kernel.org/pub/linux/kernel ... Log-5.4.97

Расскажи, что ты станешь делать с этой информацией?

[aka]

Снято на телефон, но люди сильно ругались.
На обычном кодеке же всё хорошо, почему h264 так не умеет?

Лог покажи. С той малины, на которой особенно заметно. Ещё хорошо бы проверить, что у неё со скоростью сети (например, заливанием большого файла НА флешку в малине) и что с загрузкой процессора сервера.

У меня даже на третьей малине переключение окошек мновенное, никакой ступенчатой прорисовки не видно.

[Barvinok]

h264 более требователен к сети?
Вообще там гигабитная сеть, но большинство подключены транзитом через ip-телефоны и со 100 Мбитным свичём.
На сервере 32 ядра, загрузка ~15%.
Я проверю в понедельник как будет при прямом подключении и пришлю лог.

[aka]

На третьей малине 100 мегабит, внутри подключенные по USB. Этого хватает, чтобы я никакого промежуточного состояния окошка не видел. Но это должны быть работающие 100 мегабит. Потому и предлагаю проверить записью на флешку, сколько на самом деле доходит до терминала.

[Barvinok]

Сегодня проверил работу сети. Прокачивал образ раздела, снятый Акронисом (tib) размером ~120GB (не целиком, минут пять).
Гигабитный свич и две гигабитные сетевушки (сервер-ноутбук) напрямую выдают 80-90МБайт/сек.
Через ip-телефон (100Мбит) - 8-9МБайт/с.
Без потерь. Без ошибок.
При работе за терминалом с включённым H264 и так и эдак я вижу размытость и при скроле и переключениях между окнами. На всех малинах так, не на одной. Примерно пол секунды.
Это действительно напрягает глаза.
С кодеком GFX такого не происходит.

[KudrC]

в понедельник попробую новую версию отпишусь...

Лог покажи.

А вообще нужно всё же как то сообщать, что в новой версии "трогалось", изменялось и добавлялось

Между 6.0.34 и 6.0.36 обновилось линуксовое ядро. Всего на единичку, ничего глобального, рутинное поддержание актуальной версии ядра, ядер в втвари три разных (x86, UEFI, малина), все три постоянно обновляются. Changelog одного только ядра, обновившегося на одну только единичку - больше двух тысяч строк: https://cdn.kernel.org/pub/linux/kernel ... Log-5.4.97

Расскажи, что ты станешь делать с этой информацией?

Уважаемый Ака, я конечно понимаю иронию и считаю себя обыкновенным юзером (потому к стати и пользуюсь вашим продуктом, так как всё относительно просто для меня), но конкретно информация о том, что поменялась линуксовое ядро, для меня говорит о том , что есть смысл проверить старые хотелки которые не работали или работали коряво на предыдущей версии, а если бы было написано, что изменилась версия VLC, то я бы попробовал немного другую конфигу для мозайки, а если написано будет, что поменялся загрузчик для "малинки", то я ничего делать не буду, так как не использую малинки.... как то так.

[KudrC]

Перестал работать VLC, на версии 5.8.32 работает на версии 6.0.34 показывает первый кадр и зависает, конкретно пытался выводить видео с камеры в конфиге такие настройки :

clienthostname=StafOfice_QUEUE
video=intel(U)
display=1920x1080, VGA
infobox=always, shutdown, reboot
user= список пользователей; --new--
M2_display=1280x720, HDMI
connection
next screen
connection
next screen
connection
M2_next screen
connection
application=vlc
vlc_cmdline=rtsp://192.168.2.38:7447/bfb6a216-61d2-31e4-8bfe-744b38d1ae81_0
M2_next screen
connection
server= сервер для подключения
user= один пользователь с паролем для автоподключения

Попробовал версию WTware v.6.0.36, та жа история показывает на втором экране первый кадр с камеры и зависает,
пробовал и с параметром
video = modesetting(U) , всё одно зависает

[aka]

Попробовал версию WTware v.6.0.36, та жа история показывает на втором экране первый кадр с камеры и зависает

Попробуй это: http://wtware.com/testing/202102210527.zip

[KudrC]

ага, понял сегодня проверю.

[KudrC]

так заработало, в смысле не зависает и экран с VLC отображает видео, спасибо за оперативность.
Пока будут работать на данной версии (6.0.37), если будут проблемы отпишусь.

[KudrC]

так следующие отзывы о работе 6.0.37 :
конфиг
clienthostname=StafOfice_QUEUE
video=modesetting(U)
display=1600x900; VGA
disk=usb
infobox=always, shutdown, reboot
M2_display=1280x720; HDMI
M2_position=right-top
connection
next screen
connection
next screen
connection
M2_next screen
connection
application=vlc
vlc_cmdline=rtsp://192.168.2.38:7447/bfb6a216-61d2-31e4-8bfe-744b38d1ae81_0
M2_next screen
connection
server=192.168.2.116
user=ochered_MAD[VIDEO QUEUE (очередь)]:\x6a\x78\x74\x68\x74\x6c\x6d\x32\x30\x31\x21


1. ОЧЕНЬ медленное переключение экранов на первом мониторе (прям видно как один "переползает" во второй), на втором вроде как быстро
2. ОЧЕНЬ медленная реакция на нажатие (выбор пользователя) на первом экране
3. Работа в самомой терминальной сессии вроде нормальная (юзеры не жалуются)

[aka]

1. ОЧЕНЬ медленное переключение экранов на первом мониторе (прям видно как один "переползает" во второй), на втором вроде как быстро

Напиши в конфиг:

Код: Выделить всё

animation_speed = 0

На втором мониторе переключение из VLC в RDP должно быть мгновенным. Из RDP и VLC медленно потому что VLC запускается.

2. ОЧЕНЬ медленная реакция на нажатие (выбор пользователя) на первом экране

Этого не понимаю. Опиши подробнее.
Если убрать из конфига второй монитор, починится?

[Barvinok]

Очередной отклик пользователя на новый кодек:

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

[KudrC]

1. ОЧЕНЬ медленное переключение экранов на первом мониторе (прям видно как один "переползает" во второй), на втором вроде как быстро

Напиши в конфиг:

Код: Выделить всё

animation_speed = 0

На втором мониторе переключение из VLC в RDP должно быть мгновенным. Из RDP и VLC медленно потому что VLC запускается.

2. ОЧЕНЬ медленная реакция на нажатие (выбор пользователя) на первом экране

Этого не понимаю. Опиши подробнее.
Если убрать из конфига второй монитор, починится?

Установил animation_speed = 0 и всё заработало как и раньше , второй монитор не убирал,
странно что на версии 5.Х этот параметр работал по другому (так медленно не менял экраны).
пункт 2 тоже вылечился (было - мышкой кликаешь по элементу из списка пользователей и фокус на "выбранного" пользователя переходил с задержкой)
Насчёт переключений из RDP на VLC всё правильно переключается, я знаю , что VLC при этом стартует (и это правильно мне так и надо)
в общем animation_speed = 0 помогло, других претензий от пользователей не отмечено.

[aka]

...после прокрутки картинка очень плохого качества потом восстанавливается, с чем может быть связано?

Если написать ему в конфиг "graphic=disable-h264", станет лучше? Или будет как с бородой под/над одеялом?

[aka]

Установил animation_speed = 0 и всё заработало как и раньше , второй монитор не убирал,
странно что на версии 5.Х этот параметр работал по другому (так медленно не менял экраны).

Странно. Много лет ничего в этом сдвиге не менялось. Попробуй тест скорости графики, который из меню по Del вызывается. В 5.Х и в свежей, и сравнить результаты. А то VLC в логе ругалось, что очень медленно прорисовалось, и анимация замедлилась, может что-о со скоростью рисования хуже стало.

[Barvinok]

...после прокрутки картинка очень плохого качества потом восстанавливается, с чем может быть связано?

Если написать ему в конфиг "graphic=disable-h264", станет лучше? Или будет как с бородой под/над одеялом?

Отклики пользователей, когда выключил h264 (сначала некоторым в конфиге, а потом целиком на сервере):

Оооо, кайф) визуальный экстаз) спасибо!!

Во, гораздо лучше, спасибо

[KudrC]

Установил animation_speed = 0 и всё заработало как и раньше , второй монитор не убирал,
странно что на версии 5.Х этот параметр работал по другому (так медленно не менял экраны).

Странно. Много лет ничего в этом сдвиге не менялось. Попробуй тест скорости графики, который из меню по Del вызывается. В 5.Х и в свежей, и сравнить результаты. А то VLC в логе ругалось, что очень медленно прорисовалось, и анимация замедлилась, может что-о со скоростью рисования хуже стало.

Вот результаты измерений:
WTware 5.8.32
intel(U) - 17,70
modesetting(U) - 27,85

WTware 6.0.37
intel(U) - 82,73
modesetting(U) - 164.85

и ещё такое прилетело от пользователей WTware 6.0.37 - "интернет тупит" , от пользователей WTware 5.8.32 жалобна подобное нет, хотя все работают на одном терминальном сервере, после того как я их попытал вроде как выяснилось, что хром запущенный в терминальной сессии медленно перерисовывает странички электронной почты.

[aka]

Цифры адские же. Что-то сломалось. Покажи два одинаковых лога от 5.8.32 и от 6.0.37. Чтобы конфиг одинаковый, железо одинаковое, только версии втвари разные.

[KudrC]

Цифры адские же. Что-то сломалось. Покажи два одинаковых лога от 5.8.32 и от 6.0.37. Чтобы конфиг одинаковый, железо одинаковое, только версии втвари разные.

логи как заказывал

[aka]

В версии 6.0.38 переписан h264 на малине и сделан h264 на x86 32- и 64-битных. На Intel должна заработать аппаратная акселерация.

[aka]

KudrC
Для матери есть BIOS на два года новее. Случалось, что новый биос чинил проблемы: https://downloadcenter.intel.com/downlo ... -TYBYT10H-

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

[KudrC]

KudrC
Для матери есть BIOS на два года новее. Случалось, что новый биос чинил проблемы: https://downloadcenter.intel.com/downlo ... -TYBYT10H-

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

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

[aka]

KudrC
Через час 6.0.40 выложится. Там ещё один костылик в ядре поменяется, врядли, но вдруг...

[Barvinok]

При работе за терминалом с включённым H264 и так и эдак я вижу размытость и при скроле и переключениях между окнами. На всех малинах так, не на одной. Примерно пол секунды.
Это действительно напрягает глаза.
С кодеком GFX такого не происходит.

В последних версиях - всё хорошо!
Говорят, даже гораздо лучше, чем с GFX!

[Barvinok]

Всё хорошо, кроме RPi4 с двумя мониторами.
Через несколько минут работы замирает картинка. Без артефактов. Мышь бегает. Терминал работает - запросто вхожу на web или подключаюсь по VNC. Всё быстро, не тупит.
Сеанс работает - можно зайти с другого терминала или с винды.
На Pi4 тут же появляется сообщение, дескать, кто-то вошёл в сеанс.
Можно снова зайти - сразу покажет замёрзший рабочий стол.
Если выключить h264 - не виснет.
Два лога во время такого фриза прилагаю

[KudrC]

Установил animation_speed = 0 и всё заработало как и раньше , второй монитор не убирал,
странно что на версии 5.Х этот параметр работал по другому (так медленно не менял экраны).

Странно. Много лет ничего в этом сдвиге не менялось. Попробуй тест скорости графики, который из меню по Del вызывается. В 5.Х и в свежей, и сравнить результаты. А то VLC в логе ругалось, что очень медленно прорисовалось, и анимация замедлилась, может что-о со скоростью рисования хуже стало.

Вот результаты измерений:
WTware 5.8.32
intel(U) - 17,70
modesetting(U) - 27,85

WTware 6.0.37
intel(U) - 82,73
modesetting(U) - 164.85

и ещё такое прилетело от пользователей WTware 6.0.37 - "интернет тупит" , от пользователей WTware 5.8.32 жалобна подобное нет, хотя все работают на одном терминальном сервере, после того как я их попытал вроде как выяснилось, что хром запущенный в терминальной сессии медленно перерисовывает странички электронной почты.

Прошу прощение за долгое отсутствие, то железяка ломалась, то дел не впроворот, то митинги, короче пока не закрыли продолжаю тестирование:
по моему мало что поменялось, железяка та же и конфиг тот же
WTware 6.0.46
intel(U) - 84,62
modesetting(U) - 165.74

[KudrC]

KudrC
Для матери есть BIOS на два года новее. Случалось, что новый биос чинил проблемы: https://downloadcenter.intel.com/downlo ... -TYBYT10H-

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

Насчёт BIOS и UEFI пока не менял, но планирую, как сделаю отпишусь о результатах

[aka]

Всё хорошо, кроме RPi4 с двумя мониторами.

Нашел ошибку у RPi4 с двумя мониторами и h264. Должно исправиться в 6.0.52.

[Гость]

Не работает аппаратное ускорение. Похоже кодек h264 в wtware скомпилирован с обязательной поддержкой sse4.2 , но в моем процессоре нет этих инструкций судя по логам.

[aka]

После h264 в RDP применяется фильтр, которым майкрософты шрифты подтягивают (всё что пишут про AVC420 и AVC444 - это как раз про этот фильтр). В втвари этот фильтр написан на инструкциях sse4.2. Без них не едет, да.

[xeon266]

Хочется еще раз поднять эту интересную тему, так как время идет и все меняется, совершенствуется. Готов быть тестером.

Процессор у меня на хостовой системе Hyper-V Xeon Gold 6248R и естественно есть поддержка всех возможных инструкций, в том числе и sse4.2
Гостевые системы VDI на Windows 10 22H2, все настройки по умолчанию никто никуда не лазил.
Клиентская система WTWare на Pi5 6.2.68

В конфиге
graphic=af,disable-h264-fullscreen

В логе

[ rdpclient 588] [ 18.017098] [TCP] Connection with 10.10.10.X established.
[ rdpclient 588] [ 18.017186] [TCP] Turn keepalive on.
[ rdpclient 588] [ 18.017692] Free ram after buffers allocation: 874036 KB.
[ rdpclient 588] [ 18.055656] Server supports GFX Pipeline.
[ rdpclient 588] [ 18.055739] NLA EX.
[ rdpclient 588] [ 18.055781] SSL/TLS.
[ rdpclient 588] [ 18.124224] TLSv1.2.
[ rdpclient 588] [ 18.200948] The user has permission to access the server.
[ rdpclient 588] [ 18.229784] RDP 10.8 server.
[ rdpclient 588] [ 18.474383] Enable font smoothing and Desktop Composition.
[ rdpclient 588] [ 18.498015] Microsoft License: STATUS_VALID_CLIENT.
[ rdpclient 588] [ 18.601595] [h264] Enable AVC422 and AVC444.
[ rdpclient 588] [ 18.601685] [GFX] Graphic channel.
[ rdpclient 588] [ 18.601729] [h264] Fullscreen disabled in graphic= config option.
[ rdpclient 588] [ 18.625422] GFX decoder thread.
[ rdpclient 588] [ 18.625676] [h264] Video control channel.
[ rdpclient 588] [ 18.625746] RDPGFX version 10.4, flags 0x00000022.
[ rdpclient 588] [ 18.625875] [h264] Video data channel.
[ rdpclient 588] [ 18.627526] Reset graphics output buffer 1920x1080, 1 monitors.

Суть - проблема классическая, если не использовать disable-h264-fullscreen тогда имеем кривые шрифты если фон красный или шрифт красный, причем это и в 1С и на сайтах, той же торговой площадки РТС.

Почему пишу, если использовать disable-h264-fullscreen, то тогда лагает просмотр видео в браузерах хочется чтоб было и видео без лагов и шрифты корректные...

Все таки полная поддержка h264 это будет классная тема, особенно учесть что это linux и все это на каналах интернет, у нас все в облаке.


https://learn.microsoft.com/ru-ru/azure ... s-encoding
https://learn.microsoft.com/ru-ru/azure ... o-encoding

"Кодирование видео в полноэкранном режиме обрабатывает все графические данные с помощью AVC/H.264 или HEVC/H.265. В результате он работает хуже, чем в смешанном режиме кодирования, когда содержимое экрана в основном основано на тексте." - по факту наоборот..

[xeon266]

Тут https://techcommunity.microsoft.com/blo ... s-s/249588 и тут https://virtuallyvisual.wordpress.com/2 ... -and-cool/
сказано что в версии h264 4:2:0 реально имеют проблему с отображением шрифта и что в H.264 4:4:4 дела обстоят значительно лучше, но возможно чтоб это увидеть нужно проброс GPU (а не CPU) на гостевых системах в Hyper-V через GPU_P (ну или DDE если гостевая система это сервер терминалов на не VDI), пока попробую узнать есть ли у меня такая опция. Так же ту сказано что артефакт с шрифтами как раз из за кривого кодирования в полноэкранном режиме!, так что ваша опция похоже верно называется и по дефолту именно полноэкранный режим.

Интересно почему видео начинает лагать, наверно есть какие-то баги с оптимизацией когда поток разделен на 3 части текст/картинка/видео (не полноэкранный режим)

При disable-h264-fullscreen вот эта строка в логе "[h264] Enable AVC422 and AVC444" как раз похоже и означает что текст/image идет в 422, а видео в AVC444

К вам по сути один вопрос: h264 4:4:4 есть в вашей компиляции rdp ?

[xeon266]

Что касается PI5, если верить тому что ниже, то аппаратной разгрузки нет (типа какого-то отдельного чипа), да и черт с ним, CPU ничем не занят в wtware, но "H.265 is recommended over H.264 4:4:4 on the Pi 5", то возник еще вопрос: а если у меня на сервере есть проброс GPU, то можно с аппаратной разгрузкой получить h265 на RDP, это реально реализовать в wtware ?

The Raspberry Pi 5 does not natively support hardware-accelerated H.264 4:4:4 decoding or encoding. It focuses on H.265 (HEVC) and standard H.264 (4:2:0) hardware decoding.
While the Pi 5 has improved media capabilities, high-profile 4:4:4 content (often used in screen sharing/high-fidelity video) will rely on software decoding via CPU, likely leading to high load.

Key Considerations:
H.264 Support: The hardware decoder supports standard H.264 (4:2:0) up to 1080p60 or 4K30.
H.265 Support: Supports HEVC Main 4:4:4 10-bit hardware decoding.
4:4:4 Content: If playing H.264 4:4:4, the CPU will handle the processing.
Alternative: For high-fidelity screen streaming (e.g., Moonlight/Sunshine), H.265 is recommended over H.264 4:4:4 on the Pi 5.

[aka]

Вот так выглядит в свежепоставленной Win11 на свежепоставленном server2022 окошко Far:

Untitled.png (156.63 КБ) 3649 просмотров

Никакие настройки не менялись, так мутно оно с этими цветами по умолчанию. Жёлтое Name хорошо кодируется, а красная компонента мылится. Так майкрософты настроили кодек.

Мы не сделаем лучше, чем в виндовсе. Придётся выбирать что-то одно: или h264 для видео, или вырвиглазные цвета.

https://learn.microsoft.com/ru-ru/azure ... s-encoding
"...или HEVC/H.265.

Там про ажур. Не нахожу объявления, что H.265 поддерживается в обычных серверах. И в технической документации по RDP про h256 пока ничего не написано. Когда появится документация на h265 в RDP в обычных серверах, тогда будем копать в этом направлении.

сказано что в версии h264 4:2:0 реально имеют проблему с отображением шрифта и что в H.264 4:4:4 дела обстоят значительно лучше, но возможно чтоб это увидеть нужно проброс GPU (а не CPU) на гостевых системах в Hyper-V

Да. Или запускать сервер на физическом железе, не в виртуалке. Я отлаживал это на сервере, стоящем на физическом железе, на обычном интеловом процессоре со встроенной графикой. Встроенная в процессор графика тоже GPU, сервер соглашался делать AVC444, но очень медленно. Там двухступенчатое кодирование. Сначала прилетала мутная картинка в AVC420, как на скриншоте выше, и потом, через примерно четверть секунды прилетало дополнение, которое делает шрифты читаемыми. На нормальной картинке обновление почти незаметно, а на вырвиглазных цветах бьёт по глазам, работать так мне было неприятно. Может быть, на настоящем ускорителе будет быстрее.

[xeon266]

Что-то еще почитал и не понял

AVC (Advanced Video Coding) — формат сжатия видео, также известный как H.264.

Выходит, если верить записи в логе "[ rdpclient 588] [ 18.601595] [h264] Enable AVC422 and AVC444", h264 4:4:4 у вас есть и оно кодируется процессором PI, без аппаратной разгрузки и сервер RDP это принимает? Тогда почему в полноэкранном формате шрифты размываются?

Попробовал использовать полноэкранное кодирование тогда лог указал что используется h264 на CPU (см. скрин), опять же какой? 4:4:4 или 4:2:0 (2), если учесть что аппаратная разгрузка (GPU) на PI5 есть только для 4:2 и H265, то тогда это активировался 4:4:4 с CPU (программным) декодированием?, но что-то мне подсказывает что это не так и просто wtware вообще не умеет GPU!

спустя нескольких исследований....

В общем картина прояснилась все как я и писал- windows не активирует CPU(программное) кодирование для 4:4:4, вы указали настройку в политике в шапке, она без активации включения GPU декодирования не срабатывает - нету 4:4:4! (знать бы почему)

Берем wtware с полноэкранным режимом кодирования, подключаемся к windows 11 на физическом компьютере с дефолтными политиками, глаз режет на красном фоне!
Включаем в политиках настройку которая якобы разрешает софтовое кодирование 444 если нет GPU, перезагружаем компьютер (на всякий случай и чтоб новую сессию создать), подключаемся, опять режет глаз!
Включаем в политиках аппаратное кодирование (там так и написано если не включить то ВСЕГДА программное) опать перезагружаемся, заходим и все четко, в логах добавляется 170 событие!

Событие 162 одинаковое для всех вариантов политики, типа сервер поддерживает какой-то вариант h264

Что касается видео и текста сразу, то на текущий момент как у вас написано в шапке - оптимальная настройка жирный канал c опцией graphic=disable-h264, но идеальный вариант это видеокарта с GPU-P на Hyper-V (к сожалению у меня этой опции нет)

[xeon266]

еще скрины

[aka]

Выходит, если верить записи в логе "[ rdpclient 588] [ 18.601595] [h264] Enable AVC422 and AVC444", h264 4:4:4 у вас есть и оно кодируется процессором PI, без аппаратной разгрузки и сервер RDP это принимает? Тогда почему в полноэкранном формате шрифты размываются?

У нас оно ДЕкодируется. Мы (втварь) говорим серверу, что готовы принимать AVC444. Кодируется на сервере, и решение, как кодировать, принимает сервер.

Включаем в политиках настройку которая якобы разрешает софтовое кодирование 444 если нет GPU,

Может быть, одного только разрешения недостаточно, надо ещё как-то пнуть.

Драйвер видеокарты в сервере стоит? Тесты 3D на консоли сервера показывают, что GPU работает?

Что касается видео и текста сразу на текущий момент, оптимальная настройка жирный канал c опцией graphic=af,disable-h264

Не могу не уточнить: оптималная настройка если приходится видеть красные контрастные цвета. У самих майкрософтов в приложениях таких сочетаний кажется нигде не встречается.

[xeon266]

Сервер действительно принимает решение, сейчас основная проблема чтоб пнуть сервер без аппаратного (GPU) кодирования перейти на 4:4:4, пока я считаю что программного кодирования 4:4:4 в Windows 10 22H2 нет. Как мы выяснили wtware умеет полноэкранное декодирование 4:4:4 на CPU (программное) - сам себе ответил, красный возникает потому что без аппаратного кодирования сервер использует кодирование 4:2:0 (2).

Тестировал windows-windows
GPU на тестовой машине работает (см. скрин) причем интересно так:
Если активировано аппаратное кодирование включается полноэкранный режим! - если статическое изображение то нагрузки нет, если начинаешь менять части изображения (мышь шевелишь и т.д.) идут всплески.
Если аппаратное кодирование в политиках не выключено, то полноэкранного кодирования нет, работает кодирования по умолчанию (текст, картинка, видео обрабатываются отдельно), если видео не проигрывается то всплесков нет!, как только открываешь барузер и запускаешь видео идет всплеск аппаратного кодирования.

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

Так же отмечу что включение полноэкранного кодирования 4:4:4 это хорошо и с ним ВИДЕО РЕАЛЬНО ПОКАЗЫВАЕТ ЛУЧШЕ, но не решает проблемы плавающего видео на медленных каналах. Сейчас у меня проблема, в облаке стоит оборудование с битым DAC кабелем и из за этого очень слабый канал, так вот когда через облако видео плавает при любых настройках (хоть включен GPU хоть нет), когда использую нормальный канал видео начинает более менее нормально работать. Т.е. по сути можно не гнаться за использованием полноэкранного кодирования если это обычная RDP сессия в которой не только видео. Видео будет показывать нормально и в отдельно обработке на нормальном канале. Например вы можете поменять среднее сжатие в политиках, на без потери качества и сразу увидите лаги видео и на нормальном канале.

То что я никогда не видел баги с красным при использовании windows и в качестве клиента и сервера объясняется тем что я пока не понял как эту связку заставить работать в полноэкранном кодировании на 4:2:0 (2) - как я понял, чтоб полноэкранное кодирование заработало надо включать обе политики - и GPU и приоритет AVC444 + клиент у меня все поддерживает, если просто врубить GPU то полноэкранное кодирование, если верить всплескам в мониторинге, не врубается.

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

With RDP 8.1 we introduced an AVC/H.264 mixed mode which in addition to using RemoteFX Media Streaming, extended support for AVC/H.264 to images as well, while text is compressed using a proprietary Codec.
Интересно когда пайплайн RDP соединения разделен на 3 части (не полноэкранное кодирование), какой же их собственный кодек используется для текста, поэтому баг с красным пропадает.

Что касается не полноэкранного кодирования и моих наблюдений с мониторингом разгрузки через GPU
AVC 444 and AVC/H.264 Hardware Encoders / Decoders With the Windows Remote Desktop Client (MSTSC.EXE) the AVC 444 mode automatically uses the AVC/H.264 Hardware decoder if available via the Windows DirectX Video Acceleration (DXVA) API - автоматически, т.е. политики вообще на это не влияют если клиент и сервер в порядке.

Еще из важного что буду разбирать, событие 162 (есть скрин выше) реально показывает профили кодирования и полагаю по ним можно определить какой режим, какой кодек, какое сжатие (2,8,2048)