madVR - high quality video renderer (GPU assisted)

[el Filou]

When I play a 4k-file that has no black bars and change something in MadVR like target nits, etc. I see an immediate effect !!
But on files with black bars nothing changes !!
If this not known yet could someone please alert madshi over at AVSYes, I can't find the exact post quickly but it's been reported to madshi by one of the testers that black bars were confusing the dynamic HDR algorithm. It should be fixed in the next release (or you can download the latest test build from the AVS thread, search for 'madVRhdrMeasure' starting from the last page).

[tp4tissue]

No no I m ok now. That was a video proof that there was an issue and now problem is solved. It was a reg key that was left even I uninstalled madvr.

Could you post location of reg key

[madjock]

Could you post location of reg key

HKEY_CURRENT_USER\Software\madshi\madVR

[tp4tissue]

Yes, I can't find the exact post quickly but it's been reported to madshi by one of the testers that black bars were confusing the dynamic HDR algorithm. It should be fixed in the next release (or you can download the latest test build from the AVS thread, search for 'madVRhdrMeasure' starting from the last page).

Does the size of the black bar change the quantity of confusion ?

For example, if it was a just a little bit of black bar in a near 16:9 movie, vs a 2:1 movie with big bars.

[tp4tissue]

HKEY_CURRENT_USER\Software\madshi\madVR

Thxx :D

[Grimsdyke]

It should be fixed in the next release (or you can download the latest test build from the AVS thread, search for 'madVRhdrMeasure' starting from the last page).

Just tested the latest test build (54) and the problem is unfortunately still there !! So I would be very thankful if anyone could inform Madshi about that because watching John Carpenter's original HALLOWEEN is really not 'fun' right now.

[tp4tissue]

Just tested the latest test build (54) and the problem is unfortunately still there !! So I would be very thankful if anyone could inform Madshi about that because watching John Carpenter's original HALLOWEEN is really not 'fun' right now.

What's happening, is it too dark or too bright ?

I just tried my copy of halloween 1978, changing the nit does make the screen brighter and darker.

I am using dxva2 copyback lav, on madv 92.17

[Alexkral]

I uninstalled both mpc hc & be last night and madvr, too.
I also deleted madvr's folder, rebooted and then I run a registry cleaning. I also deleted mpc's folder left in program files.

I reinstalled mpc and downloaded another(older version 91.4) of madvr and extracted the folder in another drive(c: - had it on d: ).

When I started playing a movie and opened madvr settings I noticed that my settings where there(all of them, even the hd profiles in scaling) but madvr folder didn't have "settings.bin" when I extected it. As I understand it retrieves previous settings and maybe that is the problem. Is there in other location that madvr creates folders and profiles, so if I clean them will solve the problem.

I don't believe what is happening is normal. I said before that there is not such issue with my brothers rig with 4670k and 660ti.
Gpu does all the rendering and so cpu drops clocks.
I have a 4690k and r9 290 and I know(because I have seen it) that madvr did't behave with the same way in the past.

I'd say that means you have another madVR installation, maybe for another player like JRiver like me.

[Grimsdyke]

What's happening, is it too dark or too bright ?
I just tried my copy of halloween 1978, changing the nit does make the screen brighter and darker.
I am using dxva2 copyback lav, on madv 92.17

It's way too dark !! For example, the 'Rabbit in Red' matchbook at around 9:12 is almost completely in the dark.
Unfortunately I can't use 'copyback' because my gpu is not fast enough. So I hope that Madshi might fix this soon !! Thx

[clsid]

I'd say that means you have another madVR installation, maybe for another player like JRiver like me.No, it is completely normal that Madvr stores its settings in the Registry. The settings.bin file is just a secondary storage method for the settings. See it as a backup.

[tp4tissue]

It's way too dark !! For example, the 'Rabbit in Red' matchbook at around 9:12 is almost completely in the dark.
Unfortunately I can't use 'copyback' because my gpu is not fast enough. So I hope that Madshi might fix this soon !! Thx

measure nits only work with Cpu decode, or Copyback dxva2 or dx11.

It does not work with native dxva or native dx11, because it can not measure the frame nits.

There's no way around this. if you want to use dynamic hdr + highlight recovery, you'll have to upgrade your GPU.

Which gpu do u have.

[el Filou]

Measure nits work with native DXVA however black bar detection doesn't, so maybe the two features are interacting in a bad way.

