PDA

View Full Version : What Renderer to use with Reclock?


jmone
11th September 2008, 22:32
Following from some discussion in the Reclock threat, what is the advantages / disadvantages of the various Video Renderers as I can choose on my Vista 32 Bit SP1 System:

Legacy
VMR7
VMR9
VMR9 Renderless Mode
EVR
Haali


Thanks
Nathan

Plug
13th September 2008, 14:15
i would also like to know what the best render is to use with reclock

and also what to use to change the default renderer that im useing..

lych
14th September 2008, 02:15
The following is taken from Inmatrix Media Solutions (http://www.inmatrix.com/zplayer/highlights/vidrender.shtml)

The Overlay Mixer Renderer:
Still using the Video Overlay technology, this renderer allows access to Hardware Color Controls (Hue/Saturation/Brightness/Contrast/Gamma) to cards that support color controls in hardware. Some cards may support only a subset of the color control features (only Brightness for example). This renderer also support proper Aspect Ratio controls for formats that require it (VCD/SVCD/DVD/Etc...).

The downside to this renderer is that it can't fall back to Pure-CPU. If the Video Overlay is inaccessible, it just won't work. In Media Mode Zoom Player will fall back to the Standard Overlay Renderer if this is the case. In DVD Mode, you'll get an error saying that the Video Decoder is unable to connect to the Overlay Mixer.

Lastly, this rendering technology is not very good at screen captures.


The Video Mixing Renderer 7 (VMR7)
This renderer is a hybrid of the Video Overlay technology and the Direct3D technology. It is only available on Windows XP and has been superseded by the VMR9. This is the rendering technology used by the Microsoft Media Player versions 7-10.

By default this rendering technology uses the Video Overlay. However, if it is inaccessible, it can use Direct3D to some degree.

The downside to this renderer is that it doesn't give access to Color Controls and it's not very good at screen captures.


The Video Mixing Renderer 9 (VMR9)
This is the latest technology in Video Rendering. It's completely based on Direct3D, requires DirectX-9 and recent hardware to operate. It can potentially give the best image quality (depends on the rendering mode and the display card hardware). VMR9 gives access to hardware color controls (if the card supports it) but not to Gamma controls as Microsoft didn't include support for it. VMR9 also has the best Aspect Ratio controls.

VMR9 supports three distinct rendering modes:


VMR9: Windowed
This is the most basic mode. It is available for backward compatibility. It does not give you access to Frame Capturing. One thing about this mode is that there was a bug in Windows XP-SP1 and DirectX-9b which made this mode the only mode in which DVD Menu navigation works. With Windows XP-SP2 and DirectX-9c the DVD Menu navigation bug was fixed.


VMR9: Windowless
This mode is slightly more advanced than the Windowed mode and is the best mode in which to conduct screen captures.


VMR9: Renderless
This is the most complex VMR9 rendering mode. It can work in Direct3D exclusive mode which means the entire machine is set to fullscreen and no background application are allowed access to the video hardware. Under Direct3D Exclusive Mode, less CPU is required to play videos and depending on the resolution of the video, playback may be smoother. The downside is that in Direct3D Exclusive mode, your computer is wholly dedicated to video playback and you won't be able to perform any other tasks.

From the WinHEC2006's PowerPoint

Enhanced video render
New render supersedes OvMixer, VMR(7), and VMR9
Video mixing, output timing scheduling
Many enhancements
Composites to output – non-square pixel, colorspace support
Pluggable mixer and presenters
Pull based
Advanced presenter – synchronized with monitor
Automatically handles output mode
Tear free windowed output, DWM support, fullscreen support
Glitch resilience – MMCSS, deep queuing, timeline mapping
Application integration
EVR available in Media Foundation and DShow
Stand-alone Mixer MFT
Not dependent on DXVA decoding


About the Haali Renderer (http://forum.doom9.org/showthread.php?t=108088):

1. Haali renderer is a DirectShow renderer, i.e. similar to VMR9.

2. Haali renderer by shaders, more accurately PS 2.0 compatible shaders. If your card doesnt' have those -- you can't use the renderer.

3. Haali renderer uses bicubic interpolation for resizing.

4. That resizing is done with shaders, implementation is different to casual mpc shader-based resizing in VMR9 mode.

5. Resizing in haali renderer is supposed to be faster than resizing with shaders in VMR9 mode due to limitations of implementation in the latter.

lych
14th September 2008, 02:22
As for which renderer to use, it is really up to you. There is no best renderer for all situations. However, here are some general guidelines. If speed is important, select the overlay mixer as it is the fastest. For general use, select one of the VMR9 options (either windowless or renderless). Personally, I like EVR because the image seems to be slightly sharper to my eyes while using it and it is less prone to tearing. I generally recommond against Haali's renderer because it doesn't work well with DVDs (macrovision failed errors).

Mark_A_W
15th September 2008, 05:20
I like Haali Renderer.

It's the only one which allows me to retain video levels 16-235.

And it has control over the colourspace, and respects the desktop Gamma control (I actually run a custom gamma curve with an app called VideoEqualizer).

Doesn't tear like EVR either.

Plug
15th September 2008, 10:24
I like Haali Renderer.

It's the only one which allows me to retain video levels 16-235.

And it has control over the colourspace, and respects the desktop Gamma control (I actually run a custom gamma curve with an app called VideoEqualizer).

Doesn't tear like EVR either.

what program do you use to enable or disable what renderer to use

currently reclock says im useing EVR but i wanted to try out the hali renderer

how do i select what to use as default

ashlar
15th September 2008, 11:26
what program do you use to enable or disable what renderer to use

currently reclock says im useing EVR but i wanted to try out the hali renderer

how do i select what to use as defaultWhat video player are you using?

Plug
15th September 2008, 13:14
What video player are you using?

WMP11 Vista X64 and PowerDVD 8 Ultra

Mark_A_W
15th September 2008, 17:23
What video player are you using?

Zoomplayer or MPC HC.

ashlar
16th September 2008, 03:26
WMP11 Vista X64 and PowerDVD 8 UltraI might be wrong but as far as I know it, you can't change the video renderer in those two products. Maybe you could try working with the merits, but I'm not sure if that's confined to filters or if it works for renderers as well.

You could try media player classic homecinema to have a look at what Haali has to offer.

protovision
17th September 2008, 13:45
I like Haali Renderer.

It's the only one which allows me to retain video levels 16-235.

And it has control over the colourspace, and respects the desktop Gamma control (I actually run a custom gamma curve with an app called VideoEqualizer).

Doesn't tear like EVR either.

Yeah, I like the recent colorspace logic that Haali has for HD:

"Added an automatic colorspace selection option to the renderer, it switches to BT.709 when video width is 1024 or more"

good stuff!

leeperry
17th September 2008, 19:31
yeah I'm the one who asked Haali to add it :D

too bad its 601/709 coeffs are messed up, which renders Haali useless in YUY2.

nevertheless, Haali is great in RGB32 :

http://pix.nofrag.com/a/a/0/56e67296b49323c29c8810d3b02b8tt.jpg (http://pix.nofrag.com/a/a/0/56e67296b49323c29c8810d3b02b8.html)

lych
18th September 2008, 22:07
yeah I'm the one who asked Haali to add it :D

too bad its 601/709 coeffs are messed up, which renders Haali useless in YUY2.

nevertheless, Haali is great in RGB32 :


How do you configure Haali to use RGB32?

Mark_A_W
18th September 2008, 22:16
You do it in the video decoder.

In CoreAVC/FFdshow/Whatever, deselect the boxes in the output section for everything except RGB32. So untick YUY2, YV12, etc.

Then the video decoder does the colourspace conversion instead of the Renderer.

This does take more CPU (I get stutters).

However I can't see the issue leeperry is reporting, it's pretty subtle.

leeperry
19th September 2008, 04:48
I can't see the issue leeperry is reporting, it's pretty subtle.
you're losing native contrast, the conversion gamma is too high and all the coeffs are screwed up :

http://img174.imageshack.us/img174/3989/comparohrffbx9.png

Mark_A_W
19th September 2008, 07:59
Contrast is huge on a CRT projector with a custom gamma curve (100,000's to 1).

I did some A-Bing with YUY2 vs RGB32 and couldn't see any difference on video material.

leeperry
19th September 2008, 08:27
Contrast is huge on a CRT projector with a custom gamma curve (100,000's to 1).

I did some A-Bing with YUY2 vs RGB32 and couldn't see any difference on video material.
I only use CRT and DLP.
well killing native contrast is never a good idea.
besides if the xyz matrix coordinates are false, then your gamut is also messed up.

anyhow, I like to do gamut conversion to recover the original movie colors(SMPTE-C/EBU/HDTV).......so using YUY2 doesn't make any sense for me.

if your display is uncalibrated, YUY2 will look slightly worse than proper RGB32......prolly not worth the extra CPU load ;)

Mark_A_W
19th September 2008, 08:34
I'm A-B'ing RGB32 vs YUY2 right now on my 24" CRT monitor.

Maybe there's a difference, but it's pretty subtle.

Yes, it is calibrated (I own HCFR sensor and my mate has Colorfacts - which we calibrated the HCFR against).

And I have a ski jump custom gamma curve to suit my CRT projector.

I'm not particularly sensitive to colours (judder for me..).

You sure you don't have Ffdshow or CoreAVC expanding when in RGB and leaving the levels alone in RGB32? That's a noticeable difference.

leeperry
19th September 2008, 08:49
You sure you don't have Ffdshow or CoreAVC expanding when in RGB and leaving the levels alone in RGB32? That's a noticeable difference.
lol no, but in real life examples it slightly shows :
http://forum.doom9.org/showpost.php?p=1133980&postcount=1051

one is greener than the other, that looks undersaturated :)

Mark_A_W
19th September 2008, 18:11
Gees, that's subtle.

I can *just* see it when I have those images side by side.

Haali is rounding 1 sample the wrong way? Not perfect, but hardly earth shattering.

lych
20th September 2008, 02:48
After seeing this difference myself, I can see a difference between Haali's YUY2 and RGB32. The difference is extremely subtle however. I wonder if it is possible to write a shader for mpc-hc that corrects this. I know of a thread on doom9 where a similar issue (only yv12 to YUY2) was discussed and a shader was written to correct it (thread link (http://forum.doom9.org/showpost.php?p=1184975&postcount=32)).

lych
20th September 2008, 03:55
I found a shader that might correct this subtle leeperry mentioned. Check this thread out (http://forum.doom9.org/showthread.php?p=1185866#post1185866) for the code.

leeperry
20th September 2008, 05:00
Gees, that's subtle.

I can *just* see it when I have those images side by side.

Haali is rounding 1 sample the wrong way? Not perfect, but hardly earth shattering.

yeah, some poor rounding.

well, I'm colorblind so we don't see colors the same way :D

to me, one looks OK, the other one looks B&W'ish and undersaturated :(

besides it ruins the whole idea of doing gamut conversion afterwards.

PS scripts don't work with Haali (yet).

just like the difference between RGB32HQ in ffdshow, and ConvertToRGB32() in the Avisynth filter of ffdshow.

the later creates 10% larger PNG files, it's a good guess it makes better roundings :

ffd :

http://pix.nofrag.com/a/d/7/3b34018880dbf4f814fde1c1e7afbt.jpg (http://pix.nofrag.com/a/d/7/3b34018880dbf4f814fde1c1e7afb.html)

AVS :

http://pix.nofrag.com/c/a/3/9e6036cb45bef2a19cf2baffa0041t.jpg (http://pix.nofrag.com/c/a/3/9e6036cb45bef2a19cf2baffa0041.html)

Mark_A_W
20th September 2008, 17:40
I can't see any difference between those images last two images.

Your colourblind comment is interesting.

I sit next to a guy at work who can get green and white mixed up (a green traffic light can look almost white to him), but blue is very prominent to him.

leeperry
21st September 2008, 05:06
hehe, I don't have bionic eyes :D

I also don't see a diff between converttorgb32/rgb32hq above.....yet, the PNG size is always 10% bigger with convert which leads me to believe it's more accurate.

there's many levels of colorblindness, some even see almost in B&W.

the army uses colorblind ppl to see camouflages regular ppl can't see.

so we see colors, just differently :D

personally I can't tell the diff between light yellow/light green, violet/navy blue, dark brown/dark green and such.

but getting older, my brain has learned to improve what my eyes can't see :D

I watch my movies on D65/gamut converted displays, and I can tell you they look WAY better this way :

http://pix.nofrag.com/d/1/d/7eac656dad34430f9e88da3532fddtt.jpg (http://pix.nofrag.com/d/1/d/7eac656dad34430f9e88da3532fdd.html)

lych
22nd September 2008, 02:18
PS scripts don't work with Haali (yet).

Doh! I forgot about that.

Well, there is probably a difference between ffdshow rgb and avisynth rgb because ffdshow contains lots of SIMD enhanced code while avisynth is mostly pure c code. SIMD extensions (like sse/mmx/3dnow...) sometimes produce inaccurate/unstable results ([1] (http://forum.doom9.org/showthread.php?p=1042910#post1042910)).

Mark_A_W
25th September 2008, 10:02
I watch my movies on D65/gamut converted displays, and I can tell you they look WAY better this way :

http://pix.nofrag.com/d/1/d/7eac656dad34430f9e88da3532fddtt.jpg (http://pix.nofrag.com/d/1/d/7eac656dad34430f9e88da3532fdd.html)


I see what you have done - you have cropped your gamut inside the SMPTE-C (REC709?) boundary?

How do you overlay the SMPTE-C gamut on your measure gamut?

I've got HFCR open, but can't figure that bit out..

leeperry
25th September 2008, 14:47
I see what you have done - you have cropped your gamut inside the SMPTE-C (REC709?) boundary?

How do you overlay the SMPTE-C gamut on your measure gamut?

I've got HFCR open, but can't figure that bit out..
here's in what order I did this :

-calibrate to D65 with the built-in test patterns within Color.HCFR
-input the xyz coordinates in this PS script :
http://www.avsforum.com/avs-vb/showthread.php?t=912720
-measure the end result with the official test DVD
-open the 2 .chc files, and check "use as reference" in the original file

the PS script is using a 3D lut to make your gamut fit within any reference gamut you'd like(SMPTE-C/EBU/HDTV)

in the same order, they are called REC601/PAL/REC709 in Color.HCFR ;)

Jong
29th September 2008, 06:32
I must be missing soemthing with this whole Haali thing.

I thought I would have another play with Haali, to see how my jitter varied over a prolonged period. I put on a 720p HD mkv TV show and I had to stop after a few minutes. The picture quality upscaling to 1080p was simply horrible. Ghastly aliasing visible clearly on text but also on the picture too.

Below is a comparison. It's just very poor.

What am I doing wrong?! OK I could use ffdshow as I do for SD, but it really should not be needed for 720p.

Mark_A_W
29th September 2008, 06:38
That looks like a deinterlacing issue.

It's doing BOB, instead of something more sophisticated.

It's probably your video decoder is deinterlacing in hardware when you use VMR9, but not with Haali.

1. Don't watch 720p stuff ;)

2. Don't watch video material, just film ;)

Jong
29th September 2008, 06:47
It's a 720p 23.976 H.264 progressive show. But you are right the Cyberlink decoder is using HA for VMR9 and software for Haali so maybe it is a Cyberlink issue. Horrible none the less.

Jong
29th September 2008, 06:50
Just checked and it looks horrible with the MPC video decoder too :confused:

Mark_A_W
29th September 2008, 06:53
Try CoreAVC or Ffdshow as the decoder.

I use Core.

Jong
29th September 2008, 06:54
... and VMR9 using MPC video decoder withOUT DXVA looks fine.

No, it does look like a Haali issue.

Jong
29th September 2008, 06:58
CoreAVC is just the same.

See below.

Jong
29th September 2008, 07:00
...earlier I should have said VMR9 withOUT DXVA looks fine. Post amended.

Jong
29th September 2008, 07:20
.... and using ffdshow to upscale before passing to Haali fixes it.

Yep. This definitely is a Haali resizing problem.

Mark_A_W
29th September 2008, 08:01
I guess it's time to start reading on Doom9.

I either resize DVD (very rare) to 1920x1080 with ffdshow, or watch 1920x1080 HD, so I've never noticed.

Haali is the only Renderer which allows me to retain video levels, rather than expanding to PC levels. VMR9 expands for HD with an ATi card.

leeperry
29th September 2008, 08:08
I must be missing soemthing with this whole Haali thing.

I thought I would have another play with Haali, to see how my jitter varied over a prolonged period. I put on a 720p HD mkv TV show and I had to stop after a few minutes. The picture quality upscaling to 1080p was simply horrible. Ghastly aliasing visible clearly on text but also on the picture too.

Below is a comparison. It's just very poor.

What am I doing wrong?! OK I could use ffdshow as I do for SD, but it really should not be needed for 720p.
it's a bug in the ATI drivers, same occurs with the KMPlayer VMR9/EVR scaler.

they goofed up in the PS coeffs, and don't care about fixing them.

anyway I prefer to upscale with Spline in ffdshow, than with bicubic.

downscaling is done through the Aniso. Filtering.

when you press ALT+O, you get HR's OSD, then you get 2 letters......one is the horizontal resizing, the other vertical

N = no resizing
A = aniso. filtering(downscale)
S = buggy upscaling on the ATI

as long as you don't get any S, you're good to go :)

Haali wrote major parts of VMR9, he knows what he's doing ;)

Jong
29th September 2008, 08:27
it's a bug in the ATI drivers, same occurs with the KMPlayer VMR9/EVR scaler.Well it does not occur with VMR9 in either hardware or software mode with TheaterTek or MPC-HC. So to me that says Haali is just driving the driver wrong. You sure do love Haali. He can do no wrong in your eyes!

Can't speak about KMPlayer.

leeperry
29th September 2008, 08:29
Well it does not occur with VMR9 in either hardware or software mode with TheaterTek or MPC-HC. So to me that says Haali is just driving the driver wrong. You sure do love Haali. He can do no wrong in your eyes!

Can't speak about KMPlayer.
well yeah, Casimir666 fixed it in MPC HC avec I broke his balls for quite a while :D

it's a small world, don't forget ;)

ogo is Casimir666's best friend BTW :D

Jong
29th September 2008, 08:34
All hardware and software these days have right ways and wrong ways of driving them. If MPC-HC "fixed it" then why can't Haali and what about TheaterTek which is basically never updated anymore (hasn't been since Aug'07) yet works fine.

It seems that Haali ought to get off his butt and fix all these issues for you then James will have some time to fix my 60Hz built-in estimator bug ;)

leeperry
29th September 2008, 08:36
All hardware and software these days have right ways and wrong ways of driving them. If MPC-HC "fixed it" then why can't Haali and what about TheaterTek which is basically never updated anymore (hasn't been since Aug'07).

It seems that Haali ought to get off his butt and fix all these issues for you then James will have some time to fix my 60Hz built-in estimator bug ;)
I don't have any issue with HR, besides the man works for m$/corecodec/the FBI and the CIA........he's kinda busy :o

