Hi everybody,
as a good practice I prefer to share as much information as possible, that's why I'm writing here for a question mainly directed to Tim-Phillip, at least I guess... We are developing a video-surveillance Windows application based on GStreamer where we can have multiple windows each with many videos inside it, for a total of tenth of simultaneously running videos. After many performance tests we came to Direct3D video sink before it was officially released (we started from Git development version) and we are very satisfied with it, though we noticed a very poor behavior when as an example we rescale the multiple videos window, graphics are so slow that they are quite unusable for a long time. After many tests we found out that simply avoiding the registration of WndProcHook function fixes most of our issues, graphics is very responsive and everything is fine, no particular feature (at least for what we need) is missing. Moreover Direct3D swap chain is correctly managed even if gst_d3dvideosink_refresh is not directly called. May you please explain us the reason for this implementation? We did not find anything similar for example in VLC Direct3D video output module. Many thanks in advance for your kind support, Matteo _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
If I am not mistaken the ProcHook function is registered to catch events for the window created by or provided to the sink. That would include navigation events, expose, destroy, etc..
You might be interested in figuring out which events are received in this function and the processing they are triggering as this could explain why it slows down the whole thing.
Best regards, Julien MOUTTE C.T.O. FLUENDO Influencing the Multimedia World San Francisco, USA & Barcelona, SPAIN Spain: +34 933 175 153 United States: +1 415 773 5353 www.fluendo.com Please consider the environment before printing this e-mail. On Mon, Mar 19, 2012 at 5:57 PM, Matteo Pampolini <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
In reply to this post by Matteo Pampolini
> ... we noticed a very poor behavior when as an example we rescale the multiple videos window, graphics are so slow that they are quite unusable for a long time. You should check the graphics driver/card for issues. I used to run a 16-video window (at least, sometimes more) without problem. However, that's running what's now old code. I haven't retried it with a lot of the latest commits. There was one commit that I was curious about. It seems that there's now a d3d device created per sink. Multiple devices is usually a bad idea and a potentially significant performance hit. The recommended approach (as I understand it) is one device and additional swap chains per sink. This talks a bit about that approach: http://msdn.microsoft.com/en-us/library/windows/desktop/bb147290(v=vs.85).aspx Sorry to hijack this thread, but was there a good reason for changing the behavior? I'm happy to be educated. :D > After many tests we found out that simply avoiding the registration of WndProcHook function fixes most of our issues, graphics is very responsive and everything is fine, no particular feature (at least for what we need) is missing. Moreover Direct3D swap chain is correctly managed even if gst_d3dvideosink_refresh is not directly called. > > May you please explain us the reason for this implementation? It's probably not commonly used, but there's at least 1 application I know of that actually renders into the video sink from another process and the hooks facilitate that. It's been a while since I've looked at the code, though. It might be better to instead provide a property to enable the hook, otherwise keep it off. I doubt many folks are using that functionality -- however, for backwards compatibility with existing behavior, you might want to by default enable the behavior. I'd leave that decision in the very capable hands of the gst devs. > We did not find anything similar for example in VLC Direct3D video output module. I admit that it has been a long time since last I looked at the VLC D3D plugin, but I do recall thinking that there were many things wrong with their implementation at the time I looked it over (not that mine was perfect). Their needs/requirements may have been different from gst's so please be careful when making a comparison. _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |