madVR - high quality video renderer (GPU assisted) [Archive] - Page 20

Grmpf

11th May 2009, 21:39

Here is a Screenshot with some Pixel Zoom, Lanczos8 for chroma + luma and 1080p trailer as input:
http://www.armster.de/caspar/1080pN_scaled.jpg

In my last screenshot (1080p on FullHD) lanczos wasn't totaly disabled or ? chroma just used it or ? - wether its good to use lanczos8 for chroma or not is something else to talk about ;-)

Btw i totaly agree with you that my OSD positioning problem is not important, if madVR is runing nice&smooth in the future there is no reason to toggle the osd on at all...

And you are going for a "Release Candidate" of an "Operating System" madshi ? I don't know, i wouldn't use something like this even if you would give me money for it... but i guess if you're a software developer you have to live with it. I will wait what EnTech is telling me on the support of the videocard - atm it looks as if the old chips (55nm) work even if they are not officially supported and i am the first to report a problem with the new 40nm one - all people here using the new 4770 use Vista or Win7 or ?

Just keep up the good work !

honai

11th May 2009, 22:05

Interesting - especially comparing your results to tetsuo55's results! Probably the texture uploading number is quite big for you? That might explain a bit why tetsuo55 had lower numbers: Of course uploading HD content to the GPU takes more time than uploading SD content.

Have you tried Lanczos8, just to put some real pressure on the GPUs?

Unfortunately I didn't and the 9600GT is already in a box, but I can make some tests with the 4770 later and see how performance degrades.

madshi

11th May 2009, 22:14

Well if I was to alter it slightly, frames being delivered in inconsistent intervals by the RENDERER.
Slightly? That's a *totally* different interpretation. Mark, no offense, but I am really not looking forward to people posting their own interpretations of what jitter might eventually mean (or not). I explicitly said: "Please post only if you know exactly". I did not ask: "Please everyone post your guesses". That'd be the opposite of what I want.

it's dependent on the VSYNC fliptime too, coz if the video renderer doesn't catch it spot-on to begin with....it will worsen and worsen overtime and it'll be so late after 45/60' that it will drop frames constantly to catch up...
Again no offense. But I'm not really interested in end user experiences about jitter (I thought I made that clear!). I'm interested in definite and clear defined *technical knowledge* from someone who knows *exactly* what he's talking about.

Please no more posts about jitter, unless someone comes with real technical "behind the scenes" knowledge. Thanks.

do you have any plans for refining chroma upsampling methods?
Maybe. Or maybe not.

2) And what is the config of your new HTPC :)?
Gigabyte microATX board with NVidia 9300 chipset + Q9650 + ATI 4770. That will allow me to test both NVidia + ATI. And it should have enough horsepower for some time to come...

Here is a Screenshot with some Pixel Zoom, Lanczos8 for chroma + luma and 1080p trailer as input
Ah yes, thanks!

In my last screenshot (1080p on FullHD) lanczos wasn't totaly disabled or ? chroma just used it or ?
Yes, chroma upsampling is always active (unless you choose nearest neighbor or bilinear filtering).

And you are going for a "Release Candidate" of an "Operating System" madshi ?
That's because people keep telling me that they like Windows 7 a lot (much more than Vista).

madshi

11th May 2009, 22:16

Unfortunately I didn't and the 9600GT is already in a box, but I can make some tests with the 4770 later and see how performance degrades.
Yeah, that would be interesting. Your rendering times seem to be higher with just 2 tap filtering compared to what the two other 4770 owners report with 8 tap filtering. So my guess would be that probably performance will not degrade much if you activate 8 tap filtering...

honai

11th May 2009, 22:23