he told me he would add PS gamut conversion someday, but atm I'm using an Avisynth plugin to do it(even if it uses a helluvalot of CPU cycles)....

here's the MPC HC ghost lines fix FIY :
http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=rev&revision=380

I made a bug report to ATI, but it's not like they care :D

Jong
29th September 2008, 08:41
I don't have any issue with Haali.

he told me he would add PS gamut conversion someday, but atm I'm using an Avisynth plugin to do it....

here's the MPC HC ghost lines fix FIY :
http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=rev&revision=380

I made a bug report to ATI, but it's not like they care :DI don't think that is my problem. have you a link to any images? For me it is just horrible aliasing.

And the MPC-HC fix you refer to is in their Pixel Shader resizer right? I am not using that. Just plain VMR9. And it still doesn't explain why TT works fine.

leeperry
29th September 2008, 08:46
I don't think that is my problem. have you a link to any images? For me it is just horrible aliasing.

And the MPC-HC fix you refer to is in their Pixel Shader resizer right? I am not using that. Just plain VMR9.
yes, it is your problem ;)

what does it say under Resizer in your video renderer config ?

set it to any "PS 2.0" scaler on any MPC HC build older than 380, and see for yourself :
http://tirnanog.fate.jp/mirror/Misc%20(not%20by%20celtic_druid)/MPC-Homecinema%20SVN/

