Reply to thread

Message

<blockquote data-quote="Jong" data-source="post: 609261" data-attributes="member: 104040">So, correct me if I am wrong, when it is &quot;free&quot; the two are almost the same, but otherwise (in your normal code and more so with the owlsroost mod?) there is an offset applied which depends on how the &quot;raster offset&quot; compares with the targeted location?My point was that this offset will change over time, very slowly if the rates are &quot;compatible&quot; (depending on the GPU/reference clock drift), much faster eg. if playing 23.976fps @24.000hz or 60Hz. But in either case they will drift. Only Reclock in &quot;vsync correction&quot; mode can use its feedback loop to fix this in all cases (although EVR Sync renderer can fix it using a similar method when the rates are &quot;compatible&quot;). Also, if it is left &quot;free&quot;, this free position will drift.On your last point, EVR Sync renderer in &quot;Present at nearest&quot; mode is compatible with Reclock, when vsync is not enabled, without any special &quot;hooks&quot;. Is there a reason why this cannot just be &quot;lifted&quot;?Yes, Reclock makes very small adjustments to the reference clock to pull the &quot;raster offset&quot; to a targeted position, user selectable. The size of the adjustment depends on how far away from the target it is. It slows down as it gets close to avoid overshoot. EVR Sync's &quot;Sync video to display&quot; does similar, but does not slow down it's offset as it approaches the target.You are wrong about the goal of Reclocks' vsync correction. It was always about eliminating synchronised frame rate/refresh rate judder. Ogo realised that when he had a really accurate reference clock there would be times when the point of presentation would be so close to the vsync that sometimes it would fall one side of the line and sometimes the other, causing judder, (<a href="http://software.intel.com/en-us/articles/video-frame-display-synchronization/" target="_blank">Video Frame Display Synchronization - Intel® Software Network</a>, figure 5) and that with an accurate clock this state could go on and on and on. Indeed, on my system, with Reclock on and vsync correction off, synchronised judder after a seek can go on for &gt;45mins!! I personally do not find Reclock vsync correction outdated firstly because its feedback loop does eliminate any chance of drift, second because it works with commercial Blu-ray players (and, as it happens, TMT in DVD disc mode), which we still need to play Blu-ray discs, rather than .m2ts or mkv rips, third it works when changing playback speed (24p@25p or 25p@24p). But I get your point, if 1) and 2) above are in place, as they kind of are when using Reclock (which improves the reference clock) and &quot;present at nearest&quot; (similar to owlsroost mod?), things should be close to perfect. It still will not be quite as robust though as:- without the &quot;feedback loop&quot; there can still be drift.- I am not sure it is possible to use the GPU clock &quot;raw&quot; as the reference clock as I am not sure it will be accurate enough for audio especially, although I accept the GPU clock is probably a lot better now than when Ogo first conceived Reclock.- in any case, this solution only works when rates are &quot;compatible&quot;. it does not work for 24p@25p or even 24p(23.976fps) @24Hz&nbsp; or 60Hz.Also or course, there is no alternate reference clock without Reclock, although one could of course be written.</blockquote>

[QUOTE="Jong, post: 609261, member: 104040"] So, correct me if I am wrong, when it is "free" the two are almost the same, but otherwise (in your normal code and more so with the owlsroost mod?) there is an offset applied which depends on how the "raster offset" compares with the targeted location? My point was that this offset will change over time, very slowly if the rates are "compatible" (depending on the GPU/reference clock drift), much faster eg. if playing 23.976fps @24.000hz or 60Hz. But in either case they will drift. Only Reclock in "vsync correction" mode can use its feedback loop to fix this in all cases (although EVR Sync renderer can fix it using a similar method when the rates are "compatible"). Also, if it is left "free", this free position will drift. On your last point, EVR Sync renderer in "Present at nearest" mode is compatible with Reclock, when vsync is not enabled, without any special "hooks". Is there a reason why this cannot just be "lifted"? Yes, Reclock makes very small adjustments to the reference clock to pull the "raster offset" to a targeted position, user selectable. The size of the adjustment depends on how far away from the target it is. It slows down as it gets close to avoid overshoot. EVR Sync's "Sync video to display" does similar, but does not slow down it's offset as it approaches the target. You are wrong about the goal of Reclocks' vsync correction. It was always about eliminating synchronised frame rate/refresh rate judder. Ogo realised that when he had a really accurate reference clock there would be times when the point of presentation would be so close to the vsync that sometimes it would fall one side of the line and sometimes the other, causing judder, ([url=http://software.intel.com/en-us/articles/video-frame-display-synchronization/]Video Frame Display Synchronization - Intel® Software Network[/url], figure 5) and that with an accurate clock this state could go on and on and on. Indeed, on my system, with Reclock on and vsync correction off, synchronised judder after a seek can go on for >45mins!! I personally do not find Reclock vsync correction outdated firstly because its feedback loop does eliminate any chance of drift, second because it works with commercial Blu-ray players (and, as it happens, TMT in DVD disc mode), which we still need to play Blu-ray discs, rather than .m2ts or mkv rips, third it works when changing playback speed (24p@25p or 25p@24p). But I get your point, if 1) and 2) above are in place, as they kind of are when using Reclock (which improves the reference clock) and "present at nearest" (similar to owlsroost mod?), things should be close to perfect. It still will not be quite as robust though as: - without the "feedback loop" there can still be drift. - I am not sure it is possible to use the GPU clock "raw" as the reference clock as I am not sure it will be accurate enough for audio especially, although I accept the GPU clock is probably a lot better now than when Ogo first conceived Reclock. - in any case, this solution only works when rates are "compatible". it does not work for 24p@25p or even 24p(23.976fps) @24Hz or 60Hz. Also or course, there is no alternate reference clock without Reclock, although one could of course be written. [/QUOTE]

Verification