plugin support for MPC

[stax76]

I wish MPC had a plugin interface, plugins could add features like adding support for more remote control like the MS MCE remote control I got (removing the need for application like EventGhost). Plugins could add Media Center features or communicate with Media Center applications to use MPC as external player with better integration than usual external players. Fancy transparent skinned OSD stuff is not hard using WPF. A UI for keys customizations with search and learn feature to improve usability would be nice. I'm sure people would have a lot ideas for plugins.

The three main options for a plugin interface are C, COM and .NET, .NET would require using C++/CLR which MPC developers certainly wouldn't like, C would exclude languages like C#, VB .NET and Python. What's left is COM which is supported by the majority of languages.

I could build such plugin interface, problem is I my C++/MFC/COM skills are poor since I use .NET most of the time. After all dshow is COM based so maybe a MPC developer can build a interface or somebody else with C++/COM experience also wanting a plugin interface. If there is nobody wanting to do it then I surely will if the MPC developers want me to.

The plugin interface could look similar like a shell extensions, it's pretty simple, plugins would implement a COM class which MPC would create a instance and pass a COM object into providing a interface plugins can use.

A simple C or .NET way for loading plugins is dynamically loading library files in a plugin directory, with COM it don't has to be more difficult, instead of a directory with DLLs to load dynamically there is a registry key containing the ProgIDs of the plugins.

For somebody with experience building the thing should not be that hard using ATL wizards.

A simple plugin could in VB .NET then look like:

Imports System.Runtime.InteropServices

<ComClass()> _
Public Class Plugin
    Implements IPlugin

    Private Player As IPlayer

    Public Sub Init(ByVal player As IPlayer) Implements IPlugin.Init
        Me.Player = player
    End Sub
End Class

<ComImport(), Guid("CLSID...")> _
Public Interface IPlugin
    Sub Init(ByVal i As IPlayer)
End Interface

<ComImport(), Guid("CLSID...")> _
Public Interface IPlayer

End Interface

[tetsuo55]

Would you be able to write this plugin support?

[stax76]

Yes, I would be able, the question is if MPC devs have interest of me or somebody else doing it. I could also build a VB .NET player from scratch, a lot C# code that can be reused is in MediaPortal and MeediOS, I just have to run 'Instant VB' on in order to convert the C# code to VB .NET. Or maybe somebody wants to do a player in C#.

[tetsuo55]

A lot of end-users would like plugins for non-essential parts of MPC.

I am the project manager for MPC-HC and i personally think a plugin system would be great.
The final decision lies with Casimir666.

I doubt he would say no, but i do not think he will spend time on keeping this part of the code up to date.
Also it must be coded securely to prevent security leaks.

Please PM Casimir666

I would personally prefer you join the MPC-HC team instead of writing a new player.

[clsid]

I think this idea is doomed to fail. A plugin system is only useful if it is restricted to a specific part of the players's functionality, and if there is a large variety of features that could be added to that specific part of the player. Otherwise it would be simpler to implement such functionality directly in the player.

For example:
Visualizations -> plugins would be useful
OSD -> plugins could be useful
Key bindings -> better to implement directly (since we don't need different variations of it)
Media center stuff -> a generic communication API would be the way to go

I suggest you guys come up with some more specific feature ideas.

[ChronoReverse]

It would be nice to have a better interface for the key binding. A way to bind keys by keypress search for instance.

[stax76]

It seems WPF becomes much faster popular than I thought it would be and Microsoft is very dedicated to it since all new applications are WPF based and Microsoft is replacing many parts of their native applications with managed parts, more and more of the UI is moved to WPF which is a huge managed but hardware accelerated UI API perfectly suited for skins and OSDs of media applications. Even critical parts like the text editing component in Visual Studio have been moved to WPF and not only that but the editor gets also very powerful entirely managed extensibility based on a new and much touted extensibility framework called Managed Extensibility Framework.

Lot's of applications move on, both big media centers Media Portal and MeediOS moved to WPF (though MP has a own renderer). While some of these applications feel slow and bloated, it's perfectly possible to build lightweight and responsive managed applications. A player don't has to initialize a complex WPF interface like Expression Blend for instance. The reason why MediaPortal needs five seconds to start instead of one is mostly because it parses like 100 XML files with slow IO access plus it's occasionally badly programmed, sure a native application can start very fast but working with MFC is a lot more demanding and limiting compared to managed tools.

There are different possibilities to extend native applications with managed code, a very efficient one is C++/CLR in mixed mode which don't necessarily has to be enabled for a entire application but can only be enabled for certain parts of a native application which then can either interoperate directly with code written in other managed languages or provide a extensibility interface in order to incorporate managed code dynamically. Even a larger amount of managed extension libraries don't need to have a big performance impact as libraries can be loaded on demand or in the background. When the developers spend time to optimize and polish the application the user experience will be good and modularity also helps to keep applications lightweight as only modules can be enabled that are actually needed.

Media applications are traditionally extendable because there is always a feature missing that some user might like and automation and extensibility can provide a easy way to extend a application with depending on interface wide range of easy to use and popular scripting and programming languages. All of the following applications are extendable and many of them gained a lot from the available extensions: Windows Media Center, Windows Media Player, Media Portal, MeediOS, Foobar2000, WinAmp, KMPlayer, AviSynth of course and all powerful MediaMonkey and DVBViewer with impressive SDKs due to the ease which Delphi brought to COM programming. Almost all have skins (which is trivial to do since WPF) and many can be automated with window messages, since MFC is a thin layer around the message based Win32 UI API even MPC can be automated with that.

DVD Decrypter could still be alive if the decrypting part was a extension instead of being built in, years before DVD Decrypter was developed DVB hackers provided decrypting via extensions.

Dynamic programming is perfectly suited to automate and extend applications. If you are following past, recent and future developments of Microsoft you already know there is a huge trend in dynamic programming, IronPython, IronRuby or Boo, Dynamic Language Runtime as part of .NET 4.0 and Silverlight 2.0, managed JScript as primary dynamic language for Silverlight, rumors of a dynamic VB version, Dynamic features in C# 4.0, the C# and VB compiler being redone/moved to managed code and opened up to provide advanced services.

While many people don't see the need to incorporate a managed UI or managed or COM extensibility into MPC I think it's a very interesting idea with great possibilities which I like to examine further. As far as I know MPC is the only reasonable dshow open source player and while a managed player is doable I don't think somebody will actually build one since it's a big task and there are already rich players. This leaves MPC as only reasonable solution to built upon.