GUI and VMR9 FPS bug. (1 Viewer)

[SciDoctor]

This problem occurs with VISTA32, XP and w2ksp4.

Since RC2 (didn't occur with RC1) the MP GUI can't achieve greater than approx 60FPS. (settings up to 100FPS aren't working)

When playing back 50FPS material (irrespective of codec) the VMR9 renderer struggles to achieve 50FPS averaging only 48FPS causing visible stutter and dropped frames (I must stress that RC1 svn 15757 has NO problems with locking to 50FPS with same material and OS and PC).

Now there is no problem with 24,25 and 30 FPS material.

On some VISTA 32 systems the GUI is being forced to 30FPS irrespective of any settings and when playing back 50FPS material it is also forced to 30FPS and severe stutter.

The (!) is where the info is from.

There seems to be a fight between GUI and video for accurate FPS.

All monitors and gpu drivers can achieve the desired refresh and FPS (svn 15757 has no problems in this respect)

 

[rtv]

As you might have seen from the log of D3DApp.cs and MediaPortal.cs there hasn't been a specific change which might have lead to this behavior. Furthermore there's no special handling for vista regarding GUI FPS.

While you're at it: could you please give me the exact revision of RC2?

 

[Spragleknas]

My experience is the same; starting @ 40+ fps - peaking at 49,x - never seen 50 fps. Average wouldbe between 48-49.

Remark: I've only tested with TV (TVE2). Not using HW-acc. (DXVA) fps is abou 23-24 (never 25). Can't remember any numbers form RC1, though...

 

[Pascal]

On some VISTA 32 systems the GUI is being forced to 30FPS irrespective of any settings and when playing back 50FPS material it is also forced to 30FPS and severe stutter.

I noticed that vista's regional settings have influence on the video format. My s-Video output was put to NTSC after reboot (I use PAL normally). Changing the regional country to one using PAL solved this issue. Maybe this has influence on your 30 fps (NTSC?)

Pascal

 

[SciDoctor]

Regional settings per OS are set to UK so this should be fine.

The very first v0.2.3.0 RC2 release and all SVN's onwards including RC3 and Final and SVN's.

The change/problem occured from RC1 SVN15757 (which is fine on all OS).

Makes no difference if tv2 or tv3.

 

[SciDoctor]

This bug has now got even worse as now returning from hibernation and the GUI is locked at 40FPS max which also locks VMR9 to 40FPS max.

The same result on six different systems, different OS and various ATI GPU

Latest SVN 16940.

Logs attached for one system

 

[Spragleknas]

In setup there is now an option to restart MP after resuming to avoid this (later SVN)

 

[SciDoctor]

In setup there is now an option to restart MP after resuming to avoid this (later SVN)

Thanks(I have seen that) BUT, but a BUG should be corrected and not another workaround injected into MP code.

 

[rtv]

In setup there is now an option to restart MP after resuming to avoid this (later SVN)

Thanks(I have seen that) BUT, but a BUG should be corrected and not another workaround injected into MP code.

Well - as you can see from MediaPortal.cs and D3DApp.cs the resources are freed and the graphics device is reset on resume. To the knowledge of the team this is all we can do with .NET and dshow. So we either need:
1. Microsoft to fix/extend the device reset
2. Microsoft to tell us an undocumented workaround
3. A smart community guy who knows another method which does not require to restart MP.

You're right - we'd be happy with any of these solutions

 

[SciDoctor]

Thanks for the reply/feedback.

I understand the points you put forward but why do earlier versions of SVN and final releases NOT suffer from the same symptoms.

Specifically SVN 15757