3 ms·

I actually have not engineered the streaming portion, so latency is the same as current VNC and RDP protocols. To get the product together as fast as possible

I actually have not engineered the streaming portion, so latency is the same as current VNC and RDP protocols. To get the product together as fast as possible (first line of code written three months ago), I actually did not reengineer the remote desktop protocol. In fact, the current product simply gives you the IP and password info to plug into your Windows Remote Desktop client app. Future plans are to integrate RDP into the Booste app, to make the experience seem more native. After that, I'll be implementing the modern H.265 protocol used by videogame streaming companies such as Vectordash and Nvidia GeForce Now.

mgamache 7y ago
h.265 will require hardware compression on the encode side (GPU) so you'll have to factor that into the cost.
- edunteman 7y ago
  For sure! Glad to have the tech insight. I already tether a GPU to the encode side for the 3D design apps, but I'll certainly need to rebuild for scaleability in the future.
seabrookmx 7y ago
> I'll be implementing the modern H.265 protocol used by videogame streaming companies Are you sure that's the right solution? Remote desktop is able to render sharp fonts because its sending a lot of desktop contextual information over the wire, as opposed to just doing a dump "capture the screen, encode it, and send" like the videogame streaming systems do. In a videogame, you can get away with small fringes on things (compression artifacts) but it would be quite jarring in your text editor. I've actually ran into this with the NX protocol (NoMachine) before, and it's one of the main reasons I went away from it.
- GordonS 7y ago
  I agree with this, and it's exactly the reason why RDP is a vastly better experience than VNC. Using VNC on a LAN isn't great, but over WAN it's a truely miserable experience.
- edunteman 7y ago
  Cool insight here that I was unaware of. I'm still assessing solutions. It really all depends on which use cases I end up focusing on. The initial idea was for 3D design (IE Solidworks), in which case the H.265 protocol would handle the more graphical, non text-based, visuals. This HN launch was to test out the developer markets, and it seems to resonate enough where I'd consider a way to transmit and render text as text rather than a screen capture.

mgamache 7y ago

h.265 will require hardware compression on the encode side (GPU) so you'll have to factor that into the cost.

edunteman 7y ago
For sure! Glad to have the tech insight. I already tether a GPU to the encode side for the 3D design apps, but I'll certainly need to rebuild for scaleability in the future.

seabrookmx 7y ago

> I'll be implementing the modern H.265 protocol used by videogame streaming companies Are you sure that's the right solution? Remote desktop is able to render sharp fonts because its sending a lot of desktop contextual information over the wire, as opposed to just doing a dump "capture the screen, encode it, and send" like the videogame streaming systems do. In a videogame, you can get away with small fringes on things (compression artifacts) but it would be quite jarring in your text editor. I've actually ran into this with the NX protocol (NoMachine) before, and it's one of the main reasons I went away from it.

GordonS 7y ago
I agree with this, and it's exactly the reason why RDP is a vastly better experience than VNC. Using VNC on a LAN isn't great, but over WAN it's a truely miserable experience.
edunteman 7y ago
Cool insight here that I was unaware of. I'm still assessing solutions. It really all depends on which use cases I end up focusing on. The initial idea was for 3D design (IE Solidworks), in which case the H.265 protocol would handle the more graphical, non text-based, visuals. This HN launch was to test out the developer markets, and it seems to resonate enough where I'd consider a way to transmit and render text as text rather than a screen capture.