In light of new information from the open source community that revealed how to extract better compression ratios out of x264, as well as new research on my part regarding how to coalesce framebuffer updates and avoid compressing the whole framebuffer for every single tiny update, I have upgraded my opinion of the technology from "generally useless" to "narrowly useful" and updated the report accordingly:
http://www.turbovnc.org/About/H264 I still find that H.264 doesn't compress as well as the TurboVNC encoder (and, by extension, the TigerVNC encoder) for most workloads, so its potential usefulness is going to be limited to only a subset of applications (games, Google Earth, basically apps that generate predictable motion between frames.) It doesn't seem to work well with CAD apps at all, and I still think that frame spoiling may reduce the effectiveness of H.264 in a real-world remote 3D environment. I also still think that the x264 codec is too slow for most multi-user TurboVNC deployments. For the workloads that benefit from H.264, it can be CPU-limited on even connections as slow as 3 Megabits/second. The whole point of H.264 is to squeeze more frames/second out of WAN connections, but if it's CPU-limited, then it doesn't matter that it's reducing the bandwidth-- the frame rate will stay the same. However, I think that H.264 could be beneficial on very slow connections-- for instance, if I wanted to play a game remotely over a 3-megabit DSL line, H.264 would be the way to do it. For anything greater than 10 Megabits/second, though, you're probably going to be better off with the TurboVNC encoder. I now think that H.264 warrants more study. It might be of sufficient usefulness that it would be worth including in a future release of TurboVNC, if for no other reason than to give the community a chance to further evaluate it in real-world environments. Whether or not it would be advantageous relative to the existing TurboVNC low-quality encoding method, however, would depend on the app. Integrating it into TurboVNC might also prove tricky, since it would have to interact with the existing deferred update timer and RFB flow control extensions (both of which already act as a sort of frame rate governor.) DRC ------------------------------------------------------------------------------ _______________________________________________ TurboVNC-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/turbovnc-users
