MP1 EVR Presenter/dshowhelper community development (26 Viewers)

[Jong]

Allow an advanced option to turn off all vsync correction as per EVR Sync, which would allow people using Reclock to let Reclock do everything, including vsync (with Aero ON), as it seems was possible until recently.

+1

For 1:1 material there is no v-sync / raster offset correction in the EVR presenter code. Only for the 1:2 material. So I decided to test the 1:2 material with ReClock and removing the raster offset correction. Not good, ReClock is not able to detect the refresh rate on my dev PC and it wont try the v-sync correction at all As a result the 1:2 playback is worser with ReClock than it is without it.

I assume you are using the latest version of Reclock.

Have you tried the earlier version of the renderer that Red5 says worked?

You might also need to play with your Reclock settings, as you said you do not usually use it (again red5 may be able to tell you what he used). Reclock should be able to detect the refresh rate, by default it uses GDI. If using pstrip it can use that too. I have seen problems some time ago with frame rate detection, but not refresh rate. You do need to play it some material for a while, when first installed, until the the Reclock icon switches from flashing red/green to being stable green, but that will never happen if you are not even detecting the refresh rate!

 

[tourettes]

Allow an advanced option to turn off all vsync correction as per EVR Sync, which would allow people using Reclock to let Reclock do everything, including vsync (with Aero ON), as it seems was possible until recently.

+1

For 1:1 material there is no v-sync / raster offset correction in the EVR presenter code. Only for the 1:2 material. So I decided to test the 1:2 material with ReClock and removing the raster offset correction. Not good, ReClock is not able to detect the refresh rate on my dev PC and it wont try the v-sync correction at all As a result the 1:2 playback is worser with ReClock than it is without it.

After cleaning up the video refresh rate database multiple times an restarting MP for multiple times ReClock was suddenly able to detect the refresh rate of the monitor.

Now the problem is that both current EVR presenter version and the one that I disabled the raster offset correction work nicely with ReClock with v-sync correction in ReClock enabled. Go figure.

 

[tourettes]

Jong, I'll get back to your long theory post tomorrow.

 

[red5goahead]

+1

For 1:1 material there is no v-sync / raster offset correction in the EVR presenter code. Only for the 1:2 material. So I decided to test the 1:2 material with ReClock and removing the raster offset correction. Not good, ReClock is not able to detect the refresh rate on my dev PC and it wont try the v-sync correction at all As a result the 1:2 playback is worser with ReClock than it is without it.

After cleaning up the video refresh rate database multiple times an restarting MP for multiple times ReClock was suddenly able to detect the refresh rate of the monitor.

Now the problem is that both current EVR presenter version and the one that I disabled the raster offset correction work nicely with ReClock with v-sync correction in ReClock enabled. Go figure.

It's less odd than you suppose.

the test is with the original dshowhelper (April 2 . released with RC2) and a media at 23,976 FPS.

if the monitor is the vga 75HZ reclock (do you call 1:3 , I am right?)

the vSynch reclock work . as you can se the vsynch cursor go straight to the target window. (vsynch dots are a little bit scattered around it , but is quite normal)

If the monitor is the hdmi plasma 50HZ (do you call 1:2 , I am right?)

the vSynch reclock was disabled . as you can se the vsynch cursor don't go to the target window.

edit: both cases monitor was primary .

 

[Owlsroost]

Thanks Jong and Tourettes for all the interesting discussion points and info