[tp4tissue]

Measure nits work with native DXVA however black bar detection doesn't, so maybe the two features are interacting in a bad way.

Why does native dxva cause banding on RX580 though.. :(

[DMU]

Why does native dxva cause banding on RX580 though.. :(
I have same issue on my Radeon Vega8. In addition DXVA(native) is more resource-intensive than CB.

[Manni]

Did anyone notice that 12bits on nVidia seems to distort patterns when using MadTPG as a pattern source (in 4K UHD SDR at 23p) compared to 8bits?
Could anyone with access to calibration software/equipment confirm this?
This is most visible when tracking gamut saturation and luminance linearity, but it also impacts greyscale. White balance isn't impacted significantly.
8bits is very linear and doesn't distort.
12bits breaks linearity and distorts the native gamut significantly.
It would be great if someone could confirm.
I don't use FSE, this is in full screen windowed mode.
If you don't experience this, please specify OS, nVidia driver version, and software used to calibrate/measure. Although unlikely, it could be caused by a specific setting in madVR, but I haven't had the time to investigate this yet. I have all the performance settings unchecked.
Details of rig in my sig (except driver, I was testing 385.28 for 12bits as I cant' get a custom refresh rate to work with CRU on the new JVC models).

[huhn]

can you be a bit more precise so i can do the test quicker?

[Manni]

can you be a bit more precise so i can do the test quicker?

I can't be more precise. I can ask differently though :)

Using MadTPG as a source for patterns, in 4K23p SDR, full screen windowed, using the widest gamut your display can fully cover, preferably DCI-P3:

1) Measure gamut saturations (in 20% or 25% steps) with nVidia CP set to 8bits (after checking that levels are correct).
2) Measure gamut saturation (in 20% or 25% steps) with nVidia CP set to 12bits (after checking that levels are still correct, they might need to be changed when switching between 8bits and 12bits).

Is there any significant difference?

Please report OS, driver, GPU, calibration software used with your results. I used 385.28 for my tests, otherwise rig as in my sig.

Thanks!

[huhn]

is send BT 2020 on or off?

[Manni]

is send BT 2020 on or off?

It's on when I play HDR content, not when I calibrate. And it doesn't matter if 8bits or 12bits, as the profile is the same: SDR when calibrating, as I use SDR patterns to calibrated my SDR DCI-P3 calibration, HDR when playing content.

In any case, it can't make any difference, I select the calibration manually when I calibrate.

"Send BT2020" is only a metadata flag in the SDR HDMI stream that I asked madshi to implement to help selecting a calibration automatically. It doesn't change anything in the content/patterns themselves. The only thing it can achieve is getting the display to switch to a different calibration, that all.

So as long as the proper calibration is selected when calibrating, no difference can come from that. I know it's the case here, so make sure it's the case when you run the test.

If you need BT2020 to be on for your display to select the widest gamut, then use it. Just make sure the same calibration is enabled in 8bits and 12bits, so that there shouldn't be any difference when measuring it.

[huhn]

399.07 960
displaycal 3.7.1.4
windows 10 17134
no correction
simulation profile DCI P3 D65
send bt 2020 was not used
screen with native gamut

biggest delta E between 8 bit at 8 bit and 10 bit output at 12 bit 0.2.
the used vertification testchart only uses 50% steps(didn't know that before) i do a proper one on the weekend or maybe today.

BTW. i'm not even aware of a LCD screen that can do DCI p3 100 %.

[huhn]

It's on when I play HDR content, not when I calibrate. And it doesn't matter if 8bits or 12bits, as the profile is the same: SDR when calibrating, as I use SDR patterns to calibrated my SDR DCI-P3 calibration, HDR when playing content.

In any case, it can't make any difference, I select the calibration manually when I calibrate.

"Send BT2020" is only a metadata flag in the SDR HDMI stream that I asked madshi to implement to help selecting a calibration automatically. It doesn't change anything in the content/patterns themselves. The only thing it can achieve is getting the display to switch to a different calibration, that all.

So as long as the proper calibration is selected when calibrating, no difference can come from that. I know it's the case here, so make sure it's the case when you run the test.

If you need BT2020 to be on for your display to select the widest gamut, then use it. Just make sure the same calibration is enabled in 8bits and 12bits, so that there shouldn't be any difference when measuring it.

when a screen think the input image is bt 2020 it has to change it processing because it has to clip/roll of or just squish it in that's totally different from BT 709 or just switching a screen to "native" where the screen still believes the input is "bt 709" or at least should believe that.

or with other word your device may or may not behave totally different between send bt 2020 or native.

but you don't use this option to calibrate and or verify so it shouldn't matter in this case

[Manni]

399.07 960
displaycal 3.7.1.4
windows 10 17134
no correction
simulation profile DCI P3 D65
send bt 2020 was not used
screen with native gamut

biggest delta E between 8 bit at 8 bit and 10 bit output at 12 bit 0.2.
the used vertification testchart only uses 50% steps(didn't know that before) i do a proper one on the weekend or maybe today.

BTW. i'm not even aware of a LCD screen that can do DCI p3 100 %.

Thanks a lot for checking this that quickly. Much appreciated. :)

I'll run some tests in displayCAL with your driver version to try to isolate where the issue might be coming from.

I never measure LCD monitors because I don't calibrate them. I only calibrate what I use to watch films, and that's never a monitor or even a TV.

I use a JVC RS2000 projector and with the P3 filter it can reach 100% of P3 in high lamp. Some units (not mine) can reach up to 108% of P3 with the filter. The Z1/RS4500 (laser) can reach even wider than that. On the new models such as my previous rs500, there are two filters, one green and one red (well, a dichroic filter if you prefer). On earlier models (that were also able to reach 100% of P3), there was only one green filter. Without the filters, they reach around 85-95% of P3, depending on the unit. :)

[Manni]

when a screen think the input image is bt 2020 it has to change it processing because it has to clip/roll of or just squish it in that's totally different from BT 709 or just switching a screen to "native" where the screen still believes the input is "bt 709" or at least should believe that.

or with other word your device may or may not behave totally different between send bt 2020 or native.

but you don't use this option to calibrate and or verify so it shouldn't matter in this case

Of course the display will process the content differently depending on wheter it's rec-709 or BT2020.

But the BT2020 flag by itself doesn't change anything in the content. As I explained, the only thing it can change is which display mode will be automatically selected by the display when it detects the flag. It's only a flag in the SDR HDMI stream. So if you select the display mode manually, or if the BT2020 flag has no effect on your display, the use of the flag doesn't account for any difference in measurements.

[huhn]

let me say it this way my screen disagrees and behaves very different between native and send BT 2020.

[madjock]

let me say it this way my screen disagrees and behaves very different between native and send BT 2020.

Cool one more thing to confuse me now :D

[el Filou]

So does that mean the differences Manni is seeing could be explained by a different processing of 8-bit and 12-bit input by the display?

[huhn]

could be. but there so so many more possibilities.
not going to put a finger on it yet not until i have better readings from more than one person.

[tp4tissue]

Did anyone notice that 12bits on nVidia seems to distort patterns when using MadTPG as a pattern source (in 4K UHD SDR at 23p) compared to 8bits?
Could anyone with access to calibration software/equipment confirm this?
This is most visible when tracking gamut saturation and luminance linearity, but it also impacts greyscale. White balance isn't impacted significantly.
8bits is very linear and doesn't distort.
12bits breaks linearity and distorts the native gamut significantly.
It would be great if someone could confirm.
I don't use FSE, this is in full screen windowed mode.
If you don't experience this, please specify OS, nVidia driver version, and software used to calibrate/measure. Although unlikely, it could be caused by a specific setting in madVR, but I haven't had the time to investigate this yet. I have all the performance settings unchecked.
Details of rig in my sig (except driver, I was testing 385.28 for 12bits as I cant' get a custom refresh rate to work with CRU on the new JVC models).


I noticed this in the form of less gradient smoothness.

But I don't think it's nvidia's issue, the TV probably doesn't react very well to 10 or 12 bit. Because its frc dithering algorithm may have some inherent sharpening or debanding which doesn't allow for perfectly smooth gradient.

[YGPMOLE]

A couple of stupid questions (sorry!).

1) Now I'm trying the beta version (.54) with an AMD RX480 in full RGB 8Bit, LAV in DX3D11, madVR 8bit, but the on-screen display shows the output DX3D11 10Bit that goes at 8Bit only when I open the menù (and goes back to 10 when I close it) even with SD or FullHD files 8Bit as input: it's that normal?

2) I have all the displays mode inserted (from 1080p23 to 2160p60), but I got no switches with 23.976, 24.000 or 25.000 files like it was with the .17 version: still normal?

