Thanks for your answer. As you told "H.264 doesn't benefit all applications-- mainly it will only improve the situation for games and other very video-like workloads". And this is my purpose! I need a reliable, high latency network compatible "transport". I'm interested in gaming, and video reproduction but i want (!) to use linux, and i thought that VirtualGL could be an option. Use a low JPEG quality is not a solution for me, I need good image quality. Write a transport plugin could be a solution? What i have to study before I can write a transport plugin? Have you some example (yes, i know testplugin.cpp) ? Thank you, MM
2015-05-27 9:42 GMT+02:00 DRC <dcomman...@users.sourceforge.net>: > 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 >
------------------------------------------------------------------------------
_______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