Lanczos8 for both luma and chroma (because I'm downsizing at the moment to 1680x1050)? Or just chroma? I could also output to 1080p on the tv if that'd be interesting.

mark0077

11th May 2009, 22:23

Slightly? That's a *totally* different interpretation. Mark, no offense, but I am really not looking forward to people posting their own interpretations of what jitter might eventually mean (or not). I explicitly said: "Please post only if you know exactly". I did not ask: "Please everyone post your guesses". That'd be the opposite of what I want.

Well none of us are robots, we can take the wikipedia definition but that wouldn't be much help either. Users opinions are what count in interpreting official definition. There's wikipedias "Jitter is the time variation of a characteristic of a periodic signal in electronics and telecommunications, often in relation to a reference clock source." If you need a definition you can look it up for yourself. If you need input from people that have spent time trying to find software to improve jitter then you use the forums, ie us... don't be so rude when people try to interpret what you could have looked up for yourself. Everyones trying to help you out but you make it difficult. Reclock's slight changes in frame speed as I mentioned earlier is an example of a way a renderer can improve jitter from in my case (playing 23.976 content on 48hz), to 0ms jitter. That is 0ms between the time the frame SHOULD have been displayed and the time the frame WAS displayed. Without this change every frame would be a certain offset from the "reference" time, or the time it should have been played in a perfect world.

That is most probably a decoder bug. Which decoder did you use?
This happens with various decoders, ffsdhow libavcodec, ffdshow libmpeg2. Let me know if I can test any other decoders / settings to find the source of the offsets I am seeing.

leeperry

11th May 2009, 22:45

But I'm not really interested in end user experiences about jitter (I thought I made that clear!). I'm interested in definite and clear defined *technical knowledge* from someone who knows *exactly* what he's talking about.
an email to Haali you should drop then.

honai

11th May 2009, 23:09

Here's what happens when switching chroma upsampling to Lanczos8: Basically the first block stays the same, the second:

max gpu rendering time ... fluctuates between 15ms and 22ms
resample textures ... fluctuates between 9.5ms and 13ms

The rest stays almost the same.

When also selecting Lanczos8 for luma, max gpu rendering time fluctuates between 22ms and 24ms, and resample textures is almost fixed at 17ms.

flanger216

12th May 2009, 01:17

And you are going for a "Release Candidate" of an "Operating System" madshi ? I don't know, i wouldn't use something like this even if you would give me money for it... but i guess if you're a software developer you have to live with it.

Dude... they're just words. The Windows 7 RC is vastly more stable over Vista for many users, so who cares if it's called a 'release candidate?' They could call it the 'This Will Crash' version, and I'd still use it if it were functionally more stable than the alternatives.

racerxnet

12th May 2009, 04:45

Another reason why I don't plan to look into super resolution is that I don't want to spend too much time on scaling, because my main priority is Blu-Ray playback, anyway, and scaling is usually not needed there...

It's is great that you are providing this software to all of us and appreciated, but the majority of us still use SD DVD as the titles are just not out there on BR. This is a fact that should not be overlooked.

As well, the major OS is still XP. We all know Vista was a flop and 7 is still in Beta stage. Slysoft player will dominate the marketplace once it is available as freeware if it will support Xp and Vista. Your product is good, but watch where you tread. The dominant force is XP and Sd DVD. Support what you want at your own risk. It'll be a cold day in hell before I replace 600 DVD's with BR titles. Hopefully you will address the smooth playback and not spend the next several months on perfecting last 2% regarding color fidelity. Other areas need to be focused on as well. Once again, thanks for the software. It has worked well for me on my system as long as I do not use spline 64. Otherwise it tears.

My .02

MAK

Hypernova

12th May 2009, 06:26

Dude... they're just words. The Windows 7 RC is vastly more stable over Vista for many users, so who cares if it's called a 'release candidate?' They could call it the 'This Will Crash' version, and I'd still use it if it were functionally more stable than the alternatives.

Easy :). Just say "give it a try" and be done with it. Let people decide for themselves if they like it or not.

As well, the major OS is still XP. We all know Vista was a flop and 7 is still in Beta stage. Slysoft player will dominate the marketplace once it is available as freeware if it will support Xp and Vista. Your product is good, but watch where you tread. The dominant force is XP and Sd DVD. Support what you want at your own risk. It'll be a cold day in hell before I replace 600 DVD's with BR titles. Hopefully you will address the smooth playback and not spend the next several months on perfecting last 2% regarding color fidelity. Other areas need to be focused on as well. Once again, thanks for the software. It has worked well for me on my system as long as I do not use spline 64. Otherwise it tears.

