Reply to thread

Message

<blockquote data-quote="Pat Clark" data-source="post: 924617" data-attributes="member: 123421">I got some more debugging done.&nbsp; There's a lot to report -- I hope I remember it all.&nbsp;The big news (for me) is that I can now deinterlace a 1080i/60 signal.&nbsp; Before this, it would stutter so much, I disabled deinterlacing and lived with the &quot;combing&quot; artifact that results for fast motion images.&nbsp;It appears there is some sort of feedback between MMCSS buffering and dshowhelper's reporting.&nbsp; It's as if the buffering leaves more time for dshowhelper, or dshow, or something.&nbsp; When drops are reported, there often is no discernible visual effect, but it's hard to be sure with the reporting distractions.&nbsp; Does the drop number mean frames that definitely are dropped, or just expected to be dropped?&nbsp;With a 720p/60 signal, all is well with 3 buffers.&nbsp; With a 1080i/60 signal, there is (was -- fixed) unacceptable performance, even with 7 buffers.&nbsp; Wikipedia says that 730p/60 and 1080i/60 have the same 37Mhz data rate, so I reason the GPU load must be similar.&nbsp; One of my 1080 test channels has a sub-channel (for a weather station) and that channel does worse than another channel which has no sub-channel.&nbsp; With a sub-channel, the incoming data rate must surely be lower than without a sub-channel.&nbsp; The only thing I can think of that might explain the results I see is that the GPU has more work to do to decompress the lower data-rate signal.&nbsp;I then attacked the intermittent long renders.&nbsp; I disabled a couple of likely CPU hogging services.&nbsp; I disabled &quot;performance logs,&quot; &quot;security center,&quot; &quot;super fetch,&quot; &quot;windows font cache,&quot; and &quot;windows search.&quot;&nbsp; This allowed 1080i/60 to operate very smoothly with 7 buffers -- the graph is virtually flat.&nbsp; This is with nothing extra running.&nbsp; When I start my email client (Thunderbird), there is a period of time (a minute or two) of disturbance and many drops, after which it settles down and runs smoothly, although Thunderbird must run quite often since the graph is never smooth, but drops are few.&nbsp;The extended period of drops when starting a program is apparently Windows attempting to re-optimize the working sets of the software.&nbsp; Like dropping a pebble in a smooth pond, the ripples eventually die out.&nbsp; The same sort of thing happens when starting a channel, but with much less time to recover, perhaps five seconds.&nbsp;Thank you Tony, for your past help and for this improvement in dshowhelper.&nbsp;One more thing -- I'm not sure there's a connection, but I have had 2 &quot;stalls&quot; of MediaPortal since installing the new version.&nbsp; I'll try to get a handle on it and get back to you.</blockquote>

[QUOTE="Pat Clark, post: 924617, member: 123421"] I got some more debugging done. There's a lot to report -- I hope I remember it all. The big news (for me) is that I can now deinterlace a 1080i/60 signal. Before this, it would stutter so much, I disabled deinterlacing and lived with the "combing" artifact that results for fast motion images. It appears there is some sort of feedback between MMCSS buffering and dshowhelper's reporting. It's as if the buffering leaves more time for dshowhelper, or dshow, or something. When drops are reported, there often is no discernible visual effect, but it's hard to be sure with the reporting distractions. Does the drop number mean frames that definitely are dropped, or just expected to be dropped? With a 720p/60 signal, all is well with 3 buffers. With a 1080i/60 signal, there is (was -- fixed) unacceptable performance, even with 7 buffers. Wikipedia says that 730p/60 and 1080i/60 have the same 37Mhz data rate, so I reason the GPU load must be similar. One of my 1080 test channels has a sub-channel (for a weather station) and that channel does worse than another channel which has no sub-channel. With a sub-channel, the incoming data rate must surely be lower than without a sub-channel. The only thing I can think of that might explain the results I see is that the GPU has more work to do to decompress the lower data-rate signal. I then attacked the intermittent long renders. I disabled a couple of likely CPU hogging services. I disabled "performance logs," "security center," "super fetch," "windows font cache," and "windows search." This allowed 1080i/60 to operate very smoothly with 7 buffers -- the graph is virtually flat. This is with nothing extra running. When I start my email client (Thunderbird), there is a period of time (a minute or two) of disturbance and many drops, after which it settles down and runs smoothly, although Thunderbird must run quite often since the graph is never smooth, but drops are few. The extended period of drops when starting a program is apparently Windows attempting to re-optimize the working sets of the software. Like dropping a pebble in a smooth pond, the ripples eventually die out. The same sort of thing happens when starting a channel, but with much less time to recover, perhaps five seconds. Thank you Tony, for your past help and for this improvement in dshowhelper. One more thing -- I'm not sure there's a connection, but I have had 2 "stalls" of MediaPortal since installing the new version. I'll try to get a handle on it and get back to you. [/QUOTE]

Verification