[other] Problems with dropping frames with EVR (1 Viewer)

[Scythe42]

Here's a 1/2 early scheduling dshowhelper.dll with delay = 0 for late frames in the scheduler and a sleep(3) removed. In case you want to try this more "aggressive" version that tries to render frames even earlier. It's my current development version trying out to find some ways to enhance playback (so far out of luck on my machine).

You can easily play with the values and the delay here as all the relevant lines are listed in the patch.

What might also help is bumping the thread priority up. But this was commented out in the EVR presenter before I started to work on it, therefore I never put it in again as somebody must have done this for a reason. I run MP and Halli (increased buffer as well) at higher priority.

Index: source/EVRCustomPresenter.cpp
===================================================================
--- source/EVRCustomPresenter.cpp	(revision 24764)
+++ source/EVRCustomPresenter.cpp	(working copy)
@@ -1078,8 +1078,8 @@
     }
     LOG_TRACE("Time to schedule: %I64d", *pNextSampleTime);
 
-    // If we are ahead up to one quarter of a frame present sample as the vsync will be waited for anyway
-    if (*pNextSampleTime > m_rtTimePerFrame/4)
+    // If we are ahead up to one half + 1ms of a frame present sample as the vsync will be waited for anyway
+    if (*pNextSampleTime > (m_rtTimePerFrame/2)+10000)
     {
       break;
     }
@@ -1101,8 +1101,6 @@
     else 
     {
       CHECK_HR(PresentSample(pSample), "PresentSample failed");
-      // EXPERIMENTAL: give other threads some time to breath
-      Sleep(3);
     }
     *pNextSampleTime = 0;
     ReturnSample(pSample, TRUE);
