it doesn't implement the microsoft RDP protocol, does it? I want to port the server for linux, using NvFBC instead of DX.

[hradec]

I'm just wondering if you really using the RDP protocol, or if the rdp in the name is just for "remote Desktop"...

But I'm very interested in build the server in linux, as an attempt to create a faster remote desktop solution in linux, that can support 30 or even 60fps in 4k. (like parsec does in windows!)

Although the final goal is not for gaming, I want to use gaming as a sort of latency/quality "benchmark"... If I can use it for gaming (like parsec), it's more than perfect to use for VFX desktop applications, for example.

Would you have some tips on what I would need to re-write in order for the server to work in Linux? (apart from adding NvFBC->NvEnc to the capture)

Have you ever tried running the server on a linux machine before?

Have you ever attempt to run the client on a linux machine, other than raspberryPi with openMax?

thanks in advance...
-H

[jean343]

Hello, and thank you so much for the question,

I am always looking at remote desktop solution type, and I haven't heard of parsec, this is my new favorite tool now.

You are right, RDP stands for "remote Desktop" and is not related to the windows protocol, I picked the wrong name back in the days.

I was able to get 60fps at 1080p on a RaspberryPI 3, and about 10fps at 4k on that same PI. I would suspect that we could get much better performance on a RaspberryPI 4.

In my previous project, we were displaying a Windows application on a video wall, and the Windows -> Raspberry PI link was logical. I have not tried to run this solution on any other configurations.
The Server code could be transformed to run on a Linux server by changing the WDDM capture code. The client code is quite specific to the RaspberryPI, and I am not aware of any other popular systems running OpenMax.

The overall solution is relatively simple.
On the server, run a frame grab 60 times per second, encode this stream as h.264 on an hardware accelerator, and send the stream to the client which will decode it as a video.

As they say on parsec, it is very tricky to get low latency, every step of the process adds latency. I measured this solution at around 300ms latency, it was and is still used in production today, and it feels more like 150ms.

I hope it helps.