Live data from Hacker News

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

kasmweb.com

11–20 of 36 posts

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

#11

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.

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 inefficient too but you wouldn't say that means the idea of encoding animated images as bitmaps is a bad one.

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

#12
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.

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

#13
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?

github repo mentions they use Docker in Docker and link to the docker.com article from 2013 where the -privileged flag introduced (with one dash?). So maybe the container you download is actually just a "wrapper" to setup a "real" kasm setup? But it's just my guess!

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

#14
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?

This is running a full desktop as a service system that uses docker in docker to provide multiple full remote desktops each with login etc.

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

#15

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 encoding, passing framebuffers isn't necessarily such a bad option. You just have to make sure that the CPU doesn't touch the framebuffer before encoding and after decoding.

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

#16

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.

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...

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

#17

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.

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…

The original incarnations of RDP, going back 20 years and more, preferred graphics when it could. Back then, it was more bandwidth efficient, and most programs actually used the GDI primitives to draw directly onto the screen, so it actually worked.

But IIRC, by 2007, it switched completely to sending tiles just like VNC.

However, if you read the protocol descriptions, you get the wrong idea that primitives are still used.

Similarly, most X11 clients have been doing everything client side for ages, but many people still believe that peimitives dominate.

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

#19

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.

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…

VNC, the protocol, isn't at all inefficient. There are some encoding methods which are inefficient, but I'd say that more "modern" encoding methods such as "tight" aren't all that bad, depending on how they're implemented. There has also been a recent addition of h264 to some implementations.

An example of a truly inefficient encoding method is ZRLE. It is a tiled zlib and run-length encoded format that can't be split up into multiple jobs because future computation depends on past computation.

They got things right with the tight encoding method of which there are two variants: zlib (lossless) and jpeg. With zlib, you can have up to 4 separate zlib streams, which means that you can utilise 4 CPU cores for encoding in parallel. The jpeg method has no such limitations.

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

#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 ms rtt)? Enterprise VDI solutions I've used at work has worked better than anything I've managed to put together, especially if you consider stuff like streaming audio from the host...

Post reply on HN