Haali Renderer [Archive]

Egh

2nd March 2006, 20:06

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

2nd March 2006, 20:26

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

3rd March 2006, 00:47

Egh

3rd March 2006, 02:56

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

4th March 2006, 05:16

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

Egh

4th March 2006, 07:24

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

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

roytam1

4th March 2006, 08:11

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

4th March 2006, 08:26

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

4th March 2006, 08:36

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.

4th March 2006, 12:09

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

roytam1

4th March 2006, 14:21

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

4th March 2006, 16:29

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

4th March 2006, 16:53

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

4th March 2006, 20:55

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

4th March 2006, 22:41

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

5th March 2006, 00:47

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

5th March 2006, 01:26

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

5th March 2006, 01:31

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

5th March 2006, 03:06

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

5th March 2006, 10:59

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

5th March 2006, 12:51

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

5th March 2006, 20:42

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

5th March 2006, 20:49

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

5th March 2006, 20:51

"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

5th March 2006, 21:23

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

5th March 2006, 22:02

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

5th March 2006, 22:27

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

5th March 2006, 22:29

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

5th March 2006, 22:38

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

5th March 2006, 22:41

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

5th March 2006, 22:45

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

5th March 2006, 22:45

Where is download for Haali Renderer?

breez

5th March 2006, 22:46

Where is download for Haali Renderer?

It is included with latest Haali media splitter.

Oline 61

5th March 2006, 22:47

Okay, I'll give 84.12 a shot.

chros

5th March 2006, 22:51

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

breez

5th March 2006, 22:53

BTW: perhaps it's a feature !

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

JarrettH

5th March 2006, 22:54

Can't use my ffdshow with it :/

Oline 61

5th March 2006, 23:21

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

LoRd_MuldeR

6th March 2006, 00:13

It is included with latest Haali media splitter.

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

breez

6th March 2006, 00:15

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

6th March 2006, 00:17

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

6th March 2006, 00:20

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

6th March 2006, 01:32

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

6th March 2006, 02:14

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

6th March 2006, 02:19

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

Haali

6th March 2006, 09:26

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

6th March 2006, 09:31

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

6th March 2006, 13:17

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

7th March 2006, 03:45

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.

7th March 2006, 06:08

MetalPhreak

10th March 2006, 23:21

This is pretty neat - I have a feeling this going to become my default renderer.
Ok here's a question - in the configuration for the renderer there's an option for buffer size and something called A, what is this A? (sorry if I missed this)
I also noticed the frame rate is extremely erratic - on 25fps video it's jumps between 23 and 30 fps.

Egh

11th March 2006, 04:56

Ok here's a question - in the configuration for the renderer there's an option for buffer size and something called A, what is this A? (sorry if I missed this)
I also noticed the frame rate is extremely erratic - on 25fps video it's jumps between 23 and 30 fps.

A is supposed to be parameter which affects shaprening effect. I don't know the relation between this param and standard avc style b&c params though. Need to ask Haali about it :)

B.F.

11th March 2006, 05:08

A is supposed to be parameter which affects shaprening effect. I don't know the relation between this param and standard avc style b&c params though. Need to ask Haali about it :)
The same as VirtualDub resize.
0.6 - soft
0.75 - normal
1.0 - sharp

Egh

11th March 2006, 13:37

The same as VirtualDub resize.
0.6 - soft
0.75 - normal
1.0 - sharp

What about values below 0.6?

Edit:

wheee, I found out the relation :approved:

c = -A; b + 2*c = 1;

Where A = Haali parameter; b, c = AVS parameters for bicubic sharpening.

Rash

12th March 2006, 21:58

Egh, just a suggestion. Include the Haali Splitter download link on your first post. ;)

OCedHrt

13th March 2006, 12:41

I also have a major wait time when loading videos. 10 seconds sounds about right.

Radeon 9800 Pro
2 Ghz Athlon XP-M
1 GB RAM

Update: The load time definitely varies depending on how the video is opened. If the video is opened into a new instance of mpc, the load time is instanteous. If I re-use the MPC window, it can take anywhere from 5 seconds to 15 seconds.

chros

14th March 2006, 09:56

The same as VirtualDub resize.
0.6 - soft
0.75 - normal
1.0 - sharp
From the manual of Virtualdub:
"Precise bicubic (cubic spline decimation filter):
Compute the desired pixel by applying a triangle filter to the closest N source pixels, where N=16 for enlarging and N>16 for shrinking. This mode is the same as bicubic for enlargement but gives better results when shrinking. Three different modes are given, A=-1.0, A=-.75, and A=-0.6. These vary the "stiffness" of the cubic spline and control the peaking of the filter, which perceptually alters the sharpness of the output. A=-0.6 gives the most consistent results mathematically, but the other modes may produce more visually pleasing results."

- So, when you're enlarging video, these A values doesn't take account, just when you're shrinking.
- and mathematically isn't the A=-0.6 is the sharpest ?

Update: The load time definitely varies depending on how the video is opened. If the video is opened into a new instance of mpc, the load time is instanteous. If I re-use the MPC window, it can take anywhere from 5 seconds to 15 seconds.
Confirmed with MPC v6.4.8.9 :(

LoRd_MuldeR

14th March 2006, 11:35

Update: The load time definitely varies depending on how the video is opened. If the video is opened into a new instance of mpc, the load time is instanteous. If I re-use the MPC window, it can take anywhere from 5 seconds to 15 seconds.

Hmmm...

For me it always takes 15 seconds with Haali Renderer enabled, no matter how I open the clip
(latest celtic build)

Egh

14th March 2006, 16:37

Hmmm...

For me it always takes 15 seconds with Haali Renderer enabled, no matter how I open the clip
(latest celtic build)

2 All:

You have to try harder to produce some more consistent report on this problem. The point is that Haali himself tried but failed to reproduce that bug.

It seems it's related to some specific DX/drivers/Card.

Seb.26

14th March 2006, 17:03

2 All:

You have to try harder to produce some more consistent report on this problem. The point is that Haali himself tried but failed to reproduce that bug.

It seems it's related to some specific DX/drivers/Card.
Ok:
> A64 3200+
> Ge6150
> nForceWare 84.12 (beta)
> MPC+CoreAVC+Reclock

About 10s for displaying 1st frame of video ( I will try if wait time depend on buffer size ... Does the render wait the buffer is full before start playback ? )

Is that is enought ?
( In case "No" : please ask what you want ;) )

LoRd_MuldeR

14th March 2006, 23:57

2 All:

You have to try harder to produce some more consistent report on this problem. The point is that Haali himself tried but failed to reproduce that bug.

It seems it's related to some specific DX/drivers/Card.

I use latest MPC build from Celtic Druid.
OS is WinXP (32-Bit) with SP-1.
Card is ATI Radeon 9800 Pro with Radeon Omega Drivers 3.8.221 (Catalyst 6.2)
And I use DirectX 9.0c (Feb 2006 release)

Again: Takes at least 10-15 seconds to start playback.
Computer is frozen during this time...

OCedHrt

15th March 2006, 03:08

At first I thought it might just be the ATI cards, but it seems some GeForce users are having problems too.

flanger216

15th March 2006, 05:18

Using Zoomplayer with the latest FFDshow on my Radeon x1300, there's a roughly 5-10 delay, the length of which seems to be directly proportional to how much video cache I use.

Also, very rarely I come upon a video that doesn't seek properly when I use the Haali renderer, but works fine when I use VMR9.

Scoty

15th March 2006, 10:18

i use the latest MPC with Haalis Reenderer and the NVidia PureVideo Decoder but how can i set Force RGB32 output ? in the new MPC i can not find the settings.

Egh

15th March 2006, 16:17

i use the latest MPC with Haalis Reenderer and the NVidia PureVideo Decoder but how can i set Force RGB32 output ? in the new MPC i can not find the settings.

RGB32 is enforced in the decoder. So e.g. if you use ffdshow you can disable output in YV12, YUY2 etc, apart from RGB32.

Egh

15th March 2006, 16:18

Also, very rarely I come upon a video that doesn't seek properly when I use the Haali renderer, but works fine when I use VMR9.

If that problem is reproducible (would like to know parameters of the file at least, i.e. which tracks it has, which container etc) can you upload some fragment of that to lets' say rapidshare?

Scoty

15th March 2006, 19:21

i found a other problem with Haalis Reenderer. i dont have picture on my TV. with the standart output i have a TV picture but with Haalis Reenderer i see only black screen on my TV (SVHS). what can i do ?

flanger216

15th March 2006, 23:55

If that problem is reproducible (would like to know parameters of the file at least, i.e. which tracks it has, which container etc) can you upload some fragment of that to lets' say rapidshare?

Yeah, sorry for the vague bug-report. The files were all MP42 encodes, and I remember there being some sort of problem with their indexes. Unfortunately, I've since deleted them and don't recall where I got them. Again, definitely not a big bug and probably an issue with the video-files themselves.

Egh

16th March 2006, 04:10

Scoty

16th March 2006, 09:41

What kind of standard output do you use? Overlay or VMR9?

overlay.

Egh