I won't comment on XP/Vista/7 (you can't tell I like 7>Vista>>>XP? :D ), but maybe that 2% is the reason madshi start this project in the first place? Now, if it's 0.0002% then maybe he should stop worrying, but 2%? I think he already did better than that :cool:

madshi

12th May 2009, 08:06

If you need a definition you can look it up for yourself.
I know perfectly well what the term jitter means. I didn't ask for a definition.

don't be so rude when people try to interpret what you could have looked up for yourself.
Maybe I was rude. But you flat out ignored what I wrote. I explicitly asked for expert feedback on jitter only, and I explicitly pledged end users to *NOT* post their guesses and experiences. And you ignored that.

The reason why I've been trying to cut replies to my jitter question down is that I'm doing all this in my free time - which is very limited and very precious to me. Having to read through and reply to posts which I explicitly asked for *not* to happen, is annoying to me because it feels to me like you'd disrespect the value of my time.

Everyones trying to help you out but you make it difficult.
You can't help out except if you have behind the scenes knowledge that I do not have. Actually you're doing the opposite of helping out right now: I've now spent 30 minutes on replying to your jitter posts, which are lost for madVR development. Every minute I spend on posting in the forums is lost on madVR development!

You do can help out if you report bugs like this:

This happens with various decoders, ffsdhow libavcodec, ffdshow libmpeg2. Let me know if I can test any other decoders / settings to find the source of the offsets I am seeing.
It doesn't seem to happen for me. Could you please post one exact example where the problem occurs with the following information: (1) source resolution (2) source codec (3) decoder used (4) display resolution? Thanks.

an email to Haali you should drop then.
Haali doesn't reply to my emails.

Here's what happens when switching chroma upsampling to Lanczos8: Basically the first block stays the same, the second:

max gpu rendering time ... fluctuates between 15ms and 22ms
resample textures ... fluctuates between 9.5ms and 13ms

The rest stays almost the same.

When also selecting Lanczos8 for luma, max gpu rendering time fluctuates between 22ms and 24ms, and resample textures is almost fixed at 17ms.
"Resample textures is almost fixed at 17ms". Is that average or max gpu? Generally I'm mostly interested in average gpu rendering times. How do they compare between using the default madVR options (SoftCubic50/100) and using Lanczos8/Lanczos8? Thanks...

It's is great that you are providing this software to all of us and appreciated, but the majority of us still use SD DVD as the titles are just not out there on BR. This is a fact that should not be overlooked.
AFAIK madVR already provides the best quality scaling you can get in the HTPC world right now. With some more tweaks to come, some of which even current top quality hardware (like Gennum VXP and HQV Realta) doesn't offer. What more do you expect!?

As well, the major OS is still XP.
I don't recall having said that I would stop supporting XP... ;)

Hopefully you will address the smooth playback
Fixing showstopper bugs (if any), smooth playback and DVD playback are my current top priorities.

Leak

12th May 2009, 08:58

I think is where alot of users want to see the renderer taking responsibility for these tiny adjustments, ie 23.976fps -> 24fps conversions to bring jitter to 0.
And how exactly is the (video!) renderer supposed to keep audio and video in sync in that case?

Sure, it can just display 24 instead of 23.976 frames per second, but I'm pretty sure everyone and their dog will whine that the audio starts lagging behind more and more over time - and even if there was an accompanying audio renderer that resampled the audio accordingly (why hello there, Reclock) some other audiophile nut-group would start whining about the playback not being "bit-perfect" (meh) anymore.

It's a lose-lose situation where no side can win unless (some) people finally grasp that you'll have to sacrifice a small bit of audio quality for your playback to be totally smooth.

Adjusting the audio to match the video speed is easy, adjusting the video to match the audio speed is hard, CPU-intensive and prone to much more noticeable artifacts than just a slight pitch variation.

mark0077

12th May 2009, 09:27

And how exactly is the (video!) renderer supposed to keep audio and video in sync in that case?

Sure, it can just display 24 instead of 23.976 frames per second, but I'm pretty sure everyone and their dog will whine that the audio starts lagging behind more and more over time - and even if there was an accompanying audio renderer that resampled the audio accordingly (why hello there, Reclock) some other audiophile nut-group would start whining about the playback not being "bit-perfect" (meh) anymore.

