Haali Renderer

[leeperry]

well Haali's relies on the drivers color scheme........which doesn't seem to compete with ffdshow RGB32.......I think it's far from being OT

[wozio]

well Haali's relies on the drivers color scheme........
From where did you get that? Only VMR9 with yuv input uses driver's routine to convert to rgb. Both ffdshow and haali renderer are independent on drivers.

[leeperry]

well on your pictures the worst color-wise is with HR

and I believe it's using the videocard PS 2.0 to convert from YUY2 to RGB32......

even if HR somehow drives the conversion, it could obviously be improved....

but Haali doesn't seem to follow this thread :D

[wozio]

and I believe it's using the videocard PS 2.0 to convert from YUY2 to RGB32......

even if HR somehow drives the conversion, it could obviously be improved....
Yes HR uses pixel shaders to color convert but code for this shaders were written by haali, this is exactly the same what ffdshow is doing but in the GPU not in CPU, so it is not driver nor card dependent. On nvidia you will get the same results as on ati or intel or matrox or whatever card hr may be run on.

[Haali]

There is nothing to be improved. HR does YUV->RGB conversion using shader programs according to BT.601 matrix, and is not affected by driver defaults. TV levels scale (16..235) is always used, since this format is found most ofthen on DVDs and in reencoded files. Using colorspace conversion in ffdshow should achieve the same results, and is not needed if you are using HR.

[leeperry]

well..........how come the shots from FFD and HR don't look the same then ? HR looks washed out in comparison....

and anyone knows why the last line of the image is green when using HR ?
problem doesn't occur with VMR, and doesn't show up in screenshots......so this is a renderer issue.

Thanks ;)

[3ngel]

There is nothing to be improved. HR does YUV->RGB conversion using shader programs according to BT.601 matrix, and is not affected by driver defaults

Haali, first take it easy when you have critics, and in my opinion (granted your render is a pioneristic work) i think you have to listen more closely to what users say, not putting yourself in the position "hey it's my work and so you follow what i do". Yes it's your work and you do what you want, but who is that uses the renderer? The users. Who make it better and better? The user. So i think that at last some "work" is done by the users and their words have some weight.

TV levels scale (16..235) is always used, since this format is found most ofthen on DVDs and in reencoded files. Using colorspace conversion in ffdshow should achieve the same results, and is not needed if you are using HR.
I have serious things to say on this 'cause on DVD the TV scale is used because they are supposed to be seen on TV ("TV scale" don't you see similarity?).
In our case we use it on PC and so at last the first thing to do is to do a conversion on PC Scale.
Moreover i think the chain vojage from avi->monitor is not so simple, so every render (included yours) has to take into account different situations (like the screenshots posted), and not simply ignoring them basing on "technical theories" (like that the renderer uses PS and so every situation is always fine).

[Haali]

Let me rephrase, HR always assumes its input is using TV levels, and scales that to full range before converting to RGB. This is consistent with the behavior of YUV overlays, and most sources. There was some confusion when using VMRs, because sometimes they were using PC levels, but I've heard the defaults are changed back to TV levels in recent graphics drivers by ATI and Nvidia.

One of the reasons I've written this piece of software was a desire to have stable and consistent colorspace conversion that doesn't depend on driver defaults, while using d3d hardware to have better scaling.

This unfortunate situation is partially Microsoft's fault, because they didn't provide a standard way for the decoder to signal what YUV variant it was using. Driver writers also helped by using different conversions in d3d and YUV overlays.

[leeperry]

ok thanks for the infos Haali and this awesome piece of software ;)

but how come the FFDShow RGB32 HQ conversion looks more colorful than yours using YUY2......if it's using the same matrix conversion ?

and what's the big fuss all about to enable the user to toggle the TV>PC conversion ?

I've just watched TROY using HR in YUY2 on my beamer, I didn't find the colors washed out at all........and actually a lot better looking than VMR9/RGB32HQ.......I'm sold, where do I sign :D

[3ngel]

a desire to have stable and consistent colorspace conversion that doesn't depend on driver defaults, while using d3d hardware to have better scaling.
That's a good starting point and a good principle, BUT the error for me lies in the fact that you use d3d to perform operations like scaling, in this way you call yourself the total chaos because all your hard to make the video chain consistent simply VANISHES when you call the hardware dependent functions. This because at this point you have ABSOLUTELY NO CONTROL anymore.
In other words after the scaling phase you can have on the video anything the hardware like. And this is exactly what it happens with so many posts concerning jagging, whasing out and anything else. This because the hardware functions can be implemented by the hardware in a correct or non correct way. They can change anything (including altering the so precious colors), and you have this demonstration with different colors on different cards, and on different drivers too!

