Haali Renderer

[Egh]

Recently new piece of software was released from Haali. In public, that is.

Since questions about that were scattered in several threads, I've created a thread for this one as well.

Ask questions, I'll try to get response from Haali on those :P

Info on the renderer:

1. It was released for public in the "MatroskaSplitter" build on 2006-02-25. Version of splitter in that build is 1.6.87.20

2. Alpha-tests for it were available earlier, 2006-02-13 and before that, if I'm not mistaken.

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

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

5. Haali renderer uses bicubic interpolation for resizing.

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

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

8. That's obvious that Haali wrote the new renderer, but not so many ppl khow that shaders for resizing in VMR9 mode were also written by him.

[Egh]

Question: Where to download Haali renderer?

Answer:
http://haali.cs.msu.ru/mkv/MatroskaSplitter.exe
At the moment you can't download the renderer as separate file (it was the case during testing phase though), it's included in Haali splitter package now. The link is given above.

Question: How to check that Haali renderer is working?

Answer:
In MPC, call context menu, go to "Filters" submenu, and check if Haali renderer is there. It should be typically on top of the list, whilst Haali splitter will be in the bottom.

Question: What's the difference between VMR9 and Haali renderer?

Answer (revised):

Haali renderer is similar to VMR9 in the sense it's DirectShow Renderer as well.

Only that it uses shaders for bicubic resizing, and that's forced in the renderer, i.e. it doesnt' work if no PS 2.0 support is found on the system, cause, naturally then it would be just another VMR9. The latter uses bilinear interpolation, cause that's one which is naturally built-in the 3D accellerators from the times they were born.

Question: What's going on inside ? :)

Answer (revised):

To be more technical, in the first mode (For VMR9), mpc allocates DirectShow surface and "offscreen plain source is simply blitted to backbuffer with StretchRect()" . In second and third modes, it creates two triangles and maps the video onto them. So resizing and other transformations like rotations in the 3D mode are done in hardware, using simple bilinear interpolation. These operations don't involve shaders per se.

Proper bicubic is supposed to be two-pass process, and as far as I know that's the one of the reasons for a new separate renderer. To simply put it, it wasn't impossible to implement twopass mode via shaders in mpc with VMR9. But, as Haali himself pointed out, that would require some coding from Gabest.... Which he was apparently reluctant to do. To sum up, mpc bicubic resizing in vmr9 mode is supposed to be inferior in speed to Haali renderer (cause in vmr9 it uses single-pass).

Question: Did Haali wrote code for mpc rezising?

Answer:

Shader for bicubic resizing in VMR9 was written by Haali himself, but not the code for mpc.

Question: Are mpc shaders supported in Haali renderer?

Answer:

As Haali himself pointed out, no, they are not.

Question: What colorspaces does Haali renderer support?

Answer:

Haali renderer accepts atm only YUY2 and RGB32. Conversion is done via GPU in hardware. That means if you have slower card and fast CPU, probably good idea to force RGB32 output in ffdshow (besides that often fixes TV->PC conversion as well)

[foxyshadis]

Q: Is it possible to switch between TV (YUV 16-235->0-255) and PC mode with this? I often find myself switching between renderers because different colorspace, renderer, and gpu combinations have different output modes.

[Egh]

Q: Is it possible to switch between TV (YUV 16-235->0-255) and PC mode with this? I often find myself switching between renderers because different colorspace, renderer, and gpu combinations have different output modes.

Why do you need that? Besides, AVS can be used for TV<->PC color conversion.

And what about different output with different GPUs?

[roytam1]

I got gray/white dots in screen with haali's renderer.

[Egh]

I got gray/white dots in screen with haali's renderer.

screenshot? codec decoding the video, your 3D card, colorspace used ...

[roytam1]