Index: source/Scheduler.cpp
===================================================================
--- source/Scheduler.cpp	(revision 24764)
+++ source/Scheduler.cpp	(working copy)
@@ -110,13 +110,13 @@
     timePerFrame = p->pPresenter->GetFrameDuration();
     if (hnsSampleTime > 0)
     {
-      // wait for 3/4 sample time or 3/4 of frame duration depending on what is smaller
-      delay = min((hnsSampleTime/100*75), (timePerFrame/100*75));
+      // wait for 1/2 sample time or 1/2 of frame duration depending on what is smaller
+      delay = min((hnsSampleTime/2), (timePerFrame/2));
     }
     else 
     {
-      // workaround for unknown bugs
-      delay = timePerFrame/100*25;
+      // do not schedule late frames
+      delay = 0;
     }
     if (delay >= 10000)
     {

If this really helps on your machines we need to do more tests. As said I have rarely dropped frames on my box and when they are some (beside of the beginning of playback) they are huge because of external events on my machine (it does other stuff in the background).

Edit: DLL removed as it didn't work better

 

[disaster123]

AW: Problems with dropping frames with EVR

i've already tried that 2 days ago - it doesn't help - at least for me. But what about tourettes idea?

 

[Scythe42]

Re: AW: Problems with dropping frames with EVR

It would be worth to try the Multimedia Class Scheduler Service (Windows) to improve the scheduling accuracy. Who knows if it will help on some PCs that have issues with delivering frames on correct times.

Trying shouldn't hurt. I'll provide a new binary later.

 

[disaster123]

AW: Problems with dropping frames with EVR

Scythe42
i forgot to mention that with your patch / my try two days ago i didn't see anything at all / movie starts never.

Parts from log:

17-01-2010 14:16:06.801 [558]Scheduling sample from the past (65.16 ms, last call to NotifyWorker: 118.14 ms)
17-01-2010 14:16:06.801 [974]Dropping frame, behind 70.65 ms, last sleep time 0.00 ms.
17-01-2010 14:16:06.877 [558]Scheduling sample from the past (74.16 ms, last call to NotifyWorker: 194.04 ms)
17-01-2010 14:16:06.878 [974]Dropping frame, behind 120.41 ms, last sleep time 0.00 ms.
17-01-2010 14:16:09.877 [558]Scheduling sample from the past (102.16 ms, last call to NotifyWorker: 3194.20 ms)
17-01-2010 14:16:09.877 [974]Dropping frame, behind 2978.96 ms, last sleep time 0.00 ms.
17-01-2010 14:16:17.042 [558]Critical lock time for GetFreeSample was 1020.06 ms
17-01-2010 14:16:18.882 [558]Scheduling sample from the past (10124.10 ms, last call to NotifyWorker: 11618.68 ms)
17-01-2010 14:16:18.882 [974]Dropping frame, behind 11962.83 ms, last sleep time 0.00 ms.
17-01-2010 14:16:23.679 [888]Scheduling sample from the past (13377.80 ms, last call to NotifyWorker: 0.94 ms)
17-01-2010 14:16:23.679 [974]Dropping frame, behind 13378.40 ms, last sleep time 0.00 ms.
17-01-2010 14:16:23.684 [888]Scheduling sample from the past (13359.83 ms, last call to NotifyWorker: 5.95 ms)
17-01-2010 14:16:23.684 [974]Dropping frame, behind 13359.96 ms, last sleep time 0.00 ms.
17-01-2010 14:16:24.478 [558]Scheduling sample from the past (13676.37 ms, last call to NotifyWorker: 794.00 ms)
17-01-2010 14:16:24.478 [974]Dropping frame, behind 13808.05 ms, last sleep time 0.00 ms.
17-01-2010 14:16:24.678 [558]Scheduling sample from the past (13790.79 ms, last call to NotifyWorker: 994.06 ms)
17-01-2010 14:16:24.678 [974]Dropping frame, behind 13316.83 ms, last sleep time 0.00 ms.
17-01-2010 14:16:24.679 [888]Scheduling sample from the past (13296.83 ms, last call to NotifyWorker: 1.09 ms)
17-01-2010 14:16:24.679 [974]Dropping frame, behind 13296.83 ms, last sleep time 0.00 ms.
17-01-2010 14:16:24.684 [888]Scheduling sample from the past (13276.83 ms, last call to NotifyWorker: 5.90 ms)
17-01-2010 14:16:24.684 [974]Dropping frame, behind 13276.83 ms, last sleep time 0.00 ms.
17-01-2010 14:16:24.978 [558]Scheduling sample from the past (13256.83 ms, last call to NotifyWorker: 293.85 ms)
17-01-2010 14:16:24.978 [974]Dropping frame, behind 13256.83 ms, last sleep time 0.00 ms.
17-01-2010 14:16:25.178 [558]Scheduling sample from the past (13236.83 ms, last call to NotifyWorker: 493.95 ms)
17-01-2010 14:16:25.179 [974]Dropping frame, behind 13296.71 ms, last sleep time 0.00 ms.
17-01-2010 14:16:25.179 [888]Scheduling sample from the past (13276.71 ms, last call to NotifyWorker: 1.09 ms)
17-01-2010 14:16:25.179 [974]Dropping frame, behind 13276.74 ms, last sleep time 0.00 ms.
17-01-2010 14:16:25.184 [888]Scheduling sample from the past (13289.91 ms, last call to NotifyWorker: 5.86 ms)
17-01-2010 14:16:25.184 [974]Dropping frame, behind 13289.98 ms, last sleep time 0.00 ms.
17-01-2010 14:16:25.189 [888]Scheduling sample from the past (13291.75 ms, last call to NotifyWorker: 5.26 ms)
17-01-2010 14:16:25.190 [974]Dropping frame, behind 13291.83 ms, last sleep time 0.00 ms.
17-01-2010 14:16:25.194 [888]Scheduling sample from the past (13287.54 ms, last call to NotifyWorker: 10.44 ms)

 

[cfforce]

Same here, with the .dll patch TV (SD nor HD) never starts

 

[disaster123]

AW: Problems with dropping frames with EVR

that the movie never starts is caused by delay = 0. It seems that a delay too low - even 1 does not work. I need at least 10 percent of the timePerFrame - strange.

But i highered the priority of the worker thread to ABOVE_NORMAL. This seems to work great.

I've attached a version of my .dll - if somebody wants to try.

 

[Scythe42]

Re: AW: Problems with dropping frames with EVR

that the movie never starts is caused by delay = 0. It seems that a delay too low - even 1 does not work. I need at least 10 percent of the timePerFrame - strange.

This is exactly what I do not understand. The sample is late, and there is no sense in scheduling it at all. But if you don't schedule playback never starts or CPU goes to 100% if it starts. There is definitely a bug where the delay is used for other conflicting purpose. But I can't see it in the code. Maybe you can find it.

This one really drives me insane...

 

[gemx]

The "scheduling sample from the past " message exactly happens when you set the delay to 0 and seems to not really drop the packet there but seems to always to try to present this late sample and therefore enters an infinite loop.

I think one problem/bug is that when a sample is far too late it doesn't get dropped but is somehow continously tried to be presented.

 

[Scythe42]

Re: AW: Problems with dropping frames with EVR

It would be worth to try the Multimedia Class Scheduler Service (Windows) to improve the scheduling accuracy. Who knows if it will help on some PCs that have issues with delivering frames on correct times.

The scheduler is already running with a high priority:

void MPEVRCustomPresenter::StartWorkers()
{
  CAutoLock lock(this);
  if (m_bSchedulerRunning)
  {f
    return;
  }
  StartThread(&m_hScheduler, &m_schedulerParams, SchedulerThread, &m_uSchedulerThreadId, THREAD_PRIORITY_TIME_CRITICAL);
  StartThread(&m_hWorker, &m_workerParams, WorkerThread, &m_uWorkerThreadId, THREAD_PRIORITY_BELOW_NORMAL);
  m_bSchedulerRunning = TRUE;
}

...

void MPEVRCustomPresenter::StartThread(PHANDLE handle, SchedulerParams* pParams, UINT(CALLBACK *ThreadProc)(void*), UINT* threadId, int priority)
{
  Log("Starting thread!");
  pParams->pPresenter = this;
  pParams->bDone = FALSE;

  *handle = (HANDLE)_beginthreadex(NULL, 0, ThreadProc, pParams, 0, threadId);
  Log("Started thread. id: 0x%x (%d), handle: 0x%x", *threadId, *threadId, *handle);
  SetThreadPriority(*handle, priority);
}

I don't see the benefit of adding a AvSetMmThreadPriority(hTask, AVRT_PRIORITY_CRITICAL); That's the reason this section was commented out when I looked at the code the first time.

Maybe given the WorkerThread a higher priory here might increase playback. I never made any changes here, so this is an "uninvestigated" area.

But again it drives me crazy why delay = 0 doesn't work... Let's take a look at the code again...

 

[Scythe42]

I think one problem/bug is that when a sample is far too late it doesn't get dropped but is somehow continously tried to be presented.

Interesting idea. I play a bit with this...