For reference, all my dll versions to date perform 'sync to nearest display vsync' correction for 2:1 and 1:1 FPS ratio situations, and the v003 & v004 versions do it for all FPS ratios (it's never disabled).

Meanwhile, the 'bursts of judder' investigatons are continuing - and no, it doesn't seem to be presentation/vsync positioning judder, the 'paint' position relative to vsync is the same in all cases. What seems to be happening is that it paints two frames then skips one (repetitively), resulting in a juddery 33.3333 fps with no dropped frames reported. This is at 50Hz with 1:1 fps ratio.

Tony

 

[tourettes]

Preamble / definitions

Unfortunately this is quite hard topic to discuss with, especially when one small difference in a definition of a word can turn the whole scheme upside down. Also it doesn't make it any easier when you have non-real time communication with the other persons so that it would be much easier to correct other persons view / facts (and looks like this post wont be a short one as well )

Here are some definitions for few common words that need to be exactly defined when they are used in the video rendering context. Thanks in advance for reading!

• presentation window - this is the time window that EVR presenter has time to start and end the frame drawing so that the frame will be displayed during next v-sync (after next VBLANK time is over). To make it easy for the algorithm discussion let's just assume that this is the first 1/4 of frame duration (time when raster offset is in the first 25% of the screen height)
• raster offset - this is the scan line that video HW is currently drawing
• v-sync position - same as raster offset
• 1:1 - When source material's fps and target device's refresh rate have an exact match (for example 50fps on 50Hz TV)
• 1:2 - When source material's fps and target device's refresh rate have an integer multiplied match of 2 (for example 25fps on 50Hz TV)

Next I'll try my best to try to explain the interesting parts of the ecosystem of video / audio rendering that are related to video rendering / accuracy and ReClock in general... I'm not sure how well I manage in it, but let's try anyway

To ride shotgun (current design)

Current design with the ReClock in graph is a bit odd ball, I guess this is the result that Ogg didn't want to write a custom video presenter for few reasons:

• ReClock was designed at the time when mostly overlay was used as the video renderer. Overlay doesn't give possibility to build a custom presenter (not 100% sure).
• By using a custom renderer approach all video playback applications would have required to be modified to support the renderer (this is a big no-no for few obvious reasons: 1) you cannot change implementation of 3rd party applications 2) some applications that mix GUI and video, like for example MediaPortal does,

What I mean with the odd ball design? ReClock itself does it's job really nicely, but it is not the best way to do the frame scheduling synchronization. It's a bit like blind and mute person (EVR presenter) would be instructed by guy in the passenger seat (ReClock / reference clock) about the steering and speed. That wouldn't matter that much if there wouldn't be one random variable (let's call it X this time) that ReClock cannot know.

X?

Usually X marks the spot and this is partly true in our case as well. So, what is the mysterious variable X? Hard to describe without a flip board or anything that you could draw on (too lazy to open paint since it would be just impossible to draw with...)

EVR presenter schedules the frame to be presented at time Y and this is got from the information that EVR mixer tells the frame presentation time to be and then EVR presenter queries the reference clock when such "imaginary" time is on the wall time (the PC clock in this case).

After the Y (targeted frame presentation time) is received, EVR presenter schedules a timer to wake up the rendering thread in such way that we will be "early enough" in the :aint() / frame presentation that we can draw the frame in correct v-sync period (presentation window). Since the timer is not 100% accurate we have the Mr. X appearing in our equation.

So, ReClock thinks that we will be presenting at time Y and it modifies the reference clock / audio playback rate (pushes speed pedal and/or brakes) where as in reality the presentation will happen on Y + X spot.

Pitfalls of the current design

not as glitch resistant as possible

X is result of two things 1) Windows is not a real time OS, so the timers aren't always firing on the exact moment when they should 2) some extra work on CPU / HD could delay code execution after timer has fired. Since we have the Mr. X modifying our results (ReClock doesn't see the X, but EVR presenter will see it) it might rarely happen that we aren't presenting the frame on correct v-sync even when the EVR presenter could fix that.

Slow to recover from seeking / channel changes

Since ReClock is working only based on the "feedback loop", it is taking a lot of time for it to recover from a seek or channel changes. Users can see this by multiple second that are juddering after seeking / changing channel (live tv has also one general issue, solving it would require a time machine... but lets talk about that in some other thread or universe since having a slight buffer will sort it out.)

Not optimal audio quality because of constant resampling

