[Ekiga-devel-list] Video: Performance optimizations and issues

[Matthias Schneider <matthias schneider TU-Ilmenau DE>]

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.