16th March 2006, 17:53

overlay.

Try if same effect is with VMR9 btw. Of course Haali renderer doesn't use overlay

Scoty

16th March 2006, 19:42

Try if same effect is with VMR9 btw. Of course Haali renderer doesn't use overlay

will work tv out only with overlay over svhs ?

Egh

17th March 2006, 04:01

will work tv out only with overlay over svhs ?

That's for you to research. In context of this thread you need to make sure that bugs are caused specifically by Haali renderer, not due to, like in this case, not using overlay.

KoD

25th March 2006, 11:53

Finally I can post on this board. The 5 days delay set between registering and being able to post sure is annoying.

1. People having issues with high CPU load when using YV12 or YUY2 output colorsapce from their decoder (ffdshow by default options, divx/xvid by default, too). It seems that this causes the driver to work overtime (at least on ATi cards from the 9xxx series and systems with single core CPU) and that's why you get a very high CPU usage. Force RGB32 output in your video decoder (in ffdshow, uncheck YV12 and YUY2 modes, in divx I believe there is no way to force RGB output, in XviD there's an option to force the output colorspace to RGB32). This will make your video playback run at normal (read proper) CPU usage again.

2. "I don't use YV12/YUY2 in my video driver but I can still use Haali's renderer although it's supposed to only work with YUY2 or RGB input. And this works on some files but it doesn't on others !". Most likely you were not aware of all the filters in the video rendering chain. Probably you have files with subtitles which make vsfilter to be loaded, and guess what happens... vsfilter performs the colorspace conversion from YV12 to YUY2 ! Check this by enabling the OSD page in vsfilter options and look at the input colorspace and the output one. This also means that CPU usage will be higher on certain video cards/CPU combinations, because of the problem mentioned at point 1). Feeding the renderer with YUY2 (from vsfilter output) -> high CPU usage. So, it's better to force RGB output in the video decoder.

3. High load times when opening a video file. This happens to me too, P4 2.4GHz, Ati Radeon 9700 Pro card, latest Dx, WMP10 on clean WinXp SP2 install.

4. One real problem I have noticed is tearing. This happens on all files but it's easy to spot only on those with high motion or flickering image. Haali said he'd be working on this (that was a few weeks ago).

5. Haali's renderer does not use Overlay ! It uses YUY2/RGB texture/render surfaces, just like VMR9 does ! So, of course using Overlay output will give nothing on TV-out ! And having TV-out output would probably require some other things to be implemented, things that were not really a proirity for a test release...

Egh

25th March 2006, 16:53

1.

2.

5.

As for 1. and 5. I pretty much told the same already :)

As for number 2, it could be a good explanation. I myself don't use VSFilter though :P

"And having TV-out output would probably require some other things to be implemented, things that were not really a proirity for a test release..." First, I think you still can get TV out if you change drivers configuration settings, and second, the current release of Haali renderer is no way a test release :) Test releases were prior 25th of Feb, and were not available to public.

KoD

25th March 2006, 21:42

It does look as a test release though because of the warning that's posted on Haali's website.

