Anyone got it 100% ?

[jeffboy]

Hi

Have been trying to get a totally smooth setup now for ages, but there's just this final annoyance grr!!

Based on countless hours of trying and testing, I now have a ALMOST smooth setup consisting of

Zoomplayer - haali splitter - coreavc w/cuda - ac3filter - evr - reclock - aero on - hdmi - tv (PAL land 25 fps on 50hz TV)

All vsync in reclock off (makes no difference in this setup).

No tearing (due to Aero)

Framerate is OK (thanks Reclock)

Stutter is mostly OK (thanks to EVR)

BUT! - there still seems to be a "slip" between the frame delivery and the frame rendering - resulting in periods with judder. Maybe 20 mins totally smooth, then a judder period. Pause/play will mostly fix it again. So there is still a "luck" factor and I can't enjoy the smooth parts due to waiting for the next judder

I assume the problem is when it comes close to the vsync when it can't decide on which side of the vsync to draw the picture, and then it's random until safely on the other side again... ?

Is there a best practice / perfect science to this ?

Is the problem a slip between aero and graphics card/TV (and thus no reclock/filter/player tuning will help) - or a slip between player and aero ?

Several hero points available to anyone with a solution !

 

[Jong]

Yes, it sounds like you are right about the cause of the problem. You should use Reclock vsync correction to fix it. Obviously you need to be sure Vsync correction is enabled for EVR.

Reclock vsync should make a difference with Aero on provided Zoomplayer itself has not implemented a vsync correction method (like MadVR and EVR Sync on mpc-hc). I don't know what Zoomplayer does now I don't use it. It is easy to check. Just enable vsync correction in Reclock, put up the Reclock vsync on-screen display and check that the vsync marker (single horizontal white line with a vertical line made of dots, showing the vsync position of each frame) converges on the vsync target (two horizontal lines a short distance apart). Try moving the target using the keyboard shortcuts (<ctrl><alt><shift>F11 and <ctrl><alt><shift>F12 by default) the vsync marker should move to the new location.

You may need to play with the position til you find one that is judder-free. It is easier in mpc-hc has the EVR Sync OSD tells you exactly when you are in the right position (when av. sync offset @~-16ms for 50Hz). Normally though a position about 20-30% down the screen will be good enough.

This should eliminate the periodic judder you mention and judder after seek. However there are two things to note:

- The one downside of reclock vsync correction is you can get a single brief period of judder (no more than 2-3 secs) in the first 30 secs after each seek. This is when Reclock is pulling vsync into position. Ignore any brief judder in the first 45 secs (say) of playback.

- D3D exclusive mode is much more robust for media playback. Occasional random dropped frames are quite possible/likely otherwise. For the best possible playback chose a renderer with exclusive mode.

But Reclock vsync correction properly configured really should solve your current problem.

 

[Mark_A_W]

Try madVR.

 

[theshadowrunner]

Under XP, ZP has its own vsync control over EVR.
Enabling Reclock's vsync does nothing (the vsync marker doesn't go to target and has a life of its own).
However, and again using ZP on XP, EVR is the renderer the least prone to vsync bullshit. I used to swear by VMR9 but when using 24hz rez, EVR does prove a lot more stable = more often than not it catches the vsync properly.
While using VMR9, the vsync marker is a solid line all the time, it doesn't move an inch, with EVR, I see dots around it and it very slightly moves. I think this proves EVR is constantly evaluating the best vsync position, whereas VMR9 does it at playback start and stops computing after that...
Anyway, since you mention Aero, I guess you're on 7 so that doesn't apply to you ^^;
Still, I doubt ZP's vsync control for EVR would be different on 7. Verify for sure though!

 

[jeffboy]

Thanks.

madVR for some reason seems to not work with CUDA, with my ION machine it renders 2-3 frames / sec

Jong and shadowrunner - together your information summarizes why I am currently with ZP (on w7). I have _never_ seen ZP EVR throw a single tear. So obviously it has it's own EVR vsync method - and out of the box it works better than the best I could get MPC-HC to do after weeks of fiddling... With WMR9 ZP does tear so I guess they do the most work on EVR which is also the default.

