| Thank you. I'm actively trying to improve latency. To answer your questions: - This is webp images (where available, else jpeg) demand-streamed to the client over WebSocket binary channel. For webp, they are encoded server-side using cwebp from the original JPEGs. - The servers in this demo are hosted in GCP us-west3 (Salt Lake City, Utah) Also, some possible improvements to streaming I intend to look at are: - stream frames as they are available, rather than when the client requests them (which it does at a small regular interval, or whenever the client performs some action) - encode the raw PNG frames to h264 with ffmpeg - use Chrome Extension desktopCapture API (similar to navigator.mediaDevices.getDisplayMedia) with xvfb (no headless) and send the resulting stream either through the server, or p2p using WebRTC I initially didn't develop it to handle high framerates or high quality (it's more of a debug tool, and delivery system for a web scraping app), but people are requesting this. MightApp has been in beta for a long time. Handling massive streaming and combining it with interactivity, and making the economics work, is not trivial. Despite people's requests for better video quality, and my willingness to be responsive to those, I still have my heart firmly set on providing the best experience with the minimum amount of bandwidth and the lowest framerate and lowest quality (as in, resolution) possible. I just think this is more efficient, and will end up being more scalable, and it fits well for my initial web-scraping tool use-case. My biggest fear about this feature is lag to the point of unusability, which happens whenever the bandwidth is larger than the capacity. You get a backlog of inflight frames, and the usability goes to shit because everything takes x seconds to occur, and then you're behind anyway. I'm reminded of that nightmare scape video of people inside an Oculus delay chamber trying to pick up a feather from the floor. Glitch in the matrix. |