View Full Version : madVR - high quality video renderer (GPU assisted)
DigitalLF
21st October 2015, 15:28
first of a bugreport!
in MadVR. devices - sony vm500es - properties - green text right of "test projector" says (JVC) until i press "FIND"/"TEST" again, even if the ip is correct.
Sorry, typo. I meant: "Do you have black bar *detection* activated"?
yes!
Do you have any other software which could potentially be issuing ip control commands to your JVC while madVR is running? That could cause trouble.
Just so you know. I have a Control4 system that talks TCP/IP with my projector!
I didn't mean which *device* was bold. I mean the "screen config" profiles. You do have different "screen config" profiles setup, so you could activate different lens memories, right? When you open the settings dialog while madVR is doing video playback, one of the sceen config *profiles* should be bold. Is it always the correct one?
oh sorry! No! i did not know there was a "screen config group" but i don't know how to script. i saw that i can make hotkeys for it and i tried that and that did not work more then that the OSD said "screen mode 2.40:1" or something like that.
EDIT: i now tried to make a script. Is this correct? on a "1.85:1" movie it still uses "2.40:1" my profiles are called "1.77:1", "1.85:1", "2.40:1"
if (AR = 1.85:1) "1.85:1" else
if (AR = 2.35:1) "2.40:1" else
if (AR = 2.40:1) "2.40:1" else "1.77:1"
1) What happens if you activate mem2, and then while it's still in the process of switching to mem2, if you activate mem2 *again*? Does it abort the operation then? Or does the 2nd mem2 button press have no effect?
it stops and says failed, if i press mem2 while mem2 is being "loaded" if i then press "mem3" it goes back to "mem3"
2) What happens if you activate mem2, wait until it's fully done, then activate mem2 again? Does the projector do anything at all? Or is it clever enough to know that nothing needs to be done?
then the projectors OSD just shows and says "adj. completed".
With this new build please also repeat the following 2 tests:
downloaded and tested.
1) Does abort work correctly now?
no it does not. still nothing. are you sending a incorrect command?
2) If you press mem2, and then mem1, before mem2 is fully done, does it properly abort mem2 and automatically activate mem1 now, with just the one button press?
No it stops like a "ABORT" would. and writes a log line "failed"
aufkrawall
21st October 2015, 16:28
Maybe linear light should be used by default for SuperRes?
Also with strength 3, sharpness 2 an (I think mostly unwanted) increase of brightness can be observed without it.
LL on:
http://abload.de/thumb/llon99s32.png (http://abload.de/image.php?img=llon99s32.png)
LL off:
http://abload.de/thumb/lloffp9sh8.png (http://abload.de/image.php?img=lloffp9sh8.png)
JarrettH
21st October 2015, 18:08
Is there some reason why I can't get the madvr test patterns (ytp files) to load? It's been like this for 6 months or more. Just says cannot render file. I'm on 88.21 and MPC 1.7.9, both 64-bit. Does this maybe have a 64-bit conflict? Windows 7 SP1
cvrkuth
21st October 2015, 18:29
After install new version, my devices are gone?
That's weird. I can only guess that your settings configuration got corrupted/damaged somehow. Does going back to the old version fix the problem? Please run a checkdisk/scandisk to make sure your file system is healthy.
Uninstall AMD-Catalyst-15.9.1Beta-64Bit and install AMD-Catalyst-15.7.1-Win10-64bit and now is ok
Regards!
Olivier C.
21st October 2015, 20:46
Seems interesting. Are you sure the GPU is not changing frequencies to save power?
On a quick test I get 35% usage for Catmull-Rom without linear light and 41% with LL for image downscaling on a 24fps 4K viedo and that's on a Geforce 750Ti(!).
Could you post your settings, especially scaling algorithms used, smooth motion (on/off), dithering used and screenshot of debug OSD?
Thanks for your reply.
You can find below the settings and results with Linear Light On & Off :
OSD MPC-HC & GPU-Z with Linear Light OFF :
http://img15.hostingpics.net/thumbs/mini_286452MPCHCLLOFF.jpg (http://www.hostingpics.net/viewer.php?id=286452MPCHCLLOFF.jpg)
OSD MPC-HC & GPU-Z with Linear Light ON :
http://img15.hostingpics.net/thumbs/mini_583291MPCHCLLON.jpg (http://www.hostingpics.net/viewer.php?id=583291MPCHCLLON.jpg)
madVR - General Settings :
http://img15.hostingpics.net/thumbs/mini_367171madvrGeneralsettings.jpg (http://www.hostingpics.net/viewer.php?id=367171madvrGeneralsettings.jpg)
madVR - Output :
http://img15.hostingpics.net/thumbs/mini_766354madVRoutput.jpg (http://www.hostingpics.net/viewer.php?id=766354madVRoutput.jpg)
madVR - Trade Quality for Performance :
http://img15.hostingpics.net/thumbs/mini_994018madVRTradeQuality.jpg (http://www.hostingpics.net/viewer.php?id=994018madVRTradeQuality.jpg)
madVR - Downscale :
http://img15.hostingpics.net/thumbs/mini_825447madvrDownscaleLLOFF.jpg (http://www.hostingpics.net/viewer.php?id=825447madvrDownscaleLLOFF.jpg)
madVR - Chroma Upscaling :
http://img15.hostingpics.net/thumbs/mini_601661madvrChromaUpscaling.jpg (http://www.hostingpics.net/viewer.php?id=601661madvrChromaUpscaling.jpg)
madVR - Double Luma :
http://img15.hostingpics.net/thumbs/mini_186950madvrDoubleLuma.jpg (http://www.hostingpics.net/viewer.php?id=186950madvrDoubleLuma.jpg)
madVR - Upscaling Refinement :
http://img15.hostingpics.net/thumbs/mini_120772madvrUpscalingrefinement.jpg (http://www.hostingpics.net/viewer.php?id=120772madvrUpscalingrefinement.jpg)
madVR - Dithering :
http://img15.hostingpics.net/thumbs/mini_153717madVRDithering.jpg (http://www.hostingpics.net/viewer.php?id=153717madVRDithering.jpg)
madVR - Smooth Motion :
http://img15.hostingpics.net/thumbs/mini_669892madVRSmoothMotion.jpg (http://www.hostingpics.net/viewer.php?id=669892madVRSmoothMotion.jpg)
madVR - Image Enhancements :
http://img15.hostingpics.net/thumbs/mini_482675madVRImageEnhancements.jpg (http://www.hostingpics.net/viewer.php?id=482675madVRImageEnhancements.jpg)
madVR - Deband :
http://img15.hostingpics.net/thumbs/mini_199699madVRDeband.jpg (http://www.hostingpics.net/viewer.php?id=199699madVRDeband.jpg)
Hope it helps
mcn
21st October 2015, 21:09
I'm using madVR with MPC-HC.
I noticed that if I take a screenshot with the window resized below the actual video size the image is taken at the window resolution, with aspect ratio correction (if any) applied.
This is an interesting behaviour and I would like to ask if it's possible (and how) to:
force screenshots to be always taken at the original video resolution
take screenshots at the window size resolution even when it's resized to be larger than the original video dimensions
jmonier
21st October 2015, 22:13
Just give the test tool a try, please, to double check the reliability of Ip Control with your JVC, using my code. Thanks.
Do you have any other software which could potentially be issuing ip control commands to your JVC while madVR is running? That could cause trouble.
Here's what's happening:
If the JVC is off or it's been turned on locally (JVC remote control or power button) everything works as expected using your program.
If the JVC has been turned on remotely by me (either by RS232 or TCPIP) then your program will still find it, but always reports power state as standby and NONE of the other commands work.
My software does not issue IP (or rs232) control commands once power up is completed until power down. Note that I close the socket after every control command (and that the JVC would close it if I don't).
Thus it seems that once the JVC has been turned on by a control command from one source, it will no longer accept control commands from any other source (TCPIP or RS232) until a power off command is issued from the same source that issued the power on.
nevcairiel
21st October 2015, 22:14
In the next few weeks only expect bugfixes and small improvements, no big new features. Need to concentrate on my daily job for a while now.
Honestly I consider that a good thing. With all these new features in every other madVR release of late, there hasn't been a version for a long time that I considered perfectly stable and problem free. :)
Maybe a period of quiet and collecting and fixing issues is a good thing. :D
agustin9
21st October 2015, 23:39
I'm still having problems with the subtitle margin. The bottom margin when moving the subtitles to the bottom of the window isn't woking for me. Anyone with the same problem? Thanks!
truexfan81
22nd October 2015, 00:54
Honestly I consider that a good thing. With all these new features in every other madVR release of late, there hasn't been a version for a long time that I considered perfectly stable and problem free. :)
Maybe a period of quiet and collecting and fixing issues is a good thing. :D
Maybe its because my athlon 2 dualcore 2.9, 4GB ram, and NVIDIA GTX 650 1GB is to old to use any of the new stuff, but i've had 0 issues with the latest versions of madvr.
i am mostly just using Jinc3AR with AdaptiveSharpen 0.7 pre upscale
djsolidsnake86
22nd October 2015, 01:11
with a 7850 what are the suggested settings?
Arm3nian
22nd October 2015, 05:12
with a 7850 what are the suggested settings?
Whatever looks good to you and stays under the max render time.
huhn
22nd October 2015, 06:41
Thanks for your reply.
You can find below the settings and results with Linear Light On & Off :
should be a Vram issue with madVR. it looks like it tries to take more than 6 GB ram and is now using a ram page file which is terrible slow.
ionutm80
22nd October 2015, 07:07
Hi guys,
I really need your help in understanding the effect of some changes I have made in madVR that allowed me to have a smooth playback again after hours of fighting with a nasty stuttering. Sorry if this seems stupid but I just need to know whether I have finally found the magic solution or is just something circumstantial.
First let me list my rig and the initial settings:
- Intel NUC D34010WYKH, intel Core I3 4010U (r (1.7 GHz Dual-Core processor with 3 MB smart cache), Intel HD 4400 GPU, Crucial 2x4GB = 8GB DDR3 1600MHz, 60GB OCZ Agility SSD
- LAVFIlters: DXVA Copy-Back
- madVR:
* chroma-up: BCB75AR
* image-up: DXVA
* image doubling: None
* image-down: DXVA
* enable fullscreen exclusive mode
* dithering: ordered
* smooth motion: off
- SVP: default 1g profile, 59.94Hz
- TV; Sony KDL26EX320, 60Hz, 1366x768
- ReClock: WASAPI exclusive Asus Xonar U3, 24 bit padded into 32, resolution of 59.94 input manually first time the video plays
- movies: Blu-Rays: 1920x1080 / 800, 23,976fps, DVDs: 720x576, 25,000fps (PAL) , Samsung S4: 1920x1080, 29,911fps.
With the above settings and everything else left as default in madVR I had a terrible stuttering even if madVR stats showed 1 frame drop every 6-7 hours. Please see print screen below:
http://i.imgur.com/2h3fKyP.jpg
But then I have just spotted that my "present queue" was showing 5-7/8 instead of 7-8/8 so I decided to drop the frames presented in advance from 8 to 4 in fullscreen mode and from 8 to 3 in windowed mode. Also in the tab trade quality for performance I've checked the first 4 options up to "store custom pixel shader ..." ... and voila my "present queue" was now 2-3/3 (windowed) and 3-4/4 (fullscreen) and the stutter was almost non percievable. Then I remember an article on Anandtech where they tested the NUC (the Core I5 version) with madVR and used "CPU and GPU queue sizes of 128 and 24". I said why not try, did that and no more stutter visible, madVR shows 1 drop frame every 1.02 days and SVP performance graphs show CPU average at 67% with 1g profile. Indeed the guys at Anandtech also increased the frames presented in advance to 16 ... and this is where I'm a bit lost. They have practically maxed everything.
http://www.anandtech.com/show/7566/intels-haswell-nuc-d54250wyk-ucff-pc-review/5
Can you please tell me in which way did my PC benefited from the above and whether maxing out CPU and GPU queues size is a right thing to do in my case? Are there any other settings that would give me a better bang for the buck?
ashlar42
22nd October 2015, 10:45
mashi, I fully admit that I'm ignorant about this, and you might have already given an answer for this. Considering your experience with dedicated scalers (Lumagen, if I remember correctly from our Panasonic discussions for 1:1 pixel mappings), is Non Linear Stretch for 4:3 material something you might be considering for the future?
madshi
22nd October 2015, 10:55
May be you put link to this http://forum.doom9.org/showthread.php?p=1724688#post1724688 from first post of the thread?
Not a bad idea, but then I don't think many users bother to read the first post. At some point there's going to be a manual or something like that. For now we'll have to live with constantly repeating support requests, I fear...
Is there some reason why I can't get the madvr test patterns (ytp files) to load? It's been like this for 6 months or more. Just says cannot render file. I'm on 88.21 and MPC 1.7.9, both 64-bit. Does this maybe have a 64-bit conflict? Windows 7 SP1
The test patterns currently only support 32bit media players.
Uninstall AMD-Catalyst-15.9.1Beta-64Bit and install AMD-Catalyst-15.7.1-Win10-64bit and now is ok
Ah ok. That means that with the beta driver seemingly no monitors were reported at all to madVR by your OS/driver.
You can find below the settings and results with Linear Light On & Off
should be a Vram issue with madVR. it looks like it tries to take more than 6 GB ram and is now using a ram page file which is terrible slow.
^
Yep, seems to be a GPU RAM size issue. When enabling linear light, I'm using 32bit floating point textures for some processing steps, which consume twice as much RAM as the default format. I'm a bit surprised GPU RAM size seems to more than double, though, that doesn't make a lot of sense, to be honest. Anyway, you can probably work around the issue by reducing the size of the GPU queue a bit.
madVR v0.89.12.0 seems to work as expected.
Performance improvements of NNEDI3 and SuperRes seem to pay off, I can watch 1080p60 -> WQHD with NNEDI3 32 chroma, Jinc AR image, SuperRes 3 passes and maximum deband + SM without dropped frames on my GTX 980 OC.
I'm relatively sure that this wasn't possible in the past.
Good to hear!
first of a bugreport!
in MadVR. devices - sony vm500es - properties - green text right of "test projector" says (JVC) until i press "FIND"/"TEST" again, even if the ip is correct.
Ooops, good catch! Here's a fixed madHcCtrl.exe for you:
http://madshi.net/madHcCtrlSony.rar
Does that fix the problem for you? It might also make lens memories work for your Sony.
EDIT: i now tried to make a script. Is this correct? on a "1.85:1" movie it still uses "2.40:1" my profiles are called "1.77:1", "1.85:1", "2.40:1"
if (AR = 1.85:1) "1.85:1" else
if (AR = 2.35:1) "2.40:1" else
if (AR = 2.40:1) "2.40:1" else "1.77:1"
AR is often not *exactly* one of those numbers. E.g. imagine a Cinemascope Blu-Rays with 1920x796 active pixels. That's an AR of 2.4120603015075376884422110552764. You can't write the script in such a way to handle every possible AR. So instead of using "if AR = something" use "if AR > something". So your script could read:
if (AR > 1.9) "2.40:1" else
if (AR > 1.8) "1.85:1" else "1.77:1"
That said, do you really need different profiles for 1.85:1 and 1.77:1? Your call, though. Personally, with my CIH setup I just have 2 profiles, one for Cinemascope movies, and one for every other AR. So I'm just using "if (AR > 1.9) "21:9" else "16:9"".
Maybe linear light should be used by default for SuperRes?
Also with strength 3, sharpness 2 an (I think mostly unwanted) increase of brightness can be observed without it.
The difference doesn't seem so dramatic to me. But yes, there is a difference. But look at the roof ceiling line of the left most building. The line is noticably fatter in the linear light image. Once again, as I said before, ideally linear light should be enabled if the source was downscaled in linear light, or if it wasn't downscaled at all. But if the source was downscaled in gamma light from a higher resolution master, then disabling linear light should produce results that are nearer to the original master.
I'm aware of that it's pretty hard to say when linear light should be enabled and when not. So maybe I should remove the option. But which option should I set it to then? Especially with Anime content the difference between linear light and gamma light can be *huge*. Black lines are very noticably fatter when using linear light.
I'm using madVR with MPC-HC.
I noticed that if I take a screenshot with the window resized below the actual video size the image is taken at the window resolution, with aspect ratio correction (if any) applied.
This is an interesting behaviour and I would like to ask if it's possible (and how) to:
force screenshots to be always taken at the original video resolution
take screenshots at the window size resolution even when it's resized to be larger than the original video dimensions
Screenshot functionality will be revisited at some point in the future, but probably not in the next few weeks.
Here's what's happening:
If the JVC is off or it's been turned on locally (JVC remote control or power button) everything works as expected using your program.
If the JVC has been turned on remotely by me (either by RS232 or TCPIP) then your program will still find it, but always reports power state as standby and NONE of the other commands work.
My software does not issue IP (or rs232) control commands once power up is completed until power down. Note that I close the socket after every control command (and that the JVC would close it if I don't).
Thus it seems that once the JVC has been turned on by a control command from one source, it will no longer accept control commands from any other source (TCPIP or RS232) until a power off command is issued from the same source that issued the power on.
That's quite interesting! Let's look at the possible scenario cases one by one and let me ask a few questions for clarification:
1) projector is turned on by rs232
How is this possible?? At least my JVC X35 has a setup menu option to either use rs232 or ip control - I have to choose! Does your projector not have such a menu option? If it does have such an option, have you set it to rs232 or ip control?
Does your own ip control software work if you turned the projector on via rs232, while my ip control test tool fails?
2) projector is turned on by your ip control software
In this situation my ip control test tool fails, too? Does your own ip control software manage to switch lens memories or stuff in this situation, while my test tool fails?
3) projector is turned on physically (remote or project power switch)
In this situation my ip control test tool works perfectly?
4) projector is turned on by my ip control test tool
What happens in this case? Does my test tool work? Does your ip control software work?
Honestly I consider that a good thing. With all these new features in every other madVR release of late, there hasn't been a version for a long time that I considered perfectly stable and problem free. :)
Maybe a period of quiet and collecting and fixing issues is a good thing. :D
Well, I wasn't planning to do intensive bug searching & fixing, instead of adding new features. The point was just to reduce madVR development time for a while. So I'm not sure if that will help overall stability much.
Anyway, I think the biggest stability problems were caused by adding support for rendering in paused&stopped graph state, followed by changes needed to make black bar detection work. All those changes were rather invasive, and thus came with a high risk of new stability issues. However, I think most of the other new features planned for the near future are less risky, so stability should trend up now, regardless of whether I add new features or not.
Do you have any specific problems with v0.89.12? My impression from feedback so far is that it's working pretty well and stable.
I'm still having problems with the subtitle margin. The bottom margin when moving the subtitles to the bottom of the window isn't woking for me. Anyone with the same problem? Thanks!
Which subtitle renderer? SRT, ASS or bitmap (PGS/SUP)? Screenshots and a sample would be nice.
I really need your help in understanding the effect of some changes I have made in madVR that allowed me to have a smooth playback again after hours of fighting with a nasty stuttering. Sorry if this seems stupid but I just need to know whether I have finally found the magic solution or is just something circumstantial.
With the above settings and everything else left as default in madVR I had a terrible stuttering even if madVR stats showed 1 frame drop every 6-7 hours. Please see print screen below:
[...]
But then I have just spotted that my "present queue" was showing 5-7/8 instead of 7-8/8 so I decided to drop the frames presented in advance from 8 to 4 in fullscreen mode and from 8 to 3 in windowed mode. Also in the tab trade quality for performance I've checked the first 4 options up to "store custom pixel shader ..." ... and voila my "present queue" was now 2-3/3 (windowed) and 3-4/4 (fullscreen) and the stutter was almost non percievable. Then I remember an article on Anandtech where they tested the NUC (the Core I5 version) with madVR and used "CPU and GPU queue sizes of 128 and 24". I said why not try, did that and no more stutter visible, madVR shows 1 drop frame every 1.02 days and SVP performance graphs show CPU average at 67% with 1g profile. Indeed the guys at Anandtech also increased the frames presented in advance to 16 ... and this is where I'm a bit lost. They have practically maxed everything.
http://www.anandtech.com/show/7566/intels-haswell-nuc-d54250wyk-ucff-pc-review/5
Can you please tell me in which way did my PC benefited from the above and whether maxing out CPU and GPU queues size is a right thing to do in my case? Are there any other settings that would give me a better bang for the buck?
I've no idea why both reducing and greatly increasing the queue sizes would help over the default settings. Sounds strange to me. Generally, I do like high queue sizes, as long as your CPU and GPU RAM can handle it. There shouldn't be much downside to high queue sizes, except maybe slower switching between windowed <-> fullscreen mode, and slower OSD reaction. But I suppose most people would find these problems of low importance compared to smooth and reliable video playback. So by all means, go crazy with the queue sizes etc. Just make sure you don't choose values which your CPU/GPU RAM can't handle, because doing that would slow things down dramatically.
mashi, I fully admit that I'm ignorant about this, and you might have already given an answer for this. Considering your experience with dedicated scalers (Lumagen, if I remember correctly from our Panasonic discussions for 1:1 pixel mappings), is Non Linear Stretch for 4:3 material something you might be considering for the future?
Personally, I consider NLS very ugly and damaging to the source. Especially horizontal camera pans look like you'd had taken drugs. So while I might add it at some point, it's very low priority.
nevcairiel
22nd October 2015, 10:59
Do you have any specific problems with v0.89.12? My impression from feedback so far is that it's working pretty well and stable.
So far it seems pretty good, indeed. Will have to keep an eye on it. :)
madshi
22nd October 2015, 11:16
So far it seems pretty good, indeed. Will have to keep an eye on it. :)
Glad to hear that!
FWIW, the later v0.89.x builds have several stability bug fixes in them, which e.g. v0.88.x/v0.87.x and older builds are lacking. E.g. I've been working with CiNcH on live TV playback stability when switching TV channels. He says the later v0.89.x builds are more stable with DVBViewer than any previous build ever was. So I'm hopeful about stability, especially considering that no further *invasive* changes are planned for the near future.
amire
22nd October 2015, 11:56
nnedi3 doesn't work on my system .freeze the image .need fix thx
huhn
22nd October 2015, 12:26
you didn't provide us any informations for what ever reason so here is may guess.
disable CUVID in lavfilter and try again.
CiNcH
22nd October 2015, 13:05
FWIW, the later v0.89.x builds have several stability bug fixes in them, which e.g. v0.88.x/v0.87.x and older builds are lacking. E.g. I've been working with CiNcH on live TV playback stability when switching TV channels. He says the later v0.89.x builds are more stable with DVBViewer than any previous build ever was.
The problems got pretty severe after 0.88.16 with the introduction of Stop/Pause rendering. DXVA errors, crashes, freezes... Last problems for me finally got fixed with 0.89.6. I am now taking every step and perform regression tests (I am not testing fancy stuff like NNEDI though ;) ). Currently on 0.89.12. Never experienced a problem anymore after our fixing session.
Only DX11 still doesn't work on my Intel HD 4000. It still has the ugly jumping back and forward. DX11 seems to work properly with the renderer inside KODI Jarvis though (which is of course far less complex).
Olivier C.
22nd October 2015, 13:16
should be a Vram issue with madVR. it looks like it tries to take more than 6 GB ram and is now using a ram page file which is terrible slow.
Yep, seems to be a GPU RAM size issue. When enabling linear light, I'm using 32bit floating point textures for some processing steps, which consume twice as much RAM as the default format. I'm a bit surprised GPU RAM size seems to more than double, though, that doesn't make a lot of sense, to be honest. Anyway, you can probably work around the issue by reducing the size of the GPU queue a bit.
Big thanks to you !
agustin9
22nd October 2015, 13:37
Which subtitle renderer? SRT, ASS or bitmap (PGS/SUP)? Screenshots and a sample would be nice.
With the latest XySubfilter beta, using SRT. It happens with every video and SRT I play, of course when moving the subtitles to the bottom of the window...
amire
22nd October 2015, 13:39
you didn't provide us any informations for what ever reason so here is may guess.
disable CUVID in lavfilter and try again.
thank you , it works .
SweetLow
22nd October 2015, 13:51
Only DX11 still doesn't work on my Intel HD 4000. It still has the ugly jumping back and forward.
Are the video sample exists? Since i use DX11 with HD4000 ;)
Francois76l
22nd October 2015, 14:42
Hi guys,
I really need your help in understanding the effect of some changes I have made in madVR that allowed me to have a smooth playback again after hours of fighting with a nasty stuttering. Sorry if this seems stupid but I just need to know whether I have finally found the magic solution or is just something circumstantial.
First let me list my rig and the initial settings:
- Intel NUC D34010WYKH, intel Core I3 4010U (r (1.7 GHz Dual-Core processor with 3 MB smart cache), Intel HD 4400 GPU, Crucial 2x4GB = 8GB DDR3 1600MHz, 60GB OCZ Agility SSD
- LAVFIlters: DXVA Copy-Back
- madVR:
* chroma-up: BCB75AR
* image-up: DXVA
* image doubling: None
* image-down: DXVA
* enable fullscreen exclusive mode
* dithering: ordered
* smooth motion: off
- SVP: default 1g profile, 59.94Hz
- TV; Sony KDL26EX320, 60Hz, 1366x768
- ReClock: WASAPI exclusive Asus Xonar U3, 24 bit padded into 32, resolution of 59.94 input manually first time the video plays
- movies: Blu-Rays: 1920x1080 / 800, 23,976fps, DVDs: 720x576, 25,000fps (PAL) , Samsung S4: 1920x1080, 29,911fps.
With the above settings and everything else left as default in madVR I had a terrible stuttering even if madVR stats showed 1 frame drop every 6-7 hours. Please see print screen below:
http://i.imgur.com/2h3fKyP.jpg
But then I have just spotted that my "present queue" was showing 5-7/8 instead of 7-8/8 so I decided to drop the frames presented in advance from 8 to 4 in fullscreen mode and from 8 to 3 in windowed mode. Also in the tab trade quality for performance I've checked the first 4 options up to "store custom pixel shader ..." ... and voila my "present queue" was now 2-3/3 (windowed) and 3-4/4 (fullscreen) and the stutter was almost non percievable. Then I remember an article on Anandtech where they tested the NUC (the Core I5 version) with madVR and used "CPU and GPU queue sizes of 128 and 24". I said why not try, did that and no more stutter visible, madVR shows 1 drop frame every 1.02 days and SVP performance graphs show CPU average at 67% with 1g profile. Indeed the guys at Anandtech also increased the frames presented in advance to 16 ... and this is where I'm a bit lost. They have practically maxed everything.
http://www.anandtech.com/show/7566/intels-haswell-nuc-d54250wyk-ucff-pc-review/5
Can you please tell me in which way did my PC benefited from the above and whether maxing out CPU and GPU queues size is a right thing to do in my case? Are there any other settings that would give me a better bang for the buck?
Hello ionutm80,
something is strange with your reclock parametrization.
Try to select "Automatic" instead of "59.940" fps.
Your video is running @ 23.976Hz, not 59.940Hz.
http://img11.hostingpics.net/pics/5322452h3fKyP.jpg
ionutm80
22nd October 2015, 15:04
@Francois76l
Hi, indeed is what I have inputed manually in ReClock because I'm using SVP which takes my 23,976 movie and interpolate frames up to 59.94 (23,976*5 /2) and hence ReClock should just marginally adjust vs my display resolution.
huhn
22nd October 2015, 15:05
nothing is strange he is using SVP so the source frame rate is not the same as the input frame rate.
Francois76l
22nd October 2015, 15:53
oups yes, you're right!...
:)
jmonier
22nd October 2015, 16:29
That's quite interesting! Let's look at the possible scenario cases one by one and let me ask a few questions for clarification:
1) projector is turned on by rs232
How is this possible?? At least my JVC X35 has a setup menu option to either use rs232 or ip control - I have to choose! Does your projector not have such a menu option? If it does have such an option, have you set it to rs232 or ip control?
No menu option at all. Both RS232 and TCPIP are available at all times
Does your own ip control software work if you turned the projector on via rs232, while my ip control test tool fails?
It would take quite a bit of coding for me to set up to test this so I'd like to defer it for the moment.
2) projector is turned on by your ip control software
In this situation my ip control test tool fails, too?
Yes (as I said).
Does your own ip control software manage to switch lens memories or stuff in this situation, while my test tool fails?
Yes (as I said).
3) projector is turned on physically (remote or project power switch)
In this situation my ip control test tool works perfectly?
Yes (as I said).
4) projector is turned on by my ip control test tool
What happens in this case? Does my test tool work? Does your ip control software work?
This is where the result was not as I expected it. Both of them DO work interchangeably for this case.
Could it be that your software turns on the JVC in a different way than I do? Do you do the full handshaking (PJ_OK/PJREQ/PJACK)?
BUT, the automated operation is still as before, i.e. VERY intermittent, so it's starting to appear that there's something totally different at work in that case and all the above is just a red herring.
JarrettH
22nd October 2015, 16:37
The test patterns currently only support 32bit media players.
Could I just as well test using a video? I've done this before - looking for the dither noise to vanish. Does it need to be in motion?
Shiandow
22nd October 2015, 16:43
The difference doesn't seem so dramatic to me. But yes, there is a difference. But look at the roof ceiling line of the left most building. The line is noticably fatter in the linear light image. Once again, as I said before, ideally linear light should be enabled if the source was downscaled in linear light, or if it wasn't downscaled at all. But if the source was downscaled in gamma light from a higher resolution master, then disabling linear light should produce results that are nearer to the original master.
I'm aware of that it's pretty hard to say when linear light should be enabled and when not. So maybe I should remove the option. But which option should I set it to then? Especially with Anime content the difference between linear light and gamma light can be *huge*. Black lines are very noticably fatter when using linear light.
As far as I can tell the only reason gamma light seems to thin black lines is that it makes the image lighter. Admittedly this can look nice for Anime, but it will make white lines look too fat. It's hard too say which is better, but I think using linear light will give a more consistent result. If for example you draw a black line and white line of equal thickness and scale them with SuperRes then I suspect that they will still have equal thickness with linear light but different thickness when you use gamma light, maybe somebody could try this out?
Anima123
22nd October 2015, 19:49
Only DX11 still doesn't work on my Intel HD 4000. It still has the ugly jumping back and forward. DX11 seems to work properly with the renderer inside KODI Jarvis though (which is of course far less complex).
That happened when GPU is not powerful enough while 'present a frame for every VSync' enabled.
You can try disabling the option and the jumping back and forward would have gone.
aufkrawall
22nd October 2015, 21:12
The difference doesn't seem so dramatic to me.
That may be because the brightness already has increased for some structures by using SuperRes, despite of LL on or off (yeah, sorry, I didn't post a picture without SR).
LL off gives some increase on top of that. But the increase by SuperRes with LL may be "wanted", e.g. also NNEDI3 256 looks brighter than bilinear in this case.
I'm aware of that it's pretty hard to say when linear light should be enabled and when not. So maybe I should remove the option. But which option should I set it to then? Especially with Anime content the difference between linear light and gamma light can be *huge*. Black lines are very noticably fatter when using linear light.
Well, you know that I'd like to avoid that artifical sharpened look that comes with unwanted brightness increase.
I'm not sure if anyone would ever notice that LL thickens dark lines without a direct comparison. This gets worse when increasing the sharpness, but with a sharpness of 2, I think it's not critical.
No chances that a solution can be found which doesn't increase brightness and doesn't boost dark lines at the same time?
Magik Mark
22nd October 2015, 21:47
@Francois76l
Hi, indeed is what I have inputed manually in ReClock because I'm using SVP which takes my 23,976 movie and interpolate frames up to 59.94 (23,976*5 /2) and hence ReClock should just marginally adjust vs my display resolution.
Can u try 29.97. It's a multiple of 59.94. Your cpu by the way may not be powerful enough
Raimu
22nd October 2015, 21:57
Madshi, your speculative fixes for the out-of-order frame flickering have completely eliminated the problem for me when using DX9 new windowed.
It kept happening so much on my PC it completely made the mode unusable. It's completely gone now. Thank you.
madshi
22nd October 2015, 22:15
Currently on 0.89.12. Never experienced a problem anymore after our fixing session.
:)
Only DX11 still doesn't work on my Intel HD 4000. It still has the ugly jumping back and forward. DX11 seems to work properly with the renderer inside KODI Jarvis though (which is of course far less complex).
Yeah, this is being reported by several Intel users. Unfortunately my HD4000 doesn't show this problem, for some weird reason. Might depend on the OS and GPU driver, I'm not sure. I'll probably get an Intel laptop sooner or later and hope to be able to reproduce the problem then.
Kodi Jarvis does everything in DX11, I believe, with no trace of DX9 left. madVR instead still renders most stuff in DX9, just shares the final rendering result with a DX11 device for presentation. I believe this sharing, and maybe the combination with presenting many frames in advance is responsible somehow for this back & forth jumping.
Anyway, you don't lose much by staying with DX9, and DX9 is active by default, so it's not a show stopper, IMHO.
With the latest XySubfilter beta, using SRT. It happens with every video and SRT I play, of course when moving the subtitles to the bottom of the window...
At least some screenshots would be nice, so that I could see what you're talking about.
No menu option at all. Both RS232 and TCPIP are available at all times
Interesting, they must have changed this in the X500+ series.
Yes (as I said).
Yes (as I said).
Yes (as I said).
Yeah yeah. Clarification questions to make sure I understood everything correctly have never harmed yet. It's better to ask one time too much than to draw conclusions based on a misunderstanding.
This is where the result was not as I expected it. Both of them DO work interchangeably for this case.
Could it be that your software turns on the JVC in a different way than I do? Do you do the full handshaking (PJ_OK/PJREQ/PJACK)?
I've very carefully implemented the network protocol according to specification, of course with full handshake and stuff. I've also had this all tested by an X500 user and he had no problems at all.
I'm sending 0x21 0x89 0x01 0x50 0x57 0x31 0x0A (after handshake) to turn the projector on. Do you send something different?
After you've sent your power on command, do you wait for a reply from the projector? (You should.)
BUT, the automated operation is still as before, i.e. VERY intermittent, so it's starting to appear that there's something totally different at work in that case and all the above is just a red herring.
Well, as I said, a logic bug could be involved, too. Can you confirm (once more) that my test tool works perfectly and 100% reliable (!!) if you turn your projector on via remote? And at the same time madVR does *not* work correctly under the same circumstances? If you can confirm that, I'll spend some time to add logging to madVR, so we can see what madVR tried to do (and why), and whether it succeeded or not. Don't want to invest that time before getting 100% confirmation about the test tool working perfectly. Because if the test tool doesn't work perfectly reliable, either, then it's hard to be sure where a specific problem comes from, and logging would not help.
Could I just as well test using a video? I've done this before - looking for the dither noise to vanish. Does it need to be in motion?
I don't fully understand what you mean.
As far as I can tell the only reason gamma light seems to thin black lines is that it makes the image lighter. Admittedly this can look nice for Anime, but it will make white lines look too fat. It's hard too say which is better, but I think using linear light will give a more consistent result. If for example you draw a black line and white line of equal thickness and scale them with SuperRes then I suspect that they will still have equal thickness with linear light but different thickness when you use gamma light, maybe somebody could try this out?
No chances that a solution can be found which doesn't increase brightness and doesn't boost dark lines at the same time?
Maybe we'll need to experiment a little. Doing some more tests to find out whether there are situations where using gamma light is more faithful. E.g. one good test would be to downscale one big ground truth image to 50% by using (a) gamma light and (b) linear light, and then scaling both up again, then applying SuperRes on top. I suppose the image (a) should look better with SuperRes in gamma light, while (b) should look better with SuperRes in linear light. But I might be wrong. Maybe SuperRes linear light will look more faithful to the ground truth in both cases? That would be worth a check...
madshi
22nd October 2015, 22:18
Madshi, your speculative fixes for the out-of-order frame flickering have completely eliminated the problem for me when using DX9 new windowed.
It kept happening so much on my PC it completely made the mode unusable. It's completely gone now. Thank you.
Wow, that's good to hear! :)
aufkrawall
22nd October 2015, 22:54
Maybe we'll need to experiment a little. Doing some more tests to find out whether there are situations where using gamma light is more faithful. E.g. one good test would be to downscale one big ground truth image to 50% by using (a) gamma light and (b) linear light, and then scaling both up again, then applying SuperRes on top. I suppose the image (a) should look better with SuperRes in gamma light, while (b) should look better with SuperRes in linear light. But I might be wrong. Maybe SuperRes linear light will look more faithful to the ground truth in both cases? That would be worth a check...
I did a quick search and found this image:
http://www.shaderhacker.com/wp-content/uploads/2015/01/DyingLightGame-2015-01-29-22-08-39-58.png
It looks extremely different when linear light downscaling is used or not.
DigitalLF
22nd October 2015, 22:59
Ooops, good catch! Here's a fixed madHcCtrl.exe for you:
http://madshi.net/madHcCtrlSony.rar
Does that fix the problem for you? It might also make lens memories work for your Sony.
yes it does! thank you! :)
AR is often not *exactly* one of those numbers. E.g. imagine a Cinemascope Blu-Rays with 1920x796 active pixels. That's an AR of 2.4120603015075376884422110552764. You can't write the script in such a way to handle every possible AR. So instead of using "if AR = something" use "if AR > something". So your script could read:
if (AR > 1.9) "2.40:1" else
if (AR > 1.8) "1.85:1" else "1.77:1"
That said, do you really need different profiles for 1.85:1 and 1.77:1? Your call, though. Personally, with my CIH setup I just have 2 profiles, one for Cinemascope movies, and one for every other AR. So I'm just using "if (AR > 1.9) "21:9" else "16:9"".
Thank you for this! Oh and i meant 1.78:1! Sorry! But it is nice to have one for 1.85:1 at least for me! But thank you for the help with my problems regarding this and scripting! This and the possibility to move subtitles is the best things about MadVR if you don't count the picture aspect!
Only thing missing now would be to be able to move the search bar and OSD into active picture area! and "Go back to 16:9 on exit".
You MadShi are one crazy skilled person and i really want to thank you for all work you have done for all of us! it really means a LOT!!!
I still have one problem that i have a work around for but it would be nice if the problem was not there!
When i start a movie and go into fullscreen mode and exit fullscreen back to window mode and then try to go back into fullscreen mode again the movie plays very wierdly ut stutters until i reopen in the same file in MPC-HC BE is it MadVR or a MPC-HC BE related?
jmonier
23rd October 2015, 00:17
I've very carefully implemented the network protocol according to specification, of course with full handshake and stuff. I've also had this all tested by an X500 user and he had no problems at all.
I'm sending 0x21 0x89 0x01 0x50 0x57 0x31 0x0A (after handshake) to turn the projector on. Do you send something different?
That's exactly what I send
After you've sent your power on command, do you wait for a reply from the projector? (You should.)
My software ALWAYS waits for an acknowledgement before sending the next command in the queue.
Well, as I said, a logic bug could be involved, too. Can you confirm (once more) that my test tool works perfectly and 100% reliable (!!) if you turn your projector on via remote? And at the same time madVR does *not* work correctly under the same circumstances? If you can confirm that, I'll spend some time to add logging to madVR, so we can see what madVR tried to do (and why), and whether it succeeded or not. Don't want to invest that time before getting 100% confirmation about the test tool working perfectly. Because if the test tool doesn't work perfectly reliable, either, then it's hard to be sure where a specific problem comes from, and logging would not help.
Here's what I did:
Shut down everything and unplugged the JVC to reset it. Shut down my control program completely.
Started up everything locally starting with the projector then Denon and finally computer.
Started Zoomplayer (via mouse) then used the keyboard to start a 2.39 video playing. Auto zoom did NOT work and no pause. (At this point madVr should have been the only thing controlling the JVC via TCPIP or RS232 since it was plugged in).
Tried your test program at this point and it did NOT work (reported "emergency" for power state).
Shut down computer, it still did not work.
Shut down Denon and the test program started working.
Powered up Denon and computer, test program still working.
Started up Zoomplayer to the point where the next keystroke would start the video, test program still working.
Started the video, auto zoom did NOT work and no pause.
The test program was still working after this.
Are you confused? I certainly am.
I'd already written a JVC simulator that works 100% with your test tool. It is not connected to the projector, but it does report power on correctly. I've then run my system normally with madVR pointed to the simulator.
What happens is this:
I play a video that should activate a different lens memory so I can be sure that madVR should do something.
The first time I play the video, madVR sends a Power Inquiry (PW) followed by INML2. It also pauses the video, but it never comes out of pause. Is it expecting any response other than an acknowledgement of each command and a Power On response from the inquiry?
If I then stop playback and then restart it, it does nothing (no pause, no PW, no INML2). If I close the player and then restart it, it will work as above once (but only once).
It seems from this that it's expecting some other response that the test tool doesn't check for.
I'm wondering if the only way this will work reliably is if I get the simulator to work correctly with madVR and then use it as an interface between madVR and my JVC control program. What do you think?
agustin9
23rd October 2015, 00:48
At least some screenshots would be nice, so that I could see what you're talking about.
Ok, here they are...
xysubfilter - 0 bottom margin:
http://oi60.tinypic.com/34yw5fd.jpg
internal mpc - 0 bottom margin:
http://oi58.tinypic.com/1530hu1.jpg
xysubfilter - 20 bottom margin:
http://oi61.tinypic.com/av1ua.jpg
internal mpc - 20 bottom margin:
http://oi60.tinypic.com/2mfdj6d.jpg
xysubfilter - 60 bottom margin:
http://oi61.tinypic.com/a9ts1g.jpg
internal mpc - 60 bottom margin:
http://oi59.tinypic.com/2ekj3n9.jpg
On xysubfilter is always at the same position, I even tried some high numbers like 150...
6233638
23rd October 2015, 01:38
When switching from D3D11 windowed to 10-bit FSE mode, I just had a video start flickering frames back-and-forth, which I think is the first time I've seen that happen on Windows 8.1 - at least in recent memory.
Smooth Motion was not on, as the video was 30 fps at 60Hz.
So whatever changed recently does not seem to have fixed it and may in fact have caused this issue to appear on my system.
If nothing else, I can say that it is infrequent as this is the first time that I've seen it happen so far.
I actually have had a number of issues when switching between FSW and FSE modes ever since D3D11 was introduced, which I think I mentioned at the time (black screens, frames dropping until I do another switch between FSW/FSE, exclusive mode failing) but have not had the time to fully investigate them as I have been unable to reliably reproduce any of them.
nijiko
23rd October 2015, 06:58
The problems got pretty severe after 0.88.16 with the introduction of Stop/Pause rendering. DXVA errors, crashes, freezes...
Me too, when use DXVA, pausing or resizing may cause black screen or red screen for a while (a few frame). But it doesn't affect using.
CiNcH
23rd October 2015, 07:56
Yeah, this is being reported by several Intel users. Unfortunately my HD4000 doesn't show this problem, for some weird reason. Might depend on the OS and GPU driver, I'm not sure. I'll probably get an Intel laptop sooner or later and hope to be able to reproduce the problem then.
I am still using Windows 7 (32-Bit) on my TV PC to prevent potential driver issues. Intel GPU drivers I tried several. Currently I am on the latest official one.
I might move to Windows 10 soon though.
dansrfe
23rd October 2015, 08:04
I'm confused by the bar chart comparison between super-xbr and NNEDI3 for chroma upscaling.
It seems as if super-xbr is superior in all parameters and faster compared to NNEDI3. Is this true? Are there other parameters which influence the quality of scaling which are not shown in the chart?
madshi
23rd October 2015, 08:27
I did a quick search and found this image:
http://www.shaderhacker.com/wp-content/uploads/2015/01/DyingLightGame-2015-01-29-22-08-39-58.png
It looks extremely different when linear light downscaling is used or not.
Looks somewhat psychedelic. Might be a test candidate, but I think it would be better to use a screenshot from Mononoke or some other Anime Blu-Ray. And then in addition to that some image where there are also white lines.
Only thing missing now would be to be able to move the search bar and OSD into active picture area!
It's already there! Check the option "move OSD into active video area" in the screen config page. It affects the madVR fullscreen exclusive mode seekbar, and *tries* to move other OSD elements, too. But depending on which media player you're using, it may or may not affect the media player's OSD. If your media player's OSD does not react to this option, please complain to the media player devs. I've written a PDF for them that explains how they can make it work:
http://madshi.net/89notesForDevs.pdf
and "Go back to 16:9 on exit".
Maybe later.
When i start a movie and go into fullscreen mode and exit fullscreen back to window mode and then try to go back into fullscreen mode again the movie plays very wierdly ut stutters until i reopen in the same file in MPC-HC BE is it MadVR or a MPC-HC BE related?
Please create a debug log for this problem. For the debug log, please reproduce this problem, then let it stutter for 20 seconds, then close the media player immediately (Alt+F4) without switching to windowed mode again, or doing anything else.
Here's what I did:
Shut down everything and unplugged the JVC to reset it. Shut down my control program completely.
Started up everything locally starting with the projector then Denon and finally computer.
Started Zoomplayer (via mouse) then used the keyboard to start a 2.39 video playing. Auto zoom did NOT work and no pause. (At this point madVr should have been the only thing controlling the JVC via TCPIP or RS232 since it was plugged in).
Tried your test program at this point and it did NOT work (reported "emergency" for power state).
Shut down computer, it still did not work.
Shut down Denon and the test program started working.
Powered up Denon and computer, test program still working.
Started up Zoomplayer to the point where the next keystroke would start the video, test program still working.
Started the video, auto zoom did NOT work and no pause.
The test program was still working after this.
Are you confused? I certainly am.
I'd already written a JVC simulator that works 100% with your test tool. It is not connected to the projector, but it does report power on correctly. I've then run my system normally with madVR pointed to the simulator.
What happens is this:
I play a video that should activate a different lens memory so I can be sure that madVR should do something.
The first time I play the video, madVR sends a Power Inquiry (PW) followed by INML2. It also pauses the video, but it never comes out of pause. Is it expecting any response other than an acknowledgement of each command and a Power On response from the inquiry?
If I then stop playback and then restart it, it does nothing (no pause, no PW, no INML2). If I close the player and then restart it, it will work as above once (but only once).
It seems from this that it's expecting some other response that the test tool doesn't check for.
I'm wondering if the only way this will work reliably is if I get the simulator to work correctly with madVR and then use it as an interface between madVR and my JVC control program. What do you think?
Thanks!
Writing a simulator sounds like a lot of work. And it would only make it work for you, but not for other X500 users. Still wondering why the other X500 user had no problems at all, though.
Anyway, wouldn't it make more sense to use a network sniffer like e.g. WireShark to compare how our two tools differ? E.g. in the situation in which my tool doesn't work, you could capture my network traffic, and yours. There should be a noticable difference then.
Or we could also exchange source code for the ip config stuff. Maybe you can see something wrong in my code, or I can see something I've missed in your code?
My tool does wait for a reply when changing lens memories. With my X35 this reply comes with many seconds delay, exactly when the activation of the lens memory has completed. This is very nice because it tells me exactly when the lens memory activation has completed. I'm using that to pause and resume video playback at exactly the right times. Works perfectly here. I suppose maybe the X500 behaves differently there? Would be strange, though, the network protocol is pretty clear about what should be sent by either side...
Ok, here they are...
On xysubfilter is always at the same position, I even tried some high numbers like 150...
Ah, thanks, I see what you mean!
The bottom margin option is a private subtitle renderer value which madVR doesn't know about. But the moving of the subtitles is done by madVR, so madVR doesn't use that "bottom margin" option because it doesn't even know it exists, or which value it's set to.
Are you not happy with madVR's positioning? Looking at your screenshots, I think the madVR position is by far the best one. Do you find it too high or too low?
When switching from D3D11 windowed to 10-bit FSE mode, I just had a video start flickering frames back-and-forth, which I think is the first time I've seen that happen on Windows 8.1 - at least in recent memory.
Smooth Motion was not on, as the video was 30 fps at 60Hz.
So whatever changed recently does not seem to have fixed it and may in fact have caused this issue to appear on my system.
If nothing else, I can say that it is infrequent as this is the first time that I've seen it happen so far.
I actually have had a number of issues when switching between FSW and FSE modes ever since D3D11 was introduced, which I think I mentioned at the time (black screens, frames dropping until I do another switch between FSW/FSE, exclusive mode failing) but have not had the time to fully investigate them as I have been unable to reliably reproduce any of them.
If you find a way to reliably reproduce this issue, please let me know.
madshi
23rd October 2015, 08:32
I am still using Windows 7 (32-Bit) on my TV PC to prevent potential driver issues. Intel GPU drivers I tried several. Currently I am on the latest official one.
I might move to Windows 10 soon though.
I'll try the latest driver, maybe I can reproduce it then. I will probably move my dev PC to Windows 10 sooner or later, too.
I'm confused by the bar chart comparison between super-xbr and NNEDI3 for chroma upscaling.
It seems as if super-xbr is superior in all parameters and faster compared to NNEDI3. Is this true? Are there other parameters which influence the quality of scaling which are not shown in the chart?
The size of the "ringing" bar is probably misleading. The difference in ringing is bigger than that bar suggests. Also NNEDI3 produces rather nice thin lines, while super-xbr produces thicker lines, which is not visible in any of the bars. Overall I consider NNEDI3 superior in image quality. Mainly due to lower ringing and producing thinner lines.
ionutm80
23rd October 2015, 09:36
Yeah, this is being reported by several Intel users. Unfortunately my HD4000 doesn't show this problem, for some weird reason. Might depend on the OS and GPU driver, I'm not sure. I'll probably get an Intel laptop sooner or later and hope to be able to reproduce the problem then.
Hi Madshi, can you share with us what are your settings for HD4000 or point me to a thread where you already did that? :)
Thanks a lot in advance.
CiNcH
23rd October 2015, 10:47
I'll try the latest driver, maybe I can reproduce it then. I will probably move my dev PC to Windows 10 sooner or later, too.
I also still have the problem with way higher GPU usage compared to EVR when purely using DXVA and other enhancements disabled (dithering a.s.o.). So something is for sure different.
Do you have Windows 7 on that machine or Windows 8/8.1?
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.