[thelamer]

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 your web browser. The easiest way to try this out is an all in one docker container https://github.com/linuxserver/docker-kasm . To try it ephemerally on a Docker host simply run:

docker run --rm -it --privileged -p 3000:3000 -p 443:443 linuxserver/kasm bash

I had spent a long time trying to simplify Linux Desktop application delivery with linuxserver/webtop and all the derivative dedicated app images, but the speed and quality was always lacking as it was using XRDP in tandem with Guacamole. The difference with this new KasmVNC https://github.com/kasmtech/KasmVNC implementation is night and day. Depending on client hardware it will deliver 60fps 1080p and 40-60fps 1440p for both the JPEG and QOI rendering modes. A quick video can be seen here https://youtu.be/VkzG5BU2gjo .

[IshKebab]

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.

[thelamer]

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.

[vlovich123]

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

[Veliladon]

When doing streaming for realtime interaction you don't use B-frames. You typically just have P-frames and slices of I-frames. Max one frame of latency and pretty consistent data rates.

And just about every phone, tablet, laptop, desktop made in the past decade has some form of H.264 fixed-function hardware decoding.

[arcastroe]

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

[thelamer]

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.

[ZiiS]

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.

[Lex-2008]

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!