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, 00:07   #10201  |  Link
TheShadowRunner
Registered User
 
TheShadowRunner's Avatar
 
Join Date: Feb 2004
Posts: 399
Quote:
Originally Posted by madshi View Post
This is a bug in the VP7 decoder. But I've found a workaround which I'll implement in the next madVR build.
Thank you!

Quote:
Originally Posted by madshi View Post
It sounds more like a ZP bug to me, but of course I can't be sure. Why are you disabling the option "Display OSD through madVR's OSD API"? Does it have any disadvantages?
Yes, the control bar displayed via madVR's OSD API is much less reactive/ laggy. Scrolling it is also kind of a pain.
Since I have no issues with madVR going windowed <> FSE, I disabled "Display OSD through madVR's OSD API" completely.

Quote:
Why do you switch the display refresh rate *while* the movie is playing? That's not a good idea, generally, IMHO. madVR generally doesn't like it much if you modify the refresh rate behind its back.
Yes, I know that, but the bug occurs also when madVR's internal frequency switcher is used, before the movie begins.
As I was reporting, it doesn't make any difference when it comes to this bug if madVR does it internally, or if ReClock or I do it manually.

From the log I enclosed, do you see any issue on the madVR side?
__________________
XP SP3 / Geforce 8500 / Zoom Player
TheShadowRunner is offline   Reply With Quote
Old 19th October 2011, 00:36   #10202  |  Link
6233638
Registered User
 
Join Date: Apr 2009
Posts: 1,019
Quote:
Originally Posted by madshi View Post
Uniformity issues are usually per panel (red, green, blue) and totally separate from the other panels. So using three 1dluts would be a much more efficient way for such a feature. That is, if I understand correctly what you're talking about. You do mean brightness variations of a panel, right?
Higher end monitors such as Eizo (PC) or Sony/Barco (Broadcast) use LUTs for uniformity correction, my guess is that's what he's looking for.

Seems like it could be a pretty good feature—my LCD has 70 zones and while uniformity is pretty good for an LCD as a result, there doesn't seem to be any uniformity correction available via the service menu, so doing it through the HTPC would be interesting to see just how much better things could get.

Quote:
Originally Posted by madshi View Post
BTB and WTW are not supposed to be visible on a properly calibrated display.
I agree, BTB should not be visible on a calibrated display—the only reason to make BTB visible, is to make it easier to set up black level on a CRT. It really isn't necessary on flat panel displays where there is a very obvious jump in brightness across the whole screen if you just display a full black image and adjust the brightness control.

WTW visibility is debatable. Reference-class displays are still required to show 16–255, though in reality most content does not have anything above 235 and it can improve the contrast on many current displays. The option to preserve WTW would be nice though.


Quote:
Originally Posted by madshi View Post
- probably necessary for 3D presentation (in a future version)
- necessary for 10bit output (in a future version)
This is very exciting! I don't care if it's months away, you always deliver and I'm happy to wait.

Quote:
Originally Posted by madshi View Post
I'm not accepting donations yet. Please wait for madVR v1.0. Once I get there, I'll accept donations, or maybe make a "pro" version with added features for a small price.
As soon as you start accepting donations, or offering a "pro" version, you have my money.

Quote:
Originally Posted by madshi View Post
Not sure what you mean. There should be no noticeable drop in quality when using 3DLUTs.
While madVR does a great job working in 16-bit and dithering down to 8-bit for output, 8-bit just isn't enough precision to avoid discolouration and/or banding in the image.

Here are a couple of crops from Tron Legacy, at 200%

My current 3DLUT with data from 20–100% in 10% steps:

Shows some discolouration/banding but tolerable for the improvements using a 3DLUT brings.

3DLUT with data from 10–100%:


As you can hopefully see, there is a noticeable increase in banding and reddish discolouration in the darker areas. (might be easiest to open them in separate tabs in your browser and switch between the two)

