[da-anda]

We want an out of the box experience with no additional work needed for end users - so installing third party LAV filter packages and what not is no option for a default setup. So we'll always have to do the Windows work - DSplayer won't help on this. Also it would add a huge additional support burden, as it will be way way harder to find a certain playback bug reported by users if we'd depend on random DirectShow filters.

[Martijn]

Seeing the complexity added in the DSplayer i really doubt this will ever be added to our master branch. It requires a vast array of configuration and tweaking which as da-anda already said is not new user friendly. It will also require a lot of maintenance which we can't do with a small team.

Who knows the videoplayer rework might all make it way easier but only future will tell.

[aracnoz]

actually DSPlayer comes with built-in filters to work out of box without any configuration

in the last six months i worked even harder to try to reproduce the original Kodi experience with DSPlayer, so everything configurable with a remote through the Kodi GUI, without any external windows, xml file or extra installations with also the final purpose to not lose any advanced functionality for high end users

this is a demostrative video that i made some months ago with the final result https://www.youtube.com/watch?v=BBRhWBI-Or4

I know that will be needed some additional efforts to make this officially in Kodi but please you have also to consider the advantages

p.s.

this is absolutely premature but some weeks ago I prepared a branch based on this videoplayer rework https://github.com/afedchin/xbmc/tree/videoplayer

just to show how DSPlayer currently is integrated in Kodi, more optimizations could be done to make it even less invasive in the original code

https://github.com/aracnoz/xbmc/commits/..._optimized

[FernetMenta]

DSPlayer's sources will certainly never hit our main repository. That should be clear from reading post #1 of this thread. The goal is to componentize and not adding more very platform specific code that is hard to maintain.

I know that will be needed some additional efforts to make this officially in Kodi but please you have also to consider the advantages

What exactly would be the advantage?

[AchimTuran]

@FernetMenta

Sorry for my dumb question. I didn't had the chance to look deeper into your work on VideoPlayer integration.

Is it possible to turn DSPlayer into an binary addon? I donn't know if it possible or how much effort it takes to make this happen.

It is just an idea that come into my mind, while reading this thread.

btw. is DSPlayer so much better than our dvdplayer? How many users do actually use DSPlayer?

[fritsch]

That's what we want to know from the OP - what "features" are needed for the majority of the users that dsplayer can deliver - but only on windows - with no support for all our other platforms.

[FernetMenta]

@FernetMenta

Is it possible to turn DSPlayer into an binary addon? I donn't know if it possible or how much effort it takes to make this happen.

Not at the moment but this would be the right strategy.

[aracnoz]

currently most Windows users use DSPlayer for the integration with madVR

High quality scaling (Jinc, super-xbr, NNEDI3, etc), artifacts removal (debanding), image enhancements with advanced sharpen algorithms
gamut & gamma correction via 3D LUTs, etc etc...

I always saw differences in picture quality by using madVR, but now with all these UHDTV and without any UHD sources available i think that also some inexpert users could notice the improvements

then there are also other features/preferences that push users to use DSPlayer

many of them love to use SmoothVideo Project (SVP) through ffdshow
tweak their audio settings with ffdshow audio processor
use the high quality subtitles filter XySubfilter
use ReClock as audio renderer
also the development on sanear as audio renderer seems very promising
someone is testing Lentoid's performances as HEVC video decoder

I don't want bore you with a long list, i think that there are clear advantages in having a directshow player for Windows

honestly I don't know how many DSPlayer's users there are out there, but the number seems to grow up day by day seeing in my thread

anway when i saw this thread the first time I thought that the final goal was the possibility to have differents videoplayer as binary addons

if one day Kodi will reach this result i will ready to move DSPlayer in that direction

[FernetMenta]

if one day Kodi will reach this result i will ready to move DSPlayer in that direction

One thing I most dislike about the DSPlayer project and projects like dual audio: http://forum.kodi.tv/showthread.php?tid=192480

I haven't seen you contributing a single line of code to our code base.

[madshi]

We want an out of the box experience with no additional work needed for end users - so installing third party LAV filter packages and what not is no option for a default setup. So we'll always have to do the Windows work - DSplayer won't help on this. Also it would add a huge additional support burden, as it will be way way harder to find a certain playback bug reported by users if we'd depend on random DirectShow filters.

Fair enough. I already expected this to be a major reason for not using DirectShow. I'm not convinced that it's the "right" solution for Windows users. But anyway, maybe there's a way to make us all happy:

DSPlayer's sources will certainly never hit our main repository. That should be clear from reading post #1 of this thread. The goal is to componentize and not adding more very platform specific code that is hard to maintain.

Is it possible to turn DSPlayer into an binary addon?

Not at the moment but this would be the right strategy.

