TMT3 Build 170

[andy o]

It's not that inaccurate. The EVR-CP compensates by varying very slightly the graphics clock to compensate.

But in any case, even if it wasn't, why do you need accuracy to the hundred-billionths of a Hertz? What is the frames dropped/repeated margin of error in a 2-hour movie, for a margin of error of thousandths of a hertz or less?

Let's say the card does 23.97600... Hz. The correct number to the hundred-thousandth hertz is 23.97602 Hz. That's a difference of two hundred-thousandths hertz.

But OK, let's keep it in the thousandths. Let's say for the sake of errors in reality, the difference is one thousandth (23.977 actual refresh rate). That's one frame repeat every 1000 seconds, or 16m 40s.

The margin of error if the card does 23.97600 and the source is 23.97602 would be one frame drop every 50000 seconds, or 13h 53m 20s.

I'm always baffled when people quote the whole 23.9760239... number. They might think those are errors nonetheless, but I bet 99% or more of people don't really care, especially if you compare those errors with the bugs that bitstreaming gets around.

And remember, EVR-CP and probably others too seem to vary very slightly the refresh rate dynamically.

 

[James]

It's not that inaccurate. The EVR-CP compensates by varying very slightly the graphics clock to compensate.

But in any case, even if it wasn't, why do you need accuracy to the hundred-billionths of a Hertz? What is the frames dropped/repeated margin of error in a 2-hour movie, for a margin of error of thousandths of a hertz or less?

Let's say the card does 23.97600... Hz. The correct number to the hundred-thousandth hertz is 23.97602 Hz. That's a difference of two hundred-thousandths hertz.

But OK, let's keep it in the thousandths. Let's say for the sake of errors in reality, the difference is one thousandth (23.977 actual refresh rate). That's one frame repeat every 1000 seconds, or 16m 40s.

The margin of error if the card does 23.97600 and the source is 23.97602 would be one frame drop every 50000 seconds, or 13h 53m 20s.

I'm always baffled when people quote the whole 23.9760239... number. They might think those are errors nonetheless, but I bet 99% or more of people don't really care, especially if you compare those errors with the bugs that bitstreaming gets around.

And remember, EVR-CP and probably others too seem to vary very slightly the refresh rate dynamically.

No way. You can't dynamically alter the refresh rate (unless you're PowerStrip, or I missed some cool new graphic APIs).

 

[leeperry]

yeah, I'm missing something here...I'm kinda OK w/ the guys who look for a perfect refresh rate to match their audio clock(even though I don't really believe that it works, but ok! )....but when DirectX says 23.976, it's prolly constantly jittering between 23.95 and 24.05Hz...so, how do you sync a jittery video clock to a bitstreamed audio? some frames will need to be dropped/dupped...so yes, SQ will kick a**, but how good's a movie w/ dropped frames exactly?

I really cannot stand A/V dropped frames...the same way I cannot stand gappy audio playback, I personnaly hate to be reminded that I'm using a computer source...reason why I run the GrainFactory3() avisynth script on all my movies in 48Hz, it adds 48fps grain on an uber-smooth 24fps video....it's just eye popping on a big projection screen 8)

 

[James]

....but when DirectX says 23.976, it's prolly constantly jittering between 23.95 and 24.05Hz...

Nah. First of all, DirectX says nothing. Last time I checked, there isn't a Direct-whatever function to check the exact refresh rate (ReClock measures (!) the refresh rate).
Second, why would the refresh rate move between 23.95 and 24.05Hz on its own? There can't be a crystal oscillator on a graphics card *that* bad.

 

[leeperry]

Nah. First of all, DirectX says nothing. Last time I checked, there isn't a Direct-whatever function to check the exact refresh rate (ReClock measures (!) the refresh rate).
Second, why would the refresh rate move between 23.95 and 24.05Hz on its own? There can't be a crystal oscillator on a graphics card *that* bad.

well I mean the way Reclock and the pstrip's camera manage to measure the refresh rate through DX is a far cry from real world.

