Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Hardware & Software > Software players

Reply
 
Thread Tools Search this Thread Display Modes
Old 19th October 2011, 15:26   #10221  |  Link
noee
Registered User
 
Join Date: Jan 2007
Posts: 530
"Best" is tough to define and in this case, subjective. If you care about h/w deinterlacing and madVR is your renderer of choice, then it seems nV might get the nod. If you can live with software deinterlacing, IMO, ATI 6xxx series is the way to go. Value of the 65xx series is hard to beat.
noee is offline   Reply With Quote
Old 19th October 2011, 16:24   #10222  |  Link
ajp_anton
Registered User
 
ajp_anton's Avatar
 
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 782
Feature request:
Add information about the matrix used and levels into ctrl+J, so I don't have to go around checking ctrl+shift+alt+M/I.
Also, when scrolling through ctrl+shift+alt+M/I, the "default" setting always says "(auto detect)". Is it possible to differentiate between for example BT.709 that is guessed based on the resolution, and streams that actually have the BT.709 flag?
And if I "accidentally" activate gamma processing by pressing ctrl+shift+alt+F/G, there doesn't seem to be a way to disable it without unchecking the box in the settings.

edit:
I also have a video where ctrl+shift+alt+M doesn't do anything but change the text that says BT.709 or BT.601. Image stays at 709. If you don't know why, I'll try to cut out a small piece of it. It's 10-bit, 709 at PC levels.

edit2:
nevermind the previous edit, I'm an idiot =).

Last edited by ajp_anton; 19th October 2011 at 18:07.
ajp_anton is offline   Reply With Quote
Old 19th October 2011, 17:03   #10223  |  Link
toniash
Registered User
 
Join Date: Oct 2010
Posts: 116
frequency change

I own a Sony Tv that can work at 50 or 60 hz.
Until now I'm using Reclock to do 24fps -> 25fps and change the Tv set accordingly 24/25 fps -> 50Hz 29.97/30 fps -> 60 Hz
Is it possible to let Reclock change 24 fps to 25 fps and Madvr change the frequency?
toniash is offline   Reply With Quote
Old 19th October 2011, 17:32   #10224  |  Link
XRyche
Registered User
 
Join Date: May 2008
Posts: 210
madshi, do you have any plans on adding colour controls(contrast, brightness, saturation, hue) to madVR?
XRyche is offline   Reply With Quote
Old 19th October 2011, 17:43   #10225  |  Link
nand chan
( ≖‿≖)
 
Join Date: Jul 2011
Location: BW, Germany
Posts: 380
Quote:
Originally Posted by XRyche View Post
madshi, do you have any plans on adding colour controls(contrast, brightness, saturation, hue) to madVR?
You can use a .3dlut for this
__________________
Forget about my old .3dlut stuff, just use mpv if you want accurate color management
nand chan is offline   Reply With Quote
Old 19th October 2011, 18:07   #10226  |  Link
TheShadowRunner
Registered User
 
TheShadowRunner's Avatar
 
Join Date: Feb 2004
Posts: 399
madshi, I'm closing-in on figuring out the slow ZP / control bar seek freeze bug.
You were right, it seems to be a ZP bug..
After much testing, I found out that when I disable ZP's Interface > OSD > Action > "Show OSD filename when opening a new file", the issue _never_ happens (control bar always fast, never freezes)
However with this feature disabled, more often than not I get a beautiful crash in madVR.ax as soon as playback starts.
I enclose a debug log. Could you check if anything strange is going on on madVR side that explains the crash?
__________________
XP SP3 / Geforce 8500 / Zoom Player

Last edited by TheShadowRunner; 19th October 2011 at 18:16.
TheShadowRunner is offline   Reply With Quote
Old 20th October 2011, 02:44   #10227  |  Link
6233638
Registered User
 
