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

["Anand R. Setlur" <asetlur alcatel-lucent com>]

Matthais,
Thanks for the summary relating to DirectDraw. I can confirm now that I
do see video in the future Ekiga 3 client when in the call mode unlike
when in the preview mode.

Damien,
My first call succeeds and subsequent calls get stuck at the 200ok stage
and the message does not make it to the far end. What version of  opal
should I be using since the head version of OPAL is known to broken
and will only be fixed at a later point?

Thanks
Anand

On 7/3/2007 1:49 PM, Damien Sandras wrote:
> 
> ------------------------------------------------------------------------
> 
> Subject:
> RE: [Ekiga-devel-list] # Re: Video Not working with Ekiga Trunk Version
> dated 7/2/07
> From:
> Matthias Schneider <ma30002000 yahoo de>
> Date:
> Tue, 3 Jul 2007 19:43:18 +0200 (CEST)
> To:
> Damien Sandras <dsandras seconix com>
> 
> 
> 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
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ekiga-devel-list mailing list
> Ekiga-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/ekiga-devel-list