Re: [Ekiga-devel-list] preliminary patch for X-Video support
Hi, dont worry I am also interested in a working windows port... As I mentioned I would also like to put DirectX into ekiga... The XV code is active ONLY on linux AND when the respective libraries are found, in every other case the original GDK/SDL code is compiled. Matthias --- Julien PUYDT [EMAIL PROTECTED] schrieb: Matthias Schneider a écrit : Hi, sure, SDL can provide hardware overlay with the following constraints: - only available when run as root - only DGA driver (framebuffer in console mode) - acceleration only available at fullscreen - tries to switch to a resolution close to the overlay resolution I'm convinced! But please leave us with a working win32 port ;-) Snark ___ 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 ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] preliminary patch for X-Video support
Hello, if I understand you and Julien correctly the best aproach would be: write a wrapper PVideoOutputDevice_ekiga that registers with OPAL (in GMManager::GMManager()) and may switch between multiple PVideoOutputDevices dynamically? (right now that would be GDK/SDL and XV) However this requires a change of the PVideoOutputDevice interface specifications if I am not mistaken, we need some way to signal back to the wraper device that something has gone wrong and we have to select the next-priority device. This could be e.g. - a init function that returns some value - let the setframedata function return some information - both Please let me know if I understood correctly and my conclusion is correct. Matthias --- Damien Sandras [EMAIL PROTECTED] schrieb: Le mardi 12 septembre 2006 à 21:35 +0200, Matthias Schneider a écrit : Hello, 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? I think that unfortunately you not switch from one PVideoOutputDevice to another once it is open. Doing so would require changes in OPAL. Perhaps Craig can comment on this? So I see two solutions : - Modify OPAL so that you can change from one PVideoOutputDevice to another during a call - Create a new PVideoOutputDevice_Ekiga class from the current GDK one that is able to draw using xv and fallback to SDL or GDK if it is not possible. Perhaps there is a third option: - instanciate a PVideoOutputDevice_GDK from inside PVideoOutputDevice_XV, convert the frame on receipt from YUV420P to RGB in PVideoOutputDevice_XV and send them to the PVideoOutputDevice_GDK instance? Is that possible? I would like to keep the XV and GDK output code separated... Perhaps it also makes sense to move some of the outut code in main.cpp to videooutput_gdk.cpp? What I would do is the following : - A generic class unable to display - A few other classes, to handle the display -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_FOSDEM 2006: http://www.fosdem.org/ SIP Phone : sip:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] ___ 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 ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] preliminary patch for X-Video support
Hi, Le mardi 12 septembre 2006 à 21:49 +0200, Matthias Schneider a écrit : Hello, if I understand you and Julien correctly the best aproach would be: write a wrapper PVideoOutputDevice_ekiga that registers with OPAL (in GMManager::GMManager()) and may switch between multiple PVideoOutputDevices dynamically? (right now that would be GDK/SDL and XV) I'm not sure if it is what Julien means, but that's what I meant indeed. However this requires a change of the PVideoOutputDevice interface specifications if I am not mistaken, we need some way to signal back to the wraper device that something has gone wrong and we have to select the next-priority device. This could be e.g. - a init function that returns some value - let the setframedata function return some information - both Please let me know if I understood correctly and my conclusion is correct. The upper-level class would have its own SetFrameData function. But that function wouldn't be called, it would be overloaded and the SetFrameData function of the specific display device would be used instead. When it fails, it would fallback. Julien can elaborate on this, as he has already thought a lot about it. Matthias --- Damien Sandras [EMAIL PROTECTED] schrieb: Le mardi 12 septembre 2006 à 21:35 +0200, Matthias Schneider a écrit : Hello, 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? I think that unfortunately you not switch from one PVideoOutputDevice to another once it is open. Doing so would require changes in OPAL. Perhaps Craig can comment on this? So I see two solutions : - Modify OPAL so that you can change from one PVideoOutputDevice to another during a call - Create a new PVideoOutputDevice_Ekiga class from the current GDK one that is able to draw using xv and fallback to SDL or GDK if it is not possible. Perhaps there is a third option: - instanciate a PVideoOutputDevice_GDK from inside PVideoOutputDevice_XV, convert the frame on receipt from YUV420P to RGB in PVideoOutputDevice_XV and send them to the PVideoOutputDevice_GDK instance? Is that possible? I would like to keep the XV and GDK output code separated... Perhaps it also makes sense to move some of the outut code in main.cpp to videooutput_gdk.cpp? What I would do is the following : - A generic class unable to display - A few other classes, to handle the display -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_FOSDEM 2006: http://www.fosdem.org/ SIP Phone : sip:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] ___ 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 ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_FOSDEM 2006: http://www.fosdem.org/ SIP Phone : sip:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] preliminary patch for X-Video support
mcquaid mcquaid [EMAIL PROTECTED] writes: I'm just a user but with a couple of questions. I thought that sdl can have access to hardware overlay? Also, I thought that only 1 window can have access to hardware overlay, so how is pip dealt with in this regard? Depending on your graphics card you can have multiple XVideo ports. Matrox cards, for example, support using textures to handle XVideo in which case they give you 32 ports. -- greg ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