Join Date: Apr 2009
Posts: 1,019
Quote:
Originally Posted by madshi View Post
I've checked test patterns with an "empty" 3dlut and found pretty much zero changes, when turning the 3dlut on/off. If you have a reproducible test case with an "empty" 3dlut (meaning a 3dlut which doesn't actually change anything), causing discoloration/banding, please let me know and help me reproduce the problem.
Right, there are no problems with an "empty" LUT, it's once you start making changes—particularly at the lower end of the greyscale—that problems arise.

Quote:
Originally Posted by madshi View Post
No, it does not. Please look up "dithering" and how it works.
I know how dithering works. But once you are in the lower-end of the greyscale (say 20% and under, particularly at higher gammas) single RGB value changes can make considerable differences on the display.

With CRTs, this was significantly less of an issue, as +/- 1 RGB resulted in very small changes on the display, as being analogue, they were true 8-bit devices and (most) did not apply any digital processing that would reduce the precision of the display. If you send an 8-bit gradient to a CRT there is very little if any visible banding.

With digital displays, particularly near black, +/- 1 RGB can result in changes of greater than 1-2 dE with an 8-bit input. Because of additional Greyscale, Gamma, CMS etc. processing, and limitations of the technology, most "digital" displays are not capable of displaying an 8-bit gradient that is perfectly smooth, especially compared with a CRT.

With a 10-bit input, and a capable display, you have four times the precision for adjustments and can get much better results when tuning the lower-end of the greyscale/gamma.

With madVR, outputting 8-bit or 10-bit may not make much of a difference to anything but the amount of dithering used, but when you're sending it to an actual display that is doing its own Greyscale/Gamma/CMS adjustments on top of what the 3DLUT has done, there can be a big difference between an 8-bit input and a 10-bit one.


The LUT-processed image itself might be perfect and free of discolouration, but when you send that dithered 8-bit image to a digital display, which is rather imprecise, the end results can be poor.

Dithering works because the shades used in dithering are supposed to be so close that they effectively blend together. With modern displays, however, each digital step (when near black) can be very noticeably different from the last, and so the differences between shades are too great for dithering to be effective.

Quote:
Originally Posted by madshi View Post
Can you please clarify which exact bitdepth you're talking about? E.g. there is the bitdepth you feed into the 3dlut, then there is the 3dlut input bitdepth, then there is the 3dlut output bitdepth, and then there is the HDMI transport bitdepth. You can't just talk about 8bit without specifying which exact bitdepth you mean. In the madVR processing chain there are 3 different bitdepths which could be described as "output" bitdepth.
I mean that what the video card is sending to the display is 8-bit, which is a lossy process.

If madVR's 8-bit output was going direct to a display which could show it without modification, I'm sure the results would be fine, but modern displays all do their own image processing to signals after the fact that cannot be disabled, and so sending them 10-bit data rather than 8-bit can definitely make a difference.



I think this is probably a case of application vs theory. In theory, an 8-bit output from madVR may be enough, but from hand-tuning LUTs—by which I mean looking at individual greyscale patches and adjusting the RGB values for each one digit at a time with either 8-bit (0–255) or 10-bit (0–1024) precision and measuring the results, there are definite benefits from sending 10-bit data to a display that can make use of it.

And with 8-bit LUTs, sometimes plus or minus a single digit at a specific point can be the difference between a visible error in the greyscale and it blending in smoothly. This is why I would prefer to be able to manually set 3DLUT output RGB values for points, rather than give it measurements from my display and calculate what it thinks is best. (which may be best on a perfect display)


I'm not saying you're doing anything wrong, but sometimes manual controls are necessary, and I really do think that there will be good improvements once you have a 10-bit output working in exclusive mode.