depending on the resolution, you either get vertical/horizontal ghost lines or completely interlaced pictures.

different symptoms, same core issue ;)

I dunno what plain VMR9 uses as a scaler, but this is not relevant here I think ?

you tell me about crappy upscale with HR, I tell you it's a bug in the ATI drivers.
it was there in MPC HC when using the PS scaler before I asked Casimir to have a look at it, and it's still there in KMP ;)

Jong
29th September 2008, 08:51
OK. So I guess you are saying that TT may be doing a more dated form of resize, although I cannot say I have noticed. Still, I stick with my point, Haali needs to help you out, as he seems to be the source of the problem.

leeperry
29th September 2008, 08:59
you can compare "Bilinear" and the PS2.0 resizers in MPC HC, and even w/o rescaling at 1:1 "Bilinear" will look a lot less sharp.

same in KMP.

I don't have any blocking problems with HR, so I'm not too sure what you're talking about.

HR is already adressing Reclock jitter errors for as long as 90' in a row.......if Reclock was taking the VSYNC jitter in account when messing w/ the DS graph clock, this would be far more efficient I'll give you that :)

Jong
29th September 2008, 09:07
you can compare "Bilinear" and the PS2.0 resizers in MPC HC, and even w/o rescaling at 1:1 "Bilinear" will look a lot less sharp.

