[ATI] Flickering, Tearing in 1080p24, smooth as silk with rendering stats enabled. dshowhelper?? (2 Viewers)

[Pat Clark]

Here is an evr.log. The 1080i video was visually smooth.

The sound was in sync with 117ms delay. Doesn't this mean buffering was taking place?

After some 6000 frames, the render time graph went flat, at which time I stopped MP. (I marked the file, near the end.)

This is Aero off, 32-bit, queued mode on (7).

 

[SciDoctor]

When Aero is OFF the best results are with EnableDWMQueuedMode=0, small drop in frames 17ms render; EnableDWMQueuedMode=1 and 60+ms and serious dropped frames.

I'd be interested in seeing the log for the Aero OFF + EnableDWMQueuedMode=1 situation - in case there is a bug in the DWM checking code. It shouldn't be enabling queued mode if Aero (DWM) is turned off.

Also you must restart MP whenever you change the EnableDWMQueuedMode registry value.

Tony

Aero OFF + EnableDWMQueuedMode=1 situation on screen stats show DWN and Q active. MP was restarted

(as an aside I see no differnce when restarting MP after reg change compared to stopping playback chenge reg and then resart playback without close/restarting MP, DWM and Q will change as desired in stats and performace changes the same as an MP restart. DO ATI drivers handle this differently to NV drivers.)

 

[SciDoctor]

Aero OFF + EnableDWMQueuedMode=0 situation on screen stats show DWN (zero) and Q active. MP was restarted.Ssecond set of logs. Performace is the same.

 

[SciDoctor]

I couldn't get the same result as last night with;

When Aero is OFF the best results are with EnableDWMQueuedMode=0, small drop in frames 17ms render; EnableDWMQueuedMode=1 and 60+ms and serious dropped frames.

Both settings gave the same result today and I restarted MP last night when the difference was so dramatic, odd oh well.

One thing I did notice is changing the Q size in the reg and the on screen stats show Q= reg setting - 1 is this correct behaviour

 

[SciDoctor]

When Aero is OFF the best results are with EnableDWMQueuedMode=0, small drop in frames 17ms render; EnableDWMQueuedMode=1 and 60+ms and serious dropped frames.

Actual visual experience I prefer Aero ON . Test material was BLU RAY. 32 bit colour output.

When I selected 16bit colour output in CATS Aero was automaticaly disabled and NOT available. EnableDWMQueuedMode=0 or =1 made no difference; smalll drop in frames 17+ms render.

Could you test with MPAR if the rendering time changes? This is mainly since MPAR will move the target v-sync. Rendering time just means the time that it took for the Present() call, which could be waiting the v-sync in addition to the actual drawing.

MPAR doesn't work so well for this set up just causes freezing when try to skip BLU RAY requiring task manager to kill MP, log attached. AERO ON, 32 bit, EnableDWMQueuedMode=1.

BUT if I just play (no skip) when EnableDWMQueuedMode=1 there is a significant drop in render time compared to EnableDWMQueuedMode=0; 30+ms down to 5ms.

Hope this is what you required. Also MPAR tends to push this system to 100% cpu usage on Broadcast DVB SD material (skipping is fine though) so it is not the audio choice

 

[Owlsroost]

The 'Q' value in the render stats is normally (length - 1). It's because (at the instant when the render stats are drawn) a sample has been popped off the internal queue but not returned to the free pool to be used again. It's a dynamic indication of the queue status, not a static value.

I've checked the DWM handling code - apart from a minor logging problem (so it says DWM composition - Aero - is enabled when it isn't), I believe the code is doing the right thing, and the other logging confirms this.

Tony

 

[SciDoctor]

Thanks that crossed my mind after I had posted it . (length -1)

Do yo think ATI handling is different to NV with DWM, this would explain a seperate issue with the standard dshowhelper.dll and triggerinng the ATI VSYNC rules on return from power saving events. Your dll 675 doesn't suffer this; does it reinitialises everytime it is envoked ?

From what I remember the ATI vsync rules are harsh; if desired refresh/fps is less than monitor refresh and greater than half monitor refresh then fps are forced to half monitor refresh.
ie. 60fps refresh monitor and you try 50fps playback media then 30fps is forced.

A very old thread I had here

https://forum.team-mediaportal.com/...and-turn-off-monitor.99965/page-2#post-931780

Was all but ignored at the time, most devs and testers had NV cards and not ATI.

 

[te3hpurp]

Hi.

I was about to comment that I tried eveything suggested here, with no luck, and that remaining fact was that enabling graphs stopped tearing. This morning I tried latest dshowhelper .676(available yesterday evening?) and all was fine. 24p worked nicely. Very Nice., so Thank You @Owlsroost