Last edited by 6233638; 20th October 2011 at 02:46.
6233638 is offline   Reply With Quote
Old 20th October 2011, 09:29   #10228  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by G_M_C View Post
Cant say for sure, cause looking better is kind of an subjective argument/feeling. But i have the feeling it did. Simply because i could turn of dithering in JanWillems build (or set it the lowest random setting), and outputting the 10-bit video to my receiver, wich in turn does 'its thing' using a Reon-VX video processor. Image seemed to be clearer, having more 'color-fidelity'. But as i said: This is subjective to be sure, i have to do some comparison between the two.
If you do compare again, please compare madVR to both the 8bit and 10bit output of JanWillems build. Would be curious to here your impressions.

Quote:
Originally Posted by noee View Post
"Best" is tough to define and in this case, subjective. If you care about h/w deinterlacing and madVR is your renderer of choice, then it seems nV might get the nod. If you can live with software deinterlacing, IMO, ATI 6xxx series is the way to go. Value of the 65xx series is hard to beat.
If deinterlacing is the only reason to go NVidia, then I would suggest to wait a bit. Deinterlacing is quite on the top of my to do list. Maybe I'll find a good solution for ATI. Or maybe not. At least I'm going to try...

Quote:
Originally Posted by ajp_anton View Post
Feature request:
Add information about the matrix used and levels into ctrl+J, so I don't have to go around checking ctrl+shift+alt+M/I.
Also, when scrolling through ctrl+shift+alt+M/I, the "default" setting always says "(auto detect)". Is it possible to differentiate between for example BT.709 that is guessed based on the resolution, and streams that actually have the BT.709 flag?
I guess I could add this information to ctrl+J.

Quote:
Originally Posted by ajp_anton View Post
And if I "accidentally" activate gamma processing by pressing ctrl+shift+alt+F/G, there doesn't seem to be a way to disable it without unchecking the box in the settings.
True. Couldn't think of an intuitive way to disable gamma processing again via the existing shortcuts.

Quote:
Originally Posted by toniash View Post
I own a Sony Tv that can work at 50 or 60 hz.
Until now I'm using Reclock to do 24fps -> 25fps and change the Tv set accordingly 24/25 fps -> 50Hz 29.97/30 fps -> 60 Hz
Is it possible to let Reclock change 24 fps to 25 fps and Madvr change the frequency?
You could try writing "1080p50, 1080p59" into the madVR display mode edit box. Or maybe "1080p50, 1080p60". That should probably do the trick. Ehm, of course only if your display is 1080p. If it has a different resolution, you have to adjust the mode list accordingly, of course.

Quote:
Originally Posted by XRyche View Post
madshi, do you have any plans on adding colour controls(contrast, brightness, saturation, hue) to madVR?
Yes, but it's not high priority.

Quote:
Originally Posted by TheShadowRunner View Post
madshi, I'm closing-in on figuring out the slow ZP / control bar seek freeze bug.
You were right, it seems to be a ZP bug..
After much testing, I found out that when I disable ZP's Interface > OSD > Action > "Show OSD filename when opening a new file", the issue _never_ happens (control bar always fast, never freezes)
However with this feature disabled, more often than not I get a beautiful crash in madVR.ax as soon as playback starts.
I enclose a debug log. Could you check if anything strange is going on on madVR side that explains the crash?
Unfortunately logs don't really help with madVR crashes. Is there a simple way I can reproduce the crash?

Quote:
Originally Posted by 6233638 View Post
Right, there are no problems with an "empty" LUT, it's once you start making changes—particularly at the lower end of the greyscale—that problems arise.

I know how dithering works. But once you are in the lower-end of the greyscale (say 20% and under, particularly at higher gammas) single RGB value changes can make considerable differences on the display.

With CRTs, this was significantly less of an issue, as +/- 1 RGB resulted in very small changes on the display, as being analogue, they were true 8-bit devices and (most) did not apply any digital processing that would reduce the precision of the display. If you send an 8-bit gradient to a CRT there is very little if any visible banding.

With digital displays, particularly near black, +/- 1 RGB can result in changes of greater than 1-2 dE with an 8-bit input. Because of additional Greyscale, Gamma, CMS etc. processing, and limitations of the technology, most "digital" displays are not capable of displaying an 8-bit gradient that is perfectly smooth, especially compared with a CRT.

