On 2/22/16 3:47 AM, Marco Marino wrote: > Hi, I need some help with the plugin structure of virtualgl. I'm > studying the code of testplugin.cpp and from an old post (july 2015) I > know that: > > RRTransGetFrame(...) is called from virtualGL in order to get a new > frame from the plugin and > RRTransSendFrame(...) is called to send a new frame. > My questions are: > the plugin works both as "client and server"? The same plugin will call > RRTransGetFrame and then RRTransSendFrame ?? There is no server and > client part in the plugin?
Correct. The plugin can choose to implement its own client/server connection, or it can choose not to have a client/server connection at all (for instance, the X11 Transport doesn't have a client/server connection, apart from the connection to the X server.) RRTrans* are callback functions. The plugin doesn't call those functions. VirtualGL calls those functions when it reads back a frame from the GPU. The plugin architecture is designed to allow the plugin to maintain a pool of buffers, which is what VirtualGL's existing transports do. VGL calls RRTransGetFrame() in order to fetch an available buffer from the plugin (the plugin can block until a buffer is available.) VirtualGL then reads back the 3D pixels into the buffer and calls RRTransSendFrame() to tell the plugin that the pixels have been read back and that it's safe to compress/send the buffer. > In order to write my own plugin, I need to write a custom transport if I > need to to use x264 as encoder? Yes, you will need to write your own plugin for x264-- at least for now (I'm still investigating how best to deal with H.264 in both VirtualGL and TurboVNC in the long term.) > So, should I modify getFrame and sendFrame inside the transport adding > the encode and decode part? > I have other questions, but first I need to understand if I'm on the > right way.... > Thank you, > MM The decode part is not handled by the plugin. That will be handled by whatever client application you choose to write (or, if you decide to use some pre-existing protocol to send the H.264 frames, then you may be able to use an existing video player as the client.) The plugin is entirely server-side. The simplest (but probably not the more performant approach) would be for the plugin to compress/send the frame within the body of RRTransSendFrame(), but I would suggest instead doing what VGL does-- creating a separate thread to handle the compression/transmission. Again, you can refer to the example plugins (testplugin*.cpp) to see how this is done. It would be easy, for instance, to re-use the existing VGL Transport layer and simply add H.264 functionality to it, although that may not be what you ultimately want. ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ VirtualGL-Devel mailing list VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
