Need some help on Direct3D video sink, please

dhoyt at dhoyt at
Mon Mar 19 10:56:20 PDT 2012

> ... 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:

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.

More information about the gstreamer-devel mailing list