As an ideea for tiben and madshi, wouldn`t it be possible to have 2 branches of dsplayer, one with the modded XBMC code and madVR, which never gets submitted to TeamXBMC for merging with the main branch, and the one we have now, that will get submitted to the team for merging at some point?
@hentai
I would like it, no problem
Mike
madshi and tiben20, thanks for all the hard work.
It’s so depressing
Is there any way to plea to the xbmc team to change their decision?
@
GreenEyez
2 branches seem like a lot of work for tiben, which already have full plate.
GreenEyez Wrote:As an ideea for tiben and madshi, wouldn`t it be possible to have 2 branches of dsplayer, one with the modded XBMC code and madVR, which never gets submitted to TeamXBMC for merging with the main branch, and the one we have now, that will get submitted to the team for merging at some point?
I don't have much experience with branches and stuff like that. I've no idea how difficult it would be to maintain such branches. I guess someone with a bit of experience would have to volunteer to setup and maintain these branches and to do builds once in a while. Any volunteers for that?
Waven Wrote:Just tried it again and it worked :-) I don't understand exactly how these things work. But aren't stream selection and rendering two different things? So maybe LAV source/splitter selects the right stream and the subtitle engine in dsplayer does render it.?
I've had this discussion before and it doesn't work the way steelman1991 wants basically the way forced subs should work, XBMC will select the forced subtitle stream and turn them on LAV splitter will pre select forced subtitles but you still need to turn them on in XBMC and you cant just turn them on for everything because if forced subtitles don't exist and full subs do LAV doesn't stop sending those streams and you have subtitles again
If LAV stopped sending other streams altogether and only sent forced subs to XBMC then it would work as you could just have them on permanently for everything
madshi, one question for you: in your ideal version of this, would the On Screen Display during playback work the way it normally does in XBMC? Or would the OSD be non-functional due to added control by MadVR of D3D?
In any case, regarding branches, etc. I think that the only solution might be binary addons if they'll ever get implemented. Or a real fork in the code. Where changes get merged if and when deemed necessary.
Half of the interest for a proper DirectShow player comes from things like MadVR, yCMS, and so on and so forth. If you take those away, in a world where more and more stuff is in HD, what do you need DirectShow for?
0wing has been mantaining this and updating it for several months. With tiben's help, a fork/independent branch might be doable. But it's their decision.
I would actually like somebody from team-xbmc to give us their point of view on this. Being no coder it's tough for me to understand exactly what's going on.
madshi Wrote:I don't have much experience with branches and stuff like that. I've no idea how difficult it would be to maintain such branches. I guess someone with a bit of experience would have to volunteer to setup and maintain these branches and to do builds once in a while. Any volunteers for that?
I think That would be awesome if some one could maintain a branch and update now and then when they had a bit of free time. I know i would if i had the knowledge and skill anyone up for the challenge?
madshi Wrote:I don't have much experience with branches and stuff like that. I've no idea how difficult it would be to maintain such branches. I guess someone with a bit of experience would have to volunteer to setup and maintain these branches and to do builds once in a while. Any volunteers for that?
I haven`t coded or compiled anything in over 4 years, but if i manage to dust off some my skills a little during January 2012 i`ll contact Tiben and see if we can get it done, me doing the building of one of the branches. I also have 2 guides on AVS to take care off, so my time is short but i think i`ll manage.
ashlar Wrote:madshi, one question for you: in your ideal version of this, would the On Screen Display during playback work the way it normally does in XBMC? Or would the OSD be non-functional due to added control by MadVR of D3D?
The OSD would fully work. It might however be slightly less responsive. Meaning that there might be a small delay between pressing a key and seeing the OSD react.
ashlar Wrote:Half of the interest for a proper DirectShow player comes from things like MadVR, yCMS, and so on and so forth. If you take those away, in a world where more and more stuff is in HD, what do you need DirectShow for?
Well, of course by using ffmpeg/libav and rendering video directly through Direct3D or OpenGL, you can bypass DirectShow quite easily. But if you do that, you have to take care of everything yourself. If you instead simply use existing DirectShow filters, much of the work can be outsourced to the DirectShow filter developers. The general idea of DirectShow is that tasks are splitted into separate filters, so that not every media player has to reinvent the wheel. Whether content is in HD or not does not really make much of a difference, IMHO. E.g. many MPEG2 1080i60 broadcasts are notoriously difficult to handle and both decoder and video renderer have to work hard to make them display well without stuttering and combing artifacts.
Hi madshi, I intended Direct Show in the general (wrong) sense of directshow filters, splitters, etc. And I meant: if something like what tiben20 doesn't allow for things like MadVR, then it's a lot of work for very little gain. HD audio will soon arrive to XBMC, DXVA decoding happened a lot of time ago (it was the main reason people wanted a DirectShow player, back then)... it's the advanced, custom stuff that people interested in this look for.
Thanks for the OSD answer. I frankly fail to see team-xbmc point of view, then. I thought it would have meant doing away with the OSD.
madshi Wrote:I think I need to clear up a few things:
tiben20 and I have been working on making XBMC & madVR work together. There were still some problems to solve, but it looked like we would be able to get it to work soon enough. But then tiben20 talked to the XBMC team and the XBMC team decided that they didn't like what we did. Basically tiben20's patch was not "clean" enough for their taste.
The way XBMC currently works, it requires to be in control of Direct3D. Basically XBMC requires to be the one who decides which frames are rendered and presented how and when, taking 90% of the control away from madVR. It would be possible for me to make madVR work this way, but we'd lose *big* parts of the benefits madVR is supposed to bring. Basically I'd have to castrate madVR left and right, top and bottom to allow for a "clean" XBMC patch.
Let me ask you a question: What is the main task of an HTPC? Is it (1) rendering a nice GUI? Or is it (2) providing the best possible video quality? From what I understand, XBMC sets priority on the GUI and puts video rendering quality in the back seat. The only way to make video playback work as best as possible is to give full control to the video rendering component. If the video renderer isn't even allowed to decide when a video frame should be presented then there's no way the video renderer can guarantee smooth motion playback.
tiben20 and I were working on an XBMC patch which would have allowed madVR to have as much control as possible (still not 100%), preserving most of the benefits madVR is supposed to bring, without impacting the GUI too much. tiben20's patch took away Direct3D control from XBMC and passed it to madVR instead. The XBMC team decided that they didn't like this approach/patch. There's not much tiben20 and I can do about that.
IMHO the XBMC team should get their priorities straight. If they insist on letting the GUI code dictate everything, XBMC will never have a best quality integrated video playing quality, IMHO. You gotta decide which is more important, GUI or video playback. And then you gotta give Direct3D control to the more important component.
Of course this is only my 2 cents.
Edit: Just to make it extra clear: The reason why XBMC + madVR seemingly aren't going to happen anytime soon is neither tiben20 nor me (we both tried), the reason is the decision of the XBMC team. So if you want to complain, complain to them. It makes no sense for me to remove 70-80% of the madVR features/benefits just to make the patch acceptable to the XBMC team.
Most users of DSPlayer I'm sure will consider a better renderer more important than the GUI.
Quote:"preserving most of the benefits madVR is supposed to bring"
what "parts" of madVR do you sacrifice in the current implementation that you are (were) working on?
In your ideal implementation of madVR with XBMC; what do we have to give up? Is it just that madVR dictates when the GUI should be presented (less responsive)?
That's a good thing, is it not? That means there will be no risk of stuttering when using the GUI on top of the video?
ashlar Wrote:if something like what tiben20 doesn't allow for things like MadVR, then it's a lot of work for very little gain. HD audio will soon arrive to XBMC, DXVA decoding happened a lot of time ago (it was the main reason people wanted a DirectShow player, back then)
Thanks for the OSD answer. I frankly fail to see team-xbmc point of view, then. I thought it would have meant doing away with the OSD.
I don't think that's necessarily true. With the introduction of 10-bit video encodes, DSPlayer enables playback without having to wait for the XBMC team to update FFMPEG versions, which from the sound of it, is a lengthy process and will probably only happen once every 6 months to a year. On Linux, you at least have the ability to use an external FFMPEG install; on Windows, you're stuck waiting for an update. DirectShow filters let us gain access to all of the latest formats and containers.
Once XBMC is updated to support binary add-ons, hopefully DSPlayer can be downloaded as an add-on player, so Tiben can continue tweaking it as he sees fit without having to worry about it clashing with the team's vision of the app.
Waven - Does that screenshot of the xbmc gui reflect all your movies ie: do you have the subtitle box checked for all movies - even those that don't have forced subtitles?
maruchan Wrote:Once XBMC is updated to support binary add-ons, hopefully DSPlayer can be downloaded as an add-on player, so Tiben can continue tweaking it as he sees fit without having to worry about it clashing with the team's vision of the app.
binary add-ons and dsplayer as an add-on is the only way dsplayer is really going to succeed. Otherwise i fear it will be stuck as a branch and sub-forum thread.
I'm also willing to bet that eventually there will be other directshow player add-ons as well.
Cheers
