Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
2nd March 2006, 20:06 | #1 | Link |
Registered User
Join Date: Jun 2005
Posts: 630
|
Haali Renderer
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. Last edited by Egh; 2nd March 2006 at 20:30. |
2nd March 2006, 20:26 | #2 | Link |
Registered User
Join Date: Jun 2005
Posts: 630
|
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) Last edited by Egh; 14th March 2006 at 17:58. |
3rd March 2006, 00:47 | #3 | Link |
ангел смерти
Join Date: Nov 2004
Location: Lost
Posts: 9,556
|
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.
|
3rd March 2006, 02:56 | #4 | Link | |
Registered User
Join Date: Jun 2005
Posts: 630
|
Quote:
And what about different output with different GPUs? |
|
4th March 2006, 08:11 | #7 | Link | |
Firefox User
Join Date: Sep 2003
Posts: 202
|
Quote:
Haali's renderer VMR9 Mixing renderer 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. Last edited by roytam1; 4th March 2006 at 08:15. |
|
4th March 2006, 08:26 | #8 | Link | |
ангел смерти
Join Date: Nov 2004
Location: Lost
Posts: 9,556
|
Quote:
Couple references: http://www.virtualdub.org/blog/pivot/entry.php?id=92 http://forum.doom9.org/showthread.php?t=96526 |
|
4th March 2006, 08:36 | #9 | Link | |
Registered User
Join Date: Jun 2005
Posts: 630
|
Quote:
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. |
|
4th March 2006, 14:21 | #11 | Link | ||
Firefox User
Join Date: Sep 2003
Posts: 202
|
Quote:
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. Quote:
The latest driver for my PC is 5.10 beta. Edit: Typo. |
||
4th March 2006, 16:29 | #12 | Link |
Registered User
Join Date: Jul 2003
Posts: 282
|
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). Last edited by Haali; 4th March 2006 at 16:34. |
4th March 2006, 16:53 | #13 | Link | |
Firefox User
Join Date: Sep 2003
Posts: 202
|
Quote:
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. Last edited by roytam1; 4th March 2006 at 16:57. |
|
4th March 2006, 20:55 | #14 | Link |
Registered User
Join Date: Nov 2005
Posts: 110
|
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 |
4th March 2006, 22:41 | #15 | Link |
Registered User
Join Date: Nov 2005
Posts: 110
|
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). Last edited by breez; 4th March 2006 at 23:03. |
5th March 2006, 00:47 | #16 | Link | ||
Registered User
Join Date: Jun 2005
Posts: 630
|
Quote:
Quote:
|
||
5th March 2006, 01:26 | #17 | Link |
Registered User
Join Date: Jul 2003
Posts: 282
|
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. |
5th March 2006, 01:31 | #18 | Link | ||
Registered User
Join Date: Nov 2005
Posts: 110
|
Quote:
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. Quote:
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. Last edited by breez; 5th March 2006 at 01:55. |
||
5th March 2006, 03:06 | #19 | Link | |
Registered User
Join Date: Jun 2005
Posts: 630
|
Quote:
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. |
|
5th March 2006, 10:59 | #20 | Link | ||
sidekick
Join Date: Apr 2004
Location: old Europe
Posts: 610
|
Quote:
Quote:
__________________
greets, kurt. Pioneer PDP-427 XA | Popcorn Hour NMT C-200 | Sony STR-DB 840 QS | Canton Ergo 91 DC |
||
Tags |
haali, haali renderer |
Thread Tools | Search this Thread |
Display Modes | |
|
|