Depending on what you really need to do, it may not be necessary to get that fancy. Most users of VirtualGL use it with an X11 proxy. TurboVNC is the X proxy that our project provides and which has features and performance specifically targeted at 3D applications, but there are other X proxies that work with VGL as well (although usually not as fast as TurboVNC.) The X proxy, when combined with VirtualGL, will cause all of the 2D (X11) as well as 3D (OpenGL) rendering commands from the application to be rendered on the server and sent to the client as image updates. TurboVNC specifically has a feature called "automatic lossless refresh", which allows you to use a very low JPEG quality for most updates, but when the server senses that you have stopped moving things around (such as when you stop rotating a 3D scene, etc.), it will send a lossless update of the screen. X proxies also do a much better job of handling high-latency networks, since they are sending more coarse-grained image updates instead of very fine-grained and chatty X11 updates over the network.
VirtualGL can also operate without an X proxy, but this is less useful on high-latency networks, because it requires that the non-3D-related X11 commands be sent over the network to the client machine. Even though the 3D-related X11 commands are being redirected by VirtualGL and are being rendered on the server, the 2D-related X11 commands used to draw the application GUI, etc. are still sent over the network, and that can create performance problems on wide-area networks. Now, to more specifically answer your question-- you can reduce the JPEG quality in VirtualGL, which will significantly reduce the bandwidth. Using TurboVNC will likely reduce the bandwidth as well, not only because the X11 stuff is being rendered on the server but because TurboVNC has a more adaptive compression scheme, whereas VirtualGL uses plain motion-JPEG. I'm currently working with nVidia to research possible ways of leveraging their NVENC library to do H.264 compression in VirtualGL, but there are a lot of technical hurdles we haven't figured out yet vis-a-vis how that would interact with X proxies such as TurboVNC. Also, H.264 doesn't benefit all applications-- mainly it will only improve the situation for games and other very video-like workloads. More tradition 3D applications (CAD, visualization, etc.) are already quite optimal with TurboVNC's existing compression scheme. VirtualGL does have a transport plugin API, so you could conceivably use that to write your own transport plugin based on the existing VGL Transport code (see server/testplugin.cpp for an example) but which uses ffmpeg instead of libjpeg-turbo to do the 3D image compression. Whether or not that would really improve bandwidth usage would depend a lot on your specific workload. On 5/27/15 1:31 AM, Marco Marino wrote: > Hi, > i'm a student and i'm trying virtualgl for education purposes. From my > tests with vglrun I saw that huge amount of bandwidth is required for > acceptable image quality (eg: -c jpeg with quality 90 requires peaks of > 50/60 Mbits). Is there a way to compress the video flow? Can i do > something like: "VGLSOCKET" -> My compression library (like ffmpeg or > similar) -> TCP/UDP socket ? In practice i want try to compress with my > own code the output of VGL. Is this possible? I'm sorry if this is a > stupid question, but I don't have knowledge about virtualgl. > Thanks ------------------------------------------------------------------------------ _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
