View Full Version : madVR - high quality video renderer (GPU assisted)
madshi
23rd October 2015, 10:51
Hi Madshi, can you share with us what are your settings for HD4000 or point me to a thread where you already did that? :)
I don't have any specific settings for HD4000. I'm changing settings all the time, depending on what problems users are reporting.
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?
Windows 8.1 x64. Do you have the Windows 7 Platform Update installed?
CiNcH
23rd October 2015, 10:59
Windows 8.1 x64. Do you have the Windows 7 Platform Update installed?
I don't even know what it is. But I will do some research on it ;) . I think the Windows version is indeed the key to all that.
madshi
23rd October 2015, 11:07
Yep, I also think the OS is key, although I've seen some Windows 7 users report same GPU consumption as EVR, while others have much higher GPU consumption when using madVR. But so far all reports from Windows 8.1 users seem to indicate similar GPU usage to EVR.
ionutm80
23rd October 2015, 11:15
@madshi
But from your testing so far what would be the best bang for buck with this Intel iGPUs (especially Ivy HD4000, Haswell HD44000 - seems similar in performance though after reading several tests on the net)? For the moment I have the following:
- DXVA Copy-Back in LAV Video
- debanding: off
- image enhancements: none
- Chroma: Bicubic 75 AR (although in "trade quality for performance" I have also checked "use DXVA chroma upscaling ...")
- Image Up: DXVA
- Luma Doubling: None
- Image Down: DXVA
- general settings: enable automatic fullscreen mode, use a separate device for presentation checked
- queues size: default (16 CPU, 8 GPU)
- windowed mode: 3 frames presented in advance
- exclusive mode: 4 frames presented in advance
- smooth motion: off
- dithering: none (ordered dithering set in LAV Decoder)
- trade quality for performance: first 6 options checked up to "don't analyze gradient angles for debanding"
OS: Win 10
Target: 1920x1080, 23,976 Blu-Ray rips and 720x576, 25,000 DVD rips
Thanks a lot for your time and apologize in advance for insisting.
SweetLow
23rd October 2015, 12:12
Yep, I also think the OS is key, although I've seen some Windows 7 users report same GPU consumption as EVR, while others have much higher GPU consumption when using madVR.
Win 7 x86+HD2500 / Win 7 x64+HD4000 - with completely disabled madVR processing results of madVR vs EVR in FS are nearly equal. More to say, on first system with DX11 FS Exclusive madVR consumption is lower then EVR FS (21% vs 25% for example). But in window mode the things are different :)
P.S. One near question - can we have different paths in FS Exclusive vs other modes? For example DX11 in FS Exclusive and DX9+overlay in other?
aufkrawall
23rd October 2015, 12:33
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.
This one is nasty:
http://image1.masterfile.com/getImage/618-01245035em-Wave-of-black-and-white-lines.jpg
I think it's clear that gamma correct boosts white lines and linear light black ones (not high enough resolution for a ground truth comparison, unfortunately).
Those low-res line pictures also show strong differences when changing the radius. When upscaling the images with NNEDI3, it seems to filter away the aliasing, which SuperRes of course reintroduces. Now question is, is a radius of 0.66 closest to the source in terms of aliasing?
I could imagine that a less aliased look is mostly preferred, so probably a higher radius would be better as a default setting (e.g. 0.75 or 0.8).
Are averaged calculations not possible? As a layman, I'd assume that the average brightness of linear light and gamma correct would be closest to the source.
That game screenshot from above shows crucial differences with LL on and off downscaling, so probably both are far off the original brightness.
nevcairiel
23rd October 2015, 13:03
Are averaged calculations not possible? As a layman, I'd assume that the average brightness of linear light and gamma correct would be closest to the source.
That game screenshot from above shows crucial differences with LL on and off downscaling, so probably both are far off the original brightness.
Linear Light practically just means using Gamma 1.0. I suppose its theoretically possible to try to do it at some intermediate Gamma value between 1.0 and 2.2/2.4 or whatever Gamma your video currently has, however if that yields the results you want is another question entirely.
chros
23rd October 2015, 13:15
I'll probably get an Intel laptop sooner or later and hope to be able to reproduce the problem then.
Probably you (and I) have to wait for the next gen intel chipsets and cpus and nvidia gpus to support 10 bit output and proper 4k hevc acceleration (next summer or even later).
what would be the best bang for buck with this Intel iGPUs (especially Ivy HD4000, Haswell HD44000 - seems similar in performance though after reading several tests on the net)?
- general settings: enable automatic fullscreen mode, use a separate device for presentation checked
- queues size: default (16 CPU, 8 GPU)
- windowed mode: 3 frames presented in advance
- exclusive mode: 4 frames presented in advance
Have you tried out FSE old path yet? For me it's way faster then the rest of the mode. You have to uncheck 'present frames in advance' checkbox for that. (and you can check whether it's working by reading the top rows of the OSD).
Ruya
23rd October 2015, 13:24
I installed the platform update, but it's still using D3D9 Exclusive and not D3D11.
Do I HAVE to have Aero enabled, even for Full-Screen Exclusive mode? I prefer to use classic themes and have all of the aero stuff disabled.
I tried enabling Desktop Composition (and the DWM service) but it still presented with D3D9. I can't enable the actual Aero themes themselves because I removed them from this install of Windows with NTLite.
"Present several frames in advance" is checked.
**EDIT**
Yeah, it seems to be an issue with my configuration/DWM not being available. I've reverted to 0.88.1 for the time being and D3D11 is working perfectly now.
ionutm80
23rd October 2015, 13:31
Have you tried out FSE old path yet? For me it's way faster then the rest of the mode. You have to uncheck 'present frames in advance' checkbox for that. (and you can check whether it's working by reading the top rows of the OSD).
Damn, I've never thought about that ...I'll try tonight and revert with feedback. What I did noticed is that lowering the frames from 8 to 3/4 it improved playback.
omarank
23rd October 2015, 13:53
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.
If you used 32 bit floating point textures throughout the processing chain, would that affect performance much besides higher RAM usage?
jmonier
23rd October 2015, 17:58
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.
Actually, it turned out to be quite easy, although what I've written so far only simulates the parts that are liable to be accessed by your test tool and by madVR. It's only about 50 lines of code.
I agree, though, that it's not very good as a general solution. If it really became necessary, perhaps a simpler TCPIP interface could be defined.
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.
I didn't think of that (since I don't normally deal with network problems). I'm looking at WireShark and I'll try to use it to investigate the problem further.
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?
I was actually going to suggest this. My code is written in Lua and runs under Girder. It's complex enough that even I have to take some time to get up to speed when I've been away from it for a while. So, it may or may not be useful to you to look at it. I do want to limit the distribution of my code to relatively sophisticated users simply because I don't have time to answer questions from others.
That said,if you still want to do this, let me know how we can do it.
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...
This I don't understand. My understanding of the protocol is that the only non-ACK responses that it sends are in response to a reference command, i.e. it NEVER sends an un-solicited response (or a response to an operation command other than an ACK response). My understanding is also that the ACK response ONLY indicates successful reception of the command and NEVER successful completion of the command. In addition, the INML command is specifically listed as NOT having a reference form. (And, in any case, I don't see you sending anything but the operation form.)
This is consistent with what I found with my old RS50 (although it didn't have lens memory).
So let me know exactly what you do here and I'll see whether or not it works with the RS4910.
EDIT: I upgraded my JVC simulator and ran another test. (Remember that madVR is only talking to the simulator and not to the JVC.) Here's what happened:
The first time a video is played madVR pauses the video, sends ? PW, receives 'power on", closes the socket, sends ! INML2, closes the socket. The video remains paused until I take action. If I restart the video, madVR does nothing, the video plays normally. If I end Zoomplayer and restart it, the above sequence is repeated.
So, it really looks like madVR is expecting an additional response and I have no idea what that might be. I can find nothing about it in any of the specs that I have access to including that for the x30 and the one for my JVC. This may not be the primary problem, since my JVC (mostly) doesn't respond to the INML2 command at all, but I need to know for further troubleshooting (and I definitely need it in the event that I have to use my simulator as a proxy to make it work).
Magik Mark
23rd October 2015, 19:45
Linear Light practically just means using Gamma 1.0. I suppose its theoretically possible to try to do it at some intermediate Gamma value between 1.0 and 2.2/2.4 or whatever Gamma your video currently has, however if that yields the results you want is another question entirely.
In ISF world, 2.2 is the average value. I think this should be upheld. No wonder image is a little bit dim after some upscaling / downscaling or dithering (Error Diffusion 1)
Sunset1982
23rd October 2015, 22:36
Today my mpc-hc/madvr suddenly always crashes when starting a movie mkv file. After trying a lot I reinstalled my system. Gone from win 8.1 to win10.But the problem still exists even after fresh windows 10 installation.
Tried even more settings and now I find out, that its the DX11 rendering path in madvr what crahes my player. if I deselect it, movie plays fine.
never had problems before. Happens with latest MPC-HC 1.7.9, madvr 0.89.12 and LAV 0.66.0. I also tried 0.89.11 and 0.89.10. Both crashed too.
Was there an windows platform update or something like that which broke my DX 11? Cause I havent updated anything the last days and 2 days ago everything worked fine...
How can I create a crashlog with mpc-hc and madvr?
ryrynz
23rd October 2015, 23:00
Was there an windows platform update or something like that which broke my DX 11? Cause I havent updated anything the last days and 2 days ago everything worked fine...
Perform a system restore and find out.
clsid
23rd October 2015, 23:48
Try with the latest nightly build of MPC-HC. It should show a crash report window.
https://nightly.mpc-hc.org/
ajp_anton
24th October 2015, 01:15
Because both are very well known. Also Bicubic 50 is just one of several Bicubic options. I could remove Bicubic 50, but then it wouldn't make the settings dialog any simpler. I could remove Catmull-Rom, but it's a name everybody knows.You could put Catmull into the dropdown menu, like "sharpness: 50 (Catmull-Rom)" ?
Isn't Mitchell-Netravali also just one kind of bicubic? What's the relation between sharpness (and softness in softcubic) and the Avisynth b&c parameters?
Another question:
I get this for a 1280x718 video. What does the first line mean? All black bar stuff is disabled.
http://i.imgur.com/e3GYP8K.png
madshi
24th October 2015, 01:37
Win 7 x86+HD2500 / Win 7 x64+HD4000 - with completely disabled madVR processing results of madVR vs EVR in FS are nearly equal. More to say, on first system with DX11 FS Exclusive madVR consumption is lower then EVR FS (21% vs 25% for example).
Same here. But some users (like CiNcH) have different results, for some reason that I don't understand.
P.S. One near question - can we have different paths in FS Exclusive vs other modes? For example DX11 in FS Exclusive and DX9+overlay in other?
Technically possible, but it would make my code even more complicated and more difficult to maintain than it already is. So not very attractive for me.
This one is nasty:
http://image1.masterfile.com/getImage/618-01245035em-Wave-of-black-and-white-lines.jpg
I think it's clear that gamma correct boosts white lines and linear light black ones (not high enough resolution for a ground truth comparison, unfortunately).
Those low-res line pictures also show strong differences when changing the radius. When upscaling the images with NNEDI3, it seems to filter away the aliasing, which SuperRes of course reintroduces. Now question is, is a radius of 0.66 closest to the source in terms of aliasing?
I could imagine that a less aliased look is mostly preferred, so probably a higher radius would be better as a default setting (e.g. 0.75 or 0.8).
I can't access this image. I'm getting "Referral Denied". Do you have a working link?
Yeah, it seems to be an issue with my configuration/DWM not being available. I've reverted to 0.88.1 for the time being and D3D11 is working perfectly now.
If v0.88.1 can do D3D11, then v0.89.12 should be able to, too. So I'm not sure what's going on there.
If you used 32 bit floating point textures throughout the processing chain, would that affect performance much besides higher RAM usage?
It's not used throughout the processing chain, but only for those processing steps which need it. It does affect performance a bit, more on older GPUs than on newer GPUs, of course.
Today my mpc-hc/madvr suddenly always crashes when starting a movie mkv file. After trying a lot I reinstalled my system. Gone from win 8.1 to win10.But the problem still exists even after fresh windows 10 installation.
Tried even more settings and now I find out, that its the DX11 rendering path in madvr what crahes my player. if I deselect it, movie plays fine.
You could try reinstalling the GPU drivers or installing a different version. Not sure what else it could be.
I didn't think of that (since I don't normally deal with network problems). I'm looking at WireShark and I'll try to use it to investigate the problem further.
Great - thanks!
I was actually going to suggest this. My code is written in Lua and runs under Girder. It's complex enough that even I have to take some time to get up to speed when I've been away from it for a while. So, it may or may not be useful to you to look at it. I do want to limit the distribution of my code to relatively sophisticated users simply because I don't have time to answer questions from others.
That said,if you still want to do this, let me know how we can do it.
Please contact me at madshi (at) gmail (dot) com.
This I don't understand. My understanding of the protocol is that the only non-ACK responses that it sends are in response to a reference command, i.e. it NEVER sends an un-solicited response (or a response to an operation command other than an ACK response). My understanding is also that the ACK response ONLY indicates successful reception of the command and NEVER successful completion of the command. In addition, the INML command is specifically listed as NOT having a reference form. (And, in any case, I don't see you sending anything but the operation form.)
Not sure what you mean with "reference" vs "operation" form. I can't find the word "reference" at all in the PDF I've been working with. My protocol implementation is based on this PDF, which is the newest I could find:
http://support.jvc.com/consumer/support/documents/DILAremoteControlGuide.pdf
Look at the bottom of page 22. It reads there:
> Looking at this as a timeline, using the same
> numbered steps as above, the sequence is:
> [...]
> Step 5: Command from Controller to Projector
> [...]
> Assuming the steps shown above are carried
> out correctly, the projector will respond to the
> command.
This clearly shows that the projector responds to *every* command. And my X35 definitely does.
On page 15 it's even clearer:
> The projector will return an Acknowledgement
> Response Return Code for any valid command
> that it receives.
My code waits for this reply from the projector, with a timeout of 5 seconds (meaning I abort waiting for the reply after 5 seconds). Except when activating a lens memory. In that case I've increased the timeout to 30 seconds. And my X35 replies to the lens memory command after about 15-20 seconds, exactly at the moment when the lens memory activation was fully completed. Which allows me to resume video playback exactly at the right time.
The first time a video is played madVR pauses the video, sends ? PW, receives 'power on", closes the socket, sends ! INML2, closes the socket.
Are you totally sure madVR closes the socket directly after sending the lens memory activation command? It should not close the socket before either the timeout value of 30 seconds has passed, or before a reply from the projector has arrived.
The video remains paused until I take action. If I restart the video, madVR does nothing, the video plays normally. If I end Zoomplayer and restart it, the above sequence is repeated.
Restarting the video will not do anything because madVR remembers that this specific lens memory was already activated. So why should madVR activate it another time? That would be superfluous. madVR will only activate a lens memory if it's different to the one activated before - and it will delay activating the new different lens memory until either the timeout value of 30 seconds has passed, or until the projector replied to the older lens memory activation. Basically madVR tries its best to be clever about lens memory activation, to avoid unnecessary activations, and to not crash the projector by sending lens memory activation commands too quickly. Makes sense, don't you think?
My other X500 tester reported to me that if we torture the X500 by sending lens memory activation commands too quickly, without waiting for completion of the old command, the X500 will sometimes crash and require a cold boot to be accessible at all, anymore. So I'm very careful to not crash the JVC.
madshi
24th October 2015, 01:40
You could put Catmull into the dropdown menu, like "sharpness: 50 (Catmull-Rom)" ?
Isn't Mitchell-Netravali also just one kind of bicubic? What's the relation between sharpness (and softness in softcubic) and the Avisynth b&c parameters?
I guess I could do that, but I don't find it very important right now. At some point I'm going to cleanup the whole settings dialog. That would then be a good time to optimize stuff away. Right now I consider that very low priority.
Mitchell-Netravali and SoftCubic use cubic kernels, too, but with different parameters to Bicubic. I don't know AviSynth b&c params.
I get this for a 1280x718 video. What does the first line mean? All black bar stuff is disabled.
It seems 2 pixels are cropped away for some reason. I'm not sure why. I can investigate if you send me a sample, and a list of which filters/software you use for playback.
ajp_anton
24th October 2015, 01:54
Mitchell-Netravali and SoftCubic use cubic kernels, too, but with different parameters to Bicubic. I don't know AviSynth b&c params.http://www.imagemagick.org/Usage/filter/#cubics
ajp_anton
24th October 2015, 02:04
It seems 2 pixels are cropped away for some reason. I'm not sure why. I can investigate if you send me a sample, and a list of which filters/software you use for playback.Easiest sample ever: create a 1280x718 blank video with Avisynth and encode =).
http://s.ajpanton.se/sample.mkv
LAV decoder, hardware or software doesn't matter. MPC-HC. Windows 10. Everything 64-bit.
AngelGraves13
24th October 2015, 02:09
Really liking the "crop black bars" option. It's useful for films and TV shows, especially older ones that don't fill the screen entirely. I don't zoom as I don't like losing any content at all.
For example, The Sopranos on blu-ray. The first 2 seasons have inconsistent black borders on the left side of some episodes, and the setting crops it out and scales the image. Great!
Also great for watching old 4:3 DVD episodes of Batman: The Animated Series. Some episodes have black borders and having them cropped out is great. Difference of a few pixels, and it's upscaling to 1440p anyway.
The best use of the feature so far has been to correct a mastering error for Hell on Wheels Season 2. Some episodes had very strange framing. I thought my purchase was defective, but it seems they all have it.
Example here -> http://www.blu-ray.com/movies/Hell-On-Wheels-The-Complete-Second-Season-Blu-ray/58683/
Dogway
24th October 2015, 02:12
Thanks for runtime. Unless I got it wrong, it's not working for me.
if (runtime < 15) "Short"
else "Long"
I'm using a bit older version of MPC-HC, so not sure if that has to do with that.
it also happens that whenever I try to write something into the "Display Modes" profile rules, I get out of the settings panel to the one above...
@ajp_anton: Bicubic kernels can use a implementation with two components, the b and c. I already suggested months ago to get rid of all the bicubic presets and just say "bicubic" and enable the "b" and "c". Once you start arguing between lanczos, spline and taps you already are in the place where you should know about bicubics and the different values (Hermite, Rubidoux, CatRom, etc)
JarrettH
24th October 2015, 05:44
I don't fully understand what you mean.
Do I have to watch a video as a test pattern or can it be a still (paused film)? I remember the ytp patterns being in motion or swirling or something like that.
Sunset1982
24th October 2015, 07:46
OK, found the solution to my D3D11 crashes... :helpful:
reinstalled nvidia drivers -> worked :eek:
setup stereoscopic 3D in the nv control panel -> crashes till I newly installed nvidia drivers and keep stereoscopic 3D disabled. :devil:
So the problem is mpc-hc/madvr/lav/d3d11 keeps crashing when stereoscopic 3D was setup before.Can anyone reproduce this? I dont know if this is madvr related bug or bad drivers or even mpc-hc. :confused:
tested with nv dirvers 358.50 and 355.98. I also tried latest nightly of mpc-hc and lav filters, same crashes.
After I setup 3D in the drivers I can only view flawless with D3D9 render path in madvr activated.
CiNcH
24th October 2015, 08:27
Here is another attempt to compare EVR and madVR (DXVA) performance and find out why madVR uses so much more resources on my machine.
Windows 7 (x86) SP1 + Platform Update (KB2670838)
- Aero/DWM enabled
Intel HD 4000 Graphics
- drv 15.33.39.4276-win32
- BIOS: Fixed Memory=64M, Total Memory=256M
madVR 0.89.12
- restored default settings
- DXVA chroma/luma down/upscaling
- trust DXVA color & levels conversion
- dithering: None
LAV Filters 0.66 (dxva2n)
720p50 (ORF 1 HD, H.264) @ 1080p50 (no deinterlacing)
EVR: 26% @ ~350MHz, 59°C, 2.6W, 46M Dedicated Memory, 155M Dynamic Memory
madVR (FSE): 55% @ ~650MHz, 61°C, 5.1W, 63M Dedicated Memory, 289M Dynamic Memory
1080i25 (Sky Cinema HD, H.264) @ 1080p50 (no luma scaling, frame doubling deinterlacing)
EVR: 30% @ ~350MHz, 59°C, 2.7W, 64M Dedicated Memory, 196M Dynamic Memory
madVR (FSE): 61% @ ~650MHz, 61°C, 5.8W, 63M Dedicated Memory, 304M Dynamic Memory
Seems like the Windows 7 Platform Update has already been installed on my system via Windows Update.
I already tried to increase GPU memory in the BIOS. But it did not change a thing.
I used GPU-Z 0.8.5 as measurement tool.
aufkrawall
24th October 2015, 11:48
I can't access this image. I'm getting "Referral Denied". Do you have a working link?
http://abload.de/img/618-01245035em-wave-otmjta.jpg
markanini
24th October 2015, 13:08
Any chance of ivtc functionality being extrended to include something like TDecimate(hybrid=1)?
Ruya
24th October 2015, 14:40
If v0.88.1 can do D3D11, then v0.89.12 should be able to, too. So I'm not sure what's going on there.
According to the changelog, after v0.88.1 D3D11 is not used if DWM is disabled. (Hence why I chose this version to revert to)
D3D11 isn't working in windowed mode, which is to be expected with DWM disabled, but full-screen exclusive mode is working perfectly.
It would be nice if this could somehow be changed so that I can have D3D9 when windowed and still use D3D11 in fullscreen, but I don't use windowed mode very often so for the time being I'm fine with editing the settings whenever I need windowed mode.
I haven't yet run into any major complications with v0.88.1
jmonier
24th October 2015, 14:54
Not sure what you mean with "reference" vs "operation" form. I can't find the word "reference" at all in the PDF I've been working with. My protocol implementation is based on this PDF, which is the newest I could find:
http://support.jvc.com/consumer/support/documents/DILAremoteControlGuide.pdf
Look at the bottom of page 22. It reads there:
> Looking at this as a timeline, using the same
> numbered steps as above, the sequence is:
> [...]
> Step 5: Command from Controller to Projector
> [...]
> Assuming the steps shown above are carried
> out correctly, the projector will respond to the
> command.
This clearly shows that the projector responds to *every* command. And my X35 definitely does.
On page 15 it's even clearer:
> The projector will return an Acknowledgement
> Response Return Code for any valid command
> that it receives.
And all this is exactly what I said. The confusion is in nomenclature. The document that you reference is semi-official (it comes from a JVC guy in Great Britain). That particular version is rather sloppy. To see the correct nomenclature refer to the "External Control" section of your user manual. That's what I used for my basic logic (since nothing else was available or needed for my RS-50).
My confusion comes from the user manual statement under the "ACK" type that it "returns to PC after the command is accepted without error". I assumed that to mean that it was not an acknowledgement that the command was actually executed (which may have been true for the RS50).
Apparently, from what you say, it IS an indication that the command was executed and I'll have to change my thinking.
My code waits for this reply from the projector, with a timeout of 5 seconds (meaning I abort waiting for the reply after 5 seconds). Except when activating a lens memory. In that case I've increased the timeout to 30 seconds. And my X35 replies to the lens memory command after about 15-20 seconds, exactly at the moment when the lens memory activation was fully completed. Which allows me to resume video playback exactly at the right time.
Please verify that the reply you're talking about is the ACK (06) reply and not the "Response Command" (40).
Are you totally sure madVR closes the socket directly after sending the lens memory activation command? It should not close the socket before either the timeout value of 30 seconds has passed, or before a reply from the projector has arrived.
I didn't state that too well. It was actually closing after it received the ACK reply, which I was sending immediately after I received the command.
Restarting the video will not do anything because madVR remembers that this specific lens memory was already activated. So why should madVR activate it another time? That would be superfluous. madVR will only activate a lens memory if it's different to the one activated before - and it will delay activating the new different lens memory until either the timeout value of 30 seconds has passed, or until the projector replied to the older lens memory activation. Basically madVR tries its best to be clever about lens memory activation, to avoid unnecessary activations, and to not crash the projector by sending lens memory activation commands too quickly. Makes sense, don't you think?
It doesn't make sense if I've changed the memory back after the video stops playing (since menus, etc. need a 16:9 screen). Then it thinks that the zoom is still at 2.35 and won't change it for the next 2.35 video.
Do you do anything special for this case?
mcn
24th October 2015, 16:22
I have some videos that aren't in the same aspect ratio as my monitor.
When I watch them in full screen black bars are added at the top and at the bottom.
Embedded subtitles are always partially shown in the black area at the bottom.
So far so good.
But in certain cases external subtitles aren't shown in the black area.
I can't find a pattern for this.
I only know that it depends on the .srt file.
For example if I have video A which shows external subs correctly in the black area, and video B that doesn't, I can use B's subs with video A and they will not be shown correctly.
And vice-versa.
I thought this might be related to the line ending used in the file but it doesn't.
Is this a known issue or am I doing something wrong?
I'm using (32-bit) madVR 0.89.12, LAV filters 0.66, XySubFilter 3.1.0.746, MPC-HC 1.79.
agustin9
24th October 2015, 16:36
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?
madVr positioning is fine, but shouldn't madVr send the active area rectangle to XySubfilter and it draw according to that rectangle?
CiNcH
24th October 2015, 18:29
High GPU consumption is now under control, thanks to madshi. The problem was a sightly changed procamp contrast slider. This considerably drives GPU usage.
Barnahadnagy
24th October 2015, 21:57
Hi guys! I was testing HEVC and whatnot, and I encountered something I can't explain. I switched back to AVC and x264 for this test, just in case.
So a short rundown on the problem: 10bit encode makes outline of the letters in my sample more saturated, and chroma position shifts a bit. 8bit encodes do not. EVR-CP (and VLC) does not exhibit this problem.
Sample pictures upscaled x5 in GIMP with NN (BD, 8bit):
http://i1090.photobucket.com/albums/i372/barnahadnagy/Other/BD%20x5.png~originalhttp://i1090.photobucket.com/albums/i372/barnahadnagy/Other/8bit%20x5.png~original
10bit, 10bit EVR
http://i1090.photobucket.com/albums/i372/barnahadnagy/Other/10bit%20x5.png~originalhttp://i1090.photobucket.com/albums/i372/barnahadnagy/Other/10bit%20EVR%20x5.png~original
What I tried: Different scaling algo, D3D9 or D3D11 (fullscreen windowed to allow screenshots), monitor bit-depth, disabled 10bit output in LAV (output was NV12 in this case), turned AR filter and chroma superres on/off (chroma SRes creates halos tho), changed dithering. I also had a friend test it, with KCP, it produced the same results.
Settings: (On pictures) Jinc chroma upscale with anti rigging filter, D3D9 fullscreen windowed (new path), 8bit monitor, ordered dithering, no trade quality for performance, all image enhacements and artifact removal algos are disabled. Only chroma scaling is active.
Currently on MPC HC 1.7.9, using its internal LAVfilters, MadVR 89.12 (88.12 produced same results with D3D9 and Jinc).
System is: i5 2500k, GTX 970, Windows 10 x64, latest WHQL driver.
Sample is Non Non Biyori Blu-Ray, episode 1, frame 4750.
Encoding settings: For 8 bit re-encode I used latest x264 command line, with MKV input and output. For 10bit, I did the same, and I also acquired a different encode, made quite some time ago. All exhibit the same problem.
For HEVC, I used last 1.7 x265, and 1.8.65 x265, both produced indentical results, which also exhibit this problem. In the x265 pipeline, the encoder was fed a y4m file, decoded with FFMPEG.
Sample (http://www.mediafire.com/download/768ha3idvjtpfww/NNB.zip) with 8bit and 10bit reencode, plus some more screenshots.
This seems to be a problem in MadVR, but for some reason, it didn't go away if LAV had to do the conversion from 10 to 8 bits, so I'm quite clueless as to what is going on here.
On a side note, chroma seems to be slightly shifted in EVR compared to MadVR, independent on encode. Which one is correct here (I guess MadVR, it looks more correct)?
EDIT: For those who have GIMP (or can open XCF files), here (http://www.mediafire.com/download/460rpziy5q3qzv4/NNB+GIMP+XCF+Comparison.zip) is one with lots of layers of different images, and some notes on what to look for. It also has HEVC tests in it, so if you are interested in that here you go.
Another note: using printscreen or MPC's ALT+I function made no difference.
nijiko
24th October 2015, 22:24
I finally found why snap image failed.
Conditions: An interlaced video, MPC-HC using "minimized" mode view (removed MPC-HC's title and border), madVR using DXVA method rendering.
Then, if you snap image in playing, you will failed.
madshi
24th October 2015, 23:05
Easiest sample ever: create a 1280x718 blank video with Avisynth and encode =).
http://s.ajpanton.se/sample.mkv
LAV decoder, hardware or software doesn't matter. MPC-HC. Windows 10. Everything 64-bit.
Ah, thanks. Looks like a purely cosmetical OSD display problem, I'll fix that for the next build.
Really liking the "crop black bars" option. It's useful for films and TV shows, especially older ones that don't fill the screen entirely. I don't zoom as I don't like losing any content at all.
For example, The Sopranos on blu-ray. The first 2 seasons have inconsistent black borders on the left side of some episodes, and the setting crops it out and scales the image. Great!
Also great for watching old 4:3 DVD episodes of Batman: The Animated Series. Some episodes have black borders and having them cropped out is great. Difference of a few pixels, and it's upscaling to 1440p anyway.
The best use of the feature so far has been to correct a mastering error for Hell on Wheels Season 2. Some episodes had very strange framing. I though my purchase was defective, but it seems they all have it.
Glad you like it! Was *a lot* of work to implement...
Thanks for runtime. Unless I got it wrong, it's not working for me.
Ok, will double check. The MPC-HC version doesn't matter.
Do I have to watch a video as a test pattern or can it be a still (paused film)? I remember the ytp patterns being in motion or swirling or something like that.
Banding artifacts are easier to see in motion, so using a moving video can have advantages.
OK, found the solution to my D3D11 crashes... :helpful:
reinstalled nvidia drivers -> worked :eek:
setup stereoscopic 3D in the nv control panel -> crashes till I newly installed nvidia drivers and keep stereoscopic 3D disabled. :devil:
So the problem is mpc-hc/madvr/lav/d3d11 keeps crashing when stereoscopic 3D was setup before.Can anyone reproduce this?
Yes, has been reported by several users. I doubt madVR is at fault, but I don't know for sure.
http://abload.de/img/618-01245035em-wave-otmjta.jpg
Thanks.
Any chance of ivtc functionality being extrended to include something like TDecimate(hybrid=1)?
I don't know TDecimate. What does hybrid=1 do?
According to the changelog, after v0.88.1 D3D11 is not used if DWM is disabled. (Hence why I chose this version to revert to)
D3D11 isn't working in windowed mode, which is to be expected with DWM disabled, but full-screen exclusive mode is working perfectly.
It would be nice if this could somehow be changed so that I can have D3D9 when windowed and still use D3D11 in fullscreen, but I don't use windowed mode very often so for the time being I'm fine with editing the settings whenever I need windowed mode.
I haven't yet run into any major complications with v0.88.1
Ah ok, that makes sense. But sorry to say, supporting D3D9 windowed in combination to D3D11 fullscreen is not planned. Too much complication for too little benefit.
Please verify that the reply you're talking about is the ACK (06) reply and not the "Response Command" (40).
Yes. For every command I'm sending (either reading or setting something) I first require a 06 reply. When reading stuff, afterwards I require an additional 40 response. When setting/changing stuff, there's always a 06 reply, but no 40. When changing lens memories on my X35, the 06 reply comes exactly at the moment when the lens memory activation has been completed.
Still not sure why there are situations in which my IP control test tool doesn't work while yours works. I can't find anything in either the PDF I've been using or in the X500 user manual that would indicate that I'm doing anything less than perfectly.
It doesn't make sense if I've changed the memory back after the video stops playing (since menus, etc. need a 16:9 screen). Then it thinks that the zoom is still at 2.35 and won't change it for the next 2.35 video.
Can you give me some more details about your specific use scenario? It seems you let the media player process running, and then you manually switch the lens memory to display something with a different application. And then you want to continue video playback and you want madVR in that moment to activate the lens memory again? Which applications are you using and which kind of menu are you talking about etc? I suppose that's a legit use case, although probably not very typical.
The key problem for me is that JVC doesn't support reading the current lens memory number (Sony projectors do!!). So I don't know if you've manually changed the lens memory or not. Of course I could simply issue the lens memory activation again, but doing so does blend in the lens memory focus test pattern for a short moment (on my X35 at least), even if the lens memory I'm requesting is already active, so it's not something I'd like to do if I don't have to.
So what's a good check for me to do to find out whether I should reactivate the lens memory or not? E.g. I guess I could do that every time a new video is loaded? Would that solve the problem for you?
Anyway, considering the logic I explained, does that solve the mystery of why lens activation sometimes worked as you expected and sometimes not? So it's not a logic bug, but "as intended"? Of course "as intended" doesn't automatically have to mean that it's good.
I have some videos that aren't in the same aspect ratio as my monitor.
When I watch them in full screen black bars are added at the top and at the bottom.
Embedded subtitles are always partially shown in the black area at the bottom.
So far so good.
But in certain cases external subtitles aren't shown in the black area.
I can't find a pattern for this.
I only know that it depends on the .srt file.
For example if I have video A which shows external subs correctly in the black area, and video B that doesn't, I can use B's subs with video A and they will not be shown correctly.
And vice-versa.
I thought this might be related to the line ending used in the file but it doesn't.
Is this a known issue or am I doing something wrong?
Do you have black bar detection activated in the madVR settings? Are you sure that XySubFilter is used for *all* those subtitles? Maybe sometimes one sub renderer is used, and sometimes another one? E.g. maybe one renderer or external subs and a different one for internal subs? Just a thought, though.
madVr positioning is fine, but shouldn't madVr send the active area rectangle to XySubfilter and it draw according to that rectangle?
That would be ideal, but XySubFilter doesn't support that in its current form, and the XySubFilter developer is MIA. So I implemented subtitle moving in madVR instead.
High GPU consumption is now under control, thanks to madshi. The problem was a sightly changed procamp contrast slider. This considerably drives GPU usage.
:)
Hi guys! I was testing HEVC and whatnot, and I encountered something I can't explain. I switched back to AVC and x264 for this test, just in case.
So a short rundown on the problem: 10bit encode makes outline of the letters in my sample more saturated, and chroma position shifts a bit. 8bit encodes do not.
Can't seem to be able to reproduce that here. Here's what I'm getting with Jinc AR chroma upscaling with your 8bit and 10bit sample:
http://madshi.net/Barnahadnagy8bit.png
http://madshi.net/Barnahadnagy10bit.png
Every so slightly different, but the difference is much lower than in your screenshots. Do you have any unusual filters in your playback chain? Any profiles in madVR? Try LAV Video Decoder and madVR with default settings for both, and with no funny filters in between (like ffdshow raw or stuff).
I finally found why snap image failed.
Conditions: An interlaced video, MPC-HC using "minimized" mode view (removed MPC-HC's title and border), madVR using DXVA method rendering.
Then, if you snap image in playing, you will failed.
Interesting. It happens only in minimized mode view?
nijiko
24th October 2015, 23:16
Interesting. It happens only in minimized mode view?
Not test with other conditions. This is one of conditions to trigger.
markanini
25th October 2015, 00:42
I don't know TDecimate. What does hybrid=1 do?
It a way to deal with 29.97 sources which contain mostly 24p material.
From the manual: "Blend decimation of 30p sections into 24p and leave 24p untouched"
Barnahadnagy
25th October 2015, 01:35
Can't seem to be able to reproduce that here. Here's what I'm getting with Jinc AR chroma upscaling with your 8bit and 10bit sample:
http://madshi.net/Barnahadnagy8bit.png
http://madshi.net/Barnahadnagy10bit.png
Every so slightly different, but the difference is much lower than in your screenshots. Do you have any unusual filters in your playback chain? Any profiles in madVR? Try LAV Video Decoder and madVR with default settings for both, and with no funny filters in between (like ffdshow raw or stuff).
I feel stupid now. This turned out to be two issues. I started with HEVC, but apparently that has a similar artifact here. So troubleshooting that I installed a clean version of MPC HC nightly. Which makes LAV use DXVA native by default, and fall back to software with 10bit. We all know what happens with DXVA native don't we...
So in order to troubleshoot my HEVC issues, I unknowingly created a completely different one, which looked similar enough to the original that I didn't notice. Well there goes my hard work with providing beautiful samples.
Also, I wouldn't have expected the DXVA native issue to be this serious. If I remember correctly a slight blur was mentioned, but this doesn't seem to be so slight. Not to mention misaligned chroma...
All is well in the end, at least I learned something today. Sorry for creating more work for you :p But at least we know now that EVR (and VLC) suffers from this DXVA native quality loss too...
agustin9
25th October 2015, 03:01
That would be ideal, but XySubFilter doesn't support that in its current form, and the XySubFilter developer is MIA. So I implemented subtitle moving in madVR instead.
That makes sense. Thanks for all your hard work, hope someday it get's done the right way. Thank you very much!
Sunset1982
25th October 2015, 09:04
Originally Posted by madshi
Yes, has been reported by several users. I doubt madVR is at fault, but I don't know for sure.
ah ok. Have you done some furhter investigations? Is there anything I could do to help you find out what is causing this error? Let me know if so.
In the meantime I will try to open a thread in the nvidia forums. Maybe they have an idea.
ryrynz
25th October 2015, 14:24
Is the error reporting working? I get the error message "Sorry sending the bug report didn't work"
Had madVR crash MPC-BE when I changed from fullscreen to windowed mode.
http://pastebin.com/fh0P5Y79
Dlget
25th October 2015, 14:43
Something causing memory leak.
Here is error log.
https://www.dropbox.com/s/12ef5azfz22wa6f/madVR%20-%20log.txt.bz2?dl=0
EDIT:
Probably XYSubfilter
This occur even with EVR Custom but not with EVR.
EDIT2:
Disabled Xysubfilter & no memory leak.
Can anyone report it to XY Subfilter(XySubFilter_3.1.0.746_x64_BETA3)
mcn
25th October 2015, 15:14
Do you have black bar detection activated in the madVR settings? Are you sure that XySubFilter is used for *all* those subtitles? Maybe sometimes one sub renderer is used, and sometimes another one? E.g. maybe one renderer or external subs and a different one for internal subs? Just a thought, though.
I'm not too knowledgeable but I'm pretty sure XySubFilter is used in all the cases.
I can switch between subtitles while the video is playing while using XySubFilter context menu while in MPC-HC.
And I can see how embedded subtitles are correctly shown at the bottom of the screen while (some) external ones aren't.
Regarding madVR settings, under the zoom control tab, the only checked item is move subtitles: and the corresponding drop down is set to ... to bottom of the screen/window.
I also tried checking automatically detect hard coded black bars but it didn't help.
Indeed, since the videos don't have black bars in themselves it shouldn't do anything, right?
While I was at it I also enabled full screen exclusive mode, which I usually don't use, but it doesn't help either.
VHT
25th October 2015, 19:12
Noob Question. What are the benefits of using D3D11 path instead of D3D9 if I only have 8bit display and find that using ordered dithering is good enough?
Patrik G
25th October 2015, 23:24
Question and a Problem
Why is madvr Locked to SRGB gamut when using a 3D LUT for calibration?
i have created a 3D LUT for a wider colorspace close to DCI P3 that my tv can deliver.
still selecting the P3 3D LUT in the DCI P3 section in madvr it only gets to SRGB gamut.
without the 3D LUT i get the full DCI gamut.
or is it a bug with argyll cms?
it almost seems that madvr doesnt read all the info from the 3D LUT files.
the P3 3d lut and the rec709 3d LUT are alot different and should not get the same gamut.
Edit: i know its a bug with argyll CMS but i want to try to ask here also so i can rule out madvr and have it on paper to show the stubborn argyll CMS creator lol
markanini
25th October 2015, 23:31
Question and a Problem
Why is madvr Locked to SRGB gamut when using a 3D LUT for calibration?
i have created a 3D LUT for a wider colorspace close to DCI P3 that my tv can deliver.
still selecting the P3 3D LUT in the DCI P3 section in madvr it only gets to SRGB gamut.
without the 3D LUT i get the full DCI gamut.
or is it a bug with argyll cms?
it almost seems that madvr doesnt read all the info from the 3D LUT files.
the P3 3d lut and the rec709 3d LUT are alot different and should not get the same gamut.
Edit: i know its a bug with argyll CMS but i want to try to ask here also so i can rule out madvr and have it on paper to show the stubborn argyll CMS creator lol
Have you seen http://www.avsforum.com/forum/139-display-calibration/1471169-madvr-argyllcms.html ?
jmonier
25th October 2015, 23:33
Yes. For every command I'm sending (either reading or setting something) I first require a 06 reply. When reading stuff, afterwards I require an additional 40 response. When setting/changing stuff, there's always a 06 reply, but no 40. When changing lens memories on my X35, the 06 reply comes exactly at the moment when the lens memory activation has been completed.
With my RS-4910 the 06 reply comes back within 2 ms of any operation command and it definitely does NOT wait for the completion of the Load Lens Memory operation. This is certainly different than your X35 and possibly different than your friend's X500 (since it seems to work fine with madVR).
This, of course, means that the Pause is minimal and barely noticeable.
Still not sure why there are situations in which my IP control test tool doesn't work while yours works. I can't find anything in either the PDF I've been using or in the X500 user manual that would indicate that I'm doing anything less than perfectly.
I'm not sure, either, and it needs further investigation. From what I've seen in some further tests, madVR (and to a lesser extent your test tool) are flaky on my system even when my TCPIP control is totally disabled.
This is the first time I've really looked at the logs of my TCPIP control when used with the RS4910 and it's not really working perfectly. The only reason I haven't noticed this before is because it usually gets it right on the second retry so it seems like it's ok when it really isn't.
Since it worked fine on my RS50, I have to investigate how the differences in the RS4910 are interacting with my code. I'll report back on what I find.
EDIT: I looked at it carefully last night and everything was working fine then so I don't know what to think.
Here's a couple of things in my code that may help you: 1) I found that I needed to have a 100 ms delay after the completion of the initial handshaking (PJ_OK, PJREQ, PLACK) before I sent the actual command/request, 2) if you need to send 2 commands/requests in sequence, you can send the second 100ms after the first without repeating the initial handshaking.
One thing you might change in your test tool is to have it send the PW inquiry prior to the INML command since I believe that's the way madVR does it.
FYI: I believe that one of the commercial calibration tools (Calman, I think) had a lot of trouble integrating their tool via TCPIP to the RS49/X500 series. The last I heard, they had actually given up on it. I might have missed something since then, however.
Can you give me some more details about your specific use scenario? It seems you let the media player process running, and then you manually switch the lens memory to display something with a different application. And then you want to continue video playback and you want madVR in that moment to activate the lens memory again? Which applications are you using and which kind of menu are you talking about etc? I suppose that's a legit use case, although probably not very typical.
It's only one application - Zoomplayer. ZP has a Media Library display that allows me to select the video that I'm going to play next. Via my TCPIP control of Zoomplayer, at the end of a video I can cause the Media Library display to appear so I can select the next video. At the same time I command the JVC to load the lens memory for a full 1920x1080 screen. This seems like a very typical way to do it.
If I depend on madVR to do everything, the Media Library will be partly off screen after a 2.35 video (since madVR apparently doesn't do anything at the end of a video). If I manually set the Lens Memory back to 16:9, madVR still thinks the JVC is at 2.35 and won't change it for the next 2.35 video. (Things are further confused by the fact that madVR control of the JVC is flaky in my case.)
The key problem for me is that JVC doesn't support reading the current lens memory number (Sony projectors do!!). So I don't know if you've manually changed the lens memory or not. Of course I could simply issue the lens memory activation again, but doing so does blend in the lens memory for a short moment (on my X35 at least), even if the lens memory I'm requesting is already active, so it's not something I'd like to do if I don't have to.
I understand your problem. The RS4910 does not show the focus test pattern in this case so I would be OK but we want this to be good for all users.
So what's a good check for me to do to find out whether I should reactivate the lens memory or not? E.g. I guess I could do that every time a new video is loaded? Would that solve the problem for you?
Activating the lens memory for 16:9 when a video stops would do it for me (assuming that madVR works OK otherwise). This wouldn't necessarily work for other users, though.
Anyway, considering the logic I explained, does that solve the mystery of why lens activation sometimes worked as you expected and sometimes not? So it's not a logic bug, but "as intended"? Of course "as intended" doesn't automatically have to mean that it's good.
It does solve a good part of the mystery but there's still the flaky operation.
At this point what I (as a member of the very small group of users that have done their own control programming) would like is an additional optional TCPIP interface for this part of madVR. It would work like this:
1. I would enter a TCPIP address and port number to mad VR
2. Each time madVR detected that the lens memory should be at a particular setting for the video being played it would output just the lens memory number to this port.
3. If necessary, I would send that number back as an acknowledgement
I would handle everything else in my logic (including setting it back to 16:9 at the end of a video).
I think that this would be the simplest solution for you and me to implement but, of course, it would be applicable for only a small subset of users.
EDIT: After looking at it some more, I think that I could make my JVC simulator code work just fine as an interface. The one thing that I would need from you is an option to ALWAYS send a Load Lens Memory command even when you think that it's already there. You may need to have this anyway because of the problems in determining where you are.
Patrik G
25th October 2015, 23:34
Have you seen http://www.avsforum.com/forum/139-display-calibration/1471169-madvr-argyllcms.html ?
thanks but i know all about it already.
the problem is that different 3D LUTs based on different colorspaces still gets the same rec709 colorspace when i select them in madvr.
baii
26th October 2015, 00:06
thanks but i know all about it already.
the problem is that different 3D LUTs based on different colorspaces still gets the same rec709 colorspace when i select them in madvr.
Because madvr is doing it correctly? The content ask(or madvr guess) for rec709, so it does srgb transformation. If you have wide gamut content, it will use the appropriate color space.
The 3dlut is not here so the user can "choose" the color space.
And the "rec 709 3dlut" actually have the information needed for wide gamut transformation.
Sent from my 306SH
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.