Reply to thread

Message: <blockquote data-quote="Jong" data-source="post: 609951" data-attributes="member: 104040">Yeah, I am aware it can be done by manipulating the registry. this is what I meant here, in my first postBut you need to be sure to re-enable it on player exit, or each player has to be run with a pre-queue command, configuring Reclock. All do-able, but not elegant! <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile    :)" loading="lazy" data-shortname=":)" />It is very hard to get Reclock vsync correction to work together with something else that is forcing the point of presentation. What happens is your presenter is forcing the start of presentation (SOP), so Reclock cannot control the end of presentation (EOP). If you could guarantee you always kept it inside the Reclock target, all would be fine, but ar-jar's code is actually pretty lax - you cannot ask for a greater accuracy than 1ms - and at my request Reclock's is tighter (about 0.5ms). I asked for this because of the problem I mentioned earlier, that Reclock only adjusts the clock until EOP is inside its target. It does not try to get it to the middle, or better, the opposite edge from the direction of drift. The result of this was Reclock's, old, wide target zone just eat into our safety margin - we had to set the upper edge of the vsync target so it was never too close to the preceding vsync,  but then the lower edge was eating into the margin of protection against scheduling delays etc. So ar-jar's code, at least, will always be happy at values that Reclock will not be happy with, although you might get lucky. I guess you could change the EVR Presenter tolerances, but I think you would find it tough to control it to <0.5ms accuracy! Reclcok is only checking the average is in this range.What happens when the EVR presenter is forcing a SOP that leads to an EOP outside of Reclock's target is Reclcok starts to run the reference clock to fast or slow. But, even though the "Raster offset" moves, the SOP, hence EOP, never moves - EVR Presenter alters its  "Sample Paint Time Correction" to compensate. So Reclock continually runs the clock too fast or slow for the refresh rate and you get what I call "rolling sync", where frames are regularly dropped/repeated. The frequency of these drops/repeats depends on how far away from the Reclock target the presenter target is (as I said before Reclock adjusts the clock more the further away EOP is from its target), the severity of the judder works the other way, judder is worse the closer you are to the Reclock target, because then the frame rate is very close to the proper rate and EOP remains in the danger zone for longer. Just try changing the EVR presenter target, as you can do in mpc-hc "sync settings". If you set the point away from the Reclock target you will see the "roll" is faster, but the judder on each roll briefer. There is another problem with trying to use Reclcok vsync and "present at nearest" together. As mentioned before, at least in mpc-hc, the OSD and potentially other things too can alter the gap between SOP and EOP. Because Reclcok is measuring EOP and EVR Presenter is controlling SOP, even if you managed to get Reclock and the presenter to agree for particular settings, it will all fall apart if the OSD is on or if different media/settings (even post-processing shaders, maybe?) are used.I don't think the two are compatible.For the record, here, with Reclock vsync off, I get no perceptible drift in 30 mins of playback with 25p material @50Hz or 24p material, sped up to 25p. The "Sample Paint Time Correction" is exactly the same, to the ms, after 30 mins.In fact even with Reclock off I got very little consistent drift, with my 5750 GPU (my old cards were significantly worse, but maybe luck rather than by design) although it was noticeable that the "Actual Frame Rate" and the "Sample Paint Time Correction" oscillated more with Reclock off - about 3ms in the case of "Sample Paint Time Correction". With Reclock the "Actual Frame Rate" was rock solid on 25.000Hz or 23.976Hz and the "Sample Paint Time Correction" was generally rock solid too, occasionally flitting between 2 values, presumably depending if the mean was in between these two values or near to one or the other.</blockquote>

Verification