Regarding number 2: play the file in MPC and use graphedit to connect to the filter graph. Is there anything between the output of the video decoder and the input in Haali's renderer ?
(because magic doesn't happen ^^ )

Egh

26th March 2006, 03:38

It does look as a test release though because of the warning that's posted on Haali's website.

where is it exactly?

Regarding number 2: play the file in MPC and use graphedit to connect to the filter graph. Is there anything between the output of the video decoder and the input in Haali's renderer ?
(because magic doesn't happen ^^ )

And what should be there? :confused:

KoD

26th March 2006, 11:16

I'm sorry. Looking again on the webpage I see no warning about potential problems with the splitter. I could have sworn, though... ^^;

As for the other problem, there should be something that performs the color space conversion. Except the case that this color psace conversion is performed by the video driver (unlikely), there must be something that does it.

futurex

26th March 2006, 14:59

breez

26th March 2006, 15:24

i dont know if this has been answered already, but the delay when using haali renderer looks like its depends on the decoder. try forcing dscaler for dvd/mpeg2, when compared to intervideo for example.

on my system, using dscaler it loads instantly, while intervideo takes around 10-15 seconds

Make sure Haali renderer is on the filters list when you use Dscaler decoder. Dscaler probably outputs YV12 by default (it is switchable to YUY2 through the decoder's settings and no "auto" setting available) and that just won't work with the current Haali renderer and thus another renderer will be used (VMR7 seems to be the fallback renderer of choice in MPC).

Egh

26th March 2006, 17:58

(VMR7 seems to be the fallback renderer of choice in MPC).

i think it's more old preVMR renderer even.

futurex

27th March 2006, 02:47

its definitely using haali renderer :)

i checked the "pin info" with haali, it says input is YUY2, then i checked dscaler's "pin info" and it says YV12 for "video out"

does that mean its not working correctly/efficiently? what should it be? :)

btw im using dscaler 5.0.0.8, elecard demuxer and ffdshow raw video (i havent set ffdshow to do any processing, it just passing the video through). im using a dvb mpeg2 stream

flanger216

4th April 2006, 00:00

Been playing around with this some more, and I've noticed I get little micro-tears in the video, similar to what VMR9 looks like when v-sync isn't working properly. For what it's worth, v-sync is forced-on in the drivers on my Radeon x1300.

breez

4th April 2006, 00:06

KoD

5th April 2006, 00:40

KoD

5th April 2006, 23:49

Another issue: when playing something, if I pause the file the video still goes on for a little. Then I do a skip back for 5 seconds in MPC using the keyboard, I unpause playback but now the video is no longer synched to the audio. If I pause it again, skip back and unpause, video and audio are synched again.

futurex

6th April 2006, 06:37

check your cpu load when playing the file. i find it does that on hi def video, certainly not limited to haali's renderer

flanger216

21st April 2006, 09:50

Any plans on adding in some pixel-shader - based deinterlacing? That would be, well, sweet.

Egh

22nd April 2006, 01:44

Any plans on adding in some pixel-shader - based deinterlacing? That would be, well, sweet.

In theory can be done, to my knowledge. I wonder if haali himself wishes to do that, though.

flanger216

22nd April 2006, 02:49

In theory can be done, to my knowledge. I wonder if haali himself wishes to do that, though.

Yeah, I just assumed it could be done in a way similar to MPC's pixel-shader deinterlacer. Even a simple blend capability would be useful, IMO.

LoRd_MuldeR

8th May 2006, 17:00

The new version (7/05/2006) unfortunately still freezes my system for about 15 seconds each time I start playback. Is there anything I can do about that?

My specs: WinXP, ATI Radeon 9800 Pro, AthlonXP 2800+

celtic_druid

8th May 2006, 17:33

Working ok here now.
Win2k SP4, ATI X1600 XT*1, X2 4200+

1-2sec delay.

My previous system I also had an excessive delay. Same video card as you to.

LoRd_MuldeR

8th May 2006, 17:45

Working ok here now.
Win2k SP4, ATI X1600 XT*1, X2 4200+

1-2sec delay.

My previous system I also had an excessive delay. Same video card as you to.

So it seems to be an incompatibility between Haali Renderer and Radeon 9800 Pro...
Problem is, that it's not only a delay. It freezes the whole system.
For example if I have web-radio playing in background and start some video in MPC with Haali Renderer enabled, the radio will also freeze.

Too sad, because Haali Renderer gives good results...

celtic_druid

8th May 2006, 17:56

Don't think it frooze the system here. I could probably put together another PC with the 9800pro in it.

LoRd_MuldeR

8th May 2006, 18:56

Don't think it frooze the system here. I could probably put together another PC with the 9800pro in it.

Maybe I should say that I use WinXP with SP-2, DirectX 9.0 (April 2006 release) and latest Omega Drivers.

EDIT: Updated to official Catalyst 6.4. No change...

Haali

8th May 2006, 22:03

LoRd_MuldeR

8th May 2006, 22:25

Could it be an incompatibility with some version of ati video drivers? Haali Renderer allocates all available VRAM at start of playback if you don't limit it in the options, so it could cause some strange effects.

I already have lastest official ATI drivers (Catalyst 6.4)
And I also tried latest Omega Drivers (based on Catalyst 6.3)
Problem unchanged with both!

I also limited VRAM to 16MB in the Haali Renderer settings (altough the 128MB of my Radeon 9800 Pro should be enough, eh?), but still no change.

So any suggestions, what can I do ???

Haali

8th May 2006, 22:31

I have no other ideas so far. I understand this happens only on ati 9800 cards, right?

LoRd_MuldeR

8th May 2006, 22:40

I have no other ideas so far. I understand this happens only on ati 9800 cards, right?

Well, it happens to me and I have only my ATI 9800 Pro.

If it happends on other 9800 Pro's this card might be the problem.
But I think it's also possible, that my specific PC is the problem.

No idea so far. Are other 9800 Pro user's here?

Palikrovol

8th May 2006, 23:00

I have a AIW 9800SE with latest Omega drivers (6.3) and i think it's ok.
It gets 8 seconds to play the movie, but is played after all.

CPU increases very much when resize to full screen.

LoopX3

9th May 2006, 00:15

I have an ATI 9800 128MB (might not be Pro) and don't have any problems. There is no delay except for loading (~1-2 sec or less).
Other comp specs: P4 2.6, WinXP SP2, DirectX (April 2006), ATI Catalyst 6.4

LoRd_MuldeR

9th May 2006, 00:21

CPU increases very much when resize to full screen.

Yes, here too.

Haali

9th May 2006, 00:27

LoRd_MuldeR

9th May 2006, 00:34

Shaders are evaluated once for each destination pixel, so if you go fullscreen there is a lot more work to be done on the gpu. GPU drivers can wait for the gpu to complete rendering by spinning in a tight loop on a cpu, and this contributes to cpu use.

Interesting. But CPU usage isn't a big problem for me. Does not go higher than 75% at maximum. The problem is the long delay it takes to startup.

What about this: If playback was already started and I press stop and then play again, it will play immediately and *not* freeze. But once I open a new file, it will again freeze for about 15 sec. Seems like the Renderer needs to be re-initialized each time I open a new file. Is there a way to avoid that? Would be some improvement, because then I only had to wait 15 secs one time...

futurex

9th May 2006, 01:59

i am still having a problem with playing dvd's with MPC + haali renderer. when i play the VOBs, or any file, it works fine. but when i open the dvd as a whole, mpc crashes after i try to seek

dscaler as the decoder. all is well when i change to overlay/vmr. this happens wit every dvd :(

flanger216

9th May 2006, 02:28

I have no other ideas so far. I understand this happens only on ati 9800 cards, right?

It also happens on my 512MB Radeon x1300 : about a 15-second delay, during which I get 100% CPU usage.

Sirber

9th May 2006, 02:54

sillKotscha

9th May 2006, 03:17

Any way to get overlay video mirroring on ATI?

if you use the official ati drivers and install their own control center as well, then you have to untick the coloured window...

http://i3.tinypic.com/xl9cld.png

and of course use ffdshow for overlay...

http://i3.tinypic.com/xl9gmf.png

flanger216

9th May 2006, 03:32

Works #1 on my X800XL 256MB. The more buffer I ask the more delay I get on start.

@flanger216

The decoder work at top speed to fill the buffer before the display start.

@All

Any way to get overlay video mirroring on ATI?

Oh, I know. I'm not complaining; just noting that the mysterious 15-second delay isn't limited to Radeon 9800s.

Sirber

9th May 2006, 03:40

@sillKotscha

I don't have the .NET control panel. All I have is ATI Tray Tool (http://www.radeon2.ru/atitray/). I did not find that option yet :(

[edit]

gonna get it :(

Sirber

9th May 2006, 04:00

setting the same as you now, still no overlay :(

[edit]

gonna extend desktop and fulslcreen manually then. no problem.

foxyshadis

9th May 2006, 12:20

I have a little weirdness with Haali's. Half-D1 video (ye olde VHS) gets double-sized by the renderer, and then resized again when set to full screen. At least, I think it's resizing twice, because it looks aliased as hell, presumably the effect of bicubic's sharper resize. (Especially on low A values, almost looks like point sampling.)

(On the other hand, noticing finally got me to switch on ffdshow's resize. I don't suppose there's any way to do spline resize even partially in a shader...? So much better looking than normal kernel resizers.)

Haali

9th May 2006, 16:48

No, resizing is done only once, but the size reported to the player is adjusted so the video fits the screen and is not too small.

flanger216

9th May 2006, 18:29

I still have the bug in Zoom Player where enlarging the video past 'full screen' (with 4:3 letterboxed content, for instance) causes the screen to blank out to a black screen.

B.F.

10th May 2006, 03:06

Haali
I had a GF6600 card and I had a 5 sec delay on the startup.
Drivers ForceWare 84.25

And I think you need make this autoresizig thing optional.

Soulhunter

10th May 2006, 09:07

I have a little weirdness with Haali's. Half-D1 video (ye olde VHS) gets double-sized by the renderer, and then resized again when set to full screen. At least, I think it's resizing twice, because it looks aliased as hell, presumably the effect of bicubic's sharper resize. (Especially on low A values, almost looks like point sampling.)
Looks it like this (http://forum.doom9.org/showpost.php?p=772467&postcount=66) maybe?

Bye

foxyshadis

10th May 2006, 09:40

That's referring to the chroma interpolation? No, this is on the luma channel also. I guess that A=0 actually is point sampling, so that kind of makes sense now, and once I thought about it I realized that two bicubic resizes would actually look a lot better than a single huge jump from 320x240 to 1280x1024 anyway (just try it in photoshop, the more resize steps the nicer it looks, although it thickens edges). It's that one huge leap that looks so nasty. So letting ffdshow resize partway under a certain resolution is probably the best way anyway, if you can spare the cpu power.

Soulhunter

10th May 2006, 10:06

That's referring to the chroma interpolation?
No, wasnt about chroma interpolation, its some sort of "scaling bug" (jaggy edges) my old radeon produced when feeding RGB stuff with a horizontal resolution above 768 pix. to the overlay!

Bye

LoRd_MuldeR

10th May 2006, 13:39

@Haali:

I can playback verious files with only one time initializing the Haali Renderer. This is possible in Gaph Edit. Just keep the renderer on the graph, add new video and connect to existing Renderer. This way I have the "freezing effect", that happens when Haali Renderer is initialized, only one time, and *not* each time I play a new file. A great improvement for me. So I think this should be possible with Players like MPC too, eh? So is it the Renderer itself or a the player that needs to be updatet to support that feture? And if it's the renderer, did you ever think about adding this feature?

KoD

10th May 2006, 20:54

I have the same problem with waiting time during starting playback. It's a period in which the CPU is used at 100%. I'd say the length of the wait time is proportional with the CPU one has and not anything else. My 2.4 GHz P4 shows signs of its age.

I have a Radeon 9700Pro (so, even older than the 9800Pro) and no matter what Catalyst driver I have used since the haali renderer appeared, this problem happened all the time.

Sirber

10th May 2006, 21:02

normal, you have to fill the buffer, so your CPU decode like crazy to do it. The bigger the buffer you set, the longer the delay is.

Haali

11th May 2006, 08:55

normal, you have to fill the buffer, so your CPU decode like crazy to do it. The bigger the buffer you set, the longer the delay is.
This is incorrect. Playback starts immediately while the decoder can proceed on another thead if it can decode more data. I use a rather high priority for the renderer thread, so it's unlikely that a running decoder prevents the renderer from displaying video. Also ppl with slow startup problem experience the delay only when directx objects are initially created, not when playback starts from stopped state. I think it's some unexpected interaction with the driver or directx that causes such a long delay.

LoRd_MuldeR

11th May 2006, 09:56

This is incorrect. Playback starts immediately while the decoder can proceed on another thead if it can decode more data. I use a rather high priority for the renderer thread, so it's unlikely that a running decoder prevents the renderer from displaying video. Also ppl with slow startup problem experience the delay only when directx objects are initially created, not when playback starts from stopped state. I think it's some unexpected interaction with the driver or directx that causes such a long delay.

Ist here a way to fix that :confused:

B.F.

11th May 2006, 10:19

Haali

11th May 2006, 14:09

Can you make a render priority lower?
I don't want to do that, because the renderer needs to display frames at the requested timestamps. If it had a low priority, then decoding could interfere with that and increase jitter.

Haali

11th May 2006, 14:11

Ist here a way to fix that :confused:
There probably is, but so far the cause is not clear.

celtic_druid

11th May 2006, 15:20

Unfortunatly I changed too much in my system to determine what exactly fixed the problem here.
Different video cards.
Different CPU.
Different MB chipsets.

LoRd_MuldeR

11th May 2006, 16:13

There probably is, but so far the cause is not clear.

Is there any way I can help to find the problem ???

mike_lee

11th May 2006, 16:45

Haali, I'm like a big fan - haha, to me you are a rock star - I don't know why I got that impression :-)
Anyway, I am trying to use my new PC with g a eforce 7900 GTX card. I like ffdshow because I can change image settings (using ffpresets) on the fly. I have to moniter and review a lot of video clips at once. At around 6 clips the screen starts to get cluttered and the processors start to lag. However, using the haali renderer, which looks better to my eyes then vmr9, I can no longer tweak the ffdshow filters in real time, there is quite a delay between the time you move a fader inside ffdshow (picture properties, gamma, saturation etc) and the time the clip responds. So I wonder if you have any suggestions?

Keep up the good work.

mike_lee

11th May 2006, 16:45

- - - Dp - - -

Haali

11th May 2006, 20:51

B.F.

12th May 2006, 03:18

I don't want to do that, because the renderer needs to display frames at the requested timestamps. If it had a low priority, then decoding could interfere with that and increase jitter.
Then how about make priority control like in VDub? :)

Haali

12th May 2006, 09:11

Then how about make priority control like in VDub? :)
I don't understand why would anyone deliberately set up a system in such a way that frames can be displayed at a wrong time. It's essential for correct presentation that rendering is not delayed by other activity, especially since my renderer does this on a separate thread, and not on the decoder thread, where the decoder is suspended while waiting for presentation time. It is not some background encoding after all.

B.F.

12th May 2006, 10:08

Just for test. :)
And I don't think too high priority is a good idea.

P.S.
Maybe you separate render progect from the splitter?

LoRd_MuldeR

19th June 2006, 23:02

Any news on the "player freezes for 15 sec on the start of playback" bug ???

Haali

19th June 2006, 23:29

Not yet. So far I couldn't reproduce this. If someone relibaly hits the bug, please contact me via pm.

mike_lee

20th June 2006, 12:15

haali renderer has become my default. video looks better and since I have a large (too large) monitor the resizing superiority really made a huge difference.

Good job man.

Esc

27th June 2006, 18:36

MPC 6.4.9.0 + Haali Renderer = black screen
Any video codec (tested with Divx and AVC)
NVidia GeForce FX 5200
WinXP SP2
Any ideas why?

Egh

27th June 2006, 20:31

MPC 6.4.9.0 + Haali Renderer = black screen
Any video codec (tested with Divx and AVC)
NVidia GeForce FX 5200
WinXP SP2
Any ideas why?

Sure you forced RGB32 output, comrade? Besides, FX5200 is way too low to really use Haali renderer. I have FX5500 here, and +15-20% OCed. Still software resizer works faster.

Sirber

27th June 2006, 23:08

haali renderer has become my default. video looks better and since I have a large (too large) monitor the resizing superiority really made a huge difference.

Good job man.is it better than WMR9 + Bicubic (-1.00, PS2)?

videomixer9

27th June 2006, 23:22

btw. is that some kind of making fun of it or why do you use WMR instead of VMR all the time? :P

Esc

28th June 2006, 00:13

Sure you forced RGB32 output, comrade? Besides, FX5200 is way too low to really use Haali renderer. I have FX5500 here, and +15-20% OCed. Still software resizer works faster.
Da, comrade. If by "force" you mean go to ffdshow and uncheck in "Supported Output Colorspaces" everything but RGB32 then yes, I did that. Didn't help. And I doubt it would since my avc content is played not with ffdshow but has the same problem.
Also I forgot to mention that Haali Splitter was downloaded and installed today. Twice. So it's the latest version for sure (1.6.162.22).
And I've got another comrade who has downloaded and installed CCCP (unlike me who always install things individually). He has the same problem. That's how it actually started. He asked me if Haali Renderer was working with me.
I'll try it home on my 6600GT.

foxyshadis

28th June 2006, 00:59

is it better than WMR9 + Bicubic (-1.00, PS2)?
Haali's is a drop-in replacement for VMR9. You can enable the same shaders as you can with VMR9 renderless.

Sirber

28th June 2006, 01:05

btw. is that some kind of making fun of it or why do you use WMR instead of VMR all the time? :Ptypo, nothing more.

Sirber

28th June 2006, 01:08

wierd...

Haali (-1) is sharper than VMR9 + Bicubic (-1)...

LoRd_MuldeR

28th June 2006, 01:48

is it better than WMR9 + Bicubic (-1.00, PS2)?

Well, for my eyes VMR9 Renderless Bicubic-Mode and Haali Renderer look pretty much the same. Can't say which one looks better. The Problem with VMR9 is, that it needs software YUV->RGB convertion while Haali Renderer displays YUV correctly here. But the problem with Haali is, that it feezes my system for aboz 15 secs each time I open a new video. And since I've tons of 4:00 minute vids on my HDD, that's really nasty. Hope it get's fixed one day...

Egh

28th June 2006, 13:33

Well, for my eyes VMR9 Renderless Bicubic-Mode and Haali Renderer look pretty much the same. Can't say which one looks better.

Well if you read all messages here you know that both those things were actually done by Haali :)

And note that VMR9 bicubic resize scripting is inferior to Haali renderer in terms of performance, due to constraint to use single-pass only in MPC at the time that script was done. I believe Gabest implemented support for 2-pass modes in MPC since then, but I rekon the script remains same :P

Sirber

28th June 2006, 13:52

I already read all messages ;)

