Reply to thread

Message

<blockquote data-quote="Jong" data-source="post: 609699" data-attributes="member: 104040">I agree too. Just an aside, subject closed!I was just interested in your thoughts. Actually though, I am not sure if this is a W7 thing. It has long been a subject of confusion for some of us that TMT and PDVD, even on XP, show as using EVR in Graphedt and Reclock, yet in other ways appear to use Overlay - if you try to screengrab you end up with a transparent image that shows through whatever is behind it. The passthrough of BTB/WTW and lack of RGB conversion artifacts re-enforces this. TMT support have specifically said they use EVR in conjunction with Overlay, NOT overlay mixer as we normally understand it. I don't think anyone has satisfactorily explained how this works and I wondered if you knew. Not top priority for development though I agree.As I have said before, this is exactly how &quot;Present at Nearest&quot; works in mpc-hc, which is why I have been confused when some say it does not here. It is why I wondered if you were using ar-jar's code or not. I must admit I have not done extensive testing as I use Reclock vsync correction with all EVR sync options off, but it seemed to work when i tried it and others, including ar-jar, say it is fine. Maybe it is other things causing the judder in this case, as you have hinted?Just to be clear, when Reclock vsync correction is OFF, Reclock does not do real time drift detection. Reclock just improves the reference clock by using the system timer, adjusted for what it sees as the average error of the GPU clock, as stored in the timing database. Without vsync correction Reclock will still drift, just more slowly.Actually, I have just done some tests with mpc-hc and there does seem to be a problem with Present at Nearest there too, if the &quot;sample Paint Time Correction&quot; is bang on 20ms @50Hz. Horrible judder, as was said, running at a low frame rate. Looks like there is still a small window when it does not know which vsync to target.</blockquote>

[QUOTE="Jong, post: 609699, member: 104040"] I agree too. Just an aside, subject closed! I was just interested in your thoughts. Actually though, I am not sure if this is a W7 thing. It has long been a subject of confusion for some of us that TMT and PDVD, even on XP, show as using EVR in Graphedt and Reclock, yet in other ways appear to use Overlay - if you try to screengrab you end up with a transparent image that shows through whatever is behind it. The passthrough of BTB/WTW and lack of RGB conversion artifacts re-enforces this. TMT support have specifically said they use [I]EVR in conjunction with Overlay[/I], NOT overlay mixer as we normally understand it. I don't think anyone has satisfactorily explained how this works and I wondered if you knew. Not top priority for development though I agree. As I have said before, this is exactly how "Present at Nearest" works in mpc-hc, which is why I have been confused when some say it does not here. It is why I wondered if you were using ar-jar's code or not. I must admit I have not done extensive testing as I use Reclock vsync correction with all EVR sync options off, but it seemed to work when i tried it and others, including ar-jar, say it is fine. Maybe it is other things causing the judder in this case, as you have hinted? Just to be clear, when Reclock vsync correction is OFF, Reclock does not do real time drift [I]detection[/I]. Reclock just improves the reference clock by using the system timer, adjusted for what it sees as the average error of the GPU clock, as stored in the timing database. Without vsync correction Reclock will still drift, just more slowly. Actually, I have just done some tests with mpc-hc and there does seem to be a problem with Present at Nearest there too, if the "sample Paint Time Correction" is bang on 20ms @50Hz. Horrible judder, as was said, running at a low frame rate. Looks like there is still a small window when it does not know which vsync to target. [/QUOTE]

Verification