What "video stuff" can Reclock do?!

[Jong]

James, I know you have said that Reclock already pushes the boundaries of what an audio filter can do, but could you just answer the following for me?

- Does Reclock know when a new video frame is about to be written to the frame buffer, or could it? Even in DXVA mode?
- If yes, can Reclock use "GetScanLine" to find out which line is currently being drawn as the new frame starts to be written
- Can Reclock, by fair means for foul(!) pause video playback (delay the start of writing the next frame) for a few milliseconds, so we can shift the point the frame starts being written to a different place in the scanline cycle (always less than 1 video frame pause)?

You can probably guess why I am asking this and I am guessing you have already thought about it and the answer is no, but it would be brilliant if it was not!

[Bitmonster]

You mean VSync corrections for DXVA?

I had a conversation with Ogo long time ago about this and he said, that it basically should be possible, but the main reason why VSync tools for DXVA is disabled is that he can't paint on the video for VSync display and tearing bar.

After I suggested that this display could be done elsewhere (like the configuration panel) he said that it should work, but he has a better idea to handle it. Well, he never said what this idea would be, because he disappeared.

[Jong]

Not exactly.

Both MPC-HC and PowerDVD avoid tearing but they are both susceptible to extended periods of terrible judder, using and not using DXVA, when frame rate and refresh rate are closely synced (as with Reclock) and when the time the video frame is written is very close to the VBlank time. At least I have proved to my own satisfaction(!) this is true with MPC-HC. I cannot test with PowerDVD because it does not have a "stats" screen, but I see exactly the same result as with MPC-HC - if I seek enough about 1 time in 7 PDVD judders and judders for a long time. Figure 5 in this article (http://software.intel.com/en-us/articles/video-frame-display-synchronization/)describes the problem. The problem occurs randomly on start of playback or any seek and if things drift into the trouble area during playback. I should add it is only really seen if not doing 3:2 pulldown, so it does not affect people using 60Hz, only those using 24/48/50Hz.

If Reclock could spot when the time frames are being written drifts into the zone, where due to natural variability it fluctuates backwards and forwards over the VBlank time and pause the graph for a few milliseconds to keep it away from this boundary it could fix this severe jitter problem for a single frame "hit". In essence:

- If previous frames have all been before VBlank and one is suddenly after, pause video for say 20% of frame time to move it well clear of the boundary
- If previous frames have all been after VBlank and one is suddenly before, pause video for say 80% of frame time so again it is well clear of the boundary and will remain so for a long time (especially because of Reclock's good work in synchronising frame and refresh rates.)

The Beliyaal MPC-HC build seems to be trying to fix this in MPC-HC, although it does not work for me right now, but a fix that would solve it for PowerDVD (and all players) too would be amazing.

It does not need to fix the flip time (so no need for vsync OSD or even adjustable vsync tools). That, at least for DXVA, can be left to the player. Just make sure new frames are not being written at a time when it leads to horrible extended jitter! Reclock makes frame rate and refresh rate so stable on my PC that in a test earlier today, after a deliberate series of seeks to enter the trouble area, my PC stayed in this ghastly "jitter zone" for over 45 minutes!

[Bitmonster]

Well, I haven't got the point, where this differs from the VSync correction ReClock does (or where do you think it does). As far as I see it, actually the target VSync position you can configure in ReClock has the only purpose to get the frame delivery of the renderer as far from the problematic (jittery) slot as possible.

VSync correction is the most important feature of ReClock for me. That's why I have installed an older video card (X1550) into my HTPC, to force PDVD to work without DXVA for Blu-rays, as I haven't found any other way to disable DXVA in this program. And it also has bound me to Overlay for all other stuff a very long time, till I discovered that VMR9 under Vista with Aero is also a great alternative if used with ffdshow scaling/RGB-conversion (working VSync correction, no tearing, alpha blending support, possibility to use a LUT for gamma correction, etc.).

[Jong]

The point is that this would work for all players and with DXVA and would allow the players to do their own vsync correction.

Personally I have experimented with Reclock's vsync correction and apart from the lack of DXVA support (which is a big drawback these days) I do not like the time it takes on my system to reach its target point after a seek and (unless I am doing it wrong, which is always possible) it is impossible to get the tear point completely off the screen. With other vsync methods (such as that used with PDVD and MPC-HC) the tear is invisible from the moment playback starts, but they suffer from this extreme judder problem.

My request sounds naively like it might be possible without Reclock becoming a video renderer. It sounds like the kind of thing it might just be able to do. But I don't know if it is possible!

[Bitmonster]

OK, after you have edited your second post, I think I got the point. You want to achieve a kind of "automatic adjusting VSync correction", by finding out, if the playback is currently stuttering.

Well, the idea sounds good, if it is possible. Maybe this is near the idea Ogo had in mind, as it would make the VSync display superfluous. I have no idea if ReClock could know when a new video frame is about to be written to the frame buffer. But I guess there are some more problems involved. For example ReClock would need to cache the found bad zone, as otherwise it would have to let the player get into the bad zone on every new playback, just to avoid the bad zone.

@James
While we are at this VSync stuff: would it be possible to get a more "aggressive" VSync correction, that would push the VSync away more rapidly from the problematic zone when the playback starts? Jong is right, that it would be great, if the jitter-free playback could be achieved faster after pause/start.

[Jong]

You want to achieve a kind of "automatic adjusting VSync correction", by finding out, if the playback is currently stuttering......But I guess there are some more problems involved. For example ReClock would need to cache the found bad zone, as otherwise it would have to let the player get into the bad zone on every new playback, just to avoid the bad zone.In fact I am infering that it is about to stutter from the timing of the write to frame buffer. And by jumping in quick we limit it to a single frame. But, essentially... yes.

Not sure what you mean here. I think (not sure) the bad zone is know, at least when using vsync tools in PDVD and other players that fix vsync off screen - the bad zone is when the frame time (not sure if is the start or finish, but that is mere details!) oscilates across the VBlank time (maybe actually the flip time, which is aligned by the player with VBlank). I think you just need to nudge this one way or the other across the boundary depending on which way things are drifting.

However, in my experience the drift is so slow (at least with Beliyaal's MPC build) that if you started playback with frame time close to the middle of the screen paint you probably would never need to do a correction during playback. If you do need to correct during playback it is only a one frame hit with a very long period in between (using Reclock). No need for any cache.

[Jong]

This is interesting (I think!):

http://forum.doom9.org/showthread.php?p=1257939#post1257939

It seems Reclock almost does what we want already. It depends if it is possible to turn on vsync correction even with DXVA but withpout the onscreen graphics, as Ogo said was possible.

Then all me need to do is:

- allow finer movements in Reclock's vsync "target", down to the scan line
- be able to set a Vblank Wait start target in Reclock (not sure what the real name of this target is outside of MPC-HC)
- let Reclock first move its sync target to the bottom or top of the frame until the VBlank wait start target is approached, then move the vsync position close to the middle of the frame and subtly move it during playback to keep things away from the trouble zone

[cca]

Regarding the DXVA thing, when DXVA is used with EVR in Windows Vista, Reclock reports then video as NV12 and keep the Vsync correction enabled. It cannot display the OSD ofcourse, but I think that it works.

[Jong]

I've confirmed that in a crude way Reclock can already be used to extend or shorten stutter when playing back Blu-rays using MPC-HC with vsync correction enabled (not alternate vsync) which, with luck, should apply to other players that have built in vsync correction. By moving the Reclock vsync target I can speed up or slow down the movement of "Present Wait "/"VBlank Wait Start" (depends on eactly which options are selcted in MPC renderer settings). Every time the relevant target passes through zero a judder occurs - visible on the jitter chart and noticeable on the screen.

By moving the Reclock target away from the fixed vsync position (fixed by MPC) I can drag the target away from 20/0ms were it judders (@50Hz). By moving it then back to near the vsync position I can slow down it's drift to near zero. I'm pretty sure this means if Reclock was doing this itself, with much greater accuracy and responsiveness, it would be able to move "present wait" to a nice safe position at start of playback (of course we need to know how "present wait" is defined in MPC and how to work it out) and adjust the vsync target to hold it there.

Of course all this is still without using DXVA. We would need to know if it is possible with DXVA enabled. But if this works, as it seems to, I'd be reasonably confident it will work with PowerDVD too.

If Vsync correction is possible "blind" in DXVA (as suggested by Ogo) could we turn it on for testing?

[Jong]

I think I am coming to the conclusion we have to tackle this in two different ways:

- If there is really no vysnc correction by the player then Reclock can do the job as it is (anyone know if PowerDVD uses vsync correction for Blu-ray?). If we can enable vsync correction in DXVA mode, with no on screen display, we just need to set it in the middle and we are done. This is fine if there is no tearing (which seems to be true with MPC-HC D3D mode and EVR with Aero, for example).

- If there is (potentially broken) vsync correction then we need the other method I mentioned above, where Reclock "intelligently fights" with the player by adjusting its vsync target, to first move it away from the trouble zone and then keep it there.

But we need to know if we can turn on vsync in DXVA mode (accepting there will be no on screen display) and we need to know if PowerDVD (and TMT) does vsync correction or not.

Then we would need to be able to select the appropriate method for each player.

[Jong]

Regarding the DXVA thing, when DXVA is used with EVR in Windows Vista, Reclock reports then video as NV12 and keep the Vsync correction enabled. It cannot display the OSD ofcourse, but I think that it works.Yep. You are definitely right.

For some reason my 3850 (Cat 9.2) seems to support VC-1 (not H.264) DXVA2 under XP and I can confirm that whe I use EVR custom presenter NV12 is reported and the vsync controls are enabled.

They also definitely work. I used Beliyaal's build, that always seems to enforce vsync for EVR custom presenter (at least I could not find a combination of options that turned it off!).

As discussed in the posts above, if I position the Reclcok vsync target at the bottom of the frame (a long way from the EVR target). Reclock fights against MPC and you can see the "present wait" figure "roll". if I set Reclock Vsync target at the top, so they do not fight "present wait" is stable (stays fixed). Definitive proof for me that Reclock is doing vsync correction in DXVA mode. I wonder if this is possible with DVXA1? James?

Although I cannot test in the same way because the "normal" build does not give all the stats of the Beliyaal build I am pretty confident the normal build, which does allow you to have no vsync correction with EVR custom, will together with Reclock, properly fix judder for H.264 in non-DXVA and VC-1 in DXVA!

[cca]

Yep. You are definitely right.

For some reason my 3850 (Cat 9.2) seems to support VC-1 (not H.264) DXVA2 under XP and I can confirm that whe I use EVR custom presenter NV12 is reported and the vsync controls are enabled.

They also definitely work. I used Beliyaal's build, that always seems to enforce vsync for EVR custom presenter (at least I could not find a combination of options that turned it off!).

As discussed in the posts above, if I position the Reclcok vsync target at the bottom of the frame (a long way from the EVR target). Reclock fights against MPC and you can see the "present wait" figure "roll". if I set Reclock Vsync target at the top, so they do not fight "present wait" is stable (stays fixed). Definitive proof for me that Reclock is doing vsync correction in DXVA mode. I wonder if this is possible with DVXA1? James?

Although I cannot test in the same way because the "normal" build does not give all the stats of the Beliyaal build I am pretty confident the normal build, which does allow you to have no vsync correction with EVR custom, will together with Reclock, properly fix judder for H.264 in non-DXVA and VC-1 in DXVA!

But you can disable Vsync in Beliyaal's build, just press "V" !

[Jong]

Yes, I missed that. :o But only with "alternate vsync". So many permutations! In my defence, I had ruled out "alternate vsync" earlier because it tears on my system, but it is no excuse!

Anyway, just tried it and Reclock vsync correction definitely works. None of the stats are helpful in this case unfortunately, but the tear is! I can see it start anywhere on the screen and move to the vsync target in Reclock.

Now all I need is this working with DXVA1 on XP. Any chance James?