When you originally said: "Ideally video player is a self contained component or service with its own life cycle and versioning" I had thought you meant this on a source code level, only. But now I think I misread your post and you were thinking about doing this on a binary level? That would have several advantages, of course:

1) Users could update binaries separately, and thus use different versions of the video player and different versions of the "rest".
2) DSPlayer could be turned into a binary that is fully compatible to the default DVDPlayer (or whatever the new separate component will be named).
3) Maybe even external media players (like MPC-HC/BE on Windows) could be extended to work as a fully Kodi compatible video player component, with full Kodi GUI integration and stuff.

This sounds like a promising approach. One key thing for this to work would be a *very stable* interface, of course. Not like ffmpeg/libav where you constantly have to adjust the code and recompile because often not even the source code interface stays stable, let alone the binaries. This Kodi binary interface would also have to include things like GPU sharing, so that the Kodi GUI can be drawn on top of the video. A key question here is which component would do the presentation (telling the GPU when to display which frame)? Probably you're thinking now it should be the GUI, because the GUI is the component that controls everything and the GUI will often be active even if no video is playing. However, being a video renderer developer, I have to say that having full control over the whole video rendering pipeline is important to achieve the best quality. E.g. features like "smootion motion FRC" (real time frame blending to achieve non-juddery motion when playing 24fps movies at 60Hz) would be next to impossible to realize for a video player if some "outside party" ultimately makes the decision which frames are displayed when. So I would strongly suggest an interface which allows either component (video player or GUI) to take control over presentation.

Maybe a first good step would be to try to define a binary interface that would satisfy the following requirements:

a) It should allow to preserve all the key functionality of the current DVDPlayer, while allowing a clean split of both source code and binaries.
b) The interface should be carefully designed to be upward *and* downward compatible. If this is done with proper thought, right from the start, it's not too difficult to achieve.
c) It would be great if the interface wishes (if any extra) of the current DSPlayer dev (aracnoz) could be taken into account, too.

One key question would be if this interface would (for now) only be limited to video playback, or if you want to split off even more things into separate packages?

Thoughts?

One thing I most dislike about the DSPlayer project and projects like dual audio: http://forum.kodi.tv/showthread.php?tid=192480

I haven't seen you contributing a single line of code to our code base.

I understand that. But please consider that aracnoz' work has brought several new users to Kodi. So although he may not have contributed to the Kodi code base itself, he still helped Kodi to grow its user base. Furthermore I guess many DSPlayer devs in the past had the (faint) hope that their code would some day find its way to the Kodi code base. I know tiben20 did, so did aracnoz, even if the hope was maybe low. So complaining that aracnoz has not contributed to the Kodi code base, but at the same time refusing to accept DSPlayer code into the Kodi code base is a somewhat unfair combination, IMHO. If you decided to accept some DSPlayer code into the Kodi code base, automatically aracnoz would have contributed quite a lot of code to Kodi.

[Razze]

One thing I most dislike about the DSPlayer project and projects like dual audio: http://forum.kodi.tv/showthread.php?tid=192480

I haven't seen you contributing a single line of code to our code base.

I understand that. But please consider that aracnoz' work has brought several new users to Kodi. So although he may not have contributed to the Kodi code base itself, he still helped Kodi to grow its user base. Furthermore I guess many DSPlayer devs in the past had the (faint) hope that their code would some day find its way to the Kodi code base. I know tiben20 did, so did aracnoz, even if the hope was maybe low. So complaining that aracnoz has not contributed to the Kodi code base, but at the same time refusing to accept DSPlayer code into the Kodi code base is a somewhat unfair combination, IMHO. If you decided to accept some DSPlayer code into the Kodi code base, automatically aracnoz would have contributed quite a lot of code to Kodi.

Just one quick thing:
I feel integrating this would make the platforms very, very different and even harder to support.

And it feels like it's somehow against our values "Try to make all code, feature, and functions to be platform agnostic"
http://kodi.wiki/view/Development#Team-K..._strive_to

And yes, those values are not set in stone, but they're there for a reason.

[FernetMenta]

Great madshi, this is the kind of posts I like to read here. Very good thoughts. This just got started and is at the very beginning. It's really a long way to go. Kodi's code base has grown over time and architecture has suffered and decayed.
Before we can define interfaces we need to cut some spaghetti code first. Currently video player has too many dependencies to the outside world and vice versa. IMO the most critical flaw is that the main thread is also the render thread and the main loop drives it all. I am working on a slit: http://forum.kodi.tv/showthread.php?tid=240870

One key question would be if this interface would (for now) only be limited to video playback, or if you want to split off even more things into separate packages?

Thoughts?

This work focuses on video player which is comprised of components like decoding of audio/video/subs etc and rendering. I want to separate this in a way that video player can be used for transcoding by registering an encoder for rendering.