Kazuya has a pretty accurate LCD screen, and when Reclock says 50.000Hz his screen says 50.02...and his Z4 was giving judder w/ 50.000Hz in Reclock but not w/ 50.02Hz, also Rik Wang from the pstrip tech support confirmed that hooking up an oscilloscope to a video card would tell a pretty different story from what can be measured through DX.

well ok maybe I exagerated a bit, but you can look at the realtime stats in mVR/HR/MPC HC's EVR CP..the video refresh rate jitters like HELL...if Reclock tells you 23.976 it's a good guess that it will go around the clock between 23.960 and 23.990...I really don't see it working for 2H in a row w/o a single dropped frame.

and again, when DX allows the software layer to measure 23.976...it's definitely not what's happening IRL and what your video display is seeing at its input...so how do you synchronize a 23.976 audio stream w/ a 23.960<>23.990 video stream? yay, I'm not a believer :disagree:

 

[James]

and again, when DX allows the software layer to measure 23.976...it's definitely not what's happening IRL and what your video display is seeing at its input...so how do you synchronize a 23.976 audio stream w/ a 23.960<>23.990 video stream? yay, I'm not a believer :disagree:

Again - Direct-whatever says nothing, allows nothing. ReClock is counting frames and "measuring" with a stop watch, erm, performance counter (that's why it is often important to use the /USEPMCOUNTER boot.ini setting with XP).
It doesn't matter much, you tell the graphics driver what refresh rate you want and hope for the best.
But whatever refresh rate you get, it should be quite constant. And I expect that standard refresh rates like 23.976 should be quite precise.

 

[leeperry]

Again - Direct-whatever says nothing, allows nothing. ReClock is counting frames and "measuring" with a stop watch, erm, performance counter (that's why it is often important to use the /USEPMCOUNTER boot.ini setting with XP).
It doesn't matter much, you tell the graphics driver what refresh rate you want and hope for the best.
But whatever refresh rate you get, it should be quite constant. And I expect that standard refresh rates like 23.976 should be quite precise.

I don't think it'll be precise at all, the HC49S PLL clocks you find on most graphic cards must have a ±100ppm resolution(±10ppm clocks are several times more expensive), and what you can measure at the software layer clearly isn't what your video display is seeing at its input IMHO...anyway, if some ppl manage to get HDMI bitstream/bit-perfect PCM and pass-through S/PDIF working for 2H in a row w/o dropping a single A/V frame...then I'll have to give up and call it a day

 

[andy o]

No way. You can't dynamically alter the refresh rate (unless you're PowerStrip, or I missed some cool new graphic APIs).

I wasn't 100% sure about this one, was hoping to get more info from you cause I know ReClock is specifically designed to fix this. What's EVR-CP doing then when it varies clock and refresh rate?



The clock there changes dynamically, with visible effects. I've been noticing it for a while now. Refresh rate also varies slightly, and you can see the clock correcting the drift so there are no repeated/dropped frames. I've followed the graph like an idiot for probably like 10 minutes and the green line and the sync offset remain constant with no signs of drifting overall.

I used to use ReClock with MPC-HC and I noticed that even with all video sync features turned off (the clock was red, I was only using it for WASAPI exclusive) ReClock seemed to make these clock changes slower. Sometimes it would drift, but sometimes it wouldn't, but still the changes were slower.

 

[Jong]

Come to this a bit late, but hey!

The refresh rate reported in EVR CP is calculated in much the same way that James says Reclock does at the start of playback, but reported continually. So it is measuring not the real refresh rate, which is tightly controlled by the video card oscillator, but how this is as measured by the CPU, using its own clock. If you go back to the original objectives of Reclock one of them is to better synchronise these clocks. So that is why the refresh rate moves more slowly with Reclock, not because it is improving the actually external refresh rate as it would be measured by the display, but because it is being more accurately measured by the renderer. This helps to avoid dropped frames because if the player more accurately knows the real refresh rate it can more accurately deliver frames at the right rate and time.

The other thing EVR sync renderer especially tries to do is alter the frame rate (not refresh rate) to keep presentation at a good point in the vsync cycle. This is similar to what Reclock vsync correction does, although not as powerful as it cannot be combined with Reclock to also make larger frame rate changes eg. 23.976 -> 24Hz or 23.976 -> 25Hz.

If Reclock is being used, what both EVR Sync and mpc-hc EVR CP can do is time the deliver of the frame so as not to clash with vsync but without changing the underlying refresh rate - EVR Sync calls it "Present at Nearest" and avoids extended frame rate/refresh rate synchronised judder but substitutes just a SINGLE dropped frame at an interval defined by ANY difference in frame rate and refresh rate. Not bad, but not perfect. Even with Reclock frames will occasionally be dropped using this method. By the way I am not sure EVR CP is as rigorous as EVR Sync in ensuring there is only a single dropped frame. EVR CP may lead to more than one dropped frame as the time when frame delivery to the renderer and vsync lap each other. What is sure is, unlike EVR Sync, EVR CP does not change frame rate to preserve sync, it just alters the point in the cycle the frame is actually presented, to minimise, but not completely avoid, judder.

So still the best way to get perfect delivery is to use Reclock AND Reclock vsync correction. Then Reclock self corrects for even the smallest error in the relative rates, because by measuring the point of frame presentation it sets up a feedback loop . The only downside of this is that about one time in three you will get a burst of judder lasting up to 2-3 seconds close to the start of playback or every time you seek. This happens when Reclock decides the quickest way to get frame presentation to its target is to pull it "through" vsync.

By the way, James, I have been meaning to ask this for some time, even this downside could be avoided if you could change the vsync correction code so it always took the path to its vsync target that avoided vsync I.e. @50Hz, If it measures its current vsync position as -2ms and it is trying to get to -17ms it goes the long way around (-2ms -> -17ms), not the short way though zero (-2ms -> 0ms, -20ms -> -17ms). It would take longer to get there but remove the judder!! That would be very cool 8)

 

