[other] Problems with dropping frames with EVR (2 Viewers)

[disaster123]

AW: Problems with dropping frames with EVR

gemx
seems to be correct:

    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));
    }
    else 
    {
      // workaround for unknown bugs
      delay = timePerFrame/100*25;
    }

But strange that when hnsSampleTime is not > 0 only 25 is used instead of 75 ? Shouldn't it be the same value?

 

[tourettes]

Re: AW: Problems with dropping frames with EVR

But strange that when hnsSampleTime is not > 0 only 25 is used instead of 75 ? Shouldn't it be the same value?

When sample time is "current" time we are already on doomed path, so just try to get the sample presented and worry about the next one... at least sounds right after 3/4 bottle of good red wine...

 

[disaster123]

AW: Problems with dropping frames with EVR

uups correct

but when we're on doomed path shouldn't the dealy be 0 to get out the frame as fast as possible?

 

[disaster123]

AW: Problems with dropping frames with EVR

When i look in my evr.log the sleep time seems to be to long:

15-01-2010 23:37:34.628 [aec]Dropping frame, behind 6.73 ms, last sleep time 16.96 ms.
15-01-2010 23:37:36.022 [aec]Dropping frame, behind 0.34 ms, last sleep time 10.00 ms.
15-01-2010 23:37:53.466 [aec]Dropping frame, behind 3.34 ms, last sleep time 15.04 ms.
15-01-2010 23:38:11.586 [aec]Dropping frame, behind 2.12 ms, last sleep time 10.00 ms.
15-01-2010 23:39:13.571 [aec]Dropping frame, behind 2.06 ms, last sleep time 16.31 ms.
15-01-2010 23:39:23.710 [aec]Dropping frame, behind 0.80 ms, last sleep time 15.56 ms.
15-01-2010 23:40:00.211 [aec]Dropping frame, behind 0.09 ms, last sleep time 16.56 ms.
15-01-2010 23:40:30.634 [aec]Dropping frame, behind 0.93 ms, last sleep time 15.44 ms.
15-01-2010 23:40:43.477 [aec]Dropping frame, behind 2.32 ms, last sleep time 10.00 ms.
15-01-2010 23:41:37.559 [aec]Dropping frame, behind 0.42 ms, last sleep time 15.62 ms.
15-01-2010 23:42:23.923 [aec]Dropping frame, behind 1.88 ms, last sleep time 10.00 ms.
15-01-2010 23:44:03.974 [aec]Dropping frame, behind 6.06 ms, last sleep time 16.00 ms.
15-01-2010 23:44:24.870 [aec]Dropping frame, behind 0.64 ms, last sleep time 15.03 ms.
15-01-2010 23:45:05.435 [aec]Dropping frame, behind 1.49 ms, last sleep time 15.59 ms.
15-01-2010 23:45:08.474 [aec]Dropping frame, behind 0.91 ms, last sleep time 16.09 ms.
15-01-2010 23:45:14.554 [aec]Dropping frame, behind 0.60 ms, last sleep time 15.18 ms.

Shouldn't the diff from lock substracted from the delay?

 

[gemx]

I had some partly success in playing with the delay values in SchedulerThread(void* param) and HRESULT MPEVRCustomPresenter::CheckForScheduledSample(REFERENCE_TIME *pNextSampleTime, REFERENCE_TIME hnsLastSleepTime) -> if (*pNextSampleTime > m_rtTimePerFrame/2)

I also the thread priority for the worker thread from BELOW_NORMAL to HIGHEST

I suspect the problem be there

 

[Scythe42]

Re: AW: Problems with dropping frames with EVR

@gemx
seems to be correct:

    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));
    }
    else 
    {
      // workaround for unknown bugs
      delay = timePerFrame/100*25;
    }

But strange that when hnsSampleTime is not > 0 only 25 is used instead of 75 ? Shouldn't it be the same value?

It's a minimum wait. I took it from the existing EVR Presenter and only made it dynamic to 1/4 other the display time. In theory it should be 0 as the frame is already late and shouldn't be scheduled at all. But if I insert 0 here you get very high CPU usage. That was the error I made in SVN causing the 100% CPU usage when I updated the headers. There is without question something fishy here. But I never found out what exactly.

 

[morpheus_xx]

AW: Problems with dropping frames with EVR

I have also the feeling that the dropping of late frames is a bit too aggressive:

16-01-2010 13:43:30.861 [87c]Dropping frame, behind 0.80 ms, last sleep time 16.27 ms.
16-01-2010 13:43:32.900 [87c]Dropping frame, behind 1.24 ms, last sleep time 8.41 ms.
16-01-2010 13:44:01.199 [87c]Dropping frame, behind 4.00 ms, last sleep time 7.74 ms.
16-01-2010 13:44:17.335 [87c]Dropping frame, behind 5.95 ms, last sleep time 16.04 ms.
16-01-2010 13:44:17.649 [87c]Dropping frame, behind 0.04 ms, last sleep time 17.05 ms.
16-01-2010 13:44:38.076 [87c]Dropping frame, behind 0.53 ms, last sleep time 17.09 ms.
16-01-2010 13:44:41.472 [87c]Dropping frame, behind 0.45 ms, last sleep time 9.75 ms.
16-01-2010 13:44:41.529 [87c]Dropping frame, behind 0.34 ms, last sleep time 17.20 ms.
16-01-2010 13:44:41.949 [87c]Dropping frame, behind 0.35 ms, last sleep time 17.09 ms.
16-01-2010 13:45:15.487 [87c]Dropping frame, behind 0.41 ms, last sleep time 17.18 ms.

why have these frames with 0.xx ms late to be dropped? in 25 fps for each frame is 40 ms time, so 0.xx ms shouldn't matter too much.

 

[disaster123]

AW: Problems with dropping frames with EVR

morpheus_xx
i've the same really small values and think the dropping is "harder" than showing it 0.5ms too late...

 

[Scythe42]

Re: AW: Problems with dropping frames with EVR

I have also the feeling that the dropping of late frames is a bit too aggressive:
16-01-2010 13:43:30.861 [87c]Dropping frame, behind 0.80 ms, last sleep time 16.27 ms.
16-01-2010 13:43:32.900 [87c]Dropping frame, behind 1.24 ms, last sleep time 8.41 ms.
16-01-2010 13:44:01.199 [87c]Dropping frame, behind 4.00 ms, last sleep time 7.74 ms.
16-01-2010 13:44:17.335 [87c]Dropping frame, behind 5.95 ms, last sleep time 16.04 ms.
16-01-2010 13:44:17.649 [87c]Dropping frame, behind 0.04 ms, last sleep time 17.05 ms.
16-01-2010 13:44:38.076 [87c]Dropping frame, behind 0.53 ms, last sleep time 17.09 ms.
16-01-2010 13:44:41.472 [87c]Dropping frame, behind 0.45 ms, last sleep time 9.75 ms.
16-01-2010 13:44:41.529 [87c]Dropping frame, behind 0.34 ms, last sleep time 17.20 ms.
16-01-2010 13:44:41.949 [87c]Dropping frame, behind 0.35 ms, last sleep time 17.09 ms.
16-01-2010 13:45:15.487 [87c]Dropping frame, behind 0.41 ms, last sleep time 17.18 ms.

Late is late. And rendering a late frame causes an sync delay of 40ms in this scenario until the next vsync takes place. You can only think in frame display time here as new frames are only switched at vblank or else we would see tearing.

If a frame is 1ms past it time, it can only be rendered 39ms later at the next vsync. This isn't too agressive. It's the only way to have audio and video in sync without tearing. On refresh rate > fps the additional vsync cause speed up segments of a movie which is as bad as dropping frames.

If you add something like "give 1ms grace period" the above example would already caused a significant audio sync problem of seven full frames (10 late, three dropped) which equals 280ms. You either have 7 frames running faster when RR > fps or a 7 frames video to audio delay. Bother are horrible for the viewing experience. If it's late it needs to be dropped. That's why the code makes sure they are scheduled 4th in advance.

I experimented with grace periods up to one frame and the result was a sync problem of 40ms until a frame gets dropped as painting always latest longer than the vblank on my system. As soon as a frame takes up another frames vsync you have a full display time delay in video compared to audio.

In fact frames need to get dropped earlier to compensate for painting, but I never put that in the code. Trying to paint a frame at presentation time would already be too late as painting takes longer than the vblank. Usually in these scenarios it's not the "offending" frame that will be dropped but the next one will be too late as the last one took up it's vsync. These 0.xx ms could be some of these, especially when I see the high sleep times.

Also the frames are scheduled to be 1/4 before their presentation time already and should be on time. There might be a very small grace period depending on how the vblank lasts though. And with painting it's very likely that the next frame will miss its vsync.

Trying with 1/2 or 1/3 is an option though... I couldn't see a difference in the number of frames on my machine though. But give it a try on your machines an let me know if it works better.

The real question is not: can we drop frames later (no we can't) but WHY are the frames coming so late. I expect the scheduler to having some issues here. But I can't pin point the exact reason here.

If anyone has an idea to enhance the scheduler please let me know. But trying to disable frame dropping or drop less frames doesn't solve the problem as you create an audio sync problem.

 

[tourettes]

Re: AW: Problems with dropping frames with EVR

If anyone has an idea to enhance the scheduler please let me know. But trying to disable frame dropping or drop less frames doesn't solve the problem as you create an audio sync problem.

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.