[Manni]

let me say it this way my screen disagrees and behaves very different between native and send BT 2020.

yes, and it should if you don't have another way to select a calibration manually.

This is not the way it works with all displays.

And again, the way the display behaves has nothing to do with the content. The content is identical even when the enable BT2020 flag is sent.

It is, again, only a single metadata flag.

So either your screen reacts to it, and selects a different calibration.

Or your screen doesn't react to it.

You are really making things confusing with your statements.

Your are confusing the display's response and the content.

The content is 100% the same whether the report BT2020 checkbox is enabled or not.

Enabling it *might* trigger a different calibration/mode in your display.

If it does, then of course the display's response will be different. Hopefully, it will be more appropriate to the content. But the content itself will be 100% identical.

So if you can select manually the mode that *might* be selected automatically when the BT2020 flag is enable, there should be zero difference, because the content is the same.

Please can you confirm this instead of implying that things might be different? It will help everyone to understand what is happening and not cause unnecessary confusion.

The issue I am reporting, which apparently you are not experiencing, has nothing to do with the BT2020 flag. At least on my display, I can tell you it's 100% unrelated. It simply can't be.

What you are stating, which is that your display doesn 't respond the same whether you enable the BT2020 flag or not, is 100% unrelated. It is to be expected with most displays.

As long as the flag remains the same during measurements between 8bits and 12bits, and that levels are the same, that makes zero difference. Enable if you need it to access your wide/native gamut, disable otherwise, just make sure it's consistent between the two measurements.