With a 10-bit input, and a capable display, you have four times the precision for adjustments and can get much better results when tuning the lower-end of the greyscale/gamma.

With madVR, outputting 8-bit or 10-bit may not make much of a difference to anything but the amount of dithering used, but when you're sending it to an actual display that is doing its own Greyscale/Gamma/CMS adjustments on top of what the 3DLUT has done, there can be a big difference between an 8-bit input and a 10-bit one.

The LUT-processed image itself might be perfect and free of discolouration, but when you send that dithered 8-bit image to a digital display, which is rather imprecise, the end results can be poor.

I mean that what the video card is sending to the display is 8-bit, which is a lossy process.

If madVR's 8-bit output was going direct to a display which could show it without modification, I'm sure the results would be fine, but modern displays all do their own image processing to signals after the fact that cannot be disabled, and so sending them 10-bit data rather than 8-bit can definitely make a difference.
I'm a bit confused now, though. Which is the exact reason for the banding and discoloration in your opinion? Originally you said "There is a very noticeable drop in quality when using 3DLUTs". So you were saying that the 3dluts are at fault. Now you're saying that the dithered down madVR 8bit output is at fault. These are 2 very different things which have *nothing* to do with each other. madVR always dithers down to 8bit output, regardless of whether you use a 3dlut or not. So if the dithered down 8bit output is the problem, what does the 3dlut have to do with anything? And the other way round: If you say that the problem does not occur with an empty 3dlut, then obviously the dithered down 8bit output cannot be the problem, because even with an empty (or even with disabled 3dlut) madVR still outputs dithered down 8bit. You gotta make up your mind where the discoloring and banding problems are coming from. Is it the 3dlut? Or is it the dithered 8bit output? Two totally different and separate things, which have nothing to do with each other.

Quote:
Originally Posted by 6233638 View Post
Dithering works because the shades used in dithering are supposed to be so close that they effectively blend together. With modern displays, however, each digital step (when near black) can be very noticeably different from the last, and so the differences between shades are too great for dithering to be effective.
Dithering is even used for 1bit images, where the only two available shades are black and white. And still dithering works. (Of course the noise levels are extremely high with 1bit images.)

Quote:
Originally Posted by 6233638 View Post
I think this is probably a case of application vs theory. In theory, an 8-bit output from madVR may be enough, but from hand-tuning LUTs—by which I mean looking at individual greyscale patches and adjusting the RGB values for each one digit at a time with either 8-bit (0–255) or 10-bit (0–1024) precision and measuring the results, there are definite benefits from sending 10-bit data to a display that can make use of it.
So the LUTs themselves were 8bit or 10bit? That's a *totally* different situation. No dithering is used in that case. Of course the difference between 8bit and 10bit is dramatic in that case. I would say that even a 10bit LUT is not precise enough. madVR uses 16bit LUTs and dithers the output down to 8bit.

Two situations:
(1) 16bit LUT, dithered down to 8bit, sent to display in 8bit.
(2) 10bit LUT, sent to display in 10bit.

I dare say that (1) will have a higher quality and precision.

Quote:
Originally Posted by 6233638 View Post
And with 8-bit LUTs
Who's using 8bit LUTs? madVR is using 16bit LUTs!
madshi is offline   Reply With Quote
Old 20th October 2011, 10:42   #10229  |  Link
jmone
Registered User
 
Join Date: Dec 2007
Posts: 613
Hi Madshi, any comments on these two observations? http://forum.doom9.org/showthread.ph...92#post1531792
1st Issue: madVR Windowed mode = Lip Sync issues on 23.776/24hz
2nd Issue: "Exclusive Mode Failed"