This is with modified data too—I only used the Y value from my display at 10%, xy are set to D65, as that seemed to reduce the errors.

I'm hoping that 10-bit out to the display will help in reducing those errors.

Of course, this all depends on what kind of display you're using. With CRT, any kind of reduction in bit-depth is immediately obvious. On LCDs and LCoS/SXRD it's fairly noticeable, on Plasmas it probably isn't noticeable at all, as they add colour errors like this on their own. It's the main reason I couldn't stand to keep any of the Kuros.


This is partly why I would like the ability to tweak the output RGB values being sent to the display from a LUT, rather than giving it input values. I have had success in reducing this kind of error by manually tweaking the LUT with external devices. (but ultimately, none of them have been worth the additional expense over madVR & yCMS)
6233638 is offline   Reply With Quote
Old 19th October 2011, 04:00   #10203  |  Link
mr.duck
quack quack
 
Join Date: Apr 2009
Posts: 259
madVR is screwing with keyboard shortcuts in other programs. Specifically Ctrl+Shift+R

Is this a shortcut used by madVR? Can I have an option to disable all shortcuts plox?


Feature request: Settings >> rendering >> windowed mode settings >> new option: show seek bar


Thx. madVR rocks
__________________
Media Player Classic Home Cinema Icon Library: NORMAL VERSION / GLOWING VERSION
mr.duck is offline   Reply With Quote
Old 19th October 2011, 04:46   #10204  |  Link
pdanpdan
Registered User
 
Join Date: Apr 2005
Location: Bucharest, Romania
Posts: 145
Yes, and try to use a linux console and search something with CTRL+R
pdanpdan is offline   Reply With Quote
Old 19th October 2011, 07:09   #10205  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by 6233638 View Post
Higher end monitors such as Eizo (PC) or Sony/Barco (Broadcast) use LUTs for uniformity correction, my guess is that's what he's looking for.
I highly doubt they use 3dluts, though, which was the point I was trying to make. They most probably use 3 separate 1dluts.

Quote:
Originally Posted by 6233638 View Post
While madVR does a great job working in 16-bit and dithering down to 8-bit for output, 8-bit just isn't enough precision to avoid discolouration and/or banding in the image.
I strongly disagree. Dithering down to 8bit output does not cause any problems with discoloration or banding at all. The problems you're seeing are caused by either bad measurements or by yCMS processing problems, can't say for sure. Going to 10bit output will not change discoloration or banding at all, you will see exactly the same thing there. The only thing 10bit output will help with is reducing the strength of the dithering noise.

Quote:
Originally Posted by mr.duck View Post
madVR is screwing with keyboard shortcuts in other programs. Specifically Ctrl+Shift+R
In a future version you'll be able to choose custom keyboard shortcuts to avoid such conflicts.

Quote:
Originally Posted by mr.duck View Post
Feature request: Settings >> rendering >> windowed mode settings >> new option: show seek bar
Has been posted before. On my to do list, under "low priority".

Last edited by madshi; 19th October 2011 at 07:14.
madshi is offline   Reply With Quote
Old 19th October 2011, 07:21   #10206  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by cca View Post
I recently decided to give madVR another go, last time I had issues in fullscreen. After many tries it's apparent that in my own system MadVR is incapable to produce a smooth video image. Even when the renderer itself reports zero glitches the motion is glitchy, I can see microstutters in every panning scene. I've tried all the flush options, the DX11 option, the anti-glitch options, nothing gets rid of the glitches. It is sad, because the image quality is top, but I cannot tolerate glitches when I watch videos.
Which movie frame rate and display refresh rate are we talking about? What does the madVR OSD say about the various queues (are they all full or nearly full?) and about dropped and delayed frames? Does the problem occur in both windowed and exclusive mode? If it occurs in windowed mode, too, does turning Aero on/off make any difference? What happens if you disable Reclock, does the problem go away then?

