Reply to thread

Message: <blockquote data-quote="Scythe42" data-source="post: 507622" data-attributes="member: 95833">Yes, audio is playing ahead of video and the gap keeps on increasing the longer the video plays. When it really gets bad some attempt to correct this is being bade. I assume this is the one second thingy in GetTimeToSchedule.Changing these values doesn't have any constant effect unless I change them dramatically which screws up things even more but don't have any affect on the drift. I digged a little deeper into CheckForScheduledSample because if a video lag is detected is must be corrected. If frames cannot be displayed and are behind more than the frequency you have to drop them.I changed:[PHP]        //too late, but present anyway        Log("frame is too late for %I64d ms, last sleep time %d ms.", -*pNextSampleTime/10000, msLastSleepTime );        CHECK_HR(PresentSample(pSample), "PresentSample failed");[/PHP]to:[PHP]        //too late, but present anyway        Log("frame is too late for %I64d ms, last sleep time %d ms.", -*pNextSampleTime/10000, msLastSleepTime );        m_didSkip = true;        Log( "skipping frame, behind %I64d ms, last sleep time %d ms.", -*pNextSampleTime/10000, msLastSleepTime );//        CHECK_HR(PresentSample(pSample), "PresentSample failed");[/PHP]This skips late frames as an attempt to resync and writes something to the logs. Crude but effective for debugging. When the lag is really being bad it can take some seconds before playback is back in sync. For a workaround a smoother implementation is needed.If I now take a look at the evr.log I see that late frames are skipped until playback is back in sync. It also works when skipping forwards or backwards in steps. Not as smooth at 60Hz where playback seems to be accelerated until in sync. But probably this only happens because of the highter refresh rate of 60Hz when playing back 23.976fps material. With the higher vsync the presenter is able of presenting more late frames from a 23.976 perspective at 60Hz than at 24Hz. This is probably why the bug is undetected at 60Hz and playback gets in sync quickly. So the bug is cancelled out by having a higher refresh rate running (just a guess)...For the evr.log you can see that playback started at 02:20:09, frames got dropped until they are back in sync and then playback keeps in sync until I stopped at 02:20:23.[CODE]10-09-2009 02:20:09.286 [dd4]OnClockRestart10-09-2009 02:20:09.321 [bc8]dangerous and unlikely time to schedule [0D909258]: 1597710534. scheduled time: 1597970384, now: 25985010-09-2009 02:20:09.321 [bc8]Flushing: size=310-09-2009 02:20:09.444 [d08]Scheduling sample from the past (133 ms, last call to NotifyWorker: 155 ms)10-09-2009 02:20:09.444 [bc8]frame is too late for 133 ms, last sleep time 20 ms.10-09-2009 02:20:09.444 [bc8]skipping frame, behind 133 ms, last sleep time 20 ms.10-09-2009 02:20:09.449 [d08]Scheduling sample from the past (96 ms, last call to NotifyWorker: 5 ms)10-09-2009 02:20:09.450 [bc8]frame is too late for 96 ms, last sleep time 20 ms.10-09-2009 02:20:09.450 [bc8]skipping frame, behind 96 ms, last sleep time 20 ms.10-09-2009 02:20:09.454 [d08]Scheduling sample from the past (60 ms, last call to NotifyWorker: 4 ms)10-09-2009 02:20:09.454 [bc8]frame is too late for 60 ms, last sleep time 20 ms.10-09-2009 02:20:09.454 [bc8]skipping frame, behind 60 ms, last sleep time 20 ms.10-09-2009 02:20:09.459 [d08]Scheduling sample from the past (23 ms, last call to NotifyWorker: 5 ms)10-09-2009 02:20:23.633 [dd4]OnClockPause[/CODE]One question: why are late frames displayed anyway? I don't really understand the reason for this. At least when frames are continously late skipping needs to occur. Unless a higher refresh rate can compensate for it. Then it would make sense just to display the frames for an accelerated playback (see assumption futher up). But this would break as soon as the problems occur on the material's native rate with a lag higher than the time a single frame is displayed.The evr.log on 60Hz with 24p material should show similar stuff and could proof this idea. Anyone can try this. Just check the evr.log on MP in Debug Logging and see if you have decreasing "frame is too late" at the beginning of playback.It also doesn't explain why I couldn't reproduce the issue under Win 7 so far. Maybe it's a Vista/Splitter combination thingy with 23.976fps material and set 23.976Hz/24Hz refresh rate during initialization of the playback where video frames are send too late in general. And because the code doesn't really compensate for late frames, the frames stay late. When playback starts in sync it stays in sync. About one out of ten times the file I used to reproduce the issue starts in sync and stays that way. Again the root cause here is unknown.This is where a workaround could be implemented even though the root cause is not known. Either skipping frames on playback start or ignoring vsync and display samples immediately until playback is in sync. The lag increases because nothing is early enough for compensation (vsync might play a role here), but I won't investigate this one because it's only a side effect. Focus should be on being in sync in the first place or getting there after playbacks starts as quick and smooth as possible.This also explains why other players with a EVR renderer don't show a 24p problem. They probably just skipping late frames before they display the first one and therefore the problem cannot be seen.I also checked some other material. It seems to be a general issue. When a movie starts perfectly in sync it stays in sync.  (unless there is an external effect on the HTPC which brings stuff out of sync). The drift only occurs once a frame is later than the frequency. Some movies start more likely out of sync than others for yet unknown reasons. But again, the EVR presenter has to take care of syncing the playback.</blockquote>

Verification