MP1 EVR Presenter/dshowhelper community development (6 Viewers)

[Jong]

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.

Yeah. I do not know it's method. A long time ago I thought I knew there was a way to awaken a thread at the end of presentation, akin to an interrupt, but in a quick search today I could not find it.

Anyway, it is clear that it does.:

- The position of the Reclock marker is related to, although some ms after, the "Present at nearest" target, when enabled
- With the same "Present at nearest" target, it's position on the screen varies (i.e. its distance from the "Present at nearest" target ) depending on whether the OSD is running and how much work it is doing (is it displaying a graph etc.)
- if double buffering is used it is hard pinned to the top of the screen i.e. vsync. The fact it is then pinned in hardware is shown by the fact there is almost no spread, no little dots, just line or a line with a very tight little line crossing it.

So the problem is if the Presenter is fixing SOP relative to vsync, it is also fixing EOP, allowing for scheduling/processing spread.

This means if EOP is outside of Reclock's target, even though it will try to correct it, the EVR Presenter will merely compensate by changing its "Sample Paint Time Correction". The raster offset moves but Reclock cannot tell, so it keeps on running the clock too fast (or slow) and "rolling sync" occurs. This is why you saw judder get worse when Reclock vsync correction was enabled. Reclock was continually running at, ever so slightly, the wrong frame rate.

The only time this will not happen is if you are fortunate enough to set the Presenter (or Reclock's vsync target) in just the right place and with tight enough tolerance that Reclock turns off its vsync correction, but then of course it is not doing anything anyway! And if drift is eventually a problem the Presenter will hide this from Reclock ("Sample Paint Time Correction" will change, not SOP or EOP) and its vsync correction will never kick in.

 

[Owlsroost]

Hi Jong,

I could try to target/fix the Presenter EOP position instead of the SOP - the code already gathers 'average paint time' stats, so in theory it shouldn't be a big deal (I'd had some thoughts about doing it a while ago). It might be an improvement anyway since the paint time seems to vary with GPU load, different codecs etc

On a related subject, do you know of an easy way of getting information or measuring the clock rate of the render clock ? - e.g when ReClock does PAL speedup/speeddown the clock rate is +/-4% different from the nominal rate.

Tony

 

[tourettes]

I could try to target/fix the Presenter EOP position instead of the SOP - the code already gathers 'average paint time' stats, so in theory it shouldn't be a big deal (I'd had some thoughts about doing it a while ago). It might be an improvement anyway since the paint time seems to vary with GPU load, different codecs etc

EOP indeed might be better since GUI, codecs etc. are affecting. Also if the Present() goes beyond the safe presentation window the frame will get drawn on next + 1 v-sync (dont ask me where that is, is it driver or GPU specific etc... there is just no documentation).

On a related subject, do you know of an easy way of getting information or measuring the clock rate of the render clock ? - e.g when ReClock does PAL speedup/speeddown the clock rate is +/-4% different from the nominal rate.

By an interface to Reclock Actually if reclock implements audio render interface it should be already available (it should provide the Hz information, not sure if it is accurate enough).

 

[Jong]

Hi Jong,

I could try to target/fix the Presenter EOP position instead of the SOP - the code already gathers 'average paint time' stats, so in theory it shouldn't be a big deal (I'd had some thoughts about doing it a while ago). It might be an improvement anyway since the paint time seems to vary with GPU load, different codecs etc

On a related subject, do you know of an easy way of getting information or measuring the clock rate of the render clock ? - e.g when ReClock does PAL speedup/speeddown the clock rate is +/-4% different from the nominal rate.

Tony

Yes, EOP sounds like a safer thing to set, regardless of Reclock. Don't think this. by itself, will help us use Reclock vsync correction in combination with your code though.

I don't pretend to know the answer to your second question. One place I would try though is to see how Sync Renderer calculates its "Actual Frame Rate". Even when speeding up 23.976fps material to 25p this still shows 23.976. But when vsync correction kicks in, this speeds up or slows down slightly, showing the correction Reclock is making to move EOP to its target. If you force Reclock to playback at the original speed then this figure jumps all over the place, so it cannot be used as it is, but it looks like if you look at the formula you might be able to derive the correction being applied?

I have had a thought, though, about how you might be able to use Reclock to fix drift without access to a special API!

It seems to me that if you could control EOP accurately enough to ensure Reclock vsync correction does not normally engage, you could 'simply':

- make a note of the "Sample Paint Time Correction" at the start of playback - the adjustment you are making to ensure SOP is at a safe point.
- allow it to drift, say, 70% of a frame without turning on Reclock vsync correction
- when it gets to this point, make your presenter deliberately push your EOP target outside of Reclock's comfort zone in the direction that will bring the "Sample Paint Time Correction" back to its original position.
- The further EOP is from the target the greater the clock adjustment Reclock will make, so to minimise the time any audio pitch adjustment is being made it might be worth making the EOP move quite a way at the start (but still 'safe', of course) and then slowly move it back towards its normal position as "Sample Paint Time Correction" gets close to its original position, to minimise potential for overshoot.

There should never be a need for any frame drop (major Windows scheduling gaffs aside!) and, if the original media speed and refresh rate are compatible (24p@23.976Hz, 24p@59.94Hz, 25p@50Hz) the audio will only have to be pitch corrected once or twice in a movie for a few seconds. The adjustments are truly tiny so it should be inaudible anyway, but for those that don't like any "messing" this is much closer. Of course PCM audio is still being resampled, this is unavoidable if Reclock is improving the reference clock, but most of the time it will be very benign and the upside is no dropped frames at all!

If you have a problem setting EOP tightly enough to ensure Reclock vsync correction is not engaged unless you want it to be we could ask James to add a registry value that defines the size of the Reclock target zone. As I mentioned before, it used to be much larger, about 3ms and he reduced the value for me to 0.5ms. I imagine he would be happy to let this be defined in the registry as a percentage of screen size.