Thanks
Nathan
jmone is offline   Reply With Quote
Old 20th October 2011, 10:49   #10230  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by jmone View Post
1st Issue: madVR Windowed mode = Lip Sync issues on 23.776/24hz (the video is delayed so the sound come first)

There is no issue with:
- EVR
- madVR Exclusive mode
- madVR Windowed mode at 50hz or 60hz

I've tried different combinations and the following make no difference to the lipsync issues:
- Decoding Vs Bitstreaming
- Video Clock on or off
- Normalize vol on or off
- HW Accell on or off (eg CUVID vs FFDSHOW)
- madVR Settings of "delay playback start until render queue is full" on or off
- madVR Settings of "use a separate device for presentation"
- Pause/Play or a Seek makes no difference - it is consistently out
- Disabling auto refresh rate changes
- Manually pre changing refresh rates

My only conclusion at this stage is that it is madVR Windowed mode that delays the video when the refresh rate is at 23.976/24hz ...unless there is other suggestions on what to try.
Can you cross check this with a different media player? What happens if you turn Aero on/off? Currently I don't see how madVR could be reponsible for this. madVR does not have any special code in it for 23.976/24.000Hz handling. It doesn't really matter to madVR whether the refresh rate is 24Hz or 240Hz. So I don't see how there could be a lipsync problem with 24Hz when there is none with higher refresh rates.

