MP1 EVR Presenter/dshowhelper community development (2 Viewers)

[tourettes]

I did some experiment with Reclock and MP cock fight (only short time, but looks quite promising)

0) do not enable Reclock
1) use Owlsroost's DLL (the one that forces v-sync / raster offset correction at least for 1:1 and 1:2 cases)
2) run different material with that DLL and write down SOP and EOP line values (should be around 200 and 500 to 600)
3) use following formula to calculate the "sweet spot" -> (SOP / EOP) * 100 -> this will give the middle point of the presentation window MP uses
4) make sure Reclock is not active (no media player applications open)
5) open registry editor (win+r -> regedit)
6) open HKEY_CURRENT_USER->Software->ReClock->Config
7) edit VsyncTarget (in DECIMAL!) -> put the "sweet spot" value here
8) enable v-sync correction in Reclock's config
9) make sure MP uses Reclock as audio renderer
10) test, test, test... and report back

What that should do is to make sure that Reclock and EVR presenter are both targeting the v-sync into same raster offset area. That way we should be having quite accurate playback.

A side note for Jong, as Reclock has registry setting for the v-sync enable / disable, it would be easy for MP to disable it if we cannot get Reclock's v-sync to work properly with MP's EVR presenter. But I had pretty bad experience with the Reclock and non-v-sync correction mode. It did drive the playback / v-sync into stuttering are really quickly (didn't take many minutes... where as MP itself has no issues with 30 minutes in the same 1:2 test DVD I have).

 

[red5goahead]

Anyway . Do you talk about the target windows or the vSynch dots painted during playback?
If you choose a value 88 for vysnc target position (the slide on the right or the HCU\software\reclock\VsyncTarget value) the target window will be at the bottom of the screen (in my case and my system the correct position is 22).

Actually I was talking about the fact that Reclock is unable to draw those stats on my system for some reason.

Assumed you aren't in Dxva mode I post my reclock configuration:

Check this out,

If you are in NV12 colour space also in sw mode and Dxva mode is off in vsynch correction setup section the bottom check box will be disabled during play so no vsynch correction and no osd display related.

Trust me . MP and Reclock with Vmr9 so vSynch correction is active is perfect . no stuttering for hours ! MP+Reclock together are awesome

 

[Owlsroost]

I'm going to put some counters into the code so I can check if 'samples in = samples popped' when the problem happens - that should prove if the MP code is mis-behaving or if the incoming sample data is incorrect/jittery.

BTW, this is happening with SD MPEG-2 (live SD TV, no ReClock) on a system with more than enough CPU/GPU power to cope with it.

Tony

Well, the good news is that the sample queue management looks OK (it maintains a constant queue depth of 4), so it looks like it's something earlier in the chain.

The interesting thing is that when it happens, pausing playback briefly (< 1s) will fix the problem - I did that earlier with a badly juddering live TV stream and it's fine more than an hour later.

So is it tsreader.ax, the decode filter, nvidia dxva or something else that's causing the problem (which feels a bit like data starvation somewhere down the line) ?

Tony

 

[cecet23]

I did some experiment with Reclock and MP cock fight (only short time, but looks quite promising)

0) do not enable Reclock
1) use Owlsroost's DLL (the one that forces v-sync / raster offset correction at least for 1:1 and 1:2 cases)
2) run different material with that DLL and write down SOP and EOP line values (should be around 200 and 500 to 600)
3) use following formula to calculate the "sweet spot" -> (SOP / EOP) * 100 -> this will give the middle point of the presentation window MP uses
4) make sure Reclock is not active (no media player applications open)
5) open registry editor (win+r -> regedit)
6) open HKEY_CURRENT_USER->Software->ReClock->Config
7) edit VsyncTarget (in DECIMAL!) -> put the "sweet spot" value here
8) enable v-sync correction in Reclock's config
9) make sure MP uses Reclock as audio renderer
10) test, test, test... and report back

What that should do is to make sure that Reclock and EVR presenter are both targeting the v-sync into same raster offset area. That way we should be having quite accurate playback.

A side note for Jong, as Reclock has registry setting for the v-sync enable / disable, it would be easy for MP to disable it if we cannot get Reclock's v-sync to work properly with MP's EVR presenter. But I had pretty bad experience with the Reclock and non-v-sync correction mode. It did drive the playback / v-sync into stuttering are really quickly (didn't take many minutes... where as MP itself has no issues with 30 minutes in the same 1:2 test DVD I have).

I tried this options....it seems that work pretty good... I watched a film (25fps:50hz) and I didn't see any stutter (with direchtshowhelper v004) in 20 minutes... I tried avi video with same result...no stutter in 20 minutes...this with osd closed.

With osd opened I noted the red line go up and down a few time every 3 - 4 minutes...but seems without stutter.. I have to investigate better tomorrow..

 

[Jong]

A side note for Jong, as Reclock has registry setting for the v-sync enable / disable, it would be easy for MP to disable it if we cannot get Reclock's v-sync to work properly with MP's EVR presenter.

Yeah, I am aware it can be done by manipulating the registry. this is what I meant here, in my first post

Offering this will also help people who use a commercial Blu-ray player and need to use Reclock vsync correction to avoid this problem in those players. otherwise they need to turn off vsync correction when MediaPortal's player is used and turn it on again eg. for TMT or PDVD. This is possible by changing the registry prior to loading the player software, but that is a clumsy hack at best!

But 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!

What that should do is to make sure that Reclock and EVR presenter are both targeting the v-sync into same raster offset area. That way we should be having quite accurate playback.

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.

 

[tourettes]

WRONG WRONG WRONG!

I did some experiment with Reclock and MP cock fight (only short time, but looks quite promising)

3) use following formula to calculate the "sweet spot" -> (SOP / EOP) * 100 -> this will give the middle point of the presentation window MP uses