I have several times tried to revert to MPC-HC to use the vsync techs in the later builds, and have followed the procedure you mention Jong. However even in the correct position (furthest away from most judderic place including wrap) - it is not as smooth as ZP. It seems MPC-HC has another problem with delivering the frames - it's just more unstable on average, for instance it judders way more if the PC is doing something else at the same time, while ZP remains solid. Thus I get maybe one single judder frame every 10 secs on average (but perhaps not the long judder periods). Also initial period of tearing and judder until stable looks unprofessional, whereas ZP is smooth from the start..

Interestingly - if I still use reclock to display the vsync in ZP EVR (it will do that, even though reclock does not get to pull the target) - it actually stays solid in about the same place (third down from top) that I would manually have selected using the testing procedure... But again it appears to have a "slip", so it forgets to keep checking or something,

If I go for D3D exclusive mode, ZP will not display subtitles. MPC-HC will, but no interface and still gives me more judder on average than ZP EVR.

So still no solution ... ZP with periodic judder but mostly smooth, or MPC-HC with endless fiddling and never satisfying :bang:

 

[Jong]

Shadowrunner and JeffBoy,

Some of the confusion comes from two completely different things meant by "vsync control". One, is the timing for movement to the front buffer to eliminate tearing. A second, related but totally different, is the elimination of "synchronised frame rate/refresh rate judder". It is this second problem, that JeffBoy described in his OP and that Reclock's vsync correction is primarily designed to fix, although in some situations it can have an impact on the first too.

About the "solid white line", this comes normally from use of a back buffer to try to eliminate tearing. This means in hardware the whole of the next frame is "flipped" to the front buffer during vBlank to try to eliminate tearing. Hence no spread. However, this directly CAUSES the synchronised frame rate/refresh rate judder problem when frame rate and refresh rate are compatible, e.g. exact multiples or regular cadence such as 3:2, (http://software.intel.com/en-us/articles/video-frame-display-synchronization/, see description of figure 5), since if a frame is presented too close to this buffer flip it may complete one side or the other and if the frame rate and refresh rate are closely matched this may go on for many seconds, even minutes.

Until recently no renderers manage to avoid this "synchronised judder". Now there are some that are trying. MadVR seems to be close to having it cracked, if it is not cracked already, but it is still too buggy and cannot handle subtitles or DVD disc playback (DVD menus), so as far as I am concerned, good as it is, it cannot yet be recommended as someones main choice. mpc-hc's EVR Sync renderer and EVR CP renderer have both tried to fix it but both are somewhat buggy. MediaPortal, working of the same open source code have also tried to fix it. I have heard some reports they may have succeeded but have not tried it myself.

Reclock vsync correction fixes "synchronised judder" by moving the point of presentation away from vsync to precisely avoid the problem Jeffboy describes in this OP. It does this by measuring the end of presentation relative to the target set and making tiny changes to the frame rate mostly at the start of playback to "pull" presentation away from the danger zone.

Reclock displays its marker at the point the "Present()" call returns. In non-exclusive mode, without Aero, this always happens just after the flip, regardless of when presentation started. Further rendering is unavoidably "blocked" by DirectX until after vBlank. This means that when Reclock tries to alter the position of its marker it finds itself unable to (the return of the Present() Call is fixed in hardware to just after VBlank). So Reclock keeps running the frame rate too fast or slow and this leads to "rolling sync" where every few seconds to one minute there is a brief burst of judder, the duration of which is relative to the speed of the "roll", which in turn is dependent on how far away the vsync marker is from the Reclock-defined vsync target. Similarly, renderers that control the point presentation starts will stop Reclock from changing the point presentation ends, even if, as in Aero mode, it is not "blocked". So Reclock's vsync correction is fundamentally incompatible with any renderer that itself fixes the point in the vsync cycle that Present() starts and/or returns. This includes VMR9 and the standard EVR non-exclusive renderers on XP, Vista and W7. It also includes MadVR, EVR CP and EVR Sync renderers with their vsync correction turned on and the same renderers even with vsync off, in non-Aero mode. IF RECLOCK CANNOT MOVE THE VSYNC MARKER INTO ITS TARGET ZONE THEN DO NOT USE IT!

However, Reclock vsync correction does work:

- with overlay mixer
- with an EVR/VMR9 renderer that uses an overlay surface i.e. PDVD/WinDVD/TMT in Blu-ray disc mode only and TMT only also in DVD disc mode. These players do not use an overlay surface for file mode, so Reclock vsync correction cannot be used here
- with VMR9 in D3D-exclusive mode. This "unblocks" the GPU allowing the Present() call to return immediately, thus allowing Reclock to control point of presentation.
- With EVR CP renderers in Aero or D3D-exclusive mode, that have their own vsync control (if provided) disabled. Aero, as well as exclusive mode, "unblocks" the GPU. NOTE this does not apply to renderers that do not just break Reclock vsync correction by using a blocking back buffer but actually try (mostly so far not completely successfully) to control point of presentation themselves. Do not use Reclock vsync correction with these unless you can turn off vsync control, as you can with EVR Sync and EVR CP.

You must not use Reclock vsync with the standard EVR renderer. That "slip" you describe is an indication of the rolling sync, where the frame rate laps the refresh rate due to Reclock's continually attempts to correct.

Exclusive mode is definitely the most reliable and should not be anywhere near so vulnerable to other processing activity. Aero with a CP renderer, with all vsync off, should work too. Maybe not perfect but much much better than you suggest. If you cannot use ZP's D3D mode then it is worth trying mpc-hc again using Sync renderer (and alternate EVR CP) with all Sync Renderer vsync settings OFF and instead using Reclock Vsync.

You might like to follow my discussion with Kazuya here on how to configure this:

http://forum.slysoft.com/showthread.php?p=261094#post261094

 

[jeffboy]

Thanks for your time and detailed response !

What you write matches my understanding.

The "setup wizard" would then be something like:

a) decide if Aero or not
b) decide if reclock should do vsync or not
c) decide renderer/player

