Haali Renderer

[leeperry]

good point but I'm not sure that would show up in screenshots.

anyway 16X AF suffers from very slight judder with 1080p content, and 8X AF is fine....so 8X that is :D

[foxyshadis]

There's no difference between a screenshot and the playing video (outside of overlay renderer). o.O What's on the screen is on the screen either way. An LCD's refresh rate is the only thing I can see having an effect on that, but that'll be uniformly negative and only serve to cover up any differences that might exist.

[leeperry]

well yeah, anyway I'd love to get a reply from Haali on this one, to know if there's any sense at all to force 8X AF when AF resizing takes place :D

[iron2000]

What is the effect of the buffer and frame sliders?
The higher the better?

I get lines in the video if I let Haali Renderer upscale the video, is it some video card problem?
Same thing happens with VMR9 on PS2.0 methods.
So I'm using ffdshow to resize.

[Yong]

What is the effect of the buffer and frame sliders?
The higher the better?

I get lines in the video if I let Haali Renderer upscale the video, is it some video card problem?
Same thing happens with VMR9 on PS2.0 methods.
So I'm using ffdshow to resize.
are u using ati video card? ;)
iirc nvidia doesnt have this kind of problem.

[iron2000]

Yup, using an ATI card.
So thats the problem.

[Yong]

let ffdshow handle resize might help to eliminate the lines problem, resize to higher resolution is better.

the buffer and frame slider are somekind of frame queuing like ffdshow?
i think higher value only helps if your are playing high resolution video.

[iron2000]

Maybe there should be some guides written to help promote Haali Renderer and to make it easier to use and tweak.

Like the guides at the ffdshow-tryout page.

[kutjong]

I would love to see hotkeys for changing between TV and PC levels on-the-fly and also for BT.601 and BT.709, since I'm constantly changing these depending if I'm viewing HD or SD material.

Anybody else agree?

BTW, I'm also quite interested in tweaking those buffer and frames settings. I believe those can make big difference when playing back HD material.

[Kado]

There isn't much to configure in the renderer settings anyway.
Let's see:
The "buffers" slider adjusts the amount of video memory reserved for the renderer to save video frames.
The "frames" slider limits the number of frames to be saved on the reserved video memory, the number of frames saved will depend on the amount of the reserved memory, will also depend on the video resolution and color space used (RGB32 will consume more memory than YUV2 and so less frames will fit on the same amount of memory, higher resolution video will consume more memory as well).
The "sharpness" slider will set the sharpness for the resized videos being -1 the most sharp possible.
The "YUV colorspace" can be selected to give more accurate color reproduction being "BT.601" for standard resolution material and "BT.709" more used for High Definition material (this may not be accurate).

I suppose the rest is self-explanatory.

You can think of the "Buffers / Frame" system as the queue system used in ffdshow try-outs for VMR9, and if you see a lot of HD stuff use some high values on those two sliders.

In my system I generally use 128MB for the buffers, 120 frames, -0.75 for sharpness, BT.709 and TV range, I have 256MB of video memory.

Hope this helps someone.

[kutjong]

Thanks for the enlightenment, Kado. I think I will use the same settings as you since it works really well on my setup, too.

Does anybody know what the point of having ffdshow converting YV12/YUY2 to RGB32 before rendering? I suppose it just simply does a TV->PC conversion (if necessary)? I don't see any benefit in that since Haali renderer can do this in hardware much faster. Yet I see many people doing this...
With VMR9 it's different though, since it ouputs in the default luma range (or is it always TV range?), then a RGB32 conversion would be nice, but if I understand correctly ATI and Nvidia cards do this by default in hardware when using VMR9 but this also depends on driver version (in some it's enabled, in some disabled??). What a mess!

Anyway, I don't like the TV->PC conversion very much since it isn't quite lossless if I've understood correctly (some luma data is lost), so I always just output in the TV luma range and adjust my display so that black=black, this way no luma data is lost, I think. This solution looks better anyway, IMO.
There's downsides for this though, video that is encoded with PC levels will look darker than they're supposed to, but I don't consider this as a big problem, because not much PC level video exist. One's desktop and web browsing will in addition have too dark luma (light black/grey will be black and black will be "blacker" than black). That doesn't bother me at all though, since I only watch movies on my HTPC.

It's a shame though that there's no application that will tell one if a video file is encoded in BT.601 or BT.709. I know DGIndex can do this for MPEG but I don't think there is one for DivX, XviD, x264 etc... I mostly have to resort to my eyes for choosing the right color range and I think I'm getting quite good at it, but it still bothers me a little that I have to check for conversion color errors when watching new material. This is also a reason why I think that hotkeys for changing color/luma range would be a good idea.

