[Warner306]

...

[Knight77]

After many many test I can confirm that the function to move the subs in the black bars



In both my PC works only if I use xysubfilter.dll 745 or previous. Why? Can anyone give me a solution about this? I'd like to use the last version :-(

I got that version by aracnoz in a post in this thread and is the only one working (both in dsplayer and mphc)....

[lockian]

Well, I'd just like to say thanks to aracnoz for all the hard work it's been very much appreciated, and best of luck with the brain detox.

I do hope that the Kodi developers (who I also have a large respect for and would like to thank) can come back to this objectively once this topic has settled down and find a suitable solution for those of us who wish to continue using dsplayer\madVR in the future.

I agree with the idea above with the plugin binary system - I don't think looking at this option compromises the Kodi philosophy - infact it smartly acknowledges that the team does not have the capacity to be everything to everyone, whilst leaving the door open to take advantage of alternative players \ renderers and not compromising the open source \ multiplatform nature of the stock player.

[oldpoem]

After many many test I can confirm that the function to move the subs in the black bars



In both my PC works only if I use xysubfilter.dll 745 or previous. Why? Can anyone give me a solution about this? I'd like to use the last version :-(

I got that version by aracnoz in a post in this thread and is the only one working (both in dsplayer and mphc)....

The latest internal xysubfilter is flagged as 747 build compiled on oct17 and it's working fine. If you want to install xysubfilter as separated software make sure you install x86 version since Kodi DSplayer is 32bit and x64 version won't work even you're on 64bit windows.

[Knight77]

After many many test I can confirm that the function to move the subs in the black bars



In both my PC works only if I use xysubfilter.dll 745 or previous. Why? Can anyone give me a solution about this? I'd like to use the last version :-(

I got that version by aracnoz in a post in this thread and is the only one working (both in dsplayer and mphc)....

The latest internal xysubfilter is flagged as 747 build compiled on oct17 and it's working fine. If you want to install xysubfilter as separated software make sure you install x86 version since Kodi DSplayer is 32bit and x64 version won't work even you're on 64bit windows.

I really don't know what to do. If I overwrite the xysubfilter in the DSPlayer folder or the one in the xysubfilter folder I created in MPCH folder it just doesn't work. I just tried 746, 747 but nothing it just doesn't move the subs in the black bars. If I go back to 745 (the one posted by aracnoz time ago) then they are moved in the black bars. I tried also on another PC and the result is the same, this is even weirder because that PC has just the normal Kodi installed, not the one with madVR support. Also on that PC if I use the 745 it works, 746 and 747 no.
I also tried to uninstall and reinstall MPHC and madVR and update the LAV Filters. Got no idea but it just doesn't make sense.

[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?

[madshi]

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.

[SALAMINOMACHOS]

@ afedchin
Thanks for your approach

@ madshi
Mattias , go ahead

I wish to see the whole team here , including aracnoz

Thank you MEN , the hats off

[Warner306]

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

[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

[Warner306]

I found this online...

CyberLink, makers of PowerDVD, have joined the UHD Alliance to ensure UHD Blu-rays will remain compatible with PCs. This opens the possibility of software like MakeMKV being able to rip these discs for personal use (with a very difficult crack, I would assume). It also guarantees the manufacture and sale of BD drives that can read UHD discs. At the very least, it means UHD discs should be able to be played by media software such as Kodi.

http://tv.about.com/od/accesspries/fl/Ul...or-PCs.htm

I think this step is important to the long-term life of PC media software such as Kodi by ensuring compatibility with future media formats.

[XTrojan]

I found this online...

CyberLink, makers of PowerDVD, have joined the UHD Alliance to ensure UHD Blu-rays will remain compatible with PCs. This opens the possibility of software like MakeMKV being able to rip these discs for personal use (with a very difficult crack, I would assume). It also guarantees the manufacture and sale of BD drives that can read UHD discs. At the very least, it means UHD discs should be able to be played by media software such as Kodi.

http://tv.about.com/od/accesspries/fl/Ul...or-PCs.htm

I think this step is important to the long-term life of PC media software such as Kodi by ensuring compatibility with future media formats.

It's bound to happen, I just wonder how long it'll take, not sure what protection new UHD bluray uses. The first Blu-ray took 2years to crack.

[da-anda]

This is where I feel like having a stable binary plugin interface would be to the benefit of the end users long term. It is far easier for companies to offer support for projects in such a manner, where they may not be in the position to open their source. Having binary plugin options does not mean that any default configuration has to be a binary blob – it just allows for more potential options for the end user which is a good thing. I hope that one day in the future, such an interface is possible, so that whether it is madVR, Netflix, or Sling TV, we may have a shot at getting real, supported integrations in Kodi.

I don't want to destroy your dream, but binary add-ons for DRM content will also be in charge of rendering, so no MadVR for Netflix etc - not even any Kodi post processing or scalers. The entire chain from decoding to rendering will be locked.

[madshi]

I don't want to destroy your dream, but binary add-ons for DRM content will also be in charge of rendering, so no MadVR for Netflix etc - not even any Kodi post processing or scalers. The entire chain from decoding to rendering will be locked.

Oh, don't we love DRM? I wish the movie industry would take a hint from the music industry...

[Gjel]

Compatibility with most custom DirectShow filters such as LAV Filters, Xy-SubFilter, Haali Media Splitter, AV Splitter, FFDShow, AC3Filter, etc.;
Full integration with madVR video renderer including a customized madVR gui and access to all madVR post-processing features;
Custom video renderers: Enhanced Video Renderer (EVR) and Video Mixing Renderer 9 (VMR9);

Excuse my lack of knowledge about DSplayer, but what EXACTLY advantages gives all those codecs-filters-etc to users/lookers?