[leeperry]

hah Jong and his OCD towards VSYNC

one thing I know is that sometimes mVR doesn't catch it properly, and I have to reseek to do so.

if I disable the "anti-tearing fix" in mVR, then it always catches it well...but then I get weird video artifacts

I guess my only solution would be a D3D exclusive mode, too bad mVR looks as dead as an Egyptian mummy.

 

[Jong]

I am hoping we can persuade ar-jar to offer a "Hardware Overlay Surface" option to his EVR Sync renderer. I believe this would offer the same benefits as D3D for sync, plus the banding elimination of MadVR, all without the limitations of D3D mode (but with a few of its own such as no screen capture). It would not offer the improved chroma upsampling, but Rome was not built in a day!

 

[Jong]

Here, for a limited time only(!) is a very poorly videoed example of Reclock pulling frame presentation through vsync after seek causing judder. Watch the green line. Apologies for any copyright infringement!

If it could only go "the other way" there would be no judder!

 

[Jong]

FYI, just tried TMT3 for the first time, on trial. Sick of using a two year old version of PDVD!! It looks great and I can confirm that Reclock vsync correction works with TMT3 too when playing Blu-ray discs. Looks like its overlay surface has the same effect as does PDVDs. I think (bit more testing yet!) I will be moving.

 

[andy o]

Come to this a bit late, but hey!

The refresh rate reported in EVR CP is calculated in much the same way that James says Reclock does at the start of playback, but reported continually. So it is measuring not the real refresh rate, which is tightly controlled by the video card oscillator, but how this is as measured by the CPU, using its own clock. If you go back to the original objectives of Reclock one of them is to better synchronise these clocks. So that is why the refresh rate moves more slowly with Reclock, not because it is improving the actually external refresh rate as it would be measured by the display, but because it is being more accurately measured by the renderer. This helps to avoid dropped frames because if the player more accurately knows the real refresh rate it can more accurately deliver frames at the right rate and time.

I always had ReClock disabled for video options (red clock). So you're saying that Reclock is still doing something there?

Anyway if EVR-CP is just measuring things, that would mean that the clocks in the ATI cards are extremely well syncrhonized. I'm not sure but could the audio use the same clock as the video there?

 