@El filou: yes what I'm seeing could be explained by either a different processing by the display between 8bits and 12bits, or by a bug in the drivers/OS/calibration software. That's why I need to first see if I can get the expected results in 12bits, the way Huhn does, and then see what produces the wrong results, changing one parameter at a time (driver, calibration software). If I still have the issue, then it might be the processing in the display and I'll have to try with another display, until I find the cause.

But it's great to know that it's not an issue for everyone, at least if gives me something to try. So thanks again to huhn for that.

If anyone has a JVC projector and would like to test and report if they see the same behaviour I do (or not), that would be great too.

I don't have the version Huhn used, but I'll try with the latest before that, which is 397.93. 398.11 changed a lot of things, so 397.97 should be similar to 398.07.

[Manni]

I noticed this in the form of less gradient smoothness.

But I don't think it's nvidia's issue, the TV probably doesn't react very well to 10 or 12 bit. Because its frc dithering algorithm may have some inherent sharpening or debanding which doesn't allow for perfectly smooth gradient.

Guys, please stick to the question.

Gradient smoothness has nothing to do with MadTPG patterns.

Yes, there is more banding in 8bits than in 12bits on my display. Significantly. Otherwise I'd stick with 8bits.

Yes, my display supports 12bits natively, from input to panels.

This isn't the question.

The question is: does anyone measure different results when using madTPG patterns in 8bits and in 12bits (4K23 SDR WCG)?

If you can't contribute the way Huhn kindly did, then please stay out, because that's not helping.

I don't need advice, I need data. :)

[tp4tissue]

A couple of stupid questions (sorry!).

1) Now I'm trying the beta version (.54) with an AMD RX480 in full RGB 8Bit, LAV in DX3D11, madVR 8bit, but the on-screen display shows the output DX3D11 10Bit that goes at 8Bit only when I open the menù (and goes back to 10 when I close it) even with SD or FullHD files 8Bit as input: it's that normal?

2) I have all the displays mode inserted (from 1080p23 to 2160p60), but I got no switches with 23.976, 24.000 or 25.000 files like it was with the .17 version: still normal?

Yea, my R 580 does the same thing. pops in and out of hdr if using menu.

[huhn]

i'm aware that is 100% the display not the send content.

So if you can select manually the mode that *might* be selected automatically when the BT2020 flag is enable, there should be zero difference, because the content is the same.

just telling my Tv disagrees

What you are stating, which is that your display doesn 't respond the same whether you enable the BT2020 flag or not, is 100% unrelated. It is to be expected with most displays.
what else should i see i'm over this option.
but you don't use this option to calibrate and or verify so it shouldn't matter in this case

and i said may or may not anyway

[Manni]