but with the delay haali renderer is not useable :(

Esc

28th June 2006, 16:03

I agree that such a long open delay makes it quite less attractive.

breez

28th June 2006, 21:34

Is a newer renderer than the one bundled with Haali Splitter 1.6.162.22 (07/05/2006) available?

Sirber

28th June 2006, 21:58

don't think so, didn't have a new release for a while now.

LoRd_MuldeR

28th June 2006, 22:50

I plan to make a debug build in a couple of days, maybe we'll see where it waits so long.

Hope this will help to fix the freezing problem...

Sirber

28th June 2006, 23:11

it even jam iTunes... :confused:

mike_lee

6th July 2006, 14:27

It's not a delay or a freeze, it's buffering data like 10 billion other software apps. If you don't want to use a decoder that buffers that's OK (and I can see why you wouldn't if it takes your PC 15 seconds to buffer 16 megs)

Haali

6th July 2006, 19:14

No, buffering doesn't happen until you start playback. And the delay (on a few systems) occurs before that, when the graph is created.

mike_lee

8th July 2006, 10:49

I'm sure I posted an apology but I don't see it. So I'm sorry for smarting off LoRd_MuldeR.

LoRd_MuldeR

8th July 2006, 11:02

00000000 0.00000000 [3600] ACM DRV_OPEN 11 0019A3C0
00000001 0.00012404 [3600] ACM ACMDM_DRIVER_DETAILS 11 0019A3C0
00000002 0.00015812 [3600] ACM ACMDM_FORMATTAG_DETAILS 11 0019A3C0
00000003 0.00019807 [3600] ACM ACMDM_FORMATTAG_DETAILS 11 0019A3C0
00000004 0.00028104 [3600] ACM ACMDM_DRIVER_ABOUT 11 0019A3C0
00000005 0.00107444 [3600] ACM ACMDM_FORMATTAG_DETAILS 11 0019A3C0
00000006 0.10823023 [3600] ACM DRV_CLOSE 11 0019A3C0
00000007 5.79527950 [3600] REN: CDXR created 02A52220
00000008 6.33728600 [3600] REN: Pause
00000009 6.33743763 [3600] REN: Commit
00000010 6.33747149 [3600] REN: InitAll
00000011 6.37628746 [3600] REN: Commit
00000012 6.37633419 [3600] REN: D3DI 1
00000013 6.39212847 [3600] REN: D3DI 2
00000014 6.39222336 [3600] REN: D3DI 3
00000015 6.39535093 [3600] REN: D3DI 4
00000016 6.39556217 [3600] REN: D3DI 5
00000017 6.40449286 [3600] REN: D3DI 6
00000018 6.40476370 [3600] REN: D3DI 7
00000019 6.40480375 [3600] REN: D3DI 8
00000020 6.40492916 [3600] REN: D3DA 1
00000021 6.40563822 [3600] REN: D3DA 2
00000022 6.40578270 [3600] REN: D3DA 3
00000023 6.40660095 [3600] REN: D3DA 4
00000024 6.40666437 [3600] REN: D3DA 5
00000025 6.40789604 [3600] REN: D3DA 6
00000026 6.40794277 [3600] REN: D3DA 8
00000027 6.41301060 [3600] REN: Allocated 34 buffers
00000028 6.41313028 [3600] REN: D3DA 9
00000029 6.89275026 [3600] REN: MT
00000030 6.89533567 [3600] REN: Present. (NextSample)
00000031 6.90694046 [3600] REN: Run
00000032 6.90735769 [3600] REN: Present. (PaintCur)
00000033 6.90764570 [3600] REN: No image in backbuffer for presentation. (ShowSample)
00000034 6.91077232 [3848] 114307745 has capabilities; 0
00000035 18.33591080 [3600] REN: Present. (PaintCur)
00000036 18.33595276 [3600] REN: Pause
00000037 18.34675789 [3600] REN: Commit
00000038 18.34683609 [3600] REN: InitAll
00000039 18.34687042 [3600] REN: BeginFlush
00000040 18.34701347 [3600] REN: Decommit
00000041 18.34709167 [3600] REN: DiscardInput
00000042 18.34726524 [3600] REN: DiscardVQ
00000043 18.34730148 [3600] REN: EndFlush
00000044 18.34749222 [3600] REN: Commit
00000045 18.34758949 [3600] REN: Run
00000046 18.34762001 [3600] REN: Pause
00000047 18.34873390 [3600] REN: Commit
00000048 18.34881210 [3600] REN: InitAll
00000049 18.34884644 [3600] REN: Stop
00000050 18.34905434 [3600] REN: Decommit
00000051 18.34908867 [3600] REN: DiscardInput
00000052 18.34927559 [3600] REN: Decommit
00000053 18.34929466 [3600] REN: DiscardVQ
00000054 18.36106682 [3600] REN: Present. (PaintCur)
00000055 36.12074661 [3848] 91012485 has capabilities; 32505856
00000056 36.61196518 [3848] 91012485 has capabilities; 32505856

So it doesn't happen during the init phase. too bad.

3ngel

8th July 2006, 12:00

Installed latest Haali Splitter.
The problem in the initial ENORMOUS amout of time to start playback it's still here. It's a pity 'cause i think this is a fundamental things that prevents most of us from even only *testing* this renderer ('cause it's obviously unusable in real contexts due to the unacceptable initial delay).
Tested with ATI X800.

Sirber

8th July 2006, 13:39

reported already many many times ;)

anonymez

26th July 2006, 03:34

been having a problem since first or second release; when i try to seek while playing a dvd, video stops and mpc becomes unresponsive. works fine with overlay/vmr. tried different video & audio decoders, dscaler, intervideo and mpc's internal. playing the individual VOBs works fine, as do all other files.

since i don't think it's been mentioned before, can anyone reproduce it? a decrypted dvd will do, so long as you play the video_ts.ifo :)