....

I don't have any blocking problems with HR, so I'm not too sure what you're talking about.I guess it is just that with 720p ->1080p it doesn't makes much difference. I just did a direct compare of TT (no resize options) and MPC-HC (bicubic A=-0.75) and I could not spot a difference, although it was only one frame. Hardly thorough!

Don't know what you mean by "blocking". Look at my jpgs above to see the aliasing effect.

edit..OK I get it, you mean any problems blocking you from uisng Haali. But you do have to seek upto/around "20 times" to get a trouble free playback experience and that is WITH Reclock, which whilst it may not be all you want it to be is sure a lot better than not having it. There seems simply no good reason for your problem. Other renderers do not throw a fit so easily, at least when set up with our degree of dedication, although they may once in a blue moon drop a single frame.

Jong
29th September 2008, 09:11
Hey,

Thanks for getting it fixed in MPC-HC anyway :clap::clap:

leeperry
29th September 2008, 09:31
OK I get it, you mean any problems blocking you from uisng Haali. But you do have to seek upto/around "20 times" to get a trouble free playback experience and that is WITH Reclock, which whilst it may not be all you want it to be is sure a lot better than not having it. There seems simply no good reason for your problem. Other renderers do not throw a fit so easily, at least when set up with our degree of dedication, although they may once in a blue moon drop a single frame.

