MP1 EVR Presenter/dshowhelper community development (83 Viewers)

[Owlsroost]

As long as there is some juddering I consider it much bigger issue, much more annoying than slight color space issue.

Agreed

It is completely fixable if we either have a reference clock that we can adjust from renderer side or when GPU manufacturers provide HW that has single clock chip.

Agreed - but in the meantime, the ReClock style of generating a substitute 'render clock' (frequency locked to display refresh) and re-sampling the audio to match seems to be the best we can do.

Tony

 

[tourettes]

It is completely fixable if we either have a reference clock that we can adjust from renderer side or when GPU manufacturers provide HW that has single clock chip.

Agreed - but in the meantime, the ReClock style of generating a substitute 'render clock' (frequency locked to display refresh) and re-sampling the audio to match seems to be the best we can do.

Actually I have slight hope that following would provide good results (depends how Reclock is implementing the drift detection)

1) disable v-sync in Reclock (althou this would require some profiles to be available for Reclock since other application like TMTx will require the v-sync correction to be done on Reclock level)
2) enable the raster offset correction on renderer level, like you are now doing

After that Reclock should start to resample the audio to match the video presentation rate and the drifting issue shouldn't exist. But I might be too naive to think that Reclock would already work just like we want it to

 

[Owlsroost]

That's exactly how I think it should be working when ReClock is used with MP

Tony

 

[Jong]

Off-topic question for tourettes!

Have you considered trying to implement EVR onto an overlay surface as seems to be done my commercial Blu-ray players in disc mode. TMT3 also uses it for DVD playback. It does nothing for this judder problem (except Reclock vsync works fine with it), but it does mean that YCbCr is passed over HDMI unmolested - no conversion to/from RGB. Tests over at AVS Forum show the YCbCr values to be almost perfectly to spec (as measured at the other end of the HDMI cable). A significant improvement in colour quality over current solutions.

I guess you are talking about the new Windows 7 "overlay" more (not the same as in XP / Vista). Hardware Overlay Support (Windows)

Looks like it is having quite many restrictions and limitations even from driver support -> Exploring hardware overlay support in Windows 7 - virtualdub.org

As long as there is some juddering I consider it much bigger issue, much more annoying than slight color space issue. Especially when I don't have enough free money to buy proper tv and beamer

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.

It is completely fixable if we either have a reference clock that we can adjust from renderer side or when GPU manufacturers provide HW that has single clock chip.

Agreed - but in the meantime, the ReClock style of generating a substitute 'render clock' (frequency locked to display refresh) and re-sampling the audio to match seems to be the best we can do.

Actually I have slight hope that following would provide good results (depends how Reclock is implementing the drift detection)

1) disable v-sync in Reclock (althou this would require some profiles to be available for Reclock since other application like TMTx will require the v-sync correction to be done on Reclock level)
2) enable the raster offset correction on renderer level, like you are now doing

After that Reclock should start to resample the audio to match the video presentation rate and the drifting issue shouldn't exist. But I might be too naive to think that Reclock would already work just like we want it to

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 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 "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.

 

[tourettes]

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.

We'll see how well Reclock is able to fight against the drifting in that mode. At least I hope so. I can think two different ways how the Reclock could do it:

• by checking the display refresh rate on start up and then using a multiplier generated from that (for example 25.001 / 25) for the reference clock rate for the whole
• by analysing every v-sync / VBLANK period and making the reference clock adjustment based on that

#2 would in theory allow as good results as the v-sync correction, but I fear that it is the #1. Maybe James could tell that to us?

 

[Owlsroost]

Maybe it is other things causing the judder in this case, as you have hinted?

I'm beginning to think so - I suspect that the presenter code is dropping samples sometimes, somehow - this would (I think) produce the symptoms I'm seeing with the 'average time between samples' number changing but the reported sample durations being correct.

Tony

 

[Jong]

You can ask.

Certainly it tracks refresh rate continually, you can sometimes see it change in its display, normally only just after you clear the timing database and allow the icon to turn green, as later on the the averaging effect stored in the timing database makes changes uncommon. But without the feedback loop provided by vsync correction it does still drift. My experience though is, if in the judder zone it will stay there for >45 mins. I.e. not more than about 2ms of drift in that time, much worse without it. But that clearly will vary from system to system.

 

[tourettes]

Maybe it is other things causing the judder in this case, as you have hinted?

I'm beginning to think so - I suspect that the presenter code is dropping samples sometimes, somehow - this would (I think) produce the symptoms I'm seeing with the 'average time between samples' number changing but the reported sample durations being correct.

Sample durations from where? The real duration or the one reported by DS / EVR mixer? Such horrible judder would be (in my opinion) result from a wrong v-sync that is used to be presented (that throws of the stat lines exactly in the fashion you have seen... zig-zag pattern ).

Good news is that there is a API in Windows 7 that you can use to track down the v-sync number (not suitable for MP1, but only for debugging purposes since we need to remain XP compatible).

Direct3D 9Ex Improvements (Windows) / D3DPRESENTSTATS Structure (Windows)

 

[Jong]

Maybe it is other things causing the judder in this case, as you have hinted?

I'm beginning to think so - I suspect that the presenter code is dropping samples sometimes, somehow - this would (I think) produce the symptoms I'm seeing with the 'average time between samples' number changing but the reported sample durations being correct.

Tony

My last test does suggest ar-jar's code is vulnerable when its required correction is almost precisely the frame duration. Like it has not truly solved the problem and itself cannot decide which vsync to target. It continually and regularly drops frames similar to the way you described when you said you were getting 33.333fps.

 

[tourettes]

Maybe it is other things causing the judder in this case, as you have hinted?

I'm beginning to think so - I suspect that the presenter code is dropping samples sometimes, somehow - this would (I think) produce the symptoms I'm seeing with the 'average time between samples' number changing but the reported sample durations being correct.

Tony

My last test does suggest ar-jar's code is vulnerable when its required correction is almost precisely the frame duration. Like it has not truly solved the problem and itself cannot decide which vsync to target. It continually and regularly drops frames similar to the way you described when you said you were getting 33.333fps.

I guess there the Windows 7 API about present stats would be handy since you could just decide quickly if the next v-sync is the correct one where to present the frame.