just telling my Tv disagrees


Your TV doesn't disagree. It simply means that you can't select manually the mode that is selected automatically when the BT2020 flag is sent. Even if it is the same mode, some additional/different processing is clearly enabled.

If, as with my display, you could select manually exactly the same mode/calibration/processing that is selected when the BT2020 flag is sent, then you would see that there is no difference in content.

Anyway, I guess something is getting lost in translation here.

Plus that flag isn't enabled when I calibrate, and you didn't use it for your test, so let's put that aside as it's entirely unconnected with the 8bits/12bits measurements issue.

[ashlar42]

- D3D11 native prevents using hardware deinterlacing
- D3D11 copy-back is slower than DXVA2 copy-back and has no quality advantages, so you have no reason to use it reallyIf D3D11 native prevents hardware deinterlacing in madVR, isn't that a reason to use D3D11 copy-back?

[huhn]

dxva2 copyback is supposed to be faster.

[Siso]

dxva2 copyback is supposed to be faster.

Faster than D3D11 native and D3D11 copyback?

[huhn]

DXVA copyback is supposed to be a little bit faster than d3d11 copyback.

everything had been said: https://forum.doom9.org/showpost.php?p=1866277&postcount=54943

[Siso]

DXVA copyback is supposed to be a little bit faster than d3d11 copyback.

everything had been said: https://forum.doom9.org/showpost.php?p=1866277&postcount=54943

Thanks, huhn. :goodpost:

[FranknStein7]

I just noticed that the detect black bars functionality only seems to work on some titles. I can't seem to determine why it works on some but not others. For instance, take the Harry Potter blu-rays (remuxed to MKVs with MakeMKV). On the Sorcerer's Stone black bar detection and cropping works as expected. But on the Chamber of Secrets, it doesn't. Both are blu-ray rips, both are VC-1 encodes, and both are 2.39:1 format. Any ideas?

Edit: I was wrong. Automatic black bar detection IS working on all titles it seems. For instance if I go into full screen on my 21:9 monitor, black bars are cropped appropriately. What doesn't appear to be working consistently, is automatic cropping of black bars while MPC-HC is in windowed mode. So on Sorcerer's Stone, the black bars are cropped out of the window, but on the Chamber of Secrets, they are not. If I stretch the window so that it's very wide, then the black bars are cropped appropriately.

[70MM]

I use black bar detection and think its a great thing as it lowers the rending times, however Ive had it trip up a number of titles and can go crazy at times...
e.g. On "oz the great and powerful" its a scope film but the start 15mins or so is B&W and meant to be 4.3, then when it changes colour the sides open to scope 2.35
If I dont have black bar detection ON, it works perfectly 4:3 > 2.35 in the right place.
if I have black bar detection turned on which i like to ue, on this title the start zooms up to 16:9 when it should be 4.3, then as it widens to scope after 15 mins the image jumps in and out, the zooming gets muddled and its a mess until the sides reach the scope borders.....

Black bar detection works great on most titles but not on anything that the ratios change. I have tried and tested every tick box but I just cant get it working acuratley on this title and some others that are similar. I have some other files that the ratios change 4.3, 1.66, 16.9, 1.85 and scope, on these that change often black bar detection gets muddled, again Ive tried making changes, read change every 45secs, 20secs etc etc, it still doesnt correct the zooming in and out.

Maybe there is a way that i dont know of to make black bar detection work for all unusual titles without jumping round.... For a film thats static its fantastic, maybe these other titles with mixed ratios it just cant cope...

[Grimsdyke]

Here is the problem:
When I play a 4k-file that has no black bars and change something in MadVR like target nits, etc. I see an immediate effect !!
But on files with black bars nothing changes - no matter what setting I test !! The only setting that has an effect is (de-)activating "output video in HDR format".

@Madshi. Without the madvr osd I can at least set/change target nits. Most of other settings are still not working. Don't know if you could do anything about that. Thx

[tp4tissue]

I use black bar detection and think its a great thing as it lowers the rending times, however Ive had it trip up a number of titles and can go crazy at times...
e.g. On "oz the great and powerful" its a scope film but the start 15mins or so is B&W and meant to be 4.3, then when it changes colour the sides open to scope 2.35
If I dont have black bar detection ON, it works perfectly 4:3 > 2.35 in the right place.
if I have black bar detection turned on which i like to ue, on this title the start zooms up to 16:9 when it should be 4.3, then as it widens to scope after 15 mins the image jumps in and out, the zooming gets muddled and its a mess until the sides reach the scope borders.....