THE SOLUTION.
Make an option to do EVERYTHING CPU and just send dumbly RGB32 (not even RGB24 'cause alignment reasons) to the GPU.
It will be a CPU intensive renderer, it will be not for anyone but you can be mathematically sure you'll have THE BEST, THE SAME QUALITY on any PC, on any card, anywhere.

But unfortunately you've shown you're against any option that modifies your "views of the things" so i have not so much hope you can consider it.

[leeperry]

hey 3ngel you sound quite upset :D

I'm willing to give up some color wash up for supreme smoothness and GPU acceleration anytime ;)

if I do the conversion with ffdshow in RGB32HQ, I can't upscale to 720p in lanzcos 8 passes while maintaining the "basic" sharpen filter of KMP(this thing turns SD to HD, no kidding!)

[Leak]

That's a good starting point and a good principle, BUT the error for me lies in the fact that you use d3d to perform operations like scaling,
Ugh... Haali's Renderer is all about doing scaling and colorspace conversion on the GPU - what's left if he throws all that out?

To answer that myself: nothing that couldn't be done by using ffdshow and it's YUY->RGB conversion with VMR/Overlay Mixer, so why bother at all then?

np: New Order - True Faith (Singles (Disc 1))

[3ngel]

Pheraps you haven't read well
One of the reasons I've written this piece of software was a desire to have stable and consistent colorspace conversion that doesn't depend on driver defaults
That means that haali intent is to be INDEPENDENT from GPU, (at this moment only on colorspace) not the opposite.
And concerning all the rest, i hate FFdshow, and from what i remember from the first posts of this thread (when haali was all cpu without gpu) the color conversion was better in HR than ffdshow.

[KoD]

I see lots of nonsense from people that don't know much about color spaces and video material, what decoders do, what renderers do and how to properly deinterlace and resize. To this there's the ever present "I'm a consumer, listen to me !" attitude many have with software that is provided freely for their use. Please stop. If you really want to know what to do, start reading instead of making theories on how it works and how it should work. If you want a good book on this topic, there's Charles Poynton's Digital Video and HDTV Algorithms and interfaces (Morgan Kaufmann).

Haali, it looks like HDTV (broadcasts and HD DVD and Bluray authored discs) are using BT.709 instead of 601 for color conversion. Furthermore, BT.709 is being pushed to be used in authoring SD TV and DVD video material too. Would you add this new mode as well ? Maybe giving the user an option list in the filter configure panel, with:
- always use 601 color matrix
- always use 709 color matrix
- auto (chooses 601 or 709 based on the input material horizontal resolution: if it's 720 or higher, then it assumes HD material and uses 709, if it's lower than 720 then it assumes SD and uses 601)

The option to manually set the renderer to use 601 or 709 is there to allow people to use other resizers (like ffdshow) on SD video to horizontal resolutions higher than 720 and still be abe to use the proper color conversion (601).

[Leak]

That means that haali intent is to be INDEPENDENT from GPU, (at this moment only on colorspace) not the opposite.
He meant independent from any ideas the driver has about (mis-)doing colorspace conversions.

Doing the colorspace conversion as a shader program cuts that out entirely, as pixel shaders simply perform math operations on pixels, not colorspace conversions per se. Thus whatever the driver thinks that a correct colorspace conversion is doesn't even come into play here... and video frames that get uploaded as textures don't get color converted by the driver either.

np: New Order - Waiting For The Sirens' Call (Singles (Disc 2))

[Haali]

Indeed, the image data is uploaded to the video card as RGBA textures even if it's actually YUV, and is converted using shaders.

While driver writers are known to alter shaders to achieve better benchmarks, I don't think it happens here. Also there is a simple way to check conversion results: taking a snapshot in MPC downloads converted image back from video card. You can open that in any editor and check the levels.

As for using BT.709, I'll probably add that in the next release.

[leeperry]

so the colors ain't exactly the same in HR and FFD coz one is using BT.601 and the other one BT.709 ?

indeed my bluray rips don't look as good as my DVD/DVDRip's ;)

[aydc]

I'm trying to solve the blockiness in Haali Renderer that popped up recently and refuses to go away no matter what I do. Every image is blocky, everything looks like I'm watching a 320x240 movie on 1600x1200 with no interpolation.

