View Full Version : madVR - high quality video renderer (GPU assisted)
tetsuo55
13th April 2009, 22:03
Did you get any specific error message?
Nope,it just flashes on the screen for a second and is gone.
Manually running the command from a admin command prompt works fine
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?
I did some more tests.
High CPU consumption is caused by the OSD stats(ctrl-J)
without ctrl-J cpu usage is always 35% regardless of scaling settings, retested with EVR-CP too and it's not as stale as with madvr, it hovers between 10 and 22% averaging around 15
EDIT: i also tested beliyaal's build and it gets an average of 25
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.
With everything disabled i get +/- 50ms :(
ericgur
13th April 2009, 22:15
Hi,
First, I'd like to thank you for your iniative creating MadVR.
I wrote a VR for internal company use a year ago and I know the pains....
I came into 2 issues:
When pressing CTRL+ALT+DEL (going into the screen where you can lock your computer or start task manager) and coming back to the desktop, the player crashes. Doesn't matter if in full screen or not. You should check you have a valid D3D device before the call to pd3dDevice->Present().
something like (similar code was found in direct show sample code from Windows SDK):
HRESULT hr = pd3dDevice->TestCooperativeLevel();
//device not ready!
if (hr != D3D_OK)
{
// If the device was lost, do not render until we get it back
if (D3DERR_DEVICELOST == hr || D3DERR_DRIVERINTERNALERROR == hr)
{
return E_FAIL;
}
// Check if the device needs to be reset.
if( D3DERR_DEVICENOTRESET == hr )
{
// Reset the D3D environment
DestroyD3D9();
hr = InitializeD3D9();
if (FAILED(hr))
return hr;
hr = pd3dDevice->TestCooperativeLevel();
if (FAILED(hr))
return hr;
}
else
{
ErrMsg("D3D device reported an internal error!\n"
"Quiting application.\n");
exit(hr);
}
}
Loosing the D3D device can occur as a result of screen savers or when the monitor is tuned off by the VGA driver as well.
The other issue is minor, when MadVR is first launched, no setting are set in the DS property page. Maybe the default scaling algorithm should be set.
My setup
Vista 64 SP1
ZoomPlayer
vucloutr
14th April 2009, 00:18
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.
Well for the 720p files I checked already "max gpu rendering time" -> "resample textures" (which was "update textures" before?)
has gone up to ~4ms from ~2ms before but "average gpu rendering time" is practically as good as with madVR 0.3.
yesgrey
14th April 2009, 00:27
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 :)
So is madVR not handling the 3dlut file correctly? yesgrey3, can you confirm that?
There is no problem with madVR nor with cr3dlut. leeperry was just using a custom output gamma curve different from the input gamma curve.
For now all users should use the same gamma curves for input and output. This is a subject that should be discussed carefully, so let's wait I have the time for starting the cr3dlut thread...;)
madshi
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 also think it would be good adding subtitles rendering for madVR, but I think its priority should be lower than smoothing playing (madshi, I'm not discussing IT, just setting its priority ;)). Currently we can use Vobsub or ffdshow's subtitle renderer.
leeperry
14th April 2009, 01:44
There is no problem with madVR nor with cr3dlut. leeperry was just using a custom output gamma curve different from the input gamma curve.
For now all users should use the same gamma curves for input and output. This is a subject that should be discussed carefully, so let's wait I have the time for starting the cr3dlut thread...;)
well, the same 16LUT gives different results in t3dlut() and MVR...both different from ddcc(), and no matter what I do it's too green compared to ddcc() :(
I got a test rec709 MKV(made by Kazuya), I will put it through ddcc()/t3dlut()/MVR tomorrow : http://rapidshare.com/files/221027650/rec709.mkv.html
anyway, I've watched a 2H movie w/ Reclock in 48Hz, the colorimetry was a bit off but it was hell smooth and very sharp, way to go! http://forum-images.hardware.fr/images/perso/skykhan.gif
OTOH some BD's seem very hard to stabilize w/ CoreAVC+all my PP, but as soon as I turn CUDA on...hell breaks loose, I get tearing at the third quarter bottom of the screen(and reseeking does not help).
do any of the stats look alarming? it plays fine in HR(RGB32).
http://www.image-load.eu/out.php/t157646_night.png (http://www.image-load.eu/out.php/i157646_night.png)
Malow
14th April 2009, 01:59
an 9800GT Pci-E 2.0 @ 16x is not capable of output 60fps video at 1920x1200 screen?
wen using BOB on interlaced material, the playback is jerky. but if not viewing in fullscreen (resizing the window to 75% of display) the playback is smooth.
this happens with madVR and haali renderer... only crappy overlay can play full-hd video at 60fps... :(
leeperry
14th April 2009, 02:08
wen using BOB on interlaced material, the playback is jerky. but if not viewing in fullscreen (resizing the window to 75% of display) the playback is smooth.
this happens with madVR and haali renderer... only crappy overlay can play full-hd video at 60fps... :(
read up the last pages of the HR thread, someone mentioned that the latest HR build stutters badly on 60fps and that some older builds work fine. I tried it, and that's a fact!
Shinigami-Sama
14th April 2009, 03:51
I'm getting some weirdness with Dark_Shikari's 1080p Big buck bunny
click (http://shinigami.ca/d9/bbb.png)
mitchel resizer
i7 920
GTX 280
win7
had to register the ax myself as well
Snowknight26
14th April 2009, 06:19
I'm getting some weirdness with Dark_Shikari's 1080p Big buck bunny
click (http://shinigami.ca/d9/bbb.png)
MPC Video Decoder issue.
Shinigami-Sama
14th April 2009, 06:21
MPC Video Decoder issue.
was working last time I played it
madshi
14th April 2009, 08:07
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 VC-1 aspect ratio problem will be fixed in the next build.
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
Hmmmmm, it seems that with e.g. divx7 the correct aspect ratio is only available after playback already started. Will have to look into this.
It seems now there's no difference between primary and secondary monitor in terms of CPU consumption, only thing matters is what monitor the video has been initialized in!!! The following scenario is now valid: open an empty window on primary, move to secondary, drop a video into it -- no core maximisation ;P move the window back to primary -- maximisation is present again :) If I revert the order of monitors in this scenario and do it again, same thing happens.
To sum up, it is possible to use a workaround now, which is to force madVR to reinitialize on a different monitor. That apparently fixes now both refresh issue and CPU consumption. Only thing now is to make it work automatically ;))
Yeah, madVR does currently not detect when you move the media player window to another monitor. Will need to add that.
Nope,it just flashes on the screen for a second and is gone.
Manually running the command from a admin command prompt works fine
Could you please try starting the batch from a command prompt, so that you can see (and report) the error message?
Thanks!
I did some more tests.
High CPU consumption is caused by the OSD stats(ctrl-J)
That makes sense. It's not 100% for me, but with OSD active I'm doing some things differently to be able to output reliable statistics. This different way of doing things costs a lot more CPU.
With everything disabled i get +/- 50ms :(
Well, you could still switch scaling to "Bilinear", that is done by the graphics card "for free". Doing that might push you under 40ms. But of course then you have lost many advantages of madVR. So I'd say with your graphics card using madVR does not really make that much sense, unless you want to use madVR for gamut&gamma correction...
When pressing CTRL+ALT+DEL (going into the screen where you can lock your computer or start task manager) and coming back to the desktop, the player crashes.
Thanks, will look at that.
The other issue is minor, when MadVR is first launched, no setting are set in the DS property page. Maybe the default scaling algorithm should be set.
Works for me!
Well for the 720p files I checked already "max gpu rendering time" -> "resample textures" (which was "update textures" before?)
has gone up to ~4ms from ~2ms before but "average gpu rendering time" is practically as good as with madVR 0.3.
With v0.3 there were 2 separate lines "update textures" and "resample textures". Now with v0.4 "update textures" is gone, because I'm not doing that myself, anymore. Instead I leave that to Direct3D. Probably "resample textures" takes more time because of that now. The "average gpu rendering time" is unchanged for me, too.
There is no problem with madVR nor with cr3dlut. leeperry was just using a custom output gamma curve different from the input gamma curve.
But why does he get different results from t3dlut and madVR?
OTOH some BD's seem very hard to stabilize w/ CoreAVC+all my PP, but as soon as I turn CUDA on...hell breaks loose, I get tearing at the third quarter bottom of the screen(and reseeking does not help).
do any of the stats look alarming? it plays fine in HR(RGB32).
Stats look beautiful.
an 9800GT Pci-E 2.0 @ 16x is not capable of output 60fps video at 1920x1200 screen?
wen using BOB on interlaced material, the playback is jerky. but if not viewing in fullscreen (resizing the window to 75% of display) the playback is smooth.
this happens with madVR and haali renderer... only crappy overlay can play full-hd video at 60fps... :(
Please post madVR statistics (Ctr+J).
was working last time I played it
The MPC Video decoder bug occurs only when the decoder is forced to output YV12.
FoLLgoTT
14th April 2009, 08:07
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:
I admit in this example the additional ringing inside the fonts is clearly visible and annoying. Thank you for the example! :)
But is it really visible inside of text lacking movie scenes? I never saw it.
On the other hand if you look at these shots from the same movie you can see much less aliasing on the inner side of the mirror (very annoying in moving scenes), but no additional ringing.
Lanczos2:
http://img382.imageshack.us/img382/1435/aliasing2taps.png (http://img382.imageshack.us/my.php?image=aliasing2taps.png)
Lanczos10:
http://img12.imageshack.us/img12/3598/aliasing10taps.png (http://img12.imageshack.us/my.php?image=aliasing10taps.png)
And if we analyze the picture a bit closer with the h-sweep pattern and a waveform analyzer:
http://img223.imageshack.us/img223/2646/hsweep.th.png (http://img223.imageshack.us/my.php?image=hsweep.png)
Lanczos2:
http://img187.imageshack.us/img187/7070/waveform2taps.th.png (http://img187.imageshack.us/my.php?image=waveform2taps.png)
Lanczos10:
http://img21.imageshack.us/img21/1811/waveform10taps.th.png (http://img21.imageshack.us/my.php?image=waveform10taps.png)
It is obvious that the higher frequencies are transported better with Lanczos10 and that this algorithm acts as a better low pass, because beats (aliasing) gets less. The h-sweep looks cleaner and very slightly more detail is visible.
Of course if you look at the sides of the h-sweep (hard edges, square wave) there is additional ringing introduced by the scaling algorithm. But these areas content high spatial frequencies which movies *usually* don't (or as I learned only rarely), because of the necessary low pass filtering.
Anyway, you are right. Because everything is just a big compromise it is just a matter of preference. Less aliasing and more detail (Lanczos8) or less ringing (e.g. Catmull-Rom). :)
madshi
14th April 2009, 08:53
I admit in this example the additional ringing inside the fonts is clearly visible and annoying. Thank you for the example! :)
But is it really visible inside of text lacking movie scenes? I never saw it.
http://madshi.net/madVR/earring.png
I see two or rather three circles (light, dark, light) around that ear ring with Lanczos8.
(This is still My Fair Lady, the scene directly after the intro.)
Anyway, you are right. Because everything is just a big compromise it is just a matter of preference. Less aliasing and more detail (Lanczos8) or less ringing (e.g. Catmull-Rom). :)
Have you tried SoftCubic50? Yeah, it's not as sharp as Lanczos, but it's just as aliasing free as Lanczos (I think) and adds no ringing at all.
yesgrey
14th April 2009, 10:00
well, the same 16LUT gives different results in t3dlut() and MVR...both different from ddcc(), and no matter what I do it's too green compared to ddcc() :(
But why does he get different results from t3dlut and madVR?
I will look into this...
tetsuo55
14th April 2009, 10:19
Hi mashi, yes i tried lowering the scaling filter and was able to get a lower GPU time, now its fully usable!
I Don't have to use point, the next one up works too!
Trade quality for speed options lower 10ms, however the different scalers can make a difference of up to 40ms.
I know my card is not very fast, but it has no problems with Fallout3 @ 1920x1080, with most settings at low
Mark_A_W
14th April 2009, 11:06
Madshi
The tearing on the secondary monitor of my HD2600XT has been fixed by Version 0.4 (or 0.3...I was too slow for that one).
I have to pause/unpause to get smooth playback without jitter (similar to Haali, but not so smooth for now), but it's good, really good.
Thank you very much!
My stats:
display 95.90361 Hz (3s)
movie 23.976 (says source filter)
frame queue 16/16
movie resolution 1920,1080
target rectangle 0,0,1920,1080
vsync interval 10.43ms
movie frame interval 41.71ms
avrg gpu rendering time 14.08ms
max gpu rendering time 20.59ms
avrg present wait time 4.35ms
Is everything ok with the numbers?
As (nearly) always, I am doing no scaling, watching 1920x1080p 23.976fps at 1920x1080 interlaced at 95.904hz on a CRT monitor/projector.
Your renderer is mad :devil:
Mark
Brazil2
14th April 2009, 13:31
I'm getting some weirdness with Dark_Shikari's 1080p Big buck bunny
click (http://shinigami.ca/d9/bbb.png)
Known bug of the MPC-HC internal decoder:
http://forum.doom9.org/showthread.php?p=1272614#post1272614
Malow
14th April 2009, 13:57
Please post madVR statistics (Ctr+J).
fullscreen:
http://i43.tinypic.com/skz7ur.png
windowed:
http://i42.tinypic.com/2powrqv.png
Malow
14th April 2009, 14:20
...someone mentioned that the latest HR build stutters badly on 60fps and that some older builds work fine. I tried it, and that's a fact!
you are right. i got a old one and worked nice at 60fps on fullscreen. BUT is giving tearing... :(
leeperry
14th April 2009, 16:30
you are right. i got a old one and worked nice at 60fps on fullscreen. BUT is giving tearing... :(
I've always been convinced that tearing was due to some bad BIOS design/user misconfiguration...mostly the video data is not copied fast enough from the northbridge I think.
anyway, I've tried numerous mobos/graphic cards...never had any tearing on XP or Vista.
a little while ago, a guy posted all his BIOS settings on the Reclock forum....I gave him a few hints and the tearing he had in HR apparently went away :cool:
http://forum.slysoft.com/showpost.php?p=178428&postcount=18
I will look into this...
that'd be pretty cool to get perfect colorimetry in mVR, hope you can work it out! :thanks:
FoLLgoTT
14th April 2009, 17:25
I see two or rather three circles (light, dark, light) around that ear ring with Lanczos8.
Yes, I see. For my eyes it is not enough to annoy me that much. The ringing at the fonts are much more obvious. I think I'm more sensitive to aliasing than to ringing. ;)
Have you tried SoftCubic50? Yeah, it's not as sharp as Lanczos, but it's just as aliasing free as Lanczos (I think) and adds no ringing at all.
Yes, I tried it and I don't like it. It looks like bicubic scaling with additional low pass filtering. Aliasing is still there. It is only not that visible, because the frequency response is worse than with normal bicubic scaling and aliasing is located at the highest frequencies. The problem here is that the effective bandwidth is lowered and details are also affected by the low pass filtering. The picture looks much softer than with Lanczos or Catmull-Rom.
Btw in terms of bandwidth Catmull-Rom looks like Lanczos3, but with a bit less of ringing and a bit more of aliasing. I still prefer Lanczos8 when watching DVD's. On a big screen any aliasing or lack of detail becomes clearly visible. In my eyes the inherent ringing of most DVD's covers the little additional ringing caused by the scaling algorithm. Just my two cents.
leeperry
14th April 2009, 17:29
Yes, I see. For my eyes it is not enough to annoy me that much. The ringing at the fonts are much more obvious. I think I'm more sensitive to aliasing than to ringing. ;)
I hope I don't have it wrong this time :D
don't u agree that spline36 is prefered for down or upscaling?
this thread seems to convey this idea(and so do my eyes in ffdshow) :
http://forum.doom9.org/showthread.php?p=1266030#post1266030
www.sm64.org/div/Bilinear0.png
www.sm64.org/div/Spline360.png
640x480 to 320x240
Spline36 is sharper, but both look good to me.
tetsuo55
14th April 2009, 17:38
Yes, I see. For my eyes it is not enough to annoy me that much. The ringing at the fonts are much more obvious. I think I'm more sensitive to aliasing than to ringing. ;)
Yes, I tried it and I don't like it. It looks like bicubic scaling with additional low pass filtering. Aliasing is still there. It is only not that visible, because the frequency response is worse than with normal bicubic scaling and aliasing is located at the highest frequencies. The problem here is that the effective bandwidth is lowered and details are also affected by the low pass filtering. The picture looks much softer than with Lanczos or Catmull-Rom.
Btw in terms of bandwidth Catmull-Rom looks like Lanczos3, but with a bit less of ringing and a bit more of aliasing. I still prefer Lanczos8 when watching DVD's. On a big screen any aliasing or lack of detail becomes clearly visible. In my eyes the inherent ringing of most DVD's covers the little additional ringing caused by the scaling algorithm. Just my two cents.
Could lanczos be modded/adjusted to reduce ringing?
If lanczos where ringing free would it be the best scaler?
ericd
14th April 2009, 17:44
please can anybody post a kind of tutorial to use these video renders ,cause some people like me are newbies ,thx a lot....
eric
Egh
14th April 2009, 17:59
Yeah, madVR does currently not detect when you move the media player window to another monitor. Will need to add that..
@Madshi: yeah, and I was soooooooo happy about the fact that madVR can be moved around just like a simple GUI application. :rolleyes:
Thing is to achieve somehow a "soft" reinitialisation of the renderer in the event of posting to a different monitor. Even HR has a noticable lag when you move the window, where video disappears for a second or so. Same with VMR9. madVR is the only one amongst usable renderers which doesn't do this and this is a definate bonus.
Please note that there's also a partial case, when half of the video is shown on one monitor, half on another :p In such cases, haali and VMR9 still output as normal and call for reinitialisation when about 2/3 of the video enters to a different monitor.
I've always been convinced that tearing was due to some bad BIOS design/user misconfiguration...mostly the video data is not copied fast enough from the northbridge I think.
anyway, I've tried numerous mobos/graphic cards...never had any tearing on XP or Vista.
a little while ago, a guy posted all his BIOS settings on the Reclock forum....I gave him a few hints and the tearing he had in HR apparently went away :cool:
Wheeeeeeee! So I'm not the only person in the world who thinks that "tearing" etc is most overrated issue in video ever ;) I had 7600 and 7900, on completely different systems, on old Athlon and much newer E8500, on XP and on XP64, and yet to see any tearing on video whatsoever :)
madshi
14th April 2009, 18:32
The tearing on the secondary monitor of my HD2600XT has been fixed by Version 0.4 (or 0.3...I was too slow for that one).
Great!
display 95.90361 Hz (3s)
movie 23.976 (says source filter)
frame queue 16/16
movie resolution 1920,1080
target rectangle 0,0,1920,1080
vsync interval 10.43ms
movie frame interval 41.71ms
avrg gpu rendering time 14.08ms
max gpu rendering time 20.59ms
avrg present wait time 4.35ms
Good numbers, in 1:1 mode. If you need to scale, things could get worse...
fullscreen:
windowed:
Looks good to me. Your graphics card seems to be plenty fast.
Btw in terms of bandwidth Catmull-Rom looks like Lanczos3, but with a bit less of ringing and a bit more of aliasing. I still prefer Lanczos8 when watching DVD's. On a big screen any aliasing or lack of detail becomes clearly visible. In my eyes the inherent ringing of most DVD's covers the little additional ringing caused by the scaling algorithm. Just my two cents.
Well, everybody has his own taste. That's why madVR offers all those algorithms for selection.
Could lanczos be modded/adjusted to reduce ringing?
You may want to search for threads started by me... ;)
please can anybody post a kind of tutorial to use these video renders ,cause some people like me are newbies ,thx a lot....
Basically:
(1) Use a good media player, e.g. MPC HC or Zoom Player.
(2) Select whatever renderer you want to use in the media player settings.
(3) Configure the media player and renderer to match your device setup and your personal likings.
Done.
yeah, and I was soooooooo happy about the fact that madVR can be moved around just like a simple GUI application. :rolleyes:
Thing is to achieve somehow a "soft" reinitialisation of the renderer in the event of posting to a different monitor. Even HR has a noticable lag when you move the window, where video disappears for a second or so. Same with VMR9. madVR is the only one amongst usable renderers which doesn't do this and this is a definate bonus.
Well, this bonus will likely go away, as soon as I implement the proper solution. There will likely be a lag which is as big as when switching madVR between fullscreen and windowed.
FoLLgoTT
14th April 2009, 18:43
@leeperry
don't u agree that spline36 is prefered for down or upscaling?
I never spent much time in downscaling, so I cannot tell.
For upscaling I always found that Spline in ffdshow (is it spline36?) looks very close to Lanczos3. And because it s not parametric for tweaking ringing/alising I always used Lanczos.
@tetsuo55
Could lanczos be modded/adjusted to reduce ringing?
I don't know. Although I learned the basics about signal theory/processing during my study period I'm not that much into resampling algorithms that I could tell.
But there is already a thread (http://forum.doom9.org/showthread.php?t=145358&highlight=non-ringing+lanczos) from madshi with this topic. ;)
leeperry
14th April 2009, 19:24
I never spent much time in downscaling, so I cannot tell.
For upscaling I always found that Spline in ffdshow (is it spline36?) looks very close to Lanczos3. And because it s not parametric for tweaking ringing/alising I always used Lanczos.
I post-process all my video content in the avisynth filter of ffdshow, so most likely I will always be sending native res to mVR. Yes, I think spline in ffdshow is spline36.
so what settings do you recommend exactly? what do u mean by "tweaking ringing/aliasing"...the number of taps?
chros
14th April 2009, 19:25
@madshi:
feature request:
- support for the built-in subtitle engine (like Haali's Renderer) (important !!!)
- if possible:built-in shader support
- if not possible: sharpener scripts (eg. complex sharpen2) after the resizer (or customizable shader support ???)
question: isn't dxva support available at all by design ? (I tried CoreAVC CUDA, and it works, so it's not a big deal for nvidia users)
Thanks
Egh
14th April 2009, 19:56
Well, this bonus will likely go away, as soon as I implement the proper solution. There will likely be a lag which is as big as when switching madVR between fullscreen and windowed.
I've checked the fullscreen mode and seems the switching lag is less than the lag caused by initialisation. So it may be tolerable.
Seems though when enabling fullscreen it first shows it as entire screen, and only then applies aspect ratio correction.
yesgrey
14th April 2009, 20:32
I will look into this...
that'd be pretty cool to get perfect colorimetry in mVR, hope you can work it out! :thanks:
I've been looking into this and there is not any problem with cr3dlut or with madVR.
I've compared leeperry's settings with cr3dlut 8bit and 16bit output 3DLUT files using t3dlut and madVR (only the 16bit), and with ddcc 3D LUT files with the same settings, and the images all look the same.
In fact, there is a small difference, between some of the images, but only because those images use 3D LUTs created with different settings. These images have the suffix "leeperry".
You can compare the results here (http://www.megaupload.com/?d=I5K33GBR).
So, what was the problem?
In his original settings, he was using a custom gamma curve for removing and reapplying gamma, for the color gamut correction, and with the new settings, he was using the standard curves. So, the color gamut correction is slightly different, but the more accurate should be the the newest.
madshi
14th April 2009, 20:38
- support for the built-in subtitle engine (like Haali's Renderer) (important !!!)
- if possible:built-in shader support
Already on the to do list.
question: isn't dxva support available at all by design ?
It's not available at all due to design.
Seems though when enabling fullscreen it first shows it as entire screen, and only then applies aspect ratio correction.
Yes, not sure if I can improve that. That's probably just the way the events come in...
I've been looking into this and there is not any problem with cr3dlut or with madVR.
I've compared leeperry's settings with cr3dlut 8bit and 16bit output 3DLUT files using t3dlut and madVR (only the 16bit), and with ddcc 3D LUT files with the same settings, and the images all look the same.
Thanks! I'm relieved... :)
leeperry
14th April 2009, 20:47
I've been looking into this and there is not any problem with cr3dlut or with madVR.
I've compared leeperry's settings with cr3dlut 8bit and 16bit output 3DLUT files using t3dlut and madVR (only the 16bit), and with ddcc 3D LUT files with the same settings, and the images all look the same.
In fact, there is a small difference, between some of the images, but only because those images use 3D LUTs created with different settings. These images have the suffix "leeperry".
You can compare the results here (http://www.megaupload.com/?d=I5K33GBR).
So, what was the problem?
In his original settings, he was using a custom gamma curve for removing and reapplying gamma, for the color gamut correction, and with the new settings, he was using the standard curves. So, the color gamut correction is slightly different, but the more accurate should be the the newest.
complaining that it doesn't work in public makes it sound like I'm b*tching, I was simply wondering if anyone else tried to set custom primaries...nothing else.
I've made compares w/ rec709.mkv and just dropped you a PM.
:thanks: for your answer!
cyberbeing
14th April 2009, 22:01
I was simply wondering if anyone else tried to set custom primaries...nothing else.
I have been ever since madVR was first released and haven't noticed any problems. madVR = t3dlut = ddcc.
leeperry
14th April 2009, 22:22
I have been ever since madVR was first released and haven't noticed any problems. madVR = t3dlut = ddcc.
well mVR=t3dlut YES! I messed up and put ConvertToRGB32() instead of ConvertToYUY2()...my bad :rolleyes:
but I don't get the same colors from the original PS script and rgb3dlut() :confused:
I just want plain 1/0.45 primaries correction...I will try ddcc in realtime now, this gave me the same colors as the PS script a while ago
PS: ddcc in realtime = PS script...exactly what I want! but when I go LUT it goes really wrong I think :o
flanger216
14th April 2009, 22:43
I've always been convinced that tearing was due to some bad BIOS design/user misconfiguration...mostly the video data is not copied fast enough from the northbridge I think.
anyway, I've tried numerous mobos/graphic cards...never had any tearing on XP or Vista.
I used to own a Samsung monitor that teared on everything - video games, movies, even the Windows desktop. The only way I fixed it was to fire up a tearing test, load Powerstrip and mess with the refresh rate at hundreths of a hertz. Eventually I found that tearing went away when I changed the refresh rate from ~59.9hz to ~59.8hz. Weird, huh?
Wheeeeeeee! So I'm not the only person in the world who thinks that "tearing" etc is most overrated issue in video ever ;) I had 7600 and 7900, on completely different systems, on old Athlon and much newer E8500, on XP and on XP64, and yet to see any tearing on video whatsoever :)
Gee, so you think a problem you've never had is "overrated." And, of course, your sample size of two completely different systems is astonishingly comprehensive. Personally, I think the bubonic plague is 'overrated,' based on the sole fact that I've never had it.
leeperry
14th April 2009, 22:47
that's the original untouched file(RGB32HQ 0-255 in VMR9) :
http://thumbnails16.imagebam.com/3271/befb9532705055.gif (http://www.imagebam.com/image/befb9532705055)
that's the PS script on top of it :
http://thumbnails17.imagebam.com/3271/f4984132705056.gif (http://www.imagebam.com/image/f4984132705056)
that's ddcc 1.9 in realtime (identical to the PS script!) :
http://thumbnails2.imagebam.com/3271/cd21cf32705053.gif (http://www.imagebam.com/image/cd21cf32705053)
colorYUV(levels="tv->pc")
ConvertToRGB32(matrix="PC.709")
ddcc(chr_i=3,gam_i=5,ofile="C:\HC3100.txt",threads=4,opt=1)
then I created a LUT with
ddcc(chr_i=3,gam_i=5,ofile="C:\HC3100.txt",lutfile="Z:\lut.txt",threads=4,opt=1)
then played it w/ :
colorYUV(levels="tv->pc")
ConvertToRGB32(matrix="PC.709")
rgb3dlut(lutfile="z:\lut.txt",threads=4)
and I get this :
http://thumbnails17.imagebam.com/3271/ac56e332705058.gif (http://www.imagebam.com/image/ac56e332705058)
so maybe I'm doing something really wrong...or rgb3dlut is mixing YUY2 and RGB LUT's, or well I dunno...I'm off to watch a movie w/ ddcc in realtime in HR is what I know :D
I'm getting the same sort of completely burned up green w/ yesgrey's app/t3dlut, considering they're using the same code..
leeperry
14th April 2009, 22:59
I used to own a Samsung monitor that teared on everything - video games, movies, even the Windows desktop. The only way I fixed it was to fire up a tearing test, load Powerstrip and mess with the refresh rate at hundreths of a hertz. Eventually I found that tearing went away when I changed the refresh rate from ~59.9hz to ~59.8hz. Weird, huh?
hah, I don't have ANY experience w/ LCD screens..can't comment on this, I was mostly talking about tearing created by the graphic card itself(and I tried several generations of ati/nvidia on many different mobos)
DX can't measure the refresh rate accurately, so maybe it was only meant to work at 59.940000....but DX couldn't measure it accurately enough :rolleyes:
Kazuya's Sanyo Z4 stutters w/ 50.000 in Reclock, but works fine if he uses pstrip's search engine to find the perfect "theoritical" 50.000000000Hz(that happens to give 50.002 in Reclock :D)...if your display is not multisync AT ALL, I guess that feature in pstrip is unmatched :)
racerxnet
14th April 2009, 23:05
please can anybody post a kind of tutorial to use these video renders ,cause some people like me are newbies ,thx a lot....
eric
Here is my short attempt for a guide for SD DVD playback as the bulk of movies (700+) are this format:
1 Download DVD43 which is a on the fly decrypter similar to anydvd. You will need to rip the protection or MadVR will not start. I tried to add the decrypter pack in external filters but it did not work. http://www.soft82.com/download/windows/dvd43/
2 download MPC-hc: http://www.xvidvideo.ru/content/category/1/1/2/
3 Download FFdshow: http://ffdshow-tryout.sourceforge.net/
4 Download MadVR from this site.
Install DVD 43 so that you can decrypt on the fly as Anydvd does. This is only for SDdvd's and not BL or HDdvd.
Install MPC-HC
Install MadVR and click on install.bat
Install FFdshow: select codecs on the left column and scroll to the bottom. Select Raw video and set to all supported. Scroll up to the mpeg2 setting and select libmpeg2.
Back in the left hand column select Resize and Aspect: check the resize button. Highlight the radio button marked specify horizontal size, no aspect ratio control and resize always. Check the process pixel aspect ratio internally.
Move down to the Overlay/output and check YV12, YUY2, YVYU,UYVY,NV12, select closest matching colorspace,set pixel aspect ratio in output media type.
In RGB conversion select BT601, Input levels standard ( if you are calibrated to 16-235) output : TV/projector.
InMPC_HC uncheck all internal filters. Add FFdshow audio decoder, ffdshow video decoder, mpeg2 splitter, and madVR and set all to prefer. Insert DVD and select the VOB to start the movie. You will get a "Macrovision failure" if you try to start from the "Open disk" bar in MPC-HC.
Hope this helps some newbies and a big thanks to Madishi for this great renderer. :thanks:
MAK
The most important settings are the ones in resize and aspect. If you get no video you have done something wrong.
I hope that madishi can incorporate or explain how to decrypt without other software for SDdvd's. DeCSS has been out for some time and could be added to the code.
noee
14th April 2009, 23:16
If you're going to use FFdshow as your decoder, choose YV12 as the output and ignore the settings for RGB. In addition, I would *not* use FFDshow resize if using madVR. That's really part of the whole point of this renderer.
flanger216
15th April 2009, 00:38
hah, I don't have ANY experience w/ LCD screens..can't comment on this, I was mostly talking about tearing created by the graphic card itself(and I tried several generations of ati/nvidia on many different mobos)
DX can't measure the refresh rate accurately, so maybe it was only meant to work at 59.940000....but DX couldn't measure it accurately enough :rolleyes:
Kazuya's Sanyo Z4 stutters w/ 50.000 in Reclock, but works fine if he uses pstrip's search engine to find the perfect "theoritical" 50.000000000Hz(that happens to give 50.002 in Reclock :D)...if your display is not multisync AT ALL, I guess that feature in pstrip is unmatched :)
Seriously... I nearly leapt for joy when pstrip finally fixed it. But yeah, I agree - probably a rounding error introduced somewhere in the chain, whereas the LCD processor might've needed an exact sync. Of course, I've also come across a few LCD monitors (including Samsung) that actually had bogus EDID info, so they'd provide the graphics adapter with incorrect native refresh-rates :rolleyes:
Blech. Consumers LCD screens are just disasters in motion. Speaking as an HTCP enthusiast, I find them unsatisfactory; speaking as a photographer, I find them loathsome :devil:
leeperry
15th April 2009, 00:52
Seriously... I nearly leapt for joy when pstrip finally fixed it. But yeah, I agree - probably a rounding error introduced somewhere in the chain, whereas the LCD processor might've needed an exact sync. Of course, I've also come across a few LCD monitors (including Samsung) that actually had bogus EDID info, so they'd provide the graphics adapter with incorrect native refresh-rates :rolleyes:
Blech. Consumers LCD screens are just disasters in motion. Speaking as an HTCP enthusiast, I find them unsatisfactory; speaking as a photographer, I find them loathsome :devil:
anything that doesn't support a multiple of 24p is not worth using for a HTPC.
yeah Seb.26 really had to persuade Rik Wang to add this feature, because it asks the GPU about the refresh rate...not windows :devil:
if mastering studios still stick to CRT, there's a very good reason...best CR, multisync, etc etc
bogus EDID was not too hard in my experience, simply had to check "allow unsupported resolutions"...reboot a few times and tada! the Sanyo Z2 EDID says "max res: XGA" so sending 720p is kinda awkward :D
I'll tell tritical know about the LUT issue in ddcc()
yesgrey
15th April 2009, 01:17
PS: ddcc in realtime = PS script...exactly what I want! but when I go LUT it goes really wrong I think :o
leeperry is right. The 3D LUT is giving different results compared with the PS script.
I have already found the cause, and changed cr3dlut to give the same results as the PS script, but I'm still investigating it to see which is the more accurate...
EDIT: This only affects the color gamut correction. So, the majority should be ok with the current version. I will try to release a fix tomorrow...
leeperry
15th April 2009, 01:32
leeperry is right. The 3D LUT is giving different results compared with the PS script.
I have already found the cause, and changed cr3dlut to give the same results as the PS script, but I'm still investigating it to see which is the more accurate...
ok thanks for the confirmation, and the new cr3dlut http://forum-images.hardware.fr/images/perso/mzarella.gif
well I thought you checked the PS script code w/ matlab and stuff? it looks great, and not GREEN...me like http://forum-images.hardware.fr/images/perso/ganellon.gif
racerxnet
15th April 2009, 03:56
May be a Bug:
Unless the movie is ripped with the main audio stream, disc playback includes the directors comments. I have not been able to find a way around this with the original disk yet for SDdvd.
Thanks,
MAK
Snowknight26
15th April 2009, 06:41
Unless the movie is ripped with the main audio stream, disc playback includes the directors comments. I have not been able to find a way around this with the original disk yet for SDdvd.
Sounds like a splitter issue.
madshi, I'm not sure if this would be classified as a MPC-HC issue or a madVR issue, but whenever you try to take a screenshot while using madVR (only tested it with the non-special build), an error appears about GetCurrentImage failing with error code 80070057.
ericd
15th April 2009, 07:07
Here is my short attempt for a guide for SD DVD playback as the bulk of movies (700+) are this format:
1 Download DVD43 which is a on the fly decrypter similar to anydvd. You will need to rip the protection or MadVR will not start. I tried to add the decrypter pack in external filters but it did not work. http://www.soft82.com/download/windows/dvd43/
2 download MPC-hc: http://www.xvidvideo.ru/content/category/1/1/2/
3 Download FFdshow: http://ffdshow-tryout.sourceforge.net/
4 Download MadVR from this site.
Install DVD 43 so that you can decrypt on the fly as Anydvd does. This is only for SDdvd's and not BL or HDdvd.
Install MPC-HC
Install MadVR and click on install.bat
Install FFdshow: select codecs on the left column and scroll to the bottom. Select Raw video and set to all supported. Scroll up to the mpeg2 setting and select libmpeg2.
Back in the left hand column select Resize and Aspect: check the resize button. Highlight the radio button marked specify horizontal size, no aspect ratio control and resize always. Check the process pixel aspect ratio internally.
Move down to the Overlay/output and check YV12, YUY2, YVYU,UYVY,NV12, select closest matching colorspace,set pixel aspect ratio in output media type.
In RGB conversion select BT601, Input levels standard ( if you are calibrated to 16-235) output : TV/projector.
InMPC_HC uncheck all internal filters. Add FFdshow audio decoder, ffdshow video decoder, mpeg2 splitter, and madVR and set all to prefer. Insert DVD and select the VOB to start the movie. You will get a "Macrovision failure" if you try to start from the "Open disk" bar in MPC-HC.
Hope this helps some newbies and a big thanks to Madishi for this great renderer. :thanks:
MAK
The most important settings are the ones in resize and aspect. If you get no video you have done something wrong.
I hope that madishi can incorporate or explain how to decrypt without other software for SDdvd's. DeCSS has been out for some time and could be added to the code.
thank you very much sir :D
chros
15th April 2009, 09:03
Already on the to do list.
Thanks, we're waiting for this ... :)
Bugfix request: multiple monitor support ...
Thank you for your work ...!
ericgur
15th April 2009, 09:33
Hi madshi,
I was wondering why you chose to use 3D LUTs for CSC and gamma correction.
Performing CSC using 3D LUTs is a major overkill and should be significantly faster by performing the calculations in a shader.
A simple CSC (YCbCr BT601/709 to R'G'B') involves 7 multiplications, 5 additions/subtractions and a 3 clip/saturate operations. These do not involve expensive random memory reads that are performed in large 3D LUTs where the GPU caches are almost useless.
R'G'B' gamma corrections can be performed by 3 1D LUTs (one for each color component) and performed by a shader only when requested (most users will probably not use it as the display pipeline should be calibrated to do this in first place via an ICC profile).
3D LUTs are normally used for complex Gamut correction (mostly for printing purposes) and are (almost) never used in professional video processing HW.
Using 3 1D LUTs for RGB gamma correction gives the following advantages:
* Use less GPU resources - tables should be small enough to fit in the GPU caches (3x16bitx16bit or 3x10bitx16bit or 3x10bitx8bit).
* GPU memory traffic is reduced.
* Real time manipulation of LUTs (with GUI).
* Quick load time - very important when viewing several video files sequentially.
Writing shaders for CSC will also allow adding features like contract brightness, saturation and hue modifications with a small complication to the shader code - perform full 3x3 matrix multiplication (9 multiplications, 12 additions, 3 clips). All of these can be easily modified in realtime.
tetsuo55
15th April 2009, 09:44
Hi madshi,
I was wondering why you chose to use 3D LUTs for CSC and gamma correction.
Performing CSC using 3D LUTs is a major overkill and should be significantly faster by performing the calculations in a shader.
A simple CSC (YCbCr BT601/709 to R'G'B') involves 7 multiplications, 5 additions/subtractions and a 3 clip/saturate operations. These do not involve expensive random memory reads that are performed in large 3D LUTs where the GPU caches are almost useless.
R'G'B' gamma corrections can be performed by 3 1D LUTs (one for each color component) and performed by a shader only when requested (most users will probably not use it as the display pipeline should be calibrated to do this in first place via an ICC profile).
3D LUTs are normally used for complex Gamut correction (mostly for printing purposes) and are (almost) never used in professional video processing HW.
Using 3 1D LUTs for RGB gamma correction gives the following advantages:
* Use less GPU resources - tables should be small enough to fit in the GPU caches (3x16bitx16bit or 3x10bitx16bit or 3x10bitx8bit).
* GPU memory traffic is reduced.
* Real time manipulation of LUTs (with GUI).
* Quick load time - very important when viewing several video files sequentially.
Writing shaders for CSC will also allow adding features like contract brightness, saturation and hue modifications with a small complication to the shader code - perform full 3x3 matrix multiplication (9 multiplications, 12 additions, 3 clips). All of these can be easily modified in realtime.
Would the conversion still be 64bit float?
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.