screenshot? codec decoding the video, your 3D card, colorspace used ...Screenshots:
Haali's renderer (http://roytam.byethost11.com/src/1141456029556.jpg)
VMR9 Mixing renderer (http://roytam.byethost11.com/src/1141456050788.jpg)

CPU: AMD Athlon 2600+ (2133MHz)
GPU: ATi Readon 9500
Codec: XviD 1.2.0 cvs 2006-02-28
Colorspace: not forced (default one)
OS: Win XP SP1

Edit: Opening video with haali's renderer is very slow comparing with M$ VMR9 Mixing Renderer.

[foxyshadis]

Why do you need that? Besides, AVS can be used for TV<->PC color conversion.

And what about different output with different GPUs?
If it always correctly processes it, great, just that some stupid mjpeg and mpeg codecs export 0-255 instead of 16-235, and passing it through avisynth is a lot of extra processing. Even besides that, if it passes that conversion on to the video card you're asking for trouble, since different methods or different cards give different conversions.

Couple references:
http://www.virtualdub.org/blog/pivot/entry.php?id=92
http://forum.doom9.org/showthread.php?t=96526

[Egh]

Screenshots:

Edit: Opening video with haali's renderer is very slow comparing with M$ VMR9 Mixing Renderer.

1. Force RGB32 output.

2. I'm not pro at Radeon cardz :0 Please do tell equivalent for GeForce. GFX even 5500FX, not talking 5200FX is generally not recommended for haali rendered (works on small frames but fps drops 2-3 times on fullscreen resizing in my case, i have 5500FX btw).

3. Do you change resolution desktop resolution on playback?

4. How "slow" is opening? Some slowdown is natural I think.

[B.F.]

I had a Rageon9550 on my office PC.
All work fine.
Try to update drivers.

[roytam1]

1. Force RGB32 output.

2. I'm not pro at Radeon cardz :0 Please do tell equivalent for GeForce. GFX even 5500FX, not talking 5200FX is generally not recommended for haali rendered (works on small frames but fps drops 2-3 times on fullscreen resizing in my case, i have 5500FX btw).

3. Do you change resolution desktop resolution on playback?

4. How "slow" is opening? Some slowdown is natural I think.
1. That means Haali renderer doesn't work well with other colorspace? Oh dear.
3. No
4. Counting the time from the state "Opening" till to "Playing" in mpc. Haali's needs about 10 ~ 15 seconds but VMR9 Mixing Renderer only needs 3 ~ 5 seconds.

I had a Rageon9550 on my office PC.
All work fine.
Try to update drivers.
Not able to do so. New drivers kills system.
The latest driver for my PC is 5.10 beta.

Edit: Typo.

[Haali]

To clarify a few things:
* Supported colorspaces are RGB32 and YUY2 only. YUY2 should work fine.
* Color range is TV scale only. This is not adjustable atm.
* Colorspace conversion and resizing is done via shaders, so output should be identical regardless of the video card or drivers.
* Shaders are evaluated once per output pixel, so a lot more work is usually done for a fullscreen presentation.
* Slow startup times are probably caused by hardware configuration. Here startup time is 1-2s regardless of the renderer so didn't even bother to measure it till now.

What is done differently from other renderers:
* Resizing
* Colorspace conversion
These two above are the things I dislike most of all in stock DS renderers.
* All processing is done on a separate thread, so performance on HT/SMP systems is better, on signle CPU machines it's probably worse.
* Video RAM is used to buffer a lot of decoded frames (amount is adjustable in options).

[roytam1]

To clarify a few things:
1. Supported colorspaces are RGB32 and YUY2 only. YUY2 should work fine.

2. Slow startup times are probably caused by hardware configuration. Here startup time is 1-2s regardless of the renderer so didn't even bother to measure it till now.

3. All processing is done on a separate thread, so performance on HT/SMP systems is better, on signle CPU machines it's probably worse.

1. with YUY2 colorspace, while/gray dot comes.
2. I dunno. Same result(startup time of haali's is 1.5~3 times slower than VMR9 Mixing) with my friends' computer.
Test case: plain opening files in mpc, showing 100% without resizing/fullscreen
( Althon XP 1600+ o.c. 2000+, WinXP SP1, Gfx 2 Ti
P4 2.6G, WinXP SP2, Gfx 6600LE
P4 2.4G, WinXP SP1, Gfx 5500FX )
3. Seems so.

Edit: Typo.

[breez]

There seems to be some weird bug with the resizing.

Resizing 640x480 video to fullscreen 1280x1024 (with black bars) results in 100% CPU usage. If I just resize the window by a random amount I either get no increase in CPU usage or sometimes I hit a spot where the CPU usage goes through the roof again (100% or sometimes a smaller amount). No correlation between output frame size and CPU usage, eg. find a spot where 100% CPU usage occurs and then enlarge the window a little and the CPU usage drops to normal levels.

If I force YV12 output colorspace from ffdshow the CPU usage stays normal during any resizing. When no output colorspace is forced, YUY2 is selected and the above mentioned rise in CPU usage occurs. With RGB32 forced there is smaller rise (in fullscreen, didn't try resizing the window).

If Haali renderer only supports YUY2 and RGB32, where does the colorspace conversion from YV12 happen?

System info:
1900MHz Athlon XP
Radeon 9800Pro (should be no slouch at PS 2.0 performance)
Tested with a few different catalyst drivers (5.12, 5.13, 6.1)
MPC 2006.02.26-2.2
The Haali renderer that came with the latest splitter
Windows XP SP2

[breez]

Anyway, forcing YV12 in ffdshow + Haali renderer handling colorspace conversions and resizing gives me very satisfactory performance and almost enables me to playback 1080P H.264 content (give me just 200MHz more and I'm there!). Software YV12 -> RGB32 is just way too processor intensive with 1080P frames.

I also noticed another weird behavior. 1080P H.264 clip decoded by CoreAVC and shown using Haali renderer gives me a picture with the resolution 960x540 (desktop resolution is 1280x1024). However, if I enable raw video support in ffdshow (ie. clip -> CoreAVC -> ffdshow -> renderer), but actually do no processing I get the correct 1920x1080 output.

EDIT:

And of course now I notice that forcing YV12 colorspace means I'm actually getting VMR7 and not Haali at all :) :( Didn't really look at the picture when doing the comparison (no bicubic resize, gamma correction not working).

@Haali:

Will the renderer support YV12 colorspace in the future? Because with practically everything being in YV12 we need to do YV12 -> YUY2/RGB32 in software anyway (which costs CPU cycles).

[Egh]

EDIT:

And of course now I notice that forcing YV12 colorspace means I'm actually getting VMR7 and not Haali at all :) :( Didn't really look at the picture when doing the comparison (no bicubic resize, gamma correction not working).

Exactly. Easiest way to check is filters submenu, of course. So revise the abovementioned bugs and see if those were caused when Haali renderer was on :)

Will the renderer support YV12 colorspace in the future? Because with practically everything being in YV12 we need to do YV12 -> YUY2/RGB32 in software anyway (which costs CPU cycles).

Not that fast. YUY2 is practically same as YV12 :) Converting to RGB is another matter, of course. In YV12 and YUY2 luma is same, only chroma planes differ, and since it's only a factor of two (YUY2 has twice as much "color pixels" compared with YV12, in notation: 4:2:2 and 4:2:0 respectively), conversion YV12->YUY2 is pretty straightforward. Some additional CPU is spent to rearrange luma/color info though, but that should be rather fast (planar/interleaved conversion).

[Haali]

Yes, YV12->YUY2 conversion with linear upsampling is limited by memory bandwidth, not by processing speed. Doing it on the gpu will require multiple passes. I didn't test it, but I expect little or no improvement unless the gpu implements yv12 texture support in hardware.
Video size that the player sees is adjusted to make the window fit inside the screen (I hate large windows that are not entirely visible). Same thing happens with smaller clips, they are enlarged to be at least 400x300.

[breez]

Exactly. Easiest way to check is filters submenu, of course. So revise the abovementioned bugs and see if those were caused when Haali renderer was on :)

I checked again now, Haali renderer is present with the strange behavior (with or without ffdshow in the chain, WMV9 file).

edit: It is worth noting, that there was only a small rise in CPU usage with 640x480 XVID and DivX videos when doing fullscreen resize (decoded by ffdshow). But then with a 640x480 H.264 video (decoded with CoreAVC, ffdshow not in the chain) the CPU was at 100% again.

Not that fast. YUY2 is practically same as YV12 :) Converting to RGB is another matter, of course. In YV12 and YUY2 luma is same, only chroma planes differ, and since it's only a factor of two (YUY2 has twice as much "color pixels" compared with YV12, in notation: 4:2:2 and 4:2:0 respectively), conversion YV12->YUY2 is pretty straightforward. Some additional CPU is spent to rearrange luma/color info though, but that should be rather fast (planar/interleaved conversion).

