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

[nyt]

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

tourettes
I still get stutters and dropped frames with your timing patch 2.

OnkelChris:

the V7 dll is the best so far. I only see frame drops on the most demanding of material (bird scene from earth @ 1080p). Is there any way you can provide more slack for rendering?


So, I have another question. DWM supports buffering of up to 8 frames. Why is this not being used?

Also, if the extra copy is only needed for ati, can't we detect ATI hardware/drivers and only do it then?

 

[tourettes]

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

@tourettes
I still get stutters and dropped frames with your timing patch 2.

@Onkelchris:

the V7 dll is the best so far. I only see frame drops on the most demanding of material (bird scene from earth @ 1080p). Is there any way you can provide more slack for rendering?

I'll have to test how that DLL is working. Didn't have time last evening.

So, I have another question. DWM supports buffering of up to 8 frames. Why is this not being used?

- Some users still insist that XP needs to be supported with EVR (we cannot drop it at this stage of 1.1.0 development)
- Would require huge changes in EVR renderer to use DWM (same as with previous one, not possible with this stage)
- For 24fps material buffering 8 frames would require 8x 41.66 ms -> 333 ms audio delay to be used (complicates things again a lot when we don't have our own audio renderer)

Basicly it is just too big change...

Also, if the extra copy is only needed for ati, can't we detect ATI hardware/drivers and only do it then?

As stated earlier there are huge amount of places where the changes were needed and that time when the flickering fix for ATI was added it was decided that there is too different code paths for Nvidia and ATI it would cause easialy regression on

 

[nyt]

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

@tourettes
I still get stutters and dropped frames with your timing patch 2.

@Onkelchris:

the V7 dll is the best so far. I only see frame drops on the most demanding of material (bird scene from earth @ 1080p). Is there any way you can provide more slack for rendering?

I'll have to test how that DLL is working. Didn't have time last evening.

So, I have another question. DWM supports buffering of up to 8 frames. Why is this not being used?

- Some users still insist that XP needs to be supported with EVR (we cannot drop it at this stage of 1.1.0 development)
- Would require huge changes in EVR renderer to use DWM (same as with previous one, not possible with this stage)
- For 24fps material buffering 8 frames would require 8x 41.66 ms -> 333 ms audio delay to be used (complicates things again a lot when we don't have our own audio renderer)

Basicly it is just too big change...

Also, if the extra copy is only needed for ati, can't we detect ATI hardware/drivers and only do it then?

As stated earlier there are huge amount of places where the changes were needed and that time when the flickering fix for ATI was added it was decided that there is too different code paths for Nvidia and ATI it would cause easialy regression on

understood. check that v7 dll, seems best so far. if any more rendering time could be added thatd be even better =]

 

[tourettes]

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

If I remember correctly that value is the average how much the frame time varies. So, it is not directly possible to compare it pixel amount. On my dev pc, with SD material it is something like 0.0xx ms

Generally there is not that much we can do to help the GPU to do the video streching (which is done when video frame and display resolution differs). We just as DirectX to stretch the texture, thats all.

ps. MPC-HC uses pixel shaders to get better quality resizing but lot of low end GPU users are complaining about stuttering

 

[tourettes]

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.

I think we need to open a new thread after we have few good DLL candidates and then have few days time reserved for testing (with good and clear instructions, preferably some system specs template...)

...and that sync glitches indeed needs to be removed as it just confuses users

 

[OnkelChris]

AW: Problems with dropping frames with EVR



About a beginner or why sleep sometimes is useful:
After looking at the thousands of rows in the dshowhelper, I tried to get into it. There are many things I only can guess why they are there, but at the end, I got what I wanted -> a bit understanding of what I can do to improve things.
Happy about knowing whats going on, I tried to get the theory from my brain inside the code.
It didn't help.
Tried it another way.
It didn't help.
Reading the orignal code again.
It didn't help.
Inventing new ways of getting things smooth.
It didn't help.
Just trying some breaks, sleeps, delays...
Guess... right. It didn't help.

The end of the story -> I thought about every frame which is late or dropped or anything else, but I forgot to check the input... I downloaded few sample files from anywhere on the world, relying on the descriptions... Now I know why it never run smooth. How can anyone get 1080i 29.97 smooth without dropping frames on a 50Hz Flatscreen? (I think nobody can)

Now I use RefreshRateChanger. Unfortunately, my TV can't show neither 60Hz nor 24Hz (I think it only can 50Hz). No matter, I can have a look at the logs, after running the sample... I hope people out there are having better hardware and better source of samples to test

At the end, I know, that the dshowhelper_V7 runs quite fine. Can't see any dropped frames running the samples at the right (or doubled) refreshrate.

I think, tourette is right in mentioning a new thread. We need to sort out, which changes are making the most MP users happy (Low- and Highend hardware).

So far

 

[Scythe42]

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

understood. check that v7 dll, seems best so far. if any more rendering time could be added thatd be even better =]

