Reply to thread

Message: <blockquote data-quote="Jong" data-source="post: 609597" data-attributes="member: 104040">Yes, I agree terminology can be confusing!!To try to answer your question on Reclock, the position of the Reclock vsync marker appears to correspond with the end of paint (plus presumably a scheduling delay). In MPC-HC EVR sync, for example, it is quite noticeable that the Reclock vsync marker is a few ms further down the frame than the green line on the OSD (start paint). It is also noticeable that as you reduce the work the OSD has to do (each press of <ctrl-J> gives a different OSD, some with minimal info) the difference between the EVR sync green line and the Reclock marker closes. Also, if you use a "normal renderer" which double-buffers the Reclock vsync marker is "pinned" just below the start of the frame. In my discussions with ar-jar we understand this to be because when double-buffering "end paint" does not return until after the flip. It is this that stops Reclock controlling what it terms "vsync", i.e. raster offset of "end paint" relative to vsync, with conventional EVR and VMR9. D3D mode introduces additional buffering that means Reclock sees end of paint as soon as the frame is ready to be flipped. Aero seems to do the same (assuming of course there is no "clever" vsync code in the renderer itself), making rendering, from the player perspective, asynchronous to actual vsync, as with Overlay, and allowing Reclock vsync correction to work.As you have probably figured, Reclock does not have tight control over the point paint starts, it measures the average point it finished over recent frames and if that falls outside of its target it starts to play with the reference clock to pull things back in line. So Reclock does not really know about "Y" or target it specifically, it just makes sure that on average paint completes well away from any danger. You are right, of course, this is not foolproof. But I am not sure that anything Reclock would trip up on would be fixable with the EVR Presenter. Reclock is not actively triggering the start of paint and finding execution happens too late for vsync. It merely makes sure the previous frame is close to its target, let's things happen as fast as they can, and hopes the next one will be ready in time. Maybe this sounds worse!! But I think, in reality, it means that any delay which leads to the next frame not being presented until too late would equally affect the EVR Presenter, but maybe I have missed something? Maybe there are rare occasions when this might be true.In practice, if the Reclock vsync marker is set to complete paint around half way through a frame (making sure it is not started until after vsync, or judder occurs) this leaves quite a lot of time for any delayed execution. With XP I used to see spike downward in the green line in EVR sync of as much as 6 or 7ms (C2D 2.7Ghz). However, on W7 I can honestly say I have never seen the green line spike down (although not to say it does not happen). Either way, a Reclock vsync target around 40% of the screen height, with a green line @about 16.5ms @50Hz leaves plenty of headroom (~7ms on XP). It does seem some presenters are much more sensitive to timing than others. I found it took a bit of work to get the right position for TMT3. It seems to need frames presented in a pretty narrow window (maybe 25% of the screen) for smooth playback. Fortunately, this position is compatible with other players that are less sensitive.I agree with these points. I am still trying to get James to improve the first. It cannot be eliminated completely but it could be better. Audio resampling has become much better though recently with improved code and faster PCs, allowing higher quality modes to be practical. I honestly think for the vast majority it is inaudible. For purists though it will never be bit perfect. Of course if you are using Reclock for 24p->25p, 25p->24p or even 29.97->30fps that is not possible anyway. It is also worth noting that unless the player is bitstreaming or supports WASAPI Windows Mixer messes with and resamples the audio anyway. Reclock does have the advantage it can bypass Windows Mixer completely and ensure only one, high quality resampling takes place .This is a good idea. It may be worth trying to open a discussion with James. Even better if you could get ar-jar to join you. It would be better if it were a wider open community request, rather than just a MP one. Also, James is probably trying to crack just the same issue for the mythical(!) "Slyplayer". He may have already done something similar (then I don't know if he would want to open it up) or you may have thought of something he has not. Of course if you do this make sure that you do not turn off Reclock's correction until you are in the middle of your presentation window, or better at the opposite extreme if you can predict the direction of drift. Reclock currently still stops correction as soon as the edges of its target zone are hit. In practice this means correction is continual after a while as drift is normally in one direction. It keeps drifting just out of the target to get nudged only just back into it. It then falls out of it again pretty quickly.Off-topic question for tourettes!Have you considered trying to implement EVR onto an overlay surface as seems to be done my commercial Blu-ray players in disc mode. TMT3 also uses it for DVD playback. It does nothing for this judder problem (except Reclock vsync works fine with it), but it does mean that YCbCr is passed over HDMI unmolested - no conversion to/from RGB. Tests over at AVS Forum show the YCbCr values to be almost perfectly to spec (as measured at the other end of the HDMI cable). A significant improvement in colour quality over current solutions.</blockquote>

Verification