[other] Problems with dropping frames with EVR (2 Viewers)

[disaster123]

AW: Problems with dropping frames with EVR

nice to hear that - hopefully tourettes can say something about my changes at what he thinks

 

[tourettes]

Re: AW: Problems with dropping frames with EVR

One (maybe silly?) question: Do those changes also affect VMR9 playback or are those changes only relevant for EVR (and thus irrelevant for XP-users)?

Completely irrelevant for VMR9 and XP users as well (EVR shouldn't ever be used with XP).

 

[tourettes]

With all dlls I have tested until now I get this "sawtooth" graphs... I wonder where this comes from.

Do you have AERO enabled? It could be possible that the v-sync is not used and that would explain the really bad looking raster offset graph. It should be as smooth as possible, as it will tell where the :aint() was started in the v-sync cycle.

 

[tourettes]

Re: AW: Problems with dropping frames with EVR

nice to hear that - hopefully tourettes can say something about my changes at what he thinks

In a quick peek (will check it and test in more detail hopefully in the evening) the patch looks ok. But at least the Sleep() should be replaced with something more accurate. Maybe with

- Similar timer callback as in Scheduler.cpp side
- by using directshows reference clock's AdviceTime -> IReferenceClock::AdviseTime Method (Windows)

 

[disaster123]

AW: Problems with dropping frames with EVR

good idea - but will only have the chance to do this this evening - or perhaps you'll do it

 

[tourettes]

Re: AW: Problems with dropping frames with EVR

good idea - but will only have the chance to do this this evening - or perhaps you'll do it

I might have 30 minutes (as usual) to code something. And testing the patch requires even more than that, so if someone else can provide the more accurate timer to replace the Sleep() I would be more than happy

 

[disaster123]

AW: Problems with dropping frames with EVR

OK will try todo that this evening

 

[belcom]

With all dlls I have tested until now I get this "sawtooth" graphs... I wonder where this comes from.

Do you have AERO enabled? It could be possible that the v-sync is not used and that would explain the really bad looking raster offset graph. It should be as smooth as possible, as it will tell where the :aint() was started in the v-sync cycle.

I grabbed some screenshots with AERO disabled. It definitely NOT uses v-sync!! With AERO enabled v-sync was ok.
All done with latest disaster dll as this works best for me here.

pic 1: HD in fullscreen
pic 2: HD within skin
pic 3: SD in fullscreen
pic 4: SD within skin

As you can see, there are always more dropped frames than drawn ones!?! (although it looks smooth despite the missing v-sync)
Sawtooth in Raster graph is still present.

EDIT: maybe the problem is introduced by the sleep(1), because a sleep of 1ms gets never achieved in the threading cycle, especially not with "slow" CPUs (I have Celeron E3200 here). Such a sleep would be 10 to 15ms at least! I wonder why the ATOM guys don't have this issue. The actual sleeptime is of course also affected by the runtime of other threads... I go try killing as much other apps as possible...

 

[tourettes]

pic 1: HD in fullscreen
pic 2: HD within skin
pic 3: SD in fullscreen
pic 4: SD within skin

Few notes:

- Dropped frames increases when MP GUI is rendered -> GPU has not enough power to render as rendering MP GUI requires extra work on top of the video frame painting

- Pretty close to 50% are dropped in fullscreen. I have no explanation for this (maybe software decoding is used?)

 

[belcom]

pic 1: HD in fullscreen
pic 2: HD within skin
pic 3: SD in fullscreen
pic 4: SD within skin

Few notes:

- Dropped frames increases when MP GUI is rendered -> GPU has not enough power to render as rendering MP GUI requires extra work on top of the video frame painting

- Pretty close to 50% are dropped in fullscreen. I have no explanation for this (maybe software decoding is used?)

Same again, this time with AERO enabled.
Dropped frames are greatly reduced, but graphs jump higher.