Re: VNC vs. X forwarding via SSH
Stanislav Vlasov <stanislav.v.v@gmail.com> writes:
>> А какая картинка была? DVD? А полоса на локалке 100Мбит? (только
>
> Не двд точно :-)
> Спектакль "День радио" в .avi
Я про DVD напрасно сказал. Не источник имеет значение, а количество
пикселей и формат после декодирования. Если в кадре слишком много
пикселей, то полоса уже большая требуется. Но трафик, конечно, еще от
формата зависит (какой из YUV или RGB).
>> честно!). Даже через Xv, если оно доступно (xvinfo проверял?), почти не
>> должно хватать такой полосы для картинки DVD (720x480p):
>
> Всё правильно, о чём и написал.
> Локалка, кстати, была гигабитная.
На гигабитной локалке по идее не должно быть проблем. Единственное, что
можно предположить, что никакого Xv на X-сервере не было и использовался
x11 как fallback, но тогда уже другие цифры по потоку будут. А без NX,
через ssh пробовал? Или ты один раз попробовал и потом вообще забил?
>> А с -vo x11 или при недоступном Xv и подавно полосы не хватит для такой
>> картинки. Тут в случае с 24-битной глубиной на X-сервере все 4 байта на
>> пиксель поползут по сетке, если не жать. Но с -vo x11 хотя бы средствами
>> NX можно пожать картинку, так как для ее отображения используется X11
>> core protocol.
>
> У vnc тоже есть сжатие. Несколько помогает. И точно меньше жрёт
> процессора при этом. Кстати, vnc такое видео показывало без тормозов
> в той локалке. По-крайней мере, не было заметно. Правда, сжатие с
> потерями использовалось. Полосу для vnc не мерял, так что не знаю,
> сколько оно ело.
Вот именно что сжатие! А для NX сжатие использовалось на локалке? Если в
клиенте NX выбрать тип соединения Ethernet, то там, по-моему (могу
врать), сжатие отключается, если его специально не включить. Без сжатия
полоса под 300 Мбит требуется для картинки DVD (не fullscreen и если -vo
x11 работает). Еще причина может быть связана с тем, что у NX есть
кое-какие оптимизации по передаче больших изображений. Чтобы не
блокировать прохождение других запросов на время передачи большой
картинки, она передается кусочками. Я не знаю, включается ли эта
оптимизация если не используется сжатие.
http://www.nomachine.com/documentation/building-components.php:
For example, Xcomp provides streaming of big images in small chunks, so
nxagent can put demanding clients to sleep, and wake up them as soon as
images (or other big requests) have been completely transferred to the
remote side. These interfaces are implemented in Xcompext. This makes
very simple to develop further agents leveraging similar
functionalities.
>> Однако при fullscreen поток увеличится, так как картинка
>> попрет отмасшабированная программно и плюс затраты сжимание и
>> расжимание.
>
> Угу. Думаю, упрётся в процессор раньше, чем будет достигнут нужный fps.
>
>> Было бы хорошо повторить эксперименты.
>
> А смысл?
А смысл в том, чтобы понять, получаем ли мы производительность по видео,
сравнимую с VNC. Если поверить твоему исходному сообщению, то результаты
плачевные. Сразу же возникают вопросы: а какие настройки были, какая
среда и пр. Ведь умозрительно не должно быть хуже VNC в случае с тупой
передачей картинки. Может, проблема исправимая. С Xv могло бы быть
лучше, но Knowledge base на NoMachine говорит о том, что что-то с Xv еще
не реализовано, хотя информация с конца 2007 года не обновлялась:
http://www.nomachine.com/fr/view.php?id=FR01D01271
Поток для видео в RGB без потери качества очень большой
требуется. Вариант решения - локальный плеер и сетевая файловая система,
где лежат фильмы. Или же есть другой вариант, но он не реализован пока
(и даже не знаю, будет ли) - это сделать сетевую прозрачность для VDPAU,
чтобы карточка на X-сервере, если она умеет, могла самостоятельно потоки
MPEG-2 и пр. декодировать. Вопрос от разработчиков X.Org разработчикам
VDPAU в рассылке freedesktop.org был:
http://lists.freedesktop.org/archives/xorg/2009-September/047294.html
Reply to: