Насколько реально смотреть видео через vnc в стомегабитной локалке

Оно и на гигабите лагает точно так же. Проблемы в захвате картинки с экрана в vnc. RDP как-то лучше отрабатывал относительные изменения и держал выше частоту кадров.

Вот вопрос - есть ли годные реализации rdp для онтопика? Что стоит потыкать?

передавай файл/поток и декодируй локально

я так фильмы смотрел с vps по sshfs

Приятного просмотра :3

Ет немного не то, чего желаю я. Возникни у меня желание смотреть кинчик в локалке, я бы взял что-то в духе dlna, оно ещё лет 6 назад было юзабельно даже при условии раздачи со смарта.

Хочется получить эффект похожий на miracast, только с расширением дисплея.

С помощью vnc можно сделать например так. С парой дополнительных телодвижений сиё работает и поныне, но лэйтенси слегка унылое, кино не посмотреть.

Зависит от алгоритма сжатия. JPEG с сильной компрессией давал в принципе адекватное изображение, хотя текст заметно размывался. Есть смысл заглянуть в опции TurboVNC, там есть параметр, чтобы уменьшить задержку (по дефолту он равен 40 мс).

Ещё есть SPICE, специально заточенный под передачу видео.

А с помощью spice можно пошарить область x11 дисплея?

Для этой задачи есть средства стриминга видео. Не страдай фигнёй.

Я вот думал ffmpeg привлечь, да, не знаю, почему, я ищу решения в rd протоколах, почему-то, кажется, что на многих задачах, это может оказаться быстрее за счёт каких-нибудь(звучит стрёмно, да) оптимизаций.

В случае ffmpeg - встаёт вопрос об эффективном клиенте и выборе протокола. Почему-то по запросу lowlatency куча народу в сети волохают всё через tcp, это меня тоже слегка настораживает.

Тебе кинцо смотреть или работать? Если кинцо - minidlna или по sshfs.

man gst-launch

man low-latency x264

Настоящему рокнрольщику - нужно всё.

Да, видел похожее мнение в сети, видимо то, с чего стоит начать потуги. И более того это единственное решение которое rtp использовало а не непонятные пайпы на netcat.

Ет немного не то, чего желаю я. Возникни у меня желание смотреть кинчик в локалке, я бы взял что-то в духе dlna, оно ещё лет 6 назад было юзабельно даже при условии раздачи со смарта.

dlna нужно разве что если у тебя телек. А если просто с одного компа на другой, то почему не простая шара?

Если это было не через sshfs, то прошу описать подробнее реализацию под онтопик.

Потому, что задача сделать именно расширение монитора а не просто видео проигрывать. Но, хочется, чтобы видео можно было проигрывать в том числе. В идеале, конечно и в игрушки играть. Тот же steam вполне себе такое позволяет, но хочется на oss стеке построить а не прикостылить стим.

Если бы не желание воспользоваться опенсорсом, то посоветовал бы TeamViewer.

Ого, и оно прямо может в видео? 2к в 30 fps осилит? А в 60? Я люблю открытое ПО, но без фанатизма. Реквестирую рецепт успеха. Когда saas решение с сетью как минимум из 3 пиров, работающих по tcp(кмк), и, один из пиров в интернете, таки выдаёт лэйтенси хотя бы 100 мс.

В локальной сети оно работает напрямую.

TCP при правильном использовании не даёт дополнительной задержки. И я не очень уверен, что там именно TCP.

накой нужен такой изврат, если проще зайти на другую машину через сеть, через менеджер входа gdm с XDMCP и смотреть напрямую?

TCP при правильном использовании не даёт дополнительной задержки

Эта тема для отдельной дискуссии и она таки про микросекунды в основном.

Ну, включить моник в xrandr сильно проще, если речь идёт о ежедневном использовании. Это раз. Второй момент - хочется обходится без перетыкания hdmi кабеля в случае если надо поработать.

Может тебе стоит KVM-свитч использовать или вторую видеокарту подключить?

Чего я хочу: большой моник подрублен к orange pi.

Я прихожу с ноутом, и хочу потрудиться. Ставлю ноут на зарядку, врубаю в сеть и включаю в xrandr(или любом его ui) сетевой моник(dummy драйвер от интел). И пускаю некий скрипт(в poc, который я уже делал это был x11vnc и пинок по ssh tigervnc клиента на приёмной стороне). Работать - можно. Видео посмотреть уже не очень.

Это может в итоге оказаться и не удобным но хочется :)

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

С другой стороны, всякие widi могут и на мобилке несколько часов презентации выдержать.

В общем весь сырбор в том, что бы не переключать hdmi аппаратно. Ну, и потенциально, usb тоже (но это явно отдельная история).