Intuitively it makes more sense to me to have the player and not reclock handle vsync. Perhaps there are just too many (p)layers involved and it can be difficult to even find the right layer to troubleshoot... Can you help in answering some specifics :

For all the below, assume that refresh rate matches what the TV is accepting (display settings). Also assume that the play framerate will match the refresh rate (reclock).

1) Assume Aero is on. Are we sure no "slip" exists between Aero -> graphics card -> display ? No amount of software fiddling would fix this.

2) Assume Aero is on and the answer to 1) is yes we are sure. It would then seem that the player would have a simple job to do to just wait for Aero vsync and then roll ?

If the answer to 1) is no, there can be slips - then Aero should never be used and the renderer/player has the responsibility to handle vsync and judder.

Two viable solutions should exist whether aero or not:

a) Allow (slight) difference in framerate and refresh rate (like 24.999 vs 25.001) and then find a way to steer onto the right side of vsync when needed (only once in every slip cycle). I guess this is what MPC-HC EVR Sync is trying to do (present at nearest vsync) and maybe also Zoomplayer EVR (but it fails to narrow the errors down to just one and has a period of judder instead)

b) Precisely match framerate to refresh rate with no slip and time the rendering accordingly. This is what reclock is trying to do but still relies on the stability of the player for it to work (and unfortunately doesnt work with the most stable player ZP EVR )

 

[Jong]

You should try exclusive mode mpc-hc with EVR Sync.

This is because exclusive mode allows maximum GPU resources to be applied (no blocking) and avoids the additional software layer of "Aero", which while having its uses (not least eliminating tearing in Flash/Silverlight/WPF apps) is not ideal.

Also EVR Sync is the only renderer I know that always tells you when sync "glitches". Maybe madVR too, as I don't use it day to day I only skim the MadVR thread for interesting info.

You are right, it is hard to be sure that any Windows PC will NEVER slip. It is a multitasking O/S, without realtime scheduling and more background processes than you can shake a stick at. But W7 scheduling is generally pretty solid, although I still find the need to disable Windows Update, Windows Search and Google Update when playing media.