It's a lose-lose situation where no side can win unless (some) people finally grasp that you'll have to sacrifice a small bit of audio quality for your playback to be totally smooth.

Adjusting the audio to match the video speed is easy, adjusting the video to match the audio speed is hard, CPU-intensive and prone to much more noticeable artifacts than just a slight pitch variation.

Yep exactly, I suppose its a matter of preference in this case. Where in my case at 60hz its impossible to ever get perfect output, I decide to settle for the 23.976 @ 24hz approach which apparantly plays the audio at the original pitch....

So are you suggesting ... well what I said earlier, that things like rate changes should be handled externally, ie not by the renderers.

nlnl

12th May 2009, 09:31

Nvidia 9400 IGP, MPC-НC 1095, Directx 10.0(6.0.6000.16386)
Vista 32

MadVR can not detect correctly display refresh rate with new driver Nvidia 185.85 (By the way driver properties in control panel say "compatible Windows 7 display driver", so can it output 30/36 bit RGB? Is there any card supporting deep color?).
Using 182.08 everything was OK.

Nvidia 182.08
display estimate 1: 24.97Hz
display estimate 2: 23.976Hz
display estimate 3: 23.976Hz (absolutly stable)
display 23.976 (absolutly stable)

Nvidia 185.85
Aero ON
display estimate 1: 24.97Hz
display estimate 2: 23.976Hz
display estimate 3: 26.976Hz (unstable)
display 27.976 (1s) (unstable)
Aero OFF
display estimate 1: 24.97Hz
display estimate 2: 0.0Hz
display estimate 3: 0.0Hz
display 55.9 (1s)
madshi
Gigabyte microATX board with NVidia 9300 chipset + Q9650 + ATI 4770. That will allow me to test both NVidia + ATI.

Can your detect correct display refresh rate with new driver Nvidia 185.85 + Win 7 ( 182.08 + Vista32 was OK for my config)?

honai

12th May 2009, 11:02

"Resample textures is almost fixed at 17ms". Is that average or max gpu? Generally I'm mostly interested in average gpu rendering times. How do they compare between using the default madVR options (SoftCubic50/100) and using Lanczos8/Lanczos8? Thanks...

It's max GPU. The average fluctuates a lot, but I'd say from SoftCubic to Lanczos8 it's, surprisingly, within the margin of error.

Another observation with the 4770, which in the past I also had with a 3450: It seems the card does automatic over-/underclocking, and depending on the load of the 3D-circuitry increases or decreases GPU clock. In the past this had severe consequences for video playback. While the idea of saving power when not playing 3D games might be nice, for HTPC it's not practical because the load produced by e.g. madVR's postprocessing seems to confuse that logic and make it fluctuate between the two states, i.e. no load and full load.

I'll post the averages tonight.

racerxnet

12th May 2009, 14:25

Madshi,

Thank you for the response. I'll not waste your time anymore..

MAK :)

Jong

12th May 2009, 14:40

it's dependent on the VSYNC fliptime too, coz if the video renderer doesn't catch it spot-on to begin with....it will worsen and worsen overtime and it'll be so late after 45/60' that it will drop frames constantly to catch up...which is exactly what happens w/ each and every video renderer on XP(yours/VRM/EVR/HR/all of them really).Dangerous even to step into this :D, but this isn't what happens (I firmly believe!). What happens is eventually the "end present" time gets so close to the flip time that the small differences in arrival time from frame to frame (say ~2ms) are sometimes on one side of the flip and sometimes on the other. And if the frame rate and refresh rate are almost exact multiples of each other and the presenter is a good one this situation can go on and on and on. On my PC it can easily take >45mins to get out of this state once in it.

Madshi, I do not know if you have seen this article: http://software.intel.com/en-us/articles/video-frame-display-synchronization/.

By the way, Madshi, I agree with you provided the changes in arrival time are not sufficient to pass backwards and forwards over the flip time they are irrelevant. It is important though to make sure the "end present" time is away from the flip time when playback starts and is kept away from it throughout playback. Most renderers/presenters make no effort at all to define this "end present" time, it is essential random after each seek. the time till a problem occurs then depends on how tightly the frame rate and refresh rate match and how accurately they are maintained.

