View Full Version : madVR - high quality video renderer (GPU assisted)
mark0077
26th December 2012, 15:14
Thanks for the new versions. Quick q for anyone I guess. Is it possible to open in FSE without seeing the "exclusive" message. I don't delay for 3 seconds to display it, and I have mpc set to open files in fullscreen immediately which it does. I thought this wasn't supposed to show the madVR "exclusive" message?
fallengt
26th December 2012, 16:30
If I use 3dlut file, does it helps correcting gamut at 25/50/75%Saturation points or just at 100% saturation
http://www.geocities.com/stereomandan/projector/saturationlocations.jpg
Ver Greeneyes
26th December 2012, 17:06
I think it's probably a driver problem. I think that either the driver is telling madVR that the original mode was 59Hz.
If this is the case, you could try asking the DWM instead (and do the rounding yourself): DwmGetCompositionTimingInfo (http://msdn.microsoft.com/en-us/library/windows/desktop/aa969514.aspx). I believe the DWM is always enabled in Windows 8. I've also seen a similar problem (rounding 59.94Hz down to 59Hz) in Windows 7 though. There you can check if the DWM is enabled (full Aero) by using DwmIsCompositionEnabled (http://msdn.microsoft.com/en-us/library/windows/desktop/aa969518.aspx).
aufkrawall
26th December 2012, 17:55
Small glitch: When using the uninstall.bat, cmd remains blank (doesn't show any text).
fairchild
26th December 2012, 18:01
I'm experiencing some weird artifacts (it is some weird horizontal lines which appear) when using image scaling other than Bilinear on a 720x480 mpg2 encoded interlaced test clip which I usually to test with. Everything from mitchell to spline exhibit it clearly, where as Jinc doesn't show the artifacts too much but is still present. When I get home later from work I'll try to throw in some actual DVD's and see if the issue is still occurring. Not sure if this has something to do with the changes you made to the shaders for speed up purposes or something else. This is with the latest 0.85.6 build and latest Lav Filters (software decoding) and MadVR deinterlacing enabled.
Even when I disable MadVR's deinterlacer the artifacts show up so that leads me to believe it's something with the image scaler algorithm used. (I also disabled MadVR's deinterlacing and enabled Yadif through Lav Video and the artifacts are still present.) Again, when the video is played back at it's original resolution of 720x480 no artifacts regardless of deinterlacing being on or off and regardless of deinterlacer used, but once I upscale and go FSE to my 1920x1080p (1680x1080 is the actual upscale resolution since it's a 4x3 clip), the artifacts are present. FSE doesn't have any impact on it either.
So for now I'll stick with bilinear for chroma and image upscaling till we can figure this out.
pankov
26th December 2012, 18:18
madshi, guys,
a friend of mine who is using a plasma TV for watching movies and Live/Recorded TV asked me a question that I couldn't answer.
He's using MPC-HC + madVR and asked me if it's possible to make the black bars around a 4:3 frame on a 16:9 FullHD display a shade of gray not pure black. There is such a setting in the options of the TV but this only works when the TV sees the actual 4:3 signal, not the 1920x1080 signal from the HTPC. He thinks and I kind of agree that this will make the image retention on the plasma a bit less pronounced when he switches back to 16:9 or 2.35:1 afterwards. So I thought this is something that belongs to the renderer, right? I looked around but sadly none of them has such an option.
madshi, would you consider adding something like this in madVR? I thought it would be possible to do this with a post-scaling custom pixel shader but then I remembered a discussion with cyberbeing ... or was it leeperry ... where it was explained that the custom shaders don't have access to the black bars and these are added by madVR at the last possible step before the presentation on screen. ... So that's one of the reasons that I think this belongs to madVR's options ... the other one is the lack of custom shaders support in some players.
madshi
26th December 2012, 18:44
Thanks for the new versions. Quick q for anyone I guess. Is it possible to open in FSE without seeing the "exclusive" message. I don't delay for 3 seconds to display it, and I have mpc set to open files in fullscreen immediately which it does. I thought this wasn't supposed to show the madVR "exclusive" message?
I suppose for some reason playback is started in windowed mode and only a couple milliseconds later switches to fullscreen. Don't know why, might be the media player doing funny things.
If I use 3dlut file, does it helps correcting gamut at 25/50/75%Saturation points or just at 100% saturation
If you don't get an answer here, try the yCMS doom9 thread.
If this is the case, you could try asking the DWM instead (and do the rounding yourself): DwmGetCompositionTimingInfo (http://msdn.microsoft.com/en-us/library/windows/desktop/aa969514.aspx). I believe the DWM is always enabled in Windows 8. I've also seen a similar problem (rounding 59.94Hz down to 59Hz) in Windows 7 though. There you can check if the DWM is enabled (full Aero) by using DwmIsCompositionEnabled (http://msdn.microsoft.com/en-us/library/windows/desktop/aa969518.aspx).
It's not the "real" refresh rate that counts, but the short number Windows uses to identify different modes. That's got nothing to do with Aero/DWM.
Small glitch: When using the uninstall.bat, cmd remains blank (doesn't show any text).
You're not supposed to uninstall madVR... :D
I'm experiencing some weird artifacts (it is some weird horizontal lines which appear) when using image scaling other than Bilinear on a 720x480 mpg2 encoded interlaced test clip which I usually to test with. Everything from mitchell to spline exhibit it clearly, where as Jinc doesn't show the artifacts too much but is still present. When I get home later from work I'll try to throw in some actual DVD's and see if the issue is still occurring. Not sure if this has something to do with the changes you made to the shaders for speed up purposes or something else. This is with the latest 0.85.6 build and latest Lav Filters (software decoding) and MadVR deinterlacing enabled.
Even when I disable MadVR's deinterlacer the artifacts show up so that leads me to believe it's something with the image scaler algorithm used. (I also disabled MadVR's deinterlacing and enabled Yadif through Lav Video and the artifacts are still present.) Again, when the video is played back at it's original resolution of 720x480 no artifacts regardless of deinterlacing being on or off and regardless of deinterlacer used, but once I upscale and go FSE to my 1920x1080p (1680x1080 is the actual upscale resolution since it's a 4x3 clip), the artifacts are present. FSE doesn't have any impact on it either.
So for now I'll stick with bilinear for chroma and image upscaling till we can figure this out.
Try changing the scaling factor slightly. Does that fix the issue? The new shaders are for exact 2.000x and 3.000x scaling factors. Do you get those artifacts only with those scaling factors? Or also with others?
a friend of mine who is using a plasma TV for watching movies and Live/Recorded TV asked me a question that I couldn't answer.
He's using MPC-HC + madVR and asked me if it's possible to make the black bars around a 4:3 frame on a 16:9 FullHD display a shade of gray not pure black.
Most renderers support this (including madVR), but the media player has to activate it. See here:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd377318%28v=vs.85%29.aspx
Niyawa
26th December 2012, 18:48
Which GPU and OS are you using? I'll try to reproduce that, but I have some doubts whether I'll be able to. FWIW, it might have to do with which video decoder you're using. Is it the same in MPC-HC and PotPlayer?
I'm using Windows 8 x64, my GPU is a Intel Graphics HD 4500. I'm using the same setup as my guide, so LAV Video decoder.
pankov
26th December 2012, 19:37
Since I'm a bit late to the testing and feedback I'll only respond to the questions about the options that are still present in madVR
(2) "use a separate device for presentation". This was and still is enabled by default. It used to be a good method to reduce glitches with older NVidia drivers. I'm wondering if this option is still beneficial today with both NVidia and AMD GPUs. I've been told this option can make problems for NVidia Optimus, so I'm wondering whether I should disable it by default.
I find this option useful and for my setup it's better to have it enabled. When I disable it I get actual dropped frames when downscaling (1080i to 671x382 for example) in windowed mode. From the OSD I see that the backbuffer queue is 0-3/3 and the render queue is 2-5/8 when the option is OFF and 2-3/3 and 5-6/8 when the option is ON while the GPU usage (monitored with GPU-Z) is virtually the same 81-84%. So I think from GPU load point of view there is no difference but using the same device for presentation somehow interferes with the rendering ... at least on my setup (NVIDIA).
(3) "use a separate device for DXVA processing". This is a rather new option, introduced recently. I've got one report that it helped. So I wonder if I should enable it by default. But I guess this might also make problems with NVidia Optimus (because it's similar to (2), see above). Right now I'm wondering whether maybe I should combine options (2) and (3) into one, so that I'm either using only 1 device for everything, or 3 devices, one for rendering, one for presentation and one for DXVA processing. Thoughts?
Generally I don't use DXVA so I'm not used to it and I'll have to make additional test and report later.
(4) "enable windowed overlay". When I originally implemented overlay, it wasn't ready for prime time yet, so I disabled this by default. But since its introduction, I have applied lots of fixes, so now it seems to work very well (only for NVidia and Intel, unfortunately). It works so well IMHO that I'm reevaluating whether I should enable this by default (not for AMD, obviously). Any thoughts on this?
Well, I do see a few percents improvement in the GPU usage with it enabled (down to 76-79% from 81-84% for the sample that I used in the first test) and it solves the problem that I'm reporting for the first option (empty backbuffer queue) ... and it's pretty stable but there are couple of drawbacks that I'm not so happy about. The first one is the transition between windowed and fullscreen exclusive mode which now takes a bit longer with more visual "quirks" (blinking) than the non overlay mode and the second one is of course the fact that we can no longer take screen shots. I think these two are enough to not enable this mode by default even for NVidia/Intel.
I hope my report is not too late and will be sort of usefull
pankov
26th December 2012, 20:07
Most renderers support this (including madVR), but the media player has to activate it. See here:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd377318%28v=vs.85%29.aspx
I had absolutely no idea. I'll have to look into this.
Does anybody know if there is an option about this somewhere in MPC-HC?
madshi,
I'm happy that you've found a way to improve the Jinc 3 AR chroma upscaling performance but sadly I still can't use it with all content. For example for 24/25/30 FPS it's working without dropped frames but for 50/60i/p content my GPU is not fast enough (I'm talking about upscaling 720p to 1080p)
:(
So I'll be glad when/if you add different profiles for different resolutions (SD/HD 720/HD 1080/4K) you could also support the different framerates as a parameter we the user can select different algorithms for <=30 and >30 for example.
AndreaMG
26th December 2012, 20:57
Does anybody know if there is an option about this somewhere in MPC-HC?
You can give a try to SVP "black bars lighting" function;)
AndreaMG
26th December 2012, 21:01
So I'll be glad when/if you add different profiles for different resolutions (SD/HD 720/HD 1080/4K) you could also support the different framerates as a parameter we the user can select different algorithms for <=30 and >30 for example.
Already asked in the past: he said some kind of scaling function will be implemented in future versions, please be patient:p
petran79
26th December 2012, 21:53
with the newer madshi versions, some video files and subtitles look pixellated when I switch to full screen
eg this one.screenshot was taken exactly as it appears on full-screen. On windowed mode image is smooth.
happens in both Potplayer and MPC . when I use the internal subtitle engine and not VSfilter, they appear smooth
http://www.abload.de/img/test5ckz7.jpg
Though it also might have to do with the fact that directx blitter is not supported on my system in certain emulators.
e-t172
27th December 2012, 00:16
If I use 3dlut file, does it helps correcting gamut at 25/50/75%Saturation points or just at 100% saturation
Yes, 3DLUTs are able to correct intermediate saturation points. They are able to correct any color-related issues, in fact. You should, however, verify that the software you're using to generate the 3DLUT supports your feature.
fairchild
27th December 2012, 02:01
Try changing the scaling factor slightly. Does that fix the issue? The new shaders are for exact 2.000x and 3.000x scaling factors. Do you get those artifacts only with those scaling factors? Or also with others?
How do I change the scaling factor? I'm taking a 720x480 4x3 video and upscaling it to 1920x1080 (which gets scaled to 1680x1080)
cyberbeing
27th December 2012, 02:26
With my GT440 1GB DDR5
_
use a separate device for presentation
Very significant performance improvement, especially when deinterlacing to 60fps.
_
use a separate device for DXVA processing
Significant performance drop when deinterlacing. Constant delayed frames, with queues never completely filling. (only with 0.85.6.0)
Edit: Didn't notice 0.85.6.1, re-testing now.
Edit2: None of the above queue issues in 0.85.6.1, and this setting now improves avg rendering times performance by 13%
_
speed up DXVA deinterlacing at the cost of a little chroma blur
Significantly reduces overall performance, despite it's name. Why was this enabled by default?
(25% higher rendering times, 6% lower deinterlacing times, and 5% higher GPU load. )
Edit3: Ouch, using 0.85.6.1 with both the "use a separate device for DXVA processing" & "speed up DXVA deinterlacing at the cost of a little chroma blur" setting enabled, resulted in 75% higher avg rendering times and constant dropped delayed frames when deinterlacing!
_
Summary of best performance settings for this GPU when deinterlacing 1920x1080i to 60fps and downscaling:
use a separate device for presentation: Enabled
use a separate device for DXVA processing: Enabled
speed up DXVA deinterlacing at the cost of a little chroma blur: Disabled
pie1394
27th December 2012, 02:34
How do I change the scaling factor? I'm taking a 720x480 4x3 video and upscaling it to 1920x1080 (which gets scaled to 1680x1080)
With MPC- Classic or HC or BE, you can use NumPad keys to adjust video's target window size.
In window mode, there are also hot keys for pre-defined ratios for player + video's window size:
Alt-1 ... 50%
Alt-2 ... 100%
Alt-3 ... 200%
Alt-4 ... Auto
fairchild
27th December 2012, 02:45
Thanks pie1394.
So madshi, yes changing the scaling factor causes the artifacts to go away. I was even able to reproduce with a paused image. Increasing or decreasing the width, instantly removes the artifacts, where as making the video shrink or expand vertically (the height) seems to retain the artifacts.
I also popped in a DVD which is also 720x480 4x3 aspect ratio and the same artifacts can be seen.
So going from the default target rectangle of: 240, 0, 1680, 1080 (artifacts)
going to a target rectangle of: 254, 0, 1665, 1080 (no artifacts)
going to a target rectangle of: 225, 0, 1693, 1080 (no artifacts)
madshi
27th December 2012, 02:50
Since I'm a bit late to the testing and feedback I'll only respond to the questions about the options that are still present in madVR
[...]
I hope my report is not too late and will be sort of usefull
Thanks.
How do I change the scaling factor? I'm taking a 720x480 4x3 video and upscaling it to 1920x1080 (which gets scaled to 1680x1080)
In MPC-HC you can use the "NumPad 9" key to slightly zoom into the image. Doing that modifies the scaling factor. Anyway, I think I found the problem. The next build should fix it.
with the newer madshi versions, some video files and subtitles look pixellated when I switch to full screen
I think this should be fixed in the next build.
Very significant performance improvement, especially when deinterlacing to 60fps.
Ok. I've still disabled it by default now, though, cause it results in problems with NVidia Optimus (and similar AMD) setups.
Significant performance drop when deinterlacing. Constant delayed frames, with queues never completely filling. (only with 0.85.6.0)
Edit: Didn't notice 0.85.6.1, re-testing now.
Edit2: None of the above queue issues in 0.85.6.1, and this setting now improves avg rendering times performance by 13%
Ehm, what? I'm confused. With v0.85.6.0 you couldn't even activate this option. That's why v0.85.6.1 was necessary in the first place. Did you really test with v0.85.6.0? Or maybe with v0.85.5? In any case, how this option works didn't change between v0.85.5 and v0.85.6.1 at all. So I wonder why your test results turned upside down!
Significantly reduces overall performance, despite it's name. Why was this enabled by default?
(25% higher rendering times, 6% lower deinterlacing times, and 5% higher GPU load. )
Edit3: Ouch, using 0.85.6.1 with both the "use a separate device for DXVA processing" & "speed up DXVA deinterlacing at the cost of a little chroma blur" setting enabled, resulted in 75% higher avg rendering times and constant dropped delayed frames when deinterlacing!
Ok, I'll disable that option in the next build again. It's a "complex" option. It practically stops madVR from using copyback and instead tries to convert the DXVA output to a format compatible with madVR on the GPU. This *does* consume more GPU power, however it saves CPU power. Furthermore the PCIe bus can be a bottleneck. So it could result in faster rendering, too, depending on where the exact bottleneck is in your system (GPU, CPU, PCIe transfer speed). I've now renamed the option to make it clearer what it does, namely disable copyback.
madshi
27th December 2012, 02:53
Thanks pie1394.
So madshi, yes changing the scaling factor causes the artifacts to go away. I was even able to reproduce with a paused image. Increasing or decreasing the width, instantly removes the artifacts, where as making the video shrink or expand vertically (the height) seems to retain the artifacts.
I also popped in a DVD which is also 720x480 4x3 aspect ratio and the same artifacts can be seen.
So going from the default target rectangle of: 240, 0, 1680, 1080 (artifacts)
going to a target rectangle of: 254, 0, 1665, 1080 (no artifacts)
going to a target rectangle of: 225, 0, 1693, 1080 (no artifacts)
Yeah, that makes a lot of sense. If you do the math, the target rectangle asks madVR to render the video to "left" coordinate 240 and "right" coordinate 1680. So the width of the scaled image is 1680 - 240 = 1440 pixels. The source video is 720 pixels wide. So the scaling factor in X direction is 1440 / 720 = exactly 2x. There's a bug in the current madVR build which incorrectly activates the 2x shader not only for X resampling, but also for Y resampling in this situation. But Y resampling is not a factor of 2x, that's where the artifacts are coming from. This will be fixed in the next build.
madshi
27th December 2012, 02:55
madVR v0.85.7 released
http://madshi.net/madVR.zip
* fixed: new 2x/3x shaders sometimes got activated when they shouldn't
* renamed "speed up DXVA ..." options to "don't use copyback for DXVA ..."
* disabled option "don't use copyback for DXVA deinterlacing" by default now
I really hope that all serious bugs are fixed now.
cyberbeing
27th December 2012, 03:07
Ehm, what? I'm confused. With v0.85.6.0 you couldn't even activate this option. That's why v0.85.6.1 was necessary in the first place. Did you really test with v0.85.6.0? Or maybe with v0.85.5? In any case, how this option works didn't change between v0.85.5 and v0.85.6.1 at all. So I wonder why your test results turned upside down!
You're correct, something is strange with my result, since after re-checking my downloads, both were indeed 0.85.6.1. I suspect the combination of "speed up DXVA deinterlacing at the cost of a little chroma blur" (which was enabled by default) + "use a separate device for DXVA processing" (which I tried enabling first) issue I mentioned in Edit3 was what I was seeing the first time.
ryrynz
27th December 2012, 08:17
Madshi, the blank window Overlay issue I can only get that to occur now when it's enabled before restarting, so don't worry bout it.
Regarding "use a separate device for presentation" is there a preferred setting you think for this? Reason I ask is because I have no flushing set at all and to disable it I need to flush/flush and sleep.
I can't see any obvious performance differences in display times or GPU usage between the two configs but I generally strive for the least amount of work my system has to do to get acceptable output.
No, certain videos do start dropping frames when I have that option disabled. Plays fine with it turned on.
Have you tried changing any flush settings, queues etc to help try to prevent that? Perhaps you can look into if indeed it's truly necessary for you.
glc650
27th December 2012, 09:03
Have you tried changing any flush settings, queues etc to help try to prevent that? Perhaps you can look into if indeed it's truly necessary for you.I need that option (use a separate device for presentation) enabled as well or I get slowly incrementing delayed frames. All my queue and flush settings are at their defaults. 2.4 Core 2 Quad, Radeon 6570, Win 7 x64.
ryrynz
27th December 2012, 09:29
Madshi, pausing playback whilst having the OSD open results in a constant almost 40% GPU usage on my HD3000, not a big deal considering but it does seem excessive.
madshi
27th December 2012, 11:06
Regarding "use a separate device for presentation" is there a preferred setting you think for this? Reason I ask is because I have no flushing set at all and to disable it I need to flush/flush and sleep.
It seems several people have better performance with this option enabled. So I would guess the preferred setting is probably to have it enabled, if your GPU drivers don't have a problem with it.
Having this option enabled automatically forces a "flush & wait" after the last render step. So there's really no difference with flush settings, after all.
Madshi, pausing playback whilst having the OSD open results in a constant almost 40% GPU usage on my HD3000, not a big deal considering but it does seem excessive.
Having the OSD open means that all render queues are emptied every second, so that the paused frame can be updated with the latest OSD information. After emptying the queues, madVR automatically starts working to fill them again. So basically in this state madVR is constantly rendering to fill the queues, then empties them again, then fills them again etc. This isn't really ideal, of course, but then having the OSD on should only be a temporary thing for debugging purposes, so I don't think GPU consumption with OSD on in paused state is very important.
Andy o
27th December 2012, 11:57
Hi madshi, thanks for all the updates. Just a quick one... the file name extensions (23p, 23fps, etc) don't seem to be working anymore. I'm coming from 0.55.2. If you can't reproduce it I'll post a log.
sidi0us
27th December 2012, 11:59
My rendering time doubled with "use a separate device for presentation" disabled, no frame drops or other problems though.
pankov
27th December 2012, 12:02
Andy o,
see the change log.
There was a full rewrite of the file name tags.
Andy o
27th December 2012, 12:42
OK thanks, has this been discussed more in depth though? I'm still adding "refreshRate=23" and nothing happens. Same with "frameRate=23". I don't know what the difference is between those two, either.
Here's the log https://docs.google.com/file/d/0B0La4AV_gSs8ZmdhLVNNV0hMczA/edit (to download the zip go to File-download--stupid google unzips the file right there and obscures a way to download the original zip).
aufkrawall
27th December 2012, 12:57
"Don't use CB for DXVA decoding" extremely lowers GPU usage for me.
Can there be a significant difference in quality with it?
madshi
27th December 2012, 13:11
OK thanks, has this been discussed more in depth though? I'm still adding "refreshRate=23" and nothing happens. Same with "frameRate=23". I don't know what the difference is between those two, either.
Ooops. There's a bug, making the "refreshRate" tag not work. That will be fixed in the next build. I'll not make a new build just because of this bug, though. Use "refresh=23" instead, that should do the trick, I think. Generally, "refreshRate" is a hint to the display mode changer. "frameRate" overwrites/redefines which framerate the original source has. What you really want is probably turning on film mode / IVTC for this video? In that case use "deint=film" instead of the tags mentioned above. That should also make the display mode changer pick 1080p23 in your case.
"Don't use CB for DXVA decoding" extremely lowers GPU usage for me.
Can there be a significant difference in quality with it?
For AMD users this option has no effect at all. For NVidia and Intel users it results in a small chroma blur.
aufkrawall
27th December 2012, 13:20
For AMD users this option has no effect at all. For NVidia and Intel users it results in a small chroma blur.
Ok, thanks. Regarding GPU usage it makes a huge difference with 4k, but not with 1080p. CPU usage isn't really higher either, my 2500k remains in low power state.
michkrol
27th December 2012, 13:29
First of all, thanks for your continued hard work on MadVR. A really good piece of software. :cool:
I've encountered a rather strange bug, happens randomly and with quite specific settings. Here's how to reproduce:
Enable both "use separate device for presentation" and "use separate device for DXVA processing".
Set "DXVA2" for image up-/downscaling.
Play a h264 10bit file in windowed mode, while using downscaling (or upscaling).
The video is "jumping", as if instead of next frame, the previous frame gets rendered.
What I mean is instead of frames 1 2 3 4, you get frames 1 2 1 4 or something.
Same file works fine with one of the "use separate device ..." options disabled or when using either other scaling algorithms or no scaling. Also other files work perfectly.
Link to sample:
www.mediafire.com/?ca88a1buue7g2dy
and log:
www.mediafire.com/?z72h4726xh4v859
Basic system info:
Intel Core i5 3570K
Intel HD 4000 + drivers v2875
Windows 7 (x64)
MadVR v0.85.7
MPC-HC Lite 1.6.6.6391 (32bit of course)
LAV Filters 0.54.1, but also happens if using MadVR's internal decoding
hannes69
27th December 2012, 16:11
Unfortunately I can't reproduce the problem on my PC. But I found one interesting thing. Your log contains this:
Code:
AnalyzeGpuNv12ToRgb(VideoProcessBlt): +, bitdepth: 32, yFactor: 1.00000018, yOffset: 0.00001520, range: 16.00001805..235.00005700
YCbCr -> RGB decoding matrix used by GPU:
1.00000018 0.00000000 1.73250120
1.00000018 -0.21350089 -0.51525045
1.00000018 2.11633475 0.00000000
If I play your sample on my PC, I'm getting this instead:
Code:
AnalyzeGpuNv12ToRgb(VideoProcessBlt): +, bitdepth: 32, yFactor: 1.00000024, yOffset: 0.00000380, range: 16.00000760..235.00005955
YCbCr -> RGB decoding matrix used by GPU:
1.00000024 0.00000008 1.54000108
1.00000024 -0.18300063 -0.45800027
1.00000024 1.81400121 0.00000008
Remember this problem madshi?
I have redone the tests with newest madvr build. I also noticed that I didnīt have newest VGA bios so I flashed the newest one. Donīt know if the change that now happened comes from VGA bios or madvr (donīt even know if decoding matrix has to do with settings in VGA bios...)
DXVA decoding still delivers right colors. And DXVA scaling for BT709 now seems to be the same like in your setup (very similar numbers in decoding matrix:
AnalyzeGpuNv12ToRgb(VideoProcessBlt): +, bitdepth: 17, yFactor: 0.99998474, yOffset: 0.00000000, range: 15.99975586..234.99641418
YCbCr -> RGB decoding matrix used by GPU:
0.99998474 0.00000000 1.53823853
0.99998474 -0.18417358 -0.45913696
0.99998474 1.81320190 0.00000000
Difference now: bitdepth 17 instead of 32 ???
Using DXVA scaling with BT601 content now leads to following numbers:
AnalyzeGpuNv12ToRgb(VideoProcessBlt): +, bitdepth: 17, yFactor: 0.99998474, yOffset: 0.00000000, range: 15.99975586..234.99641418
YCbCr -> RGB decoding matrix used by GPU:
0.99998474 0.00000000 1.73019409
0.99998474 -0.21400452 -0.51620483
0.99998474 2.11410522 0.00000000
The numbers have slightly changed in comparison to old test, but itīs more or less the same decoding matix. I donīt know the numbers for a correct BT601 decoding matrix, but the numbers given are the ones used.
So now DXVA decoding and BT709 DXVA scaling are right, BT601 I donīt know....
Edit: found out something more:
http://www.equasys.de/colorconversion.html
The BT709 decoding matrix is similar to "YPbPr to RGB color conversion for HDTV" and the unknown matrix which is used for BT601 DXVA scaling in my case is similar to "YCbCr to RGB color conversion for HDTV".
Confusing...
bugmen0t
27th December 2012, 17:23
I tried the avisnyth script below to do a 24p to 60p conversion using blending (my first script, so no idea if it's correct).
It causes the madVR render times to decrease massively. How can that be? There must be something wrong, right?
SetMemoryMax(512)
SetMTMode(2)
AssumeFPS(24)
ConvertFPS(36)
SelectEvery(3,0,0,1,2,2)
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last
konakona
27th December 2012, 17:43
I had problems with hi10p 1080p playback(720 worked fine)-i would drop about 50% of frames. (i think rendering queue was almost empty)
I noticed when trying to play back hi10p 1080p anime for testing that it worked just fine untill subtitles (karaoke) started-i tried messing around with gpu and cpu buffers in madvr settings-set them to 16-cpu and 12-gpu-no improvement at all.
then,i messed with sub-pictures to buffer in subtitles options in mpc-hc. Changing it from 5 to 1 did help,althrough i dont have animated karaoke subtitles now,just static ones. Setting it to 0 made the problem to come back.
It doesnt have any impact visual impact on static subtitles but i can now play back those videos just fine.
And so,i have a question-WHY does subtitles buffer have such impact on playing back such content?
im running xp32bit,phenom II x2 3,1ghz and radeon HD4870(1gb version),and 4gb of ddr3 ram.
my screen is set to 76,416hz@1680x1050 (cant yet get it working to 71,928hz). Downscaling i use is AR filter,linear light Catmull-Rom and chroma upsampling is 3-taps Jinc with AR filter.
its mkv file so mpc used haali media splitter,lav video and madFlac. (latest versions of lav and madvr)
shimaflarex
27th December 2012, 18:13
I had problems with hi10p 1080p playback(720 worked fine)-i would drop about 50% of frames. (i think rendering queue was almost empty)
I noticed when trying to play back hi10p 1080p anime for testing that it worked just fine untill subtitles (karaoke) started-i tried messing around with gpu and cpu buffers in madvr settings-set them to 16-cpu and 12-gpu-no improvement at all.
then,i messed with sub-pictures to buffer in subtitles options in mpc-hc. Changing it from 5 to 1 did help,althrough i dont have animated karaoke subtitles now,just static ones. Setting it to 0 made the problem to come back.
It doesnt have any impact visual impact on static subtitles but i can now play back those videos just fine.
And so,i have a question-WHY does subtitles buffer have such impact on playing back such content?
im running xp32bit,phenom II x2 3,1ghz and radeon HD4870(1gb version),and 4gb of ddr3 ram.
my screen is set to 76,416hz@1680x1050 (cant yet get it working to 71,928hz). Downscaling i use is AR filter,linear light Catmull-Rom and chroma upsampling is 3-taps Jinc with AR filter.
its mkv file so mpc used haali media splitter,lav video and madFlac. (latest versions of lav and madvr)
Your problem is the high CPU usage of the MPC-HC internal subtitle renderer.
Disable it and use xy-vsfilter.
konakona
27th December 2012, 18:25
Your problem is the high CPU usage of the MPC-HC internal subtitle renderer.
Disable it and use xy-vsfilter.
dont you think it will decrease quality of subtitles on materials with lower resolution than my desktop?
shimaflarex
27th December 2012, 20:09
dont you think it will decrease quality of subtitles on materials with lower resolution than my desktop?
I personally don't mind too much having the subtitles rendered at the video resolution. MadVR upscaling algorithms do a fine job making them good when stretched. You should also consider that some typesetting rendered with MPC-HC looks different of what it should be, due to it using a different color matrix and not doing a proper resolution upscaling.
When xy-vsfilter devs finish the support for the new rendering interface, it will be able to render subtitles at higher resolution without those problems.
You can, of course, keep using MPC-HC subtitle renderer for SD videos, if you are not having any slowdown with those...
konakona
27th December 2012, 20:26
You can, of course, keep using MPC-HC subtitle renderer for SD videos, if you are not having any slowdown with those...
i only experience slowdowns on hi10p 1080p content,everything else is just fine :3
Andy o
27th December 2012, 23:37
Ooops. There's a bug, making the "refreshRate" tag not work. That will be fixed in the next build. I'll not make a new build just because of this bug, though. Use "refresh=23" instead, that should do the trick, I think. Generally, "refreshRate" is a hint to the display mode changer. "frameRate" overwrites/redefines which framerate the original source has. What you really want is probably turning on film mode / IVTC for this video? In that case use "deint=film" instead of the tags mentioned above. That should also make the display mode changer pick 1080p23 in your case.
Thanks. When I use "frameRate=23" no discernible change is made either, on the CTRL-J OSD I still see the original frame rate of the file. With that file in the log, I did want to do deinterlacing so deint=film does work. But with others, I want to just decimate, they're in 720/60p. I thought "frameRate=23" would have been the same as the old "23fps" option, which worked before for those, but "refresh=23" does work in that case.
Also, why not just leave the "refresh" tag instead of "refreshRate"? It doesn't really need fixing.
pie1394
28th December 2012, 02:27
i only experience slowdowns on hi10p 1080p content,everything else is just fine :3
Such contents are very CPU computation intensive, especially on very high-bit-rated motion scenes.
My mini-server's C2D P8600 (1.6 ~ 2.4GHz) + dual-ch DDR3-1333 is not powerful enough to handle such material, either.
My HPTC is C2D E8400@3.6GHz + dual-ch DDR2-800. There is no problem for this CPU to deal with all Hi10 1080p24 contents.
Since H.264 Hi10 profile is not used in any industrial standard, I guess no graphics chipset vendor even considers to support such mode decoded with the GPU's video bitstream processor. So... Hi10p 1080p24~ needs a more powerful CPU --- at least Core2Duo 3 GHz performance level. (I guess)
leeperry
28th December 2012, 03:20
my only problem is that tags don't work when using the seamless playback feature of PotP so I can't fix my most pesky files. I've checked and Reclock doesn't see the filenames either(the "Creator source filter:" field in the mVR logs being empty)
I still would welcome a SD/HD threshold(as these days there are obviously far more WMV/XVID HD-to-SD 709 encodes around than upscaled PAL DVD's) but I've just been confirmed that the next build of PotP will advertize the first filename when opening a bunch of movies in seamless playback mode so at least tags will work :cool:
Peuj
28th December 2012, 15:43
Hi,
I've tried to reset the settings using "restore default settings.bat" but nothing has changed.
I've looked in the registry to "HKEY_CURRENT_USER\Software\madshi\madVR" and there is only the key "LastSettingsKey".
How can I do the reset?
I'm using the Windows 7 x64.
Thanks
aufkrawall
28th December 2012, 16:45
I found windowed overlay to be very annyong when moving player's window while in a DVD menu, it was unusable for some seconds after.
cafevn
28th December 2012, 17:37
madVR - crash report
ajp_anton
28th December 2012, 22:15
From another forum:
Can someone posts this on doom9, I won't register there for single post:
madVR since 0.85.5 crops mod2 height video to nearest mod4 and resizes back to original resolution.
For example: 1920x866 crops to 1920x864 and stretches to 1920x866.
0.85.4 and older work fine. I tested it thoroughly in latest mpc-hc with LAV filters and also with ffdShow.
small clip: http://www.mediafire.com/?4r6738ub58at761
Correct | Wrong
http://thumbnails101.imagebam.com/22875/e060fe228742445.jpg (http://www.imagebam.com/image/e060fe228742445) http://thumbnails105.imagebam.com/22875/6d097d228742503.jpg (http://www.imagebam.com/image/6d097d228742503)
turbojet
28th December 2012, 22:26
With latest madvr and latest mpc-be auto play works again on extended display, thanks madshi if you fixed it.
ajp_anton: The bottom 2 lines are damaged of every mod2 video I've seen, avisynth problem I think, that one is no exception. It can be really annoying at times if you look for it. I'm glad madvr is cropping to mod4 but wish it wasn't stretching back.
DXVA2 resizing with a little edge enhancement is very pleasing to my eyes, even if it is just bilinear with post-unsharp. I wonder what the more sophisticated resizers would look like with a post-unsharp.
ajp_anton
29th December 2012, 00:47
Addition to the above, after I asked about scaler algo:
I tried Jinc 3 taps and Spline 3 taps both with and without anti-ringing filter, but it didn't change anything.
Add:
That 2px dirty line on the bottom isn't dirty all the time and it's already in the source. I've done 1920x818 encodes which don't have any dirty lines.
Tested it also on another movie (1920x818) which doesn't have any dirty lines, same behaviour (crops bottom 2px and resizes back).
edit to turbojet:
I don't want madVR to crop it. It shouldn't try to protect the user from bad encodes, it's the encoder's job to do the job right in the first place. Even if h.264 somehow inherently sucked at mod2 (which it doesn't) and a codec-based fix is needed, that would be the job of the decoder.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.