My question is, could it be caused by the 3d settings in nvidia control panel. I mean, do settings like antialiasing and texture filtering make a difference on what Haali renders?

[Leak]

My question is, could it be caused by the 3d settings in nvidia control panel. I mean, do settings like antialiasing and texture filtering make a difference on what Haali renders?
Well, since the Haali Renderer operates on textures (which would indicate a "yes") you might want to set all 3D options to the highest quality settings and turn off anti-aliasing...

IIRC you can just create a 3D profile for your media player.

But why not simply try this out? :)

np: Richie Hawtin - The Tunnel (DE9 - Transitions)

[leeperry]

I'm trying to solve the blockiness in Haali Renderer that popped up recently and refuses to go away no matter what I do. Every image is blocky, everything looks like I'm watching a 320x240 movie on 1600x1200 with no interpolation.

My question is, could it be caused by the 3d settings in nvidia control panel. I mean, do settings like antialiasing and texture filtering make a difference on what Haali renders?

make sure you use Hi-Q decoders.
it seems to be a problem with RGB24/32 conversion

[Haali]

aydc: Of course, HR is affected just like any other 3d app. In paticular, forcing AA in the drivers control panel is known to cause image corruption, so don't do that, and leave default settings as application controlled.

[aydc]

aydc: Of course, HR is affected just like any other 3d app. In paticular, forcing AA in the drivers control panel is known to cause image corruption, so don't do that, and leave default settings as application controlled.

Last night I had to reinstall Windows, which of course returned everything back to normal. Good news: blockiness is gone. Bad news: I couldn't test if I could solve it by returning to default settings on nvidia control panel. :)

[aydc]

New version out!!

# 28/04/2007

* Fixed items:
o Fixed a regression in PS timestamps calculation.


# 27/04/2007

* New Features:
o Added support for DTS in TS stream type 0x82.
o Added support for more LPCM types in TS.
o Added workaround for some broken TS files.
o Added support for BT.709 color conversion in the renderer.
o Added support for full luma range in the renderer.
o Added workaround for filters that don't send NewSegment to the muxer.
* Fixed Items:
o Use WAVEFORMATEXTENSIBLE for multichannel audio.
o Fixed MPEG-2 in TS/PS parsing.
o Fixed splitter stalling on very high bitrate files.
o Fixed parsing of wrapped PTS in TS/PS.

[leeperry]

w00t, my favorite renderer is just getting better and better, thanks for the heads up!

so should i pick BT.601 or 709 ?!?!!? :confused:

709 is for DVD and HDTV, and 601 for all the rest ?
I'm colorblind :D

Also, XViD from ffdshow looks better in TV range on HR............but CoreAVC(with the "convert Tv scale to PC" unchecked) looks better in PC range :(

so should I check this option in CoreAVC and go with TV range ?!?!!?!?

Thanks!

[leeperry]

from what this page says :
http://forums.creativecow.net/readpost/65/855228

I should stick to BT.709, enable TV>PC in CoreAVC and force PC range in HR ? :)

but it seems that MPEG1/2 decoders output 16-235 :(

[aydc]

709 looks much better to me. To compare, make screenshots of the same frame with Printscreen key and save as BMP. Then view them full screen back to back. 709 gives more vibrant colors on my system.

[KoD]

All those Bt.xxx options matter only when you are feeding Haali's renderer with YUY2 (if you feed it with RGB32, there's no color conversion to be performed).

It's very simple:

• for material that was encoded using BT.709, that is real HDTV tv broadcasts, Blu-Ray and HDDVD, either original or ripped, use BT.709.
• for material that was encoded using BT.601, like normal (not HDTV) TV broadcasts, DVD, or DVD rips, use BT.601. Digital TV broadcasts, even if not HDTV, might use BT.709 though.

All TV, DVD, Blu-Ray, HDDVD, and any encodes from such material you may have done yourself where you have not explicitly converted to PC scale, use TV color range. So you should let "Luma range" to TV(16-235).

Any encode you may have done yourself that used some captured sequence from a game (Quake, Half-life, whatever) or the encode of a render from a 3D modelling application (a render from Maya, 3DStudio, etc.) has a full PC range, so when playing it select "Luma range" PC(0-255).

If I said something wrong, I'm sure someone will correct me. ^^

[ExtraEye]

KoD - thx for the info. but what about if i output the video to a TV?
BTW: I see no difference between 709 and 601.

[KoD]

