Hi Damien, hi all, the videoouput procedure of ekigas PVideoOutputDevice s works like this: There are two instances of the selected PVideoOutputDevice, one for the local frame and one for the remote frame that have two shared variables that store the pixels of the current frame that is /is to be displayed (lFrameStore, rFrameStore).
On decoding / grabbing of a new frame a pointer is passed to SetFrameData of the the respective PVideoOutputDevice instance, where it gets colorspace-converted or simply memcopied to the local shared variable. Right now SetFrameData calls EndFrame that calls Redraw where the redrawing takes place. Now there are various approaches when the actual drawing may take place. When using GDK output, redraw calls gm_main_window_update_video in main.cpp everytime whether the frame that was copied/converted was a local or remote one. My XV output works a little bit different, in videoouput_xv the instance for the local frames is the "owner" of the actual XVWindow object. An update for both local AND remote frame is only performed when the local frame instance is called - in SetFrameData of the remote frame instance is called, only the data is copied to rFrameStore. So both approaches do have some disadvantages. If on copying/converting of a local and remote frame both images are redrawn we face severe performance implications. Assuming a framerate of 25 frames/s both both local and remote video signals we would now face 50 redraw operations per second for BOTH the local and remote frame, although it would ne sufficient to do it 25 times/s (thus a performance overhead of 100%?). The trouble for drawing only on receiving a local frame is that the local framerate could be a lot lower than the remote frame rate (e.g. remote framerate of 25 frames/s and a static image as local frame which gets updated in the multiple-seconds range). The same would apply for redraw operation on the reception of a remote frame. Also this would additionally lead to the problem that on loss of data transmission without a proper call termination the redraw routine would simply no longer be called and thus also not the signal handler for the xv window which could lead to severe problems especially in FS mode. So what are our options now? Right now two methods come to my mind: A) Recognize the stream (local or remote) with the higher framerate and enable redraw in in the respective instances B) Trigger the redrawing independently from the SetFrameData calls by a timer (e.g. 25 /s) What do you think? I think that A) could lead to the same issues like I mentioned for the remote frame trigger. A second issue I am facing for DirectX is that I get a wrong window handle error when deleting the dxWindows in ~PVideoOutputDevice, although the window gets deleted and everything cleaned up quite fine. All the DirectX stuff must be called from the same thread, is it possible that the destructor ~PVideoOutputDevice is called from a different thread than SetFrameData ? If yes, how could we resolve this issue? For the DxWindow constructor its no problem since I manage it in SetFrameData anyway, but the destructor cannot be handled there. It seems not to be of a problem for XVideo though... Thank you in advance for your comments, bye, Matthias ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list