well HR needs to catch the VSYNC properly, I also had to seek several times to catch it properly with MPC HC + EVR.

that's because the video renderer doesn't care for Reclock timings(known issue from what ogo says, it would require a Reclock Video Renderer)

TSR also has the problem with VMR9 I think.

after HR has caught it properly, it needs to enable its jitter correction to fix Reclock's erratic theoritical timings to match the actual frame rate and VSYNC position.

so I'd say HR does the job it's supposed to do on its end, but if Reclock could somehow drift its theoritical timestamps with the real world jitter, I'd be a happy camper :)

and no matter what the moon looks like, you'd NEVER get dropped frames with VMR9/EVR :D

25@24, the jitter is very stable and moves very slowly
23.976@24, the jitter moves constantly and much faster.........do you really believe it's HR's fault ? I really don't think so...

Jong
29th September 2008, 12:14
25@24, the jitter is very stable and moves very slowly
23.976@24, the jitter moves constantly and much faster.........do you really believe it's HR's fault ? I really don't think so...First, I have to say again, why bother! 0.1% speedup?:confused:

Second, what you are saying is "much faster" is still actually very small. Haali ought to be able to cope (like VMR9 D3D ;)).

Anyway we are going in circles now. Let's hope a later beta fixes your problems.

leeperry
29th September 2008, 12:35
Haali ought to be able to cope (like VMR9 D3D ;))
yeah sure, how does it look if you press CTRL+J in D3D VMR9 in MPC HC again ? :D

