Reply to thread

Message: <blockquote data-quote="Scythe42" data-source="post: 508464" data-attributes="member: 95833">My conclusion so far with the current code: because people run them at their native refresh rate and there are no additional vsyncs that can be used to display late frames, so that playback can catch up without dropping frames. Also MAX_WAIT is used as a default when no timestamp is available, which puts additional lag on frames. In addition the used thread scheduling is not accurate enough. All in all it's a combination of these things that have impact on playing a file with an 1:1 refresh rate.I can reproduce the same issues with 60Hz as well by providing a HD 60fps file. Try it with transcoding a 23.976fps file to 60fps and feed it to the player. The problem here is file fps = refresh rate.So far I could reduce the dropped frames by allowing a drift in late frames up the maximum of 3/4 of the display time of a single frame based on a file's fps. It it's already late, so it can be late up to the next frame, it wouldn't make a difference. Some lagging builds up but you can't really see it until a frame needs to be dropped to catch up again. I'm very sensitive to lip-sync issues but couldn't detect this one unless a few frames got dropped. The current code does this with 15ms, but with 24Hz we have more room to breath here.Still room for enhancements. But one thing after another. First an acceptable frame dropping for material played at the same frame rate, then on to a better thread scheduling for minimizing late frames and finally go for an own vsync clocking to avoid tearing. Just taking it evolutionary step by step here. I have an updated patch for testing available soon.PS: I think I found out some stuff why Win 7 works better. Looks like the thread scheduling has been updated and is more accurate in general than under Vista.</blockquote>

Verification