[Kado]

Does anybody know what the point of having ffdshow converting YV12/YUY2 to RGB32 before rendering?

Some nVidia cards don't provide quality YUV to RGB conversion so you can have ffdshow do that instead, and haruhiko provided additional settings like the TV<=>PC settings and the YUV color setting. So if your CPU can handle both decoding and RGB conversion you should use it. VMR9 outputs properly with RGB because there's nothing to convert.

[Shakey_Jake33]

I assume BT.709 should only really be your default if you primarily view HD content? I've kept Haali at default and it looks fine for me, even on my HD footage (which might be encoded for BT.601 anyway).

[kutjong]

Some nVidia cards don't provide quality YUV to RGB conversion so you can have ffdshow do that instead, and haruhiko provided additional settings like the TV<=>PC settings and the YUV color setting. So if your CPU can handle both decoding and RGB conversion you should use it. VMR9 outputs properly with RGB because there's nothing to convert.
So in other words, YV12/YUY2 to RGB conversion in ffdshow is only good with VMR9, right? With Haali, you can just select TV range and it will do the RGB and luma conversion in hardware.

@Shakey_Jake33

Yeah, BT.709 should be your default color range if you primarily watch HD content, altough not all HD material is in BT.709, some may be in BT.601.
It might be hard for you to spot these color conversion errors and it might not even bother you. It certainly didn't bother me before I knew about this issue... Now that I know, it has become a more psychical thing, I guess.


Anyway, this one image helps much in spotting color conversion errors (kudos to leeperry):

http://img138.imageshack.us/img138/7717/barsmatrixqh9.th.jpg (http://img138.imageshack.us/my.php?image=barsmatrixqh9.jpg)

[Shakey_Jake33]

Well, when I set BT.709 and watch SD content, the colour levels are *noticably* incorrect, whereas the HD content I have looks fine in BT.601. Obviously I have no 'reference' to know they are correct, but you can tell when colours are blatently wrong even without seeing what they're supposed to look like. Mind you, in the case of stuff like HDTV rips, they might have been made for BT.601 anyway. I try not to think too much about it, otherwise I become obsessed with 'correct' and I end up suffering sleepless nights!

Looking at Kado's settings, the default Buffers/Frames setting seems awfully low, and has me wondering if I should change to similar!

[kutjong]

Hehe, I think I'm already getting obsessed with this correct video playback stuff. Not having any sleepless nights yet, though. ;)

It's sometimes annoying when you can't play back video the way you would like it. An ideal renderer would IMO be:
Haali's renderer with DXVA 1/2 support, YV12 input support and autodetection of color range. :p
Maybe even resizing in PS 3.0, but I don't know if that would show any improvement.

If Haali would have these features, I think it would be the definite renderer. Anyway. I may be getting way over my head with this stuff, because I don't know squat about software programming/development.

[Kado]

@Shakey_Jake33
Looking at Kado's settings, the default Buffers/Frames setting seems awfully low, and has me wondering if I should change to similar!
If you set them too high you will get no picture or crash the player, they are low as a precaution but tune them as you like.

@kutjong
So in other words, YV12/YUY2 to RGB conversion in ffdshow is only good with VMR9, right? With Haali, you can just select TV range and it will do the RGB and luma conversion in hardware.

Remember that is always the same hardware doing the conversion and you'll get better results from ffdshow converter, the problem with VMR9 was that it always outputted PC levels (I think EVR did it too except for EVR custom), where in Haali you can choose. I recommend ffdshow RGB conversion except if your CPU can't handle both the decoding and conversion and if it drop frames.

What I would like for the renderer to support is subtitles resolution exceeding the 1024x768 resolution from the mpc internal renderer and DXVA.

[kutjong]

@kutjong

Remember that is always the same hardware doing the conversion and you'll get better results from ffdshow converter, the problem with VMR9 was that it always outputted PC levels (I think EVR did it too except for EVR custom), where in Haali you can choose. I recommend ffdshow RGB conversion except if your CPU can't handle both the decoding and conversion and if it drop frames.
So you're saying that ffdshow does RGB conversion in hardware? I thought ffdshow was all about doing everything in software...

Anyway, as I said, I'm not doing TV->PC luma conversion. I simply calibrate my projector so that TV range black looks black, not dark grey. This looks much better than doing a TV->PC conversion, IMO.

[Kado]