First, it wont ever be possible to get bit perfect audio playback when you are targeting to a judder free video (unless GPU manufacturers start to provide GPUs that have one crystal to rule them all... meaning that there would be only one time source for the video and audio clocks).

But... it would be possible to reduce the need for audio resampling when the driver would see how close we are to the border of presentation window. Driver would instruct the passanger to speed up or slow down only when we are to close to the border.

Optimal way for the future?

If the driver would just able to tell where the car is going it would help the passanger to give better driving instructions for the driver himself!

ar-jar (vertical sync) has been experimenting with video renderer instructing the reference clock. This would be the ultimate solution for rendering. Now, if we only had a change to

1) do the fine tuning of the frame presentation in EVR presenter (making sure that presentation window is hit)
2) tell reference clock to speed up or slow down when presentation window limits are reached

This would require only small change from ReClock. It should implement a IReClock interface that has two methods:

SetVSyncMode(enum mode) - toggling between current behavior of ReClock and advice mode, where ReClock would listen to the EVR presenter's (or any other presenter's) advices should the clock run faster / slower / or at 1.0 speed
Advice(double) - this would tell ReClock to modify the reference clock to run at different speed (1.01x for example).

That way the Mr. X can be killed and video rendering is a bit more close to the perfect.

To Owlsroost

I think you aren't currently running in the opposite direction that you should be if you are trying to fix the ReClock incompatibility issue we are seeing. Your current approach is to ignore the steering commands that the passanger tells and then the passager gets confused when it sees the results (with a delay) where the car is heading into.

The raster offset that you are working now is not compatible with ReClock's philosophy but it is most likely a good way to make the non-ReClock situations a bit more robust (as some users have already reported).

How to make ReClock work with the MP / EVR presenter? Best way would be to as James to allow us to tell ReClock some info (Optimal way for the future? part in the post). Next, almost perfect, way would be to ignore the raster offset position completely in the :aint() and make :aint() to only try to target to the exact spot in the wall time that was calculated earlier (busy loop until Y is reached). Now, I don't know what ReClock expects, does it expect the paint to be started on the spot that it is monitoring (and how it is even monitoring the raster position when paint happens, since all that should be visible outside the EVR presenter is the v-sync when the frame is drawn... only James knows... ) or is it the end position (or even something in between ).

...hopefully this did make some sense

 

[tourettes]

if the monitor is the vga 75HZ reclock (do you call 1:3 , I am right?)

1:3 and 1:1 material is handled the same. No raster offset correction is done.

btw. how did you manage to get the v-sync position to be shown? Enabling it in ReClock doesn't work on my dev pc (DXVA or non-DXVA content).

 

[te3hpurp]

Too bad that ReClock is closed source, so it will make really hard to know what it is exactly doing.

XBMC is open source, right? That player features an option similar to ReClock (sync to display with audio resample).

Emph

@Tourettes

Is this same ReClock you are talking about:

Some how i cannot create link,
but in http : / / oss slysoft com / Reclock

There are GPL sources.

Regards,

 

[tourettes]

Is this same ReClock you are talking about:

http://oss.************/ReClock/

The sources are only for the audio resampling library (and maybe some other GPL components, but not for the core logic).

 

[red5goahead]

if the monitor is the vga 75HZ reclock (do you call 1:3 , I am right?)

1:3 and 1:1 material is handled the same. No raster offset correction is done.
btw. how did you manage to get the v-sync position to be shown? Enabling it in ReClock doesn't work on my dev pc (DXVA or non-DXVA content).

First Dxva option in reclock configuration set on the correction for the NV12 space colour so Dxva but also with CoreAvc for example that use NV12 as default space colour.

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).
If vSynch correction work the vysnch dots go in few seconds to that target window. If the vSynch dots don't move the reclock internal vysnch correction is off. As I show you work fine on the monitor running at 75 HZ. and is disabled with the 50HZ. Hmdi plasma (the important one !)