Black bar detection works great on most titles but not on anything that the ratios change. I have tried and tested every tick box but I just cant get it working acuratley on this title and some others that are similar. I have some other files that the ratios change 4.3, 1.66, 16.9, 1.85 and scope, on these that change often black bar detection gets muddled, again Ive tried making changes, read change every 45secs, 20secs etc etc, it still doesnt correct the zooming in and out.

Maybe there is a way that i dont know of to make black bar detection work for all unusual titles without jumping round.... For a film thats static its fantastic, maybe these other titles with mixed ratios it just cant cope...

Where is Black bar detection enabled? What does it allow you to do ?

NM I found it..

It doesn't seem to be lowering rendering times.. How much should it lower rendering times ?

OKOKOK, on 2.39:1 film, I looked more closely.. ~ 0.4-0.6 ms, Is that the correct behavior everyone else is getting.

This is on 1060 @ 2088mhz, 9ghz memory

[SirSwede]

I am sorry, if this question may be out of place and/or too "n00b" to be allowed - just tell me if that is the case and I'll remove it. :-)

I have Asperger and get anxiety if things are not done in the same way each time and I am not at home, so I can't check this and therefore I am turning to this forum.

My HTPC is a Windows 7 Home Premium DELL desktop computer and the only programs I use on it are CCleaner, ReClock, MPC-HC with LAV Filters and madVR.

(Yes, I know about CCleaner, but only use the right click option on the Recycle Bin to empty it and never enter the program itself.)

When I want to watch something, I move it from either of the USB-hard drives connected to my router or from my NAS and place it on the Windows desktop of the HTPC. I then run CCleaner once, click the .mkv-file once and press Enter on the keyboard; ReClock, MPC-HC and madVR starts accordingly. When the program has come to it's end, ReClock, MPC-HC and madVR exits back to the Windows desktop, after which I drag the .mkv-file to the Recycle Bin, run CCleaner once from the right-click menu and then either shut the computer down, turn off the TV (to watch something later) or move a new .mkv-file to the desktop from either drive.

With this in mind, I have two questions for you, the people, more knowledgeable than I:

1. The last program I watched before I left home, I think I might have forgotten the .mkv-file on the desktop, ran CCleaner from the right-click menu of the, empty, Recycle Bin and then shut down the computer. If that is the case and the computer is - next time - not turned on in the same state that it always is: With and empty Windows desktop and I the proceed to remove the file, can this in any way affect the performance and - most importantly - the picture quality of - primarily - madVR (and/or ReClock and MPC-HC)? :o

2. Additional question - please put it to me as bluntly as you can: I am "overdoing it", aren't I? :p

:thanks:

[tp4tissue]

I am sorry, if this question may be out of place and/or too "n00b" to be allowed - just tell me if that is the case and I'll remove it. :-)

I have Asperger and get anxiety if things are not done in the same way each time and I am not at home, so I can't check this and therefore I am turning to this forum.

My HTPC is a Windows 7 Home Premium DELL desktop computer and the only programs I use on it are CCleaner, ReClock, MPC-HC with LAV Filters and madVR.

(Yes, I know about CCleaner, but only use the right click option on the Recycle Bin to empty it and never enter the program itself.)

When I want to watch something, I move it from either of the USB-hard drives connected to my router or from my NAS and place it on the Windows desktop of the HTPC. I then run CCleaner once, click the .mkv-file once and press Enter on the keyboard; ReClock, MPC-HC and madVR starts accordingly. When the program has come to it's end, ReClock, MPC-HC and madVR exits back to the Windows desktop, after which I drag the .mkv-file to the Recycle Bin, run CCleaner once from the right-click menu and then either shut the computer down, turn off the TV (to watch something later) or move a new .mkv-file to the desktop from either drive.

With this in mind, I have two questions for you, the people, more knowledgeable than I:

1. The last program I watched before I left home, I think I might have forgotten the .mkv-file on the desktop, ran CCleaner from the right-click menu of the, empty, Recycle Bin and then shut down the computer. If that is the case and the computer is - next time - not turned on in the same state that it always is: With and empty Windows desktop and I the proceed to remove the file, can this in any way affect the performance and - most importantly - the picture quality of - primarily - madVR (and/or ReClock and MPC-HC)? :o

