[FernetMenta]

Kodi's video player is one of the oldest and most important components of the application. New features and ports to new platforms have long outgrown the original architecture of player. From its internal name "dvdplayer" you can tell how old this component is. In order to cope with current and future requirements like Ultra HD, MVC, 10bit depth, or PiP some elementary changes need to be done. The problem is that those changes require adjustments of platform dependent code. This dependency tremendously slows down development.

Ideally video player is a self contained component or service with its own life cycle and versioning. This would allow updates and upgrades independently from the main application. One platform could choose to stay with version X while others go with version Y. Maybe video player itself will be comprised of services with its own versions: decoders, demuxers, video/audio renderers, etc.

This is a long way and we need to get started somewhere. I requested this sub-forum to get platform devs involved, document and discuss what has been done so far, next steps, etc.

[Memphiz]

subscribed

[natethomas]

I'm experiencing some deja vu. I feel like I had this exact same discussion with somebody when binary addons were first being explained to me.

[ironic_monkey]

that's because again it's the complete disconnect between your all-platforms-or-none principle and the available devs that is at the core of the problem. learn or redo old mistakes (if the latter, prepare to be called clueless rainer).

[RockerC]

Ideally video player is a self contained component or service with its own life cycle and versioning. This would allow updates and upgrades independently from the main application. One platform could choose to stay with version X while others go with version Y. Maybe video player itself will be comprised of services with its own versions: decoders, demuxers, video/audio renderers, etc.

So you are talking about Kodi ultimately supporting and having multiple video players as self-contained binary addons?

Nice! Supporting such video players (and audio players?) as binary add-ons should indeed allow the support for rolling updates outside major releases of multiple video/audio player with dependencies, and as such could possible also help speed up development and testing of individial players on each platform.

[FernetMenta]

So you are talking about Kodi ultimately supporting and having multiple video players as self-contained binary addons?

Basically that's kind of the idea but we are very far from this goal. This is really bad spaghetti code that grew over time. At this time I am not sure if this can be slowly transformed into the desired state or we need the sledgehammer and re-write lot of this code in core.

[Martijn]

@FernetMenta
is you master branch in a state where we could start providing public builds for OSX and Windows to get feedback for those platforms? Doing so might reveal some minor problems and gets it ready for merge in first 17 alpha. Once Android is build-able we can add that to the list as well in the test thread.

[FernetMenta]

@FernetMenta
is you master branch in a state where we could start providing public builds for OSX and Windows to get feedback for those platforms? Doing so might reveal some minor problems and gets it ready for merge in first 17 alpha. Once Android is build-able we can add that to the list as well in the test thread.

I don't compile for Windows and did not get any feedback from a Windows dev recently. OSX is fine running on my laptop LCD but needs a few things to fix for fullscreen with refresh rate switching.

[erhnam]

Just out of curiosity, what are your timelines? And what have been implemented at stage and what's on your todo or bucket list?

[FernetMenta]

Just out of curiosity, what are your timelines? And what have been implemented at stage and what's on your todo or bucket list?

See the forum threads in this section. git diff to mainline shows: Showing 987 changed files with 5,351 additions and 1,896 deletions. Those first changes are scheduled for 17.0 alpha.

In parallel I just started to split the render thread. That's going to be a lot of work I guess.

[Martijn]

@FernetMenta somewhere hidden in our code is the ability for plugins to dictate which player it should use. I already removed this from API docs but seems the code is still there.
For reference this was TheUni's try on killing it https://github.com/xbmc/xbmc/pull/1427
Could you perhaps take this in account and kill off that feature? Should this be needed back in future it should be done the proper way by asking Kodi a list of available players instead of hardcoding it.

Semi related is:
https://github.com/xbmc/xbmc/pull/4781

Since the refactor is happening any way perhaps this could be tackled.

[topfs2]

Could you perhaps take this in account and kill off that feature? Should this be needed back in future it should be done the proper way by asking Kodi a list of available players instead of hardcoding it.

+1 Always hated the feature

[da-anda]

+1

I'd also like to differ between player and renderer. While we should drop the ability to specify the player used by the local Kodi instance, we still have to give the option to specify the renderer, which would be "local" and any remote playing source found (UPNP renderers).

Btw - I'd actually also drop the possibility to select specific internal players in the "play using" feature and only give the option to select default/internal, external players specified in as.xml and UPNP sources. Ideally though UPNP sources would not show up there but rather in a "play to" context item, which could also be exposed in GUI (to allow pushing playback to a different device while watching, like when you start on TV in living room and want to finish in bedroom or on tablet).

edit: option to select internal player implementation could be enabled via some expert setting if needed (like for debugging and comparing dvdplayer vs omxplayer)

[FernetMenta]

I will look into this and consider it.

[madshi]

Ideally video player is a self contained component or service with its own life cycle and versioning. This would allow updates and upgrades independently from the main application. One platform could choose to stay with version X while others go with version Y. Maybe video player itself will be comprised of services with its own versions: decoders, demuxers, video/audio renderers, etc.

I think that's a very good idea.

Specifically for Windows: Could this be a good opportunity to maybe join efforts with the DSPlayer dev(s)? E.g. in Windows we already have the excellent "LAV" DirectShow package which includes the best of libav/ffmpeg for movie playback, combined with some more decoders from other sources (e.g. Intel QuickSync). Also we have different subtitle renderers available for DirectShow, and besides EVR we also have madVR for video rendering. There are also good quality standalone DirectShow audio renderers in the works, like e.g. Sanear. Making use of all that would reduce the strain on Kodi developers, because they would not have to bother with all that sort of stuff for Windows, anymore, but could instead rely on those external packages. Also there would be no duplicate efforts for Kodi DVDPlayer & DSPlayer devs, anymore. The current main DSPlayer dev already expressed willingness to work on DSPlayer in such a way that changes to Kodi itself would be minimal. Maybe worth a thought?

I understand that on other OSs, e.g. Linux, there's no general framework available for media player components, so for those OSs it probably makes sense to include all the decoders and renderers in Kodi itself. But since in Windows the situation is different and there are high quality external components available, isn't it worth reevaluating the situation, just for Windows?