oh my, jitter is very bad....it never stands still on 23.976 :o

leeperry
28th October 2008, 06:32
Haali's Renderer :

http://thumbnails6.imagebam.com/1686/82253516855196.gif (http://www.imagebam.com/image/82253516855196)

VMR7 :

http://thumbnails6.imagebam.com/1686/82253516855197.gif (http://www.imagebam.com/image/82253516855197)

VMR9 Windowed, YUV mode :

http://thumbnails6.imagebam.com/1686/a536a916855198.gif (http://www.imagebam.com/image/a536a916855198)

VMR9 Windowless, YUV mode :

http://thumbnails6.imagebam.com/1686/a536a916855199.gif (http://www.imagebam.com/image/a536a916855199)

leeperry
28th October 2008, 06:48
VMR9 Windowless(everything unchecked in ZP) :

http://thumbnails10.imagebam.com/1686/82253516856634.gif (http://www.imagebam.com/image/82253516856634)

so Haali/VMR7/VMR9 "non-yuv" are bit-perfect, meaning they don't temper with the picture :policeman:

OTOH on the VMR9 "yuv mode" the picture is less green...and the PNG files are 20% smaller ?!

yes, I used the same BT709 colorspace.

and the VMR9 Windowless presenter in ZP is SOOOOOO stable w/ Reclock, the VSYNC simply NEVER moves...even after 2H in a row!

http://pix.nofrag.com/e/d/a/59de904d2dc198374454e3410745ctt.jpg (http://pix.nofrag.com/e/d/a/59de904d2dc198374454e3410745c.html)

http://pix.nofrag.com/5/1/e/1dab46bc35f222cab65cbc8500598tt.jpg (http://pix.nofrag.com/5/1/e/1dab46bc35f222cab65cbc8500598.html)

Mark_A_W
29th October 2008, 18:14
Hi Lee

I'm back from holidays, and I've just had a play with the Renderers too.

I seem to get the best results with VMR7.

I'm watching BD/HD-DVD converted to MKV files at 1920 x 1080p (can't even get Powerdvd to play on this PC, despite full HDCP compliance...grr so I have to convert them), on a Q6600 at stock speed (for now, but it's not a toy as is).

I prefer to watch video at video levels, not expanded to PC levels = this affects my results strongly. Also I don't need colour controls, and would prefer they weren't there = less to mess up.

I'm watching on a 24" CRT monitor for testing, and a CRT projector for real, at 1920x1080i at 95.904hz, via a ATi HD2600XT on XP SP3.

Overlay Mixer/Standard Overlay = black screen or freeze. No loss there.

Haali Renderer = unstable Vsync. Occasional judder, does not seem to matter whether ffdshow or Haali does the RGB conversion, but the Tearing test shows some tearing if ffdshow does the RGB conversion.

VMR9 Windowless or Windowed= If ffdshow does the RGB conversion then I run out of CPU and it stutters. If VMR9 does the RGB conversion then playback is perfect, with stable V-sync....but the levels get expanded (ATi card). I don't like the lack of levels expansion controls or lack of colourspace controls either - you are at the mercy of the ATi drivers.

VMR7 = Works fine with ffdshow doing the RGB conversion, so my levels are preserved. V-sync is rock solid. Don't seem to get any judders like Haali, and ffdshow can do the RGB conversion, unlike VMR9 Windowless or Windowed.


I'm pretty happy with VMR7. I'm not sure if it's worth playing with Vista? How did Vista go for you?

Now I'm playing with the ffdshow Queue :)

leeperry
29th October 2008, 20:20
hey Mark ;)

