2015-11-30, 00:25
...
(2015-11-30, 00:43)Knight77 Wrote: 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)....
(2015-11-30, 10:04)oldpoem Wrote:(2015-11-30, 00:43)Knight77 Wrote: 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.
(2015-11-28, 11:11)madshi Wrote: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.(2015-11-27, 12:39)afedchin Wrote: 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.
(2015-11-30, 17:18)afedchin Wrote: 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?
(2015-11-30, 18:08)madshi Wrote:(2015-11-30, 17:18)afedchin Wrote: 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.
(2015-11-30, 22:57)Warner306 Wrote:(2015-11-30, 18:08)madshi Wrote:(2015-11-30, 17:18)afedchin Wrote: 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...
(2015-12-01, 00:38)Warner306 Wrote: 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.
(2015-11-29, 23:38)starlightknight Wrote: 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.
(2015-12-01, 13:05)da-anda Wrote: 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.
Quote:Compatibility with most custom DirectShow filters such as LAV Filters, Xy-SubFilter, Haali Media Splitter, AV Splitter, FFDShow, AC3Filter, etc.;Excuse my lack of knowledge about DSplayer, but what EXACTLY advantages gives all those codecs-filters-etc to users/lookers?
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);