B.F.

26th July 2006, 06:00

anonymez

26th July 2006, 06:33

thanks, thought it was just me (and 3 of my PC's) :)

rig_veda

8th August 2006, 00:33

Tested the renderer that came with the 2006-07-07 splitter on a 2.8Ghz Northwood with hyperthreading and Geforce5700FX. I didn't have any delays of the sort people described.
CPU utilisation is considerably higher than when using overlay or vmr9. I initially had hoped that doing the YUY2->RGB conversion on the GPU instead of YV12->RGB on the CPU via ffdshow, would give me more free CPU cycles, but it seems the other way around on my hardware.

Anyway, what I'd like to ask Haali: how exact is the YUY2->RGB conversion done by the ps2 code? Is it identical in precision to AviSynth's ConvertToRGB or ffdshow's high quality mode? Haali Renderer definitely looks better than GeForce5700FX's hardware conversion (e.g. less banding in gradients), just like AviSynth and ffdshow do.

Sirber

11th August 2006, 15:32

Still having the delay, X800XL AGP.

MacAddict

11th August 2006, 16:47

Anxious to try this out! Anyone know if my 9700 Pro would provide acceptable performance? I've seen a few in this thread with a 9800.

Seb.26

12th August 2006, 15:44

[solved]

Where picture properties (Brightness/Contrast/Hue/Gamma) can be set for using Haalli render ???
Is it same as overlay setup in panel control ?!
... Or is it in DirectX ???
( I've got NVidia 6600GT - Fw 91.31 WHQL )

Thanks for the help . :)

[Edit]
Thanks to KoD : the setup can be done in DirectX Panel control ( Haali use Direct3D to render frames )
:)

KoD

13th August 2006, 10:54

I have a Radeon 9700 Pro and I can tell you that it's faster than using bicubic software resize in ffdshow.

There will be a few quirks, though:

- higher playback start-up time
- when you pause or skip back/forward you may loose video-to-audio synch. This is solved by simply pausing the video again and/or skipping even further back or forward and then letting it play again.
- force output to RGB32 in all your video decoders (easy to set this in ffdshow and coreavc); YUY2 output involves too much processing for the pixel shaders on a Radeon 9700 Pro and you'll have high kernel cpu loads
- sometimes you'll notice jerky pans and tearing. Enabling "Lock back-buffer before presenting" in MPC will cure this most of the time when using MPC to view your video files. You'll also have to disable the "SoftLock" option in Haali's renderer otherwise it won't work.

MacAddict

13th August 2006, 20:28

Thanks for the information. I've just installed the 9700 today in my HTPC and using this render I have to say the image quality is excellent. I'm using the max sharpness setting along with RGB32. The A64 3200 is easily playing back my movies hovering around 50% of usage. I only experience about a 2 second delay on startup, not a big problem at all.

Any suggestions which video drivers provide all around better image quality and performance with Haali's renderer?

KoD

13th August 2006, 22:41

All video drivers are the same. Just don't force antialiasing by default in them. Leave it to "application preference".

As for Seb.26, Haali's renderer has no Brightness/Contrast/Hue/Gamma controls. But you can just use your video card drivers settings for Brightness/Contrast/Hue/Gamma for Direct3D (if nvidia drivers have something like that). If not, use a third party application like Powerstrip that allows you to alter the LUT table. I don't have a nvidia card, so I don't know of any free app that can do this for a nvidia card, but they might exist, so ask around.

Seb.26

17th August 2006, 12:34

Haali

17th August 2006, 21:17

SeeMoreDigital

17th August 2006, 21:28

Hi Haali,

May I as what the most up-to-date version is of your splitter is that can handle MPEG-4 AVC within TS... And where it can be obtained.

I would like to try it with some of the new MBAFF compatible vesions of FFdshow ;)

mariner

18th August 2006, 06:12

Hi Haali,

Greetings and thank you for the excellent spltter and renderer.

Have been using the renderer in mpc for a while now, but could not get it to display 1920x1080 when playing HD .ts files. The display window stays at somethins like 640x480. Any assistance would be most appreciated.

Thank you and best regards.

ernesto

Seb.26

18th August 2006, 09:48

Seb.26 Resizing and colorspace conversion is slower on older hardware, gf6800 or better have no problems with it. And slow startup happens rarely, I've been unable to identify the issue so far since I don't have problematic hardware and can't reproduce it.
OK, I've 6600GT and A64@2.4GHz ... faster to use CPU or GPU ???

-> For the delay, I will make serious tests and report results ...

Haali

18th August 2006, 20:16

Have been using the renderer in mpc for a while now, but could not get it to display 1920x1080 when playing HD .ts files. The display window stays at somethins like 640x480. Any assistance would be most appreciated.

The initial size is lowered to fit the screen because I hate windows that needlessly span beyond the screen edges. You can still resize the video to whatever size you like.

mariner

21st August 2006, 10:22

Hi Haali, thanks for the reply.

I use a 1920x1200 screen for 1080 .ts files playback, with mpc set to 100% zoom to avoid any scaling artifacts. When Haali renderer is used, the initial window size is about 640x480, and stays the same if I enaged full screen. Is this the expected behaviour, and how to get a 1902x1080 window ?

A related question : are there plans to implement the "full screen exclusive mode" , which some claim to speed up performance?

Thanks and best regards.

dumbuser

22nd August 2006, 06:18

Have been using the Haali splitter now for some time and look for updates quite regularly. I do appreciate the work here and the concepts brought to life. :D

I would like to ask the dumb question though! Is there any plan to support the old QuickTime ASP MP4?

I can make them or download them and it works fine in QT but have never been able to play them using your front end.

Have checked this with Graph edit, it just will not open. Nero works as well as 3ivx of coarse. No it isn't a conflict as I have never had all of these installed at the same time and as I said, I have and use Graph edit.

Thanks!

mike_lee

22nd August 2006, 18:21

I have a question ( maybe a stupid one ) :

Why use Haali render ?!
> If resizing is slower than pure CPU one ( FFDShow )
> If it's adding a delay before first frame display ( about 7s for me )

PS: thanks a lot KoD for your answer ;)

I have a large LCD screen, haali re-sizes much, much netter then ffdshow and it's automatic (You choose bi-cubic in MPC-output) although I have no idea why it enlarges when I didn't specify the size anywhere, it just doubles the size on most clips. I keep a different MPC version in my windows tray which is set to VMR9 for when I need shaders. The coloring is somewhat better with haali as well. But the settings are cryptic, I have no idea where to set the sharpness slider, I'm a "soften" kind of guy and sharpening bugs the hell out of me. -0.00 is impossible isn't it? ::ribs Haali:: Also not sure what soft vsync does but I have it checked.

Seb.26

23rd August 2006, 09:34

I have a large LCD screen, haali re-sizes much, much netter then ffdshow and it's automatic (You choose bi-cubic in MPC-output) although I have no idea why it enlarges when I didn't specify the size anywhere, it just doubles the size on most clips. I keep a different MPC version in my windows tray which is set to VMR9 for when I need shaders. The coloring is somewhat better with haali as well. But the settings are cryptic, I have no idea where to set the sharpness slider, I'm a "soften" kind of guy and sharpening bugs the hell out of me. -0.00 is impossible isn't it? ::ribs Haali:: Also not sure what soft vsync does but I have it checked.
Have you really try FFDShow ?! ( with Lanczos ) ...
Because Halli can't be better ... FFDShow can use Lanczos or Bicubic ( like Haalli ) ... done in software ... but with RGB32 output with HQ 16..235 mapping correction ... :rolleyes:

Halli is a great output filter, but for the moment, it's too young for me : about 7s before starting ( with the minimum buffer ?! where does this CPU time go ??? ) ... some problem with pause and seek ... And Haalli use more CPU than FFDShow+Overlay for me ( 2.4 GHz A64 CPU with 6600GT GPU ) ...

But I'm waiting the next version to see what have change ... :D

foxyshadis

23rd August 2006, 19:39

