HI Nick, > Hi Robert, > yes, that was the place I started implementing the check there, however, in > there , DoRenderSample, the EC_COMPLETED is not fired.
I was wondering if this might happen - the event fired after one gets the frame is updated. Oh well nice try anyway :-) > I did quite a good > search for this, looked in the SDK samples the code is originated from, and > they have it checking outside in the render loop. So I did it like this. > Probably good solution is to make it like in the ImageSequence, to use the > update callback. What you think? I've just done quick search of the IID_IMediaEvent online and come across MS docs on directshow that discuss the how to handle the events in various ways. It looks like you can tell directshow to dispatch a windows event to your applications windows and have the event checked for here, but this requires a handle to the window, which you don't have in the plugin, so really a promising lead. The other item that the approach of using WaitForCompletion in a separate thread that blocks till the the video is complete. From the msdocs at: http://msdn.microsoft.com/en-us/library/dd389098%28VS.85%29.aspx > When the filter graph runs, data moves through the filters and is rendered as > video and > audio. Playback occurs on a separate thread. You can wait for playback to > complete by > calling the IMediaEvent::WaitForCompletion method: > > long evCode = 0; > pEvent->WaitForCompletion(INFINITE, &evCode); > > This method blocks until the file is done playing, or until the specified > time-out interval > elapses. The value INFINITE means the application blocks indefinitely until > the file is done > playing. For a more realistic example of event handling, see Responding to > Events. This would still require a dedicated thread to spawed just to wait till the rendering is complete, but at least it should sit there consuming little or no CPU resources till it gets awoken so might be marginally better than your original solution of polling for the events. Finally the approach of overriding Image::update(..) is an possibility, I don't recall the details of ImageSequence so browsing through the headers of ImageSequence we find the helper callback class that enables the calling of the Image::update(..) from the update traversal virtue of a StateAttributeAttribute callback that needs to be attached to the Texture that the image is attached to, without this callback the Image::update(..) isn't ever called: struct OSG_EXPORT UpdateCallback : public osg::StateAttributeCallback { virtual void operator () (osg::StateAttribute* attr, osg::NodeVisitor* nv); }; That is implemented in src/osg/ImageSquence.cpp thus: void ImageSequence::UpdateCallback::operator () (osg::StateAttribute* attr, osg::NodeVisitor* nv) { osg::Texture* texture = attr ? attr->asTexture() : 0; // osg::notify(osg::NOTICE)<<"ImageSequence::UpdateCallback::"<<texture<<std::endl; if (texture) { for(unsigned int i=0; i<texture->getNumImages(); ++i) { texture->getImage(i)->update(nv); } } } And another bit of hacky code magic that glues things together automatically can be found in src/osg/Texture2D.cpp - note the attachment of the ImageSequence::UpdatecCallback() automatically: void Texture2D::setImage(Image* image) { if (_image == image) return; if (dynamic_cast<osg::ImageSequence*>(_image.get())) { setUpdateCallback(0); setDataVariance(osg::Object::STATIC); } _image = image; _modifiedCount.setAllElementsTo(0); if (dynamic_cast<osg::ImageSequence*>(_image.get())) { setUpdateCallback(new ImageSequence::UpdateCallback()); setDataVariance(osg::Object::DYNAMIC); } } Now the DirectShowImageStream won't trigger this automatically callback attachment, so you'd have to manually attach this callback to the textures you want. Potentially we could tweak osg::Image to have a bool requiresUpdateCall() that tells the Texture classes whether Image::update needs to be called, rather than relying upon the hacky dynamic_cast above. Personally I think this is something that would be appropriate regardless of this DirectShowIssue as it just feels like a better solution than present hack for ImageSequence. Thoughts? Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