OK, let's compare timer delay to render time based on a 50Hz example. Please remember that the current timer function only works with ms, therefore I just list full integers here. And talking about 0.x ms delays has no real benefit as 1ms could already be a close call.

1000ms/50Hz = 20ms frame display time

3/4 frame time = 15ms timer = 5ms to render (MSDN recommendation of rendering 1/4 of display time before vsync)
2/3 frame time = 13ms timer = 7ms to render
1/2 frame time = 10ms timer = 10ms to render
1/3 frame time = 6ms timer = 14ms to render
1/4 frame time = 5ms timer = 15ms to render
1/8 frame time = 2ms timer = 18ms to render
1/16 frame time = 1ms timer = 19ms to render

We need to delay the rendering of samples at least a bit to make sure that the presentation time delta is bigger than display time per frame. So going down to 1ms would be a close call. We could end up rendering two frames in one vsync cylce resulting in stuttering without any log entry.

Please remember that the presentation time has no 100% direct relation to the vsync number on most machines. It's usually just sample number * time per frame. And the clock isn't that exact on most machines (especially at 23.976Hz). A 1ms delay could be a close call, especially when taking into account that any timer could be inaccurate based on external influences on a given hardware.

Also we need to make sure that 1:2 fps/Hz ratio still runs smooth. Maybe with alternative timings as it the case in current SVN.

So basically we should test between 15ms and 19ms left for rendering. Longer time doesn't necessarily mean it gets better. It could introduce other problems.

Testing would require:

• Test focus on ION/ATOM or any other lower end machine
• Test each DLL with the same sample (if possible) a few minutes long
• Don't have the stats renderer open while testing
• Do the same test multiple times to make sure it provides a similar result
• Test live tv, recorded TV, DVD and other files
• Test 1:1 fps/Hz ratio and 1:2 fps/Hz ratio
• Test for SD and HD where possible
• Same filters for each scenario
• DLLs don't show which timing is used to have a blind viewing test. Other versions will be included as well.
• Name the DLL that runs best / runs worst in a given scenario

Would this be ok or is it already too much?

PS: Please don't post anymore DLLs for now just with different timings - will open a new thread for testing.

 

[OnkelChris]

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

1000ms/50Hz = 20ms frame display time

3/4 frame time = 15ms timer = 5ms to render (MSDN recommendation of rendering 1/4 of display time before vsync)
2/3 frame time = 13ms timer = 7ms to render
1/2 frame time = 10ms timer = 10ms to render
1/3 frame time = 6ms timer = 14ms to render
1/4 frame time = 5ms timer = 15ms to render
1/8 frame time = 2ms timer = 18ms to render
1/16 frame time = 1ms timer = 19ms to render

So basically we should test between 15ms and 19ms left for rendering. Longer time doesn't necessarily mean it gets better. It could introduce other problems.

Changing the delay ended up in 1/4 for 1:1. If using lower values (1/8), things are getting bad (on my ION).
Changing the delay ended up in 1/2 for 1:2. If using higher values (2/3), things are getting bad (on my ION).

Did this on ION with MPC-HC codecs... everytime same samples. Live SDTV, recorded SDTV also tested. (recorded HDTV only for about 20seconds; not enough...). No stats renderer. Mutiple times tested. Tested 1:2 ratio and since today 1:1 (without picture, just logs; added log entries only for me to see, which delay is selected. Can confirm that I really tested 1:2 and 1:1).

Best dll so far: dshowhelper_V7

PS: Please don't post anymore DLLs for now just with different timings - will open a new thread for testing.

Sounds good

 

[disaster123]

AW: Problems with dropping frames with EVR

On my system with dshowhelper_V7 i get very often dropped frames and last time MP was crashing - also a lot of entries have "last sleep time 0.00 ms." - which produces a lot of overhead for the CPU.

For me my version with the sleep still works much better: https://forum.team-mediaportal.com/...ping-frames-evr-74360/index26.html#post575725

System:
Athlon X2 2300BE with HD3200 onboard
Win7 x64 with MS DTV Codec

 

[OnkelChris]

AW: Problems with dropping frames with EVR

perhaps this is a useless thought, but could it be that there is a big difference in handling stuff between ATI and NVIDIA? (like the flickering...)