[Videos] Adding madVR support (1 Viewer)

hoborg

Portal Pro
June 13, 2008
4,413
1,644
Nový Jičín
Home Country
Czech Republic Czech Republic
Hi,
After a year, where is the situation ?
MadVr is an actor, in Display Family as EVR.
i understand Tourettes your position about MPAR, why work for nothing !

@hoborg : can you converse with Madshi for add support of MPAR ? I understand is a specific dev for he.

Screenshot for comparaison with MadVR (1)
Hi.
Well, i am not in any contact with Madshi and i am not a part of MePo devs either.
 

Andy22

Portal Member
September 10, 2011
46
4
I don't see any change, for the MePo developers supporting and rewriting there UI interface to support MadVR is at low priority or has even no priority. I guess most MePo users are happy with the quality of EVR and the native features. I still use MePo, but only because it has MyAnime3 and there is nothing close to it on any other mediacenter. Using MePo + MPC-HC as external player works, the only complain i have is that MP always flags episodes "watched" even if u just open and close it for a few seconds.

On the technical side, MadVR has a public UI interface for overlays for some time now and also a new subtitle interface to fully support future xy-VSFilter versions, with subtitles that are not upscaled and can be directly send to MadVR. So technically there is nothing that prevents MadVR implementation in any player anymore.

So i would not get my hopes up, since MP2 will need a lot of work and i don't see a developer devoted enough to this feature, which "works" using a external player.
 
Last edited:

infinite.loop

Retired Team Member
  • Premium Supporter
  • December 26, 2004
    16,163
    4,133
    127.0.0.1
    Home Country
    Austria Austria
    There was quite some research done internally during the last months regarding image quality, 3d support, etc.
    The bottom line was that switching to/supporting MadVR is more work than it's worth. Actually we do not gain anything from a switch, because what madvr can we we can also do on our own without to rely on 3rd party code.

    There is absolutely no time-frame for this. The code that exists is only a POC at the moment and the developer who did the research and POC is currently in the hospital. I am sure he will reply here once he can. :)
     
    Last edited:

    infinite.loop

    Retired Team Member
  • Premium Supporter
  • December 26, 2004
    16,163
    4,133
    127.0.0.1
    Home Country
    Austria Austria
    because what madvr can we we can also do on our own without to rely on 3rd party code.
    but is not more speed to use madvr, with all feedback done ?
    You mean if it would be faster for us to implement madvr?
    No, because of all the work around it / changes inside MP that are required to get the same experienced.

    Generally speaking a 3rd party application must have KILLER features to take the risk to build your system upon. mtn, live555, gentle .... prime examples in our code of how relying on 3rd party software can be very problematic when the project dies.

    Supporting multiple different renderers is simply not possible with the somewhat limited development resources we have.
     
    Last edited:

    Andy22

    Portal Member
    September 10, 2011
    46
    4
    Actually we do not gain anything from a switch, because what madvr can we we can also do on our own without to rely on 3rd party code.

    As a programmer myself i accept the trouble of supporting/switching to a new interface, if there is no/less gain for the average user.
    I'm still a little skeptical that u can match MadVR render/output quality, given the sheer amount of "different" encodes out there. MadVR does more than just using some fancy scaling routines like Sinc/Spline. For me the 10bit support is very important and the ability to setup all Level/scaling/gamma/input range related things at the end of the pipeline, since this allows for a greater chance to actually get "correct" outputs on different input materials. In theory even ffdshow + EVR or any player out there should be able to produce "correct" and good scaled outputs, but in reality this often fails, because of several Level/Colorrange or simply bad DShow filter color range conversion.

    To me as a programmer supporting MadVR would simply mean to skip all those crazy display pipeline problems, so i can focus on other things. I read the MadVr thread from time to time and i'm always amazed how many things can go wrong or bad if u care about image quality in your playback pipeline. So maybe this is a incentive for supporting MadVR? Ofc i also understand the problems of using MadVR from a license standpoint, since its closed source.

    bye Andy
     

    Users who are viewing this thread

    Top Bottom