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

[tourettes]

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...

So, you are watching 1:2 material? (25 fps progressive on on 50Hz for example). Otherwise that sleep wont get triggered at all. Using Sleep(0) is not "allowed", and looping that v-sync position in more tighter loop would get the CPU usage to go out of roof.

3rd party programs should be killed and as well the 3rd party plugins and skins (especially the ones that have some extra plugins...).

 

[gemx]

Since we are currently always trying to solve the dropped frames issue - i thought about - do we really know why they occure or are we just fiddling with some timings at best will ?

So as far as i know dropped frames are in general caused by audio/video not in sync which can be caused by the following 2 circumstances:

1) GPU was too slow rendering the previous frame
2) Decoder was too slow delivering the current frame because of
2a) decoding took too long
2b) errors in the stream (wrong PTS etc.)
2c) splitting took too long

What i wanted to express:
We don't have a evr version which suits all so we have to find out were the bottlenecks are on which system.

Is there a way to output in evr.log at least if a frame was dropped because of 1) or 2) ?
We can't do much about 1) besides buying new HW but probably 2) can be solved.

 

[disaster123]

AW: Problems with dropping frames with EVR

gemx
i'm not shure cause i've not programmed the scheduler - but i mean we know why this happens or at least i believe to know it - and that is was i've tried to solve with my patch.

When we are too early with the frames the old dshowhelper simply breaks the loop but when the next start of the loop is not triggered fast enough the frame get's dropped and not displays cause scheduler and presenter are not in sync. I try to solve this with only breaking the loop when we are mor than ONE whole frame too early and otherwise to simply sleep until we're only 1/3 of framerate too early. Not shure if i was able to explain this in english.

 

[tourettes]

Since we are currently always trying to solve the dropped frames issue - i thought about - do we really know why they occure or are we just fiddling with some timings at best will ?

Fiddling is required as no one knows for example how early a frame can be presented...

Is there a way to output in evr.log at least if a frame was dropped because of 1) or 2) ?
We can't do much about 1) besides buying new HW but probably 2) can be solved.

:aint() could be used to get that info, but if I remember correctly the Present() call is blocking one (As not all are using Windows 7 and/or we are using AERO to handle the v-sync) so the results would include frame painting time and the waiting time for the v-sync so it wouldn't provide accurate / usable results. With Windows 7 / DWM we could query the current v-sync count and if the paint start / paint end v-syncs are different the paint took too long (but it could be still caused by the fact that our timing code is not working properly and we are just starting the Present() too late and GPU has no time to complete it, even it it we GT295).

 

[OnkelChris]

AW: Re: Problems with dropping frames with EVR

Since we are currently always trying to solve the dropped frames issue - i thought about - do we really know why they occure or are we just fiddling with some timings at best will ?

So as far as i know dropped frames are in general caused by audio/video not in sync which can be caused by the following 2 circumstances:

1) GPU was too slow rendering the previous frame
2) Decoder was too slow delivering the current frame because of
2a) decoding took too long
2b) errors in the stream (wrong PTS etc.)
2c) splitting took too long

What i wanted to express:
We don't have a evr version which suits all so we have to find out were the bottlenecks are on which system.

Is there a way to output in evr.log at least if a frame was dropped because of 1) or 2) ?
We can't do much about 1) besides buying new HW but probably 2) can be solved.

After trying to understand the dshowhelper sorry, I didn't "tune" things. I started to delete code, so the whole framedropping is acting with less conditions. It helped a bit... (I know I deleted some needed conditions, but it was just searching the tree in the wood...^^)

Knowing this, I did a quick stop at my hardware. tourette's hint with the low-end GPU's and nyt's hint with CoreAVC gave me point to search... Unfortunately it now ended like this:

1. original dshowhelper works smooth

2. replacing "if (*pNextSampleTime > m_rtTimePerFrame/4)" with "if (*pNextSampleTime > m_rtTimePerFrame/2)" made it a bit better

3. last patch by disaster123 nowalso works smooth, but every few secons it seems to be not as smooth as option 1 or 2



What I did:
Just changing some BIOS values, that the CPU is running at 2,0GHz instead of 1,6GHz...

The bottleneck here shouldn't be the GPU, it looks like the CPU is it.

 

[tourettes]

Re: AW: Problems with dropping frames with EVR

When we are too early with the frames the old dshowhelper simply breaks the loop but when the next start of the loop is not triggered fast enough the frame get's dropped and not displays cause scheduler and presenter are not in sync. I try to solve this with only breaking the loop when we are mor than ONE whole frame too early and otherwise to simply sleep until we're only 1/3 of framerate too early. Not shure if i was able to explain this in english.

That sounds perfectly logical and that is why I'm hoping to see the test results of that patch. One additional fix would be to try to figure out why the scheduler is early in the first place.

ps. there are two huge performance bottlenecks in our implementation

1) To solve that ATI flickering issue we needed to move from surface to texture based rendering (this costs one additional copy step)
2) Some users are having Vista on HTPC -> On Vista there is one extra texture copy step involved in DWM. This cannot be solved if we want to keep the EVR compatible with Vista / XP. Writing multiple code paths would make the code too complex and it is definitely out of 1.1.0 scope.

...there is huge extra GPU load requirements.

 

[disaster123]

AW: Problems with dropping frames with EVR

tourettes

That sounds perfectly logical and that is why I'm hoping to see the test results of that patch. One additional fix would be to try to figure out why the scheduler is early in the first place.

Sorry i wasn't able to find this out. But with my patch both should get in sync after some frames. Perhaps one thread is started before the other or so. Debugging this stuff is really difficult as printing to the log mostly results in stuttering due to massive CPU usage.

 

[gemx]

Just tested disaster's last version. It works but i get around 10 % dropped frames on 1080i content.
Also i overclocked my ION 330 board to 2.1 GHz but that didn't solve it.

So it seems as this can't be solved the easy way.
Just in theory - talking about new hardware: what would probably be the bottleneck on my ASRock ION 330 system:
1) the nVidia ION GPU
2) the Atom 330 (even if overclocked to 2.1 GHz)
3) both

Could anybody comment please?

 

[disaster123]

AW: Problems with dropping frames with EVR

tourettes
why do we use timeSetEvent in scheduler.cpp instead of AdviseTime ?

Hi tourettes i'm really sorry but this is a step too much for me - still not a C# or C programmer. I don't know how to implement this. All other code i found is using GetSyncSource and SetSyncSource - but i cannot find somethink like that in the EVR presenter.

 

[disaster123]

AW: Problems with dropping frames with EVR

here is my latest patch and the corresponding .dll but i wasn't able to integrate this timer stuff - sorry