View Full Version : madVR - high quality video renderer (GPU assisted)
madshi
8th April 2009, 19:15
http://madshi.net/madVR.zip
madVR v0.82.5
* added: new option to activate deinterlacing if in doubt whether it's needed
* added: new IVTC option to only look at pixels in the frame center
* added: IVTC "cadence breaks" information to OSD; resets with Ctrl+R, as usual
* deinterlacing + IVTC are now always forced on for 60i sources tagged as 24Hz
* improved IVTC cadence logic
* improved DXVA deinterlacing behaviour slightly
* improved display mode change event handling
* improved exclusive -> windowed switch a little bit more
* lots of fixes
You can download old madVR versions here (http://www.videohelp.com/tools/madVR/old-versions#download).
The Intel Media SDK Software MPEG2, VC-1 and h264 Decoder DLL can be download here (http://madshi.net/libmfxsw32.zip).
features:
- high quality chroma upsampling
- high quality scaling (bicubic, mitchell, lanczos, spline etc)
- high quality YCbCr -> RGB conversion
- gamut & gamma correction for display calibration
- full 16bit processing queue
- final 16bit processing result is dithered down to RGB output bitdepth
- bypasses graphics card's video (damage) algorithms
- all work is done via GPU shaders (except madVR's IVTC atm)
- no shortcuts, highest quality has priority over anything else
requirements:
- graphics card with full D3D9 / PS3.0 hardware support
- at least 128MB of dedicated graphics card memory
- Windows XP or newer
known problems / limitations:
- DVD playback with navigation/menu currently only works in XP, but not in newer OSs
- hardware accelerated video decoding (DXVA) is currently not supported
- no manual color controls (brightness, contrast, saturation, hue)
- media player screenshot functionality not supported yet
firewall complaints:
madVR tries to automatically find other PCs in your local network which are also running madVR. If any such PCs are found, you can remotely switch audio and subtitle tracks, jump to specific chapters, etc etc. For this network functionality to work, madVR tries to access the local network, obviously. So if your firewall complains, you know why. If you don't ever plan to use madVR's network functionality, you can safely tell your firewall to block any and all madVR network accesses. Please rest assured, though, that madVR does not upload your private data to a server or anything of that sort. So allowing madVR to access the LAN should not result in any privacy or security problems.
madshi
8th April 2009, 19:16
chroma upsampling comparison:
http://madshi.net/madVR/chroma upscampling comparison 1.png
A picture says more than 1000 words. I don't think I have to comment this, do I? :)
http://madshi.net/madVR/chroma upscampling comparison 2.png
These pictures are 400% enlarged. If you want to see the original 100% images, I've uploaded them here:
ATI - VMR9 - red fonts.png (http://madshi.net/madVR/ATI - VMR9 - red fonts.png)
ffdshow 2867 - red fonts.png (http://madshi.net/madVR/ffdshow 2867 - red fonts.png)
MPC HC YV12 Shader - red fonts.png (http://madshi.net/madVR/MPC HC YV12 Shader - red fonts.png)
Haali Renderer - red fonts.png (http://madshi.net/madVR/Haali Renderer - red fonts.png)
madVR 0.5 - red fonts.png (http://madshi.net/madVR/madVR 0.5 - red fonts.png)
extreme downscaling comparison:
http://madshi.net/madVR/extreme downscaling comparison.png
I'm aware that you usually don't downscale that much. But I still thought that the differences were interesting, so I'm posting them here.
The ffdshow gray background is *not* caused by incorrect settings (like output levels), I've double checked that. The gray background must originate from calculation errors in the scaling algorithm (lanczos, default settings). The ATI VMR9 and Haali Renderer downscaling results might not look that bad on a quick check, but you need to see it in motion! It sparkles like crazy, totally unwatchable. ffdshow's and madVR's downscaling don't sparkle, they're both stable and smooth.
visible benefits of more than 8bit processing:
I've some screenshots to demonstrate that higher than 8bit processing does help in specific situations, but the screenshots are too big to include them in this post, so I'll just post links instead. Please open the 3 links in different tabs of your browser and then switch between them. Please make sure that your browser does not rescale the images, so that there are no additional artifacts added by the browser scaling.
The following screenshots were made with images produced by the "madTestPatternSource" YCbCr test pattern generator. More details about that in this thread:
http://forum.doom9.org/showthread.php?t=146203
Now the comparison images:
ATI - VMR9 - colors.png (http://madshi.net/madVR/ATI - VMR9 - colors.png)
ffdshow 2867 - colors.png (http://madshi.net/madVR/ffdshow 2867 - colors.png)
Haali Renderer - colors.png (http://madshi.net/madVR/Haali Renderer - colors.png)
madVR 0.1 - colors.png (http://madshi.net/madVR/madVR 0.1 - colors.png)
This test pattern consists of colored rectangles which form a smooth full screen color gradiant. Properly displayed you should be able to see the rectangle borders, but you shouldn't see any visible patterns in the color gradiants.
Now if you look at the ATI VMR9 and Haali Renderer result, you do see some kind of pattern. It doesn't look that bad on the screenshot, but in motion it's really ugly, because the pattern changes with every frame. The ffdshow result is even worse. The madVR result is exactly how the test pattern is supposed to look. It also stays stable in motion. The patterns in the color gradiants are caused either by too low processing bitdepth or by rounding or truncating the final processing result down to 8bit. The madVR output is only that smooth because it uses proper dithering.
If you like these kind of comparisons, I'd suggest to try "madTestPatternSource" yourself. It's contained in the madVR archive. Use it to compare image quality yourself with the renderer you're usually using.
ATI - VMR9 - smallramp.png (http://madshi.net/madVR/ATI - VMR9 - smallramp.png)
ffdshow 2867 - smallramp.png (http://madshi.net/madVR/ffdshow 2867 - smallramp.png)
Haali Renderer - smallramp.png (http://madshi.net/madVR/Haali Renderer - smallramp.png)
madVR 0.4 - smallramp.png (http://madshi.net/madVR/madVR 0.4 - smallramp.png)
On a first check these 3 images might not look all that different. But if you look closer you should see two things: (1) The gradiants in the ATI VMR, Haali Renderer and madVR screenshots are smooth from left to right, while there are some unexpected bright bars standing out in the ffdshow gradiant. (2) In the ATI VMR, Haali Renderer and ffdshow screenshots the whole gradiant is covered by very small and faint vertical bars. In contrast the madVR screenshot doesn't show any such bars.
This test pattern works very well to test whether the processing queue beginning with upscaling and ending with final output somewhere somewhen ends up in rounded or truncated 8bit. If it does, you will see those faint vertical bars. The only way to produce a really smooth output with this test pattern is to do scaling and all the processing steps afterwards with more than 8bit. Also the final result must not be rounded or truncated down to 8bit. Instead only proper dithering preserves the smoothness.
madshi
8th April 2009, 19:16
How to use:
(1) First of all you need to use a media player which supports using madVR as a renderer. Your choices are currently MPC-HC, Zoom Player, J.River Media Center 16, PotPlayer and KMPlayer.
(2) madVR only accepts YCbCr 4:2:0 input (YV12, NV12, P010 and P016) and nothing else. So make sure that the decoder you're using actually outputs YCbCr 4:2:0, or else madVR will not work. I've intentionally limited madVR in this way because outputting YCbCr 4:2:0 is simply the best quality option for 99.9% of all content out there.
(3) You can press Ctrl-J to turn the OSD on/off.
(4) If movies stutter for you then maybe your graphics card is not fast enough. In that case you can open the madVR settings dialog (you'll find it somewhere in your media player, at the same place where you also find the settings dialogs of all other filters). There you can turn down image quality somewhat to gain some speed. You can also simply just play with the options to see what effect they have. If you want to do that, I'd suggest trying the "madTestPatternSource", which allows you to easily see differences with the various madVR options enabled/disabled.
If you want to know more about which scaling filters have which effect, you can check out this post:
http://forum.doom9.org/showthread.php?p=1272990#post1272990
For starters, I recommend to use "SoftCubic100" for chroma resampling. IMHO it produces best quality. And it's even quite fast, too. For luma resampling you will have to experiment which filter you like most. Some are sharper than others, but have more ringing artifacts. So it's a matter of taste...
If you run into any trouble, please let me know. If you don't run into any trouble but love what you see, then please let me know, too... :)
madshi
8th April 2009, 19:17
technical discussion:
I've seen many comments about HDMI 1.3 DeepColor being useless, about 8bit being enough (since even Blu-Ray is only 8bit to start with), about dithering not being worth the effort etc. Is all of that true?
It depends. If a source device (e.g. a Blu-Ray player) decodes the YCbCr source data and then passes it to the TV/projector without any further processing, HDMI 1.3 DeepColor is mostly useless. Not totally, though, because the Blu-Ray data is YCbCr 4:2:0 which HDMI cannot transport (not even HDMI 1.4). We can transport YCbCr 4:2:2 or 4:4:4 via HDMI, so the source device has to upsample the chroma information before it can send the data via HDMI. It can either upsample it in only one direction (then we get 4:2:2) or into both directions (then we get 4:4:4). Now a really good chroma upsampling algorithm outputs a higher bitdepth than what you feed it. So the 8bit source suddenly becomes more than 8bit. Do you still think passing YCbCr in 8bit is good enough? Fortunately even HDMI 1.0 supports sending YCbCr in up to 12bit, as long as you use 4:2:2 and not 4:4:4. So no problem.
But here comes the big problem: Most good video processsing algorithms produce a higher bitdepth than you feed them. So if you actually change the luma (brightness) information or if you even convert the YCbCr data to RGB, the original 8bit YCbCr 4:2:0 mutates into a higher bitdepth data stream. Of course we can still transport that via HDMI 1.0-1.2, but we will have to dumb it down to the max, HDMI 1.0-1.2 supports.
For us HTPC users it's even worse: The graphics cards do not offer any way for us developers to output untouched YCbCr data. Instead we have to use RGB. Ok, e.g. in ATI's control panel with some graphics cards and driver versions you can activate YCbCr output, *but* it's rather obvious that internally the data is converted to RGB first and then later back to YCbCr, which is a usually not a good idea if you care about max image quality. So the only true choice for us HTPC users is to go RGB. But converting YCbCr to RGB increases bitdepth. Not only from 8bit to maybe 9bit or 10bit. Actually YCbCr -> RGB conversion gives us floating point data! And not even HDMI 1.4 can transport that. So we have to convert the data down to some integer bitdepth, e.g. 16bit or 10bit or 8bit. The problem is that doing that means that our precious video data is violated in some way. It loses precision. And that is where dithering comes to rescue. Dithering allows to "simulate" a higher bitdepth than we really have. Using dithering means that we can go down to even 8bit without losing too much precision. However, dithering is not magic, it works by adding noise to the source. So the preserved precision comes at the cost of increased noise. Fortunately thanks to film grain we're not too sensitive to fine image noise. Furthermore the amount of noise added by dithering is so low that the noise itself is not really visible. But the added precision *is* visible, at least in specific test patterns (see image comparisons above).
So does dithering help in real life situations? Does it help with normal movie watching?
Well, that is a good question. I can say for sure that in most movies in most scenes dithering will not make any visible difference. However, I believe that in some scenes in some movies there will be a noticeable difference. Test patterns may exaggerate, but they rarely lie. Furthermore, preserving the maximum possible precision of the original source data is for sure a good thing, so there's not really any good reason to not use dithering.
So what purpose/benefit does HDMI DeepColor have? It will allow us to lower (or even totally eliminate) the amount of dithering noise added without losing any precision. So it's a good thing. But the benefit of DeepColor over using 8bit RGB output with proper dithering will be rather small.
TheFluff
8th April 2009, 19:26
Looks like it uses PC levels without any option to expand TV->PC. Other than that, seems to work fine in my extremely brief test. Works fine as a custom renderer in zoomplayer. Quite slow in changing window size and going between fullscreen/windowed mode, but I guess that's to be expected.
(nice job, by the way)
madshi
8th April 2009, 19:31
Looks like it uses PC levels without any option to expand TV->PC. Other than that, seems to work fine in my extremely brief test. Works fine as a custom renderer in zoomplayer.
You're too quick!! :D I'm still working on the description and documentation (see "reserved" posts).
YCbCr -> RGB conversion is done through a 96MB 3dlut file. The 3dlut file shipping with madVR is using PC levels. You can however create your own file with any custom setting you want. Please check out this thread to learn more about this topic:
http://forum.doom9.org/showthread.php?t=139389
leeperry
8th April 2009, 20:04
these test patterns look somewhat familiar :)
awesome project btw! do you plan on adding jitter correction(a la HR) and means to synchronise to the VSYNC fliptime ?
this is the real enemy : http://software.intel.com/en-us/articles/video-frame-display-synchronization
96MB seems quite a lot, why not only 5-6 frames?
hopefully when it'll be mature, James won't mind adding support for it in Reclock :)
EDIT: oh cool it reads LUT's from yesgrey's software :eek:
Rectal Prolapse
8th April 2009, 20:08
madshi, have you tested this with neuron2's VC1/AVC CUDA decoder, or coreavc's CUDA? That can get you back some h/w acceleration. :)
madshi
8th April 2009, 20:32
do you plan on adding jitter correction(a la HR) and means to synchronise to the VSYNC fliptime ?
I'm not sure yet which exact method I'll use to get motion display smooth, but I do plan to make sure that at least with a 1:1 match between source frame and display refresh rate motion display will be smooth. Such a feature is not implemented yet, though. After all, this is just a very first beta release to get some feedback from users with different graphics cards.
96MB seems quite a lot, why not only 5-6 frames?
Those 96MB are spent on the 3dlut file (for YCbCr -> RGB conversion, gamut & gamma correction), not on frame storage!
madshi, have you tested this with neuron2's VC1/AVC CUDA decoder, or coreavc's CUDA? That can get you back some h/w acceleration. :)
I have an ATI card, so I can't test that. However, yesgrey has already tested CUDA + madVR and generally it works, although it seems that with a low range graphics card using both CUDA + madVR at the same time may be too much of a burden for the GPU.
Atak_Snajpera
8th April 2009, 21:21
@madshi
Could you also post screenshot from MPC-HC with enabled shader YV12 Chroma Upscaling (EVR Custom)
leeperry
8th April 2009, 22:02
@madshi
Could you also post screenshot from MPC-HC with enabled shader YV12 Chroma Upscaling (EVR Custom)
the biggest problem w/ EVR is the ugly EE it adds, yet it doesn't show on screenshots :confused:
they must be doing it after the RGB32 mixer, behind the scene. Use LSF in ffdshow, play a video in EVR then in HR on a large screen...they don't look quite similar, the picture in EVR is more 3D-like and its EE algorithm interferes w/ LSF, making the picture way oversharpened(VMR9 has the same problem, but less EE)
a D3D renderer that'd keep the PQ untouched(like HR), use yesgrey's LUT and sync to the VSYNC fliptime is one hell of a terrific idea :devil:
but on Vista, Aero forces the VSYNC constantly...which makes HR jerky to hell...hopefully madshi will find a workaround for this, making it XP compatible too :o
madshi
8th April 2009, 22:04
Could you also post screenshot from MPC-HC with enabled shader YV12 Chroma Upscaling (EVR Custom)
That's a gone one. I've updated the screenshots. You may need to press F5 to reload the images.
In the "Jacques Pibarot" test the MPC-HC YV12 Shader is *almost* as good as madVR. But in the other chroma upsampling test madVR is still in a class of its own.
Atak_Snajpera
8th April 2009, 22:09
@leeperry
What does 'EE' stand for?
madshi
8th April 2009, 22:13
Edge Enhancement, which often produces ringing (typically white ghost lines next to high contrast edges).
leeperry
8th April 2009, 22:14
@leeperry
What does 'EE' stand for?
Edge Enhancement : www.videophile.info/Guide_EE/Page_01.htm
Mark_A_W
8th April 2009, 22:30
Thanks Madshi
I would be awesome if you integrated it with Reclock (sync to V-sync or something). Smoothness is the most important to me (and no tearing!).
Snowknight26
8th April 2009, 22:41
Alternate link to the custom MPC-HC build:
http://stfcc.org/misc/mplayerc.rar
And while I'm at it:
http://stfcc.org/misc/mplayerc.png
Oops. :D
DeepBeepMeep
8th April 2009, 23:46
Many thanks Madshi for this new creation!
However, I am not sure I have understood its added value compared to VMR9/EVR for a typical usage, I mean is there any real benefit to use this renderer if no resize is needed for the playback of a 1080p movie on an 1080p screen using HDMI 1.0?
On a side note I have noticed that when a player that uses the renderer (in my case zoomplayer) is in the background the CPU usage rises to 50% even in pause mode.
yesgrey
9th April 2009, 00:01
Here is the link for the new reclock release that already supports madVR, I've requested it to James (reclock's current developer) and he was so nice to add it imediatelly.:)
http://forum.slysoft.com/showthread.php?t=19931
honai
9th April 2009, 00:29
I just knew madshi was cooking up something, but I suspected he might be the force behind the mysterious SlyPlayer. ;)
This is really amazing work, madshi, thank you very much! It proves once again that when it comes to obsessing about quality nothing beats German engineering. :) And I'm in total agreement, when we can get the best quality why compromise?
One question: Does madVR actually support 10-bit data paths in GPU drivers?
jmone
9th April 2009, 00:51
Is there a list of what apps work with this renderer so far? I'm particulary intereted if anyone has it working with:
- JR Media Center
- Arcsoft TMT V3
Thanks
Nathan
STaRGaZeR
9th April 2009, 04:57
The renderer is just amazing. List of things to improve to make it perfect for me:
- Improve windowed - fullscreen change if possible. Now it takes too much time and the image does some weirdness that's ugly to see.
- Improve load time. It's not that slow but if it can be improved... :p
- Support for MPC-HC shaders or similar.
- Output options ala ffdshow (levels, 601vs709, etc.)
- Stats ala MPC-HC
Mark_A_W
9th April 2009, 05:35
This renderer raises a dilemma...
Do we use:
- MadVR
or
- MPC HC with EVR Custom with Beliyaal's tweaks for smoothness?
I hope this gets "united" with MPC HC, getting all the tweaks that EVR Custom is getting - and eventually replaces EVR Custom as preferred/tweaked renderer in MPC HC.
madshi
9th April 2009, 07:00
I am not sure I have understood its added value compared to VMR9/EVR for a typical usage, I mean is there any real benefit to use this renderer if no resize is needed for the playback of a 1080p movie on an 1080p screen using HDMI 1.0?
Well, even if you don't have to resize, you still get best in class chroma upsampling, a full 16bit processing queue with all its benefits for image quality and best in class YCbCr -> RGB conversion with included gamut & gamma correction. Finally, due to the way madVR works, all the damaging video processing algorithms which graphics card manufacturers like to use, are disabled.
On a side note I have noticed that when a player that uses the renderer (in my case zoomplayer) is in the background the CPU usage rises to 50% even in pause mode.
This does not happen with MPC HC for me. Seems to be a ZoomPlayer specific problem?
One question: Does madVR actually support 10-bit data paths in GPU drivers?
Actual processing is done in 32bit floating point (that's the native processing bitdepth of GPU shaders), but temp buffers used for storing processing results can be either 16bit or 10bit, depending on the madVR settings. Final RGB output bitdepth at this time is always dithered down 8bit, but the down dithering is only done in the very last step. I'm planning to add support for 10bit and 16bit output modes once Windows 7 arrives. The 10bit/16bit switch in the madVR settings only applies to the temp buffers.
Is there a list of what apps work with this renderer so far? I'm particulary intereted if anyone has it working with:
- JR Media Center
- Arcsoft TMT V3
Seemingly: MPC HC (special build), ZoomPlayer and ReClock.
You'll have to ask the JR Media Center and ArcSoft guys about madVR support. Not sure if there's any chance with ArcSoft because they may need to use protected data paths for copy protected material, which madVR doesn't support.
- Improve windowed - fullscreen change if possible. Now it takes too much time and the image does some weirdness that's ugly to see.
Can you describe that weirdness for me? Is there some visible corruption? Or is the image just squeezed for a short time?
- Improve load time. It's not that slow but if it can be improved... :p
I'm not sure if it can be improved much. Reading a 96MB file does take its time.
- Support for MPC-HC shaders or similar.
That will require a combined effort on my side and MPC-HC side, but it should be possible to do. One problem is that I think the best place for some shaders would be in YCbCr space and madVR could offer that to custom shaders, while VMR/EVR can not. So MPC-HC currently does not support YCbCr shaders.
BTW, forgot to mention: Subtitle rendering is currently not supported. That needs to be added, too.
- Output options ala ffdshow (levels, 601vs709, etc.)
- Stats ala MPC-HC
That's already planned.
I hope this gets "united" with MPC HC, getting all the tweaks that EVR Custom is getting - and eventually replaces EVR Custom as preferred/tweaked renderer in MPC HC.
madVR getting united with MPC HC is not in the cards, because I want madVR to be media player independent. You know, although personally I'm using MPC HC for now, some people prefer ZoomPlayer.
But as explained in the first few posts of this thread, I'm planning to work on motion smoothness.
--------------------
Can I get some specific feedback, please? I'm especially interested in playback smoothness? Do you guys get stuttering with madVR? Or is your graphics card fast enough? How smooth or non-smooth is motion display for you currently? Especially if you set display refresh rate to 1:1 match with the source frame rate? Are the Beliyaal special builds a lot smoother for you, or only slightly so? Thanks!
jmone
9th April 2009, 07:14
You'll have to ask the JR Media Center and ArcSoft guys about madVR support. Not sure if there's any chance with ArcSoft because they may need to use protected data paths for copy protected material, which madVR doesn't support.
I've asked the JR Media Center guys - will advise of the response.
??? on the Arcsoft stuff....
madshi
9th April 2009, 07:26
??? on the Arcsoft stuff....
Well, you can ask the ArcSoft guys, too. Maybe they'll add support for it. The problem I see is that ArcSoft can play Blu-Rays and they have an official license for that. Consequently they are forced to protect the Blu-Ray content from being copied. Which means that they can't just use any renderer. After all, madVR could have a hidden feature (it does not) that secretly stores the Blu-Ray video stream to harddisk!
Thunderbolt8
9th April 2009, 07:57
looks great, must test it in the next days.
could you please also add comparison pics to the haali renderer? I guess that its used by many people as their standard renderer (at least for me :D ) thats why I'd like how your renderer compares to it. thanks!
btw. I also like that it displays comparable good quality when downscaling, since I can watch 1080p stuff only on 720p screen here
wozio
9th April 2009, 08:31
chroma upsampling comparison:
http://madshi.net/madVR/chroma upscampling comparison 1.png
A picture says more than 1000 words. I don't think I have to comment this, do I? :)
What was input color space when using VMR9. I never seens such horrible VMR9/EVR output. Did you use YV12 or YUY2? If yes then it is very unfair comparision since on ATI NV12 is color space of choice. It produces very good results near that bad as on your screenshots.
I will check at home later today how it is going on my system.
Regards
Piotr
Hypernova
9th April 2009, 08:57
I tried it and would like to give some feedback. I am no expert or even understand what stuttering is though.
First, the installer bat file does not work here. I have to manually register it.
Second, the output color is certainly different from EVR CP and everything else. I think madVR is wrong though, it kinda "washed out". Output level should be correct though. I tried the TV Level test clip and madVR is certainly not wrong. Or madVR is the only correct one here and all other renderer give me the same wrong so I never notice? I am not sure on that part.
Thrid, I didn't try all scaling method, but Lanczos and Spline both crash.
Finally, it certainly does not smooth. Compare to, say, EVR CP or mplayer.
Well, that's all. I'm on Windows 7 Beta 7000. ATi HD2600 with Catalysis 9.2
madshi
9th April 2009, 09:31
could you please also add comparison pics to the haali renderer? I guess that its used by many people as their standard renderer (at least for me :D ) thats why I'd like how your renderer compares to it.
Argh, another one added. Please use F5 to refresh.
What was input color space when using VMR9. I never seens such horrible VMR9/EVR output. Did you use YV12 or YUY2? If yes then it is very unfair comparision since on ATI NV12 is color space of choice. It produces very good results near that bad as on your screenshots.
I've used the standard which many decoders output by default, which is YV12. I don't think it's unfair. I didn't even know that ATI produces better results with NV12. And if even I didn't know that how do you think an average HTPC user will know that? Still, I'll look into how ATI compares with NV12...
First, the installer bat file does not work here. I have to manually register it.
Hmmm... Did you run the batch with admin rights?
Second, the output color is certainly different from EVR CP and everything else. I think madVR is wrong though, it kinda "washed out". Output level should be correct though. I tried the TV Level test clip and madVR is certainly not wrong. Or madVR is the only correct one here and all other renderer give me the same wrong so I never notice? I am not sure on that part.
It depends on your source. All the various sources use slightly different color formats/specs, different gamma transfer functions etc. madVR by default does what is needed for correct Blu-Ray playback. So for Blu-Ray maybe madVR is the only renderer with the correct colors? For SD content, however, what madVR does by default is incorrect. You can change the way how madVR does colorspace conversion by creating your own 3dlut file by using the "cr3dlut" tool. That gives you all the options you need including correcting the gamut of your display. A future madVR version will offer these settings in the GUI.
Thrid, I didn't try all scaling method, but Lanczos and Spline both crash.
Weird. Could you please try any other besides Lanczos and Spline? Lanczos and Spline both use 3 or 4 taps. All other algorithms use only 2 taps. Maybe that is the difference? On my XPSP2 Lanczos and Spline work fine.
Can anybody else reproduce a crash with Lanczos or Spline activated?
Finally, it certainly does not smooth. Compare to, say, EVR CP or mplayer.
Well, that's all. I'm on Windows 7 Beta 7000. ATi HD2600 with Catalysis 9.2
Ok, thanks for feedback. Improving motion smoothness is on the top of my priority list. However, the non-smoothness might also be caused by the HD2600 being too old/slow. Compared to my (entry level) HD3850, the HD2600 only has 1/3 of the shader power and only half of the memory bandwidth. You can try activating some of the "trade quality for performance" options. Maybe that helps smoothness for you?
madshi
9th April 2009, 09:38
Did you use YV12 or YUY2? If yes then it is very unfair comparision since on ATI NV12 is color space of choice. It produces very good results
I've just retested with ATI NV12. The results are exactly the same as with YV12 for me. Please note that such ugly chroma upsampling artifacts are usually only visible in specific scenes. Especially red fonts on black background.
(MPC-HC, XPSP2, VMR9, HD3850, Catalyst 9.1.)
littleD
9th April 2009, 10:19
Ati 3450
Winxp sp3 drv 9.2
Funny, have no big delay when opening video. But have massive lag when closing player. Sytem freeze for a long moment. Similar behaviour occurs when minimizing.
Win7 7057 drv 9.4
Installing madrenderer requires give exact path to madVideoRenderer.ax file in bat installer. No problems with closing and minimizing.
On both systems small lag when going to fullscreen or back to windowed (connected with aspect ratio). Seeking is fast.
Unfortunatly, i need dxva to work, so i will stick to evr :(
Thunderbolt8
9th April 2009, 10:32
Argh, another one added. Please use F5 to refresh.
thanks! both, haali and madvr look quite similar to each other, apart from that one can see that haali outputs a bit too much red.
but then im not that good on such graphic specific technical stuff, perhaps someone else sees differences?
is it actually possible technically to further improve the graphic quality of your renderer (hinting that it looks similar to haali, so this is basically best what can be achieved)? I mean at some point there must be a limit, when it looks exactly like the 'real' image looks like. but how is it possible that it actually looks different on each renderer? and how it is possible to perhaps make it look even better, but then again its not done by other renderers? (dont understand the process how such things can looks differently)
edit: cant seem to install it (winxp prof sp3), I get "LoadLibrary("madvideorenderer.ax") fehlgeschlagen - Das angegebene Modul wurde nicht gefunden." :S (windows login is listed as computer administrator).
*nvm, got it to work manually*
madshi
9th April 2009, 11:20
thanks! both, haali and madvr look quite similar to each other, apart from that one can see that haali outputs a bit too much red.
but then im not that good on such graphic specific technical stuff, perhaps someone else sees differences?
If you look at the "cF" comparison image from a further distance, the madVR image looks slighty smoother (less jaggied) to me than the Haali Renderer image. The difference is not big, though...
is it actually possible technically to further improve the graphic quality of your renderer (hinting that it looks similar to haali, so this is basically best what can be achieved)? I mean at some point there must be a limit, when it looks exactly like the 'real' image looks like. but how is it possible that it actually looks different on each renderer? and how it is possible to perhaps make it look even better, but then again its not done by other renderers? (dont understand the process how such things can looks differently)
With Blu-Ray the luma (brightness) information is stored in 1920x1080 pixels, however, the chroma (color) information is only stored in 960x540 pixels. So someone somewhere has to upscale those 960x540 chroma information to 1920x1080. There are a multitude of upscaling filters available, all have their advantages and disadvantages. That's why different renderers produce different results. madVR uses a very soft upscaler for chroma to get rid of jaggies. I don't think you can get much better results than what madVR already does right now for chroma upsampling.
Thunderbolt8
9th April 2009, 11:27
does soft here correspond to overall softness/sharpness of the image?
some small things:
- atm it doesnt seem to be possible to take screenshots in mpc-hc? (ffdshow & madvr)
- could you somehow integrate mpc's jitter display? atm it always displays 0ms all the time at playback, would be nice if it could display the actual information like with ffdshow & haali for example.
thanks!
btw. my installation problem seemed to result from a missing d3d .dll file (d3dx9_35.dll), which I had to download manually (dunno why, I have d3dx9_40.dll here though, is it newer?)
Leak
9th April 2009, 11:37
btw. my installation problem seemed to result from a missing d3d .dll file (d3dx9_35.dll), which I had to download manually (dunno why, I have d3dx9_40.dll here though, is it newer?)
Those d3dx9_xx DLLs are the regular Direct3D updates released every two to three months by Microsoft. You should get all of them if you run the DirectX web setup (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=2da43d38-db71-4c1b-bc6a-9b6652cd92a3) again.
(Yeah, it's still DirectX 9.0c, but look at the release date...)
Thunderbolt8
9th April 2009, 11:40
perhaps mine got somehow deleted or corrupted when windows once again crashed :P
btw. regarding all those madVR options (like resampling, dithering etc.) I guess the default choices are those which represent the displayed image most closely 1:1 (and I don't have to worry :D ) ?
madshi
9th April 2009, 11:40
does soft here correspond to overall softness/sharpness of the image?
When doing upscaling "soft" means less jaggies but also less sharpness. Fortunately our eyes are much more sensitive to brightness information than they are to color information. That's why e.g. LimitedSharpenFaster only modifies the luma (brightness) channel, but doesn't touch the chroma, AFAIK. So having soft chroma is actually a good thing. Having an overall soft image quality is not good, though. That's why madVR uses different scaling algorithms for chroma and luma.
- atm it doesnt seem to be possible to take screenshots in mpc-hc? (ffdshow & madvr)
True. Not implemented yet. I'm taking screenshots by doing PrintScreen.
- could you somehow integrate mpc's jitter display? atm it always displays 0ms all the time at playback, would be nice if it could display the actual information like with ffdshow & haali for example.
I don't know what exactly I'd have to do to make that work. I'm also not sure if jitter will make any difference once I implemented smooth motion display.
btw. my installation problem seemed to result from a missing d3d .dll file (d3dx9_35.dll), which I had to download manually (dunno why, I have d3dx9_40.dll here though, is it newer?)
Hmmmm... I guess _40 is newer than _35, but I don't really know why you had _40 but not _35!? Does anybody know?
btw. regarding all those madVR options (like resampling, dithering etc.) I guess the default choices are those which represent the displayed image most closely 1:1 (and I don't have to worry :D ) ?
If you display the source 1:1 in its original size, all luma scaling is turned off. The whole scaling options in the settings dialog have no effect in that situation. If you want to rescale the original resolution to something else, all the various filters have their own advantages and disadvantages, as I already said. E.g. Lanczos is the sharpest of the bunch, but also adds a lot of ringing to the image. Scaling is always a balance act between sharpness, aliasing and ringing. Just play with the filters and choose which looks best to your eyes...
Hypernova
9th April 2009, 11:41
I run the bat file by right click and choose run as admin, but it seems that does not work. Probably a bug on windows/UAC part, maybe. Your bat file work fine when run cmd as admin first then run the bat. So the problem is not on your part. :)
I think the scaling method crash may have something to do with something else entirely and not relate to the scaling itself. The thing is, I can't change the scaling method by go to MPC-HC options->external filter. When I change it there and play a file, it go back to default. When I right click while playing and change it by go to filter->madVR then close the file and reopen it, MPC-HC crash as soon as (I guess) the 96mb is filled and it try to display the video.
I may try what you suggest about the 3dlut later. I don't have a blu-ray file with me, so I can't test anything about that. I can't just use any 1080p video either right?
I would like to have choice in scaling though, so I probably keep checking back on madVR. Anyway, great work so far.
A little more info, I'm on Dell 3008WFP (2560x1600).
Thunderbolt8
9th April 2009, 11:52
I don't know what exactly I'd have to do to make that work. I'm also not sure if jitter will make any difference once I implemented smooth motion display.
I guess it wont make any difference to smooth playback, but to recognize when the movie runs out of sync. you can see it quickly as soon as the numbers pile up that something is working not fast enough, sometimes despite to what windows cpu load screen tells.
as it seems here, the fps numbers of movies I tried partially seem to vary. sometimes its ~24, another time > 30. it seems like when the system is not fast enough, then playback & displayed fps rate speeds up? haali renderer for example then slows down.
so jitter display would be a nice thing to spot speed problems on a quick & safe to tell glance, while otherwise it seems to be a bit more of guessing ("is this already running too slow/fast?") to be really sure (I'd compare it to the delay guessing of thd tracks of old eac3to versions, when correct delay for truehd wasnt yet supported)
wozio
9th April 2009, 12:38
I've used the standard which many decoders output by default, which is YV12. I don't think it's unfair. I didn't even know that ATI produces better results with NV12. And if even I didn't know that how do you think an average HTPC user will know that? Still, I'll look into how ATI compares with NV12...
For me average user also doesn't know how to use different than standard renderer and he doesn't know what the hell renderer is ;)
Custom renderers are for enthusiasts and changing output color space is easy for them.
If you want any hardware acceleration working best on ATI you must use NV12, be it hardware decoding, deinterlacing, post processing or color conversion. All current commercial decoders use nv12 on ATI.
Regards
Piotr
Will this work on popular integrated video card Intel GMA X3100/X3000 (http://en.wikipedia.org/wiki/Intel_GMA#Table_of_GMA_graphics_cores_and_chipsets)?
noee
9th April 2009, 13:11
Here is some SD feedback, upscaled to 1080P, playback on a 1080P monitor. All of my source playback is AVC MKVs, 23.976fps.
XPSP3, Reclock, ATI HD2600 XT, CCC9.2, using MPC_HC's internal decoders.
I used the following settings to create the 3DLUT:
Input_Bit_Depth 8
Input_Video_Format NTSC_DVD YCbCr
Output_Bit_Depth 16
Output_Video_Format sRGB RGB_Video
With default upscaling, I get substantial tearing at 24Hz. Switching to 3tap Lanzcos or Spline helps. Haven't tried any other settings. When I switch to 60Hz, the tearing goes away. Vsync correction with Reclock does not seem to help so far.
Image detail is outstanding, I can't seem to see that EVR-CP is any smoother, but I have some 1080P home videos (AVCHD) and I will build a 3DLUT for those and try with those next.
tetsuo55
9th April 2009, 13:28
Would it be possible to get DXVA working with madVR?
You would obviously loose some of the extreme quality, but it could never be worse than VMR9/EVR
haruhiko_yamagata
9th April 2009, 13:31
Great work, specially the dithering is impressive. ffdshow's output is inferior just because it does not have dithering. I'm sure ffdshow converters calculate in 10bit and round to 8bit.
With "Allow output format change during playback" checked and "Connect to compatible filters only" unchecked,
I found two issues,
I cannot toggle resize during playback.
I cannot play DVD at all (DVD: Macrovision Fail) whichever the decoder is.
Reconnecting filters is the most difficult and important step in DirectShow.
Each video renderer has its own API to reconnect, and most open source DirectShow filters have workaround for each video renderer. This is a big mess. I don't want to add new workaround in ffdshow.
Please simulate one video renderer's behavior so that we don't have to code too much.
Also please document how to reconnect with your video renderer.
You may want to check out our svn and read Tffdecoder.cpp TffdshowDecVideo::reconnectOutput (which is a mess) or DScaler5's DSVideoOutPin.cpp.
My video card is nVidia 7900GS.
Dark Shikari
9th April 2009, 13:47
Great work, specially the dithering is impressive. ffdshow's output is inferior just because it does not have dithering.As I'm currently stuck with a burnt out graphics card, I have to output in RGB16 and as far as I can tell it most definitely has dithering.
honai
9th April 2009, 13:57
@Dark
this is not about dithering to RGB16, but dithering from YV12 (i.e. floating point) to RGB24/32. What you observed is something totally different, namely GDI dithering from RGB24 to RGB16. ;)
Mark_A_W
9th April 2009, 14:20
madVR getting united with MPC HC is not in the cards, because I want madVR to be media player independent. You know, although personally I'm using MPC HC for now, some people prefer ZoomPlayer.
But as explained in the first few posts of this thread, I'm planning to work on motion smoothness.
--------------------
Can I get some specific feedback, please? I'm especially interested in playback smoothness? Do you guys get stuttering with madVR? Or is your graphics card fast enough? How smooth or non-smooth is motion display for you currently? Especially if you set display refresh rate to 1:1 match with the source frame rate? Are the Beliyaal special builds a lot smoother for you, or only slightly so? Thanks!
I'm one of those who prefer Zoom Player, but Beliyaal's MPC HC builds are definitely smoother for me. It's enough to make me jump ship (but I am getting a glitch about once per hour).
With Beliyaal's build the Reclock tearing test line has less "micro" judder than Haali Renderer in ZP.
My setup:
Q6600
HD2600XT
Vista32
CRT monitor/projector running 1920x1080 interlaced at 95.904hz exactly.
CoreAVC for AVC
FFdshow using WMV9 decoder for VC-1
(Therefore no DXVA...ever!!)
Ffdshow doing RGB HQ for Haali Renderer
Reclock
Madflac for Flac (of course ;) )
With MadVR I get slight stutters and tearing. The tearing is odd, there are about 5 little tears, rather than the more normal big single tear towards the top of the screen (I get that with EVR back on XP).
If you can get it as smooth as Beliyaal's MPC builds, I'll be as happy as a pig in poo. :D It really sets the standard.
leeperry
9th April 2009, 14:23
test line has less "micro" judder than Haali Renderer in ZP.
from my experience, ZP's HR presenter just doesn't work.
MPC's HR presenter is far better(KMPlayer uses the same "borrowed" code).
Thunderbolt8
9th April 2009, 14:24
another thing, the subtitles field is greyed out in mpc-hc when rightclicking into the picture, while its selectable with haali (already reinstalled vsfilter after replacing the mediaplayer .exe file)
STaRGaZeR
9th April 2009, 14:27
Can you describe that weirdness for me? Is there some visible corruption? Or is the image just squeezed for a short time?
Yep, that's it. Also the image is frozen for 0.3 seconds or so.
That will require a combined effort on my side and MPC-HC side, but it should be possible to do. One problem is that I think the best place for some shaders would be in YCbCr space and madVR could offer that to custom shaders, while VMR/EVR can not. So MPC-HC currently does not support YCbCr shaders.
BTW, forgot to mention: Subtitle rendering is currently not supported. That needs to be added, too.
No problem if the shaders are custom, but it'll be nice if they could be managed (toggle, change between them, etc.) with keyboard or remote controller shortcuts.
That's already planned.
Cool.
TinTime
9th April 2009, 15:09
My first impressions...
Testing
I thought the best way to test madVR would be to sit down and watch a movie all the way through, rather than trying lots of different clips.
Hardware
Athlon X2 5000, Nvidia 8600GT (512MB) feeding 1080p plasma telly (DVI to HDMI) at 24Hz (23.998Hz according to ReClock).
Software
Win XP SP3, Zoom Player, CoreAVC with CUDA enabled, ReClock in S/PDIF passthrough mode. Er, and madVR ;)
Source file
mkv ("Revenge of the Sith" if anyone cares), 1024x576 h264, DTS audio. Encode from a PAL DVD but a/v slowed to 23.998Hz (prior to playback) to match my refresh rate as reported by ReClock.
Installation
No problems here - worked as advertised, but I guess those having difficulties were using Vista.
Playback
Initial brightness levels were off for me so there was a brief interlude where I went from "What on earth is cr3dlut?" to generating a new 3D LUT (PAL DVD to RGB Video) :D
I then watched the film. As I said above the source file frame rate matches the display refresh rate.
So after 2hrs+ I'm happy to report that playback was smooth for me - no stuttering, no tearing. General image quality is as good as I've ever seen, although I need to calibrate my display or play around with different 3D LUTs to get the levels correct (low blacks are currently too bright). EDIT - changed output format from sRGB to Blu-ray and this sorted it. I need to read up on cr3dlut. If I use VMR9 or Haali at 24Hz (but not 50Hz or 60Hz) I get occasional tearing and stuttering when I first start playback which can be fixed by pausing the video. This never happened with madVR. Not bad for v0.1 beta :)
No problems either running madVR and CoreAVC CUDA at the same time, although I haven't tried any HD video yet.
STaRGaZeR mentioned weirdness when going from windowed to fullscreen. When I do this there is a split second where the windowed image is displayed within the fullscreen image - I think. It is for a split second so it's kind of hard to tell, and not a problem as far as I'm concerned unless it's a symptom of a bigger issue.
Conclusions
Very impressive and no problems for me on my system so far. I went on a bit of a clicking frenzy, trying all the resizers and turning performance options on and off at random, and none of the settings caused any crash.
And so to the inevitable feature request... In the future you mentioned adding support for user switching between 3D LUTs. I have absolutely no idea whether this is possible or not, but what would seem to be ideal for playback purposes would be to flag mkv files somehow to indicate to madVR which 3D LUT to use when playing it back. Perhaps the appropriate LUT could be attached to the mkv and madVR would load it from there? That's for further down the line anyway.
So that's it for now - another quality product :thanks:
yesgrey
9th April 2009, 16:27
madshi, have you tested this with neuron2's VC1/AVC CUDA decoder, or coreavc's CUDA? That can get you back some h/w acceleration. :)
I've tested this, but it did not worked fine. My card is a GF8600GT 256MB, but I think it's not lack of GPU power, it seems to be some kind of "fighting" for resources between CoreAVC with CUDA and madVR. One user with a GF 8600GT 512MB reported good results, so, perhaps it's only a "fighting" for graphics card memory (mine has only 256MB)...
List of things to improve to make it perfect for me:
- Improve load time. It's not that slow but if it can be improved... :p
It's in our plans adding compression for the 3DLUT files to reduce size and (hopefully) improve load time.
I'm planning to add support for 10bit and 16bit output modes once Windows 7 arrives.
Some graphics cards seems to already support 10bit output mode when using fullscreen (Belyiaal add that to mpc-hc evr-cp).
Or is the image just squeezed for a short time?
I also see this.
BTW, forgot to mention: Subtitle rendering is currently not supported. That needs to be added, too.
Yes, It would be good. Currently I have to keep using ffdshow's subtitle rendering.
Thunderbolt8
9th April 2009, 16:36
regarding speed: I played a few HD remuxes now with madVR and ffdshow on my system (c2d @2800, 400MHz bus + 7600GT). most stuff starts around 30fps and then very(!) slowly pends down to little above 24fps (but mostly doesnt reach 23.9 fps). but the picture is actually never really fluid and theres can also a very little audio delay perceived. guess my hardware is a little too slow, at least for v0.1. seems to be a little faster with coreavc instead of ffdshow, but not as fluid as ffdshow or coreavc with haali.
edit: another little things, step forward (right arrow button) in mpc also doenst work yet ;)
leeperry
9th April 2009, 16:39
In the future you mentioned adding support for user switching between 3D LUTs. I have absolutely no idea whether this is possible or not, but what would seem to be ideal for playback purposes would be to flag mkv files somehow to indicate to madVR which 3D LUT to use when playing it back. Perhaps the appropriate LUT could be attached to the mkv and madVR would load it from there? That's for further down the line anyway.
well, one LUT for SD/one for HD would do IMHO(like <1024 horizontal>)
noone can guess if you're watching US, PAL or HDTV gamut stuff...so shortcuts in the start menu would enable you to change that(by renaming/decompressing), because having (2x96)x3 is nearly 600MB of LUT data.
PS: or maybe they could be compressed?
yesgrey
9th April 2009, 16:43
because having (2x96)x3 is nearly 600MB of LUT data.
That's why we want to add compression...
For example, a 96MB 3DLUT file compressed with winrar at the best compression method could end up to a size of only... 640kB!...
racerxnet
9th April 2009, 16:46
Using MPC-Hc I get a macrovision failure when opening a disk.:scared:
MAK
Win XP SP2
DX updated
ATI 3850 ATI 9.2 drivers
C2 Duo 6320
leeperry
9th April 2009, 16:47
That's why we want to add compression...
For example, a 96MB 3DLUT file compressed with winrar at the best compression method could end up to a size of only... 640kB!...
yeah that's what I use atm on my ramdisk(decompressing if I wanna go PAL/NTSC/HDTV), but it takes 2/3 seconds to unRAR...I'd rather waste 200MB of RAMDISK than wait 3" before each movie opens :o
plus MPC's major point is that it takes 100ms to open up, KMPlayer is so darn slow...my benchmarks are available here : http://www.kmplayer.com/forums/showthread.php?t=11629
PS: oh well, 2x96 of LUT is fine...forget what I said, just setting one LUT for SD/one for HD and we'd be all set :cool:
TinTime
9th April 2009, 17:02
well, one LUT for SD/one for HD would do IMHO(like <1024 horizontal>)
noone can guess if you're watching US, PAL or HDTV gamut stuff
You're right that you can't guess. I know when I create an mkv file what it is though. That's why I thought that if I can tag the mkv in some way (BT.601 or BT.709 I suppose) that madVR could then pick up on this and choose the LUT accordingly. No manual selection then and no assumptions based on resolution.
But as I said before I've got no idea if this is feasible or not, and this is a purely selfish idea based on how I'd like my HTPC to work :)
That's why we want to add compression...
For example, a 96MB 3DLUT file compressed with winrar at the best compression method could end up to a size of only... 640kB!...
Sounds good - thanks for your work too on the LUT side of things!
leeperry
9th April 2009, 17:10
You're right that you can't guess. I know when I create an mkv file what it is though. That's why I thought that if I can tag the mkv in some way (BT.601 or BT.709 I suppose) that madVR could then pick up on this and choose the LUT accordingly.
indeed a tag in the filename would be great, like no tag=SMPTE-C otherwise [EBU]/[REC.709] :)
cyberbeing
9th April 2009, 17:10
Could you make a small change so the properties settings are retained? It would be nice to not have to change the settings every time I load a video.
Another thing that would be nice is some simple statistics that show the achieved framerate, actual framerate, jitter, sync offset, and frame drops (is madVR able to drop frames or does it never drop frames?).
BTW, forgot to mention: Subtitle rendering is currently not supported. That needs to be added, too.
Subtitles are currently working perfectly with VSFilter auto-loading.
Thunderbolt8
9th April 2009, 17:20
yes, but only with autoloading. but then you cant choose between differents subs, for example different ones inside one mkv file or between an internal or an external file.
clsid
9th April 2009, 17:23
Then you are doing something wrong! DirectVobSub (aka VSFilter) supports subtitle switching and works for both embedded and external subs.
Rectal Prolapse
9th April 2009, 18:23
both, haali and madvr look quite similar to each other, apart from that one can see that haali outputs a bit too much red.
I believe this is because haali has the incorrect colorspace conversion for 709. AFAIK, Haali Renderer has always had the wrong colors, which is why I don't use it (I have calibrated displays and I can see the problems hehe).
leeperry
9th April 2009, 18:37
haali has the incorrect colorspace conversion for 709.
it's also wrong for 601....HR in YUY2 is a no no :o
Rectal Prolapse
9th April 2009, 19:09
heh, I didn't know that leeperry!
Anyhow - kudos to madshi for this cool renderer.
leeperry
9th April 2009, 19:14
heh, I didn't know that leeperry!
well, there's some new comers that didn't follow all the previous episodes :D
Dark Shikari
9th April 2009, 19:43
@Dark
this is not about dithering to RGB16, but dithering from YV12 (i.e. floating point)YV!2 isn't floating-point.to RGB24/32. What you observed is something totally different, namely GDI dithering from RGB24 to RGB16. ;)But then why does it still dither even when I use FFDshow for the conversion? ;)
cyberbeing
9th April 2009, 19:46
yes, but only with autoloading. but then you cant choose between differents subs, for example different ones inside one mkv file or between an internal or an external file.
Then you are doing something wrong! DirectVobSub (aka VSFilter) supports subtitle switching and works for both embedded and external subs.
Subtitle switching is working fine over here as well using VSFilter and Haali Media Splitter on MKVs with multiple subtitles. Switching between internal and external subs also is working fine. I think clsid is right, you must be doing something wrong.
TripleH
9th April 2009, 20:12
My findings (all tests was made with remuxed BDs):
Configuration:
Intel Core 2 Quad Q9400
2GB DDR2 800Mhz CL4
Radeon HD 4670 512MB GDDR3
Windows Vista Ultimate SP1 32bit
ATi Catalyst 9.2
FFDShow video decoder, MPC-HC and Reclock latest version
1080p@23.976hz to Optoma HD81 projector
Result:
The video is suffering from massive tearing, and Reclock Vsync correction doesn't seem to work on it (the Vsync cross is always stays at the same area, even if I move the Vsync target position).
Moreover, I've tried setting Reclock hardware access method to both automatic (then it choose DirectDraw) and Direct3D, and the result is the same.
I think it'll be one hell of a renderer when it stables.
cyberbeing
9th April 2009, 21:24
Configuration:
AMD X2 4800+ @ 2.64Ghz
2GB DDR400 @ 440Mhz 2-3-3-6-1T
NVIDIA 7800GTX 512MB
Windows XP SP3 x86
NVIDIA Forceware 182.50
Tested Resolutions:
1920x1080@120Hz, 1280x720@144Hz, 1600x1200@96Hz
on Sony GDM-F520
Software:
CoreAVC(software only)/FFDshow, MPC-HC, Reclock 1.8.4.2
I'm seeing no tearing with or without Reclock. It's not as smooth as Haali Renderer, but since you haven't done any work on smoothness yet, that is to be expected. It is very watchable with the current smoothness, but I will welcome any improvements you are able to make in that area.
Other then the simple changes in my previous post, and the ability to switch between two different LUTs automatically depending on the video resolution, I have no other wishlist features in mind.
BUG:
madVR freezes (locks up) when I check both use 10bit luma & chroma buffer during playback and hit apply. It recovers when I uncheck the options and click apply.
madVR freezes (locks up) when I check use 10bit luma buffer and click apply. It recovers when I uncheck the options and click apply.
madVR crashes the player silently when I check use 10bit chroma buffer and click apply.
Thunderbolt8
9th April 2009, 22:05
Then you are doing something wrong! DirectVobSub (aka VSFilter) supports subtitle switching and works for both embedded and external subs.
hm seems like it. on another system that button is not greyed out, although I did exactly the same on I did on my PC. strange :S
Mark_A_W
9th April 2009, 22:48
My setup:
Q6600
HD2600XT
Vista32
CRT monitor/projector running 1920x1080 interlaced at 95.904hz exactly.
CoreAVC for AVC
FFdshow using WMV9 decoder for VC-1
(Therefore no DXVA...ever!!)
Ffdshow doing RGB HQ for Haali Renderer
Reclock
Madflac for Flac (of course ;) )
With MadVR I get slight stutters and tearing. The tearing is odd, there are about 5 little tears, rather than the more normal big single tear towards the top of the screen (I get that with EVR back on XP).
More info:
I'm watching 1080p BD/HD-DVD transferred to MKV.
And the levels were fine. They were unmolested, with black at 16 and white at 235....just the way they should be ;)
When I play a file with a freshly opened ZP, all is well. But if I try to play another file, or replay the original, ZP just disappears.
I haven't played with the scaling options...because I don''t scale anything (HD on HD baby!).
Thanks Madshi
Mark
vucloutr
9th April 2009, 23:03
..
NVIDIA 7800GTX 512MB
..
BUG:
madVR freezes (locks up) when I check both use 10bit luma & chroma buffer during playback and hit apply. It recovers when I uncheck the options and click apply.
madVR freezes (locks up) when I check use 10bit luma buffer and click apply. It recovers when I uncheck the options and click apply.
madVR crashes the player silently when I check use 10bit chroma buffer and click apply.
I encoutered the same problem with GeForce 7 Series onboard graphics.
silent crash on 10bit luma and/or chroma when hitting apply.
btw: great work madshi !
first eac3to and now this gem. thanks ! ^.^
Rectal Prolapse
10th April 2009, 01:09
Hmmm. If I use Haali Media Splitter + Autoloading VSFilter, the madVR renderer is never loaded. Only the regular Video Renderer is loaded, and the subtitle rendering is awful. If I disable VSFilter.dll, madVR loads fine again. What am I missing?
(I am using an older Haali Media Splitter, from June 2007, the last known Haali splitter that doesn't blow out my speakers when playing LPCM in .m2ts files).
TinTime
10th April 2009, 01:21
Is VSFilter passing out YV12? If not then madVR won't connect.
Rectal Prolapse
10th April 2009, 01:21
Hmm didn't work with latest Haali splitter either.
madshi
10th April 2009, 10:04
Second, the output color is certainly different from EVR CP and everything else. I think madVR is wrong though
You were right after all. There is a bug in madVR's color handling. This will be fixed in the next build.
I think the scaling method crash may have something to do with something else entirely and not relate to the scaling itself. The thing is, I can't change the scaling method by go to MPC-HC options->external filter. When I change it there and play a file, it go back to default. When I right click while playing and change it by go to filter->madVR then close the file and reopen it, MPC-HC crash as soon as (I guess) the 96mb is filled and it try to display the video.
Strange. You don't need to close the file and reopen, though. Changing scaling settings by right clicking during playing should show immediate effect.
If you want any hardware acceleration working best on ATI you must use NV12, be it hardware decoding, deinterlacing, post processing or color conversion.
Well, I've retested and I get ugly chroma upsampling with ATI when using NV12, too. However, Beliyaal has sent me a screenshot of his ATI card which looks a lot nicer. We're not sure yet why he gets different results than I do. Might be due to different OS, driver version or graphics card...
Will this work on popular integrated video card Intel GMA X3100/X3000 (http://en.wikipedia.org/wiki/Intel_GMA#Table_of_GMA_graphics_cores_and_chipsets)?
Technically it should work. But I rather guess that the Intel GMA shaders and memory access speed will not be fast enough for fluid playback. But you can give it a try...
With default upscaling, I get substantial tearing at 24Hz. Switching to 3tap Lanzcos or Spline helps. Haven't tried any other settings. When I switch to 60Hz, the tearing goes away.
The video is suffering from massive tearing
Not sure why you guys get tearing. I've not seen any tearing on my setup. But I'll investigate. I plan to implement a fullscreen mode, which should get rid of any tearing, if all else fails...
edit: another little things, step forward (right arrow button) in mpc also doenst work yet ;)
I know, but I don't know why it doesn't work right now. Will have to see...
Would it be possible to get DXVA working with madVR?
Nope, sorry.
Great work, specially the dithering is impressive. ffdshow's output is inferior just because it does not have dithering. I'm sure ffdshow converters calculate in 10bit and round to 8bit.
With "Allow output format change during playback" checked and "Connect to compatible filters only" unchecked,
I found two issues,
I cannot toggle resize during playback.
I cannot play DVD at all (DVD: Macrovision Fail) whichever the decoder is.
Reconnecting filters is the most difficult and important step in DirectShow.
Each video renderer has its own API to reconnect, and most open source DirectShow filters have workaround for each video renderer. This is a big mess. I don't want to add new workaround in ffdshow.
Please simulate one video renderer's behavior so that we don't have to code too much.
Also please document how to reconnect with your video renderer.
You may want to check out our svn and read Tffdecoder.cpp TffdshowDecVideo::reconnectOutput (which is a mess) or DScaler5's DSVideoOutPin.cpp.
Thanks for the feedback! I'll see what I can do about the reconnect problems. Can you give me a hint what I need to do to make this macrovision error go away? I've no clue right now...
My first impressions...
Thanks!
And so to the inevitable feature request... In the future you mentioned adding support for user switching between 3D LUTs. I have absolutely no idea whether this is possible or not, but what would seem to be ideal for playback purposes would be to flag mkv files somehow to indicate to madVR which 3D LUT to use when playing it back. Perhaps the appropriate LUT could be attached to the mkv and madVR would load it from there? That's for further down the line anyway.
I'm not sure how I will handle that. Theoretically the video bitstream contains information about which color transformation has to be used, but sometimes this information is not available.
Could you make a small change so the properties settings are retained?
That's on my to do list, of course.
BUG:
madVR freezes (locks up) when I check both use 10bit luma & chroma buffer during playback and hit apply. It recovers when I uncheck the options and click apply.
madVR freezes (locks up) when I check use 10bit luma buffer and click apply. It recovers when I uncheck the options and click apply.
madVR crashes the player silently when I check use 10bit chroma buffer and click apply.
I encoutered the same problem with GeForce 7 Series onboard graphics.
silent crash on 10bit luma and/or chroma when hitting apply.
It seems that either your graphics card hardware or the driver you're using doesn't support 10bit temp buffers. I'll need to handle that situation gracefully, of course, but I'll probably not be able to make 10bit work for you.
When I play a file with a freshly opened ZP, all is well. But if I try to play another file, or replay the original, ZP just disappears.
Strange. Doesn't happen with MPC HC, it seems. Will have to check that...
madshi
10th April 2009, 10:05
madVR 0.2 released
http://madshi.net/madVideoRenderer.rar
* fixed: colors were not fully correct
* improved install/uninstall
Thunderbolt8
10th April 2009, 10:37
thanks! :D
haruhiko_yamagata
10th April 2009, 10:52
Thanks for the feedback! I'll see what I can do about the reconnect problems. Can you give me a hint what I need to do to make this macrovision error go away? I've no clue right now...
Well, just random guesses...
For DVD playback, renderers have to implement subpicture input pin. ffdshow does alpha blending in itself, this shouldn't be necessary (only if you use ffdshow) though.
Renderers have to support switches between 16:9 and 4:3 during playback. Even if it is the first picture, it's technically during playback.
You could ask Casimir for support.
Matching_Mole
10th April 2009, 12:41
madVR is really interesting and if you succeed to improve its smoothiness at the level of HR or EVR CP customized by Beliyaal, it will be the best renderer on Windows.
Just a question, do you plan to handle the subtitles like doing VRM9 and EVR?
Thanks.
STaRGaZeR
10th April 2009, 13:40
Well, I've retested and I get ugly chroma upsampling with ATI when using NV12, too. However, Beliyaal has sent me a screenshot of his ATI card which looks a lot nicer. We're not sure yet why he gets different results than I do. Might be due to different OS, driver version or graphics card...
Try with other renderers, in Vista if you use NV12 and EVR Custom, you get bad chroma upsampling. However if you use plain EVR instead you get good chroma upsampling. Weird.
Mike5
10th April 2009, 15:47
XP SP3
Radeon 9700 Pro 128MB
Catalyst 9.1
I can't have madVR working. I tried MPC-HC (special version) and ZP6 with or without the last reclock and get audio but no video for several second, then both players freeze.
I checked YV12 in decoder output (both internal MPC-HC and ffdshow tried) and in Reclock.
Finally I tried Graphedit, changing the video renderer to madVR and get the same behaviour: audio, no video, after a few seconds Graphedit freezes.
Perhaps the video card is too old (it's my workplace PC and dates back to 2002).
Tonight at home I'll try on a recent PC.
Xorp
10th April 2009, 16:21
I get some wackiness trying to play VC1 content:
http://img208.imageshack.us/img208/1112/bad1.th.png (http://img208.imageshack.us/img208/1112/bad1.png)http://img167.imageshack.us/img167/7917/bad2.th.png (http://img167.imageshack.us/img167/7917/bad2.png)
None of those color issues with AVC, but playback is very choppy on higher bitrate stuff, get about 15fps. But CPU is at 100% (C2D @ 3.4ghz)
No issues with MPEG2 stuff it seems.
Graphics card is a 8800GTS 640MB, its the original G80 version so no DXVA or CUDA.
Also, madVR didn't work for me at all with v0.1, just got a black screen.
Keiyakusha
10th April 2009, 16:47
After installing version 0.2, in settings it still shows ver 0.1. Thats normal?
http://www.petaimg.com/u397/858111.png
Mike5
10th April 2009, 18:14
Tonight at home I'll try on a recent PC.
Tried on a E8500, ATI HD 4650 (my HTPC)
XP SP3 Catalyst 9.1
Now it works fine with HD content, quality appears excellent to me. As for smoothness, I need to watch a whole movie.
As for DVD on Hard Disk, if I open the .IFO file, MPC-HC hangs. No problem with single .VOB files.
Windows 7 7048 Catalyst 9.3
Perfect with HD content.
As for DVD on Hard Disk, if I open the .IFO file, I get the error: DVD: Macrovision Fail. No problem with single .VOB files.
So, probably the problems in the workplace PC were due to the old video card, but there is still a problem on DVD.
What's this Macrovision Fail that I have seen reported by others above,too ? It reminds me old analogic stuff.
P.S. Both in XP and Windows 7 madVR needs d3dx9_35.dll to be present in C:\Windows\System32. I downloaded it from the Internet.
Brazil2
10th April 2009, 19:28
I get some wackiness trying to play VC1 content:
http://img208.imageshack.us/img208/1112/bad1.th.png (http://img208.imageshack.us/img208/1112/bad1.png)http://img167.imageshack.us/img167/7917/bad2.th.png (http://img167.imageshack.us/img167/7917/bad2.png)
I got the same but only when the MPC-HC internal VC-1 decoder is used. It's Ok with the Microsoft VC-1 decoder (wvc1dmod.dll).
However I have a 1920*1080 VC-1 video in a MKV container (demuxed from the M2TS with TsMuxer and muxed in a MKV with MKVToolNix) that doesn't want to be displayed with the correct aspect ratio with MadVR and only with MadVR. Aspect ratio is correct with other renderers (VMR and EVR).
Video
ID : 1
Format : VC-1
Format profile : AP@L3
Codec ID : WVC1
Codec ID/Hint : Microsoft
Duration : 1h 37mn
Bit rate : 26.8 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16/9
Frame rate : 23.976 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.539
Egh
10th April 2009, 21:49
madVR is really interesting and if you succeed to improve its smoothiness at the level of HR or EVR CP customized by Beliyaal, it will be the best renderer on Windows.
Oh, someone really started doing the right job! HR is the best, let's see if this renderer can match it ;)
16bit per channel per design is the way to go!!!! I just love it!
As for Beliyaal's or even not customized EVRCP, I love your sarcasm. Just in case you didn't know, both Beliyaal's and SVN versions output junk instead of video on EVRCP on my system. If not Haali or now madVR I'd be stuck with VMR9 on a system with pulls Crysis in medium settings easily....
As for DXVA with modern systems it is not a priority for mainstream PCs, only for nettops and stuff, and even that realistically is a bit too early as first nettop with integrated GeForce 9400M has just been announced.
I will choose CPU&Quality over "Fast, unreliable and limited in functionality" DXVA anytime...
Besides, due to GPU usage on HR and on madVR, much of the quality improvement is achieved on GPU anyway.
I will probably start saving for true 10bit capable LCD panel :)
KoD
10th April 2009, 22:30
Laptop with a Merom Core 2 Duo T5800 (800 Mhz FSB), 2GHz and Nvidia GeForce 9600M GT with 512MB DDR3 dedicated memory graphics.
Media files are played with ZoomPlayer. No ReClock or other similar filters. Using latest "official" notebook drivers from Nvidia's website, no "modded" ones (so no CUDA for video, either).
Good things:
- playback is good, colors seem to be appropriate, no tearing that I was aware of
- loading time is low enough, but it's true it causes a litle desync at the beginning of playback, with sound going on and video playing catch up. However, catching up happens very fast, even with 1080p files. In comparison, Haali's renderer, once it loses sync, it keeps on widening it as playback goes, and never catches it up (well, unless you pause the video and let the buffer fill in, then resuming playback and pausing it again, to allow the buffer to fill in some more, and so on untill you get to around 4 ms, after which Haali's renderer seems to be able to keep sync). madVr catches up sync very fast and keeps it, so this is a great improvement over Haali's behavior. This is most noticeably on laptops, where power management might keep the CPU running at a lower frequency when starting playback, until it figures out the load went sky high and it needs to increase the clock speed.
- subtitles work perfectly with VSFilter. The issues people are reporting are either related to filter management issues on their system, or MPC random bugs (if they're using MPC).
- CPU load is light, however the GPU load is not. I notice that when I look at the temperatures monitor: CPU temps stay low, but GPU ones rise.
- regarding playback smoothness, there are issues, but I don't know if they're ZoomPlayer related or madVR related. Let's explain:
I start a file in ZoomPlayer and playback seems smooth. I stop playback, without closing the player. I start another file, and now playback might be smooth, or it might be jerky (visible on long pans). No matter what I do, like opening another file (but still not having closed ZoomPlayer), I can't seem to get rid of the jerkiness. Now, I close ZoomPlayer. I open ZoomPlayer again and start playing the file I got jerkiness. However, this time playback is smooth...
I should say playback of one file after another in ZoomPlayer is always smooth with Haali's renderer, it doesn't randomly start to get jerky like with madVR.
Features requests:
- having the renderer remember the settings is a must. Each time playback starts, it forgets what the settings were.
- remembering the position of the settings panel on the screen, is also a good thing to have.
Questions:
- how does the filter know whjat .3dlut file to use. What if I have many .3dlut files in the folder where madvideorenderer.ax is, will it load one at random, or will it load only the out16.3dlut one ?
Issues:
- madVR accepts YUY2 input, however it can't handle it and shows a black screen. The proper behavior in this case would be to reject a connection with YUY2 input, not to accept it.
- sometimes, after changing the resizing algorithm in the settings panel, the renderer doesn't show a picture anymore, but only a black screen. This seems to happen randomly. Remember, I'm using ZoomPlayer, so it might be an issue between the two, as well.
- yes, switching from fullscreen to windowed is not very visually pleasing, but we can live with that.
- wrong AR on some anamorphic video mkv files, in conjunction with the "Derived" aspect ratio option in ZoomPlayer. Haali's renderer shows proper behavior.
This is related to the issue haruhiko mentioned: the renderer should accept a change of the aspect ratio during playback and adapt accordingly. Why ? Well, on anamorphic video files (like the one I'm mentioning), during intial graph connection and before playback starts, the advertised biWidth and biHeight in BITMAPINFOHEADER are those of the source size (like, let's say, 688x448), and only as soon as playback starts the desired display size gets entered into biWidth and biHeight (like 768, -448). madVR doesn't catch this change, and ends up displaying the image at an aspect ratio of 688/448 (=1.53571) instead of 768/448 (=1.776785).
One more note: dwPictAspectRatioX and dwPictAspectRatoY members in the VIDEOINFOHEADER2 structure are initialized to a value that almost reflects the correct display AR even before playback, but the value is in fact not very correct (it's rounded up). In the case above, they were dwPictAspectRatioX = 0x000031bf and dwPictAspectRatoY = 0x00001c00, which gives display AR = 1.776646. This might be considered a good enough approximation or not.
Great job with this renderer, by the way. Way to go, madshi !
Finally: login management on Doom9 Forum needs some improvement. Save goodness I had the inspiration to copy to clipboard all this text before pressing the submit button, or I would have lost everything when the forum suddenly decided I was no longer logged in. I learned this behavior from previous experiences, that's why I copied everything to clipboard before trying to submit. It happens if one doesn't enable the "Remember me" option at login.
Final edit: to all the people reporting issues with madVR: try using another player than MPC. You may not like to hear this, but you might be encountering bugs in MPC instead of bugs in madVR.
Snowknight26
10th April 2009, 22:35
I get the same thing that Xorp does except with H.264 content as well. MPC Video Decoder (YUV2) -> ffdshow video decoder (YV12) -> madVR. (Edit: Nevermind, guess it's an MPC Video Decoder issue. Blocking that filter so that only ffdshow does the decoding shows the videlo correctly.)
Also, on a laptop of mine (GM45), MPC-HC freezes and maxes out a single core while its frozen. RAM usage keeps climbing but nothing else happens.
Also, when you go to fullscreen in MPC-HC, it takes up to half a second for the video's AR to adjust to the correct AR.
Egh
10th April 2009, 23:00
This renderer potentially is top#1 choice for video elite ;)
However some issues already: massive CPU load (independent of the videocodec or original resolution), typically uses here in between 60% and 90% CPU, that is on 7900GTX (fastest 7xxx GForce) and E8500 stock freq (3.1GHzX2) Funny enough even when I pause the video it still uses around 50% so I sense a bug here as well ;)
For the same content but with Haali renderer overall CPU usage is typically around 10-15% for 720p AVC content.
So, does it really support older than 8xxx series of GForce of GPUs? If so, why so much CPU%? In order to be really usable here needs to be probably around half of the current load and definitely as minimal as possible whilst paused.
Mark_A_W
10th April 2009, 23:06
Interesting.
I'm not getting any unusual CPU load watching BD's converted to 1080p MKV.
But I am getting major tearing, which I don't get with EVR/VMR9/Haali/etc.
On an ATi 2600XT (which has been fine so far, I don't game).
Thunderbolt8
10th April 2009, 23:25
perhaps it might be optimized more for ATI card, as madshi has no nvidia card (provided that optimization has to be done into that direction and cannot be generally be done for all cards/manufactors by generally optimizing direct3d stuff or something similar). so it could make sense here to have another programmer with nvidia card trying to optimze nvidia playback then?
noee
11th April 2009, 00:23
...
But I am getting major tearing, which I don't get with EVR/VMR9/Haali/etc.
On an ATi 2600XT (which has been fine so far, I don't game).
I have the same card and the same issues here, with SD material inside MKV (AVC) and 1080P material inside MKV (AVC).
I've tried turning all of the "quality" settings off and same tearing results. Perhaps this card just doesn't have the guts?
Mark_A_W
11th April 2009, 00:27
I have the same card and the same issues here, with SD material inside MKV (AVC) and 1080P material inside MKV (AVC).
I've tried turning all of the "quality" settings off and same tearing results. Perhaps this card just doesn't have the guts?
Maybe...but like I said, it's fine with every other renderer on Vista (but not EVR on XP....but that's a bad idea).
It's early days yet, let's see what Madshi can pull out of his hat ;)
Rectal Prolapse
11th April 2009, 00:42
I fixed my VSFilter issue - I had to block several filters: Arcsoft Video Decoder, Cyberlink PDVD8 h264 Decoder, CoreAVC (it has trouble with AR on some videos), etc. and chose FFDShow as the decoder for the target videos (x264). Now it can connect! Naturally, VSFilter is limited by the resolution output by ffdshow - if I leave the resolution untouched and let madVR do the scaling, the video looks quite good, but of course the subtitles are soft and/or jaggy!
I can't wait for the subpicture pin to be implemented in madVR! :)
Hypernova
11th April 2009, 01:53
Dithering is the best indeed. Color from madVR still looks different (and looks wrong) for me, though. I still don't have time to learn about 3dlut file either. But now a lot of people already giving their feedback, I'll just sit back and wait, I think.
Edit: Now I'm spoiled by madVR dithering, could anyone suggest me the setting that give me the closest to what madVR have? I'm using Beliyaal's MPC-HC build with EVR CP right now. Sometimes I use Kovensky's mplayer build with software upscaling to my desktop resolution as well.
ice25
11th April 2009, 09:43
Interesting.
I'm not getting any unusual CPU load watching BD's converted to 1080p MKV.
But I am getting major tearing, which I don't get with EVR/VMR9/Haali/etc.
On an ATi 2600XT (which has been fine so far, I don't game).
Yup quite a bit of tearing here as well, i'm on a 8800 GTS though.
red5goahead
11th April 2009, 10:34
Any Media Portal users in there?
now I'm using Media Portal under Vista with Evr and Aero with an Asus Ati HD 3850 graphic card. I use Slysoft Reclock.
My monitor is a plasma Panasonic 37PV60 it hasn't 24p support only 50 and 60 HZ. so reclock speedup play to Pal mode. No meaningful problem.
the minor problems with this configuration are:
1) with Ati card the secondary monitor in extended desktop mode do not work very well. so when start Media Portal I switch the two monitor and plasma became the primary one.
2) with reclock the evr vsynch does'nt work. I have to use the embedded reclock vsynch correction to get the perfect smooth play (24p to Pal and Pal/25 fps either).
And only with Aero on because without Aero reclock and evr do not work fine. I got stuttering for vysnch problems.
Could be important a combined developer with Slysoft to obtain the ultimate renderer for the perfect and troubleless htpc (very optimistic :D )
yesgrey
11th April 2009, 11:38
This renderer potentially is top#1 choice for video elite ;)
7900GTX (fastest 7xxx GForce)
On an ATi 2600XT
Perhaps this card just doesn't have the guts?
Maybe...but like I said, it's fine with every other renderer on Vista
So the "video elite" want's to run madVR in such old graphics cards?:D
Please remember that madVR needs lot of shader processing power, and the old cards have very few shader processing units... My GF 8600GT only has 16, and it barelly keeps up with it. So, if we really want to use madVR, we should start thinking in upgrading... of course madshi could be able to optimize the code, but in the end it will always be a question of shading power. You have it or not.;)
It would be great if people with more recent cards would test it and post the results, so we could be able to see if it's just our cards that cannot handle it.
Dithering is the best indeed. Color from madVR still looks different (and looks wrong) for me, though. I still don't have time to learn about 3dlut file either.
I can help you with the 3dlut files creation, but you have to be more specific with your problems... Which source, which other renderers are you comparing? video levels or PC levels?
madshi,
are you ok with using this thread for 3dlut discussions, or will you prefer that we discuss 3dlut stuff in another thread?
jj666
11th April 2009, 11:51
So the "video elite" want's to run madVR in such old graphics cards?:D
lol ;-)
It would be great if people with more recent cards would test it and post the results, so we could be able to see if it's just our cards that cannot handle it.
A single 9800GX2 works fine, I observed no "tearing" or anything else out of the ordinary.
Thanks a lot Madshi!
Cheers,
-jj-
Casshern
11th April 2009, 12:24
No fundamental problems here. XP SP3, ATI 2600 PRO 512 MB, Catalyst 9.2, Zoomplayer. No tearing, smoothness is on par with overlay and vmr7 when using reclock. Just some small things:
1) The options do not get saved, and the dialog looks wierd (white boxes)
2) Picture looks a tad to light - according to the 3dlut employed it should expand just as the ATI drivers do. But it seems different. It's not a 16 vs. 0 difference more a 2 vs. 0. Could it be that the ATI level expansion is not very accurate? Or is there still a small inaccuracy in this renderer?
Is there a way to save the resulting RGB frame? Then one could easily compare with the real values...
bye,
Casshern
lol ;-)
A single 9800GX2 works fine, I observed no "tearing" or anything else out of the ordinary.
Thanks a lot Madshi!
Cheers,
-jj-
Mark_A_W
11th April 2009, 12:31
So the "video elite" want's to run madVR in such old graphics cards?:D
Please remember that madVR needs lot of shader processing power, and the old cards have very few shader processing units... My GF 8600GT only has 16, and it barelly keeps up with it. So, if we really want to use madVR, we should start thinking in upgrading... of course madshi could be able to optimize the code, but in the end it will always be a question of shading power. You have it or not.;)
It would be great if people with more recent cards would test it and post the results, so we could be able to see if it's just our cards that cannot handle it.
I can help you with the 3dlut files creation, but you have to be more specific with your problems... Which source, which other renderers are you comparing? video levels or PC levels?
madshi,
are you ok with using this thread for 3dlut discussions, or will you prefer that we discuss 3dlut stuff in another thread?
Yeah....that 2 year old junk ;)
I guess we need to figure out the minimum required card for 1080p video, if it is these cards that are the issue. I was looking at video card prices and for the ~$200 or so I paid for the 2600XT, I can get a 4850 or somesuch.
What's Madshi got (cue re-reading this thread..)? That would be a good place to start!
And yes please, can you create a thread with the basics of creating a 3dlut?
Currently I run a custom gamma curve (hand crafted with VideoEqualiser which a CRT owner in the AVS CRT forum wrote), on a CRT calibrated with HCFR (which was in-turn calibrated against Colorfacts with the help of a friend).
Can I use HCFR to help generate a 3d lut? Does it/can it replace my custom gamma curve?
Please answer in a new thread!
Thanks
Mark
Mark_A_W
11th April 2009, 12:42
Ok, thanks for feedback. Improving motion smoothness is on the top of my priority list. However, the non-smoothness might also be caused by the HD2600 being too old/slow. Compared to my (entry level) HD3850, the HD2600 only has 1/3 of the shader power and only half of the memory bandwidth. You can try activating some of the "trade quality for performance" options. Maybe that helps smoothness for you?
I tested disabling all of preformance options, and it still tears.
The tearing is not very noticable on most scenes - it can be missed at a casual glance, but the Reclock tearing test reveals all. There are about 5 minor tears, spaced up the screen.
Normally tearing is one big tear towards the top of the screen. This is different.
I take your point about the HD2600 series cards. It may be time for an upgrade.
yesgrey
11th April 2009, 13:07
the dialog looks wierd (white boxes)
I think you (like me) might be using another color for your windows backgrounds instead of the default white...;)
Is there a way to save the resulting RGB frame? Then one could easily compare with the real values...
Yes. Use your keyboard PrtSc key and paste it to an image editor. I use Microsoft photo editor and "paste as new image...".
I was looking at video card prices and for the ~$200 or so I paid for the 2600XT, I can get a 4850 or somesuch.
It's better waiting a little... Soon should be released (in May?) the new ATI 4770 which should be slightly slower than the 4850 and should cost ~$100...;)
And yes please, can you create a thread with the basics of creating a 3dlut?
Does it/can it replace my custom gamma curve?
I'm currently adding the custom gamma curves. I will create the thread once it's ready.
Jaja1
11th April 2009, 13:27
First of all, thanks for another great project Madshi.
I tested some AVC Blu-rays on two machines. I'm using the same software setup on both machines XP+SP3, Zoomplayer, Haali splitter and CoreAVC.
On the NVidia 7600GT machine I get 90-100% CPU usage and the image stutters as hell. So I can't conclude whether the vidcard lacks power since the CPU usage alone would result in serious stuttering.
On a NVidia 9500GT on the other hand the CPU usage is normal (about 20-25%) and at first sight the video is smooth. Not very reliable since this is small PC Monitor. Will test this later with my PJ on a large screen.
It would be great if your effort to create smooth pan's would apply not only to 24p but also to 59,94 Hz displays. My projector unfortunately cannot do 24p. Of course you can't resolve the 3:2 judder, but now there are pans from time to time that are so bad that they are hard to watch.
There might be a annoying problem with custom timings on modern vidcards. Powerstrip doesn't support NVidia after the Geforce7 series and the Nvidia drivers are in my experience very unreliable creating custom timings. I do not know about ATI though.
Mike5
11th April 2009, 13:29
It would be great if people with more recent cards would test it and post the results...
I'm going to spend the afternoon trying madVR on a HD 4650, with a projector and a 2.50 mt wide screen. I'll post the results.
Casshern
11th April 2009, 13:46
I noticed no tearing on an AGP 2600 Pro 512 MB passive (MSI). I have set catalyst to activate vsync synchonization if the application does not specify and use zoomplayer with reclock (but without vsync correction). But will check again tonight.
I tested disabling all of preformance options, and it still tears.
The tearing is not very noticable on most scenes - it can be missed at a casual glance, but the Reclock tearing test reveals all. There are about 5 minor tears, spaced up the screen.
Normally tearing is one big tear towards the top of the screen. This is different.
I take your point about the HD2600 series cards. It may be time for an upgrade.
Mark_A_W
11th April 2009, 13:51
I noticed no tearing on an AGP 2600 Pro 512 MB passive (MSI). I have set catalyst to activate vsync synchonization if the application does not specify and use zoomplayer with reclock (but without vsync correction). But will check again tonight.
Ditto with ZP and Reclock.
I tried the CCC V-sync settings. No difference. Reclock tearing test shows tearing.
Video is playing on my secondary monitor, that could be an issue (it is with Haali if Aero is enabled, that causes tearing..Aero gets confused with two monitors).
yesgrey
11th April 2009, 13:51
I'm using the same software setup on both machines XP+SP3, Zoomplayer, Haali splitter and CoreAVC.
Please try Coreavc with and without cuda. With my 8600GT I have to disable cuda.
leeperry
11th April 2009, 14:30
Please try Coreavc with and without cuda. With my 8600GT I have to disable cuda.
I'll try on my GF9600 and will report back, it all works like a charm in HR in 23.976@48Hz...except for that damn jitter that requires many reseeks to catch the VSYNC fliptime properly :devil:
it all works fine w/ 25/29.97fps MKV and any other container, just 23.976 MKV crap out constantly....I think HR/HMS are too tied up together, and there's some glitch in either of those that apparently will NEVER be fixed :(
madVR might very well be the answer to all this Reclock hiccup and offer perfect smoothness OOTB...and if it could have a "compatibility" mode that uses the GUID of another renderer(VMR7/EVR/HR?) it could even work in *ANY* player(PDVD9/TMT3/KMPlayer) :cool:
2009 started well w/ CoreAVC CUDA and all, it might look even better w/ madVR....hopefully we'll also get an english.ini for PotPlayer(new player from the original KMP coder) soon enough :)
yesgrey
11th April 2009, 14:47
I'll try on my GF9600 and will report back, it all works like a charm in HR
But HR does not make such an intensive use of GPU as madVR, and also the memory use in madVR is very high due to the 3dlut (96MB) and all the intermediate buffers at 16bit per component... That's why we need to redefine our working minimuns.
With madVR doing everything in the GPU, we would have more CPU power for software AVC decoding...;)
Egh
11th April 2009, 15:21
But HR does not make such an intensive use of GPU as madVR, and also the memory use in madVR is very high due to the 3dlut (96MB) and all the intermediate buffers at 16bit per component... That's why we need to redefine our working minimuns.
With madVR doing everything in the GPU, we would have more CPU power for software AVC decoding...;)
lolz. CPU if anything is the one to be used here, for madVR. Remember I reported it maxed one of the 3.1GHz cores here whilst paused.
As for memory requirement and so on, with 512mb I have on my grafix card I should expect no problems.
Quote:
Originally Posted by Egh View Post
This renderer potentially is top#1 choice for video elite
7900GTX (fastest 7xxx GForce)
Quote:
Originally Posted by Mark_A_W View Post
On an ATi 2600XT
Quote:
So the "video elite" want's to run madVR in such old graphics cards?
Please remember that madVR needs lot of shader processing power, and the old cards have very few shader processing units... My GF 8600GT only has 16, and it barelly keeps up with it. So, if we really want to use madVR, we should start thinking in upgrading... of course madshi could be able to optimize the code, but in the end it will always be a question of shading power. You have it or not.
It would be great if people with more recent cards would test it and post the results, so we could be able to see if it's just our cards that cannot handle it.
Well, thing is that 7900GTX even though is definately older architecture, but still pulls most contemporary games in DX9 in medium and sometimes even high graphics settings. It renders about 100fps in a Source-engine based game whilst consuming slightly more CPU power than madVR displaying still frame only.
We definitely need some clarification from the developer regarding what shader version it uses and how many shader units are employed simultaneously.
I'm looking into upgrade options and this renderer would fasttrack it :) However I'm looking into the card which is able to produce 10bit colour, as one of my monitors is CRT which is theoretically able to produce deepcolour (few LCD panels are able to do it, and they do cost alot ;))
Betsy25
11th April 2009, 15:27
Congratulations Madshi !
Some more bug fixing and it's definitely a renderer to keep and use !
Can you please update links to the latest version in your top post ?
Thanks a bunch ! :o
yesgrey
11th April 2009, 15:38
However I'm looking into the card which is able to produce 10bit colour
It's not the card, it's the OS. It seems that only Vista and up support the 10bit mode... I've tryed it with XP SP3 and did not work.
one of my monitors is CRT which is theoretically able to produce deepcolour (few LCD panels are able to do it, and they do cost alot ;))
I'm not so sure about it... I always thought that being CRT analog it would be able of higher than 8bit bit depth, but recently I have read that the CRT phosphors limit is 8bit... and even if you feed it more you will not be able to see any difference...
It seems we can only achieve >8bit color with digital displays...:(
Brazil2
11th April 2009, 15:39
MPC-HC freezes and maxes out a single core while its frozen. RAM usage keeps climbing but nothing else happens.
I'm randomly getting the same issue, MPC-HC seems to freeze but in fact it's playing as I can hear the sound but I see no video and after several seconds the memory usage raises up to about 700 MB and then the video is displayed.
I can't find a way to reproduce this each time but it happens to me when I'm successively playing different video formats (Xvid, MPEG2, H264, VC-1) in different containers (AVI, MPG, MP4, MKV, WMV) and with different resolutions (from 512*288 up to 1920*1080).
There is also something wrong when MadVR is used in GraphEdit/GraphStudio.
The caption bar of the MadVR window has no controls (no system menu, no buttons) and it's cropping the video because the whole MadVR window is at the video native resolution but this includes the caption bar.
Screenshots:
With default VMR the whole window is 520*315 but the video part is 512*288 which is the resolution of the video:
http://img135.imageshack.us/img135/4748/vmr.png
With MadVR the whole window is 512*288 including the caption bar which ends up with a cropped video:
http://img10.imageshack.us/img10/7114/madvr.png
In these screenshots you can also notice the difference between colors.
I got the cr3dlut v2 tool but I'm not sure about which parameters to use to create a new 3dlut for SD with MadVR (say for DVD and DVB MPEG2 SD). Please, could anyone post a 3dlut file for this ?
yesgrey
11th April 2009, 16:13
I got the cr3dlut v2 tool but I'm not sure about which parameters to use to create a new 3dlut for SD with MadVR (say for DVD and DVB MPEG2 SD). Please, could anyone post a 3dlut file for this ?
Here is for PAL, and video levels to PC levels expansion:
Input_Bit_Depth 8
Input_Video_Format PAL_DVD YCbCr
Output_Bit_Depth 16
Output_Video_Format PAL_DVD RGB_PC
For NTSC use "NTSC_DVD" and if you don't want video levels to PC levels expansion use RGB_Video.
Soon I will open a thread for cr3dlut helping and discussion...
leeperry
11th April 2009, 16:31
I always thought that being CRT analog it would be able of higher than 8bit bit depth, but recently I have read that the CRT phosphors limit is 8bit... and even if you feed it more you will not be able to see any difference...
It seems we can only achieve >8bit color with digital displays...:(
ARGYLLCMS has a tool to check the LUT accuracy, of course it's 8bit in DVI but it's 10bit in VGA on nvidia cards(and 9 on ATi :o)
but because of the D/A > A/D conversions, and the fact that CRT monitors have legacy onboard IC....prolly it doesn't really matter.
as about sending pure 10bit, well for the same reasons I'd be rather dubious...or maybe w/ 5BNC connectors on professional broadcast equipment.
But HR does not make such an intensive use of GPU as madVR, and also the memory use in madVR is very high due to the 3dlut (96MB) and all the intermediate buffers at 16bit per component... That's why we need to redefine our working minimuns.
With madVR doing everything in the GPU, we would have more CPU power for software AVC decoding...;)
oh sure, doing the RGB32 conversion in 32float, plus applying your LUT's and scaling in spline is a HUGE plus(the YUY2 coeffs in HR are completely off) :eek:
my GF9600GSO is actually a rebadged 8800GS and it's got 96SP(the regular 9600GT has only 64), so w/ an o/c Q6600 it should take the load hopefully :)
Mike5
11th April 2009, 16:44
Ok, I tried with a HD 4650, Win 7, Catalyst 9.3, MPC-HC, Reclock (my display doesn't support 24Hz, so I need it to stretch 23,976/24fps to 25Hz), a 1280x720 projector and a 2.5 mt wide screen.
HD-mkv mostly H.264 720p, some 1080p
No problem of any type. No crashes, no tearing at all (Reclock tearing test is perfect), no glitches.
Quality is very high with respect to EVR(CP), expecially colours. Particularly in "Speed Racer" the difference in colours between the two renderers is impressive. With madVR there is a sort of "higher colour resolution".
Smoothness can be improved. Like other renderers it depends on where you start the playing.
WMV-HD
720p Ok. 1080p gives a distorted and greenish image.
DVD
Impossible to play .ifo files from disk o DVD from drive. It gives DVD: Macromedia Fail. I can't understand what Macromedia has to do with the renderer, but wait some guru to explain me. No problems with single .vob or .mpg files. Quality is approx. on the same level as EVR plus YV12 -> RGB conversion by ffdshow.
Tried also avi, divx, xvid and everything I have with no problems.
Egh
11th April 2009, 16:46
the ARGYLLCMS has a tool to check the LUT accuracy, of course it's 8bit in DVI but it's 10bit in VGA on nvidia cards(and 9 on ATi :o)
but because of the D/A > A/D conversions, and the fact that CRT monitors have legacy onboard IC....prolly it doesn't really matter.
as about sending pure 10bit, well for the same reasons I'd be rather dubious...or maybe w/ 5BNC connectors on professional broadcast equipment.
Fail -- a) DVI standard supports >8bit accuracy (read about dual-link for instance). b) There are monitors with HDMI c) DisplayPort :win:
As for CRTs, there may be some issues but note that normal people don't use cheap CRTs nowadays, so hopefully high-end monitors may display colours a bit better in 10bit mode. Never tried myself so cannot guarantee anything, however I do opt for high-end grafix with deepcolour and HDMI/DisplayPort as for the next upgrade.
Nvidia RAMDAC in 9xxx series is 10bit I think.
Mike5
11th April 2009, 16:50
I forgot to mention I tried several BluRay with AnyDVD HD in background and the results are similat to mkv's (they are all 1080p).
leeperry
11th April 2009, 16:55
Fail -- a) DVI standard supports >8bit accuracy (read about dual-link for instance). b) There are monitors with HDMI c) DisplayPort :win:
of course I meant general consumer DVI equipment.
show me a DVI display that does >8bit and doesn't cost an arm and a leg :rolleyes:
there's some graphic adapters that support 10bit HDMI 1.3(nvidia IGP's), but not too many ppl talk about them...let alone post benchmarks.
leeperry
11th April 2009, 17:50
well, it works just fine w/ CoreAVC CUDA on XP SP3 here(latest DX9/nvidia drivers updates) w/ ffdshow video(LSF/GrainF3 in the avisynth filter) in YV12 on a GF9600GSO(96SP) + ffdshow audio(volume/mixer/Ozone4 winamp plugin)/AC3filter in 32float on an o/c Q6600.
it sucks a helluvalot of CPU cycles when paused, but that's about it....also, it looks very smooth w/ Reclock in 25@48.000Hz :eek:
will try it on the big screen this evening :thanks:
if you could set one LUT for SD, and one for HD I'd be sold...and faking HR's GUID so it'd work in KMPlayer would be the icing on the cake.
PS1: from what I understand CUDA doesn't use the GPU itself, only the VP2 routines.
in the past I was using the gamut conversion PS script(from yesgrey) in HR w/ Avishader() w/o any problem.
PS2: sending a 720p video in 1280*768 is VERY sharp! is it 1:1? or is that to say that HR indeed has a "soft" picture? this point has been thoroughly debated on HCFR :o
madshi
11th April 2009, 20:35
Just a question, do you plan to handle the subtitles like doing VRM9 and EVR?
I've no idea right now. Haven't looked into subtitles yet.
Try with other renderers, in Vista if you use NV12 and EVR Custom, you get bad chroma upsampling. However if you use plain EVR instead you get good chroma upsampling. Weird.
Yes, it's weird. On my PC I can't seem to get any good chroma upsampling from ATI at all, regardless of the renderer. But this whole mess just proves the point of madVR: With madVR video rendering should look 100% the same on every OS, graphics card and driver version (as long as the drivers don't mess up the shaders). Provided that the GPU is fast enough, obviously...
I get some wackiness trying to play VC1 content
Thanks for the report. I've investigated that and it's a clear bug in the MPC Video decoder. It only shows with madVR because if you use a different renderer, the MPC Video decoder usually outputs YUY2. madVR forces it to use YV12 and it seems that the MPC Video decoder bug only shows this way. I've already reported the bug to the MPC HC guys...
None of those color issues with AVC, but playback is very choppy on higher bitrate stuff, get about 15fps. But CPU is at 100% (C2D @ 3.4ghz)
No issues with MPEG2 stuff it seems.
Graphics card is a 8800GTS 640MB, its the original G80 version so no DXVA or CUDA.
You may want to try with the next version which will have an OSD which shows some statistics. That might help us find the reason for why things are choppy for you. 8800GTS sounds powerful enough for me...
However I have a 1920*1080 VC-1 video in a MKV container (demuxed from the M2TS with TsMuxer and muxed in a MKV with MKVToolNix) that doesn't want to be displayed with the correct aspect ratio with MadVR and only with MadVR.
Can I have a small sample, please?
I start a file in ZoomPlayer and playback seems smooth. I stop playback, without closing the player. I start another file, and now playback might be smooth, or it might be jerky (visible on long pans). No matter what I do, like opening another file (but still not having closed ZoomPlayer), I can't seem to get rid of the jerkiness. Now, I close ZoomPlayer. I open ZoomPlayer again and start playing the file I got jerkiness. However, this time playback is smooth...
Not sure where this is coming from. But since I didn't really implement any "smooth motion" features yet, please let me ignore "non-smooth motion" reports for now. I can only do one step at a time... :)
- having the renderer remember the settings is a must. Each time playback starts, it forgets what the settings were.
Of course.
- how does the filter know whjat .3dlut file to use. What if I have many .3dlut files in the folder where madvideorenderer.ax is, will it load one at random, or will it load only the out16.3dlut one ?
Currently always "out16.3dlut".
- madVR accepts YUY2 input
No, it doesn't. At least not on my PC. How did you get it to accept YUY2? Doesn't work for me in GraphEdit...
- wrong AR on some anamorphic video mkv files, in conjunction with the "Derived" aspect ratio option in ZoomPlayer. Haali's renderer shows proper behavior.
Can I have a small sample, please?
So, does it really support older than 8xxx series of GForce of GPUs? If so, why so much CPU%? In order to be really usable here needs to be probably around half of the current load and definitely as minimal as possible whilst paused.
I have about 4-5% on paused. During playback CPU consumption is too high. Don't know why right now, will need to check that. There is no specific requirement for any specific GPU generation. However, obviously the GPU needs to be fast enough and support 16bit textures etc...
perhaps it might be optimized more for ATI card, as madshi has no nvidia card
I'm developing with an ATI card, but yesgrey3 has been beta testing for a while with his (not too fast) NVidia and found no major problems...
I've tried turning all of the "quality" settings off and same tearing results. Perhaps this card just doesn't have the guts?
Not having the guts shouldn't result in tearing, I think. But I'm not 100% sure...
the dialog looks wierd (white boxes)
That's because it seems to be rocket science to ask Windows which background color a themed window has... :( I still haven't found out how to do this properly!
2) Picture looks a tad to light - according to the 3dlut employed it should expand just as the ATI drivers do. But it seems different. It's not a 16 vs. 0 difference more a 2 vs. 0. Could it be that the ATI level expansion is not very accurate? Or is there still a small inaccuracy in this renderer?
I've tested this and found that the pixel values madVR is putting out are exactly what I'm getting on a PrintScreen screenshot. This is not the case for me when feeding VMR9 RGB (!!).
I guess we need to figure out the minimum required card for 1080p video
Yes. Next version might help by giving us a bit more information to work with (OSD).
What's Madshi got (cue re-reading this thread..)?
ATI HD3850. Seems just about fast enough for 1080p24 playback with resizing activated. Planning to upgrade to an ATI HD4770 when it's released (early May).
We definitely need some clarification from the developer regarding what shader version it uses and how many shader units are employed simultaneously.
Shader version 3.0. I'm using HLSL, so I've no idea how many "shader units" my shader code is making use of.
There is also something wrong when MadVR is used in GraphEdit/GraphStudio.
The caption bar of the MadVR window has no controls (no system menu, no buttons) and it's cropping the video because the whole MadVR window is at the video native resolution but this includes the caption bar.
Will check that.
In these screenshots you can also notice the difference between colors.
About colors you have to talk to yesgrey3. As long as madVR uses the 3dlut files correctly (and I think version 0.2 does), everything depends on the 3dlut files.
Ok, I tried with a HD 4650, Win 7, Catalyst 9.3, MPC-HC, Reclock (my display doesn't support 24Hz, so I need it to stretch 23,976/24fps to 25Hz), a 1280x720 projector and a 2.5 mt wide screen.
HD-mkv mostly H.264 720p, some 1080p
No problem of any type. No crashes, no tearing at all (Reclock tearing test is perfect), no glitches.
Quality is very high with respect to EVR(CP), expecially colours. Particularly in "Speed Racer" the difference in colours between the two renderers is impressive. With madVR there is a sort of "higher colour resolution".
:)
WMV-HD
720p Ok. 1080p gives a distorted and greenish image.
With which decoder? With the MPC Video decoder? Try the MS one (see above).
it sucks a helluvalot of CPU cycles when paused
Not for me!!
also, it looks very smooth w/ Reclock in 25@48.000Hz :eek:
I think with a 1:1 match between display refresh rate and source frame rate even the current simple logic implemented in madVR can produce very smooth results. However, as soon as you don't have 1:1, things can quickly get very ugly.
sending a 720p video in 1280*768 is VERY sharp! is it 1:1? or is that to say that HR indeed has a "soft" picture?
I'm not sure if scaling is activated, depends on your media player zoom modes, of course. Try zooming a little to make sure that scaling is activated in order to judge sharpness with activated scaling. Also try the different scalers. Of course Lanczos4 and spline64 are sharper than the others.
I'm not sure if Haali is inherently soft. I was hoping that you guys would test that and report back! What I noticed is that Haali's scaling solution sometimes produces artifacts (ghost lines). That indicates that maybe there's something wrong. Also I'm not sure if Haali is deactivating scaling if no scaling is needed. Of course madVR only scales if necessary. Scaling is even "half" deactivated by madVR if scaling is only needed into one dimension... ;)
Jaja1
11th April 2009, 20:46
Please try Coreavc with and without cuda. With my 8600GT I have to disable cuda.The 7600GT doesn't support CUDA, nevertheless switching CUDA on and off didn't influence the CPU usage.
With the 9500GT I see no difference in CPU usage.
Doesn't the 9500GT support CUDA? I thought the entire 9 series did that. I don't mind, my processor doesn't have a problem with highbitrate AVC decoding.
leeperry
11th April 2009, 20:49
I'm not sure if scaling is activated, depends on your media player zoom modes, of course. Try zooming a little to make sure that scaling is activated in order to judge sharpness with activated scaling. Also try the different scalers. Of course Lanczos4 and spline64 are sharper than the others.
I'm not sure if Haali is inherently soft. I was hoping that you guys would test that and report back! What I noticed is that Haali's scaling solution sometimes produces artifacts (ghost lines). That indicates that maybe there's something wrong. Also I'm not sure if Haali is deactivating scaling if no scaling is needed. Of course madVR only scales if necessary. Scaling is even "half" deactivated by madVR if scaling is only needed into one dimension... ;)
well I've got a video test pattern(encoded by Kazuya) that does exactly that...test whether we got 1:1 mapping : http://rapidshare.com/files/220185543/Dila_720p.mkv.html
but I mean is it a true 1:1 mapping, no lanczos sharpening or anything if the scaler is not enabled? like playing 720p in 1280*768
the ghost lines of HR's internal scaler are due to a bad sum in the PS code(Haali wrote the PS scaler code in MPC, and when Casimir666 set it to 0.98 instead of 1.0...it fixed the glitch : http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/trunk/src/apps/mplayerc/DX9AllocatorPresenter.cpp?r1=380&r2=379&pathrev=380 )
this problem also occurs on nvidia if you set the zoom too high, but it's much worse on ATi's.
well there's always been 2 schools on HCFR, one that swears by HR's smoothness and the other one that finds HR too "soft" compared to EVR/VMR9...which the other side finds "oversharpened" :D
I believe your renderer's sharper than HR(in native res of course), but I'll wait for Kazuya's feedback on this...BTW, when HR says "NN" in its OSD, it's supposed to keep all scaling disabled.
I understand you got a huge TODO list, but adding one LUT for SD/one for HD, and giving the opportunity to fake the GUID would be really awesome(sorry to repeat myself)...would love to have it working in KMP w/ proper 601/709 decoding http://forum-images.hardware.fr/images/perso/otakonleboss.gif
PS: I ran more tests, w/ perfectly matching refresh rates(23.976/24/25@48.000)+Reclock it's just perfectly smooth :eek: ....and it doesn't look oversharpened, so I guess HR is indeed "soft" :o
but until it allows 2 different LUT's for SD/HD, it's not quite usable yet..or maybe w/ a null LUT in madVR and 2x LUT's in tritical's plugin. lemme ask yesgrey
also, while seeking sometimes it missed the VSYNC fliptime...but that's quite rare.
cyberbeing
11th April 2009, 21:03
I just thought I'd mention that with my 7800GTX 512 (faster memory, but slower core then 7900GTX with overall comparable performance), I'm not seeing any of the CPU usage issues that Egh is on 1080p video. CPU usage for madVR seems identical to (and possibly even slightly less then) Haali on my system. CPU usage is 0% when paused, so I'm not having that issue either.
As I mentioned in my previous post I use WinXP SP3, so if Egh doesn't, maybe that is the problem rather then his graphics card.
Also of note is madVR uses ~200MB more RAM then Haali, so if you have high latency or not enough RAM, maybe that could contribute to the problem, but for some reason that seems to be an unlikely cause.
Egh
11th April 2009, 21:40
of course I meant general consumer DVI equipment.
show me a DVI display that does >8bit and doesn't cost an arm and a leg :rolleyes:
there's some graphic adapters that support 10bit HDMI 1.3(nvidia IGP's), but not too many ppl talk about them...let alone post benchmarks.
Well then I'll open you a secret -- most displays are only 6bit native. The other 2bits per channel are achieved by dithering (therefore some color artifacts may be observed). Even for 8 bit proper colour you need to look only for displays with S-IPS or S-PVA matrices, and that is not used in anything below 22" nowadays, and only few models.
leeperry
11th April 2009, 22:08
Well then I'll open you a secret -- most displays are only 6bit native. The other 2bits per channel are achieved by dithering (therefore some color artifacts may be observed). Even for 8 bit proper colour you need to look only for displays with S-IPS or S-PVA matrices, and that is not used in anything below 22" nowadays, and only few models.
you know, I'll tell you another secret....I don't have ANY LCD based display, mostly coz I find this technology really crappy...Darkchip3 DLP/CRT all the way :D
and I'm well aware than most(TN?) panels don't actually show 8bit...I'm not sure what you're trying to prove here, but you just made it to my ignore list :cool:
OK I'm gonna try to play a 2H movie in MPC w/ mVR, hopefully it won't drop like crazy after 1H(like non-D3D VMR9/EVR always do in MPC w/ Reclock)
Egh
11th April 2009, 22:19
I just thought I'd mention that with my 7800GTX 512 (faster memory, but slower core then 7900GTX with overall comparable performance), I'm not seeing any of the CPU usage issues that Egh is on 1080p video. CPU usage for madVR seems identical to (and possibly even slightly less then) Haali on my system. CPU usage is 0% when paused, so I'm not having that issue either.
As I mentioned in my previous post I use WinXP SP3, so if Egh doesn't, maybe that is the problem rather then his graphics card.
I agree that 7800 is just somewhat slower than 7900GTX, however it does take a lot of CPU power here. I tried even SD video in native resolution -- still one of the cores is maxed even when video is paused (around 90% of CPU usage on that core).
Just by scratching my head though I was able to find the cause.
Madshi: bug report #1 here! ;)
Crazily enough, it maxes one of the cores always independent of the actual video (can be even paused) if it is rendered onto non-primary display :eek: I have two monitors, if I move the window from one to another then madVR consumes CPU if the monitor being rendered on is not the current primary. I switched the primary monitors in Nvidia Contol Panel and observed the same behaviour but on the other monitor.
Madshi: bug report #2 here! ;)
If MPC AVC internal is used (no DXVA per definition here), 1920x1080 videos are rendered incorrectly, colors are weird, a yellow bar all the way in the bottom of the frame etc. No such problem if ffdshow avc decoder is used (and fed to YV12). No such problem if 720p video is decoded by internal MPC codec.
madshi
11th April 2009, 22:27
well I've got a video test pattern(encoded by Kazuya) that does exactly that...test whether we got 1:1 mapping : http://rapidshare.com/files/220185543/Dila_720p.mkv.html
but I mean is it a true 1:1 mapping, no lanczos sharpening or anything if the scaler is not enabled? like playing 720p in 1280*768
I find your questions very confusing. First you say you have a test pattern to test 1:1 mapping. Then you ask me if you have 1:1 mapping. Why don't you test it with the test pattern?
Then you ask me if you get 1:1 mapping when playing 720p in 1280x768? How am I supposed to know how your media player is configured? madVR does what the media player asks it to do in terms of scaling. Of course if the media player asks for playback in 1280x720 with a 1280x720 source then madVR does simple 1:1 with no scaling and no sharpening. If the media player asks madVR to scale a 1280x720 source to 1280x768 then madVR does scale, but only in Y direction. Sharpening is currently not applied by madVR at all. There are just softer and sharper scaling algorithms available for selection, which of course are only used if scaling is asked for by the media player...
madshi
11th April 2009, 22:31
Crazily enough, it maxes one of the cores always independent of the actual video (can be even paused) if it is rendered onto non-primary display
Don't know why that is the case. Right now I don't have a second monitor to test this, but sooner or later I should be able to...
If MPC AVC internal is used (no DXVA per definition here), 1920x1080 videos are rendered incorrectly, colors are weird, a yellow bar below etc.
I already replied to this somewhere in my last "monster" reply post.
Egh
11th April 2009, 22:55
I already replied to this somewhere in my last "monster" reply post.
Hmmmm.... which one? :)
In my case colours are totally distorted, not just wrong levels or so. Probably some colour planes problem.
madVR freezes (locks up) when I check both use 10bit luma & chroma buffer during playback and hit apply. It recovers when I uncheck the options and click apply.
madVR freezes (locks up) when I check use 10bit luma buffer and click apply. It recovers when I uncheck the options and click apply.
Regarding that previously reported bug with 10bit, just my experience tells it doesn't recover even if I uncheck 10bit options, then it will crash, silently or not. So yes, older generation cards may have troubles with 10bit buffers apparently.
Mark_A_W
11th April 2009, 23:16
I've narrowed the tearing down on my system (2600XT) to when Zoom Player is on the SECONDARY monitor.
If I switch the primary monitor to the video playback one, it doesn't tear. But it's not smooth, it has little jerks and jumps (yes, I know this will be ignored for now, but just reporting what I found).
Can somebody else with a multi-monitor system try it on the secondary monitor? Preferably at 23.976hz or a multiple thereof. Someone with a beefy videocard would be helpful, to narrrow this down to a secondary monitor issue.
Thanks
Mark
Brazil2
12th April 2009, 00:06
Here is for PAL, and video levels to PC levels expansion:
Input_Bit_Depth 8
Input_Video_Format PAL_DVD YCbCr
Output_Bit_Depth 16
Output_Video_Format PAL_DVD RGB_PC
For NTSC use "NTSC_DVD" and if you don't want video levels to PC levels expansion use RGB_Video.
Thanks for the infos, but as I see you advice to do one for PAL DVD and one for NTSC DVD may I ask you why ? I don't get where is the difference.
Does this also mean that I should create one file per format / resolution ? For instance one for Xvid 512*288, one for H264 1280*720, one for VC-1 1920*1080, etc. I admit I'm a bit lost about how it works...
noee
12th April 2009, 00:08
...
If I switch the primary monitor to the video playback one, it doesn't tear. But it's not smooth, it has little jerks and jumps (yes, I know this will be ignored for now, but just reporting what I found)....
Interesting find, Mark. FWIW, I can duplicate your results, except I don't get the "little jerks". If I set my "secondary" to Primary and playback on it (23.976@24Hz w/Reclock), I get no tearing at all and very smooth playback. Tremendous!
XPSP3, MPC-HC, CCC9.4
Brazil2
12th April 2009, 00:13
Can I have a small sample, please?
Here you go:
http://www.zshare.net/download/58510577a2d908e4/
Cut with DGSplit so I believe it still has the original header.
About colors you have to talk to yesgrey3. As long as madVR uses the 3dlut files correctly (and I think version 0.2 does), everything depends on the 3dlut files.
Yesgrey3 gave me some infos, however I'm afraid I'm still a bit lost about these 3dlut files. It would be nice to have this process automated to avoid confusion and possible mistakes.
Mark_A_W
12th April 2009, 00:14
Interesting find, Mark. FWIW, I can duplicate your results, except I don't get the "little jerks". If I set my "secondary" to Primary and playback on it (23.976@24Hz w/Reclock), I get no tearing at all and very smooth playback. Tremendous!
XPSP3, MPC-HC, CCC9.4
What video card do you have Noee?
leeperry
12th April 2009, 00:34
I find your questions very confusing. First you say you have a test pattern to test 1:1 mapping. Then you ask me if you have 1:1 mapping. Why don't you test it with the test pattern?
Then you ask me if you get 1:1 mapping when playing 720p in 1280x768? How am I supposed to know how your media player is configured? madVR does what the media player asks it to do in terms of scaling. Of course if the media player asks for playback in 1280x720 with a 1280x720 source then madVR does simple 1:1 with no scaling and no sharpening. If the media player asks madVR to scale a 1280x720 source to 1280x768 then madVR does scale, but only in Y direction. Sharpening is currently not applied by madVR at all. There are just softer and sharper scaling algorithms available for selection, which of course are only used if scaling is asked for by the media player...
well, this test pattern can only help to check if the scaling is unchanged...but I find your renderer sharper than HR, and I guess some slight texture processing/luma sharpen/PS script/driver user misconfiguration could make the picture appear sharper on screen....I don't know of any test pattern that can help to spot any post-processing but I'll look further(KMP doesn't rescale)...but prolly it's just that HR is softer, no worries.
anyway my 2H movie went just fine in MPC+Reclock at 25@48.000Hz, so that's cool! if you could find a way to never miss the VSYNC fliptime(triple buffering?), that'd be the final solution for a foolproof Reclock HTPC :)
until you add a LUT management for SD, I will keep madVR for HD movies only...very impressed so far, keep it up :cool:
PS: just to be clear(english not being my native tongue), if I play 720p stuff in 1280*768 in HR, its OSD will show "NN" meaning it simply added horizontal black bars w/o rescaling..but I guess madVR does the same :o
yesgrey
12th April 2009, 00:49
oh sure, doing the RGB32 conversion in 32float, plus applying your LUT's:eek:
The 3DLUT also performs the YCbCr->RGB conversion, and it uses 64bit FP.;)
DVD
Quality is approx. on the same level as EVR plus YV12 -> RGB conversion by ffdshow.
Did you use the same 3DLUT file for HD and DVD? For dvd you should use a different 3DLUT file, so maybe that's the reason you seemed to not like madVR so much with dvds...
Thanks for the infos, but as I see you advice to do one for PAL DVD and one for NTSC DVD may I ask you why ? I don't get where is the difference.
In the example I gave there is no difference, it would be the same for both PAL and NTSC. You only need to differentiate if you want to correct your display's color gamut, but let's leave this for the future cr3dlut thread... for now, use the same file for both.;)
Does this also mean that I should create one file per format / resolution ?
No. Only by video format, and not for all, because some of them use the same file.
leeperry
12th April 2009, 00:55
The 3DLUT also performs the YCbCr->RGB conversion, and it uses 64bit FP.;)
well, OK but the LUT is just a whole bunch of figures, what I meant is that outputting RGB32 off ffdshow/avisynth is not required anymore(so w/ CoreAVC CUDA it's a major relief CPU-wise). LUT's are definitely more GPU-friendly than CPU I think, as the video data is already there and HLSL can work in 64float indeed :devil:
BTW, left side is LSF+PC conversion in MVR(YV12), right side is LSF+PC conversion+t3dlut(w/ MVR's lut) in HR(RGB32) :
http://www.image-load.eu/out.php/t157404_1mvr.png (http://www.image-load.eu/out.php/i157404_1mvr.png)http://www.image-load.eu/out.php/t157403_1hr.png (http://www.image-load.eu/out.php/i157403_1hr.png)
http://www.image-load.eu/out.php/t157406_2mvr.png (http://www.image-load.eu/out.php/i157406_2mvr.png)http://www.image-load.eu/out.php/t157405_2hr.png (http://www.image-load.eu/out.php/i157405_2hr.png)
it's a copy of the RGB32 mixer, so it doesn't tell the whole story...yet the MVR's screenshots yield 10% bigger PNG's and seem a tad darker. I tried w/ the PC conversion in ffdshow, but using a LUT that converts by itself could have been a better idea....but I like to process GrainF3() on PC levels anyway, it looks better.
noee
12th April 2009, 01:14
What video card do you have Noee?
MSI HD2600XT 512MB, passive, stock clocks.
Hypernova
12th April 2009, 06:32
I can help you with the 3dlut files creation, but you have to be more specific with your problems... Which source, which other renderers are you comparing? video levels or PC levels?
Thank you for your offer. On second thought, I think it's defintely TV/PC level problem, except that it's not so clearly one or the other. Here goes:
madVR:
http://img382.imageshack.us/img382/7418/madvrwhite.th.jpg (http://img382.imageshack.us/my.php?image=madvrwhite.jpg)http://img18.imageshack.us/img18/2854/madvrblack.th.jpg (http://img18.imageshack.us/my.php?image=madvrblack.jpg)http://img19.imageshack.us/img19/7817/madvr1080.th.jpg (http://img19.imageshack.us/my.php?image=madvr1080.jpg)http://img23.imageshack.us/img23/7611/madvr720.th.jpg (http://img23.imageshack.us/my.php?image=madvr720.jpg)http://img16.imageshack.us/img16/8082/madvr.th.jpg (http://img16.imageshack.us/my.php?image=madvr.jpg)
and EVR CP:
http://img19.imageshack.us/img19/5905/evrcpwhite.th.jpg (http://img19.imageshack.us/my.php?image=evrcpwhite.jpg)http://img23.imageshack.us/img23/9134/evrcpblack.th.jpg (http://img23.imageshack.us/my.php?image=evrcpblack.jpg)http://img18.imageshack.us/img18/4651/evrcp1080.th.jpg (http://img18.imageshack.us/my.php?image=evrcp1080.jpg)http://img19.imageshack.us/img19/5926/evrcp720.th.jpg (http://img19.imageshack.us/my.php?image=evrcp720.jpg)http://img23.imageshack.us/img23/3310/evrcp.th.jpg (http://img23.imageshack.us/my.php?image=evrcp.jpg)
I'm sorry for jpg's, but the differences should be clear. EVR CP result is consistent with all othe renderers.
My monitor is Dell WPF3008 of DVI, so I think that's PC Level?
Thanks again. I just hope my problem is not so stupid that it's a waste of your time...
Casshern
12th April 2009, 07:43
On catalyst > 9, there is a major problem with multi monitor and reclock, at least with my AGP ATI 2600. Before you just had to set the primary monitor and playback was smooth on that monitor. But starting with the 9 versions, i only get smooth playback if i disable the second monitor altogether. Maybe the new reclocks get confused - but you need it for this renderer.
I've narrowed the tearing down on my system (2600XT) to when Zoom Player is on the SECONDARY monitor.
If I switch the primary monitor to the video playback one, it doesn't tear. But it's not smooth, it has little jerks and jumps (yes, I know this will be ignored for now, but just reporting what I found).
Can somebody else with a multi-monitor system try it on the secondary monitor? Preferably at 23.976hz or a multiple thereof. Someone with a beefy videocard would be helpful, to narrrow this down to a secondary monitor issue.
Thanks
Mark
Mark_A_W
12th April 2009, 07:59
On catalyst > 9, there is a major problem with multi monitor and reclock, at least with my AGP ATI 2600. Before you just had to set the primary monitor and playback was smooth on that monitor. But starting with the 9 versions, i only get smooth playback if i disable the second monitor altogether. Maybe the new reclocks get confused - but you need it for this renderer.
I'm running Cat 9.2 on a PCI-Express HD2600XT, with two monitors, and I can get really smooth playback with Haali and Reclock....and REALLY FRIGGIN SUPER DUPER SMOOTH WITH A CAPITAL SMOO playback with Beliyaal's MPC-HC builds (except I get a big glitch about once per hour).
hubblec4
12th April 2009, 08:12
Hello
i have installed your very good VideoRenderer and use the MPC-hc(Casimir). all plays fine but when i deactivate the internal h264 decoder, and use coreavc. the video will be load but dont play. the player crash and i must kill the prog in the task-manager.
what i do wrong?
hubble
cyberbeing
12th April 2009, 08:43
Thank you for your offer. On second thought, I think it's defintely TV/PC level problem, except that it's not so clearly one or the other.
What you are seeing is the gamma transfer function. Personally I'm unconvinced if this actually make the picture more accurate, but some people seem to believe it does.
If you don't like how it looks, these should make it look similar to other renderers:
# Blu-ray_PC
# Set input bitdepth
Input_Bit_Depth 8
# Set source video format
Input_Video_Format Blu-ray YCbCr
# Set output bitdepth
Output_Bit_Depth 16
# Set display video format
Output_Video_Format Blu-ray RGB_PC
# Output Gamma
Output_Gamma 1
# DVD-NTSC_PC
# Set input bitdepth
Input_Bit_Depth 8
# Set source video format
Input_Video_Format NTSC_DVD YCbCr
# Set output bitdepth
Output_Bit_Depth 16
# Set display video format
Output_Video_Format NTSC_DVD RGB_PC
# Output Gamma
Output_Gamma 1
Hypernova
12th April 2009, 10:05
Thanks for your help cyberbeing!
So, you think what I got from madVR is actually what should have been, and all other renderer give me wrong picture all along? That sounds..disturbing.
yesgrey
12th April 2009, 11:15
LUT's are definitely more GPU-friendly than CPU I think, as the video data is already there and HLSL can work in 64float indeed :devil:
Yes, the video memory access speed it's a lot higher than the ram access speed.
HLSL works in 32float, what works in 64float is cr3dlut. It needs it because the gamma operations require more precision than the rest of the image processing...;)
leeperry
12th April 2009, 11:43
Yes, the video memory access speed it's a lot higher than the ram access speed.
HLSL works in 32float, what works in 64float is cr3dlut. It needs it because the gamma operations require more precision than the rest of the image processing...;)
oh ok, coz this link says that HLSL can work in up to 64float :
http://www.neatware.com/lbstudio/web/hlsl.html
HLSL provides scalar data type like float and vector data type like float3. The scalar data types include bool with true or false value, int with 32-bit signed integer value, half with 16-bit floating point value, float with 32-bit floating point value, and double with 64-bit floating point value.
yesgrey
12th April 2009, 12:37
oh ok, coz this link says that HLSL can work in up to 64float
But madshi said he's using 32FP. Don't worry that's more than enough.;)
leeperry
12th April 2009, 12:54
But madshi said he's using 32FP. Don't worry that's more than enough.;)
I think so yeah :p and I rest my case that MVR looks sharper than HR...w/ LSF/GrainF3/Reclock on top of it, it's really mind blowing on the BD of "The Nightmare Before Christmas" in 48Hz :cool:
Apparently the ghost lines in HR disappear if you set the max PS model to 1.1/1.4 instead of 2.0...I'd like to try to see if it improves HR's sharpness, but it'd require a reboot in RivaTuner...and I'm afraid CoreAVC CUDA/MVR might not like 1.1 PS :D
rica
12th April 2009, 13:36
Thanks madshi, just started trials...
FYI guys: no need a custom MPC-HC build.
Register MadVideoRenderer.ax and select it as preferred under external filters.
Here is the graph at the background of MPC-HC:
http://img9.imageshack.us/img9/6595/madvid01.th.png (http://img9.imageshack.us/my.php?image=madvid01.png)
SS from MPC-HC:
http://img412.imageshack.us/img412/9042/madvid02.png (http://img412.imageshack.us/my.php?image=madvid02.png)
Here is the config:
http://img412.imageshack.us/img412/2941/madvid03.png (http://img412.imageshack.us/my.php?image=madvid03.png)
BTW, no problem here:
GTX 260 nVidia FW 185.66 Vista SP1
_ _ _ _ _ _
ice25
12th April 2009, 13:36
Got rid of the tearing by switching around the secondary and primary display.. The CPU usage when i display MadVR on the secondary display is through the roof..
madshi
12th April 2009, 16:19
FYI guys: no need a custom MPC-HC build.
Register MadVideoRenderer.ax and select it as preferred under external filters.
Nice - didn't know that the "preferred" functionality also works for renderers!
madshi
12th April 2009, 16:23
madVR 0.3 released
http://madshi.net/madVR.zip
* lowered CPU consumption a bit
* playback start is now delayed until 3dlut file is fully loaded
* during initialization madVR posts a message to the screen
* added OSD (on screen display) with some stats, can be toggled with Ctrl+J
* added display refresh rate detection
* added GPU rendering time measurements
* Direct3D resources are completely freed on exit now
* errors are now properly handled and displayed
* if 10bit textures are not available, 8bit textures are used instead
* fixed: window size in GraphEdit was slightly too small
* missing 3dlut files are now automatically created by calling "cr3dlut"
* depending on source resolution "SD.3dlut" or "HD.3dlut" is loaded now
* renamed "madVideoRenderer" to "madVR" everywhere
* settings are now saved to (and read from) "settings.ini" file
* improvement for playing video on secondary monitor (not tested)
NOTE:
I've renamed the file from "madVideoRenderer.ax" to "madVR.ax" now. That means you should uninstall/unregister the old version before updating to the new one.
Also please don't be shocked if the first movie playback startup time of madVR 0.3 is extremely long - that's because madVR is not shipping with any 3dlut files, anymore. Instead the 3dlut files are now created on demand (by calling yesgrey3's "cr3dlut" tool), which takes several seconds. But this only occurs the first time you start a movie (it occurs once for SD content and once for HD content).
----------------------
Guys, please test:
(1) Does playback on secondary monitor work better now?
(2) Is the display refresh rate detection working properly (press Ctrl+J)? Also on secondary monitor?
(3) If you have a lot of trouble with stuttering, please post the stats from the OSD (Ctrl+J). That might help figuring out whether your graphics card is too slow, or whether there's a different problem. You can also turn on all the "trade quality for performance" options and check in the OSD which effect these options have on GPU rendering time.
Thunderbolt8
12th April 2009, 17:07
hm stats from a movie (quite grainy movie)
display 59.XXXHz
movie 23.976 fps
1920, 1080
vsync interval 16.73ms
movie frame interval 41.71ms
avrg gpu rendering time 47.XXms
max gpu rendering time 47.XXms
doesnt run smoothly on that c2q with 7600GT (AGP), so how can I determine this from the numbers? is it like that that the avrg gpu rendering time value has to be lover than the movie fram interval value for fluent playback?
edit: when I enable all those "performance for quality settings" then the avrg gpu rendering time drops to ~30ms and it looks almost fluent (max gpu rendering time sometimes still higher than movie framerate interval; creating 10bit textures fails, uses 8bit instead)
rica
12th April 2009, 17:34
some feedback:
tried to open an avs file including a dga created by neuron's DGAVCDecodeNV in MPC-HC. (Sure CUVID server is opened)
Here are the results:
with EVRCustom Presenter CPU utilization is 20 to 35%
with madVR, it is 50 to 75 %.
.03 didn't change the CPU usage.
Is the display refresh rate detection working properly (press Ctrl+J)?
Yes:
http://img412.imageshack.us/img412/2444/madvid04.png
_ _ _ _
leeperry
12th April 2009, 17:38
so my custom timings are not as spot-on as I initially thought...that's w/ CoreAVC CUDA :
http://www.image-load.eu/out.php/i157460_jitter.png
I should be getting an ideal frame interval of 41.67, and it's 41.71...I guess it can't get any better than that just yet :o
and you've added LUT support for SD/HD, awesome :)
now if you could add an option to force triple buffering(this works in MPC HC+VMR9/EVR to never miss the VSYNC fliptime w/ Reclock, using D3DOverrider.exe from the RivaTuner package) and let us fake the GUID to improve compatibility in third party players(MVR is only a few days old), I'd be a happy camper :)
maybe making the OSD white would make it more readable too.. :thanks:
yesgrey
12th April 2009, 17:40
is it like that that the avrg gpu rendering time value has to be lover than the movie fram interval value for fluent playback?
Yes. If madVR is taking more time to render the frame that the time interval between each frame, the next frame to render will be delayed...;)
leeperry
12th April 2009, 17:51
I've got a dllhost.exe that doesn't want to die since I've installed the new beta...maybe it's unrelated :confused:
madshi
12th April 2009, 17:55
hm stats from a movie (quite grainy movie)
display 59.XXXHz
movie 23.976 fps
1920, 1080
vsync interval 16.73ms
movie frame interval 41.71ms
avrg gpu rendering time 47.XXms
max gpu rendering time 47.XXms
doesnt run smoothly on that c2q with 7600GT (AGP), so how can I determine this from the numbers? is it like that that the avrg gpu rendering time value has to be lover than the movie fram interval value for fluent playback?
edit: when I enable all those "performance for quality settings" then the avrg gpu rendering time drops to ~30ms and it looks almost fluent (max gpu rendering time sometimes still higher than movie framerate interval; creating 10bit textures fails, uses 8bit instead)
Grainy or not doesn't matter to madVR. You'd get the same stats even with a static test pattern... ;) Only source resolution and framerate matters to madVR.
Well, that is one slow GPU you have there! I take it you have scaling disabled (1:1 display)? If so, could you please zoom a little and post the average GPU rendering time then? Does it go to 100ms per frame then? :eek:
If you want to give madVR even a chance to achieve smooth playback you have to achieve an "average gpu rendering time" that is a notch lower than the "movie frame interval". I'd say it should not be higher than 35ms for 23.976 playback. Now the optimal configuration for madVR is if you drive the display with the same refresh rate the source is in (in your case 23.976Hz). If you have to use 59.940Hz, things get slightly more difficult for madVR. In that case you may have to bring "average gpu rendering time" down even more. But madVR is not optimized for this situation yet, so even if you do manage to bring gpu rendering time down, don't expect perfect smoothness with the current madVR version.
I'm not sure yet how much influence "max gpu rendering time" will have. Could be that high spikes in that area may result in frame drops. Or maybe not, if I find a way to smoothen things out...
tried to open an avs file including a dga created by neuron's DGAVCDecodeNV in MPC-HC. (Sure CUVID server is opened)
Here are the results:
with EVRCustom Presenter CPU utilization is 20 to 35%
with madVR, it is 50 to 75 %.
.03 didn't change the CPU usage.
Hmmmmmm... I still don't know why CPU utilization is higher with madVR than it is with EVR/VMR/Haali. In theory there shouldn't really be much difference... :( Maybe I will find out one day. But for now I have different priorities, so CPU consumption will have to wait...
so my custom timings are not as spot-on as I initially thought...that's w/ CoreAVC CUDA :
I should be getting an ideal frame interval of 41.67, and it's 41.71...I guess it can't get any better than that just yet :o
You are misinterpreting the OSD information. The "frame interval" is for the movie source framerate. It's not for the display refresh rate. For the display refresh rate look at the first line in the OSD, that looks quite good. Or look at "vsync interval", which is basically half of 41.67 (due to using 48Hz instead of 24Hz), so you should be happy.
now if you could add an option to force triple buffering
Things are not as easy as that. There's more to smooth playback than just enabling triple buffering. Actually triple buffering can be bad in some situations. Anyway, I don't want to talk about smooth motion playback improvements right now because (as I said multiple times), that feature is simply not implemented yet.
and let us fake the GUID to improve compatibility in third party players
No plans for that right now. Please ask those 3rd party players to support madVR.
maybe making the OSD white would make it more readable too.. :thanks:
The OSD layout is not final yet. Only few things in madVR are final right now...
STaRGaZeR
12th April 2009, 17:57
Refresh rate detection is working properly here. However I'm experiencing the typical "colors are washed out" situation. My monitor expects PC levels and it seems that madVR is sending TV levels. All other renderers are fine. To have proper levels with madVR I've to use ffdshow's levels filter. BTW could you provide with a brief description of each resizer? I know a few of them but not the others.
leeperry
12th April 2009, 18:01
I've got a dllhost.exe that doesn't want to die since I've installed the new beta...maybe it's unrelated :confused:
apparently it comes from the "ComSysApp" COM+ service, did you use that to create the LUT's from yesgrey's app or sumthing? if so, it might need to be closed afterwards.
look at "vsync interval", which is basically half of 41.67 (due to using 48Hz instead of 24Hz), so you should be happy.
[...]
I don't want to talk about smooth motion playback improvements right now because (as I said multiple times), that feature is simply not implemented yet.
[...]
No plans for that right now. Please ask those 3rd party players to support madVR.
[...]
The OSD layout is not final yet. Only few things in madVR are final right now...
1)I am happy, no worries :D
2)got it, just an idea :o
3)I did, but the main KMP coder is AWOL...and I tried to hexedit the GUID in both your renderer and kmp.exe w/o succeeding
4)yet it looks really good already :cool:
the measured refresh rate slightly oscillates from time to time, no wonder Reclock is mandatory for smooth playback..
yesgrey
12th April 2009, 18:19
Hmmmmmm... I still don't know why CPU utilization is higher with madVR than it is with EVR/VMR/Haali.
Are you sure all your buffers are created in the GPU memory? Maybe it's using some of the RAM of the computer, which should slow things down and increase CPU usage...
rica
12th April 2009, 18:20
Hmmmmmm... I still don't know why CPU utilization is higher with madVR than it is with EVR/VMR/Haali. In theory there shouldn't really be much difference... Maybe I will find out one day. But for now I have different priorities, so CPU consumption will have to wait...
OK, thanks, sure we have time for this :)
But i should remind you when i open an m2ts with any SW based decoder (like arcsoft), CPU consumption is 75 to 100%.
My trials were based on DGAVCDecodeNV as you know.
:thanks:
STaRGaZeR
12th April 2009, 18:23
Are you sure all your buffers are created in the GPU memory? Maybe it's using some of the RAM of the computer, which should slow things down and increase CPU usage...
I get ~309MB of RAM usage with madVR vs ~105MB with EVRCP.
Any chance of a x64 build?
KoD
12th April 2009, 18:24
madshi, I've sent you a PM with a small anamorphic sample displayed by the renderer with wrong AR . Source is DVD.
ice25
12th April 2009, 18:25
CPU usage is still very high when i use the secondary display for madVR, but according to the stats it's detecting the refresh rate from the primary screen while i'm using the secondary display. So i guess refresh detection for secondary display is bugged atm, cpu usage should be fixed once you get around fixing that.
madshi
12th April 2009, 18:40
could you provide with a brief description of each resizer? I know a few of them but not the others.
Check out this page:
http://audio.rightmark.org/lukin/graphics/lhouse_more.htm
In my source code I've added the following comments. They might help here, too:
aliasing (negative): the lower the better
additional ringing (negative): the lower the better
hide source ringing (positive): the higher the better
sharpness (positive): the higher the better
Bilinear (2 tap)
- aliasing = 5
- additional ringing = 0
- hide source ringing = 3
- sharpness = 5
Catmull-Rom = Bicubic50, Bicubic60, Bicubic75 (2 tap)
- aliasing = 4.5, 3.5, 3
- additional ringing = 1, 2, 3.5
- hide source ringing = 0
- sharpness = 7.25, 7.50, 7.75
Mitchell-Netravali (2 tap)
- aliasing = 4
- additional ringing = 1
- hide source ringing = 1
- sharpness = 5
SoftCubic80, SoftCubic70, SoftCubic60, SoftCubic50 (2 tap)
- aliasing = 0.25, 1, 2, 2.5
- additional ringing = 0, 0.25, 0.5, 0.75
- hide source ringing = 7, 6, 3, 1
- sharpness = 2, 3, 3.5, 4
Lanczos3 (3 tap), Lanczos4 (4 tap)
- aliasing = 2, 1
- additional ringing = 6, 8
- hide source ringing = 0
- sharpness = 8.5, 9
Spline36 (3 tap), Spline64 (4 tap)
- aliasing = 2.5, 2.3
- additional ringing = 4.5, 5
- hide source ringing = 0
- sharpness = 8, 8.1
Please note that these numbers are just my personal opinion. There's nothing scientific about these numbers.
apparently it comes from the "ComSysApp" COM+ service, did you use that to create the LUT's from yesgrey's app or sumthing?
madVR has nothing to do with COM+.
the measured refresh rate slightly oscillates from time to time, no wonder Reclock is mandatory for smooth playback..
Refresh rate measurements are not an exact science. It is to be expected that the measurement oscillates. That does not mean that the real refresh rate does that, too. It just means that the measurement is not perfect. Not too much of a problem, though. madVR doesn't need perfection in this case, if it's reasonably close (as in < 1% from true value), that's good enough.
Are you sure all your buffers are created in the GPU memory? Maybe it's using some of the RAM of the computer, which should slow things down and increase CPU usage...
In theory all buffers used for the rendering should be on the GPU, I've intentionally done it that way.
I get ~309MB of RAM usage with madVR vs ~105MB with EVRCP.
madVR stores 16 decoded frames in RAM.
Any chance of a x64 build?
Not for now, maybe later, when 32bit is more or less complete...
CPU usage is still very high when i use the secondary display for madVR, but according to the stats it's detecting the refresh rate from the primary screen while i'm using the secondary display. So i guess refresh detection for secondary display is bugged atm, cpu usage should be fixed once you get around fixing that.
Too bad, I had hoped that was fixed. Can't properly test it cause I don't have a secondary display at the moment. So I guess the fix will have to wait a while...
noee
12th April 2009, 19:03
XPSP3, HD2600XT, CCC9.4, AMD X2 3.0Ghz, Reclock, MPC-HC (int decoders)
Monitors: (Prim) Samsung 60Hz (PC levels) - (Sec) LG 37 24/60Hz (Video Levels)
Source material: SD = 23.976@24Hz AVC in MKV, HD = 29.970@60Hz AVCHD in M2TS (1080P)
1. Still getting tearing on secondary, SD and HD
2. madVR displaying 60Hz on my secondary (LG) when the monitor is set for 24Hz
Not getting the automatic creation of the LUT's. I ended up creating them myself with modified config files.
I have retained the folder structure from the zip with "cr3dlut" folder in a "madVR" folder.
madshi
12th April 2009, 19:06
1. Still getting tearing on secondary, SD and HD
2. madVR displaying 60Hz on my secondary (LG) when the monitor is set for 24Hz
Yeah, seems that madVR still thinks it's running on primary.
Not getting the automatic creation of the LUT's.
What did you get instead? Any error messages? Or a crash? Or what?
yesgrey
12th April 2009, 19:07
In theory all buffers used for the rendering should be on the GPU, I've intentionally done it that way.
madVR stores 16 decoded frames in RAM.
So the frames are stored in RAM instead of GPU memory?
If they are, when you process them with the GPU are you accessing them via the AGP/PCI-E or via the CPU? Could this be the source of the high CPU usage?...
madshi
12th April 2009, 19:12
madVR v0.3 released *again*
http://madshi.net/madVR.zip
* updated cr3dlut templates
Sorry guys, please redownload. madVR itself is unchanged, but yesgrey3 has been so kind to provide me with some preconfigured cr3dlut templates. Mine has been wrong, it seems.
Please delete "out16.3dlut" (in case you still have it) and "SD/HD.3dlut". Then rerun madVR. Hopefully that will clear any and all complaints about washed out colors.
BTW, there are also templates for video levels now. If you need video levels, replace the files "SD/HD.txt" with "template - SD/HD - Video.txt", then delete "SD/HD.3dlut" and rerun madVR.
Xorp
12th April 2009, 19:12
30mbps avg Blu-ray remuxed to mkv with eac3to, weird resolution reported (its 1920x1080)
http://img151.imageshack.us/img151/2922/testa.png
framerate stays around 18fps according to zoomplayer's stats
graphics card is 8800GTS-640MB
madshi
12th April 2009, 19:12
So the frames are stored in RAM instead of GPU memory?
No. I'm uploading every frame to GPU memory before processing it, of course.
madshi
12th April 2009, 19:17
30mbps avg Blu-ray remuxed to mkv with eac3to, weird resolution reported (its 1920x1080)
Strange! How does the pin connection info look like?
Not sure why you only get 18fps. Might be due to madVR consuming too much CPU so that your decoder chokes (the frame queue is only at 3/16, usually it should be 16/16, having it at so low value means that the decoder is not delivering frames fast enough). But your gpu rendering times are also quite heavy.
Do you happen to have another filter running (e.g. ffdshow) which upscales the video to double resolution? :confused: That would explain the strange movie resolution report and also the high gpu rendering times.
noee
12th April 2009, 19:19
Sorry, yeah, the msg I get is:
madVR Reports:
opening 3dlut file fails
madshi
12th April 2009, 19:23
madVR Reports:
opening 3dlut file fails
Do you happen to use a non-ansi char path? That's the only cause I can imagine right now. Lazy as I am I used ansi chars instead of unicode... :o Or is your overall madVR directory path extremely long (> 260 chars)?
Thunderbolt8
12th April 2009, 19:27
Grainy or not doesn't matter to madVR. You'd get the same stats even with a static test pattern... ;) Only source resolution and framerate matters to madVR.
Well, that is one slow GPU you have there! I take it you have scaling disabled (1:1 display)? If so, could you please zoom a little and post the average GPU rendering time then? Does it go to 100ms per frame then? :eek:
just wanted to indicate grainy = high bitrate file here :)
yes, the card is quite old. I have the same one (as PCIE though) in my own C2D system, might be a tiny bit faster, but not much I guess.
the display I used here has 1680*1050 res, so its not 1:1 (the other screen on my own system has 1280*1024). so you still want me to try zoom? but how can I do that, have no clue about zooming options :S
If you want to give madVR even a chance to achieve smooth playback you have to achieve an "average gpu rendering time" that is a notch lower than the "movie frame interval". I'd say it should not be higher than 35ms for 23.976 playback. Now the optimal configuration for madVR is if you drive the display with the same refresh rate the source is in (in your case 23.976Hz). If you have to use 59.940Hz, things get slightly more difficult for madVR. In that case you may have to bring "average gpu rendering time" down even more. But madVR is not optimized for this situation yet, so even if you do manage to bring gpu rendering time down, don't expect perfect smoothness with the current madVR version.
hm so your advise would be to change it to 24 (or exactly 23.976?)Hz? how can I do that, in my graphic card options when I rightclick on windows screen and then properties (only have the option to choose either 59 or 60Hz there)? or do I need to change that in ffdshow?
TinTime
12th April 2009, 19:31
* depending on source resolution "SD.3dlut" or "HD.3dlut" is loaded now
How does madVR decide what's SD and what's HD? What are the resolution cut-offs?
The crtl+J info is reporting the refresh rate correctly for me at 24Hz, 50Hz and 60Hz (I only use a primary display). Average GPU rendering time hovers around 14ms for 24Hz playback. I've tried a blu-ray AVC source (muxed to mkv with eac3to) and that works for me with CoreAVC CUDA decoding too, on a 512MB 8600GT.
I tried turning off CUDA decoding in CoreAVC and found that I got some tearing during playback of HD AVC files. It looks like tearing for me is a symptom of my PC not quite decoding fast enough. It's an Athlon X2 5600+, which I think is a bit borderline for HD decoding. It's not a problem with madVR itself, unless madVR should absolutely never tear under any circumstances.
HD VC1 is similar. I get occasional tearing which seems to coincide with a dropping in the number of frames in the frame queue reported by madVR. I can't get totally smooth playback with other renderers either though for HD VC1, except for VMR9 with DXVA.
Xorp
12th April 2009, 19:38
Strange! How does the pin connection info look like?
Not sure why you only get 18fps. Might be due to madVR consuming too much CPU so that your decoder chokes (the frame queue is only at 3/16, usually it should be 16/16, having it at so low value means that the decoder is not delivering frames fast enough). But your gpu rendering times are also quite heavy.
Do you happen to have another filter running (e.g. ffdshow) which upscales the video to double resolution? :confused: That would explain the strange movie resolution report and also the high gpu rendering times. Only CoreAVC was decoding, nothing else.
I had the same low fps problem in MPC custom build with madVR, but when I went back to the Beliyaal-build setting madVR as a preferred external renderer, everything runs smoothly now. Getting 16/16 frame queues.
madshi
12th April 2009, 19:46
the display I used here has 1680*1050 res, so its not 1:1 (the other screen on my own system has 1280*1024). so you still want me to try zoom?
No, scaling was probably already activated because it's not 1:1.
hm so your advise would be to change it to 24 (or exactly 23.976?)Hz? how can I do that, in my graphic card options when I rightclick on windows screen and then properties (only have the option to choose either 59 or 60Hz there)? or do I need to change that in ffdshow?
That would be graphics card properties or PowerStrip (if all else fails). But that makes sense only if your display can handle that!
How does madVR decide what's SD and what's HD? What are the resolution cut-offs?
HD = wider than 1024 or higher than 576
The crtl+J info is reporting the refresh rate correctly for me at 24Hz, 50Hz and 60Hz (I only use a primary display). Average GPU rendering time hovers around 14ms for 24Hz playback. I've tried a blu-ray AVC source (muxed to mkv with eac3to) and that works for me with CoreAVC CUDA decoding too, on a 512MB 8600GT.
Sounds good to me.
Only CoreAVC was decoding, nothing else.
I had the same low fps problem in MPC custom build with madVR, but when I went back to the Beliyaal-build setting madVR as a preferred external renderer, everything runs smoothly now. Getting 16/16 frame queues.
Strange. Could you please post the pin connection info? (right click -> filters -> madVR -> Pin Info). If possible for both the situation where madVR reports the funny resolution. And also for the situation where madVR runs fluidly. There must be a difference somewhere. I'd really like to know why madVR reports such a high resolution for you!
madshi
12th April 2009, 19:48
Two questions for those of you who have such ultra high CPU consumption:
(1) Is that with the OSD turned on? Or also with OSD turned off? FWIW, with OSD turned off CPU consumption should be a bit lower than with it turned on.
(2) Are you running madVR on your primary monitor? Or on secondary? I'm asking because running on secondary has problems right now...
STaRGaZeR
12th April 2009, 20:10
Check out this page:
Thanks for the info.
madVR stores 16 decoded frames in RAM.
Wouldn't it be better to store them in the GPU RAM? EVRCP does this, maybe it'd solve latency problems and/or CPU consumption.
Oh and the levels are good now, thanks!
Does madVR have any kind of deinterlacer? Interlaced material looks deinterlaced, with ghosting though. Of course no other deinterlacer is in the chain.
yesgrey
12th April 2009, 20:10
Here are my stats while playing a Blu-ray movie remuxed to a mkv file. My card is a GF 8600GT 256MB.
9756
The frame rendering is ~14ms. For playing in my monitor at 72Hz (13.9ms) is not enough, but should be fine to use with my projector at 48Hz (20ms). If I use Lanczos or Spline resampling the rendering time jumps to ~20ms, so I should not be able to use those resamplers with smooth playing...
madshi, would it be possible for us to set the number of frames buffered (maybe in the settings.ini)? I could try reduce the number to see if it works better with cuda enabled...
yesgrey
12th April 2009, 20:18
In my source code I've added the following comments. They might help here, too:
It might be a good idea to include those comments in the readme...
madshi
12th April 2009, 20:20
The frame rendering is ~14ms. For playing in my monitor at 72Hz (13.9ms) is not enough, but should be fine to use with my projector at 48Hz (20ms). If I use Lanczos or Spline resampling the rendering time jumps to ~20ms, so I should not be able to use those resamplers with smooth playing...
You would be right if madVR needed to draw a *new* Blu-Ray frame every VSync. But if it did that, you'd get 3x respectively 2x as fast movie playback as you should get. madVR has to skip lots of VSyncs with your refresh rates. Because of that the most important reference time is not the "vsync interval" but the "frame interval". So I think you should be able to use Lanczos4 just fine, sooner or later...
madshi, would it be possible for us to set the number of frames buffered (maybe in the settings.ini)? I could try reduce the number to see if it works better with cuda enabled...
The frame queue is stored in RAM, not in GPU. So how could it possibly conflict with CUDA?
It might be a good idea to include those comments in the readme...
I hope that sooner or later I can reduce the number of scaling options. I was hoping to start a vote after a while for which scaling options to keep and which to remove.
leeperry
12th April 2009, 20:21
It might be a good idea to include those comments in the readme...
I think the AVS peeps advise spline36 as the "best" choice...so that's 3 taps then :)
Xorp
12th April 2009, 20:24
madVR selected in Output
Filter : madVR - CLSID : {E1A8B82A-32CE-4B0D-BE0D-AA68C772E423}
- Connected to:
CLSID: {9852A670-F845-491B-9BE6-EBD841B8A613}
Filter: DirectVobSub (auto-loading version)
Pin: Output
- Connection media type:
Video: YV12 3840x2160 24.00fps
AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YV12 {32315659-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 112
VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 416666
VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 3200
dwPictAspectRatioY: 1800
dwControlFlags: 0x00000000
dwReserved2: 0x00000000
BITMAPINFOHEADER:
biSize: 40
biWidth: 3840
biHeight: 2160
biPlanes: 3
biBitCount: 12
biCompression: YV12
biSizeImage: 12441600
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0
pbFormat:
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020: 00 00 00 00 00 00 00 00 9a 5b 06 00 00 00 00 00 ........š[......
0030: 00 00 00 00 00 00 00 00 80 0c 00 00 08 07 00 00 ........€.......
0040: 00 00 00 00 00 00 00 00 28 00 00 00 00 0f 00 00 ........(.......
0050: 70 08 00 00 03 00 0c 00 59 56 31 32 00 d8 bd 00 p.......YV12.ؽ.
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
madVR set as preferred in external filters
Filter : madVR - CLSID : {E1A8B82A-32CE-4B0D-BE0D-AA68C772E423}
- Connected to:
CLSID: {09571A4B-F1FE-4C60-9760-DE6D310C7C31}
Filter: CoreAVC Video Decoder
Pin: Output
- Connection media type:
Video: YV12 1920x1080 24.00fps
AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YV12 {32315659-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 112
VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 416666
VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 1920
dwPictAspectRatioY: 1080
dwControlFlags: 0x00000000
dwReserved2: 0x00000000
BITMAPINFOHEADER:
biSize: 40
biWidth: 1920
biHeight: 1080
biPlanes: 3
biBitCount: 12
biCompression: YV12
biSizeImage: 3110400
biXPelsPerMeter: 1
biYPelsPerMeter: 1
biClrUsed: 0
biClrImportant: 0
pbFormat:
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020: 00 00 00 00 00 00 00 00 9a 5b 06 00 00 00 00 00 ........š[......
0030: 00 00 00 00 00 00 00 00 80 07 00 00 38 04 00 00 ........€...8...
0040: 00 00 00 00 00 00 00 00 28 00 00 00 80 07 00 00 ........(...€...
0050: 38 04 00 00 03 00 0c 00 59 56 31 32 00 76 2f 00 8.......YV12.v/.
0060: 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
So DirectVobSub was interfering.
Brazil2
12th April 2009, 20:31
madVR v0.3 released *again*
I can't get any OSD, Ctrl+J has no effect at all.
Maybe because I've manually installed MadVR.ax (using regsvr32) rather than using InstallFilter.exe ?
I'm still having aspect ratio problems with the sample I've posted here:
http://forum.doom9.org/showthread.php?p=1272713#post1272713
And also with this one:
http://mirror05.x264.nl/public/force.php?file=./beyonce.at.the.bbc.1080mbaff.sample.ts
Both files are playing fine with the correct aspect ratio with other renderers.
And I have problems with MPEG2 NTSC interlaced when the built-in MPC-HC decoder is set to BOB. It's hard for me to describe what is happening but the image is 'shaking' a lot.
It seems to be OK with PAL MPEG2 interlaced though.
madshi
12th April 2009, 20:32
So DirectVobSub was interfering.
Yep. I've never used DirectVobSub myself yet, but it seems that it doubled resolution somehow for you, probably with the intention of being able to render smoother looking subtitles. Of course having 4x as many pixels brings madVR (or rather your graphics card) to its knees. Your gpu rendering times should be a lot lower without DirectVobSub doubling resolution, I guess about 4x lower. And that makes a lot more sense because your 8800 should be quite powerful and should have no problems with processing 1080p24.
madshi
12th April 2009, 20:35
I can't get any OSD, Ctrl+J has no effect at all. Maybe because I've manually installed MadVR.ax (using regsvr32) rather than using InstallFilter.exe ?
Strange, seems to work for everyone else? Manually installing makes no difference.
I'm still having aspect ratio problems with the sample I've posted [...] and also with this one
Thanks, will have a look at that later...
And I have problems with MPEG2 NTSC interlaced when the built-in MPC-HC decoder is set to BOB. It's hard for me to describe what is happening but the image is 'shaking' a lot.
If that fine with other renderers? If so, can I have just another sample? :)
Brazil2
12th April 2009, 20:52
If that fine with other renderers? If so, can I have just another sample? :)
Yes, it's fine with other renderers.
Well, any MPEG2 NTSC interlaced DVD compliant file I've tried is doing the same. I've tried with a VOB from a ripped and decrypted DVD (because I couldn't play the DVD itself in MPC-HC with MadVR, MPC-HC just hangs and nothing happens) and also with a MPG file created with MEncoder which is DVD NTSC film compliant. Maybe the 3:2 pulldown is the problem ?
I live in PAL land so I don't have much MPEG2 NTSC material but the ones I have are not working fine when MPC-HC decoder is forced to BOB.
yesgrey
12th April 2009, 20:56
So the frames are stored in RAM instead of GPU memory?
No. I'm uploading every frame to GPU memory before processing it, of course.
The frame queue is stored in RAM, not in GPU. So how could it possibly conflict with CUDA?
From the previous answer I thought the frame queue was stored in GPU memory... now I realize that I've not understood completelly your reply. They are stored in RAM but are copyed to GPU memory (one at a time) before starting any processing. Got it.:)
Because of that the most important reference time is not the "vsync interval" but the "frame interval". So I think you should be able to use Lanczos4 just fine, sooner or later...
Great! so it seems I could keep my 8600gt a little longer...;)
I hope that sooner or later I can reduce the number of scaling options. I was hoping to start a vote after a while for which scaling options to keep and which to remove.
I plan to do my scaler test and will post here the results...
I can't get any OSD, Ctrl+J has no effect at all.
Maybe because I've manually installed MadVR.ax (using regsvr32) rather than using InstallFilter.exe ?
Have you uninstalled the previous? madVideoRenderer.ax?
Brazil2
12th April 2009, 20:59
Have you uninstalled the previous? madVideoRenderer.ax?
Yes, of course I did :)
regsvr32 -u madVideoRenderer.ax
regsvr32 madVR.ax
I haven't rebooted since then. Should I ?
yesgrey
12th April 2009, 21:10
I haven't rebooted since then. Should I ?
Shouldn't be needed, but it will not hurt... maybe you should use the uninstall and install, instead of manually doing it...
leeperry
12th April 2009, 21:18
I've just realized that you can press CTRL+J twice and get even more stats...great for boring movies I guess :cool:
http://www.image-load.eu/out.php/t157493_kmpppp.png (http://www.image-load.eu/out.php/i157493_kmpppp.png)
it's good that it's like HR(and unlike EVR/VMR9), as long as you can catch the VSYNC properly it will remain so and *NOT* drop video frames :)
PS: that'd be fun if you could put 3 or 4 digits after the coma for the VSYNC interval.
buletti
12th April 2009, 21:53
So the frames are stored in RAM instead of GPU memory?
No. I'm uploading every frame to GPU memory before processing it, of course.
The frame queue is stored in RAM, not in GPU. So how could it possibly conflict with CUDA?
Could that be the cause of the high CPU load? The copy operation from RAM into VRAM is done by the CPU and is a rather slow operation AFAIR. However, after a short google search, it seems that this is no big issue anymore with PCI-E and asynchronous memcpy via CUDA...
Snowknight26
12th April 2009, 23:08
Can anything be done about an error that says "graphics card only supports power of 2 textures?" Happens with my GM45.
Egh
12th April 2009, 23:33
Quote:
Originally Posted by ice25 View Post
CPU usage is still very high when i use the secondary display for madVR, but according to the stats it's detecting the refresh rate from the primary screen while i'm using the secondary display. So i guess refresh detection for secondary display is bugged atm, cpu usage should be fixed once you get around fixing that.
Too bad, I had hoped that was fixed. Can't properly test it cause I don't have a secondary display at the moment. So I guess the fix will have to wait a while...
@Madshi: bit late but better than never ;)
fix reports
a) overall CPU consumption is reduced on primary and I think for SD content at least the difference between HR and madVR is negligible.
b). madVR properly reports that 10bit buffers are not available and engages 8bit buffers, and weirdly enough, no crashes or silent quits after than, video plays as normal :)
bug confirmation reports
1.
although the CPU consumption is down in total, still secondary monitor maxes one of the cores.
Interesting enough, now with OSD I can tell that avrg present wait is actually about 3 times lower on the secondary monitor ;)
Still one of the cores is on maximum.
As for the rest of parameters, I cannot see any substantial difference in times for any of the other parameters on two monitors. I even used ctrl+j twice, but all the numbers are nearly same whilst CPU usage is dramatically different.
2. Monitor refresh rate is not updated if you move to a different monitor. I think btw Beliyaal fixed that issue with EVRCP at some point, but that code is not in SVN yet (may be mistaken)
important: retested the issue, madVR uses refresh rate not as of PRIMARY monitor per se, but the rate of the monitor the mpchc window was started on!!! (in simpler words, if I start mpchc on the secondary monitor it will use its refresh rate). Note that your code is the best so far when moving the window to a different monitor, as other renderers may have a small pause or blank screen displayed for a while when you move a window. Moving window with madVR is same as moving any normal application.
noee
12th April 2009, 23:45
important: retested the issue, madVR uses refresh rate not as of PRIMARY monitor per se, but the rate of the monitor the mpchc window was started on!!! (in simpler words, if I start mpchc on the secondary monitor it will use its refresh rate).
fwiw, this is not the case on my setup. If I start the player (MPC-HC) on my secondary (LG37@24Hz), madVR picks up the refresh of 60Hz, which is what my primary runs.
DeepBeepMeep
12th April 2009, 23:53
Would it be possible to propose another means like an option to turn on / off stats since CTRL J is usually a keyboard shorcut reserved by most players.
Many thanks
yesgrey
13th April 2009, 00:07
I've tryed to overclock my card to see the benefits.
Clock description: Core / Shader / Memory
Standard clocks
540 / 1188 / 700
9759
Overclock Core and Shader
595 / 1404 / 700
9761
Overclock All
595 / 1404 / 918
9760
Overclocking only the Core and Shader clocks gives a ~4% performance increase, if I also overclock the memory it gives a ~9% performance increase.
So, with madVR, the performance increase with my card was directly proportional to the clocks increase.:)
Egh
13th April 2009, 00:52
fwiw, this is not the case on my setup. If I start the player (MPC-HC) on my secondary (LG37@24Hz), madVR picks up the refresh of 60Hz, which is what my primary runs.
Nope here. Although it seems you have TV screen? I just run dualview with two monitors. It seems it always picks the refresh rate of the monitor it starts on. And i don't mean madVR per se, what I mean is the main MPCHC window. I.E. even if I start an empty window on one monitor, then move to another and drop a video into it, it detects the refresh rate of the original monitor.
Egh
13th April 2009, 00:54
Would it be possible to propose another means like an option to turn on / off stats since CTRL J is usually a keyboard shorcut reserved by most players.
Many thanks
I think it is standard shortcut used by MPCHC, and it works in many other renderers, VMR9 and EVRCP, for instance. Even cycling through different stat views has been already employed by Beliyaal in his MPCHC branch. So it is more de-facto standard ;):p
DeepBeepMeep
13th April 2009, 01:02
I think it is standard shortcut used by MPCHC, and it works in many other renderers, VMR9 and EVRCP, for instance. Even cycling through different stat views has been already employed by Beliyaal in his MPCHC branch. So it is more de-facto standard ;):p
The trouble is that under Zoom Player, CTRL-J creates some navigation window...
Anyway, I don't mind keeping CTRLJ as long as there is another way to display the stats.
vucloutr
13th April 2009, 01:27
Hi, here some feedback.
System:
WinServer2008 x64 - MPC HC special build - latest Nvidia drivers - latest DirectX drivers
8800GTS512 (G92) - 19" LCD 1280x1024 @72Hz over DVI
720p,h264,23.976fps,3Mbit/s encodes displayed at fullscreen (no stretch)
CoreAVC w/o CUDA / MPC HC's internal decoder / DivX H.264 Decoder :
display 72.0xxxxHz
movie 23.976 fps
frame queue pretty much always 16/16
movie resolution 1280,720
target rectangle 0,152,1280,872
vsync interval 13.90ms
movie frame interval 41.71ms
avrg gpu rendering time ~3ms
max rendering time is ~4ms
avrg present wait ~11ms
those times are pretty stable and don't vary much from decoder to decoder.
CoreAVC w/ CUDA same as above but:
max rendering time -> update textures goes from normal ~2ms up to 12-15ms then down to normal, then again up, etc. happens every now and then.
with some 1080p high bitrate material it goes even higher resulting in strong stuttering. some other material works without any flaws.
- framerate sometimes doesn't oszillate at all
- time behind display x.xxxx.Hz in brackets stays fixed (0s/1s/2s) or counts sometimes
- I noticed that a display refresh rate slightly below 3*23.976Hz (CVT reduced blanking for example) causes stuttering. While a refresh rate slightly above 3*23.976Hz results in smooth playback. Unfortunately I can't test this for 75Hz becaused i can't get more then 75.01xxHz which is not enough as it seems.
- display refresh rate detection works sometimes, if 0.0000Hz is displayed window minimize->restore is a workaround
- avrg present wait shows large negativ values immediately after pressing CTRL+J then it normalizes
I'm afraid I can't tell something more distinct because it all seems so random. :confused:
rica
13th April 2009, 02:21
Strange;
when i opened DGAVCNV avs file with GraphStudio, CPU utilization decreased to 25 to 35 % level.
Avi/wav File Source > MadVR
What is interesting here is MPC-HC is using the same filter chain as well but with a 50-75 % Cpu consumption???? :confused:
Adub
13th April 2009, 03:39
I could kiss you!
Madshi you rock with all of the contributions you produce in this community! Thank you so much!
Mutiny32
13th April 2009, 04:16
Great renderer, it will be even better when you can make it output 0-255 and output smoother video. But those are pretty trivial, as other things can handle that sort of thing. You say that you can't output to YCbCr444 with our video cards, or at least easily. Actually, I'm running Win 7 with the WDDM 1.1 driver and the default control panel has a specific page that has a simple dropdown box to switch between RGB and YCbCr444 output over HDMI. My TV has all kinds of controls to handle and enhance colors and black levels to the room lighting (Philips 42pfl7422d/37), so it doesn't matter much.
I do have one request though, can you compile this for 64-bit windows? I'm going to be installing a newer build soon and Microsoft is really pushing the 64-bit thing, especially after Apple started with the whole Snow Leopard 64-bit schtick. It's seeming more and more that 64-bit will be the norm and I'm not sure of its capabilities in handling 32-bit programs; it's not like I can just do an 'apt-get install ia32-libs' or anything, that would make too much sense.
Keep up the great work!
Egh
13th April 2009, 04:22
Well x64 version will be required in the future, as only x64 codecs may work with x64 mpchc and x64 decoders. Though here I haven't found any particular video yet which would consume substantially different amount of CPU% on x64 compared to x86. Maybe when lots of additional post-processing is involved, decoding itself doesn't load CPU differently.
Though recalling how much time required to persuade Haali to do x64 version ;))) He resisted for more than a year before finally surrendering :P
Snowknight26
13th April 2009, 05:14
Assuming hes writing this in Delphi, it will be a while before even the possibility ofa 64-bit version of this or any other of madshi's programs.
FoLLgoTT
13th April 2009, 08:14
Excellent renderer! For such fine piece of software I was waiting for! :)
I have only one small suggestion. It would be great, if the number of lobes/taps of Lanczos could be chosen like in ffdshow. I know that many people will claim that ringing becomes visible, but this is only true with test patterns and not with low pass filtered movies, because ringing only occurs near the band limit. The advantage of 8 or 10 taps is a much better frequency response and visible less aliasing.
I will be really happy when DVD works with madVR. :)
FoLLgoTT
13th April 2009, 09:49
@madshi
I compared the chroma upsampling a bit and I noticed that madVR's frequency response is noticeably lower than ffdshow's (HQ upscaling and Lanczos resize to 1920x1080). In both cases I used Lanczos4 for resizing.
If you look at the middle of the Siemens star you'll see that the lines are not fully resolved. Without the resampling option in madVR the resolution stays almost the same, but aliasing occurs.
ffdshow:
http://img2.imageshack.us/img2/4061/bild3d.th.png (http://img2.imageshack.us/my.php?image=bild3d.png)
madVR with resampling:
http://img2.imageshack.us/img2/6592/bild1dpu.th.png (http://img2.imageshack.us/my.php?image=bild1dpu.png)
madVR without resampling:
http://img2.imageshack.us/img2/1946/bild4d.th.png (http://img2.imageshack.us/my.php?image=bild4d.png)
The problem is even more visible at the burst pattern. The amplitude of the chroma signal begins to fall at 1MHz.
ffdshow:
http://img2.imageshack.us/img2/3711/bild5z.th.png (http://img2.imageshack.us/my.php?image=bild5z.png)
madVR with resampling:
http://img2.imageshack.us/img2/357/bild6.th.png (http://img2.imageshack.us/my.php?image=bild6.png)
Is this a bug or just a side effect of your upsampling algorithm?
leeperry
13th April 2009, 11:11
I wonder if anyone tried to create LUT's w/ custom primaries coordinates, coz I'm getting strange results...even the stock LUT's are way too dark, but yesgrey is on the case :)
VHT
13th April 2009, 11:23
Hi! I've got a problem connecting madVR with ffdshow for post-processing. Using 32-bit vista MPC-HC Beliyaal build (preferred renderer madVR) + CoreAVC without CUDA. I've got raw video in ffdshow on all supported mode and output for YV12 is marked.
madshi
13th April 2009, 11:58
that'd be fun if you could put 3 or 4 digits after the coma for the VSYNC interval.
Not needed. The VSync interval is just calculated by doing "1000 / display refresh rate" and the display refresh rate is displayed with enough digits. So you can calculate the VSync interval yourself. But please note that the display refresh rate is not 100% perfect. So take those additional digits with a grain of salt!
Could that be the cause of the high CPU load? The copy operation from RAM into VRAM is done by the CPU and is a rather slow operation AFAIR.
Well, the data has to be transported to the GPU somehow. All the other renderers must do that, too, sooner or later. Actually if you feed other renderers with RGB data or even with upscaled data, you have to send more data from RAM to GPU than madVR does! So I still don't see why madVR should consume more CPU.
Can anything be done about an error that says "graphics card only supports power of 2 textures?" Happens with my GM45.
Unfortunately there's not so much I can about that. The error message means that your GM45 only supports textures which follow strict resolution patterns. Basically textures on your graphics card must have a width and height of one of the following numbers: 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096. Now madVR needs textures in the resolution of the source (e.g. 720x480 for NTSC-DVD) and in the resolution of the display (e.g. 1920x1080). Your GM45 seemingly does not support textures in such "odd" resolutions. Probably it would be possible to use the next higher supported resolution like e.g. 2048x2048, but that would make texture addressing in my shaders a lot more complicated. So I'd rather not support that. I fear the GM45 would be too slow, anyway... :(
display 72.0xxxxHz
movie 23.976 fps
frame queue pretty much always 16/16
movie resolution 1280,720
target rectangle 0,152,1280,872
vsync interval 13.90ms
movie frame interval 41.71ms
avrg gpu rendering time ~3ms
max rendering time is ~4ms
These are extremely good numbers. Of course it helps that you have 1:1 display and don't need to scale.
CoreAVC w/ CUDA same as above but:
max rendering time -> update textures goes from normal ~2ms up to 12-15ms then down to normal, then again up, etc. happens every now and then.
with some 1080p high bitrate material it goes even higher resulting in strong stuttering. some other material works without any flaws.
Interesting!
- time behind display x.xxxx.Hz in brackets stays fixed (0s/1s/2s) or counts sometimes
If the time counter goes up a lot that helps exactness of the display refresh rate calculation. The time counter restarts from 0s, if madVR ran into any kind of trouble interpreting the VSync data.
- I noticed that a display refresh rate slightly below 3*23.976Hz (CVT reduced blanking for example) causes stuttering. While a refresh rate slightly above 3*23.976Hz results in smooth playback. Unfortunately I can't test this for 75Hz becaused i can't get more then 75.01xxHz which is not enough as it seems.
That problem should be solved in a future version of madVR. Might take a while, though...
- display refresh rate detection works sometimes, if 0.0000Hz is displayed window minimize->restore is a workaround
Do you really have to minimize/restore? The display refresh rate detection should be able to recover automatically. It retries measurements every second.
Strange;
when i opened DGAVCNV avs file with GraphStudio, CPU utilization decreased to 25 to 35 % level.
Avi/wav File Source > MadVR
What is interesting here is MPC-HC is using the same filter chain as well but with a 50-75 % Cpu consumption???? :confused:
Weird!!
You say that you can't output to YCbCr444 with our video cards, or at least easily. Actually, I'm running Win 7 with the WDDM 1.1 driver and the default control panel has a specific page that has a simple dropdown box to switch between RGB and YCbCr444 output over HDMI.
Yeah, but how do you know what the driver does internally? E.g. with ATI cards even if you do select YCbCr output, BTB and WTW are clipped, which is a strong indicator that the graphics card internally does YCbCr (video) -> RGB (PC) -> YCbCr (video), which I consider bad.
I do have one request though, can you compile this for 64-bit windows?
I've already replied to this question a few posts before.
I have only one small suggestion. It would be great, if the number of lobes/taps of Lanczos could be chosen like in ffdshow. I know that many people will claim that ringing becomes visible, but this is only true with test patterns and not with low pass filtered movies, because ringing only occurs near the band limit. The advantage of 8 or 10 taps is a much better frequency response and visible less aliasing.
Ok, will add 8 tap Lanczos. But in my tests it didn't look any better than 4 tap Lanczos. Actually it looked worse to me, because it was not any sharper and only ever so slightly less aliased, but had very noticeable double ringing!
...even the stock LUT's are way too dark, but yesgrey is on the case :)
You mean the default LUTs created by madVR are too dark? Or are they only too dark if you activate custom primaries?
Hi! I've got a problem connecting madVR with ffdshow for post-processing. Using 32-bit vista MPC-HC Beliyaal build (preferred renderer madVR) + CoreAVC without CUDA. I've got raw video in ffdshow on all supported mode and output for YV12 is marked.
There's a switch somewhere in ffdshow to allow or forbid to connect to "unknown" filters.
madshi
13th April 2009, 12:06
I compared the chroma upsampling a bit and I noticed that madVR's frequency response is noticeably lower than ffdshow's (HQ upscaling and Lanczos resize to 1920x1080). In both cases I used Lanczos4 for resizing.
These are pretty interesting tests - thanks! Are these test pattern (legally) available somewhere for download?
If you look at the middle of the Siemens star you'll see that the lines are not fully resolved. Without the resampling option in madVR the resolution stays almost the same, but aliasing occurs.
Which madVR resampling option do you mean?
The problem is even more visible at the burst pattern. The amplitude of the chroma signal begins to fall at 1MHz.
Is this a bug or just a side effect of your upsampling algorithm?
I've optimized my chroma upsampling algorithm in such a way that it gets rid of all the nasty aliasing. That may result in a hit on frequency response. Of course that's not nice. But we have to set our priorities right: Do you want higher frequency response and live with ugly jaggies? Or do you want smooth jaggies and can live with a lower frequency response?
Please check out the chroma upsampling screenshots in the 2nd post of this thread. Don't you agree that madVR's chroma upsampling looks *a lot* better than ffdshow's HQ chroma upsampling in those screenshots? I guess I could offer "nearest neighbor" chroma upsampling. That would probably produce a perfect frequency response. And it would result in the most ugly chroma upsampling quality possible... ;)
But seriously, I could allow different chroma upsampling algorithms (e.g. Bicubic and Lanczos) to be selected in addition to the currently used very soft resampler (which is SoftCubic100). So you could find your own compromise between jaggies and frequency response. Would you consider that useful?
Can you see the "missing" frequency response in any real life pictures?
leeperry
13th April 2009, 12:19
You mean the default LUTs created by madVR are too dark? Or are they only too dark if you activate custom primaries?
well..I output PC range off ffdshow and my displays all have PC range(so no levels conversion needed)
that's my RGB32HQ picture :
http://www.image-load.eu/out.php/i157521_rgb32hq.png
now w/ ddcc doing the gamut conversion(8bit LUT created in ddcc) in HR :
http://www.image-load.eu/out.php/i157519_ddcc.png
and that's w/ a 16bit LUT from yesgrey's app in t3dlut() :
http://www.image-load.eu/out.php/i157520_lut.png
so that 16bit LUT is way too dark, and my .ini settings appear to be OK...even yesgrey agrees.
and I'm getting opposite results when I put this LUT in madVR :confused:
that's w/ ddcc(8bit LUT created in ddcc) in HR :
http://www.image-load.eu/out.php/i157518_hr.png
this is the stock HD LUT in madVR :
http://www.imagebam.com/image/43c8ae32526309
and this is my custom 16bit LUT :
http://www.imagebam.com/image/c716bb32526310
I know ddcc "works" coz it matches what the PS script outputs(slightly better of course)...
I think you may wanna give the option to the user to choose untouched levels or TV>PC conversion, and then make 2 LUT's :
SD: REC.601 (untouched levels OR levels expansion from TV to PC)
HD: REC.709 (untouched levels OR levels expansion from TV to PC)
but anyway, the CMS is pretty broken right now I think, waiting for yesgrey's feedback :cool:
VHT
13th April 2009, 13:45
There's a switch somewhere in ffdshow to allow or forbid to connect to "unknown" filters.
Madshi.I did find the switch but didn't solve my problem.Ffdshow connects nicely with MadVR if I use ffdshow to decode my H264 movies but when I try to use CoreAVC for decoding, ffdshow doesn't want to connect anymore...(Ffdshow settings are inputting and outputting YV12, so that shouldn't be the problem).Also my Coreavc settings should be correct.
Mike5
13th April 2009, 13:57
@VHT
Have you set ffdshow video / Codecs / Raw video = all supported ?
If the CoreAVC output color space doesn't match ffdshow allowed input color spaces, ffdshow doesn't enter the graph (as post-processor)
VHT
13th April 2009, 14:01
@VHT
Have you set ffdshow video / Codecs / Raw video = all supported ?
If the CoreAVC output color space doesn't match ffdshow allowed input color spaces, ffdshow doesn't enter the graph (as post-processor)
Yes I have.
madshi
13th April 2009, 14:12
well..I output PC range off ffdshow and my displays all have PC range(so no levels conversion needed)
so that 16bit LUT is way too dark, and my .ini settings appear to be OK...even yesgrey agrees.
and I'm getting opposite results when I put this LUT in madVR :confused:
So is madVR not handling the 3dlut file correctly? yesgrey3, can you confirm that?
Madshi.I did find the switch but didn't solve my problem.Ffdshow connects nicely with MadVR if I use ffdshow to decode my H264 movies but when I try to use CoreAVC for decoding, ffdshow doesn't want to connect anymore...
Can't tell you why. Please try with madVR 0.4. If that still fails, I'd need a sample or something, so that I can reproduce the problem on my PC.
madshi
13th April 2009, 14:20
madVR 0.4 released
http://madshi.net/madVR.zip
* modified (improved?) initialization order
* fixed: aspect ratio was incorrect with some sources
* added Lanczos8 resampling option (but I don't recommend to use it)
* changed the way the GPU textures are updated
Maybe eventually (but probably not) the multi monitor problem is already improved in this build due to the modified initialization order, but I doubt it.
Unless new show stopper bugs show up, this will probably be the last release for this weekend.
buletti
13th April 2009, 14:42
These are pretty interesting tests - thanks! Are these test pattern (legally) available somewhere for download?
I'm afraid they are not. The patterns are from the Peter Finzel Test Disc (http://www.cine4home.de/software/DVD/PeterFinzelTestDisc/PFTestDisc.htm).
There are also similar, commercial calibration test disc from Bürosch, AVIA and Digital Video Essentials. Dunno about free alternatives, tho...
FoLLgoTT
13th April 2009, 14:43
These are pretty interesting tests - thanks! Are these test pattern (legally) available somewhere for download?
They are from the Peter Finzel Disc, a german test pattern DVD. I find these patterns useful to exermine luma and chroma response and aliasing (beats) in just a few seconds. The raw pictures can be legally downloaded here (http://www.peterfinzel.de/tbilder.zip). :)
Which madVR resampling option do you mean?
I meant the option "don't resample chroma".
Please check out the chroma upsampling screenshots in the 2nd post of this thread. Don't you agree that madVR's chroma upsampling looks *a lot* better than ffdshow's HQ chroma upsampling in those screenshots?
It looks better indeed in that example. :)
I guess I could offer "nearest neighbor" chroma upsampling. That would probably produce a perfect frequency response. And it would result in the most ugly chroma upsampling quality possible... ;)
Oh yes! And joe sixpack will be happy about the *sharp* picture! :D
But seriously, I could allow different chroma upsampling algorithms (e.g. Bicubic and Lanczos) to be selected in addition to the currently used very soft resampler (which is SoftCubic100). So you could find your own compromise between jaggies and frequency response. Would you consider that useful?
This is an excellent idea! I hope it is not too much work to implement this option.
Can you see the "missing" frequency response in any real life pictures?
Good point. ;)
In terms of chroma upsampling I have no real world example. Maybe some Pixar movies would have sensitive scenes, but I think I would really have problems noticing the differences.
But in terms of luma scaling I have a few movies which show a visible difference between Lanczos3 and Lanczos10. These movies have very high frequency response and suffer from quite a bit aliasing. With more taps there is very slightly more detail and much less aliasing. The german DVD of "My Fair Lady" is a good example. Maybe some Superbits with aliasing on the disc (e.g. "The 5th Element") could also benefit from more taps. And btw., additional ringing by the scaling algorithm is no problem even with such high frequency material. :)
noee
13th April 2009, 15:13
.4 build
* madVR is now pickup up my LG37 (HDTV) refresh of 24Hz properly.
* Reclock tearing test shows *no* tearing now with 23.976@24Hz playback on *secondary* (LG37)
Movie_frame_interval = 41.71
Avg GPU rendering = 19.67
Excellent work!
ice25
13th April 2009, 15:17
Yup at first glance secondary display detection is working nicely. Well done.
Any chance you could add a A/V jitter statistic to the OSD?
madshi
13th April 2009, 15:39
The raw pictures can be legally downloaded
Very cool! Which license do these pictures come with? Would it be legal to include them in madVR somehow?
This is an excellent idea!
Which scaling algorithms would you like to have? The same used for luma scaling? Or a subset?
But in terms of luma scaling I have a few movies which show a visible difference between Lanczos3 and Lanczos10. These movies have very high frequency response and suffer from quite a bit aliasing. With more taps there is very slightly more detail and much less aliasing. The german DVD of "My Fair Lady" is a good example. Maybe some Superbits with aliasing on the disc (e.g. "The 5th Element") could also benefit from more taps.
Well, madVR 0.4 now does Lanczos8. Personally, I think the difference between Lanczos3 and Lanczos4 is bigger than the difference between Lanczos8 and Lanczos4. So I think Lanczos8 should be virtually identical to Lanczos10.
And btw., additional ringing by the scaling algorithm is no problem even with such high frequency material. :)
I don't agree.
.4 build
* madVR is now pickup up my LG37 (HDTV) refresh of 24Hz properly.
* Reclock tearing test shows *no* tearing now with 23.976@24Hz playback on *secondary* (LG37)
Yup at first glance secondary display detection is working nicely. Well done.
Great news! I was hoping for that, but didn't really expect it.
So is CPU consumption on secondary display ok now, too? No more 100%?
Any chance you could add a A/V jitter statistic to the OSD?
That would fall under the "smooth playback" category which is not implemented yet. So I can't give you any comment on that...
FoLLgoTT
13th April 2009, 15:53
Very cool! Which license do these pictures come with? Would it be legal to include them in madVR somehow?
I guess you have to ask Peter Finzel. I don't know under which license the pictures are published.
Which scaling algorithms would you like to have? The same used for luma scaling? Or a subset?
For my part Lanczos would be enough as an extra option. But the algorithms are already there so maybe it could be useful to choose between all available.
Well, madVR 0.4 now does Lanczos8. Personally, I think the difference between Lanczos3 and Lanczos4 is bigger than the difference between Lanczos8 and Lanczos4. So I think Lanczos8 should be virtually identical to Lanczos10.
I agree. The difference between Lanczos8 and 10 is very little.
I don't agree.
I'm really interested, because I never saw it outside of test patterns yet. All I noticed was an amplification of the inherent EE of the disc, because of the algorithm's better frequency response.
Do you have DVD examples on which additional ringing is visible in a movie? I mean scenes inside the movie and not the fonts at the ending? If this discussion is too off topic I would be thankful for a short PM. :)
noee
13th April 2009, 15:57
So is CPU consumption on secondary display ok now, too? No more 100%?
FWIW, I never saw the CPU utilization issues others mentioned re: secondary monitor. My CPU util is around 12% and GPU is around 45% running X2 O/C at 3.0Ghz, this is with SD material upscaled to 1080P, Lanczos 4-tap.
For HD material (1080P-M2TS AVCHD), CPU util is around 55%, using MPC-HC internal decoders.
leeperry
13th April 2009, 15:59
examples on which additional ringing is visible in a movie? I mean scenes inside the movie and not the fonts at the ending?
the start credits of Shoot'em Up on BD are very good to spot dodgy chroma processing(the big SHOOT/EM/UP logos written in blood)...but apart from these extreme examples, any red object should do(there's a woman w/ a strongly saturated red coat in "Night at the Museum")
FoLLgoTT
13th April 2009, 16:01
the start credits of Shoot'em Up on BD are very good to spot dodgy chroma processing(the big SHOOT/EM/UP logos written in blood)...but apart from these extreme examples, any red object should do(one woman in THE NIGHT MUSEUM has a strongly saturated red coat that might help too)
Thanks for the hint. But my quote was in the context of (luma) scaling and not chroma processing. :)
leeperry
13th April 2009, 16:02
Thanks for the hint. But my quote was in the context of (luma) scaling and not chroma processing. :)
OK, I thought I was missing the point...and I was :rolleyes:
I'm very concerned about chroma(being colorblind and all), I let you guys take care of luma then :D
TinTime
13th April 2009, 16:20
Very cool! Which license do these pictures come with? Would it be legal to include them in madVR somehow?
Looks like they're copyright Peter Finzel Productions (http://www.peterfinzel.de/impres.htm) so you'd have to get his permission to distribute them.
midiboy
13th April 2009, 16:37
Hi madshi,
thanks for the new renderer. Just playing around with it. Currently I do get lots of heavy stutter in ZoomPlayer when using the renderer though. (on secondary display with reclock) I am on a ATI radeon 4550 with 512MB of memory. I guess that card is not powerful enough, right ? I also tried disabling all quality settings but that did not change much.
CPU utilisation is below 40% on a DualCore CPU and the Haali renderer works fine so I guess the videocard is the problem, right ? Are there any baselines what GPU is the minimum for stutterfree 1080p playback ?
Bye,
Alex
mark0077
13th April 2009, 17:30
Hi all,
Just a thought. Would madshi and beliyaal consider teaming up to integrate beliyaal's work on reducing judder, syncing frames etc, with the excellent levels conversion and more, work by madshi.
I am torn between which renderer I want to use but would love to see madVR with the frame sync stuff from beliyaal if possible to combine both.
It would be a terrible waste of time for madshi to spend lots of time on audio / video sync if its possible to use the existing work by beliyaal.
Cheers,
flanger216
13th April 2009, 17:38
As of 0.4, everything works great on my end. No CPU usage penalty, and I get smooth playback with Bicubuic -0.75 (anything higher introduces stutter in 1080p material). And all of this on a lowly Radeon HD3650. Great job.
Keiyakusha
13th April 2009, 18:20
madshi
Can you add support for loading subtitles anytime soon or this is too much of work for now? I really want watch some movies with MPC-HC/madVR but i prefer to watch with subtitles coz English is not my native language. "Use VobSub" is not the solution.
TinTime
13th April 2009, 19:21
madshi, aspect ratios are still not (quite) handled correctly. I've got a 704x576 encode with a 16/9 ar that madVR scales to 1918x1080, not 1920x1080. VMR9 and Haali both scale correctly.
Here's a sample (http://www.sendspace.com/file/7d51sd).
Thanks very much.
pitch.fr
13th April 2009, 20:02
Sorry My English isn't very well
Hello, very good job on the new renderer, but I find the latest version 0.4 less "smooth"
leeperry
13th April 2009, 20:09
yep, I agree I found beta2 smoother...it takes more reseeks w/ Reclock to catch the VSYNC in beta3 & 4, but the smooth code is not there yet ;)
KoD
13th April 2009, 20:16
True, I've just noticed jerky pans when playing a 480p xvid file. Frame decoding time is not an issue here, there must be something else that's causing these jerky pans.
madshi
13th April 2009, 20:17
I'm really interested, because I never saw it outside of test patterns yet.
Then you haven't looked properly... ;)
Since you mentioned the Germany My Fair Lady DVD, here's that DVD, enlarged to my PC display's native resolution of 1680x1050:
http://madshi.net/madVR/Audrey.png
Left side is "SoftCubic50", right size "Lanczos8". The ringing you can see in the right side is not in the source at all. It's added by the Lanczos resampling algorithm. As you can see, I didn't have to search very long to find ringing. After all this is still the movie intro... ;) Here are the full screenshots:
SoftCubic50 (http://madshi.net/madVR/AudreySoftCubic50.png)
Lanczos8 (http://madshi.net/madVR/AudreyLanczos8.png)
Looks like they're copyright Peter Finzel Productions (http://www.peterfinzel.de/impres.htm) so you'd have to get his permission to distribute them.
Thanks.
Currently I do get lots of heavy stutter in ZoomPlayer when using the renderer though. (on secondary display with reclock) I am on a ATI radeon 4550 with 512MB of memory. I guess that card is not powerful enough, right ? I also tried disabling all quality settings but that did not change much.
Press Ctrl+J, then post your stats here. That may help us figuring out whether your GPU is fast enough or not.
Would madshi and beliyaal consider teaming up to integrate beliyaal's work on reducing judder, syncing frames etc, with the excellent levels conversion and more, work by madshi.
Beliyaal has done great work to improve smoothness with the MPC HC renderers. But I haven't even started looking into this kind of stuff yet. I also don't know if his tweaks would work with my renderer. Maybe yes, maybe no. My renderer eats a lot more GPU shader resources than the MPC HC renderers do. Maybe if I run into trouble with implementing smooth playback, I will ask Beliyaal to come on board. But I'm not sure if he wanted that, after all madVR is closed source and I want to keep it that way. But this is too early, anyway. As I said a lot of times already, I DON'T really want to talk about smooth motion playback yet.
Can you add support for loading subtitles anytime soon or this is too much of work for now?
It's one of the many things still missing. I haven't decided on in which order I will tackle them. Everybody has his own priorities...
I've got a 704x576 encode with a 16/9 ar that madVR scales to 1918x1080, not 1920x1080.
Thanks, that's a simple rounding issue. Will be fixed in the next build.
Sorry My English isn't very well
Hello, very good job on the new renderer, but I find the latest version 0.4 less "smooth"
Again (and again and again) motion smoothness is not a thing I have really looked into yet. Did your GPU stats (see Ctrl+J), especially "average gpu rendering time" get worse with 0.4 compared to 0.3? That's a thing I would have to look into.
tetsuo55
13th April 2009, 20:26
Hi
I just tested v4 (did not try the older builds)
The bat file failed to install on my system (windows 7 32bit)
The 1:1 results for media my system can handle are okay, but as soon as any scaling is applied the video becomes a slideshow.
My specs:
AthlonXP 2600+ @ 2ghz
A7N8X Deluxe
ATI HD2400pro AGP
Windows 7
Catalyst 9.3
CPU% maxes out as soon a scaling is enabled
1:1 usage is between 30-80%
EVR-CP cpu usage is 10%
Screenshot of 1:1 stats:
http://img213.imageshack.us/img213/6663/1on1.th.png (http://img213.imageshack.us/my.php?image=1on1.png)
Screenshot of scaled to 1920x1080:
http://img208.imageshack.us/img208/892/scaledto1920x180.th.png (http://img208.imageshack.us/my.php?image=scaledto1920x180.png)
due to no DXVA support i was unable to test anything above SD resolution (With overlay renderer my cpu is just fast enough for 1280x720)
madshi
13th April 2009, 20:39
The bat file failed to install on my system (windows 7 32bit)
Did you get any specific error message?
The 1:1 results for media my system can handle are okay, but as soon as any scaling is applied the video becomes a slideshow.
My specs:
AthlonXP 2600+ @ 2ghz
A7N8X Deluxe
ATI HD2400pro AGP
Windows 7
Catalyst 9.3
CPU% maxes out as soon a scaling is enabled
1:1 usage is between 30-80%
EVR-CP cpu usage is 10%
Not sure why you get so much higher CPU usage when scaling is enabled. For me CPU consumption does not change much if I enable/disable scaling. Could you please try 1:1 and then just zoom in one step (MPC HC numpad [9], IIRC)? Do you get the same high CPU consumption that way?
Screenshot of 1:1 stats:
Screenshot of scaled to 1920x1080:
Wow, what a difference in gpu rendering times! Ok, the source seems to have a very small resolution. Of course that helps keeping rendering times down in 1:1 mode. "average gpu rendering time" is the most important and it's quite nice with 5ms in 1:1 mode. It needs to be smaller than the "movie frame interval" (40ms). However, in scaled mode your "average gpu rendering time" is going through the roof with almost 60ms! That's too much. It seems that your graphics card is not fast enough to do scaling to 1080p with full madVR quality options. You can turn down the quality a bit in the madVR settings dialog. Maybe that helps? Try lowering luma+chroma textures to 10bit. With a bit of luck that might already be enough to push "average gpu rendering time" down under 40ms.
mark0077
13th April 2009, 20:49
Using version 4, with ffdshow in the chain doing de-interlacing (if necessary) I get DVD Macrovision failed error playing backed up dvd's from hdd.
This was the reason I could never use Haali also, could never get rid of this error.
Brazil2
13th April 2009, 21:43
madVR 0.4 released
* fixed: aspect ratio was incorrect with some sources
I'm still having aspect ratio troubles with the two samples I've posted here (http://forum.doom9.org/showthread.php?p=1273052#post1273052).
The first sample (VC-1 in MKV) gives me the correct aspect ratio with the MPC-HC built-in decoder. I always got a wrong aspect ratio when the Microsoft decoder is used and it doesn't matter which splitter is used. The Arcsoft decoder doesn't want to connect even with the VC1tweak filter so I'm stuck to the MPC-HC decoder or the Microsoft one, but as you know the MPC-HC decoder is not working fine with your renderer for now.
Now I got different results with the Beyonce TS sample depending on which combination of splitter + decoder is used. So I've done more tests:
Splitter + Decoder = aspect ratio result
MPC-HC + MPC-HC = wrong
MPC-HC + Arcsoft = wrong
MPC-HC + CoreAVC = OK
MPC-HC + Divx7 = wrong
Arcsoft + MPC-HC = OK but lot of stuttering (+ the bug of the decoder)
Arcsoft + Arcsoft = OK
Arcsoft + CoreAVC = wrong
Arcsoft + Divx7 = doesn't connect
I don't have Haali installed and I don't plan to install it. My config is actually working fine for every use I have except some troubles with MadVR.
But I know it's a work in progress, I don't blame I only report. Good and impressive job anyway, thanks for that :)
vBulletin® v3.8.5, Copyright ©2000-2012, Jelsoft Enterprises Ltd.