MSL_DK 35 Posted March 17, 2015 Share Posted March 17, 2015 The good news, this will soon be a thing of the past. The new version of MBT is being build around Mpdn, which you think of as a modernized mpc-hc and is seeing heavily active development: http://forum.doom9.org/showthread.php?t=171120 It is now the best video player for windows and it's going to be built right into the new MBT, and I can tell you it's a thing of beauty. This choice leads me to leave MBT, conclusively. One reason could be the discussion madshi and developer of the program. Head Shaking choice! Link to comment Share on other sites More sharing options...
babgvant 143 Posted March 17, 2015 Share Posted March 17, 2015 This choice leads me to leave MBT, conclusively. One reason could be the discussion madshi and developer of the program. Head Shaking choice! Do you have a link? I have my own concerns, but it would be interesting to see what madshi had to say. Link to comment Share on other sites More sharing options...
MSL_DK 35 Posted March 17, 2015 Share Posted March 17, 2015 (edited) Read madshi ironic and somewhat coarse comments in the developer's thread. I also think his questions about the rather basic questions, such as, 3DLUT is a bit worrying. Edited March 17, 2015 by JLPFLD Link to comment Share on other sites More sharing options...
MSL_DK 35 Posted March 17, 2015 Share Posted March 17, 2015 From madshi to Zachs I would have thought that studying the basic standards is the first thing a video renderer developer would do. Oh well... (Of course what madVR does is correct. But did I really have to say that? RTFSs! ) Link to comment Share on other sites More sharing options...
babgvant 143 Posted March 17, 2015 Share Posted March 17, 2015 Yeah, I've been reading backwards through the thread. The most concerning thing about it (highlighted in that quote) is that the developer doesn't seem to know some basic things about how video is stored, decoded, and rendered. Link to comment Share on other sites More sharing options...
MSL_DK 35 Posted March 17, 2015 Share Posted March 17, 2015 Agree. And I only know madshi to lead a good tone, so that in itself is worrying. Link to comment Share on other sites More sharing options...
babgvant 143 Posted March 17, 2015 Share Posted March 17, 2015 Agree. And I only know madshi to lead a good tone, so that in itself is worrying. Excellent point. Link to comment Share on other sites More sharing options...
MSL_DK 35 Posted March 17, 2015 Share Posted March 17, 2015 I remember ebr at one point announced that Media Browser went a step further than services like Netflix and would provide the best image quality. I do not get the opportunity with this choice, and it makes me sad. I do not know the reason for your choice ... but how the heck can you engage with someone who disagrees with the king of all when it comes to video rendering? And one who does not know when a 3DLUT should be presented? Link to comment Share on other sites More sharing options...
Luke 37066 Posted March 17, 2015 Share Posted March 17, 2015 It's being built in a modular fashion just like the current MBT. There will be an opportunity to have multiple players, including the current one if we decide to retain it. Link to comment Share on other sites More sharing options...
Aphid 212 Posted March 17, 2015 Share Posted March 17, 2015 (edited) Zacks: If you have nothing useful to contribute, please shut up. Yes that comment does worry me greatly. Zachs has not shown behaviour like that before, as far as I am aware. Madashi is, as usual, exemplary in how he continues to assist the developers despite such behaviour. I went with MPDN, as I was looking for a new external player to use so that users could switch to something else if they were having trouble with our internal player. I had also just completed a re-write of the playback management system in MBT, and needed a player to use to test it, but I didn't want to start with updating the internal player (complex system which will take a long time to update before the code would compile, and I would likely introduce additional bugs in somewhat unfamiliar code). MPDN's player extensions allows us to support MPDN with the same level of integration that we can offer with our internal player, while supporting many of the features which attract people to MadVR. My own testing showed the player to have good image quality and performance, and was very stable for me, which is impressive considering how new the player is. Having what is, in effect, a second development team working in parallel with MBT development is very attractive. I have no intention of dropping our internal player, however. Andy has done some fantastic work, and I still feel that MBT must be able to support MadVR (and potentially other filters in the future) before we can confidently claim top-tier rendering quality. However, the player is the most complex component of MBT, and I am not sure that it is reasonable to expect Andy to work on it solo. A very large portion of the issues that crop up with MBT involve the internal player, and they can be difficult to fix due to sometimes only showing themselves with particular system configurations or videos. I will make whichever player proves to be the most stable the default player, but users will always have the choice to switch to another player if they wish. The internal player and MPDN (pending on keeping an eye on these recent developments) will not be the only players available within MBT. The new playback framework much more robustly supports switching player implementations freely while working through a playlist, and I expect MBT to support additional more specialised players in the future (e.g. dedicated music player + visualiser, GameBrowser emulators, etc). ..and that it requires users to manage the filter installations personally. MBT can now install and auto-update externally installed filters (inc manually installed and via popular codec packs such as K-lite). It will not configure those filters, however, and this is a major area where the internal player surpasses external players for most users. Also curious about the integration, are you hosting it in your WPF app (similar in concept to how modern revs of PowerDVD work) or is it used as an external player? MPDN is not hosted inside WPF for the same reasons that the internal player renders in a 2nd window. The MPDN integration works in the same manor that the internal player does and, once updated to support the new playback manager, the internal player will use the same APIs for window management as the MPDN plugin does. Edited March 17, 2015 by Aphid 1 Link to comment Share on other sites More sharing options...
Luke 37066 Posted March 17, 2015 Share Posted March 17, 2015 Perfect answer Link to comment Share on other sites More sharing options...
babgvant 143 Posted March 17, 2015 Share Posted March 17, 2015 (edited) MPDN is not hosted inside WPF for the same reasons that the internal player renders in a 2nd window. The MPDN integration works in the same manor that the internal player does and, once updated to support the new playback manager, the internal player will use the same APIs for window management as the MPDN plugin does. "Hosting" probably wasn't the best word to use (AFAIK, it's not possible to host a process within a process). What I meant to ask was if you were hosting the target window surface that it was using as a render target (which is how PowerDVD works in the last couple/few versions, and interestingly enough how I think the WMC TMT player achieves its slick integration), or if it was a simple "shell-to-external-player" implementation. If you have the plumbing in place, and the results are promising it might make sense to POC the current internal player implementation as an external process. I'm not completely confident that it will fix all the performance issues (it will still render to a windows owned by the WPF application after all), but it might. MBT can now install and auto-update externally installed filters (inc manually installed and via popular codec packs such as K-lite). It will not configure those filters, however, and this is a major area where the internal player surpasses external players for most users. Opt-in I hope? Also, how do you manage escalation issues? Edited March 17, 2015 by babgvant Link to comment Share on other sites More sharing options...
Aphid 212 Posted March 17, 2015 Share Posted March 17, 2015 What I meant to ask was if you were hosting the target window surface that it was using as a render target (which is how PowerDVD works in the last couple/few versions, and interestingly enough how I think the WMC TMT player achieves its slick integration), or if it was a simple "shell-to-external-player" implementation. No, MPDN is still rendering onto its own window. I don't think it is possible to mix WPF and D3D rendering within the same window - at least, that is what the documentation says. It would be great if we could just get the HWND of the WPF window and point the player at that, but it supposedly will not work. Not tried it though. If you have the plumbing in place, and the results are promising it might make sense to POC the current internal player implementation as an external process. I'm not completely confident that it will fix all the performance issues (it will still render to a windows owned by the WPF application after all), but it might. Well, we certainly can try that. The player can create its own window, and the MBT-side code can handle re-parenting the WPF windows when the player starts up. This is how MPDN support works at the moment. Opt-in I hope? Also, how do you manage escalation issues? Filters can be marked as required or optional. If they are required, then the MBT setup wizard will not allow your to start MBT until they are installed (yourself, or via the wizard). If you do have a filter installed (required or optional), then you will be given the choice as to whether or not you want to update it, if a new release has been published (pulled from GitHub releases in the case of LAV and XySubFilter). The wizard is launched by the MBT process as a separate process with elevated privileges. Auto-updating once you have setup MBT and have it running will only work if MBT is being run as admin. If not, the option will be unavailable. You can also force the setup wizard to run again by launching MBT with the -setup argument. I may add options to this to run without the UI so that people can run an update as a scheduled task or such if people ask for it. Link to comment Share on other sites More sharing options...
babgvant 143 Posted March 17, 2015 Share Posted March 17, 2015 No, MPDN is still rendering onto its own window. I don't think it is possible to mix WPF and D3D rendering within the same window - at least, that is what the documentation says. It would be great if we could just get the HWND of the WPF window and point the player at that, but it supposedly will not work. Not tried it though. I think we're talking about the same thing. When I get some time I'll look at the implementation. Filters can be marked as required or optional. If they are required, then the MBT setup wizard will not allow your to start MBT until they are installed (yourself, or via the wizard). If you do have a filter installed (required or optional), then you will be given the choice as to whether or not you want to update it, if a new release has been published (pulled from GitHub releases in the case of LAV and XySubFilter). The wizard is launched by the MBT process as a separate process with elevated privileges. Auto-updating once you have setup MBT and have it running will only work if MBT is being run as admin. If not, the option will be unavailable. You can also force the setup wizard to run again by launching MBT with the -setup argument. I may add options to this to run without the UI so that people can run an update as a scheduled task or such if people ask for it. I don't think it's a good UX to require escalation rights to run the app. That's one of the reasons why the internal player uses registration free COM for the filters. Link to comment Share on other sites More sharing options...
Aphid 212 Posted March 17, 2015 Share Posted March 17, 2015 Yea, but the escalation is only needed if users want MBT to automatically update the filters that are installed on their system. It won't prompt for it if it does not have it - it just won't attempt to install filter updates. I do prefer that the internal player uses its own installs. Not just because it allows us to update them without escalation, but also because it helps make us more immune to poorly-configured systems, and prevents us from stepping over the configuration of other players. Adding MPDN support does put us in the awkward position of using both system-installed and private copies of these dependencies. Link to comment Share on other sites More sharing options...
Aphid 212 Posted March 17, 2015 Share Posted March 17, 2015 If we could convince the MPDN developers to give us an option, via command line or the config file, to point MPDN at our own filters instead of retrieving them from the registry - then that would be brilliant. That could be a fair bit of work on their end, though. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now