Yes, there wasn't much difference in CPU usage with YV12 and YUY2 ffdshow (or HQ RGB32 for that matter). Just ffdshow handling raw video though takes 20% eventhough it is doing nothing (YV12 output)! Comparison made with VMR9.

No ffdshow, but just WMV9 decoder and Haali (no resize) gives me ~same 20% higher CPU usage, obviously WMV decoder doing the colorspace conversion (with bad chroma upsampling even! tsk, tsk) so that Haali renderer can accept it.

[Egh]

Yes, there wasn't much difference in CPU usage with YV12 and YUY2 ffdshow (or HQ RGB32 for that matter). Just ffdshow handling raw video though takes 20% eventhough it is doing nothing (YV12 output)! Comparison made with VMR9.

No ffdshow, but just WMV9 decoder and Haali (no resize) gives me ~same 20% higher CPU usage, obviously WMV decoder doing the colorspace conversion (with bad chroma upsampling even! tsk, tsk) so that Haali renderer can accept it.

For WMV9, btw, check post-processing options in it.

What is your CPU and ffdshow build btw? 20% for just passthru seems to be a bit too much. 10% would be more sensible, imo.

[kurt]

And of course now I notice that forcing YV12 colorspace means I'm actually getting VMR7 and not Haali at all :) :( Didn't really look at the picture when doing the comparison (no bicubic resize, gamma correction not working).
Exactly. Easiest way to check is filters submenu, of course. So revise the abovementioned bugs and see if those were caused when Haali renderer was on :)
so what is displayed in filters submenu exactly if haali renderer is working? just "video renderer"? I wonder why the renderer should run on my old matrox g400...