Т.е. по сути - ты прав я хочу сделать сетевой kvm свитч в перспективе. По идее пропускных способностей домашних сетей на это должно хватать.

С учётом того, что экран обычно обновляется с частотой 60 FPS, задержки меньше 8-16 мс вообще никак не будут видны.

Хорошо бы тут ещё понимать, что пиковая лэйтенси может и не очень различаться в зависимости от протокола. Но, в случае udp с пропусками устаревших пакетов, лучшие результаты будут сравнимы с tcp, однако распределение будет в разы лучше при прочих равных.

Не осилит.

Вообще бессмысленно жать и гнать по сети, когда уже есть сжатый поток: само видео.
Вот его и надо гнать, а декодировать на приёмнике.

Он в первую очередь про виртуалки. Если вывести экран VM на отдельный монитор, и в этом же VM включить Spice, то будет именно так работать. Кстати, такой же трюк может работать и с VNC без виртуалок. Хочешь поработать на локальной машине? Подключаешься к локалхосту VNC-клиентом. Удалённо? Тогда как обычно. Либо через xpra или аналог организовать проксирование на уровне иксов, чтобы перекидывать приложения с одного реального экрана на виртуальный или наоборот.

Ещё есть X2Go. Я им активно пользуюсь, это самый комфортный способ удаленного доступа в линуксе (а может быть и везде). Но там есть свои заморочки.

Кстати, почему сеть именно соточка? На гигабите всё было бы гораздо проще.

Если сеть не перегружена, её скорости хватает и приложение отправляет данные с небольшой скоростью, то теоретически retransmission-ов быть не должно. Работает ведь как-то SSH по мобильной сети, где потери данных гигантские, как и latency.

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

Кстати, почему сеть именно соточка?

Какая есть.

Пример с ssh скорее антипоказательный, ибо mosh в сетях с высокими задержками показывает гораздо более приятное время отклика, начиная с пинга 70 это становится заметно невооружённым взглядом.

Ставлю ноут на зарядку, врубаю в сеть и включаю в xrandr(или любом его ui) сетевой моник(dummy драйвер от интел). И пускаю некий скрипт(в poc, который я уже делал это был x11vnc и пинок по ssh tigervnc клиента на приёмной стороне). Работать - можно. Видео посмотреть уже не очень.

Не проще ли ноутбук к монитору и клавомыши подключить через KVM-свитч?

В общем весь сырбор в том, что бы не переключать hdmi аппаратно.

А ведь HDMI для этого и сделан - чтобы аппаратно подключаться. И мониторы сделаны чтобы аппаратно подключаться. Максимум, что ты можешь сделать для беспроводного соединения - это что-то вроде передачи изображения через Miracast. Но зачем, когда можно кабель подключить или KVM-свитч прицепить?

Если тебе надо _поработать_, то обойдёшься и без видео. Достаточно будет конкретное приложение пробрасывать через иксы. Если тебе надо видео, то можешь стримить или по удалённой файловой системе покрутить. Как видишь, описанная задача решается элементарным грамотным распределением задач по соответствующим инструментам.

Если бы пропускной способности домашней сети для этого хватало, то все средства ввода-вывода давно бы по протоколам через LAN работали, ибо нафиг не нужно было бы париться с десятками гигабит данных без допуска малейших лагов по HDMI и DisplayPort. Так что нет - пропускной способности не только домашней, но и специализированной быстрой локальной сети не хватит.

Ну, это ты уже прибегаешь к излюбленной пиратскойлоровской тактике - вам не нужно, то, чего вы спрашиваете :)

Ты пытаешься практиковать нецелевое использование интерфейсов и получаешь закономерный результат. Я просто указываю на это и предлагаю использовать правильно подобранные инструменты для решения задачи.

Какая есть.

Есть смысл переделать. Тем более это пригодится не только для удаленного дисплея.

У распределения слишком много параметров, чтобы прямо вот так говорить «в разы». И слишком много факторов, которые оказывают влияние на работу протоколов. Лучше просто взять и попробовать. Тем более, как уже говорили выше, задержки меньше 8-16 мс несущественны при данном применении.

Mosh сам отрисовывает введённые с клавиатуры символы и корректирует их при неправильном предсказании, а SSH ничего не предсказывает и просто ждёт ответа с сервера. Поэтому и чувствуется, что Mosh быстрее. Если у Mosh не получается предсказать изменения на экране, то субъективно задержка там сравнивая с SSH.

Mosh сам отрисовывает введённые с клавиатуры символы

Это только, если ответ не прилетел через таймаут? И он эти символы подчёркивает, т.е можно понять когда это происходит(обычно тут речь уже о задержках 150мс и более). И это только про ввод.

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

Лучше просто взять и попробовать

Золотые слова, но, не та посылка с али пришла пока что:(

Есть смысл переделать.

Обязательно, но не сейчас.