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

[belcom]

While testing the Timing2 dll I found out something very odd to me.
See my 2 attached Snapshots.

pic 1 was taken with output resolution in FullHD (1080p) and Video (720i) in native res.
pic 2 was taken with output resolution in HD (720p) and Video (720i) also in native res.

Why does the display resolution dramatically change things, if video size and therefore what needs to be rendered is always the same??

1920 x 1080 = 2073600
1280 x 720 = 921600

2073600 / 921600 = 2.25

FullHD has 2.25 times more pixels than 720p...

So if SDev raises say to a triple I would understand it, but why does it grow from under 1ms to 6.5ms??

Could it be that our big issue is less in the timing but more in the resizing part? (altough in my example no resizing would be needed at all)
Or is there another explaination for this?

Who else has such behavior?
What is your "main" resolution?

 

[OnkelChris]

AW: Problems with dropping frames with EVR

belcom:
had such a behaviour on another HTPC... I thought, the hardware was not enough to display MP in 1920x1080...

now my main resolution is 1200x670 (1280x720 cropped, because my TV can't do 1:1 pixelmapping) on an ION

EDIT:
Tried different resolutions. Same behaviour like belcom mentioned...

 

[Sebastiii]

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

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

if (*pNextSampleTime > (m_rtTimePerFrame/4))

to

if (*pNextSampleTime > m_rtTimePerFrame)

if (fabs(p->pPresenter->GetDisplayCycle() - timePerFrame/20000) < 0.0015)
      {
        delay = hnsSampleTime[B]*3/4[/B];
      }
      else
      {
        delay = hnsSampleTime[B]*2/3[/B];
      }

ends in less dropped frames on my ION. Are there any problems in this?

Both changes seem to work on a quick test (I'll continue to test more). DLL attached (make sure that version in log is 1.1.1 when testing).

We are mainly interested to hear if ION is behaving any better with these sceduling values. As well that these aren't breaking current SVN behavior on high end systems.

Hi,

On my HTPC (I7 + ATI 5770) it works good for my little test that i made
Cheers,
Seb.

 

[Scythe42]

dshowhelper_timing2 works best and with only a dropped frame here and then on 1080i

That sounds promising. Looks like we make progress here based on disaster123's idea of sleeping instead of rescheduling. Should it be possible to get it decent for low end machines without breaking other stuff? That would be awesome.

Timing2 is good on my Atom system as well. Less than 1 dropped frame in every 1000 frames. I even only get a couple of dropped frames with shift+1 running, while I would get a lot more with the latest SVN when the grafs were running.

Sounds even more promising. Let's wait for some more feedback.

I do get quite a lot of sync glitches, although it seems to an on / off thing. Sometimes then sync glitches keep on counting up quickly, other times not at all. I'm not quite sure what that means, I can't see anything that is out of sync og stuttering on the tv.

If you don't see stuttering while the glitches count up just ignore them. The algorithm used to detect potential glitches that could be corrected is far from perfect. We probably remove them from the stats renderer as it confuses people more than it does good.

What are the disadvantage of my changes? It seems to help a lot on ION systems and normal systems are also running fine and i don't break anything with 1:2 hz/fps and so on

It's perfectly OK even though you reverted a bit too much code. I just tried to combine the idea of "don't reschedule" with "render as early as possible". It came to to me while looking at your patch and thinking about the description I wrote of the current code logic.

When I started to work with the code there was always a /x something that added up to 1 with the value from the scheduler. It made sense. Never crossed my mind that we can render a frame right away once it was scheduled without skipping frames unintentionally. Prior efforts to change something in this area didn't work so well as I was thinking too complex.

I just thought we give it a try with a simpler patch trying to achieve the same idea. Just need to find out which of all the daily versions work the most reliable for most people here and maybe go for one round of fine tuning with a batch of builds to compare in one post.

@All:
Again thanks for keep testing even though there is a flood of dshowhelpers in the recent days. This is the spirit of open source. Everybody contributes to the project to his best of his abilities.

 

[OnkelChris]

AW: Problems with dropping frames with EVR

too bad, i can't test HD LiveTV... but SD did 84000 frames, 1 dropped, 400 sync glitches.

The 2 HD LiveTV samples I have (about 10 seconds each; BBC HD, ARD HD) work smooth.
for some HD videos, I still need my ION @2,0GHz. Perhaps they are encoded bad.

gemx
which codec do u use?

 

[Sebastiii]

Re: AW: Problems with dropping frames with EVR

please wait 2 more minutes and test this one on your highend machine...

changed this

if (fabs(p->pPresenter->GetDisplayCycle() - timePerFrame/20000) < 0.0015)
      {
        delay = hnsSampleTime/2;
      }
      else
      {
        delay = hnsSampleTime/4;
      }

and this

if (*pNextSampleTime > m_rtTimePerFrame)

Please all ION users test. It seems to work good with less changes (on lowend)

EDIT:
patch inside

Hi, i tested too, and on my HTPC, really good too, i didn't test liveTV, but series, movies in 23.975Hz 50Hz it's ok (i use refreshrate to set 23hz, 50hz and 59hz).
Seb.

 

[nyt]

i'll do some testing when i get home on my ion as well with 23.976, 25@50, and 60p.

 

[OnkelChris]

AW: Re: Problems with dropping frames with EVR

dshowhelper_timing2 works best and with only a dropped frame here and then on 1080i

That sounds promising. Looks like we make progress here based on disaster123's idea of sleeping instead of rescheduling. Should it be possible to get it decent for low end machines without breaking other stuff? That would be awesome.

Thats not the whole truth... the "timing2" is the one provided by tourettes with my changes. I changed the scheduler in

if (fabs(p->pPresenter->GetDisplayCycle() - timePerFrame/20000) < 0.0015)
      {
        delay = hnsSampleTime*3/4;
      }
      else
      {
        delay = hnsSampleTime*2/3;
      }

and in EVRCustomer...

if (*pNextSampleTime > (m_rtTimePerFrame/4))

to

if (*pNextSampleTime > m_rtTimePerFrame)

with a "break" right after. No Sleep or similar from disasters code....

Just want you to get it right, that we are looking at the same...

 

[Scythe42]

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

with a "break" right after. No Sleep or similar from disasters code....

Disaster123's sleep idea instead of rescheduling is what brought the idea of "why reschedule or sleep anyway, just present the thing". Doesn't mean that the actual sleep code was used. But of course you deserve some credits here as well for your tireless efforts.

 

[OnkelChris]

AW: Problems with dropping frames with EVR

hmm... i must improve my english...

it's not about getting credits. I read your post and thought you think, that disaster's sleep() is implemented in the "dshowhelper_timing2" provided by tourettes (making 1080i work on gemx's atom).

for sure, you have much more experience than me. I'm just trying to keep as much of the original stuff, to not break any other features. If disaster's sleep idea is the better one for MP and is not breaking things, than I'm happy too.