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

[tourettes]

Just had a look at MPC-HC's evr implementation and from what i saw at first sight (don't have much time currently) is that the measure or know, how long it took to present the last frame, when the next v-sync happens and so on.
I think these are exactly the "things" we need to know to make our EVR impl. really efficient but that leads to "implements MPC-HC's evr method" which won't happen for MP 1.1.0.
I just wanted to state, that we probably have to gather and use these values to really improve things

And for MPII we could completely rely on the DirectX / DWM for the scheduling

 

[OnkelChris]

AW: Re: Problems with dropping frames with EVR

...

• Drop XP / Vista support completely from EVR (this allows one less texture copy step to be performed because DWM can access the application provided texture directly in Windows 7, where as Vista is forcing us to do one extra step). For more information please read the whole article in Direct3D 9Ex Improvements (Windows)
• Drop the ATI flickering
• Optimize MP DirectX rendering path in general

If I had the knowledge, I would try to revert the ATI change and drop XP/Vista (do you mean to drop XP support in common or just the EVR?)... Unfortunately, I don't have...

I totally understand what tourettes is trying to explain. It's not possible to get the "extra steps" out of the code in less time. If I got it right, not only the dshowhelper is affected if changing/reverting some things, also Mediaportal itself...

I will not stop playing around with Visual Studio and share all my findings

 

[disaster123]

AW: Problems with dropping frames with EVR

What about using a continious timer which is repeating itself without using this ONE_SHOT stuff? I've never seen this in any other EVR renderer code.

Another idea to try is to play with the priority of MP, scheduler thread, presenter thread. As the scheduler and presenter are really time critical doesn't it make sense to set them to REALTIME? I've tried that but then i don't get a picture at all - but how could this be? As these threads are only doing things any X ms there should be enough free CPU time for other actions.

 

[tourettes]

Re: AW: Problems with dropping frames with EVR

What about using a continious timer which is repeating itself without using this ONE_SHOT stuff? I've never seen this in any other EVR renderer code.

It will work even worser I would say, as v-sync and the timer has no correlation at all, so it could drift. I think there is no small changes that are solving the playback issues (as stated earlier).

Another idea to try is to play with the priority of MP, scheduler thread, presenter thread. As the scheduler and presenter are really time critical doesn't it make sense to set them to REALTIME? I've tried that but then i don't get a picture at all - but how could this be? As these threads are only doing things any X ms there should be enough free CPU time for other actions.

In general the scheduling accuracy is good enough, as we don't have to present on exact the right ms (v-sync is taking care of that and also blocks the possibility to present at v-blank period). If AERO would be disabled then the accuracy would need to be brought on a different level.

"Black screen only" could be caused some bug that some of the trheads was just doing work all the time (maybe a bug).


Ps. if someone is really willing to fix the issues in EVR playback for MP1 please consider rewriting the EVR presenter code from scratch. Patching old and bad approach is not going to make miracles.

There are few directions what people should study:

1) MPC-HC way - port the whole EVR renderer code base into MP (it fits badly as it wants to control v-sync / paint positions itself -> this leads into fact that MP GUI should be also made to handle v-syncs itself or otherwise you need to delete and recreate the D3D device when video playback starts or stops)

2) Use DWM all the way - Drop Vista & XP support form EVR completely and use all the bells and whistles that Windows 7 provides for frame scheduling

3) maybe some 3rd way that someone else figures out

 

[disaster123]

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.

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.

 

[tourettes]

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.

 

[disaster123]

AW: Problems with dropping frames with EVR

I wanted to log on every schedule and present (so every 20 or 10ms) but this causes a lot of extra frame dropping BUt perhaps this was also causes by the massive disk writing... puh i'm out of ideas then.

 

[OnkelChris]

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

2) Use DWM all the way - Drop Vista & XP support form EVR completely and use all the bells and whistles that Windows 7 provides for frame scheduling

If I could decide, I would go this way... XP doesn't really support EVR and Vista... what should I say, it's Vista

I wish I would have enough knowledge about this.

@tourettes:
Dropping XP and Vista out of EVR... does this mean, to only change things in dshowhelper or are there more changes inside MP?

@disaster123:
I did a logging at every schedule too, but it wasn't that much difference. Just the HDD was more in use

 

[tourettes]

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

@tourettes:
Dropping XP and Vista out of EVR... does this mean, to only change things in dshowhelper or are there more changes inside MP?

MP as well, as the DirectX rendering type must be changed to get rid of one extra texture copy step.

 

[OnkelChris]

AW: Problems with dropping frames with EVR

thx for the answer... Unfortunately, this is far, far away from what I could try...