MP 1.3.x dshowhelper development (1 Viewer)

[cruse]

I don't know if dshowhelper is the right place for my suggestion, but wouldn't it be better to start counting dropped frames after a certain period of time or number of frames? Since starting, skipstepping or channel changes almost always result in a few dropped frames.

If you could implement a 2 second delay or force 200 frames to pass or something like that, we could all take the same 1080i .ts sample and have a community benchmark with different hardware and DWM/MMCSS settings to find somewhat of a sweet spot.

 

[Owlsroost]

'Pause' will also reset the dropped frame counter, so doing that just after the start is the best way of clearing the initial dropped frame count.

Tony

 

[Pat Clark]

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.

 

[Owlsroost]

Pat - which dshowhelper registry settings are you using (just so we know) ?

Tony

 

[Pat Clark]

Registry settings I settled on for handling 1080i/60 with some Windows Services disabled:
EnableDWMQueuedMode=1
EnableMMCSSforDWM=0
EnableMMCSSforSchedulerThread=1
NumDWMBuffers=7

I also delayed the audio by 7/60 second, or 117 ms.

 

[wonkyd]

Owlsroost are you still using the nVidia Tesla drivers with your GT430 or are you on the stock GeForce drivers? Sorry for being off topic!

 

[Owlsroost]

Owlsroost are you still using the nVidia Tesla drivers with your GT430 or are you on the stock GeForce drivers? Sorry for being off topic!

Currently on 276.52 Tesla/Quadro - I tried a 295.xx version recently and had black screen problems after resume from sleep, so I reverted back. Not tried any 3xx versions yet.

Tony

 

[Owlsroost]

v667 is now on the first page

Tony

 

[red5goahead]

Owl, Which is the best MPAR for these new releases? the original one deployed with the 1.3.0 is it still good?
Because I've some problem , sometimes the audio become jerky for few seconds (stretching 24P->25P). (Note that now I'm using a Realtkek embedded with my Asus P5K not the Xonar)

 

[doveman]

I've started having problems with LiveTV 'sticking' (i.e. the video freezes for a brief moment) which have only started recently, so I suspect v666 of this which I installed a couple of days ago. I see there's a v667 now so I'll try that but if there's no changes in that which could possibly fix such a problem, please let me know if logs would be helpful.