Hi Michael, You should be able to stream your video at 60Hz without problems, you just need to implement things more efficiently.
The best way to do video work like this is to have an osg::Image that you assign a PixelBufferObject to, if you subclass or use ImageStream this will be assigned automatically for you - this will ensure an efficient upload of the image data to the GPU. Next up double buffer your image data so that you have one thread (a background video thread) writing to data while the main/graphics thread is reading from the other side of the buffer. When the video thread completes it's copy of data you simply have to swap the data pointer on the osg::Image, there isn't any need to copy any data. With this model there isn't any need for StateAttributeCallback to manage the updating - the background thread will do it all without ever holding back the viewer from rendering. If you want to see examples of video rendering have a look at the ffmpeg or quicktime plugins. Robert. On 1 March 2012 16:41, Michael Schanne <[email protected]> wrote: > Hi, > > I am trying to create a scene which contains a texture displaying a live > video image. The image is sent as a buffer of raw data from an attached > camera. I was able to get something working but the performance is terrible: > about 1.42 frames per second. I need to get to at least 20 fps. I am > dealing with an image that is 640x480 pixels with 32 bits per pixel. I have > stripped down my scene to contain only a geode with a quad geometry, and an > attached texture, and I still see the performance problem. The texture has > an attached StateAttributeCallback, in which I fetch the buffer of data for > the next video frame, and then call setImage: > > img->setImage( 640, // width > 480, // height > 1, // depth > GL_RGB8, // internal texture format > GL_BGRA, // pixel format > GL_UNSIGNED_INT_8_8_8_8_REV, // data type > data, // raw data pointer > osg::Image::NO_DELETE); > > I also experimented with another technique that I found on another post where > someone is doing something very similar to what I’m trying to do: > > >> Re: Update a texture's pixels contents, using apply or glTexSubImage2D >> Robert Osfield >> Fri, 26 Sep 2008 01:33:52 -0700 >> Hi Guillaume, >> >> The way to integrate a live video stream is to subclass from >> osg::ImageStream (which is subclass from osg::Image), as is done in >> the OSG's quicktime and xine-lib plugins. The ImageStream is then >> attached to Texture be it a Texture1D, 2D, 3D or TextureRectangle. >> This approach means that you don't ever subclass from the Texture >> objects as the image data is encapsulated complete by >> osg::Image/ImageStream. >> >> The way I'd tackle your task is to subclass from osg::ImageStream and >> then allocate the image data then copy over this in your background >> thread and then call dirty() on the ImageStream, this will tell the >> Texture::apply() that the image data has changed and it'll then >> automatically subload the data for you. ImageStream also by default >> provides a PixelBufferObject which means upload performance will be >> the best you can get. >> >> Robert. > > > To make this technique work, in my video frame producer thread I was calling > ImageStream::data() to get the pointer to the raw data, then doing a memcpy > to write the new frame, then calling dirty(). I no longer used a > StateAttributeCallback in this method. Unfortunately, I did not see any > noticeable change in performance using this technique. Do I need to use > another function in order to write directly to the pixel buffer object? Also > what thread synchronization do I need here? > > My hardware specs are as follows: > > Intel Celeron 550 CPU (2.0 GHz) > 1.0 GB RAM > Mobile Intel GME965 Express Chipset with integrated graphics > > Upgrading hardware is not an option for me. Please let me know what I can do > to maximize performance in this situation. > > Thanks, > Mike > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=45922#45922 > > > > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