No clue why I was writing such formula, it is complately wrong Also the correct formula wont give the middle of presentation window (the definition that I wrote is quite different).

The correct formula for "sweet spot" is: ((EOP - SOP) / height of screen) * 100 and to fine tune that you need to reduce the EOP with some magic number, that depends on how slow your GPU is since stats rendering takes more time and affects SOP & EOP. More time will be taken on slower GPUs.

 

[Owlsroost]

If you are trying to calculate the middle of the SOP -> EOP interval as a percentage of screen height, shouldn't the formula be:

"sweet spot" = ((((EOP - SOP)/2) + SOP) / screen height) * 100

Tony

 

[tourettes]

If you are trying to calculate the middle of the SOP -> EOP interval as a percentage of screen height, shouldn't the formula be:

"sweet spot" = ((((EOP - SOP)/2) + SOP) / screen height) * 100

Yes, it should be that. I guess I should have woken up first before posting, basic math is just sometimes too hard

 

[Jong]

If you are trying to calculate the middle of the SOP -> EOP interval as a percentage of screen height, shouldn't the formula be:

"sweet spot" = ((((EOP - SOP)/2) + SOP) / screen height) * 100

Yes, it should be that. I guess I should have woken up first before posting, basic math is just sometimes too hard

One of us is missing something here though guys (quite prepared to accept it is me!).

What you seem to be trying to do is use Reclock vsync correction to fix drift, but as my long rambling, possibly incoherent, post above said is that as soon as you turn on your vsync correction you break Reclock's feedback loop. Reclock adjusts the "raster offset" by measuring EOP. It relies on EOP occurring, on average, a fixed time after "raster offset" (asynchronous to vsync), but when the Presenter fixes SOP this link is broken. It wont work. For Reclock to do what you want it would need to have another point of reference that either was your "raster offset" or is at least related to it and for that you would need the special API you have discussed.

Or are you trying to do something else altogether?!

 

[tourettes]

If you are trying to calculate the middle of the SOP -> EOP interval as a percentage of screen height, shouldn't the formula be:

"sweet spot" = ((((EOP - SOP)/2) + SOP) / screen height) * 100

Yes, it should be that. I guess I should have woken up first before posting, basic math is just sometimes too hard

One of us is missing something here though guys (quite prepared to accept it is me!).

What you seem to be trying to do is use Reclock vsync correction to fix drift, but as my long rambling, possibly incoherent, post above said is that as soon as you turn on your vsync correction you break Reclock's feedback loop. Reclock adjusts the "raster offset" by measuring EOP. It relies on EOP occurring, on average, a fixed time after "raster offset" (asynchronous to vsync), but when the Presenter fixes SOP this link is broken. It wont work. For Reclock to do what you want it would need to have another point of reference that either was your "raster offset" or is at least related to it and for that you would need the special API you have discussed.

I was planning to answer to you long "rambling" but haven't had any change during the workday (and I might be unavailable whole next week).

I think I yet haven't understood completely the algorithm how Reclock behaves (nice to have closed source component with no good documentation ).

Some quick notes:

• One thing I cannot understand is that how Reclock is able to detect the EOP.
• If Reclock only "tries" to drive the SOP by adjusting the reference clock wide enough presentation window should not interfere with Reclock's algorithm.

But of course that is far from perfect and still quite vulnerable for different issues (two correction algorithms cannot be good, unless they are targeted to correct the faults in each other).

My vacation (if flights is possible...) comes into "bad" time, so could you Jong or Owlsroost ask James opinion about the possibility to have a interface in Reclock? Mainly about the idea overall and how he sees it. Interface should just allow

1) toggling the v-sync on / off (to reduce registry hack and wrong setting leaved as set if crash occurs)
2) Advising reference to speed / slowdown when v-sync is disabled
(3) as extra reclock could provide some stats to help rendering in later stages)

Just remind him that many MP / MPC-HC etc. users have bough AnyXXX (me included) and more would by if Reclock when it is working nicely together with those players.

Implementing the EVR presenter "steering" control for reference clock speedup / slowdown is already ready (ar-jar's genlock code is perfect for this usage).