About the exclusive mode problem: I'd need a way to reproduce this, without having to wait hours or even days for the problem to appear.
madshi is offline   Reply With Quote
Old 20th October 2011, 11:40   #10231  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by STaRGaZeR View Post
Play this clip for example, got more if you want them. ffdshow configured as: YUV spec auto, input levels auto (or standard, it's the same), output levels PC. LAV Video is wrong with any sample. When playing fraps recorded files "AVI Decompressor (FPS1)" outputs RGB32 and connects with madVR, but the screen is black.
This will be fixed in the next build. Furthermore, RGB input with unknown range will now be treated as full range by default.
madshi is offline   Reply With Quote
Old 20th October 2011, 13:24   #10232  |  Link
6233638
Registered User
 
Join Date: Apr 2009
Posts: 1,019
Quote:
Originally Posted by madshi View Post
I'm a bit confused now, though. Which is the exact reason for the banding and discoloration in your opinion?
Perhaps I'm making things too complicated.

I'm a calibration guy. I care about the end results, and try to do my best to understand how things work in the video chain to get the best results possible.

The most recent LUT box I used was a VideoEQ Pro, which had 16-bit internal processing and the option of either an 8-bit or 10-bit output.

To calibrate with the device, you set RGB output values for each point. (e.g. 10, 20, 30...% grey)
So you either have 10-bit or 8-bit control over what is being sent to the display at any one point, so you could set 50% grey to 126,125,128 or 502,501,510 for example.

At the lower end of the greyscale, if you were working in 8-bit, I saw the same kind of discolouration that I am seeing in madVR. With 10-bit controls, you could tweak the values slightly and end up with a much better result on the display. What I would see with many displays is that moving the control either up or down a notch would sometimes result in no visual change on the display - at some points it would take two or three notches before the display actually changed at all (this is not uncommon) however taking the time to find the best values definitely improved things.


I don't know that the problem is necessarily with the 3DLUTs in madVR itself, but that sending 8-bit data to the display isnt a good enough input for its own internal LUTs/Processing to work with, as illustrated above. Sometimes it's more about manipulating the data being sent to the display to get the result you want rather than sending the "correct" data and hoping the display behaves itself. (unless it's a CRT, it won't)

I would consider most displays' internal processing to be "lossy" so you really want to give them as much data to work with as possible.

It may not have much of an effect on madVR's side of things whether it outputs 8-bit or 10-bit, but there can be consequences further along the display chain as a result.

When you're limited to 8-bit out, +/- 1 RGB can make a big difference, which is why I'm so frustrated at the lack of control with 3DLUTs, because I know I can get better results than I am now, even with 8-bit out of the PC.

I know that the output is dithered and so +/- 1 shouldn't matter, but from working with various external calibration/LUT boxes over the years, I'm not convinced this is getting the best results from the display.



I'm still not entirely convinced that you can manipulate an 8-bit source in 16-bit, dither it back down to 8-bit for output and have a lossless result either, but that's another matter. Comparing like-for-like, with the 3DLUT calibration disabled, madVR certainly has the best 8-bit output I've seen from any Blu-ray source, so you're obviously doing the best job possible there. (not that I had any doubts)
6233638 is offline   Reply With Quote
Old 20th October 2011, 13:48   #10233  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by 6233638 View Post
The most recent LUT box I used was a VideoEQ Pro, which had 16-bit internal processing and the option of either an 8-bit or 10-bit output.
To my best knowledge the VideoEQ Pro is not able to dither. So you're working with *rounded* 8bit or 10bit values. If you work with rounded (or truncated) data, of course every bit more makes a dramatic difference. 10bit really is *much* better than 8bit, when no dithering is used.

Quote:
Originally Posted by 6233638 View Post
With 10-bit controls, you could tweak the values slightly and end up with a much better result on the display. What I would see with many displays is that moving the control either up or down a notch would sometimes result in no visual change on the display - at some points it would take two or three notches before the display actually changed at all (this is not uncommon) however taking the time to find the best values definitely improved things.
The problem is that you don't have an 256x256x256 3dlut with the VideoEQ box, AFAIK. How many control points do you have? Probably *much* less than 256x256x256. So if you change one value, you don't affect a specific brightness step. You change much more, due to the necessary input interpolation. Add to that that no dithering is used (AFAIK). You cannot compare that to madVR. That's a whole different situation.

Quote:
Originally Posted by 6233638 View Post
When you're limited to 8-bit out, +/- 1 RGB can make a big difference, which is why I'm so frustrated at the lack of control with 3DLUTs, because I know I can get better results than I am now, even with 8-bit out of the PC.
Hand tuning a 3dlut can only work if you have a limited number of data points. How many data points do you have with the VideoEQ box? With madVR, if you wanted to hand tune the 3dlut, you'd have to play with 256x256x256 data points! You'd need decades to wade through such many data points. The number of data points is simply too big for you to edit them one by one. You could play with the measurement data you feed into yCMS, though.

Quote:
Originally Posted by 6233638 View Post
I know that the output is dithered and so +/- 1 shouldn't matter, but from working with various external calibration/LUT boxes over the years, I'm not convinced this is getting the best results from the display.
Did any of those boxes meet madVR's specs, which are:

- 256x256x256 data points
- 16bit output
- dither

Your experience with those LUT boxes doesn't say much, if they didn't use dithering, or/and if they had much less input data points than madVR has. Especially if they don't use dithering *and* have less input data points, you can't really compare that to madVR's solution at all.

Quote:
Originally Posted by 6233638 View Post
I'm still not entirely convinced that you can manipulate an 8-bit source in 16-bit, dither it back down to 8-bit for output and have a lossless result either
It's not lossless, the dithering raises the noise floor. But there should be no added banding and no discoloration.

You said it yourself: With an "empty" 3dlut, you see no banding and no discoloration. But still, with an empty 3dlut, madVR runs the full processing with the final dithering down to 8bit output. If either the 3dlut or the downdithering to 8bit is a problem in itself, why do you not see any problems with an empty 3dlut? That makes no sense. So the problem is neither the 3dlut processing in itself, nor the dithering down to 8bit. The problem you're seeing with madVR is probably caused by either bad measurements and by yCMS doing something wrong. At least that's my current understanding.
madshi is offline   Reply With Quote
Old 20th October 2011, 14:19   #10234  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
madVR v0.75 released

http://madshi.net/madVR.zip

Code:
* fixed: v0.74 stopped decoder DirectShow filter from being released properly
* fixed: PotPlayer sometimes crashed when switching video files
* fixed: internal decoders made problems with cropped MKVs & Haali Splitter
* fixed: OSD sometimes didn't appear in ZoomPlayer in exclusive mode
* fixed: VP70 decoder showed video upside down
* fixed: RGB24 input sometimes crashed madVR
* fixed: ffdshow RGB input level detection sometimes failed
* subtitles run through the 3dlut now, too
* internal decoders are now auto disabled if required decoder dlls are missing
* added option to scale Luma in linear light, disabled by default
* RGB input with unknown range is now treated by default as full range
* added detailed information about matrix, primaries and levels to debug OSD
* updated libav/ffmpeg dlls
I'm not sure whether I should recommend to activate the linear light scaling option or not. Please check it out and let me know what you think. It should be somewhat slower. From what I could see, if looks a bit better when downscaling by a large factor, but for upscaling I couldn't see much of a difference. Furthermore, with linear light scaling activated, I could see more halos, when using Lanczos. So make up your own mind. I'd be interested in your opinion about how it looks. And also how big of a performance drop you're seeing.

@STaRGaZeR, please check whether you can find a situation where the auto detection still fails. I hope you won't find any such situations, anymore. If you do, please let me know. And maybe you can then upload a sample, that would be helpful. Thanks.
madshi is offline   Reply With Quote
Old 20th October 2011, 14:27   #10235  |  Link
G_M_C
Registered User
 
Join Date: Feb 2006
Posts: 1,076
Quote:
Originally Posted by madshi View Post
If you do compare again, please compare madVR to both the 8bit and 10bit output of JanWillems build. Would be curious to here your impressions.
[...]
I'll try to set it up so that i can switch between the two renderers and its possibillities. I'll let my GF comment/choose which looks best, ehhh ... sorry let my GF TRY to choose between them.
G_M_C is offline   Reply With Quote
Old 20th October 2011, 15:02   #10236  |  Link
Guybrushtx
Registered User
 
Join Date: Apr 2007
Posts: 1
madvr 0.75 and MPC HC

I have a problem with madvr 0.75:
Every time I close MPC HC (1.5.2.3456), program crashes.
With 0.74 everything goes well.
Could you please verify?
Guybrushtx is offline   Reply With Quote
Old 20th October 2011, 15:07   #10237  |  Link
kerimcem
Registered User
 
Join Date: Aug 2011
Posts: 81
Quote:
Originally Posted by Guybrushtx View Post
I have a problem with madvr 0.75:
Every time I close MPC HC (1.5.2.3456), program crashes.
With 0.74 everything goes well.
Could you please verify?
and exul. seek bar not see
kerimcem is offline   Reply With Quote
Old 20th October 2011, 15:08   #10238  |  Link
fastplayer
Registered User
 
Join Date: Nov 2006
Posts: 799
Thanks for 0.75, madshi!
Unfortunately, MPC-HC (rev 3785) crashes when closing it. No such issue with 0.74.
fastplayer is offline   Reply With Quote
Old 20th October 2011, 15:08   #10239  |  Link
RyaNJ
RyanJ
 
Join Date: Mar 2008
Posts: 60
Quote:
Originally Posted by Guybrushtx View Post
I have a problem with madvr 0.75:
Every time I close MPC HC (1.5.2.3456), program crashes.
With 0.74 everything goes well.
Could you please verify?
I can confirm this.
RyaNJ is offline   Reply With Quote
Old 20th October 2011, 15:13   #10240  |  Link
Nevilne
Registered User
 
Join Date: Aug 2010
Posts: 134
Downscaling in linear light seems to look just slightly better, but upscaling has bit too much aliasing, and what looks to be chroma bleeding as well? Just tried both with spline3.

Potplayer bug: all madvr and potplayer osd and subtitles have blackness instead of transparency.
Nevilne is offline   Reply With Quote
Reply

Tags
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 19:20.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.