madshi

12th May 2009, 14:57

Can your detect correct display refresh rate with new driver Nvidia 185.85 + Win 7 ( 182.08 + Vista32 was OK for my config)?
I've no idea, I have an ATI card. Please wait for the next version and then retry...

I'd say from SoftCubic to Lanczos8 it's, surprisingly, within the margin of error.
Good!

What happens is eventually the "end present" time gets so close to the flip time that the small differences in arrival time from frame to frame (say ~2ms) are sometimes on one side of the flip and sometimes on the other.
Ok, that makes sense. I plan to use two totally different presentation logics in madVR: One for situations where source frame rate and display refresh rate don't match. And one for situations where they do match (1:1 or 2:1 etc). In the latter case I plan to strictly show one frame per VSync (or every other VSync), regardless of timestamps. Only if timestamps stray away too much madVR will drop or repeat a frame in that mode. So the problem you described should not occur in madVR's 1:1 mode. Please note that it might take a while until I actually get around implementing all this... ;)

Jong

12th May 2009, 15:05

Ok, that makes sense. I plan to use two totally different presentation logics in madVR: One for situations where source frame rate and display refresh rate don't match. And one for situations where they do match (1:1 or 2:1 etc). In the latter case I plan to strictly show one frame per VSync (or every other VSync), regardless of timestamps. Only if timestamps stray away too much madVR will drop or repeat a frame in that mode. So the problem you described should not occur in madVR's 1:1 mode. Please note that it might take a while until I actually get around implementing all this... ;)You may know better! If so, I apologize! But, from experience with other renderers I am not sure they know anything is wrong. Maybe it is just that they are not looking, but they might be very strictly delivering one frame per vsync but if sometimes, due to small variances, that actually arrives one side of the flip or other (see figure 5 in the Intel document) the result is horrible judder - frames repeated for two vsync intervals then frames being missed altogether (because one arrived just after vsync and the next just before the next). There is still one frame per vsync on average over a couple of frames and within, say, 2ms, but still anything but smooth playback! VMR9 stats certainly do not record any dropped frames when the judder is absolutely ghastly because of this issue. I think the only solution is to keep the "end present" time well away from the flip time. I think Beliyaal is trying to keep it to around line 200 on a 1080p screen with his EVR CP enhancements. The Intel document may have another way involving some kind of predictive logic that I never spent enough time to get my head around!

leeperry

12th May 2009, 16:10

from experience with other renderers I am not sure they know anything is wrong.
yep! either Aero or exclusive mode on XP make sure that the hardware layer(that knows) watches over the software video renderers(well HR knows what's going on, but doesn't care...Haali didn't use Reclock at all)

anyway, I'm also talking from experience...so I'll simply shut it, and hope some software engineers will offer technical clues :)

tetsuo55

12th May 2009, 16:17

From what i read about jitter, if madVR buffers as many frames as logical and then presents them at the exact right moment there should be near 0 video jitter. (and currently madVR already does this to the best of its current ability). What the right moment is depends on a lot of things (most of which madVR already seems to have covered), i however cannot list them.

This however does nothing for audio jitter or a-v sync jitter.

Fixing audio jitter requires an audio renderer that presents the samples at exactly the right moment so there is near 0 audio jitter.

To get A-V sync perfect both should work together intensively.
Timing not only their individual perfect presentation moment but also how the 2 relate to each other.

I don't think madshi is interested in that last part at all.

honai

12th May 2009, 16:43

From memory, Beliyaal once explained that, actually, jitter is the only way to achieve smooth playback as long as the jitter (=deviation of display time from presentation time in the stream) oscillates within a margin such that, statistically, the average achieved fps is very close to the desired fps, and the display time deviates below the perception threshold of omitted/duplicated frames. Which means that when playing a 24000/1001 video on a 59.xyz refresh rate display, it's actually necessary to alternate between 59.x1 and 60.x2 to achieve the perception of smooth playback.

I think the basic algorithm is close to what eac3to does when repacking VC-1 streams in MKV and therefore calculating timestamps. ;)

Jong

12th May 2009, 16:54