KoD - thx for the info. but what about if i output the video to a TV?
BTW: I see no difference between 709 and 601.

That "Luma range" setting seems to control wether 16-235 to 0-255 conversion is to be performed or not, like this:
- if "Luma range" is set to TV(16-235), then the renderer will do a conversion: 16-235 input -> 0-255 output, respectively 0-255 input -> 0-255 output but the original 0-16 and 235-255 info in the input is lost
- if "Luma range" is set to PC(0-255), then the renderer will not perform any conversion, so the range that is on input gets on output: 16-235 input -> 16-235 output, respectively 0-255 input -> 0-255 output

Or at least that's how I guess it works. Only Haali knows.

You will probably want to select "Luma range" PC(0-255), so that the renderer will not mess with the input range. Obviously, if what I guessed above is right, then any encode that uses the full 0-255 range will not be viewed properly on your TV screen, as the TV screen expects useful luma information to be contained only in the 16-235 interval.

[Haali]

Remeber, the frame buffer on the video card is RGB, and all these conversions in the renderer apply only to source video when it is placed into framebuffer. The FB is always RGB even if you use TV-out or whatever video output. The video card hw then converts it back to YUV for output if you have a TV connected. So all this talk about TV-out is really pointless unless you know for certain how this RGB->YUV step is implemented. My guess is that you certainly don't need to limit your *RGB* values to 16-235, as the TV encoder on the video card likely assumes normal computer RGB content. But to verify that you'd need a TV Scope to measure actual analog levels.

[leeperry]

709 looks much better to me. To compare, make screenshots of the same frame with Printscreen key and save as BMP. Then view them full screen back to back. 709 gives more vibrant colors on my system.

actually I can't capture 709........it looks like 601 in my captures..

709 makes the colors more vibrant indeed......but somewhat different :devil:

red looks more orange, and green looks darker...

All those Bt.xxx options matter only when you are feeding Haali's renderer with YUY2 (if you feed it with RGB32, there's no color conversion to be performed).

All TV, DVD, Blu-Ray, HDDVD, and any encodes from such material you may have done yourself where you have not explicitly converted to PC scale, use TV color range. So you should let "Luma range" to TV(16-235).

yes i output YUY2 to HR, that's the whole point :D

My guess is that you certainly don't need to limit your *RGB* values to 16-235, as the TV encoder on the video card likely assumes normal computer RGB content.

it seems that avi/mkv output to 0-255 as expected, but mpeg1/2 decorders output to 16-235

if that was possible to switch between 601/709 and TV/PC from the MKV tasktray icon and through hotkeys like CTRL+F2/CTRL+F3, that'd be so awesome :devil:

it takes several clicks to switch it in the HR configuration, and the window comes in the way ;)

anyway, HR is my number one renderer, and more than ever......Haali spacibo ;)

[Haali]

it seems that avi/mkv output to 0-255 as expected, but mpeg1/2 decorders output to 16-235

These figures are quite strange. Are you sure all your mkv/avi use a different luma range? I personally see fullrange content very rarely, if any.

[leeperry]

gee, you're losing me here again :D

I've got several bluray/HD-DVD rips in VC1 that I use for tests, and some XViD too

and when I check 16-235, my movies look too dark, the blacks are burned......

I will run more tests then :D

could you add the 601/709 and TV/PC in the MKV tasktray please ?
and some hotkeys would be awesome too........thanks for all your hard work ;)

[aydc]

actually I can't capture 709........it looks like 601 in my captures..


Don't use player programs' internal frame capture shortcuts. Watch the video full screen and use the PrintScreen key on your keyboard. Then save the image using an image editor like paint. This way you'll capture exactly what you see, so you'll see the difference between the two modes clearly.

By the way, thanks to Haali for listening to user feedback here and giving us these options. Now only if he could add Lanzcos resizing and Brightness/Contrast controls..... :)

[leeperry]

Now only if he could add Lanzcos resizing and Brightness/Contrast controls..... :)

if you upscale in lanzcos in your player(I do it in KMPlayer) or in ffdshow, the internal resize of HR is bypassed.

KMPlayer also enables you to change the brightness/contrasts controls in realtime, but I never use it ;)

concerning 601/709, 709 makes the skin tones much more realistic, less grey-ish ;)

[leeperry]

btw I can't skip in MPEG-PS files if I choose Haali's Splitter........and I dunno if there's any advantage to use it for AVI either ?!

[aydc]

