MP 1.3.x dshowhelper development (1 Viewer)

[SciDoctor]

I have posted logs to show improvements and possibly in comparison you can see where any further improvements can be found (if any)

Using my most difficult channel BBC NEWS SD, with its horizontal scrolling text; 676 visual improvements are noticeably smoother, stats show raster is very flat and, square wave for fps (interlaced material?) almost perfect in comparison to 675.
The only area that can if possibly be improved is the render time with the stats showing imporvement but a slightly sinusoidal waveform instead of flat, fall and rise coinciding with the interlacing if that makes sense.

Many thanks again.

 

[Pat Clark]

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

I can confirm SciDoctor's earlier report that queueing takes place with Aero off and EnableDWMQueuedMode=0. At least the "Q" reported in the stats fluctuates, so I presume your internal queue is distinct and runs always.

The temporary solution I was using for sound sync (delay in LAV audio) caused unsync in 24fps material, so I killed that and added EnableDWMAudioDelayComp=1. This fixed the 24fps sync. I previously had reported TV sync is "off" a little that way, but now it seems not, so I'm happy with 676.

Aero: off, 32-bit desktop. When stable, render reduced by about 3.5% from 13.5 to 13.0ms, similar to SciDoctor's report.
Running almost anything else, such as EditPad, disturbs the graph/drops/etc., even when just sitting there not doing anything. Perhaps it would resync and flatten out again with time -- untested.

EnableDWMAudioDelayComp=1
EnableMMCSSforDWM=0
EnableDWMQueuedMode=0
EnableMMCSSforSchedulerThread=1
ForceFirstFrame=0 == What does this do?
LowResVSyncCorrectionTiming=1
NumDWMBuffers=7 == Q seems to be fairly stable at 4 in stats. Are they related?
SampleQueueSize=5
SchedulerThreadMmcssPriority=3
TimerThreadMmcssPriority=1
WorkerThreadMmcssPriority=2

 

[Owlsroost]

The number of DWM buffers and the internal sample queue size are unrelated.

'Q' on the render stats is the actual number of samples in the internal queue - in a fast enough system, it's normally SampleQueueSize-1 (at the instant when the render stats are drawn, there is one sample which is allocated but not in the queue, hence the -1).

'DWM' is a static value which = NumDWMBuffers, unless EnableDWMQueuedMode=0 when it should display 0.

Tony

 

[Owlsroost]

v677 added - controllable FPS rendering rate limiter added, in case it's useful to get smoother video on low GPU performance systems (e.g. systems which can't render 50/60 FPS HD video at the full rate without dropping frames).

Tony

 

[SciDoctor]

Worked well; I used it to restrict 4k rendering in LAV software fallback when forceing deinterlacing (prefer this for lower res formats as it doubles effective rendered frames giving for my monitor a better PQ)

 

[Pat Clark]

FWIW, I've had 2 lockups in the past 2 weeks with 676. Video stalls displaying a frame and MP is unresponsive, but kills OK via task bar. No logs -- sorry.

 

[mhoogenbosch]

Worked well; I used it to restrict 4k rendering in LAV software fallback when forceing deinterlacing (prefer this for lower res formats as it doubles effective rendered frames giving for my monitor a better PQ)

what exactly do you mean by this, i'm always in for better PQ. I don't have a 4k screen, so don't know if this is possible for me.

 

[Owlsroost]

FWIW, I've had 2 lockups in the past 2 weeks with 676. Video stalls displaying a frame and MP is unresponsive, but kills OK via task bar. No logs -- sorry.

As no-one had reported any lock-ups I'd assumed that all was fixed (but I'm not planning on more mods until I get some logs, so I know where to look....)

When did the lock-ups happen - when playing, or at start-of-play/skipping/FFWD/RWND/end-of-play ?

Other than the new FPS limiter, v677 is identical to v676.

Tony

 

[SciDoctor]

Worked well; I used it to restrict 4k rendering in LAV software fallback when forceing deinterlacing (prefer this for lower res formats as it doubles effective rendered frames giving for my monitor a better PQ)

what exactly do you mean by this, i'm always in for better PQ. I don't have a 4k screen, so don't know if this is possible for me.

I don't have a 4k screen, this is just 4k test files for software or gpu rendering tests on a 1920x1200 monitor.

My monitor has one refresh rate of 60fps so using the LAV settings above has the PQ benefit for me by doubling the rendered frames and now using the 677 settings 'cut-off' 4k test files are rendered at 25fps instead of the doubled 50fps ie 100fps that would cripple most hardware.

Just try the LAV settings and see if you like the results if not revert to standard settings.

 

[Deda]

FWIW, I've had 2 lockups in the past 2 weeks with 676. Video stalls displaying a frame and MP is unresponsive, but kills OK via task bar. No logs -- sorry.

As no-one had reported any lock-ups I'd assumed that all was fixed (but I'm not planning on more mods until I get some logs, so I know where to look....)

Other than the new FPS limiter, v677 is identical to v676.

Tony

I can report for 676 that it works ok for now (I'm always on current GIT). Before I used it, I cleaned registry so there is now only default values. I must admit that I made some changes in mediainfowrapper (dunno if dshowhelper or refresh-rate changer depends on it ) because we got some detection problems inside for fps and duration for some videos (VFR type).