yep! either Aero or exclusive mode on XP make sure that the hardware layer(that knows) watches over the software video renderers(well HR knows what's going on, but doesn't care...Haali didn't use Reclock at all)

anyway, I'm also talking from experience...so I'll simply shut it, and hope some software engineers will offer technical clues :)What I mean is you can have horrible judder definitely due to frame rate/refresh rate synchronisation yet VMR9 reports no dropped frames. It's experience for sure, but measurable and reproducable.

Understanding what frame rate/refresh rate synchronisation is, it seems to me this is because it is still delivering the exact number of frames required at almost exactly (sic) the right time, but +/- 1ms or 2ms could mean the difference between a frame getting displayed once, twice or never. What I do not know is whether it is possible for the renderer to know to sub-1ms accuracy whether the frame it wrote to the back buffer arrived just after flip time or before and, anyway, then it is too late. Best to avoid it.

leeperry

12th May 2009, 17:20

you can have horrible judder definitely due to frame rate/refresh rate synchronisation yet VMR9 reports no dropped frames.
yep, they send frames and hope for the best! prolly the video renderers cannot "know" about the VSYNC fliptime position...which would explain why Beliyaal enforces buffering in his presenter to catch it "spot on", he takes the problem the other way around :)

Jong

12th May 2009, 18:12

yep, they send frames and hope for the best! prolly the video renderers cannot "know" about the VSYNC fliptime position...which would explain why Beliyaal enforces buffering in his presenter to catch it "spot on", he takes the problem the other way around :)That's why I thought I would warn Madshi. It may not be a problem, he may be able to do a better job, but it is possible that just "strictly show(ing) one frame per VSync" may, surprisingly, not be enough.

madshi

12th May 2009, 20:00

Guys, enough talk about jitter now, thanks. As I already said, in madVR's 1:1 mode there should be no problem.

Egh

12th May 2009, 23:17

Madshi: yeah, it is confirmed -- no one knows how to derive these spline coefficients :) Even avisynth has a disclaimer about that. Trouble is that they may not be ideal, although they do surprisingly good job. And seems "spline256" is what some people call "sinc256" in the original PanoTools (where all these coefficients were taken). So far even proficient in math don't have a clue what conditions were used for these splines.

However we may try to find out if there are any better splines than existing ones.

Very keen on trying your adaptive rescaling algorithm as well.

madshi

13th May 2009, 06:59

However we may try to find out if there are any better splines than existing ones.
Great! yesgrey3 earlier reported that "Akima" splines may be interesting. Documentation is available on the net. Maybe you can try figuring that out? I haven't been able to turn that documentation into a coefficient set that I could use for my resampling filters...

Grmpf

13th May 2009, 11:06

Just wanted to give a short feedback on my Powerstrip problem - its solved bei EnTechTaiwan as some of you may already knew by reading my thread over there.

The reference clock had changed from 27mhz to 100mhz, so the following line in the pstrip.ini is required:

[HW.94B31002.29011682.0100] (<- thats where to put it in my pstrip.ini)
OSC=100000

Doing a quick test it worked, 60.000hz are 60.000hz again and so on. Trying 23.976hz in the advanced timing options resulted in 23.973hz, but i didn't mess around with the different timings, was just a quick check. Guess i stay with Win XP now ;-)

Thunderbolt8

13th May 2009, 13:57

whats the difference anyway when its not exactly 23.976, but 3 Hz off now? does the picture then look somewhat distorted or are there other disadvantages?

madshi

13th May 2009, 14:23

whats the difference anyway when its not exactly 23.976, but 3 Hz off now? does the picture then look somewhat distorted or are there other disadvantages?
It's 0.003Hz off, that's about 0.0125%. If you calculate that for a 100 minute movie 0.0125% is about 750ms difference. That means if you use a 1:1 display logic where you display exactly one video frame per VSync without correcting audio (ReClock), audio will be off by 750ms at the end of the movie. Or if you want to drop/repeat frames instead of resampling the audio, you have to drop/repeat about 18 frames while watching the movie. So obviously, although the difference is small, it does affect playback.

Hope my math is alright... :o

Thunderbolt8

13th May 2009, 14:34

