Reply to thread

Message: <blockquote data-quote="tourettes" data-source="post: 507783" data-attributes="member: 10858">That was already on my todo list when it comes to playback improvements. Good if someone can provide the patch so I can concentrate on some other things and hopefully reveal something pretty interesting to "advanced" / "hifi" crowd of the MP user base (stay tuned <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile    :)" loading="lazy" data-shortname=":)" />).I think maximum allowed wait should be something close to the frame presentation time (there is slight few millisecond paint over head). So, for 25 fps it is 40 ms, for 50 fps 20 ms etc. ( I guess the actual refresh rate needs to be taken into consideration? So for 25fps PAL video on 75 Hz would actually be 13.33...ms. This one needs to be checked. Even if its not that, the deinterlacing has an effect on this).About the late frames, MS documentation says that no late frames should be rendered.[code]Discard the sample because it is late. [/code]I think it is not a good idea to render a frame that is already late on its presentation time, it would only cause visible judder as timeline of movement in the video won't be continuous. Also it would increase the case that the next frame is also late.I'm puzzled, too. So far it only happens when selecting EVR in MP's config and material with a 23,976fps. And I only noticed it with HD so far. With VMR the issues don't come up. But on the other hand VMR just might drop frames and therefore I didn't saw the issue. I am way more sensitive too lip-sync issues than to a dropped frame every minute or so. I need to run some more tests here and see what debug logs tell me.That should rule out the bug on codec side. Next step would be try to eliminate the digital audio connection as source of the late samples (audio clock could be drifting away from the video clock, althou the graph clock is sourced currently from the audio clock so it should cause dropped frames or juddering... not sync drifting... but still it is a good idea to rule out that audio renderer / device is not causing the sync drifting).Few users as well have reported that the issue is not reproducible with Windows 7. Did you install haali splitter with Windows 7 or does it provide some other source filter? Also could you check if MPC-HC source filter is making any difference?<a href="http://msdn.microsoft.com/en-us/library/dd319605%28VS.85%29.aspx" target="_blank">EC_SAMPLE_LATENCY (Windows)</a>  Maybe that could help EVR mixer or any other component to notice that samples are delivered too late?</blockquote>

Verification