WelcomeUser Guide
ToSPrivacyCanary
DonateBugsLicense

©2025 Poal.co

1.1K

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

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.