[andy o]

Here, for a limited time only(!) is a very poorly videoed example of Reclock pulling frame presentation through vsync after seek causing judder. Watch the green line. Apologies for any copyright infringement!

If it could only go "the other way" there would be no judder!

In my setup the green line is constant. It seems the clock and refresh rate vary slightly in order to maintain sync offset only within a small range. I don't know what is causing these clock changes but you can see them compensating. If the offset is going one way, the clock goes the other, and then offset starts going the other way, then clock reverses again. This happens very rapidly without ReClock.

With reclock I haven't tried it yet with the same version of MPC-HC or with the 5770 card, only with a 4670, but with that it was about the same, only it happened at a slower pace.

 

[Jong]

What renderer are you using, what settings do you have in Reclock and what figure are you talking of when you speak of "clock changes"?

EVR CP is not just measuring things. It changes the point of presentation to minimize synchronised judder, but, unlike EVR Sync, it does not change the underlying frame rate. Basically it holds on to the frame and adds an "offset" to the frame delivery so it is delivered at the point in the cycle it wishes to. However, if the frame rate and refresh rate do not match exactly this offset will change over time, getting bigger or smaller and judder will happen when the two lap each other and there is no choice but to drop/repeat a frame. If you use Reclock (in normal mode, not necessarily with vsync correction), with matching refresh/frame rates, there is a better chance this will not happen during a movie as the GPU, CPU and audio clocks are synchronised so they are much closer to agreeing what 23.976 (for example) actually is.

EVR Sync a.k.a. Sync Renderer can alter the frame rate to stop even this cause of judder but, unlike Reclock, can only do it for very small adjustments (not even 23.976 -> 24).

The EVR CP green line measures something completely different to the Sync Renderer green line! The Sync Renderer green line will only move as in my little video if you use Reclock vsync, with a compatible renderer. This is another reason why I like sync renderer; It reports clearly every time a sync error happens. If it doesn't show it in the green line and in in its cumulative totals you know you are good! Judder does not normally show in the EVR CP green line and there are no cumulative totals for sync errors. Actually it is this that is the only reason I use Sync Renderer, as I use Reclock vsync correction, so have to turn off all Sync Renderer sync improvement options.

With Sync Renderer the green line will start out bang on its target location, but as I said it cannot cope with significant changes in frame rate so if used in conjunction with Reclock to change refresh rate (in "Present at Nearest" mode) it will, like EVR CP occasionally drop a frame (but not multiple juddery frames as otherwise would happen). But how often depends on the difference in refresh rates and whether Reclock is being used merely to improve clock accuracy e.g. 23.976fps @23.976Hz or to actually change rates, e.g. 23.976 @24Hz or 50Hz or 60Hz.

By the way, even TMT3, Like PDVD and just about every other player, does none of this!! I've just done the test and if you seek enough times with TMT3, say watching rolling credits (can take 15-20 times), the movie will judder like crazy. Fortunately, Reclock vsync correction fixes it (but can lead to a one off burst of judder in the first 30 secs or so or so as mentioned above. Normally this is during the studio logos etc. so no real issue, but if James could fix that...... ).

(ps. not sure what you meant by "ReClock disabled for video options")

 

[andy o]

disabled vsync, framerate detection, disabled audio resampling (think it's called media adaptation), set "original speed" in framerate, and check "slave reference clock to audio". The clock was always red, not yellow nor green.

 

[Jong]

Oh, in that case I am not sure why Reclock seemed to improve things. If "slave reference clock to audio" is checked the video benefits of Reclock should be disabled.

 

[andy o]

Actually it didn't "improve" them. At best it kept them practically the same, at worst the sync offset slightly drifted until a frame repeat or drop happened. Without Reclock the clock changes just happen more rapidly.

BTW I'm playing right now a 23.976 mkv rip of an HD-DVD with EVR Sync. How long is it acceptable to wait until a drop frame occurs, and what does it mean if it doesn't happen?

 

[Jong]

Oh, OK I get it now.

What is your refresh rate, what does Reclcok say it is and what EVR Sync sync option are you using?