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

[nyt]

Re: AW: Problems with dropping frames with EVR

@tourettes
the black screen or let's thay when starting a channel the MP GUI simply stays and only audio appears happens when i set the scheduler and or the EVR renderer to REALTIME - have you tried this? I'll try to find out what is happening this evening.

Using real time is always risky as if you manage to write bad code, lot of OS code is running on lower priority.

I tried telling DWM that it should use multimedia priority class. This was recommended by MS, but it causes stuttering after switching refresh rates... and didn't seem to help at all for the frame dropping (I guess this tells that DWM is not to blame).

Can you perhaps tell me if there is a way to do logging in dshowhelper without creating too much CPU load? Every time i try to log things - this creates a lot of additional CPU load.

Maybe direct all the logging to debug messages and use debugview to view those. btw I haven't ever seen high CPU usage even when enabling the EVR traces. Those are logging multiple lines per one scheduler frame.

maybe try enabling the mmcs at the end of the thread that runs to fix the stutter crap in refreshrate changer and see if it helps anything. windows wasn't getting the right refresh rate until that point..

I think something is still being missed. Why can I play the same 1080p content perfectly with a 60hz refresh rate, but not as well at its native 23.97 refresh rate? You'd think it'd be the opposite, since at 60hz it's painting more frames and has a shorter sync interval. This would probably be something worth looking into. Also, people are seeing the problems with hardware that isn't exactly low end.

I think it is still completely related to the performance bottleneck (as with even 60Hz you are getting dropped frames, but not as much). On 60Hz the v-sync period is almost three times smaller than the v-sync time on 23.976Hz. This difference will give an advantage for the 60Hz mode, it will have less waiting for the GPU when it is sitting in the displays v-blank and therefore give more time for GPU to render (EVR renderer doesn't care if the rendering caused v-syncs to be missed or if the rendering takes multiple v-syncs.) Therefore if someone is able to tell how long v-blank periods are taking, we could easialy calculate how much more spare time GPU has in 60Hz mode.

I have no proof on this, but sounds only plausible explanation.

btw. performance issues are easy to rule out. Just use 640x480 resolution on 23.976Hz and re-encode some blu-ray content to same frame size. Does MP still behave badly on that 1:1 case?

it dropped like 3 frames on the hardest to render 1080p video that i know of, and only with the ! menu up. thats a big difference from dropping 30 at 24hz.. hm.. weird

 

[Scythe42]

Re: AW: Problems with dropping frames with EVR

maybe try enabling the mmcs at the end of the thread that runs to fix the stutter crap in refreshrate changer and see if it helps anything. windows wasn't getting the right refresh rate until that point..

Been there, done that. Doesn't make a difference in playback quality as we do not need exact scheduling. It only re-introduces stutter for 50Hz/60Hz after playing 23.976fps.

Giving low end machines the maximum time for rendering a sample is the only thing we can do. For everything else the whole GUI painting needs to be done in a different way that's only really possible on Win7. Just playing with scheduling and thread priorities doesn't solve this fundamental problem of too weak CPU for what MP1 needs to do at the moment.

You can always use an external player that doesn't have this issues if even disabling all process that don't deactivate themselves during movie playback doesn't help.

 

[OnkelChris]

AW: Problems with dropping frames with EVR

nyt:
don't know, if this makes any difference, but could you try to set your refreshrate to 24 instead of 23.97?

Scythe42:
is the 23.976Hz something special? I don't have such big differences between 1:1 and 1:2...

 

[nyt]

Re: AW: Problems with dropping frames with EVR

@nyt:
don't know, if this makes any difference, but could you try to set your refreshrate to 24 instead of 23.97?

@Scythe42:
is the 23.976Hz something special? I don't have such big differences between 1:1 and 1:2...

the media is at 23.976. I'll try setting to 24.0 and see if it helps any, but 23.97 is closer

 

[disaster123]

AW: Problems with dropping frames with EVR

I read the code again and again and have two questions again perhaps tourettes or scythe42 can answer them:
1.) in Scheduler.cpp SchedulerThread run in a while loop - at the end of the loop we create a timeSetEvent but at the beginning of the loop we kill this event again:
timeKillEvent(lastTimerId);
Why?

2.) CheckForScheduledSample in EVRCustompresenter gets all samples from the queue until the queue is 0 then it returns and the scheduler tells via the timeSetEvent that "p->eHasWork" is this correct?

3.) not an issue only code redundancy:

     if (p->bDone)
    {
      Log("Scheduler done.");
      if (lastTimerId > 0)
      {
        timeKillEvent(lastTimerId);
      }
      p->csLock.Unlock();
      return 0;
    }

Why do we try to kill the timer again? doesn't make sense as it is already killed above.

 

[disaster123]

AW: Problems with dropping frames with EVR

Can anybody also tell my how it could be that the hnsSampletime is sometimes higher than timeperframe and still no frame drops? Or isn't hnsSampletime the time it took to present the last sample?

 

[OnkelChris]

AW: Problems with dropping frames with EVR

i will disaster, i will...

 

[nyt]

i'll test as well

 

[disaster123]

AW: Problems with dropping frames with EVR

sorry were too fast - i still need too know some things i asked above.

 

[tourettes]

Re: AW: Problems with dropping frames with EVR

Can anybody also tell my how it could be that the hnsSampletime is sometimes higher than timeperframe and still no frame drops? Or isn't hnsSampletime the time it took to present the last sample?

Maybe codec was too slow? Or EVR mixer is trying to change the sceduling logic for some reason (maybe because the feedback we are providing, which might be wrong).