Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Streaming lossless VNC to a web browser with Quite OK image format

kasmweb.com

Post reply on HN
Print view View original

21–30 of 36 posts

Re: Streaming lossless VNC to a web browser with Quite OK image format

#21

Post by vardump »

userbinator wrote: post #16
IshKebab wrote: post #11

Earlier quoted context omitted.

RDP doesn't pass through graphics primitives. You're probably thinking of X11. Sending graphics primitives turned out to be the worst way to do remote desktop. All modern solutions just use video codecs. NX (the best solution on Linux) even switched from X11 forwarding to a video codec in NX4. VNC is inefficient because it is ancient and uses extremely inefficient methods to encode the graphics. GIF is really ineffic…

Yes it does. https://learn.microsoft.com/en-us/openspecs/windows_protocol...

In the past, maybe Windows XP to perhaps Windows 7 era it did — not sure exactly when they stopped using primitives. But not since a long time. It's just (lossy) compressed bitmap streaming nowadays.

Re: Streaming lossless VNC to a web browser with Quite OK image format

#22

Post by thfuran »

fulafel wrote: post #8

Sad that in 2022 an "entire gigabit connection" is still considered a lot of bandwidth, the statement would have sounded the same 10 years ago and only slightly out of the ordinary 20 years ago.

A gigabit internet connection would've been a lot more than slightly out of the ordinary in the consumer space 20 years ago.

Re: Streaming lossless VNC to a web browser with Quite OK image format

#23

Post by jbverschoor »

any1 wrote: post #15
userbinator wrote: post #5

Lossless encoding can and will consume all available bandwidth available to a client and is designed to be run on local networks. VNC is unfortunately inherently inefficient because it is just a framebuffer protocol, instead of RDP which passes through the graphics primitives to be rendered. The former will always involve encoding/decoding overhead at the server and client.

I am pretty sure that no RDP solution for any Linux desktop system uses graphics primitives. For that to happen, all the toolkits would have to implement some way of passing their scene graph and their primitives to the compositor and the compositor would have to know what to do with that info. RDP also supports plain framebuffers and that's what we use. Anyhow, with the advent of specialised hardware for video encod…

Ah the good 'ole days of X11

Re: Streaming lossless VNC to a web browser with Quite OK image format

#24

Post by vanviegen »

fulafel wrote: post #8

Sad that in 2022 an "entire gigabit connection" is still considered a lot of bandwidth, the statement would have sounded the same 10 years ago and only slightly out of the ordinary 20 years ago.

Shrug. Why spend more when 100mbit is also enough for most purposes.

Re: Streaming lossless VNC to a web browser with Quite OK image format

#25

Post by thelamer »

IshKebab wrote: post #12
thelamer wrote: post #2

This has been a dream of mine ever since I first saw QOI. The encoding and decoding times and relatively high compression were perfect for this use case it was just a matter of implementation. Because the VNC protocol with tight encoding breaks frame changes into 100s of tiny images it allows us to encode and decode in a threaded manner. This means high FPS and low latency on a truly lossless remote Linux desktop in…

It makes more sense just to use a normal video codec. They can handle all sorts of situations efficiently that this can't e.g. scrolling, zooming and embedded videos. That is how NX4, Chrome, RuskDesk, Zoom, etc. all do it.

Yes video codecs are great but in almost every case they need a GPU. This functions with no special hardware. The only lossless option would be AV1 and that needs an Intel arc card or 4000 series Nvidia card.

You also have an inherent latency issue as you have to buffer 2-5 frames at 16ms a pop server side to encode the data.

Re: Streaming lossless VNC to a web browser with Quite OK image format

#26

Post by thelamer »

arcastroe wrote: post #4
thelamer wrote: post #2

This has been a dream of mine ever since I first saw QOI. The encoding and decoding times and relatively high compression were perfect for this use case it was just a matter of implementation. Because the VNC protocol with tight encoding breaks frame changes into 100s of tiny images it allows us to encode and decode in a threaded manner. This means high FPS and low latency on a truly lossless remote Linux desktop in…

Probably a naïve question, but why does it need to be run as privileged?

That is only the all in one container solution geared to home server users.

The standard install uses no priv containers. https://www.kasmweb.com/downloads

I only mention the Linuxserver container because most Linux/Docker users do not want to pollute their base OS with stuff just to try it out.

Re: Streaming lossless VNC to a web browser with Quite OK image format

#28

Post by LoganDark »

vanviegen wrote: post #24
fulafel wrote: post #8

Sad that in 2022 an "entire gigabit connection" is still considered a lot of bandwidth, the statement would have sounded the same 10 years ago and only slightly out of the ordinary 20 years ago.

Shrug. Why spend more when 100mbit is also enough for most purposes.

Because some ISPs (like the monopoly over here) give you only about 3% of your download speed in upload. No, that figure is not off by an order of magnitude - I have 900Mbps download and only 25Mbps upload. That's less than 3%. And they don't offer 25Mbps upload for any cheaper.

Sometimes you gotta take what you can get.

Re: Streaming lossless VNC to a web browser with Quite OK image format

#29

Post by krolden »

filleokus wrote: post #20

I still have a dream of a DIY thin client setup for remote development. I've spent a couple of weekends here and there over the past years trying out different servers and clients, but always struggled with anything non-VNC. Either on the server (linux) or client (macOS) side. What is the state of the art for remote desktoping from linux to macos/windows, over "almost lan" conditions (symmetric 1 Gbit ethernet, < 10…

Spice is good for that

https://www.youtube.com/watch?v=oLatrZBFQrw

Re: Streaming lossless VNC to a web browser with Quite OK image format

#30

Post by vlovich123 »

thelamer wrote: post #25
IshKebab wrote: post #12

Earlier quoted context omitted.

It makes more sense just to use a normal video codec. They can handle all sorts of situations efficiently that this can't e.g. scrolling, zooming and embedded videos. That is how NX4, Chrome, RuskDesk, Zoom, etc. all do it.

Yes video codecs are great but in almost every case they need a GPU. This functions with no special hardware. The only lossless option would be AV1 and that needs an Intel arc card or 4000 series Nvidia card. You also have an inherent latency issue as you have to buffer 2-5 frames at 16ms a pop server side to encode the data.

> You also have an inherent latency issue as you have to buffer 2-5 frames at 16ms a pop server side to encode the data.

Consider that oculus link uses video compression and doesn’t introduce the extra latency you’re describing. You only need to buffer frames if you want the best compression ratio. But you can always configure the encoder to not do look ahead. It’s also better to choose cbr over vbr to avoid the second pass of a frame at the cost of reducing quality/bitrate a bit. I’m practice it can work really well because even 20mbit/s is sufficient to send high res text.

I wish Remote Desktop applications would copy the oculus link architecture. You can easily get only a few frames of latency (sub 100ms) provided you composite on the GPU, use hardware encode/decode, and slice the video stream (which ie send 1/4 of the screen while encoding the next 1/4) which cuts down on decode latency and ensures you smear the expensive work across the entire refresh cycle time instead of having to do it all at once in a non-pipeline fashion (which introduces bubbles into scheduling).

Post reply on HN