The problem with EVR Sync "present at nearest" is the renderer still needs to decide which is nearest. You move the problem from what happens when presentation is too close to vsync to what happens frames are ready for presentation from the decoder too close to the desire scanline position of the renderer. EVR Sync has not solved this problem although it has made judder less likely to happen. Still if you seek enough you can get to a position when EVR Sync cannot decide which frame is best (it varies from one frame to the next) and the judder comes back. The standard EVR renderer supplied with Windows 7, I think what you mean by the "ZP renderer" (or are you using a ZP Custom presenter?), seems to have similar issues judging purely from problems like yours and many others. I have never used it other than for brief testing, I jumped straight to Reclock vsync correction for W7, as I already had it working on XP. But your reports and the effort that went into the Beliyaal CP renderer and then the EVR Sync renderer certainly indicates there is a problem. The standard EVR renderer is a closed source renderer without a community route to the developer and its reported stats are useless. The sync "glitches" do not appear in its stats as technically the frame is presented, just sometimes two might be presented in the same vsync interval so one is never seen or one might just miss its intended vsync and get written in the next. Still all are presented and there are no dropped or repeated frames, so it is hard to know what is the problem there, but it seems clear there is one.

The point of Aero with Reclock is not for its ability to avoid tearing but because it "unblock" the GPU allowing Reclock to control the point of presentation. This should help Aero as frames will be presented (possible Windows scheduling hiatus aside!) consistently at the same point in the vsync cycle. Avoiding any "difficult" decisions on which frame to present in. But no question exclusive mode is better and what I use.

You are right, in an ideal world the video renderer is a better place to fix this than in Reclock. It can, in theory, ensure you never see a burst of judder even immediately after a seek/pause. Maybe MadVR in exclusive mode (coming soonish) will be that renderer. We would still need a subtitle pin though. But a renderer that does not have Reclock's ability to adjust the frame rate will always have a problem, as you say, if the frame rate and refresh rate are not exactly compatible and, even if they are, will always have a "stressful" time deciding which frame to present in when, randomly after a seek, the offset it is applying to avoid a clash with vsync is close to one exact frame. Reclock "de-stresses" this situation by altering the frame rate briefly to keep all dangers away. For now I still believe Reclock vsync correction is the only reliable method.

 

[theshadowrunner]