good point! I completely forgot about the ffdshow queue :eek:

now that I'm a good boy and use regular renderers I can give it a shot!

I think you can force the levels type through the reg ?
but anyway the ATI drivers make very poor chroma upsampling, I think I posted a comparison link on the previous page of this thread.

basically you get terribly blocky reds, except if you use Leak's PS script in MPC or KMP

I personally tried to output 16-235 from ffdshow, and set my HC3100 pj to TV range....but the reason why everyone uses HTPC's is mostly coz they do a much better job than onboard cheapo ASIC's.

It was pretty clear that the pj was internally working in PC range, and did a terrible conversion at that.

at least w/ ffdshow(or better SmoothLevels()), it looks much better on most digital pj's

yeah VMR7 in ZP6 is good, but its presenter doesn't look as stable as its VMR9 Windowed/Windowless counterparts

plus, if you enable the VSYNC indicator in Reclock it's always in the visible picture on a 2.35 movie....but in VMR7 it usually sits on top of the 16/9 frame, so you can't see it in 2.35 movies....hence you can't know whether you caught it properly..

so what player do you use ?

anyhow yesterday I played several movies w/ b20 and the VSYNC indicator stood completely still for all the movies.

today, I've been messing around w/ a few things and it started moving a lot after 60'

I dunno if I got lucky yesterday, or if I messed some things up today....but anyhow I'll play around with the Queue Samples in ffdshow :D
well Vista's good, Aero forces the VSYNC to behave....that's our http://tbn0.google.com/images?q=tbn:uxv0FAh7ddQzoM

Mark_A_W
29th October 2008, 22:25
I use ZP6.


I can't get the queue to work now (I did on my other PC). I get Queued Samples = 0.

I changed the registry setting from 10 to 50, but it didn't help.


It's enabled, it's just not queueing any samples :(

leeperry
30th October 2008, 05:23
I tried yesterday in VMR9 Windowless, it works....but it doesn't seem to help to get the VSYNC stable.

I'll try w/ b14, I've always been lucky w/ this build & HR....

ashlar
30th October 2008, 06:01
I think that a good and clear tutorial on how to use the vsync correction for VMR7 and under would be really appreciated.

Whereas Haali, VMR9 and EVR have built-in vsync correction mechanisms, VMR7 lacks it but the explanation in the Readme has never cut it (for me, at least).

leeperry
30th October 2008, 06:48
you guys tried yesgrey's ICL10 resampler ?
http://forum.slysoft.com/showthread.php?t=21879

I think that's what kills my VSYNC stability...gonna run more tests.

I already had this feeling w/ HR

OK I'm trying b20 w/ VMR9 Windowed@48Hz and ffdshow queue(which is MT btw) set to 12 frames.

http://pix.nofrag.com/8/f/d/fc1159c32c4f4485c955f80700dactt.jpg (http://pix.nofrag.com/8/f/d/fc1159c32c4f4485c955f80700dac.html)

leeperry
30th October 2008, 09:01
I think both yesgrey's resampler and a modded version of an avisynth plugin I use were killing the VSYNC stability(jitter)

everything looks cool now in VMR9 Windowed with 12 queue samples.

gonna let it run for 2H, I'll see how it goes when I come back :D

leeperry
30th October 2008, 14:22
ok I've run a few tests, they all went fine!

I don't really mind to have that static white VSYNC dash when I watch movies(on a 2 meters wide screen :D ), so I'll leave it on this evening :policeman:

leeperry
31st October 2008, 00:39
at some point in the past, I spent several weeks using custom EVR in MPC HC.

after going back to HR, I had the feeling as if there were more fps....in comparison HR was like if Trimension DNM were enabled :eek:

Kazuya just told me the same thing after I tipped him on ZP6, and he's right.

besides VMR9 in ZP6 on XP seems to work perfectly on 16/9 movies, but craps out once in a while on 2.35

and I've watched a movie with HR on Vista, it was butter smooth!

now all I need is getting the damn ZP6 working on Vista, it says "invalid floating point" when I connect it to Reclock atm.

starman said he got it working :bang:

Mark_A_W
5th November 2008, 03:20
I've dual booted Vista on my PC, and I have no trouble with ZP6 and reclock. I disabled UAC and installed ZP6 in Legacy mode.

But I can't get Powerstrip to work (it thinks it's working, but nothing happens).