[breez]

For WMV9, btw, check post-processing options in it.

Not sure how to do it. In WMP10 options I have disabled "Use video smoothing" under Video Acceleration -> Advanced for long time. Is this it?

What is your CPU and ffdshow build btw? 20% for just passthru seems to be a bit too much. 10% would be more sensible, imo.

1900MHz Athlon XP. Previously used 21. december build and went back to Milan's latest compiled build from 29. november. The 20% rise only happens with these WMV9 in avi files :confused: AVC in MKV is fine (same resolution, framerate and colorspace) with CoreAVC being the decoder (so ffdshow's role is the same as with the WMV9 files).

so what is displayed in filters submenu exactly if haali renderer is working? just "video renderer"? I wonder why the renderer should run on my old matrox g400...

It says "Haali's Video Renderer".

[Egh]

so what is displayed in filters submenu exactly if haali renderer is working? just "video renderer"? I wonder why the renderer should run on my old matrox g400...

"Video renderer" is old pre VMR renderer :O

Haali renderer should be displayed in the "Filters" submenu on playback, if it's working :)

[Egh]

Not sure how to do it. In WMP10 options I have disabled "Use video smoothing" under Video Acceleration -> Advanced for long time. Is this it?


Truth being said, I don't know :) I would trust old ways more anyhow. I.e. either registry tweakening or downloading program which does it for you. "WMVPostpross.exe" is the name. Link for it was somewhere on doom9, along with instructions how to do essentially same thing but manually altering registry values.

Since PP complexity is directly linked with pixels per frame, disabling PP in WMV9 gives HUEG boost in speed on hdtv resolutions. I.e. with my athlon XP i couldn't watch some 1024*576 wmv9 videos withouth framedropping. Until i disabled PP. Then CPU % dropped considerably, effectively being not so much over XVid.


1900MHz Athlon XP. Previously used 21. december build and went back to Milan's latest compiled build from 29. november. The 20% rise only happens with these WMV9 in avi files :confused: AVC in MKV is fine (same resolution, framerate and colorspace) with CoreAVC being the decoder (so ffdshow's role is the same as with the WMV9 files).


Hmm... Strange. I NEVER had any problems with b0b0rs 1221 build. Sure you use his build? (SSE1 only on x264.nl). And try kuroshi SSE Athlon builds as well (but they have some problems, as I noted in ffdshow builds thread).

Sure it's WMV Decode which does WMV decoding? And which colorspace is ffdshow receiving?

[kurt]

"Video renderer" is old pre VMR renderer :O