if you upscale in lanzcos in your player(I do it in KMPlayer) or in ffdshow, the internal resize of HR is bypassed.

That depends on CPU however. On a Core2Duo 6600, ffdshow takes 40% CPU power to resize small movies to 1680x1050. Haali uses GPU instead so it would be much more efficient.

[MatMaul]

btw I can't skip in MPEG-PS files if I choose Haali's Splitter........and I dunno if there's any advantage to use it for AVI either ?!
same here.
I select MPEG PS when I install and the splitter don't want to be used with ps file.

[KoD]

How about splitter related issues be reported in the "Alternative Matroska splitter" thread and keep this one only for video renderer issues ? My guess is that the PS and TS splitting is still not complete. Another issue might be that Haali's splitter is not very tolerant with broken ps and ts files.

[leeperry]

That depends on CPU however. On a Core2Duo 6600, ffdshow takes 40% CPU power to resize small movies to 1680x1050. Haali uses GPU instead so it would be much more efficient.

well yes, and no.
I use the "basic" sharpen filter of KMP.
KMP upscales to 720p in lanzcos 10 passes, then processes the SHARPEN filter.
I prefer to get SHARPEN on 720p, than on sh*tty XViD SD(a la 624*320) resolutions ;)

same here.
I select MPEG PS when I install and the splitter don't want to be used with ps file.

I give up on the MPEG PS support, it just doesn't work.
I was wondering if there was any point to use it for AVI mainly ;)

[Isochroma]

I'm considering switching from VMR9 renderless to Haali's renderer due to its superior quality, but need to know which nVidia (no ATI cards, thanks) will be fast enough to display 720p on a 1600x1200 monitor. The requirements:

1. AGP (my mainboard uses it)

2. Fanless (home theatre setup, noise is very important)

3. reasonable power consumption

My current card is a fanless FX5200 AGP 8x, and it is not fast enough to scale DVD resolution to even 1366x768, never mind 1600x1200. All driver settings are at max performance, and AGP Fast Writes are enabled.

My CPU is an Athlon XP Barton running @ 2.33 Ghz. CPU isn't a limiting factor for playback of up to 720p AVC on my machine, using VMR9 renderless.

In light of this, I'm hoping people in this thread could contribute their experiences about how well their cards work with Haali's renderer (please include the make/mode/bus), thanks!

[leeperry]

you don't need a superfast videocard to run it and your CPU is really slow so you'll get better results anyhow...just try it ;)

[Isochroma]

@leeperry: "just try it" doesn't tell me what card to buy, and "your CPU is really slow" is factually incorrect.

[Haali]

I've tested it on a 6800LE, and it was probably overkill for simple video rendering. I think something like a 6600 card might work fine too.

[Isochroma]

Excellent, thank you Haali for the prompt reply. My goal is minimum power consumption for required functionality. I'll probably go for a 6800-class GPU if that's the case.

[leeperry]

oh really....I got a 6800GT/P4 3.4EE/2gigs dual channel, it works like a champ :D

your CPU is indeed slow.......to do 720p lanzcos update, sharpen, etc....

if you balance the load on your GPU, you might get luckier ;)

[wozio]

My goal is minimum power consumption for required functionality. I'll probably go for a 6800-class GPU if that's the case.
If power consuption is priority I think some medium level but from 7 line instead of top from older 6 line, for example 7600gt. I have agp version of radeon x1650 pro which is slower than 7600gt and it handles resizing from 1440x1080i50 to 1360x768 without any problem. When output resolution is 1920x1080 then it starts to slow down but remember, this is 50 fps. Some lower resolution 60fps clips are perfectly smooth even at 1920x1080.

[leeperry]

are you guys sure that your GPU is limiting you ?!
you need some bad ass CPU(C2D) to handle fullHD decoding...

[Peuj]

Hi Haali,

I have a problem with you renderer. When I try to watch the following video on MPC or KMPlayer nothing happens. There is no sound, no images and no CPU but it's like the video is playing because the progress bar is moving.

If I switch to WMR9 renderer I don't have the issue.
I use the latest Haali renderer.
I have a FX5200 Video Card with the latest driver.

http://www.1-clickshare.com/download.php?file=668db2ff0aa53d51d566a71bbf49f0fb_517

Thanks

[Kado]

@Peuj
That file plays just fine on my system, using latest MPC, ffdshow rev1125 (using wmv9 codec instead of libavcodec), and latest haali renderer.

Pentium D @ 3.6ghz
GF 6800GS