[Ekiga-devel-list] [Fwd: RE: # Re: Video Not working with Ekiga Trunk Version dated 7/2/07]

[Damien Sandras <dsandras seconix com>]

-- 
 _     Damien Sandras
(o-      
//\    Ekiga Softphone : http://www.ekiga.org/
v_/_   NOVACOM         : http://www.novacom.be/
       FOSDEM          : http://www.fosdem.org/
       SIP Phone       : sip:dsandras ekiga net

--- Begin Message ---

• From: Matthias Schneider <ma30002000 yahoo de>
• To: Damien Sandras <dsandras seconix com>
• Subject: RE: [Ekiga-devel-list] # Re: Video Not working with Ekiga Trunk Version dated 7/2/07
• Date: Tue, 3 Jul 2007 19:43:18 +0200 (CEST)

Hi Damien, could you forward this to the list? I already sent it to Anand directly. (I dont know
why the list again is eating my mails)
Matthias 
------

Hello Anand,

see my comments inline...

--- Anand R Setlur <asetlur alcatel-lucent com> schrieb:

> Matthias,
> You are correct I was expecting video to displayed in preview mode prior to
> making any calls. Are you suggesting that the behavior is different between
> Ekiga2 and the future Ekiga3.0 . Does only Ekiga3 use direct draw and the other
> one does not? I will try to make a video call and send a followup e-mail
> as to whether video works fine when in the calling mode.

Ekiga output was completely rewritten and improved for release 3.00. In 2.x all output was done
via GDK, i.e. using software scaling and drawing. On 3.00 we support XVideo hardware acceleration
on Linux and DirectDraw hardware acceleration on windows. This decreases CPU load impressively,
allows fullscreen and higher frame rates and also provides better video quality since the graphics
adaptor is also doing anti-aliasing. In case the accelerated output is not available (should not
really happen on windows), we automatically fall back to the "old" gdk software rendering. Right
now the issue you are experiencing is due to the decision we have to take of when to redraw both
local and remote images, which are unsynchronized in their arrival. I think it is bad from a
performance perspective to redraw at both events, so right now on windows we refresh the image
only on arrival of a remote frame (there is a architectural reason why we cannot do it on arrival
of local frame like we do on Linux XVideo). The plan is to switch between refreshing on arrival of
a remote and a local frame dynamically, depending which arrives at the higher frame rate (i.e.
also when remote framerate =0)

> 
> Regarding the ffmpeg misalignment, my compile date is yesterday and so should
> have included your fix if that was dated two weeks ago. I am using a Debian etch
> system for compilation purposes. What was the nature of your fix and did it
> count on a specific version of the compiler or other build environment?
> 

Hmm, actually the fix was not by me, I just noticed that the error message disappeared some time
ago and I read a comment that said it was fixed:
http://openh323.cvs.sourceforge.net/openh323/opal/plugins/video/MPEG4-ffmpeg/mpeg4.cxx?view=log#rev1.7

I will try to check again when I find some free minutes

Regards,
Matthias

> Regards,
> Anand
> 


      __________________________________ Wissenswertes zum Thema PC, Zubehör oder Programme. BE A BETTER INTERNET-GURU!  www.yahoo.de/clever

--- End Message ---