Thanks for the extra fine details Jong, I learned a lot.
But since I plan to stick to ZP, and find D3D Exclusive mode to be unusable (no control bar, hidden controls, oh and also Reclock's "change rez" VBS script hanging), I guess I'll just keep using regular EVR with Reclock's vsync correction off.
A few hiccups once in a while but otherwise stable, at least that's what I think at the moment ^^;
Later,

TSR

 

[cfh]

hey guys, please don't give up. I really understand your feelings (or should i say frustration) but maybe if we'll keep this thread open, we will finally get a perfect solution.
I, myself, am trying to enjoy a stutter free movies for weeks with no luck.
My setup is a little different then yours and the results are reasonable but still far from perfect.
For some movies, I get zero dropped frames with no stutters/judders at all (at least I could not notice any) but for other movies I get occasionally stutters (not periodic), they are mostly visible on the credits part of the movie and during panning scene.
My setup is:
Windows 7 with Aero on.
mpc-hc with EVR-CP and using DXVA
VSync and Accurate VSync are on in mpc-hc.
Flush GPU before vsync is on (not sure if it matters).
ReClock VSync correction turned off.
As you mentioned, D3D exclusive mode is not a good option since it lacks a control bar.
I chose mpc-hc with evr-cp since i'm using dxva and I need subtitles.
It is hard to setup ReClock vsync because i'm using dxva and it is not possible to see the vsync indicators on screen. I tried few values between 0 to 100 but I got judders in all the experiments. I usually test the setup with the final part of the movies when you can see the movies credits rolling up the screen. I'm not sure it is a good method because it takes few seconds to ReClock to sync the frames.
Any recomandations for other setups? or any hints for a way to setup ReClock vsync with dxva?

 

[Jong]

The way to set up Reclock Vsync DXVA, in fact the best way to set up Reclock vsync altogether is using the EVR Sync renderer with all its vsync options off. See my link above. The Reclock markers, whilst useful to see that vsync control is working don't really give you much of a clue where is the right position, so not ideal anyway.

Rolling credits IMO are a good way to test. You just need to ignore any brief judder in the first few secs. I use it when testing TMT and PDVD, which do not have a usefulstats display. But, if you use EVR Sync its stats will tell you if there is judder, you do not need to watch anything.

I do understand the limitations of exclusive mode, but if you are watching a movie full screen with a remote it works just as well as a standalone player.

 

[namaiki]

I found EVR-Custom Pres in MPC-HC with ReClock's V-sync correction disabled does the trick for me. (aero enabled, renderer defaults, geforce)

 

[cfh]

namaki, that was exactly my setup and I also thought it solved all my problems until i noticed judders in some movies....
Jong, I tried your sugestion last night, i used EVR-Sync with all sync options off and tried to tune the target vsync position in ReClock.
It looks like i can get pretty good results, the red like is total flat and the green line is "wavy". But still, from time to time (every few seconds), I get downward spike on the green line which results with a judder.
I tried with other movies and it looks like the the frequency of these spikes are media dependant??? or is it just the windows scheduling that you mentioned on the other thread...., if that is the case, maybe giving the player a higher priority in the task manager may improve something....
And another question, what should be the optimal distance between the red line and the green line? as a results of my tests, it looks like the further the green line is from the red like, the better results i get.

 

[Jong]

What OS are you using? I used to see spikes on the green line occasionally with XP, but never on W7. But, yes, those spikes are most likely scheduling glitches. I would look for processes that might be doing something every few seconds. A Tool like Sysinternals "Process Explorer" can really help to see if there is a process causing frequent IO or CPU spikes during media playback and which process it is. Increasing priority might help Reclock can even help here with "give high priority to player" setting. But on XP I found I had to knock the HTPC front-end right down to "low" during media playback as its importers were updating RSS and weather feeds and causing glitches and only "low" fixed. it. I think the issue is that Windows has a flexible priority system that starts to increase priority the longer a process has been denied; Even with an increased player priority I think eventually the HTPC software was "butting in". Anyway, making those changes certainly fixed those issues on XP, but I have not had to do anything like that on W7.

The thing is though that waves or even spikes on the EVR Sync green line are completely invisible unless the green line hits the red line and the #sync glitches in the EVR Sync OSD increases. Essentially, the green line tells you how far in advance of vsync the frame was ready, but since it is copied to the front buffer by a hardware buffer flip during vsync it really is invisible whether the next frame is presented and ready 16ms early or 4ms early (for example).

With regard to the ideal "av sync offset", or average green line position, it should be as far away from the red line as possible but at least 3-4ms away from the start of the frame. As you observe the scheduling "spikes" are always downwards (frame is presented later than expected due to the thread being processed late), so you need maximum protection in the downward direction whilst being sure that the frame is never presented so close to the previous vsync that it is flipped too early. So @50Hz a frame is 20ms and the "av sync offset" should be around -16 to -17ms. @60Hz a frame is 16.7ms and the "av sync offset" should be around -12 to -13ms. @24Hz you don't have to worry so much the timing is so relaxed; Even though the frame time is 41.7ms you could use with the 50Hz/60Hz value, or whatever offset the same Reclock vsync slider position gives you, if that does not cause lipsync issues (as some have @24Hz). Hopefully, you should find the ideal Reclock vsync slider position for 60Hz (most demanding) will work for all the others. If you are interested in higher refresh rates, depending on those spikes, 72Hz may be possible but, as you can see, 96Hz starts to be pretty tight and 120Hz I think it is just about impossible, certainly on XP.

 

[cfh]

I'm using W7 and the gpu refresh rate is set to 24 fps as I decided to watch movies just like you would see them in theater. ReClock is set to slowdown both pal and ntsc titles.
I did take the green line far above the red line and and even the downward green spikes are far enough from the red line (I can't remember the exact distance but I can send screen caputures tomorrow) but I can still notice judders... I hope it is not something with my mind or imagination.......(maybe I should visit a doctor....).
Anyway, my test went like this: I watched the credits part of the film while the OSD graphs were running on the left side of the screen. I hid the graphs with my hands and waited for a judder....., when I noticed one, I removed my hands from the graph and watched it and "surprisingly" i saw a green spike.
Are you sure that I shouldn't notice any judder as long as the green line doesn't cross the red line?
Could it be that there is something wrong with the encoded films? (with different films I get different results).
Another thing that may worth to mentions that sometimes the OSD graphs themselfs seems to stutter...
Any suggestions?

 

[jeffboy]

Update here from me - last night ran en entire movie with not one judder ! On W7 - ZP71a5 - ION - CoreAVC - EVR - Reclock.

I updated ".net framework" to version 4 - this I believe is where EVR renderer is delivered with. Using reclock to display vsync (but not fix/control it) - there seems to be a difference. Interestingly every now and then the vsync "cross" will take a "cycle" or move and return but with no judder as result! Wonder if it has become wiser and now does some compensation for that slip...

Just can't get anything reasonable result from MPC-HC with any configuration. Don't know it it's the relatively slow CPU from my ION machine that MPC-HC is not happy about. Also it seems very media dependent. 720p and 1080p material seem to require different settings/tweaks for instance. If it runs smoothly on one file, likely there will be problems with other files.

ZP just simply runs it smooth from the moment you click play, it's the same on all files and it doesnt care about scheduling or other background activity. Maybe the final solution would be ZP EVR with ZP vsync disabled and using reclock to vsync ? Unfortunately there is no such option. But it clearly seems some of MPC-HC's problems are not renderer/vsync related but more something in the code that makes the frame delivery less stable and more prone to disturbances.

 

[Jong]

Are you sure that I shouldn't notice any judder as long as the green line doesn't cross the red line?

Honestly, if the two do not cross and there is no increase in the number of dropped frames or "sync glitches" there should be no judder due to rendering. Of course there could be encoding/decoding issues or it could be the TV introducing it.

What is the source? Broadcast TV in the US often has de-interlacing issues, where sometimes the decoder drops out of "film mode" (23.976 inverse telecine) and starts to treat the source as 29.97fps interlaced. These are very visible as judder but are always in the same place and even visible if you pause the movie, with interlacing artifacts (double edges where there is movement).

If you have a PAL TV try using Reclock to speed up 23.976 to 25p (set refresh rate to 50hz) and play like a PAL DVD (yes, I know, with sped up voices, but just for testing). Then we could eliminate the TV. Not all 24p implementation on PAL TVs are that great. Not all are that great on 60Hz TVs either. My PAL TV will accept 48Hz but then internally converts to 50hz introducing judder.

 

[Jong]

ZP just simply runs it smooth from the moment you click play, it's the same on all files and it doesnt care about scheduling or other background activity. Maybe the final solution would be ZP EVR with ZP vsync disabled and using reclock to vsync ? Unfortunately there is no such option. But it clearly seems some of MPC-HC's problems are not renderer/vsync related but more something in the code that makes the frame delivery less stable and more prone to disturbances.

I really do not believe that is the case. I believe you when you say ZP works better for you, but that is not generally the case. In a different environment mpc-hc can work just as well. I have seen none of your issues on several W7 systems.

One other advantage of using Reclock for vsync (as indirectly mentioned above) is that, once configured, it also works for PDVD/TMT/WinDVD blu-ray disc playback and TMT DVD playback. No other solution can also fix vsync in those players. I know not everyone is bothered about being able to play full Blu-ray discs, but many are.

 

[Jong]

Honestly, if the two do not cross and there is no increase in the number of dropped frames or "sync glitches" there should be no judder due to rendering.

In case you do not spot it in the discussion I linked to above <Ctrl><Alt>R will reset all the counters including "frames dropped" and "sync glitches" so it is easy to see if these numbers ever go above zero if you reset after a seek.

 

[cfh]

Like I said, the green and red line are not crossing each other and there is no dropped frames nor sync glitches druing these judders and green spikes (they are always coming together).
If it is my tv like you suggest, why do the judders always come with the green spikes???? or is it really only in my mind....
My content is mostly ripped from BDs (1080p), some american and some european.
I really hope it is not a problem with my tv since I just bought a 50 inch plasma two months ago
I'll do these testings with the 50hz tonight and I'll be back with an answer (and maybe some screen shots).