Haali renderer should be displayed in the "Filters" submenu on playback, if it's working :)
ok, thank you both for clearing things up... (even if I don't like it :p)

[breez]

Truth being said, I don't know :) I would trust old ways more anyhow. I.e. either registry tweakening or downloading program which does it for you. "WMVPostpross.exe" is the name. Link for it was somewhere on doom9, along with instructions how to do essentially same thing but manually altering registry values.

Since PP complexity is directly linked with pixels per frame, disabling PP in WMV9 gives HUEG boost in speed on hdtv resolutions. I.e. with my athlon XP i couldn't watch some 1024*576 wmv9 videos withouth framedropping. Until i disabled PP. Then CPU % dropped considerably, effectively being not so much over XVid.

Found the WMVPostpross.exe. There is a difference in CPU usage, but the 100% @ fullscreen resize remains.

Hmm... Strange. I NEVER had any problems with b0b0rs 1221 build. Sure you use his build? (SSE1 only on x264.nl). And try kuroshi SSE Athlon builds as well (but they have some problems, as I noted in ffdshow builds thread).

Can't remember off hand if it was b0b0r's build or not, but it was a fast build and worked very well with my AXP. Note, the strange behavior is also present with the Milan's 29. nov build (which to me seems very stable). I'll try some other builds.

Sure it's WMV Decode which does WMV decoding? And which colorspace is ffdshow receiving?

Yup, "WMVideo Decoder DMO" in the filters list and ffdshow receives YV12 as expected (encode source from DVD).

[chros]

Edit: Opening video with haali's renderer is very slow comparing with M$ VMR9 Mixing Renderer.
Yes, same here, aprox. 3-4 sec. Geforce 6600GT, driver 81.85, MPC 6.4.8.8
Is it right ? (maybe because of desing ?)

1080P H.264 clip decoded by CoreAVC and shown using Haali renderer gives me a picture with the resolution 960x540 (desktop resolution is 1280x1024).
Same here with a *.ts file: contains a MPEG2 video ...

[breez]

I presume the slow startup is because of buffering. Try setting the amount of buffering lower in Haali Video Renderer properties (click on it in the filters list).

[Oline 61]

So this renderer properly scales the chroma in YV12 (4:2:0) so that you don't get the jaggies (http://forum.doom9.org/showthread.php?t=106111&highlight=vmr9+yv12)?
I have a 6600GT, so no RGB overlay, and VMR9 does a 0-255 -> 16-235 conversion that washes out the video. MY only choice is to convert to RGB and use VMR9, but then I have to switch to Overlay for non RGB sources!

[breez]

So this renderer properly scales the chroma in YV12 (4:2:0) so that you don't get the jaggies (http://forum.doom9.org/showthread.php?t=106111&highlight=vmr9+yv12)?

Yup.

EDIT: Ah, actually the renderer doesn't support YV12 at all. I guess the YUY2 > RGB is done without such mistakes though.

I have a 6600GT, so no RGB overlay, and VMR9 does a 0-255 -> 16-235 conversion that washes out the video. MY only choice is to convert to RGB and use VMR9, but then I have to switch to Overlay for non RGB sources!

Not to be a nitpicker, but it is really the other way around, the possible conversion is from 16-235 -> 0-255 (since the levels in video are originally 16-235).

You could try the latest forceware 84.12, reportedly nvidia changed the behavior with these drivers and 16-235 -> 0-255 conversion is done with VMR9 (ppl at avsforum weren't too happy).

[Oline 61]

Not to be a nitpicker, but it is really the other way around, the possible conversion is from 16-235 -> 0-255 (since the levels in video are originally 16-235).

You could try the latest forceware 84.12, reportedly nvidia changed the behavior with these drivers and 16-235 -> 0-255 conversion is done with VMR9 (ppl at avsforum weren't too happy).
Okay, I am on Forceware 81.98 and it does do a 16-235 -> 0-255 conversion, making the video look washed out. Are you saying that 84.12 doesn't do the conversion or that it does do the conversion? My current setup does do the conversion.

[breez]

Okay, I am on Forceware 81.98 and it does do a 16-235 -> 0-255 conversion, making the video look washed out. Are you saying that 84.12 doesn't do the conversion or that it does do the conversion? My current setup does do the conversion.

In my experience, not doing conversion from 16-235 to 0-255 will make the video look washed out on a PC display (which expects levels 0-255). 84.12 does the conversion, previous drivers do not (AFAIK).

[LoRd_MuldeR]

Where is download for Haali Renderer?

[breez]

Where is download for Haali Renderer?

It is included with latest Haali media splitter.

[Oline 61]

Okay, I'll give 84.12 a shot.

[chros]

... resizing hd video ...
Same here with a *.ts file: contains a MPEG2 video ...
BTW: perhaps it's a feature !

[breez]

BTW: perhaps it's a feature !

Could be :) But users probably want such a feature to be an option.

[JarrettH]

Can't use my ffdshow with it :/

[Oline 61]

Thanks, breez, 84.12 solves the problem completely. That simplifies my video playback experience a great deal.

[LoRd_MuldeR]

It is included with latest Haali media splitter.

I have the latest Haali Media Splitter, but how to enable the Renderer?

[breez]

I have the latest Haali Media Splitter, but how to enable it?

You need a recent MPC (6.4.8.8 was just released). You can choose Haali renderer from the options (Output).

[Egh]

Where is download for Haali Renderer?

@ All:

do read first two posts before asking something!

I'm constantly updating mini-FAQ in the second post, btw.

Today included answers about shaders support in the renderer and how to identify if it's working in the decoding chain :D

Anything else worth including in the FAQ, btw?

Also I would like to see reports on Haali renderer speed in different configurations (i.e. report OS, cpu, 3D card, drivers, resolution and colorspace used and fps, of course).

[Egh]

Yes, same here, aprox. 3-4 sec. Geforce 6600GT, driver 81.85, MPC 6.4.8.8
Is it right ? (maybe because of desing ?)


Same here with a *.ts file: contains a MPEG2 video ...

Again: haali renderer is supposed to have slower startup, it need to engage shaders and allocate lots of VRAM.

Can you be more specific about problems with lower resolution?


In my experience, not doing conversion from 16-235 to 0-255 will make the video look washed out on a PC display (which expects levels 0-255). 84.12 does the conversion, previous drivers do not (AFAIK).


You're right. MPEG4 is in TV range (not exactly 16-235 btw :P), PC display range is 0-255. You can test all that with just one AVS command : ColorYUV(levels="TV->PC")

Converting to RGB in ffdshow, btw, takes levels into account.

[LoRd_MuldeR]

Again: haali renderer is supposed to have slower startup, it need to engage shaders and allocate lots of VRAM.

Okay, I found the option in MPC ;)

But startup is REALLY slow. Too slow indeed!
You press "play" and you have to wait about 10 seconds before it starts to play.
Worst is, the whole system freezes during this time.

Until this is improved, I'll have to disable Haali Renderer... :(

[Egh]

In my experience, not doing conversion from 16-235 to 0-255 will make the video look washed out on a PC display (which expects levels 0-255). 84.12 does the conversion, previous drivers do not (AFAIK).

I tried new drivers (which are still beta), but conversion is not done on YV12/YUY2 for VMR9. Or maybe that conversion is not for FX5500?

So far back to old good RGB32 output in ffdshow :) Btw amazingly hi-q conversion does provide a slight improvement on colors compared to plain RBG32. Can't explain why exactly :)