I have a large LCD screen, haali re-sizes much, much netter then ffdshow and it's automatic (You choose bi-cubic in MPC-output) although I have no idea why it enlarges when I didn't specify the size anywhere, it just doubles the size on most clips. I keep a different MPC version in my windows tray which is set to VMR9 for when I need shaders. The coloring is somewhat better with haali as well. But the settings are cryptic, I have no idea where to set the sharpness slider, I'm a "soften" kind of guy and sharpening bugs the hell out of me. -0.00 is impossible isn't it? ::ribs Haali:: Also not sure what soft vsync does but I have it checked.
VSync keeps tearing down, at the cost of occasionally dropping frames if the decoder isn't fast enough.

It only enlarges below 600x400 or so, because who wants to watch a 320x240 window on a 1600x1200 screen? Same deal with 1920x1080 video, it sizes down. But it only resizes once in fullscreen no matter what the output size in windowed mode is.

Seb.26

24th August 2006, 09:49

VSync keeps tearing down, at the cost of occasionally dropping frames if the decoder isn't fast enough.
With Haali's render (thanks to the buffer in the graphic card) you can't have dropped frame due to the decoder speed on bitrate peak ...

For exemple with DVD : 720*480 in RGB32 -> 1350KB per frame in GC RAM -> about 50 frames (with 64MB buffer) -> more than 1 seconds buffered ... without any cropping before render ...

This is really the big good point for Haali ( IMO of course ) ...
... But the resizing method in Haali is also really good and simple for them who don't like FFDShow ...

Does anybody have an idea for the next version released ???

foxyshadis

24th August 2006, 19:27

That doesn't help if you're pushing the system so hard you still run out of buffer.

Something I'm curious about: Who controls dropping frames? The decoder, the renderer, or something else? I can't seem to force slowdowns to become framedrops anymore, which is irritating - I'd much rather drop frames occasionally than end up with a video permenently out of sync after the problem point.

Seb.26

25th August 2006, 12:02

That doesn't help if you're pushing the system so hard you still run out of buffer.
Yes, but in this case, your system can't play the movies ...

[DeliriumMode=true]
... or imagine a buffer about 1h frames ... that take about 2h to fill ...
... your can watch 1h30 of your film without any dropped frame ... but your system is about 50% 'to small' to play this ...
... But this have non-sens, buffer cost is about 2.3GB per minute in 720*480(32b)@30fps ... !!! ... maybe a day with
[DeliriumMode=false]

Something I'm curious about: Who controls dropping frames?
+10000

Why sometimes, the CPU is clear ( about 30% for DVD without PostProcessing ), the RAM is OK ( 1GB ), all is ok, but a frame is dropped ... or a frame have tearing ...

Why ?

With Halli's Render, I hope this will "the past" ... because with a lot of frames in Graphic RAM I hope video will playback without any dropped frame ... :D

Isochroma

25th August 2006, 19:47

Notes:

1. Using Haali's MKV splitter (with MKV sourcefile), the control item under Filters named "Haali's Video Renderer" is not shown when ffdshow outputs YV12. Other pixel formats result in its visibility. However, any formats other than YV12 are impossibly slow to render (no problems here with other MPC modes).

2. "Load Subtitles" option in context-menu is grayed out when using Haali's Renderer (using MKV sourcefile without subtitles). Also, since rendering is impossibly slow in anything else but YV12, I cannot play any softsubbed files using this renderer, because MPC refuses YV12 connections when subtitles are present. Gabest, please fix MPC!

Hardware is OC'd Athlon XP (2333 MHz.) AGP8X FX5200 (128 MB) on ASUS A8V8X MB, 2.5 GB RAM.

KoD

25th August 2006, 21:50

Notes to Isochroma:

- if you would take the time to read the thread from the beginning, you would see that Haali's renderer accepts YUY2 or RGB32 input by default and does not accept YV12. Something must perform the conversion to YUY2 or RGB32 for the renderer to be used, preferably the video decoder itself.

- Haali's renderer uses PS 2.0 shaders to perform its magic. In case of YUY2 input, the shaders are even longer and use your gfx card even more. And all FX5xxx Nvidia series are known to have poor shader performance. It was a big case back when the cards appeared. So, force RGB32 output in your video decoder and if that is not enough then your system is just not powerful enough to use this renderer.

Isochroma

25th August 2006, 23:13

Sorry, but YV12 works fine here. All other modes run at 1/2 framerate. Theory and practice are two different creatures entirely.

foxyshadis

26th August 2006, 07:10

Sounds like your FX5200 just can't handle Haali's - if it isn't in the filter list then you aren't using it, it falls back on VMR9 or overlay instead when YV12 is used. Evidenced by its dismal performance when it is used. The performance on mine with YUY2, YV12, or RGB32 are all pretty close, the conversion probably takes practically no time, it's the filter itself that sucks up speed.

Yes, but in this case, your system can't play the movies ...
Well, I meant for long enough to overtake the buffer, which is only second or less of HD AVC bitrate spike to bleed it dry. Not to say it won't help, it certainly will.

On the other hand, I just set it to 256M, because I have more than enough memory. =p I wouldn't mind a 1G buffer if it used it smartly!

dumbuser

26th August 2006, 21:20

The Haali splitter version 1.6.224.23 thumbs renderer crashes Windows Explorer (XP SP2) when new videos are added to the folder. The prior version 1.6.162.22 did not do this. Until this can be resolved I have had to revert to the older version.

On a positive note the MPEG TS/TP front end is working well. Is there a possibility for h.264 support in a MPEG TS/TP in the future?

FYI I have resolved the MP4 ASP problem. Is seems that when uninstalling one of the MP4 decoders it did not give back control to XviD or DivX until a reinstall of either of these. While XviD or DivX does not have this problem 3ivx does. Sorry to imply the problem may be yours. :)

Update: The problem occurs when adding a 25 FPS video to an existing folder. If you want to induce the problem erase the thumbs.db and enter and exit the folder a few times.

Also I would like to note that I have never been able to use OGG because the thumbs renderer will crash for some OGG/OGM files OGMs in particular made with the original Tobias encoder. Installing and using that filter set does not display the same problem for any OGG/OGM file and thumbs do render properly.

clsid

26th August 2006, 23:29

It already supports H.264 in TS.

Seb.26

28th August 2006, 18:45

On the other hand, I just set it to 256M, because I have more than enough memory. =p I wouldn't mind a 1G buffer if it used it smartly!
You have 512MB of CG RAM ?!!! ... :eek:

Whaoo ... With my little 128MB, I already think it's too much ...
... 256MB of RAM = 1 second buffer lenght ( 1900*1080*32b@30fps ) ... if with that you can't have smooth playback, you will never have !!! :p :D

Have fun,
Seb

PS: with this biffer size, how many seconds have you to wait before playback start ?! :confused:

PPS: anybody know something about next public release of Haali's Render ??? ( Project still running ?! )

Isochroma

28th August 2006, 20:08

Bug: Using the latest Haali renderer and MPC, when the numpad 8 & 2 are used for expanding/shrinking the video vertically, using normal rendering modes this works fine. But the HR resizes the entire video frame horizontally as well as vertically, when it should only be changing the vertical size. Probably happens for the 'horizontal only' MPC options too.

dumbuser

29th August 2006, 04:15

It already supports H.264 in TS.

Using whos decoder filter?

Not Nero, Ateme or CoreAVC! But it does do MPEG quite well! :D

chros

29th August 2006, 10:38

Seb.26

29th August 2006, 11:28

Something I'm curious about: Who controls dropping frames? The decoder, the renderer, or something else? I can't seem to force slowdowns to become framedrops anymore, which is irritating - I'd much rather drop frames occasionally than end up with a video permenently out of sync after the problem point.
Have you try Reclock audio render ?!
... if not ... it could be a big step 4 U ... :D

And also try 91.47 forceware (from 3d Guru), they are ... amazing
( great ones ! ;) )

clsid

29th August 2006, 13:30

Using whos decoder filter?

Not Nero, Ateme or CoreAVC! But it does do MPEG quite well! :D
Haali's splitter is bundled with CoreAVC and it works fine on most H.264 TS files for me.

Maybe this is your problem:Warning: TS files with missing PAT/PMT tables are not supported.

dumbuser

30th August 2006, 23:28

Haali's splitter is bundled with CoreAVC and it works fine on most H.264 TS files for me.

Maybe this is your problem:

I did notice the bundling of Haali with CoreAVC but already had the latest version. Is there something special about the bundled version. If so isn't this going to get rather confusing next time anyone updates Haali?

The problem is not PAT/PMT.

dumbuser

4th September 2006, 03:01

It already supports H.264 in TS.

I tried! And you are correct in that there are two versions. The one that is packed with CoreAVC is older than the latest public release and works slightly worse. However neither one of these supports H.264 in a MPEG TS container. I would suggest either uninstalling Gabest's mpegsplitter (if installed) or shutting it down in MPC if that's what your using to judge this.

Unfortunately I have been forced to go back to an earlier version because the thumbs render crashes Explorer when 25 FPS videos are added to the video folder. The same thing happens with OGM files made with the Tobias filters. So the MPEG TS thing will have to wait until Haali gets fixed.

clsid

4th September 2006, 13:39

I am using the latest version and it works fine on for example "BBC_H264_test6.ts" in combination with CoreAVC 1.1. PM Haali himself if you don't believe me. It may not work on all TS files. It is still in early development. I prefer Gabest splitter too atm.

