OK, then yes, with the qualifications that you mention (a workload that updates a predictable area of the screen in a predictable way, i.e. games & video applications; low-bandwidth; reasonable image quality), then a video codec such as H.264 is definitely going to be the best solution.
I am working with some engineers at nVidia to look into how to integrate H.264 with VirtualGL and TurboVNC, but we are still just bouncing ideas around at this point. I don't know if we'll come up with anything concrete in the timeframe you need. And since you're a student, writing a transport plugin would be a good exercise. Study testplugin.cpp. Some things you'll have to consider: -- how to handle the delivery of images over the network. The VGL Transport is really designed for use along with a remote X server, so it's probably not the right protocol for you to use. What would be Really Cool(TM) is if you could leverage an existing streaming video protocol. -- how to handle the delivery of keyboard/mouse events from the client to the server. When you're dealing with an immersive application, such as a game, for which window and GUI management are irrelevant, you could do something clever, such as using an Xvfb instance on the server side to act as a 2D X server. Xvfb would be used solely for event management. Your plugin would intercept keyboard/mouse events from the client and inject them into the Xvfb instance so that the 3D application will receive them via its X event queue. No actual pixels will be drawn into that X server-- the pixels will be intercepted by the VGL plugin and sent directly to the client. You are not required to open source any of your work (VGL plugins can be proprietary), but if you choose to do so, I'll be happy to review it for possible inclusion in VirtualGL. Also, you should investigate whether libx264 is a faster solution than FFmpeg for compressing H.264. Please feel free to ask follow-up questions on the virtualgl-devel list. On 6/12/15 12:17 PM, Marco Marino wrote: > 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 > <mailto: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 > <mailto: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 > ------------------------------------------------------------------------------ _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