Make sure VSync correction is disabled in Reclock. You reported that you used a profile to fix the clocks. Have you verified whether the profile actually works as intended?
madshi is offline   Reply With Quote
Old 19th October 2011, 07:33   #10207  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by TheShadowRunner View Post
Yes, I know that, but the bug occurs also when madVR's internal frequency switcher is used, before the movie begins.
As I was reporting, it doesn't make any difference when it comes to this bug if madVR does it internally, or if ReClock or I do it manually.

From the log I enclosed, do you see any issue on the madVR side?
Hmmmm... According to the log, a seek was performed after about 5 seconds of playback. During/after that seek playback was paused, but never resumed. So basically madVR doesn't seem to be frozen at all. It's just that playback is paused. You just pressing play/pause once or twice should unfreeze the player - unless the media player itself is really frozen. If that's the case the log doesn't indicate why that would have happened.
madshi is offline   Reply With Quote
Old 19th October 2011, 08:03   #10208  |  Link
TheShadowRunner
Registered User
 
TheShadowRunner's Avatar
 
Join Date: Feb 2004
Posts: 399
Quote:
Originally Posted by madshi View Post
Hmmmm... According to the log, a seek was performed after about 5 seconds of playback. During/after that seek playback was paused, but never resumed. So basically madVR doesn't seem to be frozen at all. It's just that playback is paused. You just pressing play/pause once or twice should unfreeze the player - unless the media player itself is really frozen. If that's the case the log doesn't indicate why that would have happened.
Damn, I feared so. For that log, I never paused once (and madVR's own internal frequency switcher was used btw).
Zoom Player is really frozen, and hangs there. In this state, its own guarddog kills it (after 20 seconds, it's a feature), or if the guarddog is disabled the only option is to kill the zplayer.exe process manually (what I did for that log, in order to keep it small).
I'll try to come up with a method to always recreate the issue...

A maybe related question: when frequency switching is involved, exemple 720p@60 to 1080p24, sometimes the switch is instantanous (exactly when the media starts) and sometimes [for the same media!] it takes up to 6-7 seconds before the switch occurs, during which a couple seconds of the media are looped (5-6 times).
What is this difference due to ? (I'm asking for madVR's internal frequency switcher specifically)
__________________
XP SP3 / Geforce 8500 / Zoom Player
TheShadowRunner is offline   Reply With Quote
Old 19th October 2011, 08:06   #10209  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by TheShadowRunner View Post
Damn, I feared so. For that log, I never paused once (and madVR's own internal frequency switcher was used btw).
Zoom Player is really frozen, and hangs there. In this state, its own guarddog kills it (after 20 seconds, it's a feature), or if the guarddog is disabled the only option is to kill the zplayer.exe process manually (what I did for that log, in order to keep it small).
I'll try to come up with a method to always recreate the issue...
In any case you may want to contact the ZP developer. From the log it doesn't look to me like madVR was at fault.

Quote:
Originally Posted by TheShadowRunner View Post
A maybe related question: when frequency switching is involved, exemple 720p@60 to 1080p24, sometimes the switch is instantanous (exactly when the media starts) and sometimes [for the same media!] it takes up to 6-7 seconds before the switch occurs, during which a couple seconds of the media are looped (5-6 times).
What is this difference due to ? (I'm asking for madVR's internal frequency switcher specifically)
I don't know. I just tell the OS to change the display mode.
madshi is offline   Reply With Quote
Old 19th October 2011, 08:14   #10210  |  Link
Dogway
Registered User
 
Join Date: Nov 2009
Posts: 2,352
Is it the dither error diffusion or ordered dither? I say because I encode my rips in ordered dither (to save bitrate), I have tested ordered dithering over ordered dither and results are horrible so by the moment I have dithering disabled just in case.

I would also like to suggest a profile load option. Or some way where you can switch fast exclusive mode with windowed mode with its preconfigured settings. That is because I normally use mpc-hc to play small files, preview my encodes, watch clips downloaded from youtube, etc, and windowed mode is more convenient as I can pause, do a few things aside, resize window, I mean, more manageable. Other times I would just plug my laptop to the TV use exlusive mode, and Im good to go.

I also envy how you managed to port the resizers to be processed by the GPU, it would be great to see spline36 running on GPU for avisynth as well.
Welcome back!
__________________
i7-4790K@Stock::GTX 1070] AviSynth+ filters and mods on GitHub + Discussion thread
Dogway is offline   Reply With Quote
Old 19th October 2011, 08:27   #10211  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Dogway View Post
Is it the dither error diffusion or ordered dither?
Neither nor. I'm currently using TPDF (random) dithering. I would love to implement some kind of error diffusion, but the basic principle of error diffusion is to spread the error to neighboring pixels. And that contradicts the basic principle of how GPUs work. Maybe I'll find a way to make error diffusion work by using CUDA/OpenCL some time in the future, but it would probably be quite slow, due to the algorithm contradiction I mentioned.

Quote:
Originally Posted by Dogway View Post
I have tested ordered dithering over ordered dither
I don't think madVR's dither should collide with ordered dither. Of course it's always better to not dither at all, but to use a higher bitdepth instead. But if you can't use a higher bitdepth, then it's usually better to use dither than to not use it. Maybe applying ordered dither twice is bad, that's quite possible. I have no personal experience with ordered dither. Anyway, that doesn't apply to TPDF dithering (used by madVR). TPDF dithering can be applied multiple times without any negative side effects, other than that applying it multiple times of course raises the noise floor. In audio processing TPDF dithering is used all the time.

Quote:
Originally Posted by Dogway View Post
I would also like to suggest a profile load option.
Maybe in some future version. Not anytime soon, though. Too many crucial things missing to spend my time on things like that right now.

Last edited by madshi; 19th October 2011 at 08:31.
madshi is offline   Reply With Quote
Old 19th October 2011, 08:43   #10212  |  Link
G_M_C
Registered User
 
Join Date: Feb 2006
Posts: 1,076
Madshi, welcome back after a well-earned break.

First: I've been using madVR for a short period now, coming from JanWillems test-builds. Must say i'm satisfied with madVR's stable output and quality.

JanWillems builds however had a possibility to convert 8-bpc video to 10-bpc, and output that. It uses EVR-CP, i know, but somehow it was possible to force 10-bit output. I have the luck that i have equipment that accepts this 10-bit video. So 'bit-wise' that seems to be the better option.

But JanWillems builds aren't always stable (thats logical, they aren't labeled experimental for nothing), and also AVR-CP isn't always stable. Thats why i choose to work with madVR.

Some posts in this thread before there was some talk about 10-bpc maybe coming to madVR. Can you comment about this, do you think it is possible, and/or are you working on this subject ?

Also some posts before there was some talk about MPC-HT with madVR not exiting full-screen correctly. I want to report that i have also noticed this. I run full-screen on my secondary display. When exiting full screen, and coming back to my primary display the MPC-HT's window doesn't have the window-controls in the top bar anymore (dont know what they are called, but i mean the 3 small buttons in the right top for minimizing/maximizing/closing the window). These controls are 'simply not there anymore'

Last edited by G_M_C; 19th October 2011 at 09:20.
G_M_C is offline   Reply With Quote
Old 19th October 2011, 08:44   #10213  |  Link
TheShadowRunner
Registered User
 
TheShadowRunner's Avatar
 
Join Date: Feb 2004
Posts: 399
Quote:
Originally Posted by madshi View Post
In any case you may want to contact the ZP developer. From the log it doesn't look to me like madVR was at fault.
I sure did, and Blight and I came to the conclusion it's a madVR issue since it doesn't happen with EVR/VMR9.
I can reproduce the bug at will here.. only with madVR.

Maybe these logs can help.
I do _exactly_ the same for both tries, and close ZP in between of course.

I launch ZP, play a SD PAL video and then close the player. (madVR's internal frequency switcher is used: 720p60 to 720p50)

http://videoff7.free.fr/madVR_ZP_OK.zip (fast ZP control bar, all OK)
http://videoff7.free.fr/madVR_ZP_buggy.zip (slow ZP control bar, freeze if seek)

Quote:
I don't know. I just tell the OS to change the display mode.
Ok, I found out that this delay that sometimes occur before frequency switching is due to ReClock, never happens when ReClock isn't in the graph. All OK on the madVR side regarding this.
__________________
XP SP3 / Geforce 8500 / Zoom Player

Last edited by TheShadowRunner; 19th October 2011 at 09:04.
TheShadowRunner is offline   Reply With Quote
Old 19th October 2011, 09:07   #10214  |  Link
TheProfosist
Registered User
 
TheProfosist's Avatar
 
Join Date: Aug 2009
Posts: 136
Quote:
Originally Posted by madshi View Post
Unfortunately crash reports like this are hard for me to fix at this point in time. If there was a way for me to reproduce the crash, that would help greatly. Unfortunately these crashes don't seem to occur on my PC.
I posted more information later on in the thread. And the problem on the laptop I believe is because of Nvidia Optimus.
TheProfosist is offline   Reply With Quote
Old 19th October 2011, 10:44   #10215  |  Link
6233638
Registered User
 
Join Date: Apr 2009
Posts: 1,019
Quote:
Originally Posted by madshi View Post
I highly doubt they use 3dluts, though, which was the point I was trying to make. They most probably use 3 separate 1dluts.
You're right, they do use 1D LUTs, I misunderstood the point you were trying to make.

Quote:
Originally Posted by madshi View Post
I strongly disagree. Dithering down to 8bit output does not cause any problems with discoloration or banding at all. The problems you're seeing are caused by either bad measurements or by yCMS processing problems, can't say for sure.
Editing the LUT so that xy values for all points are D65 (0.312713, 0.329016) still introduces that discolouration/banding in the image, so it's not a measurement/greyscale issue.

It is a combination of both what is being done with the LUT, and how those values end up being displayed on the screen. Using higher precision does have benefits in this area beyond reducing dithering. This is why high end displays use much higher precision LUTs for internal calibration. High-end Eizo monitors use 16-bit LUTs to drive the display panel for example:

(of course the panels themselves are not 16-bit native, but they aren't 8-bit either)

When you are only sending 8-bit to a display, changing the RGB values being sent to it by even a single digit can have considerable effects on greyscale at the lower end of the scale. With 10-bit, you have four times the precision and it really does make a difference in reducing visible errors. (another reason why I want to manually tweak the LUT output values)

I have spent a considerable amount of time hand-tuning LUTs with dedicated devices, and this is a definite limitation caused by a lack of precision when only outputting 8-bit.
6233638 is offline   Reply With Quote
Old 19th October 2011, 10:45   #10216  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by G_M_C View Post
JanWillems builds however had a possibility to convert 8-bpc video to 10-bpc, and output that.
And does it look "better" in that mode compared to madVR?

Quote:
Originally Posted by G_M_C View Post
Some posts in this thread before there was some talk about 10-bpc maybe coming to madVR. Can you comment about this, do you think it is possible, and/or are you working on this subject ?
I may look into this in a future version. But to be honest, I don't find it very important, because the only benefit 10bit output would bring is a lower dithering noise floor. Other than that, 10bit output will have no advantage.

Quote:
Originally Posted by G_M_C View Post
Also some posts before there was some talk about MPC-HT with madVR not exiting full-screen correctly. I want to report that i have also noticed this. I run full-screen on my secondary display. When exiting full screen, and coming back to my primary display the MPC-HT's window doesn't have the window-controls in the top bar anymore (dont know what they are called, but i mean the 3 small buttons in the right top for minimizing/maximizing/closing the window). These controls are 'simply not there anymore'
This was reported with some older madVR versions when using the madVR D3D11 presentation mode. Are you using that mode? And are you sure you're using the latest madVR version? Try without D3D11 presentation mode. Does the problem still occur?

Quote:
Originally Posted by TheShadowRunner View Post
I sure did, and Blight and I came to the conclusion it's a madVR issue since it doesn't happen with EVR/VMR9.
I can reproduce the bug at will here.. only with madVR.
Haha, two can play that game: The issue only occurs with ZP, but not with any other media player, so it must be ZP?

Fact is, the problem only occurs with the combination of ZP + madVR. Use a different renderer and/or media player and the problem is gone. So we have no proof. It could be either ZP or madVR or it could be how those two interact. The log you uploaded earlier does not indicate a madVR problem.

Quote:
Originally Posted by TheShadowRunner View Post
Maybe these logs can help.
I do _exactly_ the same for both tries, and close ZP in between of course.

I launch ZP, play a SD PAL video and then close the player. (madVR's internal frequency switcher is used: 720p60 to 720p50)

http://videoff7.free.fr/madVR_ZP_OK.zip (fast ZP control bar, all OK)
http://videoff7.free.fr/madVR_ZP_buggy.zip (slow ZP control bar, freeze if seek)
Not sure what to look for in those logs. Both run about 6.8 seconds and then stop. Both look ok to me. The "buggy" log runs 6815 milliseconds and after 6813 milliseconds madVR claims to have successfully displayed a video frame. So I don't see anything wrong in that log. Or did the freeze start after those 6.8 seconds?

Quote:
Originally Posted by TheShadowRunner View Post
Ok, I found out that this delay that sometimes occur before frequency switching is due to ReClock, never happens when ReClock isn't in the graph. All OK on the madVR side regarding this.
Again, having someone else change display modes behind madVR's back is not a good idea. You sure this isn't the cause of the problem?

Quote:
Originally Posted by TheProfosist View Post
I posted more information later on in the thread.
From your post it looks like most of the problems are D3D11 related? I'm aware of that the D3D11 presentation mode is not as stable as it should be atm. That's on my list of things to look at. The D3D11 presentation mode is only meant as a last resort if you run into glitch problems. So if you don't urgently need the D3D11 mode, I'd suggest to turn it off (for now).
madshi is offline   Reply With Quote
Old 19th October 2011, 10:57   #10217  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by 6233638 View Post
Editing the LUT so that xy values for all points are D65 (0.312713, 0.329016) still introduces that discolouration/banding in the image, so it's not a measurement/greyscale issue.
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.

Quote:
Originally Posted by 6233638 View Post
It is a combination of both what is being done with the LUT, and how those values end up being displayed on the screen. Using higher precision does have benefits in this area beyond reducing dithering. This is why high end displays use much higher precision LUTs for internal calibration. High-end Eizo monitors use 16-bit LUTs to drive the display panel for example
I'm not sure what you're talking about. The 3dluts used by madVR are 8bit input and 16bit output. Are you saying that Eizo monitors are using 16bit *input* 3dluts? That's technically impossible. Such a 3dlut would consume 1536 Terrabytes of memory. The 3dluts used by displays are to my best knowledge usually 17x17x17 with 16bit output bitdepth. The 3dluts used by madVR are 256x256x256 with 16bit output bitdepth. I'm pretty sure that there's not a single display out there which uses a 3dlut anywhere near the precision that madVR uses.

Quote:
Originally Posted by 6233638 View Post
When you are only sending 8-bit to a display, changing the RGB values being sent to it by even a single digit can have considerable effects on greyscale at the lower end of the scale. With 10-bit, you have four times the precision and it really does make a difference in reducing visible errors.
No, it does not. Please look up "dithering" and how it works.

Quote:
Originally Posted by 6233638 View Post
I have spent a considerable amount of time hand-tuning LUTs with dedicated devices, and this is a definite limitation caused by a lack of precision when only outputting 8-bit.
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.

Those hand-tuned LUTs with dedicated devices, do they do trilinear interpolation? Which input/output bitdepth does the LUT have? Which bitdepth does the display accept and is the LUT output dithered down to the native display bitdepth?
madshi is offline   Reply With Quote
Old 19th October 2011, 11:17   #10218  |  Link
G_M_C
Registered User
 
Join Date: Feb 2006
Posts: 1,076
Quote:
Originally Posted by madshi View Post
And does it look "better" in that mode compared to madVR?
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.

But then again: Another important argument for madVR is that using madVR with a trunk build of mpc-ht is more stable then Jan's experimental builds.

Quote:
Originally Posted by madshi View Post
I may look into this in a future version. But to be honest, I don't find it very important, because the only benefit 10bit output would bring is a lower dithering noise floor. Other than that, 10bit output will have no advantage.
Thanx for your reply on this. 10-bit would be interesting i guess. But if benefit is small, and my subjective feeling towards it is wrong, than the effort might not be worth it.

Quote:
Originally Posted by madshi View Post
This was reported with some older madVR versions when using the madVR D3D11 presentation mode. Are you using that mode? And are you sure you're using the latest madVR version? Try without D3D11 presentation mode. Does the problem still occur?
I'm using 0.74, which is latest afaik. And your right, not using D3D11 mode fixes the problem. I'll keep using the D3D9 path. I set it to D3D11, simply without thinking (like: I have D3D11, so might as well use it).

Last edited by G_M_C; 19th October 2011 at 11:22.
G_M_C is offline   Reply With Quote
Old 19th October 2011, 13:35   #10219  |  Link
TheShadowRunner
Registered User
 
TheShadowRunner's Avatar
 
Join Date: Feb 2004
Posts: 399
Quote:
Originally Posted by madshi View Post
Haha, two can play that game: The issue only occurs with ZP, but not with any other media player, so it must be ZP?
Fact is, the problem only occurs with the combination of ZP + madVR. Use a different renderer and/or media player and the problem is gone. So we have no proof. It could be either ZP or madVR or it could be how those two interact. The log you uploaded earlier does not indicate a madVR problem.
Thanks, good to know. It could very well be a ZP bug, I'm not saying otherwise, just trying to rule out one of the 2.

Quote:
Not sure what to look for in those logs. Both run about 6.8 seconds and then stop. Both look ok to me. The "buggy" log runs 6815 milliseconds and after 6813 milliseconds madVR claims to have successfully displayed a video frame. So I don't see anything wrong in that log. Or did the freeze start after those 6.8 seconds?
No I didn't seek the control bar to trigger the freeze this time, but on the "buggy" log, ZP was in that weird slow state that eventually freezes after seeking. I was hoping the logs would show something different after (madVR's internal) frequency switch.

Quote:
Again, having someone else change display modes behind madVR's back is not a good idea. You sure this isn't the cause of the problem?
Yes, I'm absolutely certain, I very much understood you don't like frequency switching behind madVR's back, so for all my testing I exclusively use madVR's internal switcher! ^^;
__________________
XP SP3 / Geforce 8500 / Zoom Player
TheShadowRunner is offline   Reply With Quote
Old 19th October 2011, 14:23   #10220  |  Link
pacemaker1000
Registered User
 
Join Date: Mar 2011
Posts: 90
sorry to repeat myself but i am looking to pull the trigger today on a new GPU
contenters are the nvidia gt 430 or AMD 5xxx
initila research looks like the 430 was blighted on launch by bad drivers but i cant find if this is sorted
as i use MadVr and i know you lot are critical about picture quality like me can anyone suggest which is best? and if amd which model within the 5xxx series ar is a basic 6xxx better

thanks in advance
pacemaker1000 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 03:20.


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