Back on XP, for some reason VMR9 is now working with the decoder outputting RGB32, and it's just smooth as silk. I watched all of a Harry Potter the other night and didn't see a single judder/jump/jitter.

So I'm pretty happy with XP now. Not certain I'll persist with Vista, as my soundcard drivers don't allow the fancy Audio stuff (like room correction). Will see how I go, I'd like to fix the Powerstrip issue and give it a proper go.

But for now:

-Reclock with Vsync enabled.
-VMR9 Windowless
-ffdshow or CoreAVC restricted to RGB32 output, with levels set to 16-235.

leeperry
5th November 2008, 05:07
well watch a few movies, and at the end enable Reclock's VSYNC indicator ;)

I had it stable for a little while, then it started to randomly crap out.

and after a while, switch to HR for a change....if your display is "nervous" enough you too should find that it's way smoother than anything else on PC :)

but if you don't use pstrip, then you don't have perfect refresh rates in reclock ?

Mark_A_W
5th November 2008, 05:24
I can't get Powerstrip working on the Vista boot. On XP it works fine. Until I get this sorted, Vista is a no go for me.

But on XP, Haali Renderer has jumps and judders on occasion for me. VMR9 doesn't.



And what do you mean by "2.35:1" movies? BD/HD-DVDs are all encoded 1920x1080 square pixels, with black bars for 2.35:1 movies. The black bars are just black bars. Or do you mean you re-encode to 1920x802? Why bother?

leeperry
5th November 2008, 05:30
well even with your funky 95.904Hz, HR should be smooth.

it's smooth for me at 89.91 :D

you still need to check that HR's jitter figure in its OSD is <8ms, but at least there's no need to run Reclock's tearing test to see if you caught the VSYNC properly.

well I happen to have several 2.35 mkv movies :p

Mark_A_W
5th November 2008, 05:46
Haali has never been smooth enough.

It's taken a long while to eliminate all the issues (massive CPU overkill helps), and HR judders.

You can see it in the Tearing Test. HR is jumpy compared to VMR9.

I wanted to preserve my 16-235 levels, so on my old PC I had to use Haali Renderer as I didn't have the grunt to do the RGB conversion in the decoder.

Now I have enough grunt, and I was able to pinpoint the issue with HR.


How do you get the jitter down? With an interlaced res it sits at 15-16ms, and with a progressive res it sits around 5-8ms. But the tearing test jumps and the Vsync rolls.

VMR9 just seems to work.

Why are you running 90hz? Ick!!

leeperry
5th November 2008, 05:59
maybe I'm mistaking...ain't u the guy with the CRT pj ?

I run 48Hz w/ Reclock, tearing test is smoother than VMR9.

in VMR9 on XP(or HR on Vista) I have to run the tearing test a few secs before watching each video, to make sure that I caught it properly...very annoying :disagree:

in HR on XP, I seek a few times to make sure that I got <8ms jitter and I'm good to go.

Mark_A_W
5th November 2008, 07:15
maybe I'm mistaking...ain't u the guy with the CRT pj ?

I run 48Hz w/ Reclock, tearing test is smoother than VMR9.

in VMR9 on XP(or HR on Vista) I have to run the tearing test a few secs before watching each video, to make sure that I caught it properly...very annoying :disagree:

in HR on XP, I seek a few times to make sure that I got <8ms jitter and I'm good to go.

Yes, I have a CRT projector, that's me.

I just watched a full 16:9 frame BD...back to VMR7 for me.

VMR9 tears if I do the RGB conversion in the decoder. I didn't notice it before, as I watched a 2.35:1 film with black bars.


For me Haali jumps around in the tearing test. And the jitter in HR moves up and down. There's no way to keep it constantly below 8, it moves. Down to 2, up to 10.

I think the Haali V-sync thing fights reclock.

leeperry
5th November 2008, 07:35
enabling VSYNC correction in Reclock is begging for problems from my experience.

ogo said that it only worked w/ Overlay(and maybe VMR7?)

I tried to enable it w/ HR, but then it was going completely nuts!

quite frankly, I don't think the VMR renderers are fundamentally bad guys....it's just that noone coded a presenter that's good enough to be used w/ Reclock.

like ZP's HR presenter, which is not as stable as MPC/KMP's(Haali did some code in MPC & KMP stole it).

at least HR has built-in jitter correction, which counter-balances VSYNC hiccups with its video frame cache(in the graphic card's RAM).