[afedchin]

Just to be honest. I as one developer who supports windows platform (yes, it's me) I don't want to support a huge "black box" like DSPlayer is for me. I'm alone and have no time enough for core Kodi not even speaking about DSPlayer. The main problem of DSPlayer for me as windows developer: there is no a possibility to use madVR renderer without DirectShow filters. If there is a some way to use madVR (through COM) just as another renderer like DXVA, Pixel Shaders or Software, I would be glad to try to implement an integration. But current state of DSPlayer in not acceptable not only for me but for all devs in the team whether you like it or not. Also I didn't like what madVR isn't open source project and I'm realy don't like to working with closed source projects.

I could add a non-DirectShow interface to madVR. But it seems that an "official" Kodi video renderer binary interface might be happening sooner or later, anyway, so maybe we should just wait for that, to save you the development time, and to keep the Kodi code base as clean as possible?

Btw, such an interface would have to go a bit deeper than you probably anticipate right now, because in order to provide *all* the madVR features, I'd need to have control over Direct3D presentation. So the interface would need to include some way for the Kodi main EXE and the video player and the video renderer components to discuss who's in charge of Direct3D etc. I wish a simple "draw frame X and deliver it in a surface or texture" would suffice, but it doesn't. We'd lose half of the madVR features that way. Well, maybe not half, but some of them are quite important.

We are only at the beginning of this way. It's not known exactly when it will happen in real. But we can start thinking about integration today.

We cannot provide the control over Direct3D presentation to the renderer otherwise renderer should care to Kodi's GUI presentation over video. We can provide current D3D11DeviceContext (it's always a deferred context, but this doesn't matter), a set of frames (past and future) and target surface to render.That's how all the renderers currently work. Is this enough to work a most of features of madVR?