[Oline 61]

High quality conversion properly scales the chroma instead of doing pixel doubling.

[Haali]

Video size that the player sees is adjusted to make the window fit inside the screen (I hate large windows that are not entirely visible). Same thing happens with smaller clips, they are enlarged to be at least 400x300.
This does not affect the image in any way.

[chros]

I presume the slow startup is because of buffering. Try setting the amount of buffering lower in Haali Video Renderer properties (click on it in the filters list).
I have select the minimum amount of buffer (16MB) but the problem is the same, I have measured it: 10 sec ! (All ther other renderer work ok.)

So you guys want to tell me, that you have not experienced such a slow down at loading files ????

[breez]

I have select the minimum amount of buffer (16MB) but the problem is the same, I have measured it: 10 sec ! (All ther other renderer work ok.)

So you guys want to tell me, that you have not experienced such a slow down at loading files ????

Yes, I have the slow down as well, but 10s is not really significant for me if I'm going to watch a video 24+ minutes long :)

[flanger216]

Awesome... on my sys (Radeon X1300) it's much, much faster than FFDshow's lanczos resize and looks comparable.

Only one problem: I use Zoomplayer, which has a zoom function that allows you to scale video to larger than fullscreen, which is useful when watching 4:3 letterboxed content on my widescreen monitor. However, when using the Haali Renderer, the video blanks out when I enlarge the video beyond fullscreen. Of course, I don't know if the fault lies in the renderer or Zoomplayer itself, but it works perfectly with overlay and all VMR modes.

[B.F.]

Awesome... on my sys (Radeon X1300) it's much, much faster than FFDshow's lanczos resize and looks comparable.

Only one problem: I use Zoomplayer, which has a zoom function that allows you to scale video to larger than fullscreen, which is useful when watching 4:3 letterboxed content on my widescreen monitor. However, when using the Haali Renderer, the video blanks out when I enlarge the video beyond fullscreen. Of course, I don't know if the fault lies in the renderer or Zoomplayer itself, but it works perfectly with overlay and all VMR modes.

You need to change your player.
On MPC all work OK.