Welcome • User Guide
ToS • Privacy • Canary
Donate • Bugs • License

©2025 Poal.co

730

It would have to allow access to only the single app and no extra permissions aside from what the app had natively. So ie we can't use Xpra, which would be a wonderful solution otherwise. Consider also you'll have access to the source of the apps you want to forward visually and the control of over to the browser. And they'll be in c/c++ and you'll have written them yourself so you're well familiar with the code.

What approach would you use to forward them visually live to a browser and forward back control of just the native running app?

It would have to allow access to *only* the single app and no extra permissions aside from what the app had natively. So ie we can't use Xpra, which would be a wonderful solution otherwise. Consider also you'll have access to the source of the apps you want to forward visually and the control of over to the browser. And they'll be in c/c++ and you'll have written them yourself so you're well familiar with the code. What approach would you use to forward them visually live to a browser and forward back control of just the native running app?

(post is archived)

[–] • 1 pt

Sounds like a security nightmare

[–] • 1 pt

The approach I'm looking at / developing at the moment is I'll grab the frame buffer of the app, run my own self developed micro http server, the the httpserver will then upon connect stream what it claims is video file but will in fact be a live encoded video that just started at the beginning of that connection of the frame buffers given to the httpserver.

If that works then the browser will feedback events like mouse movements and keys back to the httpserver through websocket and then the httpserver back to the app.

[–] • 1 pt

Actually got the custom http server / live encoding approach to work... Had to prebuffer 500k of data to get the browser to accept it (wget etc would work without pre buffering the send). Now the browser refuses to play without a buffer (even though I gave it one). So the best I can get (so far) is like a 3 second lag. Even like 200ms is unacceptable.

The more I get into this the more I think the browsers are INTENTIONALLY trying to bug and stop live streaming. My guess is so big names like youtube / twitch can have the market.

So far it looks like the only real way is to write your own native deencoder with WebAssembly, something I had never heard of until a few days ago even though it's been supported for many years, and then deencode and render yourself.

[–] • 0 pt

Why not just rewrite the code and make it a legit web app?

[–] • 0 pt

I need to demo native code I'm writing. Also I'd like to possibly make a "solution" / lib out of this where I can turn any app into a webapp.

One idea I had was override all the opengl calls and essentially just forward them to the browser through a websocket, and then just let the browser do the opengl calls instead, which javascript can do.

[–] • 0 pt
[–] • 1 pt

Holy shit that might actually work thanks! At least for the long run of making a native browser run version of the app!

[–] • 0 pt

I would have the customer open a web browser based Teams, I open an app based Teams call and I share-screen my app, and then allow the 3rd party to control mouse if needed.