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

[cfforce]

Re: AW: Re: Problems with dropping frames with EVR

What I did:
Just changing some BIOS values, that the CPU is running at 2,0GHz instead of 1,6GHz...

The bottleneck here shouldn't be the GPU, it looks like the CPU is it.

I can confirm aswell, that when i increase CPU speed to 1.9Ghz (found that it's the break-even point) Less dropped frames and sync glitches occur; steady @ 50fps; with cpu set to default (1.6Ghz) it's erratic between 40-47 fps.

So yes, cpu has an impact aswell in combination with MP; but when i open up MPC-HC with the same Recorded HDTV; then @ 1.6Ghz steady 50fps.

 

[gemx]

Re: AW: Problems with dropping frames with EVR

@tourettes
why do we use timeSetEvent in scheduler.cpp instead of AdviseTime ?

Hi tourettes i'm really sorry but this is a step too much for me - still not a C# or C programmer. I don't know how to implement this. All other code i found is using GetSyncSource and SetSyncSource - but i cannot find somethink like that in the EVR presenter.

Can't answer this but i remember that we often had such things in the code were timiing was really essential but the dev (don't want to exclude myself here) just used what he always used.

The difference seems to be that the resolution of timeSetEvent is max. 1 ms whereas IReferenceClock::AdviseTime is more accurate with a resolution of 100 nano-secs.
Also when using direct show i would always use the same sync clock during coding otherwise you could get mixed clock accuracies.

So exchanging timeSetEvent with AdviceTime seems like a "fix" which could theoretically improve things

 

[tourettes]

Re: AW: Re: Problems with dropping frames with EVR

So yes, cpu has an impact aswell in combination with MP; but when i open up MPC-HC with the same Recorded HDTV; then @ 1.6Ghz steady 50fps.

MPC-HC is most likely doing one less texture copy (as they don't have to care about the ATI flickering issue). Also their scheduling code is quite different from ours (please dont ask to port that as it will be quite huge effort, it is really not that easy to read code... much more twisted that the EVR renderer code MP has).

 

[OnkelChris]

AW: Problems with dropping frames with EVR

could you please port MPC-HC to MP?

(just kidding)

I tried to implement the AdviseTime, but I can't get it... Just making things worse or even brake them

 

[tourettes]

Re: AW: Problems with dropping frames with EVR

The difference seems to be that the resolution of timeSetEvent is max. 1 ms whereas IReferenceClock::AdviseTime is more accurate with a resolution of 100 nano-secs.
Also when using direct show i would always use the same sync clock during coding otherwise you could get mixed clock accuracies.

So exchanging timeSetEvent with AdviceTime seems like a "fix" which could theoretically improve things

With EVR it is most likely better to use -> IMFTimer Interface (Windows) that can be queried the same way as the m_pClock is done currently.

 

[belcom]

It's maybe the worst question in this thread, but why don't we use the standard Video-Renderer which comes with windows?

 

[tourettes]

It's maybe the worst question in this thread, but why don't we use the standard Video-Renderer which comes with windows?

I haven't seen it supporting something like MP GUI rendering

 

[riksmith]

Re: AW: Problems with dropping frames with EVR

The difference seems to be that the resolution of timeSetEvent is max. 1 ms whereas IReferenceClock::AdviseTime is more accurate with a resolution of 100 nano-secs.
Also when using direct show i would always use the same sync clock during coding otherwise you could get mixed clock accuracies.

So exchanging timeSetEvent with AdviceTime seems like a "fix" which could theoretically improve things

With EVR it is most likely better to use -> IMFTimer Interface (Windows) that can be queried the same way as the m_pClock is done currently.

From the site:
Minimum supported client Windows Vista

Does not sound good for XP users if it would be used.

 

[nyt]

Re: AW: Problems with dropping frames with EVR

The difference seems to be that the resolution of timeSetEvent is max. 1 ms whereas IReferenceClock::AdviseTime is more accurate with a resolution of 100 nano-secs.
Also when using direct show i would always use the same sync clock during coding otherwise you could get mixed clock accuracies.

So exchanging timeSetEvent with AdviceTime seems like a "fix" which could theoretically improve things

With EVR it is most likely better to use -> IMFTimer Interface (Windows) that can be queried the same way as the m_pClock is done currently.

From the site:
Minimum supported client Windows Vista

Does not sound good for XP users if it would be used.

EVR isn't supported in xp to begin with though.

 

[Scythe42]

Re: AW: Problems with dropping frames with EVR

With EVR it is most likely better to use -> IMFTimer Interface (Windows) that can be queried the same way as the m_pClock is done currently.

There's no benefit of a timer with a higher resolution. We leave the thread sleeping up to 3/4 of the presentation time delta. So it wakes up early anyway and then we render the sample and Aero takes care of when to display it (which is the next vsync). We don't even try to schedule it up the the presentation time. So timer resolution is not an issue here.

The break inside the CheckForScheduledSample() only breaks if the thread is not 1/4 early (3/4 sleep + 1/4 early = 1). So if the timer is inaccurate and wakes too early the sample get scheduled again with 3/4 of the current delta to the presentation time. If it's less then 1ms no scheduling happens. If it's a bit late the sample will be rendered. The 1/4 is the MSDN recommendation.

Because we render all samples early it's not a matter if the timer is accurate to 100ns units. It just needs to be close enough and not several ms late.

Instead of the break and possible rescheduling a sleep seems to be a nice idea to improve things here on low end machines. It could actually improve things a bit. But why sleep anyway if we are not a full vsync too early? Just render the sample if the next vsync is the one we like to present the sample on. And if we are a vsync too early then rescheduling is fine as well. And this brings the problem of: which is the correct vsync? We don't know. The only thing we have to work with is the sample time. But we can't schedule too early or we run into stuttering as the wrong vsync is used by Aero.

I'm not saying the current scheduling is the correct way to do it. It was just there and we tried to make the best out of it for RC1. And we encountered a lot of oddities in DWM...

The only thing you can try is schedule it early enough but not too early. That's what I tried with 1/3 sleep and 1/3 + 1ms grace period early rendering for presentation. The grace period was there to compensate for 1ms inaccuracy and avoid unnecessary rescheduling.

With this the sample got scheduled multiple times and get's closer to 1/3 each time. Wastes some CPU here but it is very likely you get very close to the 1/3 early, which seems to be enough for rendering. That was the best I could offer with the current presenter to offer a better experience on low end machines. In theory we could use a fixed value of x ms as well here. It's just x/y of something to keep it a little bit more dynamic with various fps.

Also 1/3 sleep and render if 2/3 early would be worth a try. But I don't have an ION based machine to test, so it's up to others to test what works good on low end machines. For mid range machines all this doesn't make a difference. They drop an occasional frame and that's all. And high end machines don't care at all, they can even render the frame during the vblank.

But then we came across the problem with 1:2 fps/Hz ratio. Solving this had the most impact on playback on low end machines in my opinion as Aero cannot just take the next vsync anymore. While doing this we fixed some other bugs as well and maybe even introduced a new one.

Now we are at a cross road for RC1 in my opinion: we either accept that 1:2 fps/Hz ratio stutters (was always the case with the EVR code) and reverse some changes or we accept that low end machines have more problems displaying all frames. Tough choice.

On a side note: we rely on the presentation time of a sample in 100ns units and not vsync counts. This presentation does not necessarily correspond to vsyncs as audio/video clock is not that exact. This is the small drift of the yellow line you are seeing in the stats. The more it jumps between frames the more you have a CPU/GPU limitation (CPU is currently more important from my experiments). And every process plugin that runs during playback makes this worse.