No ffdshow do it in software, the renderers do in hardware.

[kutjong]

So... Wouldn't Haali renderer be better for that since it does the YUY2->RGB conversion in hardware?

[Kado]

vmr9, evr do it in hardware as well. there are some nvidia graphics cards that don't give good conversion. the problem with evr and vmr9 is that they output always in pc leves if the input is YV12/YUV2 unless registry tweaked.

[kutjong]

vmr9, evr do it in hardware as well. there are some nvidia graphics cards that don't give good conversion. the problem with evr and vmr9 is that they output always in pc leves if the input is YV12/YUV2 unless registry tweaked.
Yeah, and in some driver releases the registry tweak won't even work...

Man, putting buffer size to 128 mb and frames to 120 has really helped on HD playback. I'm now able to play back x264 1080p material with CoreaAVC with standard deblocking on my laptop. Before this I always had to disable deblocking to play it back properly.

My laptop is btw: Core 2 duo T7200 2 GHz, 7600 Go, 2048 MB RAM, XP etc...

[foxyshadis]

Anyway, I don't like the TV->PC conversion very much since it isn't quite lossless if I've understood correctly (some luma data is lost), so I always just output in the TV luma range and adjust my display so that black=black, this way no luma data is lost, I think. This solution looks better anyway, IMO.

YUV->RGB is the lossy conversion, using TV or PC coefficients doesn't change anything, and it's much simpler than recalibrating your monitor every time you watch something. Of course, TV->PC conversion is lossy if done entirely in the YUV or RGB domain, as well; thus the preference for doing it all in one step.

You should actually get slightly better (less banding) results by performing the conversion, but that's only if your monitor isn't a cheap 6-bit or 7-bit screen.

[iron2000]

Thanks for the explanation and suggestion, Kado.

From what I think I understand, the only differences between Haali's and VMR9 is that its more configurable and has a different way resizing videos.

Putting those two differences aside are there anymore advantages of using Haali's?

[KoD]

Putting those two differences aside are there anymore advantages of using Haali's?
What other advantages would you expect ? Care to elaborate ?

[Yong]

Thanks for the explanation and suggestion, Kado.

From what I think I understand, the only differences between Haali's and VMR9 is that its more configurable and has a different way resizing videos.

Putting those two differences aside are there anymore advantages of using Haali's?

you should read the first page of this thread ;)

[iron2000]

Maybe not advantages but differences.

Read the first page again and the main difference is the way they resize videos so if you take that away they are both the same thing? Then Haali's advantage is that it allows the user to change the buffer and frames values?

[kutjong]

Maybe not advantages but differences.

