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

[JackTramiel]

AW: Problems with dropping frames with EVR

Might be a stupid idea, but how about a option during setup what kind of display is used and install the "best" solution for it?

 

[tourettes]

@tourette:
Can you try this and check if it breaks 1:2 fps/Hz? In theory you could remove the stuff you added to the scheduler.cpp when m_rtTimePerFrame is correct for 25p material at 50Hz.

I'll test...if my dev PC will stop rebooting in a loop (10 min and a reboot)... I guess PSU is dying, again...

 

[OnkelChris]

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

yes and no:

1) ATI starts to flicker
2) reducing the 2nd step would make Windows 7 dependency

Is it possible to point on the code for this or giving a diff file with the code you implemented for 1) and 2)?

 

[grubi]

AW: Re: Problems with dropping frames with EVR

I would recommend "...accept that 1:2 fps/Hz ratio stutters (was always the case with the EVR code) and reverse some changes..." since more and more users are going to use some lower end machines (Atom, ION ....) as they are very silent and don't use much power.

Also the more CPU the renderer needs MP is getting more and more useless.
On my current machine which is (overclocked though) a 2.0 GHz Atom dual core + an ION GPU i can only watch 1080i absolutely smooth when i disable nearly every plugin.
So more and more people may say
"Hey, wait - MP with only the Tv plugin and pictures and videos and nothing else do have full HD? Are you crazy? I will stick with 1.0.2 stable and wait for MP II"

What i wanted to say is that over all improvements MP 1.1.0 brings, we can't tell the user that you can only use it with full HD content if you have a > 3 GHz dual core + > GeForce 220 system

Would at be at least possible to make this configurable by a simple switch in config.exe (LoPower/HiPower profile or something like that)?


grubi.

 

[tourettes]

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

Would at be at least possible to make this configurable by a simple switch in config.exe (LoPower/HiPower profile or something like that)?

And how many people are able to tell which is the correct setting? 25% of forum users, and most likely 5% of rest of the MP users

 

[tourettes]

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

yes and no:

1) ATI starts to flicker
2) reducing the 2nd step would make Windows 7 dependency

Is it possible to point on the code for this or giving a diff file with the code you implemented for 1) and 2)?

#1 is implemented about a year ago (sorry, Mr Hipp is the only one who knows what exactly was changed in multiple SVN commits ) - contains changes on MP and dshowhelper side.

#2 hasn't been ever implemented and would require few weeks at least to be implemented (with the option that someone has free evenings to work with such huge change).

 

[tourettes]

Can Atom users not select to use VMR9 under Vista / Win7 ?? I am running XP and full HD is not problematic with a 2.2Ghz dual core processor and same graphics chip as the Atom setup (9400 based IGP)

VMR9 + Vista / W7 -> tearing as no exclusive DX mode is used.

 

[grubi]

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

Would at be at least possible to make this configurable by a simple switch in config.exe (LoPower/HiPower profile or something like that)?

And how many people are able to tell which is the correct setting? 25% of forum users, and most likely 5% of rest of the MP users

Sure?
I think there are a few other settings already there which are not self explanatory.
So a simple switch with explanation "enable on low power machines if you encounter the following symtoms" should be understandable by most (maybe I'm wrong).

Cheers.

 

[tourettes]

There's one more thing you guys can try. As said I rarely have dropped frames and therefore can't really reproduce the issues here. But I just had an idea:

In CheckForScheduledSample() don't reschedule current samples at all.

I mean exchange the

if (*pNextSampleTime > (m_rtTimePerFrame/4))

to

if (*pNextSampleTime > m_rtTimePerFrame)

and leave everything as it is in SVN for now.

Then it would break and reschedule a sample if the delta of the presentation time is larger than the duration of a frame which means it is one of the frames in the queue. Maybe this could help and this is where the actual problem lies...

If this helps a bit, then try use *3/4 or *2/3 in scheduler.cpp depending on how early a sample needs to be presented on a machine to be there in time.

@tourette:
Can you try this and check if it breaks 1:2 fps/Hz? In theory you could remove the stuff you added to the scheduler.cpp when m_rtTimePerFrame is correct for 25p material at 50Hz.

An quick testing that gives good results on SD / HD and 1:2 PAL material.

 

[tourettes]

Here's the DLL to match Scythe's proposal:

if (*pNextSampleTime > (m_rtTimePerFrame/4))

to

if (*pNextSampleTime > m_rtTimePerFrame)

Please test and report back.