Probably the MAX_WAIT can be increased as well based on the refresh rate. With the current 20 it is dropping frames too early with the quick patch at 24Hz. A delay up to 40ms would be ok for 24fps playback (need to test it) because even though the frames are e.g 25ms late they can still be rendered in time and there's no need to drop them.
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.
In this case a constant drift because all frames are always rendered is actually worse because you can't watch a movie at all without going crazy. But I agree with you that dropped frames are no good and should only occur when CPU/GPU are maxed out.
).Discard the sample because it is 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.
I'll do my best. And I am looking forward to your enhancements.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
I'm currently browsing through the MS documentation to get myself up to speed on EVR presentation....
I just repeat what I did before to limit this one further down. Once done on Vista I repeat the same on Win 7 again out of curiosity what might be different and to make compare the various configurations. The only thing I know that MS did some enhancements to the automatic quality control in Win 7. According to some paragraph in MSDN it reacts faster than under Vista. Maybe these enhancements are just kicking in here and compensating for this issue. I also look into the EC_SAMPLE_LATENCY as well.
France
Thanks for testing. What you see are frames that are dropped now because they were late and could not be presented in time.
static CCritSec lock; // lock for timer initialization (multiple threads are using the timer during startup)
static LONGLONG GetCurrentTimestamp()
{
LONGLONG ticks100ns;
{
CAutoLock lock(&lock);
if( !g_bTimerInitializer )
{
g_bQPCAvail = QueryPerformanceFrequency( &g_liQPCFreq );
Log("GetCurrentTimestamp(): Performance timer available: %d", g_bQPCAvail);
g_bTimerInitializer = true;
}
}
if( g_bQPCAvail )
{
// [url]http://msdn.microsoft.com/en-us/library/ms644904(VS.85).aspx[/url]
// Use always the same CPU core (no clue if it actually makes any difference...)
DWORD_PTR oldmask = SetThreadAffinityMask(::GetCurrentThread(), 0);
QueryPerformanceCounter ((LARGE_INTEGER*)&ticks100ns);
ticks100ns = LONGLONG((double(ticks100ns) * 10000000) / double(g_liQPCFreq.QuadPart) + 0.5);
SetThreadAffinityMask(::GetCurrentThread(), oldmask);
}
else
{
// to milliseconds to microseconds
ticks100ns = GetTickCount() * 10000;
}
return ticks100ns;
}