For video encoding you may want to think about encoding deltas instead of sending full compressed frames.

Also, even in the case of full-frame compression, some games will do better with more primitive image compression algorithms, as JPEG is tuned for photos.

Don't forget about sound too.

I've thought about trying to see what DOSBox looks like over Remote Desktop with output=surface.

src/gui/sdl*

I don't see how sending jpeg's would be better than how RDP handles it.

> ... through a normal web browser

😁

Well as long as the "normal web browser" is IE he should be good to go! 😁 (Although RDC 6.1 will need to be on the client computer)

Meh, I've used VNC viewers that are Java based, and some VNC servers even provide browser-based viewing. VNC isn't as responsive or accurate as RDP on Windows in my experience though. Anyways, the point is just because it's browser-based doesn't mean you need to use a rapid-fire sequence of JPEG screenshots. You could probably even decode an MPEG stream in Java for example.

wrt using RDP, we are aiming for a system which is highly portable and can run anywhere a browser can, using RDP would probably work, and possibly faster than what we end up with, but is not suitable for this project as it would place a requirement on the client we find unsatisfactory.

The primary sources of latency in the original system (using JPC as emulator) were the hardware virtualization, JPEG encoding time and the time taken to transfer the image back. I suspect that MPEG encoding would increase the latency as there would be another level of decoding required. The current synchronous nature of the architecture (Keyboard/mouse input is sent to server which sends a new frame in response) would also need to be completely overhauled.

Sending PNG instead of JPEG would be nice, but PNG compression has taken longer in our experience, anyone know of a super quick tool to do PNG compression?

Currently im investigating how best to transfer audio without getting out of synch with the video.
We thought of maybe having a small buffer client side that holds a collection of the most recently played sounds, as they tend to be played repeatedly, but that would still introduce a delay when the soundfile is sent the first time.
Another option is to preload all sounds to the client, but that is a last resort as it is then not really a "thin" client.
A streaming solution that simply directs the output of dosbox to the client as it is produced is currently favourite, but again, the client is likely to need specialist software capable of receiving the stream.

Anyone know how heavily dosbox uses SDL? If all video/audio/input passes out through SDL then i can probably just interface with that and let dosbox do its thing.

Thanks for the ideas guys, keep em coming.