eww, I hope they will be able to fix that then to exact 23.976 fps :S

tetsuo55

13th May 2009, 14:48

madshi,

Do you think it will be possible to have madVR switch the display refresh rate based on the ideal video refresh rate (using pre-defined allowed values)

My panel and videocard support all formats (24p, 25i, 30i, 50p, 60p)

OH and if it can and will it should switch back to a pre-defined value too (60p in my case)

FoLLgoTT

13th May 2009, 15:09

whats the difference anyway when its not exactly 23.976, but 3 Hz off now? does the picture then look somewhat distorted or are there other disadvantages?

The absolute refresh rate is not important. Important is that the clock generator of your soundcard fits to the clock generator of your graphics card.

Due to Bitmonster's timing calculator (http://www.avpedia.org/wiki/HTPC_Bildfrequenz_Optimierung) there is no need for big deviations on ATI cards. This script analyzes ReClock's log file and calculates possible Powerstrip timings which fit best to the clock generator of your soundcard. The resulting timing usually gives more than 24 hours without a single audio drop or repeat. Enough for every situation. ;)

tetsuo55

13th May 2009, 15:12

The absolute refresh rate is not important. Important is that the clock generator of your soundcard fits to the clock generator of your graphics card.

Due to Bitmonster's timing calculator (http://www.avpedia.org/wiki/HTPC_Bildfrequenz_Optimierung) there is no need for big deviations on ATI cards. This script analyzes ReClock's log file and calculates possible Powerstrip timings which fit best to the clock generator of your soundcard. The resulting timing usually gives more than 24 hours without a single audio drop or repeat. Enough for every situation. ;)

Assuming you have CRT panel :(

Leak

13th May 2009, 16:04

Assuming you have CRT panel :(
Last time I checked my projector was DLP, not CRT...

np: Moderat - 3 Minutes Of (Moderat)

tetsuo55

13th May 2009, 16:07

Last time I checked my projector was DLP, not CRT...

np: Moderat - 3 Minutes Of (Moderat)

I should have said multisync capable display :P

Thunderbolt8

13th May 2009, 16:58

ordered a HD 4770 as well, should be here within a week (I hope). can post some stats from me then too.

Wilbert

13th May 2009, 17:05

Madshi: yeah, it is confirmed -- no one knows how to derive these spline coefficients Even avisynth has a disclaimer about that. Trouble is that they may not be ideal, although they do surprisingly good job. And seems "spline256" is what some people call "sinc256" in the original PanoTools (where all these coefficients were taken). So far even proficient in math don't have a clue what conditions were used for these splines.
In a few days i will post a story about those splines! Stay tuned :)

madshi

13th May 2009, 17:24

Do you think it will be possible to have madVR switch the display refresh rate based on the ideal video refresh rate (using pre-defined allowed values)

My panel and videocard support all formats (24p, 25i, 30i, 50p, 60p)
Don't spoil the surprise! I have plans for a number of features I haven't mentioned yet... ;) But now is not really the time for that yet.

In my experience, interlaced output doesn't work well with HTPCs, though, so my plans do not include interlaced output or interlaced graphics modes...

Due to Bitmonster's timing calculator (http://www.avpedia.org/wiki/HTPC_Bildfrequenz_Optimierung) there is no need for big deviations on ATI cards. This script analyzes ReClock's log file and calculates possible Powerstrip timings which fit best to the clock generator of your soundcard. The resulting timing usually gives more than 24 hours without a single audio drop or repeat.
Didn't know that one yet. Looks quite promising! The only question is whether the display/projector will accept funny modes. I think some displays/projectors are more forgiving than others...

In a few days i will post a story about those splines! Stay tuned :)
Looking forward to it... :)

FoLLgoTT

13th May 2009, 18:05

Didn't know that one yet. Looks quite promising! The only question is whether the display/projector will accept funny modes. I think some displays/projectors are more forgiving than others...

Yes, the display has to sync to the custom mode. With CRT projectors custom modes are no problem in general as long as the porches stay inside a range which doesn't cause geometry errors.
Digital displays behave very differently. Some does many custom modes well, others not. And some show tearing or judder with certain modes, because they internally sync with a different refresh rate. It is trial and error.