home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Development
Improvement Suggestions
Adding madVR support
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Andy22" data-source="post: 929880" data-attributes="member: 115420"><p>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.</p><p>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.</p><p> </p><p>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.</p><p> </p><p>bye Andy</p></blockquote><p></p>
[QUOTE="Andy22, post: 929880, member: 115420"] 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 [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Development
Improvement Suggestions
Adding madVR support
Contact us
RSS
Top
Bottom