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... - get the -display command line parameter Right now the XVWindows will be created on the DefaultDisplay. I would prefer making them appear on the display specified on the command line (if it was specified) - 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? - 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 th respectire window, so possibly XV may be displayed inside ekigas main window as well. However up to now, my efforts where unsuccessfull... 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.. Also 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? - 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 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, bye Matthias ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Attachment:
ekiga-2.0.2-xv-1.5.tar.gz
Description: 1198927105-ekiga-2.0.2-xv-1.5.tar.gz