molitar

6th September 2006, 00:00

Tried Haali and not for me. It breaks the secondary output to full screen. Otherwise it worked alright so I went back to vmr9.

oddball

6th September 2006, 01:08

Haali is giving me problems playing back Transport Streams (.TS). Some it will play and fast seek just fine whilst others it will balk at. When it refuses to work I get a blank screen and it just stays stuck with an incorrect playback length displayed. Using Zoom Player 5 preview. I have tried running the .TS files through MPEG2Repair and it makes no difference. I understand that Haali does not support .TS files with invalid PAT/PMT. Is there any way to check if the files I have contain it and any way to fix it?

EDIT: I split a 4.3GB file into 700 meg chunks and the 3rd split part gave me the same problems. Again running it through MPEG2Repair did not fix it enough to playback. After opening it in Avidemux and saving that part with direct stream copy it would then playback using Haali. However the AC3 audio was several hundred milliseconds out of sync. Going to try joining the two main large .TS files together using TSplitter and then run the entire thing through Avidemux to see what happens. I may have to correct for audio sync and then resplit it later.

SeeMoreDigital

6th September 2006, 09:06

Hi Oddball,

Out of interest.... Is there any particular reason why you want to keep your files as .TS streams?

By the time you've run them thru' MPEG2 Repair you might as well have run them thru' HDTVtoMPEG2 and re-muxed the streams into the .MPG container....

Just a thought!

oddball

6th September 2006, 12:22

I tried running it through HDTV2MPEG and it keeps splitting the files into 1GB chunks whereas I want to keep it in one big file. I could not playback the chunks either.

EDIT: In the end I just ran it through Avidemux and set the audio sync to -500 which seems close enough. There are flaws in this rip anyhow such as telecine 'bounce' (Image moves up and down where the telecine machine is not set correctly. Either that or the source film was problematic). I won't go into more detail than that due to this boards rules. Thanks for the suggestions though even if they did not help much.

chros

17th September 2006, 12:21

I don't know if it was mentioned: this renderer mess up the display AR on anamorphic mp4-s. No problem with Overlay or WRM9 renderless.

Seb.26

18th September 2006, 11:39

I don't know if it was mentioned: this renderer mess up the display AR on anamorphic mp4-s. No problem with Overlay or WRM9 renderless.
+1 ... same problem with anamoprhic video ... numeric key '2' in MPC is usefull ... ;)

Seb.26

18th September 2006, 11:41

An idea of new feature : An option to display some informations about the buffer, to detect underflow for exemple ... this could be usefull, not ?

chros

18th September 2006, 13:33

+1 ... same problem with anamoprhic video ... numeric key '2' in MPC is usefull ... ;)
I know this, but a bug is a bug ... :)

MaXi_TK96

3rd October 2006, 20:14

I am having a specific subtitle problem with Haali renderer, the same subtitles are displaying twice: once in the actual picture frame and then outside of it (as much bigger here). I am using MPC (Haali renderer) with Haali splitter and DirectVobSub. If I disable sub showing from DirectVobSub then both subs will be gone. This behaviour seems to be depending on the subtitle type, ASS subtitles are being displayed twice but not SRT subs. Is there some setting I am missing or is this about something else ?

foxyshadis

3rd October 2006, 21:31

MaXi_TK96

4th October 2006, 08:05

This only happens with Haali, and not VMR9? If both, it sounds more like an MPC & DirectVobSub interaction problem. A bit odd to use them together with a DX9 renderer anyway, since MPC internally already has exactly the same code as directvobsub; normally it'd be used in overlay or other players.

Okay, I feel so stupid here: this was all due to MPC's subtitling engine starting to work when using Haali renderer or VMR9. I though I had disabled MPC's subtitling engine from the options menu but apparently it needs to be disabled from playback menu too. Now working as I wanted. As far as the renderer goes I was surprised about how good the output was. If only files would start playing faster... still great work!

Kador

7th October 2006, 15:41

Hi, why is it tv-scale only ???

Haali

7th October 2006, 19:08

Hi, why is it tv-scale only ???
Because I don't have any PC-scale files.

foxyshadis

7th October 2006, 23:58

That's odd, it's always PC-scale for me, I usually run a levels beforehand if I need to.

breez

8th October 2006, 00:05

PC scale for me too. I suggest adding an option TV-scale/PC-scale though.

Haali

8th October 2006, 01:42

Just to make sure I'm not confusing things, TV scale usually means 16-235 Y levels, and that's what is usually used on DVDs and stuff like that. Are you saying that your files that use the full 0-255 range? In that case you can simply use VMR9 as its default behaviour was to use the full range. One of the reasons I've made this renderer was to correct the levels problem.

foxyshadis

8th October 2006, 01:57

Yeah, on my ATI X1400 system it decodes 0-255->0-255. VMR9 has the same behavior. It's been this way through several driver revisions. I don't mind it this way.

anonymez

8th October 2006, 02:01

in addition to post #160. this one is with 1440x1080 mpeg2 streams, i just get a black screen and MPC locks up. link to a small (4mb) sample below to save you the trouble

http://www.sendspace.com/file/cb9hp1

a few observations to cancel a few things out:

-works fine in overlay & vmr
-1920x1080 mpeg2 streams play fine
-xvid stream at the same res, 1440x1080 plays too
-container and audio makes no difference, tried ts/ps/es
-tried different splitters/decoders
-tried on two different systems, each with decent graphics cards (ati X800XL & nvidia 7900GT)

Seb.26

9th October 2006, 13:10

Egh

9th October 2006, 14:31

Are you saying that your render do the 16..235 -> 0..255 re-scale ?! :scared:

And what happen if the source is RGB32 ? ...

well incoming *RGB32* is not a problem per se, since it's not a luma-chroma type of colorspace even.

The problem might actually arise if YV12 received by the renderer has been already converted to 0..255 range.

Some scenarios this might happen:

Video is decoded by CoreAVC and VMR9 correction is on
h264 is decoded by ffdshow but the video is inherently fullrange.

LOL, it seems this topic becomes an epidemic :) Note that I suspect ffdshow doesn't do proper conversion to RGB32 if video is already in fullrange. See here for some discussion on that topic: http://forum.doom9.org/showthread.php?p=884562#post884562

Haali

9th October 2006, 17:45

Are you saying that your render do the 16..235 -> 0..255 re-scale ?! :scared:

Yes, it does.

And what happen if the source is RGB32 ? ...

RGB32 is not scaled.

foxyshadis

9th October 2006, 19:12

The problem might actually arise if YV12 received by the renderer has been already converted to 0..255 range.
YUY2, you mean. And yeah, seems to be the longest running fountain of confusion, but at least it's getting better over time.

Haali, does your renderer send out Quality messages? I'm trying to capture them (in ffdshow) but haven't been successful so far; but then again, I haven't been able to pick up vmr9's either so I may be doing it wrong somehow.

Edit: Oh, it's working in VMR9 now, but it seems none are being sent from yours.

Haali

9th October 2006, 19:46

YUY2, you mean. And yeah, seems to be the longest running fountain of confusion, but at least it's getting better over time.

Haali, does your renderer send out Quality messages? I'm trying to capture them (in ffdshow) but haven't been successful so far; but then again, I haven't been able to pick up vmr9's either so I may be doing it wrong somehow.

Edit: Oh, it's working in VMR9 now, but it seems none are being sent from yours.
The result was always much uglier with the messages enabled (e.g. ffdshow would stop decoding for half a minute under some circumstances), so I disabled them. Maybe I'll add an option to turn them on in preferences.

foxyshadis

9th October 2006, 20:43

I'm trying to fix ffdshow's QoS handling now, I thought I was going batty until I got it working with VMR9. =p Even if it's just a reg hack for now, I'd like to be able to work with it. Thanks.

Peuj

10th October 2006, 13:47

Something I don't get:

Ok Haali Renderer only supports colorspaces RGB32 and YUY2 and always does TV-scale-> PC-scale conversion.

So is this renderer only useful to watch videos on a PC ?
If I want to watch a movie on my TV I need PC-scale-> TV-scale, no ?
Usually I get a best image on my TV with WMR9 and YV12 and on my PC with WMR9 and RGB32.

For information, most of my videos are YV12, so to be able to use Haali Renderer I need to set the output colorspace with ffdshow to YUY2 or RGB32. But on my computer, set the output colorspace to YUY2 + Haali Renderer takes really too much CPU (more than RGB32 + HQ) and the video lags a lot , so I can only use RGB32 with Haali Renderer.
I don't have this problem with WRM9 + YUY2.

My config:
Number of cores 1
Number of threads 2 (max 2)
Name Intel Pentium 4
Codename Prescott
Specification Intel(R) Pentium(R) 4 CPU 3.40GHz
Package Socket 478 mPGA (platform ID = 2h)
CPUID F.3.4
Extended CPUID F.3
Core Stepping D0
Technology 90 nm
Core Speed 3400.1 MHz (17.0 x 200.0 MHz)
Rated Bus speed 800.0 MHz
Stock frequency 3400 MHz
Instructions sets MMX, SSE, SSE2, SSE3