2. Additional question - please put it to me as bluntly as you can: I am "overdoing it", aren't I? :p

:thanks:


It will definitely not affect picture quality.

The ccleaner also has no impact in your current use-process.

Theoretically if you wanted everything to remain identically in place, you would have to re-image the entire drive every time you used the computer.

EVEN THEN, because of wear leveling on the ssd nand, the data will never be copied to the exact same place after imaging.

There are analog elements to the entire computing process which one can not bring ORDER to. :D

The very nature of Perception is a simplification/ modeling process, an approximation of what is.

[Jesco]

I am sorry, if this question may be out of place and/or too "n00b" to be allowed - just tell me if that is the case and I'll remove it. :-)

I have Asperger and get anxiety if things are not done in the same way each time and I am not at home, so I can't check this and therefore I am turning to this forum.

My HTPC is a Windows 7 Home Premium DELL desktop computer and the only programs I use on it are CCleaner, ReClock, MPC-HC with LAV Filters and madVR.

(Yes, I know about CCleaner, but only use the right click option on the Recycle Bin to empty it and never enter the program itself.)

When I want to watch something, I move it from either of the USB-hard drives connected to my router or from my NAS and place it on the Windows desktop of the HTPC. I then run CCleaner once, click the .mkv-file once and press Enter on the keyboard; ReClock, MPC-HC and madVR starts accordingly. When the program has come to it's end, ReClock, MPC-HC and madVR exits back to the Windows desktop, after which I drag the .mkv-file to the Recycle Bin, run CCleaner once from the right-click menu and then either shut the computer down, turn off the TV (to watch something later) or move a new .mkv-file to the desktop from either drive.


:thanks:

Why don’t you just run the movie directly from the nas or external harddrive? Seems senseless to move files everytime. Defeats the purpose of having external storage. Also, why don’t you just empty the recycle bin using rightmouse button on it. No need for ccleaner for just emptying the recyclebin.

[SirSwede]

Why don’t you just run the movie directly from the nas or external harddrive? Seems senseless to move files everytime. Defeats the purpose of having external storage. Also, why don’t you just empty the recycle bin using rightmouse button on it. No need for ccleaner for just emptying the recyclebin.

Two reasons:

1. I had the HTPC before I had any kind of external storage, so that would move me away from how I've always done it (the Asperger comes into play there)

2. In my head, that would be slower, no? Wouldn't the render and present times increase, running it not directly from the same hard drive where madVR is installed? :confused:

[clsid]

Press Shift+Delete to bypass recycle bin.

Location of a file does not have any effect on the performance of madvr.

[tp4tissue]

Press Shift+Delete to bypass recycle bin.

Location of a file does not have any effect on the performance of madvr.

It does on very low spec machines. I've got a netbook that chokes if playing files over wifi, as the transfer and cpu overhead of the wireless eats into the rendertime. And some wireless cards also greatly increase dpc latency which can cause render time spikes as well.

[huhn]

this has nothing todo with madVr if the file doesn't get there in time.

I use black bar detection and think its a great thing as it lowers the rending times, however Ive had it trip up a number of titles and can go crazy at times...
e.g. On "oz the great and powerful" its a scope film but the start 15mins or so is B&W and meant to be 4.3, then when it changes colour the sides open to scope 2.35
If I dont have black bar detection ON, it works perfectly 4:3 > 2.35 in the right place.
if I have black bar detection turned on which i like to ue, on this title the start zooms up to 16:9 when it should be 4.3, then as it widens to scope after 15 mins the image jumps in and out, the zooming gets muddled and its a mess until the sides reach the scope borders.....

Black bar detection works great on most titles but not on anything that the ratios change. I have tried and tested every tick box but I just cant get it working acuratley on this title and some others that are similar. I have some other files that the ratios change 4.3, 1.66, 16.9, 1.85 and scope, on these that change often black bar detection gets muddled, again Ive tried making changes, read change every 45secs, 20secs etc etc, it still doesnt correct the zooming in and out.

Maybe there is a way that i dont know of to make black bar detection work for all unusual titles without jumping round.... For a film thats static its fantastic, maybe these other titles with mixed ratios it just cant cope...

try the option: "if black bars change pick one zoom factor".

this feature will never be fool proofed.