ReClock 1.8.6.7

[leeperry]

I really wish you would chime in mVR's thread, but no biggy

 

[Jong]

If madshi enters into a discussion on this I am happy to join in. I just do not feel comfortable forcing the discussion on a renderer I do not use and have not personally tested (well I've played with it, for sure, but not rigorously put it through its paces). I am taking you at your word, for example, that madshi's current vsync code does not work and occasionally judders. I don't doubt you are right, but I cannot speak from personal experience.

 

[Kazuya]

ps. just to be clear again the EVR Sync Target of -14ms is not doing anything the way we have configured MPC (all Sync Renderer vsync options off). It should really be greyed out.

Strange, I was sure it does something !
Power of belief !

A few more things:

<ctrl><alt>r resets the sync counters in the Sync Renderer OSD, so you can reset when playback has stablised and check easily at the end if there have been any problems, without watching the graph the whole time! On XP you may see occasional downward spikes on the green line due to scheduling delay, but with 17ms of margin you should almost always still be OK.

Nice !

Personally, I would move the green line down a bit to more like 16:5ms -17ms av. Offset. You can see the green line is peaking dangerously close to -20ms, where t will first lead to the red line wobbling and if a bit worse judder. You may get way with the current position (especially as it will move down when the other simpler OSD modes are used or if, as normally, the OSD is off.) But you have plenty of margin, better use it.

I'm not sure to succeed, when I find the good setup last night, I feel it was more due to chance to anything else ! lol
Why Vsync target couldn't be a numerous thing ?

 

[Jong]

I'm not sure to succeed, when I find the good setup last night, I feel it was more due to chance to anything else ! lol
Why Vsync target couldn't be a numerous thing ?

I'm not sure I understand any of this, sorry! Care to explain?

 

[Kazuya]

I mean, why this target vsync position is a bar ?
It could be a number to choose, no ?
Like in EVR sync, in ms.
Because it's pretty obscur to understand what it does...

Tonight, I had a problem at beginning, reclock couldn't make synchro, green and red line were totally crazy and made a lot of glitches... but without a drop.
Maybe my fault (long to explain ! lol).
Then, I searched again a good target vsync position (at the middle of the bar), and this time it seems better :

 

[Jong]

Yeah, this is one of the mysteries of Reclock. I think it comes down to Reclock being an audio renderer, not a video renderer. I don't think it knows the actual scanline position. That seems true as otherwise I'd expect the position to be the top of the screen if the slider is to the left and the bottom if to the right. And renderer writers have said to me they do not know how it would get that info. But somehow it seems to be able to know if it is not where you said it should be without necessarily knowing where that actually is on the screen Yes, it's odd!

I'm confused by the rest of your post.

The green line should always end up in the same place, dictated by the slider position. You should be able to move the target position, even during playback using <ctrl><alt><shift>F11 and F12 (by default) and watch the green line follow it after a few seconds.

You seem to be saying it settles at a different point after each seek. That says vsync control is off. But I may be misunderstadning you!

You should never get a situation where it cannot sync, unless you set the target too close to vsync (red line), although you can get a couple of seconds of judder after a seek, as I described. With a 20ms frame time anything >6ms <17ms should be fine from that point of view, but as scheduling delays always cause a spike downwards it is better to go for the highest acceptable figure e.g the 16.5ms av. offset I originally recommended.

 

[Kazuya]

I'm confused by the rest of your post.

The green line should always end up in the same place, dictated by the slider position.

It's the case.

You should be able to move the target position, even during playback using <ctrl><alt><shift>F11 and F12 (by default) and watch the green line follow it after a few seconds.

Not really effective... Maybe my remote doesn't work for this hotkey ? It happens sometimes. I will try again.
(I have to close MPC, open reclock configuration, change target and reopen MPC to see difference)

You seem to be saying it settles at a different point after each seek. That says vsync control is off. But I may be misunderstadning you!

No, no, it starts at different point, then reach the same target.

You should never get a situation where it cannot sync, unless you set the target too close to vsync (red line), although you can get a couple of seconds of judder after a seek, as I described. With a 20ms frame time anything >6ms <17ms should be fine from that point of view, but as scheduling delays always cause a spike downwards it is better to go for the highest acceptable figure e.g the 16.5ms av. offset I originally recommended.

Just to be sure I understand well, at each position of Vsync target, one position of the green line, right ?

 

[Jong]

It's the case.
....
No, no, it starts at different point, then reach the same target.

Great!

Not really effective... Maybe my remote doesn't work for this hotkey ? It happens sometimes. I will try again.
(I have to close MPC, open reclock configuration, change target and reopen MPC to see difference)

It really should work. Use "show vsync on screen" <ctrl><alt><shift>F9 to display the target and current position and make sure the target moves when you use F11/F12. If you have a problem mapping the default hotkeys you can change them in Reclock's config tool.

Just to be sure I understand well, at each position of Vsync target, one position of the green line, right ?

Pretty much. The green line (a.k.a. sync offset) is actually "start of presentation" and the Reclock target is "end of presentation" so the difference between the sync offset position and the Reclock target varies depending on how much work is involved in presentation and how fast your PC is. Eg. as I mentioned before, you will find if you press <ctrl>j a second time, to simplify the OSD, the Reclock-measured "end of presentation" jumps up, because the full OSD adds significant work to presentation and simplifying it reduces the presentation time. Reclock then pulls it back to target, so then sync offset moves down a little.

Basically, they are related and for the same player doing the same amount of work the green line will be in the same place for the same Reclock target but the precise position can change if the workload changes. Make sense?

 

[Kazuya]

Yes, understood. But the difference of workload between two videos could be huge !
Hope it will not change too much this presentation time !

 

[Jong]

No, its not the decoding time, just rendering time. It is player/renderer dependent and not dependent on media content or decoders.

It does vary a little between players/renderers, but rarely is the total time more than a few milliseconds (on an average modern PC) and the difference between players/renderers consequently even less. MadVR may be an exception because it is doing a lot of work, but right now it does not work with Reclock vsync correction and might never, so the issue is moot!

 

[Kazuya]

Ok !
Maybe when we use shaders this rendering time may increase ?

I tried several kind of videos and all seem to work well now, stabilize around 13,8ms. Hope it will always be like that !

 

[Kazuya]

Last night, a movie of 1 hour 40 without any drop !
Only 5 sync glitches. What are exactly glitches ? Bad timing frames ?

The green line settled at 13.4ms for that movie, 2.35movie, a little less than the other 1.85 video I saw (13.9).

 

[Jong]

Ideally you should not get any glitches either, they are when a frame is presented but too early or late for vsync, so visible (in the right scene) as judder. But a low number like 5 suggests it is not a burst of judder but maybe each is a single frame, possibly due to a green spike downward due to scheduling that does happen occasionally on XP. You may be able to reduce/eliminate by reducing background processes and activity. W7 is much better in this regard.

The av.offset is different (+/-~1ms) depending on what form of OSD is displayed (or no OSD). Also, Reclock only controls the position to an accuracy of around 0.5ms, so it will vary by that much from time to time even within a movie.

 

[Kazuya]

I'm not sure, but maybe glitches appear when I put the display stats on/off !
Try again tonight ! 8)

 