Thanks

Egh

10th October 2006, 15:10

Peuj

10th October 2006, 15:22

You hardly need Haali renderer to watch videos on TV imo. As for VMR9+YV12 vs VMR9+RGB32, you can try enabling range correction in ffdshow (either with Levels or avs filter ColorYUV(levels="TV->PC"). See what better looks on your screen.

Ok thanks I will try that but just to be sure I understand:
I have a TV-scale video, Haali Renderer will re-scale it to PC-scale and then I do a range correction to re-scale to TV-scale. :confused:

If input space is YUY2 then Haali renderer does require more CPU, it is not a bug, it's a known feature :)
:D

Seb.26

10th October 2006, 17:14

Yes, it does.
RGB32 is not scaled.
Ok, all is perfect for me about ColorSpace ... thanks a lot ! :)

PS: Have you think about creating a debug version of your render ? ... with a lot of debug trace in ASCII file ...
... I'm ok to run it on my system for helping you to understand why some users (I'm in) have black screen for more than 10s before playback start ... ;)

chros

10th October 2006, 20:54

Is there out any docs or tutorial about the colorspaces (not specs, but user-friendly guides) ?
I don't get anything at all about what you're talking about ... :)

Egh

11th October 2006, 18:58

Is there out any docs or tutorial about the colorspaces (not specs, but user-friendly guides) ?
I don't get anything at all about what you're talking about ... :)

http://en.wikipedia.org/wiki/YUV ftw:P
http://en.wikipedia.org/wiki/RGB_color_model
http://www.fourcc.org/fccyvrgb.php

concerning the signal used for digital television see
http://www.stewe.org/itu-recs/bt601.pdf#search=%22ITU-R%20BT.601-5%22

:search:

Eretria-chan

13th October 2006, 16:24

Whenever I use Haali's Renderer and Reclock DirectShow filter to play Sonic X sources (other sources seem to work fine with both filters enabled for playback), I get "floating point overflow" message. There appears to be a conflict between these on this source...
If I don't use Reclock, it works fine (only Haali). If I only use Reclock (not Haali), it works fine.
Aside from that, it also seems that Haali's rendered seems to get the aspect ratio all wrong.

But hey, aside from that, Haali is pretty much the only video renderer that works good on Vista!

This is using Zoom Player, btw.

Haali

13th October 2006, 20:17

Does anyone have a sample with wrong AR? All my files play with correct AR.

Eretria-chan

15th October 2006, 00:58

A little update...
The wrong aspect ratio was gotten if used with "Source." However, if I do select "Derived," it's fine.
But the rendered is also somewhat unstable. If paused for too long, it won't resume (it won't display the video but the audio will continue). When trying to play a new file (when playing a file), the player stops reponding.
Oh and when using the rendered it seems to like to "unhide" the mouse pointer. It tends to disappear whem Zoom Player (I take it is the player?) hides it, but then it appears right again.

All of this doesn't happen with other renderers.
Again, Zoom Player & Vista RC1 (x64).

cc979

17th October 2006, 23:38

just found weird bug, using ffdshow_rev404_20061017_clsid.exe and mplayerc.rev611-2.2kxp.7z

this mov/svq3 plays fine using the internal mp4/mov parser on mpc but plays very jumpy with haali splitter 07/07/2006

http://files.filefront.com/Ridge+Racer+7+TGS+06+Trailer/;6029161;/fileinfo.html

foxyshadis

18th October 2006, 01:20

SVQ3 doesn't work with haali's splitter, it's a known issue. The splitter doesn't include some data structure, haruhiko_yamagata knows a lot more about it and could provide details.

cc979

18th October 2006, 22:09

SVQ3 doesn't work with haali's splitter, it's a known issue. The splitter doesn't include some data structure, haruhiko_yamagata knows a lot more about it and could provide details.

it must be some time stamp thing or something as there was no corruption or crash just weird jumpy video

cheers anyway

Haali

18th October 2006, 23:05

SVQ3 doesn't work with haali's splitter, it's a known issue. The splitter doesn't include some data structure, haruhiko_yamagata knows a lot more about it and could provide details.
Do you have a sample that doesn't work? The ones in my collection play fine.

Seb.26

19th October 2006, 10:02

Does anyone have a sample with wrong AR? All my files play with correct AR.
I will prepare one for you this evening after job ...
... It will ok for tomorrow ... ;)

[Edit 19/10/06] I've upload a small file ( 3.4MB ) ... maybe someone can test it ...

http://membres.lycos.fr/sebfr26/Haali/Sample.mkv
( Universal intro )

Else, it's a 720*432 video with a display size of 1024*432 ( it's an anamorphic PAL DVD with top/bottom crop ... )

In any case, I will test it this evening at home ... an report if sample work or not with Haali's render ...
( I have test it with MPC and VMR9 : it's ok ... )

[Edit 20/10/06] I've done some tests yesterday, and I can't reproduce the Aspect Ratio bug ...
... I will try more this WE ... maybe the bug wasn't in the render ... I don't understand ...

[Edit 24/10/2006] Sometimes, Halli's render lost the aspect ratio, this happen with MPEG2 (DVD) by trying a jump ...

cc979

19th October 2006, 12:34

Do you have a sample that doesn't work? The ones in my collection play fine.

this one here
http://files.filefront.com/Ridge+Racer+7+TGS+06+Trailer/;6029161;/fileinfo.html

does not play correctly

ChronoReverse

23rd October 2006, 02:25

This is probably the wrong place to ask but I'll try anyways.

What would cause opening files while one is already open to be slow? For example, if I open video1.mkv in Zoomplayer or MPC, then open video2.mkv, it invariably takes a long to for it to come up and it may even crash. This seems to only occur with MKV and not MP4 (I don't use Haali for AVI).

Seb.26

23rd October 2006, 10:33

This is probably the wrong place to ask but I'll try anyways.
What would cause opening files while one is already open to be slow? For example, if I open video1.mkv in Zoomplayer or MPC, then open video2.mkv, it invariably takes a long to for it to come up and it may even crash. This seems to only occur with MKV and not MP4 (I don't use Haali for AVI).
You are speaking about Haali demuxer ( Matroska splitter ) or about Haali's render ?!
( this post is for render :D )

chros

23rd October 2006, 21:10

Do you have a sample that doesn't work? The ones in my collection play fine.
Or this one (and a tons of one :) ): alien-resurrection-trailer-640.mov (http://www.movie-list.net/classics/alien-resurrection-trailer-640.mov)

Seb.26

24th October 2006, 11:10

What can be done to disable tearing with Haali's render ? ... I use :
> MPC
>> DScaler( out=YV12 )
>>> FDShow( just out=RGB32-HQ )
>>>> Reclock
>>>>> Haali's render

And there is a lot of tearing, just on the middle of the screen :scared:

... a little tech question : how could I have tearing since D3D vSync is forced in NVidia properties ?! ... The render don't use D3D ?! ...

In my mind, the render take a frame from directshow, copy it in GPU ram as a texture or something like that ... draw the texture on backbuffer with the resize shaders, swap buffer on vsync ...etc...

Another point : the buffer is used to store "input frames" ( ie: 640*480 ) or "output frames" ( ie: 1280*720 ) ...

Is it possible to have a look on source code ? :D

;)

KoD

27th October 2006, 22:19

This is what I do:
- in MPC "Lock back-buffer before presenting" is enabled
- in Haali's video renderer filter options "Soft Vsync" is disabled.

ExtraEye

29th October 2006, 19:15

Sorry for asking something that is probably answered here somehow... Though I did look through the pages of this thread and couldn't completely understand.

I use Zoom player along with ffdshow usually (outputting to RGB32 -HQ conversion) and the renderer VMR9 to view videos on a television screen (wide screen). My sources are mainly fansubs (which are mainly encoded in xvid or h264). My graphics card is Geforce 6600GT.
I tried using Halli's renderer and it worked nicely (I changed the settings to max sharpness and it was nice ^^) but it took long to load videos - normally it's done instantly and now it took about 10 seconds.

I don't really understand much about the way renderers work and people here talked about ranges and shaders and I lost track ^^

So in short I want to know if I should use the renderer or stick to VMR9 (since I pretty much always view videos on my TV).
If i switch to Halli's renderer is there a way to make it load faster?

Seb.26

30th October 2006, 10:03

This is what I do:
- in MPC "Lock back-buffer before presenting" is enabled
- in Haali's video renderer filter options "Soft Vsync" is disabled.
Thanks, I thing I have this too, but I will check ...

KoD

31st October 2006, 18:11

ExtraEye, you can't make the renderer load faster. Though, to me it looks that the last version does load faster than the previous one, but it might just be me getting accustomed. ^^

I did not know that you could chose to use Haali's renderer in ZoomPlayer. Maybe with a custom graph... But I haven't used ZoomPlayer for quite some time, things might have changed. If you are selecting VMR9 in ZoomPlayer's output options, then it uses the VMR9 Renderer and not Haali's renderer.

Seb.26, it won't cure the tearing completely, but it will be much better.