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

[Scythe42]

Re: AW: Problems with dropping frames with EVR

attached are the changes in a patch file... Please don't blame me. I am just at the very beginning...

Late frames need to be dropped or you are introducing audio/video sync issues until the correct number of frames is dropped to bring audio video back in sync. But you never allow that.

Just not dropping them in favour of audio/video desync is not correct. If I saw it correct in the patch, audio/video can drift apart up to half a second. This is just wrong. Looks like you are not very sensitive to lipsync issues.

You basically disabled frame dropping in preference of 0.55 second audio/video lag. As a result people are seeing less dropped frames. Now they see video lagging behind audio...

So this patch doesn't solve anything and just re-introduces old bugs.

 

[OnkelChris]

AW: Problems with dropping frames with EVR



this is just the beginning of my experiences with this problem... I know that it is not the best solution (let's call it solution), but perhaps there are different sections of the code, which I will explore later on. I just want to know, where the stutters can be easily deleted...

these changes make it possible to use my ION to watch HD videos again.

EDIT:
deleted attachment

 

[nyt]

The stutter introduced by dropping frames is quite obnoxious, as it seems to choke more than as if it just dropped one frame. Often it drops chunks at a time. Something isn't right.

 

[tourettes]

The stutter introduced by dropping frames is quite obnoxious, as it seems to choke more than as if it just dropped one frame. Often it drops chunks at a time. Something isn't right.

Like said before, dropping frames is not a symptom itself. If frame is late it just needs to be dropped. The issue is else where.

 

[disaster123]

AW: Problems with dropping frames with EVR

sorry video was faster than audio...

 

[tourettes]

if (*pNextSampleTime > (m_rtTimePerFrame/2))

When such change helps, it most likely means that the GPU is not fast enough to draw the video frame in given time, unfortunately it also increases the change of frame to be presented on a wrong v-sync (especially when it comes to the 1 fps to 2 Hz material. like 25 fps PAL progressive content on 50Hz tv). Basicly we need to decide if we want to favor low end GPUs to get acceptable level of playback quality (low end GPUs wouldn't present too early that often but higher end GPUs would be having great deal of strugle to hit a correct v-sync as they would be too early in many cases) or almost perfect playback quality with higher end GPUs.

...and to solve that you would be required to write code that would do:

1) keeps count on v-syncs (DWM can provide that info)
2) delays the frame presentation in :aint() as long as the corrent v-blank is received

I spent quite amount of time to try to get that to work but with current scheduler architecture it was just pita

 

[tourettes]

Re: AW: Problems with dropping frames with EVR

This thread starts to get spammed by dshowhelper.dll's

So here another try by me - working fine for myself (only SD tested at the moment) - based on the latest SVN and it still drops late frames

Please post patches as well. Otherwise it wont hep at all. We should clean up all the .dlls that wont contain the patch file...

 

[disaster123]

AW: Problems with dropping frames with EVR

Hi tourettes i've another question.

In EVRCustomPresenter.cpp we have the following code:

	if (*pNextSampleTime > m_rtTimePerFrame/4)
    {
      break;
    }

So if we skip here as the frame is too early - who schedules the next frame fast enough scheduler.cpp already thought this is OK and who cares about that the next frame schedule is fast enough to try this again? What about sleeping instead of breaking?

 

[gemx]

if (*pNextSampleTime > (m_rtTimePerFrame/2))

When such change helps, it most likely means that the GPU is not fast enough to draw the video frame in given time, unfortunately it also increases the change of frame to be presented on a wrong v-sync (especially when it comes to the 1 fps to 2 Hz material. like 25 fps PAL progressive content on 50Hz tv). Basicly we need to decide if we want to favor low end GPUs to get acceptable level of playback quality (low end GPUs wouldn't present too early that often but higher end GPUs would be having great deal of strugle to hit a correct v-sync as they would be too early in many cases) or almost perfect playback quality with higher end GPUs.

...and to solve that you would be required to write code that would do:

1) keeps count on v-syncs (DWM can provide that info)
2) delays the frame presentation in :aint() as long as the corrent v-blank is received

I spent quite amount of time to try to get that to work but with current scheduler architecture it was just pita

Since the number of people using an ION board is increasing rapidly where in the range of low-end GPU -> high end GPU would you rate the ION?

Mine is never using more than 64 % GPU even with HD so i would assume it's fast enough or can't the function the GPU offers just no be used for H 264/AVC-1 decoding and therefore it's still lagging for HD decoding?

 

[tourettes]

if (*pNextSampleTime > (m_rtTimePerFrame/2))

Please test following DLL. Should give more time for low end GPUs to render the fram (actaully 100% more time). Seems to work as well with the GT220 (with only quick testing...).