Reply to thread

Message: <blockquote data-quote="Scythe42" data-source="post: 513311" data-attributes="member: 95833">I haven't read the ReClock docs, but here is what I assume it does from playing around with it. If I am wrong on something please correct me.Short answer: No, ReClock tries to assure that each frame is displayed at a multiple of the refresh rate currently selected for the GPU to avoid judder caused by this difference. That should be enough if fps/refresh rate differ. If you use 1:1 frame rate don't let Reclock touch anything (except for bitperfect audio playback and maybe channel adjustments).Long answer: Back in the days of CRTs there was a ray running around and lighting each pixel on the tube, because of phosphor decay the pixels need constantly be refreshed with energy to be lightened up. Once the ray came the the end of the screen (lower right corner) it had to trace to the beginning (upper left corner) in one straight motion. To avoid stuff like tearing, meaning a picture is changed when the ray is in the middle of the picture and already starts to display the next picture new picture information is provided during this vertical retrace period. That's the vertical synchronization: keep the display of new frames in line with vertical retrace of the cathode ray. The time it takes the ray to to get back to the start is often called the vertical blank. On a PC it could happen that frames are send to late to the renderer, which means the renderer has to wait for the next vertical retrace before displaying the picture or else you would see juddering or tearing if a frame is displayed immediately or dropped by the renderer. There is one important difference here when it comes to frame dropping. Frames need to be dropped when they are not in time, usually caused by codecs or CPU/GPU limitations. It simply means the frame was never early enough for being delivered to the renderer in the first place. Among other things this is what a presenter does: It takes data from the mixer, schedules frames for delivery to the renderer, which then sends it to the GPU. If something isn't on time it doesn't even bother sending it to the renderer. The renderer itself tries to render what it can. Here GPU limitations come in.If you estimate from a software when the vsync happens you can be off. And even though you got the frame from the mixer in time you could send it too late to the renderer. That's the difference here. Frame was never received in time by a presenter vs. frame was not send at the correct time by the presenter. That's a huge difference. and ReClock's vsync correction deals with the second one.The PC itself doesn't care about the display device. For him it's important that there is enough time to deliver the next frame to the GPU before the vertical retrace is completed. Of course this does not exist on non CRTs, but they once existed and technology was created to deal with that. That's why even the video processor in a modern LCD still thinks in this terms even if the LCs don't require any refresh (LCDs don't flicker). And for computer usage they agreed that LCDs accept frames at 60Hz for computer usage. What they do with it doesn't matter from this point on. Of course with video playback on computer and LCD TV's video processor started to handle more rates. In theory any rate up to the reaction time of a liquid crystal can be handled. And GPUs also need to support some rates. Usually it makes no sense to support rates on an LCD for which no material exist. What does ReClock try to achieve with the Vsync Correction:It tries to solve the problem by assuring that the vertical retrace doesn't happen at the same time as a new frame is delivered to the renderer. This can be a problem if the renderer doesn't accept new frames once the vertical retrace has begun. It only works if ReClock adjust's the frames to match the refresh rate. Again this should only be an issue if the vsync is estimated by the software and the software takes full control over when a frame is send to the renderer and the renderer displays it right away.In case of MP, DirectShow handles this. Frame is send to the renderer sometime before the vsync and the Renderer waits for the vsync before sending it to the GPU. Driver options in regards to vsync might interfere here. Usually best practice is to let the application decide. If you run into problems, force it in the driver. If you still experiencing problems and can't solve them with various settings in a player, then ReClock needs to be used.Depending on what options you enable in ReClock, it can show you when the vsync happens. From a PC point of view this is basically the time when the first pixel is displayed (the end of the vertical retrace and the new frame begins, what is usually called vsync these days). In Reclock you see various points on the left side. Every point is for one vsync in the last 100 frames. In addition there is a horizontal line. If the total heights of points is small  < 10-15% of the video height the playback can be considered as very good.  The position of this horizontal line is also important because they can show when frames are provided to the renderer. Movement of the horizontal line also tells that ReClock is trying to find the correct clock. If it constantly moves ReClock had a problem to get the correct clock.Now don't get paranoid if you see the horizontal vsync line in the middle of the picture. Also not if the pixel on the left are spread apart very wide. Sometimes it's simply the codec that is not delivering frames at an accurate rate. Try to compare ffdshow with MPC for example and you see what I mean. Unless you see any juddering or tearing don't worry about it.Usually ReClock shows the best effect with Overlay Mixer or VMR7. With VMR9/EVR you don't really have to care about it as there is a internal DirectShow function that takes control of the vsync estimation. Basically a pre-rendered frame is only send to the GPU during the vertical retrace depending on the  selected refresh rate. That's why the EVR presents for example send frames early to the renderer. DirectShow's Vsync will take care of the rest.For MP this shouldn't really be an issue, except for compensating fps vs. refresh rate. And when you use DVXA it shouldn't matter at all because the GPU should even take more responsibility for displaying frames on time. If you use software rendering the VSync correction might be an option for you.Try it out. If you can't see a difference at once (don't turn on the vsync display, as it will fool your perception) don't think about it anymore.Yes, DirectShow is also not perfect here, but it's as good as it gets. And Win 7 again has media enhancements over Vista. Not as much as Vista had over XP but everything is welcome.</blockquote>

Verification