Read the first page again and the main difference is the way they resize videos so if you take that away they are both the same thing? Then Haali's advantage is that it allows the user to change the buffer and frames values?
Haali also supports options for color range and luma range. VMR9 always outputs in tv range (doesn't convert to PC), this'll make black look like dark grey etc...
Haali's superior resizing is already enough for me to choose it over VMR9, the only thing that Haali lacks is DXVA and YV12 input support.

[Kado]

VMR9 always outputs in tv range (doesn't convert to PC)
Its the other way around, VMR9 uses the the full luma range, i.e. the PC levels.

For the differences although both use shader model 2 and bicubic haali seems more efficient (haali coded both resizing engines), haali can use shader model 1 as well in the latest versions. another point is the advanced configurability and osd for av info. VMR9 sometimes display that one pixel line in the videos haali does not. Since I don't really need DXVA Haali rules! There are some problems with the subs when using haali and mpc internal renderer but that's just me wanting supreme quality, will document later.

[iron2000]

hmm...
The resizing doesn't matter to me as videos will have lines if PS2.0 methods are used, currently using ffdshow to resize.

Is DXVA = hardware acceleration?
How much does the video card play in the case of using Haali's or VMR9, are there any difference?

Is it that if the codec does not do DXVA than it doesn't matter if the renderer supports DXVA or not?

[kutjong]

Its the other way around, VMR9 uses the the full luma range, i.e. the PC levels.

You know what I meant. ;) VMR9 just displays the TV levels in PC levels without doing the actual conversion, I mean.

@iron2000

For DXVA, you need a DXVA compatible decoder, renderer and graphics card. Nvidia calls their DXVA implementation Purevideo and ATI theirs AVIVO.
AFAIK, the only DXVA compatible renderers are VMR9 and EVR. DXVA decoders... Well, I don't think there's any open source decoders that would support it. But commercial e.g purevideo decoder, cyberlink decoder support it. Ffdshow doesn't, FYI.

DXVA simply adds hardware acceleration for video decoding and other advanced features such as noise reduction, motion adaptive deinterlacing etc... You can do all this in software I suppose, but it would probably be way too heavy for a CPU.
DXVA is really helpful when decoding H.264 material.

[Kado]

WMV3/9 supports DVXA for the version 11 of the codec. You can use Zambelli's WMV PowerToy (http://www.citizeninsomniac.com/WMV/) to enable those options. Use VMR9 because it does not seem to work with EVR at least for me (6800GS and Vista x86).

[kutjong]

Yeah... DXVA is also only available for MPEG-2, H.264, WMV and VC-1, I think. No DXVA for MPEG 4-ASP (XviD, DivX), but decoding that doesn't take much on the CPU anyway.

And then there's DXVA 1.0 and 2.0... I'm not quite certain about the differences, but I think 2.0 requires EVR to work and a DX10 capable graphics card? :confused: 1.0 requires VMR9 and DX9, and I believe it's not compatible with EVR.
I also think that 2.0 is the only way to get 100% HW acceleration with H.264.

Anyway, if 2.0 requires DX10 then there's no way to make it work on XP, altough I've heard that Nvidia is working on somehow getting DXVA 2.0 on XP. Can't remember where I read that, though.

Also, is it even possible to implement DXVA 1.0/2.0 into a opensource/personal project? I mean, does it require a license of some sort? Just thinking if it's even possible to implement it in Haali renderer...
I would guess though that Haali doesn't even want it/need it. :p

[iron2000]

Thanks for the answers, I feel enlightened!

[Kado]

I also think that 2.0 is the only way to get 100% HW acceleration with H.264.

The level of acceleration depends on the hardware used, of course only the latest cards (directx10) have full hardware acceleration and they use DXVA 2.0. While the ATI cards have full hardware acceleration the nVidia ones still lack full acceleration for VC-1 encoded streams (even the 8800GT).

With DXVA 1.0 you have limited acceleration for WMV/VC-1,MPEG2 and H.264 (H.264 in XP only) with compatible hardware and for DXVA 2.0 you have full (with the limitations stated before) hardware acceleration for the same formats, with full I mean decoding and post-processing in hardware.

Anyway this tread sure is going off topic with all this DXVA talking...

[mjrweed]

My setup:
Vista
MPC Home Cinema
ffdshow
haali splitter

This might be a stupid question, but here go`s:
When i chose haali`s video render as output, and try to play a 1280x720 file, it seems to resize the image to 640x360(Video properties) when my screen res is 1280x720. Any way to use haali`s video render without the resizing of the video?
(When i switch back to default render in mpc, it plays in 1280x720)

[chros]

This might be a stupid question, but here go`s:
No, it's not !
Haali said that he wants this feature, and we couldn't tell him to include an option for it at least (He doesn't like when some portion of the video is outside of the screen).

So, it's normal (unfortunately), and if it's bothering you (like many of us) just resize the player at double sizes (eg: ALT+3 in MPC), and in this case the renderer doesn't resize at all !!!

[mjrweed]

Thanks for the quick reply chros.

Ive set mpc to go directly into fullscreen when starting a video file. I guess that will have to do :)

[Haali]

A few notes about HR regarding the previous discussion:
1) HR produces predictable results independent of the driver version or settings when doing YUV to RGB conversion.
2) HR does bicubic upscaling using shaders 2.0 and AF downscaling.
3) HR uses shaders 2.0 for deinterlacing, frame doubling is the only available method.

When only shaders 1.x are available HR uses hardware scaling and does only YUV->RGB conversion using shaders, deinterlacing is also not available.

[leeperry]

ok thanks for the clarifications

but why does 16X AF create tearing then ?
no point in forcing 8X AF at all for "AA" content ?

any chance providing support for DXVA ?
Whenever I enable Trimension DNM in the WinDVD6 video decoder I get a lot of tearing.....which doesn't occur in overlay.

and also H264 acceleration from PowerDVD's filter is not working with HR....I believe this one is using DXVA2 ;)

and some hotkey for BT601/709 would be handy, just like some auto-detection would be....if any possible ?!

Thanks for all!!!

[Leak]

but why does 16X AF create tearing then ?
Because it needs more memory bandwidth than 8x AF? If getting an image out will take too long it's too late to wait for VSync, so probably the renderer immediately starts on the next frame - that'd of course cause tearing.

np: Future Sound Of London - Long Shadows (From The Archives Vol. 3)

[Haali]

