[Razze]

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?

Great - constructive discussion! BTW, if you like, you could email me at madshi (at) gmail (dot) com to continue this discussion. Since this would not be dsplayer, it probably doesn't belong into this thread, anyway.

Generally, implementing madVR support is possible in two levels:

1) The easiest approach would be for you to provide me with a decoded frame (in a D3D surface or texture, or alternatively in CPU RAM), and simply ask me to render it to a specific target surface. Probably very easy for you to implement. I'd just need to add an API to madVR to allow this sort of usage. Relatively easy for me to implement, too. But we would lose quite a lot of madVR functionality this way. If you're interested to know, I can give you a full list of which features would be lost.

2) The more difficult approach would be to try to support all madVR features. For that I fear that the interface you're currently using for your renderers might need to be extended a bit. E.g. the decoder would have to deliver frames in full speed (blocking), totally independent of the rendering process, so that I can build up an internal frame queue in madVR. Furthermore I would need to be able to take control over presentation, and Kodi would then have to send its GUI frames to me, instead of the other way round. You could still do your thing as usual, with your own D3D devices and at your own speed/timing, but instead of calling ISwapChain.Present, you would simply call something like madVR.Present, to pass your backbuffer to madVR instead of directly to D3D. I think this should be possible to implement, too, but would probably require a bit more work on your side.

The way aracnoz implemented 2) in dsplayer is by letting both Kodi and madVR have their own totally separate D3D devices and then use shared textures to combine the final output of both into one presentation device. If we want to go the full way and make all madVR features available, I think this would be a good approach because it would allow us to keep things as much separated as possible.

What do you think? I'm quite willing to add any APIs or exported functions or whatever you need.

That sounds like a conclusion to this discussion. Like other Kodi users, we look forward to trying any new features.

I should not call the current player "rubbish," but it is starting to look long-in-the-tooth.

Plex Media Player is currently being rewritten to replace the previous player, which was forked from Kodi. This is a complete rewrite with a developer hired from mpv.

Emby Theater is also being rewritten -- the GUI, the player, everything. Emby is purported to offer full support of madVR.

So, it would only make sense for Kodi's DVDPlayer to be next...

Well there is a rewrite in the works and should be merged for 17. And Plex/mpv even grabbed some code from our rewrite already, that's open source spirit.
You might want to look here for development on the new player. http://forum.kodi.tv/forumdisplay.php?fid=240