So complaining that aracnoz has not contributed to the Kodi code base, but at the same time refusing to accept DSPlayer code into the Kodi code base is a somewhat unfair combination, IMHO.

Nobody has been able to reject anything because we haven't seen any pull request so far. I was referring to aracnoz repo I had a brief look. Even binaries are in this tree and I could not see anything that was in-line with this strategy here. I may be wrong though. Submit some PR and we can discuss proposed changes.

[aracnoz]

I can speak only for me because I'm not the original DSPlayer developer...

but I think there are different interpretations

I have never seen my work with DSPlayer so far from the official version, each step that i made to reproduce the original Kodi experience with a player based on direct show filters or each time that i preferred to make my work more difficult to not introduce changes in the original Kodi code, the days, weeks and months that i past by developing, i made this for Kodi and not against Kodi

I do not think that my role in kodi should be seen differently from the skin's developers, My only fault is that my work is not applicable to all platforms

in the past i tried to help but no one has never considered what i was saying so i preferred to not insist by presenting some pull request
e.g here http://forum.kodi.tv/showthread.php?tid=223530 i think that this bug it's always there, i also made a video https://www.youtube.com/watch?v=kiWmP3KHTwA
now are past some months... but if I remember I was thinking to something like that https://github.com/aracnoz/xbmc/commit/3...e07d8b348c

I also opened a thread with some suggestions even with the final purpose to open a dialog between us

then I have to admit that all that I have done until now with DSPlayer had a huge price to make it possible, sometime I also thought "how can I continue to do my real work, live and develop the DSPlayer part?" ,
so it's possible that my contribution in other things might not be so big as I would like

yeah, madshi it's really a special guy, and i'm sure that each of you has more experiences, skills and kodi's knowledge to do this job better then me, I really do not know where to start

i only know what i've done, so include a direct show player in the current kodi master branch without touch or enter in conflicts with the original functionalities

I'm not a saint but I do not think I should apologize for what I did

anyway, I can understand your points but honestly I only see the alot of "no" "never" "it's useless and without advantages"

so maybe it's not this time

[madshi]

Full disclosure: I'm not a Kodi dev myself, and I can't become one, because that would be a conflict of interests (I need to support all media players who support (or who don't support) my madVR in the same way, so I can't start developing for one media player but not for the others). I'm very willing to help with thoughts and ideas, though, if you find them useful.

Kodi's code base has grown over time and architecture has suffered and decayed.
Before we can define interfaces we need to cut some spaghetti code first.

Yeah, every dev's daily problem!

Here's a wild thought, and it might be totally unhelpful, but I'll post it anyway: Maybe one way to reduce the spaghetti code would be to start with defining the future interface, and then by making it work step by step with the current code base by gradually replacing the current "direct interaction" between GUI and DVDPlayer with the new interface? That way you could slowly work towards a complete split without having to work on a separate code base and without breaking anything on the way? But as I said, just a wild thought. Maybe working on a completely separate code base would be more efficient, or less dangerous, I'm not sure.

This work focuses on video player which is comprised of components like decoding of audio/video/subs etc and rendering. I want to separate this in a way that video player can be used for transcoding by registering an encoder for rendering.

Would the encoder then be part of the video player component, or would the encoder be another separate component? In theory an encoder doesn't sound like it would be a logical part of a "video player". But if it's another external component, and if the video player supports using such an external component, then logically a normal video renderer would also be external? This begs the question into how many pieces you want to split the whole thing? One extreme would be to split every decoder, splitter and renderer into separate components. The other extreme would be to put all video playback related stuff into one big video playback component. But in the latter case I'm not sure how to fit encoding into it logically.

If you want to keep providing all the splitters and decoders yourself, then I suppose splitting them all into separate components probably wouldn't make much sense. Most of them will be libav/ffmpeg based, anyway. Makes sense to keep all that together, I would say. Supporting multiple different external renderers might make some sense. Then you could either use an "encoder" or a "presenter", for both audio and video. But is it worth splitting renderers into external components just to make encoding possible? I'm not sure how important encoding is for Kodi...

-------

@aracnoz, I just hope you don't get de-motivated. I very much appreciate all the work you've invested. Especially to add support for madVR, of course...

[Warner306]

I would like to point developers in this forum to this post by aracnoz: 2170377 (post).

It is a disappointment the code for DSPlayer is dead due to his departure. This is his personal decision and not a reflection of Team Kodi, but still very disappointing given the stable nature of the player.

I can't comment on what intentions are behind typed correspondence, but the response to aracnoz's requests could have been handled better. The messages from Team Kodi can be very cold at times. Please remember that when typing responses to users. A Team Kodi title implies a response from an official dignitary, and users outside the developers' club can feel shunned. This has also been my experience in the past with a select few Team Kodi members not named in this thread.