HR already uses maximum possible AF samples, and enables VSync. Forcing these settings in driver control panel only screws other unsuspecting apps.

[leeperry]

alright, sounds fair enough ;)

I would guess that you would force top-quality AF resizing....but you don't seem to be using 16X AF ?

with 1080p high bitrate movies, I get tearing if I force 16X AF, which I don't with 8X ?!

any chance auto-detecting the colorspace ?
that would be so awesome :D

or at least setting up a hotkey to toggle them.

благодарю Вас ;)

[rijnton]

My setup:
Vista
MPC Home Cinema
ffdshow
haali splitter

This might be a stupid question, but here go`s:
When i chose haali`s video render as output, and try to play a 1280x720 file, it seems to resize the image to 640x360(Video properties) when my screen res is 1280x720. Any way to use haali`s video render without the resizing of the video?
(When i switch back to default render in mpc, it plays in 1280x720)

I see this too and maybe MY question, as a new member of this forum and a noob IS stupid:
Does that mean that without any additional settings and when playing in fullscreen, I only get half of the reolution ?
Or in other words, is 640x360 in fact "blown up" to 1280x720 ?
(I have a HD-ready LCD TV as display and resolution set to 720p fwiw and use HR in MPC)

And may I ask another question: I read Kado's post, a few pages back, about the Buffer and Frame sliders.
Could you give me a recommendation on how to set it ?
I watch a lot of HD material and have 768MB video memory on my 8800GTX. (If of interest, my cpu is a Core2 E6600).
Thanks in advance.
Ton

[Haali]

No, only the initial window size is affected. Using many buffers may help on a slow pc. I think on your setup it won't gain anything.

[Shakey_Jake33]

I see this too and maybe MY question, as a new member of this forum and a noob IS stupid:
Does that mean that without any additional settings and when playing in fullscreen, I only get half of the reolution ?
Or in other words, is 640x360 in fact "blown up" to 1280x720 ?
(I have a HD-ready LCD TV as display and resolution set to 720p fwiw and use HR in MPC)

It only affects Windowed, it's just making it so that when your video is so high a resolution that it overscans the TV (when windowed), it halfs the resolution. Annoyed me at first, but I've become to like it. You can Press Right-Alt+O to see exactly what resizing is going on.

[rijnton]

Thanks for the replies.
May I still ask a few more questions then ?
1) I have my display (tv) calibrated, with DVE, to video levels so that 16 is black.
Is it correct that I have to set Luma Range in HR to PC (o-255) then ? I noticed that when I set it to TV, I cannot make btb visible, even when I increase brightness of tv to max. Set to PC I can see btb. (of course I calibrate then so that 16=black and btb resolves in the background). And should CoreAVC, for H.264, be set to TV output ?
2) What is the best setting in CoreAVC for Output Formats, YUY2 on top or RGB32 ? I noticed that cpu usage with RGB32 is about doubled compared to YUY2, although still rather low (YUY2=around 20% and RGB32=around 40%).
3) I have HR as a component of the CCCP package and apparently it is not the latest version. Can I install the latest version of Haali Media Splitter over it ?
Thanks in advance.
Ton

[kutjong]

1. If you select PC levels in Haali, it will output in PC levels without doing any conversion to PC levels. If you select TV, then it'll do the TV->PC conversion. I keep coreavc on auto, then it won't do any sort of luma range conversion. I let Haali do that.

2. I always output YUY2 to Haali. It does the RGB conversion faster.

[rijnton]

1. If you select PC levels in Haali, it will output in PC levels without doing any conversion to PC levels. If you select TV, then it'll do the TV->PC conversion. I keep coreavc on auto, then it won't do any sort of luma range conversion. I let Haali do that.

Thanks. Just to know if I understand it correctly:
So to keep blacker-than-black and whiter-than-white and then calibrate my tv to that (so 16=reference black) I indeed have to set Haali to PC ?
And when set to TV Haali "clips" 0-15 en 236-255 and expands the 16-235 range to 0-255 ?

[kutjong]

Thanks. Just to know if I understand it correctly:
So to keep blacker-than-black and whiter-than-white and then calibrate my tv to that (so 16=reference black) I indeed have to set Haali to PC ?
And when set to TV Haali "clips" 0-15 en 236-255 and expands the 16-235 range to 0-255 ?
Yes. Consider the luma range options as options for input. E.g if your video material is in TV range, you would normally want to do the TV->PC conversion, then you select TV as "input".
But in your (and my) case, we're getting the correct luma output by calibrating our display, so that means we have to choose PC as "input" so that no conversion is made.