What do you think?

 

[Owlsroost]

To be honest Jong, provided ReClock's substitute render clock is accurate and stable enough to keep the display vsync and render 'vsync' phasing within a few ms over (say) 30 minutes - which I suspect it is, based on my experience as a user - I'm happy. If James could modify it so that it uses display vsync feedback to correct the render clock in real time that would be even better

The MP presenter can already handle the display vsync correction to avoid the presentation time/vsync co-incidence judder problem (in conjunction with the sample queue it has internally) - it probably needs some improvement, but that's in the pipeline

Tony

 

[tourettes]

I have had a thought, though, about how you might be able to use Reclock to fix drift without access to a special API!

It seems to me that if you could control EOP accurately enough to ensure Reclock vsync correction does not normally engage, you could 'simply':

- make a note of the "Sample Paint Time Correction" at the start of playback - the adjustment you are making to ensure SOP is at a safe point.
- allow it to drift, say, 70% of a frame without turning on Reclock vsync correction
- when it gets to this point, make your presenter deliberately push your EOP target outside of Reclock's comfort zone in the direction that will bring the "Sample Paint Time Correction" back to its original position.
- The further EOP is from the target the greater the clock adjustment Reclock will make, so to minimise the time any audio pitch adjustment is being made it might be worth making the EOP move quite a way at the start (but still 'safe', of course) and then slowly move it back towards its normal position as "Sample Paint Time Correction" gets close to its original position, to minimise potential for overshoot.

Sounds like an ugly hack, I would even prefer a self written audio renderer that has a nice and clean interface to control the reference clock speed. EOP cannot be controlled tightly, looks like GPU and drivers just differ a lot between different frames. There seems to be even over 200 lines differences when the :resent() call returns. Also I think is shouldn't matter to the playback quality in general how long the :resent() call takes (as long as it wont force the frame to incorrect v-sync), just that it confuses Reclock's algorithm as a side effect (DirectX wont change the presentation point anyhow, it is directly linked to the v-sync time).

So, I would prefert to have a reference clock that can be adviced correctly. Preferably Reclock, since it has all the audio resampling ready (multiple audio formats etc. will take quite long to implement properly, especially when I have no knowlwdge on that area at all...)

If no one else asks James opinion to extend the Reclock to allow external component to give advices in the v-sync off mode I'll ask from him as soon as I get back from vacation.

 

[Owlsroost]

If no one else asks James opinion to extend the Reclock to allow external component to give advices in the v-sync off mode I'll ask from him as soon as I get back from vacation.

I think it might be better if someone with reasonable Windows programming knowledge - e.g Jong or yourself, not me - talked to James about this.

In the meantime, have a good vacation - and try not to think too much about programming problems

Tony

 

[Jong]

display vsync correction to avoid the presentation time/vsync co-incidence judder problem (in conjunction with the sample queue it has internally) - it probably needs some improvement, but that's in the pipeline

Sounds like an ugly hack.

Well, at least you're honest, guys!

However, I would say the following:

- the whole of Reclock is an ugly hack that has stood the test of time for going on a decade!
- If you don't think its worth doing the code on your side because MP is already good enough, you could understand James not being over keen, with the other paid for work he is doing!
- I honestly think this effectively gives you 95% of what you want - the ability to signal to Reclock that you want it to adjust the raster offset, the direction you wish it to move in and even how fast you want it to move. You actually do not need to control EOP that tightly - Reclock looks at the average over several frames, not any one frame and at its simplest it is a binary (or tertiary) setting - OFF (in the target zone), SPEED UP, SLOW DOWN (either side of the target).
- the only thing you cannot do with this method is turn off resampling, but i know what James will say to that - resampling is what Reclock is all about. It is constantly manipulating its clock to ensure the frame rate and refresh rate are spot on. If you don't want that don't use Reclock! If you are sure that you already have perfectly matching rates you can use bitstream mode to pass HD audio unmolested, but better, just don't use Reclock!

Feel free to raise with James, you may catch him on a good day. As I said before it would be better if you had the mpc-hc team also on your side so you are not asking for hooks just for one player. There is an elegance in what you suggest, but, as owlsroost says, not a huge benefit for that elegance!

 

[Owlsroost]

Hi Jong,

I know that the response to your suggestions (which are very much appreciated, as are all your other comments) might come across a bit as 'thanks but no thanks', but part of the problem is that the MP presenter has to do the best it can in situations where ReClock can't be used e.g. live TV (which is a big part of MP usage for many users, me included). So if we can arrive at a good vsync correction scheme for those 'no ReClock' situations, I can't see the point in spending a lot of time trying to design/debug a feedback control system to work with/around the behaviour of the ReClock vsync correction system.

Tony

 

[red5goahead]

Hi Jong,
I know that the response to your suggestions (which are very much appreciated, as are all your other comments) might come across a bit as 'thanks but no thanks', but part of the problem is that the MP presenter has to do the best it can in situations where ReClock can't be used e.g. live TV (which is a big part of MP usage for many users, me included). So if we can arrive at a good vsync correction scheme for those 'no ReClock' situations, I can't see the point in spending a lot of time trying to design/debug a feedback control system to work with/around the behaviour of the ReClock vsync correction system.
Tony

I agree. Media Portal should work without Reclock for those users have a video device fully compatibility with 24P and Pal even (how many? I'm not sure is the majority) For those users it haven't Reclock still fundamental as in any other players.
So Imho the key is get information from reclock (if allowed by the developer) about its current job and decide to disable MP internal vsynch and let reclock to do it. Basicaly in pal speedup/down situation. (with live tv this is not important)