[leeperry]

You may be able to reduce/eliminate by reducing background processes and activity. W7 is much better in this regard.

the number of background processes in Vista/W7 is giving cold sweat...when I boot my XP box, I got 15 processes 8)

 

[Jong]

I'm not sure, but maybe glitches appear when I put the display stats on/off !
Try again tonight ! 8)

Yes, switching modes doesn't, but bringing the OSD up does. That could be it.

 

[Kazuya]

Yes, I checked and it was that !
Every time I make appear display stats, there's one glitch !
Then it's perfect, 0 glitch and 0 drop for a whole movie !
No tearing, perfect smoothness...

Thanks Jong !

And the last reclock provide a better sound that 1.8.5.4 !
Totally obvious !
It is so clear and sharp ! Unbelivable...

 

[Jong]

the number of background processes in Vista/W7 is giving cold sweat...when I boot my XP box, I got 15 processes 8)

W7 scheduling seems much improved on XP.

Early on I did have some problems with occasional "stalls" playing video, which could last even a second or two. I now make sure no "auto-update" tools are running and I disable Windows Search and Windows Update before playing video. No other tweaks. All now working perfectly.

 

[crisliv]

Hi,

First, pls excuse me in advance if the questions I ask here have been answered elsewhere already.
I did some research, but was not able to find any confirmation.

I use TMT3 plugin in MediaCenter, Win7 32b PC, ATI 4670 in HDMI to a proj (supports 24p).
I was formerly using it with S/PDIF output to my amp, ReClock configured in "accept bitstream" mode, it was working great, besides the occasional audio frame drops.

I decided to purchase an Asus Xonar HDAV 1.3 Deluxe, for 2 reasons: get some HD audio from blu rays, and have ReClock working the way it’s intended to. I now have this audio card, connected in Analog to my amp (amp does not have any HDMI inputs). TMT3 is configured in 5.1 to the Xonar.

But now I have issues:

• with TMT3 v170 or 175
  • ReClock enabled: no sound at all. ReClock shows “48000 Hz, 2 channel(s), 16 bits PCM” on Avatar BR (DTS HD-MA (48k 24 bits) stream)
  • ReClock disabled: sound is working great.
• Switching back to with an earlier version of TMT3 (160)
  • ReClock enabled: sound is working, I’m guessing it’s downsampled.
  • ReClock shows "48000 Hz, 6 channel(s), 16 bits PCM"

My conclusions, from what I understand:
Before TMT3 v170, ArcSoft did not support the Xonar as a full rate audio option, and used to downsample to 48k / 16b. You had to use the Asus version of TMT3.
From version 170, they backported the modifications they did in the Asus version (built-in support of the Xonar), and therefore there is no downsampling anymore using this card. But it requires a PAP.
And this is why there is no audio when using ReClock, as ReClock is PAP compliant?

Currently my options, as I know them, are:

• use latest TMT3 version with full def audio, but remove ReClock
  • annoying, I get occasional stutter, even though my refresh rate is 23.976 (pretty rare, but it’s there). Would love to keep ReClock working
• use older TMT3 (v160), with ReClock, but get downsampled audio
  • annoying as TMT3 will ask for an upgrade at each launch
  • moreover, it does not support some BRs unless AnyDVD is loaded (ex: Avatar), and no idea until when this will be working, on new BRs
• use PowerDVD9, with ReClock, and get downsampled audio
  • annoying & ironic, as I purchased the Xonar just because I prefer TMT3 over PDVD... I just hate PDVD.

Can somebody help me, at least to understand whether my conclusions are correct, and that there is currently no way to have this setup working?
Or should I keep trying to make it work?
Is there any other way to get this working as it should?

Any clue or information would be greatly appreciated, thanks...

 

[Qaq]

And the last reclock provide a better sound that 1.8.5.4 !
Totally obvious !
It is so clear and sharp ! Unbelivable...

I confirm. Just updated from 1855. Feelin' like got better XO and op-amps on my Essence. Thanks James.