Re: [Ekiga-devel-list] preliminary patch for X-Video support

[Matthias Schneider <ma30002000 yahoo de>]

Hi Damien,

--- Damien Sandras <dsandras seconix com> schrieb:

> Hi Matthias,
> 
> Le lundi 11 septembre 2006 à 23:17 +0200, Matthias Schneider a écrit :
> > Hi all, 
> > a few months I had posted an email about integrating XVideo hardware acceleration into ekiga,
> > unfortunately I didnt find some time until a few weeks ago...
> > 
> > The image quality of XVideo is a lot better than SDL, also CPU drops significantly since the
> > dedicated hardware does the scaling and colorspace transform.
> > 
> > Enclosed I am sending a patch for ekiga 2.0.2. After applying, please run
> > 
> > patch -p1 < ekiga-2.0.2-xv-1.5.patch
> > aclocal
> > automake
> > autoconf
> > configure
> > ./configure [-disable-xv]
> > make
> > 
> > The XV support may be disabled at compile time with configure --disable-xv (or if the
> respective
> > libraries are not found).
> >   
> > Right now the XV implementation creates separate video windows that may be put into fullscreen
> > with the key "f", be made to stay on top with "o" and feature removable decorations "d".
> > 
> > I would like to raise a discussion about some of the issues that I have not yet resolved:
> > 
> > - window coordinates:
> >   Where should the Video windows be located? Right now they appear in the upper left corner of
> the
> > screen...
> > 
> 
> Is XV support intended to replace GDK or SDL?
> I would replace both if possible.

Ok, on compile time we have options: configured with --disable-xv and without.
If disable-xv is given to configure, the behaviour is like before, GDK for window mode and SDL (if
found and enabled) for fullscreen mode. On linux systems only (to answer Juliens question),
without the --disable-xv given, ekiga will make use of the XV code for window (fully scalable) and
fullscreen mode. 


> > - ptrace levels
> >   right now all PTRACEs are sent on level 1, however some messages are warnings, other pure
> debug
> > information. Could someone educate me about the respective levels?
> > 
> 
> >From my point of view:
> 1 is for errors.
> 3 is sane.
> 4 is intense debugging already.

Ok, implemented...
> 
> > - layout of video windows
> >   Right now all XV displaying makes use of a separate X-only window. I would like to ask if we
> > could review the display modes in ekiga, right now we have:
> >   local only
> >   remote only
> >   Picture inPicture
> >   SideBySide
> >   Two windows
> >   Fullscreen
> >   I find myself am only using fullscreen or a picture-in-picture in a separate window (which
is
> > missing from this list). I think it should be possible to paint XVideo into GTK windows
> > knowing the X-Windows handle for the respectire window, so possibly XV may be displayed inside

> > ekigas main window as well. However up to now, my efforts where unsuccessfull... 
> 
> You should ask for help to some GTK hacker. I can put you in contact.
> Notice that in CVS, SideBySide is gone.

Thank you that would be really nice.. Ok, I will quit sidebyside, and try to implement the
embedded window functionality. However I would like to add an PIP external window option. 

> >   Shall we add the PIP in external window? Shall we stick to all the others as well? What
about
> > the zoom stuff? My windows are freely resizable, no need for the 2x or 0.5x menu entries..
> > What about the Fullscreen menu entry? XV supports it, but what if we compiled with XV and have
> > to fallback to gdk and have no SDL compiled in? 
> > 
> 
> Then fullscreen should be disabled.
Ok so if we compile without SDL and XV we wont have / will have a disabled fullscreen option. 
In case we have to fallback from XV to GDK and do not have SDL compiled in we switch back to
window mode and dynamically disbale the fullscreen menu entry?


> I would really keep the video in the window, simply because this is how
> others are doing.
> 
Ok I will investigate like I said above..

> > - fallback to gdk if XV is not available
> >   The XVWindow classes init procedure returns NULL if XV cannot be properly initialized. In
> that
> > case a GDK renderer should be registered instead of the XV renderer. 
> >   Right now however I do not have the slightest clue how to do that, because the setframedata
> > function is called from opal, and I think it would be quite ugly to touch opal for such a
> feature.
> >   The PVideoOutputDevice constructor is called to early (startup) for opening the window
> already.
> >   How can we get the GDK output device registered in case XV is not available at run time
> (another
> > program using it and the graphics adaptor supporting only one XV port for example)
> > It would be really cool if I could get some support from someone who knows ekigas code better
> than
> > me..
> 
> I don't understand the problem.
> 
> Can you elaborate on the functions flow and what is the exact problem?

Ok I will try to describe the problem in a better way. Right now the implementation works like
this: either we enable GDK/SDL OR XV output at compile time. However even if XV is compiled into
ekiga, at runtime it is possible that:
- there is no support for XV by the graphics driver
- there is no free XV port available because another program is using it.
Right now in that case there simply is no window.  I suppose it would be nicer to have a fallback
to the GDK/SDL implementation. The problem I am facing right now that I do not know whether XV is
available until the first frame is to be displayed.

Right now the output device is set in manager.cpp GMMAnager::GMManager() statically to GDK/SDL or
XV (via the device variable in OpalManager)
I this correct? I have not yet fully understood how the different output device are handled in
ekiga/opal.
My question now is where and how could I possibly implement a fallback in case XV is not
available? Can I register a PVideoOutputDevice_GDK from inside the PVideoOutputDevice_XV class? Or
where could I start to implement something like that? 

Another idea would be to check once before registering the ouput device in GMManager::GMManager()
if XV is available and register the respective output device. This however would not cover the
situation that XV is available on a system, but no more ports are available.

I dont know if I make more sense than in my message from yesterday, perhaps it would be better to
use some code to demonstrateE?

Matthias
> 
> 
> > 
> >   I also have an nearly similar DirectX class waiting for ekiga, hopefully I will find some
> time
> > soon. Please let me know what you think about this XV class,
> 
> I like it :)
> 
> Thanks!
> -- 
>  _      Damien Sandras
> (o-     
> //\     Ekiga Softphone: http://www.ekiga.org/
> v_/_    FOSDEM 2006    : http://www.fosdem.org/
>         SIP Phone      : sip:dsandras ekiga net
>                          sip:600000 ekiga net
> 
> _______________________________________________
> Ekiga-devel-list mailing list
> Ekiga-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
> 



	

	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de