video sink to update OpenGL texture?
Locked
video sink to update OpenGL texture?
 
|
Hi,
I'm trying to use Gstreamer to display video in a presentation tool which is written in python and uses OpenGL for rendering. For displaying video, the idea is to update an associated OpenGL texture after a frame has been decoded. Can anyone tell me how this is best done. I was looking for something like a "memory video sink" from where I can grab the video frame after it has been decoded and update the OpenGL texture. Ideally the sink would also support synchronization from the client. Thanks, Martin ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: video sink to update OpenGL texture?
|
|
Hi Martin, We developed a toolkit for OpenGL called Pigment and that is used by Elisa Media Center. https://code.fluendo.com/pigment/trac It provides a video sink that will import the video frames in a texture using pixel shaders to optimize colorspace conversion. The toolkit makes it easy to do animations. Hope this helps, Best regards, Julien Moutte, FLUENDO S.A. Martin Luessi wrote: > Hi, > > I'm trying to use Gstreamer to display video in a presentation tool > which is written in python and uses OpenGL for rendering. For > displaying video, the idea is to update an associated OpenGL texture > after a frame has been decoded. Can anyone tell me how this is best > done. I was looking for something like a "memory video sink" from > where I can grab the video frame after it has been decoded and update > the OpenGL texture. Ideally the sink would also support > synchronization from the client. > > Thanks, > > Martin > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > ------------------------------------------------------------------------ > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: video sink to update OpenGL texture?
|
|
On Fri, 2009-03-20 at 23:04 +0100, Julien Moutte wrote:
> Hi Martin, > > We developed a toolkit for OpenGL called Pigment and that is used by > Elisa Media Center. > > https://code.fluendo.com/pigment/trac > > It provides a video sink that will import the video frames in a texture > using pixel shaders to optimize colorspace conversion. Clutter and the gst-plugins-gl module are other options you might explore. For the rawest output, where you're doing all the other GL operations yourself, you probably want the gst-plugins-gl stuff, but you'll have to get it from git - there's been no release tarballs yet. Cheers, Jan. -- Jan Schmidt <[hidden email]> ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: video sink to update OpenGL texture?
|
|
> Clutter and the gst-plugins-gl module are other options you might
> explore. For the rawest output, where you're doing all the other GL > operations yourself, you probably want the gst-plugins-gl stuff, but > you'll have to get it from git - there's been no release tarballs yet. > > Cheers, > Jan. > -- Thanks Jan, I installed gst-plugins-gl from git and did some first experiments. This seems to be what I'm looking for. Is it correct that I would use 'glimagesink' and do the drawing using the client-draw-callback? I'm not experienced with OpenGL, is it safe to just redraw the part of the scene that shows the video in the callback? I'm wondering as this callback function is called by a gstreamer thread and if the application is doing other OpenGL stuff or contains more than one video display, multiple threads are doing OpenGL drawing operations simultaneously. If this does not work I guess I will need to synchronize the draw callbacks of the glimagesink with the main draw function of the application. Another question, I'm using glimagesink from Python and try to connect the callback like this: self.videosink = gst.element_factory_make('glimagesink', 'videosink') self.videosink.set_property('client-draw-callback', self.draw_callback) But I get an error: TypeError: could not convert argument to correct param type Can anyone tell me the correct way of setting the callback in Python? I also tried self.videosink.connect('client-draw-callback', self.draw_callback) But this doesn't work either (error: unknown signal name: client-draw-callback) Thanks, Martin ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: video sink to update OpenGL texture?
|
|
Hi,
> Thanks Jan, I installed gst-plugins-gl from git and did some first > experiments. This seems to be what I'm looking for. Is it correct that > I would use 'glimagesink' and do the drawing using the > client-draw-callback? I'm not experienced with OpenGL, is it safe to > just redraw the part of the scene that shows the video in the > callback? If i'm not mistaken glimagesink isn't what you are looking for, except if your opengl application supports composite redirection (when glimagesink's textures are redirected inside your own opengl app): the glimagesink will be a dedicated, separate window and gl context. If you need to display gst-gl-originating frames inside your own opengl canvas, then you need to develop some form of a gstreamer sink for your canvas. This is what has been done in both pigment (with pgmimagesink) and clutter (cluttergstsink). The clutter section in gst-gl examples directory shows a gst-gl-originating texture redirection inside a clutter application (using composite redirection). > I'm wondering as this callback function is called by a > gstreamer thread and if the application is doing other OpenGL stuff or > contains more than one video display, multiple threads are doing > OpenGL drawing operations simultaneously. Your application should take care of the draws sync so that no conflict between opengl operations exists. Also, sharing opengl contexts between apps seems a difficult task. > self.videosink = gst.element_factory_make('glimagesink', 'videosink') > self.videosink.set_property('client-draw-callback', self.draw_callback) I think the client-draw-callback will offer you a way to manipulate the video texture inside the glimagesink context, not the other way around (drawing video inside your own app). I assume you are only trying to display gst-originating (decoded video) video inside your Gl app. If so, you can prototype things using the fakesink element, by connecting it's handoff signals to a texture upload in your application. See [1] and [2] for more info Florent [1] http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-data-spoof.html [2] http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-plugins/html/gstreamer-plugins-fakesink.html#GstFakeSink-handoff ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: video sink to update OpenGL texture?
|
|
> I assume you are only trying to display gst-originating (decoded
> video) video inside your Gl app. If so, you can prototype things using > the fakesink element, by connecting it's handoff signals to a texture > upload in your application. See [1] and [2] for more info > > Florent > > [1] http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-data-spoof.html > [2] http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-plugins/html/gstreamer-plugins-fakesink.html#GstFakeSink-handoff Florent, thanks for all your tips. I played around using the fakesink element with the handoff signal. However, as my application is python based, this cannot be the final solution, as it is pretty poor performance wise. Also, I don't feel like writing and a C based python extension for this. I then started looking into that clutter library that also Jan mentioned. I had never heard of clutter before, but it is absolutely amazing and seems to be exactly the right thing to build a presentation tool on. Displaying video is trivial using the 'gstreamer actor'. Also, I found that there are python bindings for poppler, which makes it really easy to render PDF files into clutter (they can be rendered directly into the CairoTexture actor). So, after all, I will rewrite everything using clutter and poppler. The final goal is to have something similar to 'impressive' [1], but with more focus on overlaying video and animations on top of the PDF and better support for beamer based presentations (i.e. all the animation and video related things can be embedded in the latex file and are parsed by the tool). Best, Martin [1] http://impressive.sourceforge.net ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
In reply to this post by Florent THIERY-2
Hi, I have been following this discussion with interest and I just
wanted to add a couple of comments/questions. I'm currently combining opengl and gstreamer within my application. Right now, the gst-originated video buffers are pushed out of the pipeline with a handoff signal, and then uploaded to an opengl texture for further gpu-accelerated processing and final display on the application window. But it would be quite great if I can just get the gl texture id from the gst-plugins, for instance glupload, and then directly use the texture inside my application. Since my app is cross-platform (linux, win, osx), the composite redirection approach doesn't seem viable. The XOverlay interface won't work either, because I need to do some gpgpu post-processing before the actual image rendering. From what I read, one alternative (perhaps the only one under this type of scenarios) would be to share the opengl context between the app and the gst gl-plugin. Basically, the app would create the opengl context and then pass it to the plugin when initializing the gst pipeline. Is this possible in the current implementation of gst-plugins? If not, wouldn't be an useful (additional) method for setting up gl-accelerated pipelines? Thanks, Andres Florent wrote: > Hi, > > >> Thanks Jan, I installed gst-plugins-gl from git and did some first >> experiments. This seems to be what I'm looking for. Is it correct that >> I would use 'glimagesink' and do the drawing using the >> client-draw-callback? I'm not experienced with OpenGL, is it safe to >> just redraw the part of the scene that shows the video in the >> callback? >> > > If i'm not mistaken glimagesink isn't what you are looking for, except > if your opengl application supports composite redirection (when > glimagesink's textures are redirected inside your own opengl app): the > glimagesink will be a dedicated, separate window and gl context. If > you need to display gst-gl-originating frames inside your own opengl > canvas, then you need to develop some form of a gstreamer sink for > your canvas. > > This is what has been done in both pigment (with pgmimagesink) and > clutter (cluttergstsink). > > The clutter section in gst-gl examples directory shows a > gst-gl-originating texture redirection inside a clutter application > (using composite redirection). > > >> I'm wondering as this callback function is called by a >> gstreamer thread and if the application is doing other OpenGL stuff or >> contains more than one video display, multiple threads are doing >> OpenGL drawing operations simultaneously. >> > > Your application should take care of the draws sync so that no > conflict between opengl operations exists. Also, sharing opengl > contexts between apps seems a difficult task. > > >> self.videosink = gst.element_factory_make('glimagesink', 'videosink') >> self.videosink.set_property('client-draw-callback', self.draw_callback) >> > > I think the client-draw-callback will offer you a way to manipulate > the video texture inside the glimagesink context, not the other way > around (drawing video inside your own app). > > I assume you are only trying to display gst-originating (decoded > video) video inside your Gl app. If so, you can prototype things using > the fakesink element, by connecting it's handoff signals to a texture > upload in your application. See [1] and [2] for more info > > Florent > > [1] http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-data-spoof.html > [2] http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-plugins/html/gstreamer-plugins-fakesink.html#GstFakeSink-handoff > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > > ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: video sink to update OpenGL texture?
|
|
Hi,
2009/3/24 Andres Colubri <[hidden email]> Hi, I have been following this discussion with interest and I just ok
Would be cool but it's not possible for the reasons you explain next. (a texture id can be used only inside the opengl context where it comes from) But there is maybe an other way: --on win32: wglCopyContext(glcontextSrc, glcontextDst, GL_TEXTURE_BIT); --on linux (assume it's X): glXCopyContext(disp, glcontextSrc, glcontextDst, GL_TEXTURE_BIT); --on OpenGL ES 2.0: http://www.khronos.org/opengles/sdk/1.1/docs/man/eglCreateContext.xml (Specifies the EGL rendering context with which to share texture objects) I have not experimented those things a lot. So I cannot tell more about this possible way. (there is some restrictions but in our case we are ok) So we can try it, for example I enable a function from a glfilter that would allow to retrieve the glcontext used inside the pipeline. You could then just call glCopyContext one time, and then use the texture id(s) just like you want.
Yup, the XOverlay interface is only there to specify a window id. There is not any relation with OpenGL (I mean about the goal). >From what I read, one alternative (perhaps the only one under this type This is a solution (use the same opengl context bettween you app and the plugin). I also first added a function but it's currently not implemented because of time (and I think there is a better/prefered way). http://cgit.freedesktop.org/gstreamer/gst-plugins-gl/tree/gst-libs/gst/gl/gstglwindow.h http://cgit.freedesktop.org/gstreamer/gst-plugins-gl/tree/gst-libs/gst/gl The main bad thing would be to use a lot of glMakeCurrent call (for each frame), inside your app thread and inside the gst-gl thread. For now, there is only one call to glMakeCurrent at gst-gl init. Switching a gl context bettween different threads it's very expensive. More over with several opengl context (several branch in the pipeline) this solution would be like a hell. I have experience on this so I can tell more and that's a bad way. Is this possible in the current implementation of gst-plugins? If not, There is 2 other solutions. First, have you take a look at glfilterapp ? Look at the code of gst-plugins-gl/tests/examples/generic/recordgraphic/main.cpp There is a drawcallback, which is invoked each time a new video frame is upload, and at the point of glfilterapp place in the graph. The last solution is to write a glfilter as glbumper, gleffects,
glfiltercube, glfiltersobel (etc..) are, and use you animation API
inside the implementation of its.This is the easiest way, if your scene is not extremelly complex. In this way, you have not to create/handle the opengl context, but you can give a windows ID in which you want see the gl scene. Also you could control your filter through gobject properties as it's done for gleffects (see property "effect"). And it would be more flexible. Finally, you could also split your rendering process in several glfilters. For example, one for the scene (rotation, quad), and one other for the effect on the texture. In this way too, you have not to create/handle the opengl context, but you can give a windows ID in which you want see the gl scene. I think it's the best way, the more viable, useable, flexible. So we have 4 solutions. The 3 (glfilterapp), and 4 (create a glfilter) are already fully implemented. The 1 (copyContext), we have to test it. The 2, (use the same context) must be used only if 1, 3 and 4 are not possible (because really a bad way). And it's not yet implemented. About the solution 4, you will tell me that you can implement a glfilter because you are using a framework that comes with its own opengl context management. So the problem is still the same. (I mean, all the opengl framework focused on draw and esthetic: clutter etc...) Then I will say yes, but then I will tell you that the solution is to implement glwindow with your friendly framework. I am mean if it's clutter, then you have to create a gstglwindow_clutter.c. I can help on this.
I hope this can help. Sincerely Julien
------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: video sink to update OpenGL texture?
|
|
-you will tell me that you can
+you will tell me that you cannot ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: video sink to update OpenGL texture?
|
|
note that you can already try the first solution I suggested in the last mail: Use glfilterapp (see the link I past in last mail), then in the drawcallback you have to call src = glGetCurrentContext(), then glCopyContext(src, dst, ...), just one time. You can also use dst = glGetCurrentContext() in your gl framework thread, to get the gestination. Let me know if it works. Julien ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
In reply to this post by Julien Isorce
Hello Julien,
Many thanks for your detailed answer. From what you say, I'd rather chose solution 1, this is, get the gl context of the gst pipeline and then copy it (just once, right after the pipeline initialization if I'm not mistaken) to the gl context of my app using wglCopyContext/glXCopyContext. However, I haven't experimented with these things yet, but I'm willing to try them out. Context state copy is something that I'd really like to figure out, since I need it not only to integrate the gst-plugings-gl with my own gl shading framework, but also for other things (multiple screen rendering). Andres Julien Isorce wrote: > Hi, > > 2009/3/24 Andres Colubri <[hidden email] > <mailto:[hidden email]>> > > Hi, I have been following this discussion with interest and I just > wanted to add a couple of comments/questions. > > I'm currently combining opengl and gstreamer within my application. > Right now, the gst-originated video buffers are pushed out of the > pipeline with a handoff signal, and then uploaded to an opengl texture > for further gpu-accelerated processing and final display on the > application window. > > ok > > > > But it would be quite great if I can just get the gl texture id > from the > gst-plugins, for instance glupload, and then directly use the texture > inside my application. > > > Would be cool but it's not possible for the reasons you explain next. > (a texture id can be used only inside the opengl context where it > comes from) > > But there is maybe an other way: > --on win32: > wglCopyContext(glcontextSrc, glcontextDst, GL_TEXTURE_BIT); > --on linux (assume it's X): > glXCopyContext(disp, glcontextSrc, glcontextDst, GL_TEXTURE_BIT); > --on OpenGL ES 2.0: > http://www.khronos.org/opengles/sdk/1.1/docs/man/eglCreateContext.xml > (Specifies the EGL rendering context with which to share texture objects) > > I have not experimented those things a lot. So I cannot tell more > about this possible way. (there is some restrictions but in our case > we are ok) > ** > So we can try it, for example I enable a function from a glfilter that > would allow to retrieve the glcontext used inside the pipeline. > You could then just call glCopyContext one time, and then use the > texture id(s) just like you want. > > > > Since my app is cross-platform (linux, win, osx), the composite > redirection approach doesn't seem viable. The XOverlay interface won't > work either, because I need to do some gpgpu post-processing > before the > actual image rendering. > > > Yup, the XOverlay interface is only there to specify a window id. > There is not any relation with OpenGL (I mean about the goal). > > >From what I read, one alternative (perhaps the only one under > this type > of scenarios) would be to share the opengl context between the app and > the gst gl-plugin. Basically, the app would create the opengl context > and then pass it to the plugin when initializing the gst pipeline. > > > This is a solution (use the same opengl context bettween you app and > the plugin). > I also first added a function but it's currently not implemented > because of time (and I think there is a better/prefered way). > http://cgit.freedesktop.org/gstreamer/gst-plugins-gl/tree/gst-libs/gst/gl/gstglwindow.h > http://cgit.freedesktop.org/gstreamer/gst-plugins-gl/tree/gst-libs/gst/gl > > The main bad thing would be to use a lot of glMakeCurrent call (for > each frame), inside your app thread and inside the gst-gl thread. > For now, there is only one call to glMakeCurrent at gst-gl init. > Switching a gl context bettween different threads it's very expensive. > More over with several opengl context (several branch in the pipeline) > this solution would be like a hell. I have experience on this so I can > tell more and that's a bad way. > > Is this possible in the current implementation of gst-plugins? If not, > wouldn't be an useful (additional) method for setting up > gl-accelerated > pipelines? > > > There is 2 other solutions. > > First, have you take a look at glfilterapp ? > Look at the code of > gst-plugins-gl/tests/examples/generic/recordgraphic/main.cpp > There is a drawcallback, which is invoked each time a new video frame > is upload, and at the point of glfilterapp place in the graph. > This is the easiest way, if your scene is not extremelly complex. > In this way, you have not to create/handle the opengl context, but you > can give a windows ID in which you want see the gl scene. > > The last solution is to write a glfilter as glbumper, gleffects, > glfiltercube, glfiltersobel (etc..) are, and use you animation API > inside the implementation of its. > Also you could control your filter through gobject properties as it's > done for gleffects (see property "effect"). > And it would be more flexible. > Finally, you could also split your rendering process in several > glfilters. For example, one for the scene (rotation, quad), and one > other for the effect on the texture. > In this way too, you have not to create/handle the opengl context, but > you can give a windows ID in which you want see the gl scene. > I think it's the best way, the more viable, useable, flexible. > > So we have 4 solutions. > The 3 (glfilterapp), and 4 (create a glfilter) are already fully > implemented. > The 1 (copyContext), we have to test it. > The 2, (use the same context) must be used only if 1, 3 and 4 are not > possible (because really a bad way). And it's not yet implemented. > > About the solution 4, you will tell me that you can implement a > glfilter because you are using a framework that comes with its own > opengl context management. So the problem is still the same. > (I mean, all the opengl framework focused on draw and esthetic: > clutter etc...) > Then I will say yes, but then I will tell you that the solution is to > implement glwindow with your friendly framework. > I am mean if it's clutter, then you have to create a > gstglwindow_clutter.c. I can help on this. > > > Thanks, > Andres > > > I hope this can help. > > Sincerely > > Julien > > > > > Florent wrote: > > Hi, > > > > > >> Thanks Jan, I installed gst-plugins-gl from git and did some first > >> experiments. This seems to be what I'm looking for. Is it > correct that > >> I would use 'glimagesink' and do the drawing using the > >> client-draw-callback? I'm not experienced with OpenGL, is it > safe to > >> just redraw the part of the scene that shows the video in the > >> callback? > >> > > > > If i'm not mistaken glimagesink isn't what you are looking for, > except > > if your opengl application supports composite redirection (when > > glimagesink's textures are redirected inside your own opengl > app): the > > glimagesink will be a dedicated, separate window and gl context. If > > you need to display gst-gl-originating frames inside your own opengl > > canvas, then you need to develop some form of a gstreamer sink for > > your canvas. > > > > This is what has been done in both pigment (with pgmimagesink) and > > clutter (cluttergstsink). > > > > The clutter section in gst-gl examples directory shows a > > gst-gl-originating texture redirection inside a clutter application > > (using composite redirection). > > > > > >> I'm wondering as this callback function is called by a > >> gstreamer thread and if the application is doing other OpenGL > stuff or > >> contains more than one video display, multiple threads are doing > >> OpenGL drawing operations simultaneously. > >> > > > > Your application should take care of the draws sync so that no > > conflict between opengl operations exists. Also, sharing opengl > > contexts between apps seems a difficult task. > > > > > >> self.videosink = gst.element_factory_make('glimagesink', > 'videosink') > >> self.videosink.set_property('client-draw-callback', > self.draw_callback) > >> > > > > I think the client-draw-callback will offer you a way to manipulate > > the video texture inside the glimagesink context, not the other way > > around (drawing video inside your own app). > > > > I assume you are only trying to display gst-originating (decoded > > video) video inside your Gl app. If so, you can prototype things > using > > the fakesink element, by connecting it's handoff signals to a > texture > > upload in your application. See [1] and [2] for more info > > > > Florent > > > > [1] > http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-data-spoof.html > > [2] > http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-plugins/html/gstreamer-plugins-fakesink.html#GstFakeSink-handoff > > > > > ------------------------------------------------------------------------------ > > Apps built with the Adobe(R) Flex(R) framework and Flex > Builder(TM) are > > powering Web 2.0 with engaging, cross-platform capabilities. > Quickly and > > easily build your RIAs with Flex Builder, the Eclipse(TM)based > development > > software that enables intelligent coding and step-through debugging. > > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > > _______________________________________________ > > gstreamer-devel mailing list > > [hidden email] > <mailto:[hidden email]> > > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > > > > > > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex > Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. > Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based > development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > <mailto:[hidden email]> > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > ------------------------------------------------------------------------ > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
In reply to this post by Julien Isorce
Great, I'll test this approach soon and keep you posted about the results.
Thanks a lot for your help! Julien Isorce wrote: > > note that you can already try the first solution I suggested in the > last mail: > > Use glfilterapp (see the link I past in last mail), then in the > drawcallback you have to call src = glGetCurrentContext(), then > glCopyContext(src, dst, ...), just one time. > > You can also use dst = glGetCurrentContext() in your gl framework > thread, to get the gestination. > > Let me know if it works. > > Julien > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
Hi Andres,
Looks like you are doing what I want to do. Did this approach work? Or do you recommend any other way? Thanks in advance. Kiju
|
Re: video sink to update OpenGL texture?
|
|
see cluttershare example in gst-plugins-gl/tests/examples/clutter
A texture is created from gst-gl (from our own gl context) and then you can use it in an external opengl context, clutter context in this example. But it can be SDL or anything else. It uses opengl context sharing. Julien 2009/8/13 Kiju <[hidden email]>
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |