Need some help on Direct3D video sink, please

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Need some help on Direct3D video sink, please

Matteo Pampolini
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
Reply | Threaded
Open this post in threaded view
|

Re: Need some help on Direct3D video sink, please

Julien Moutte
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
Contact phone:
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:
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



_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

RE: Need some help on Direct3D video sink, please

David Hoyt
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