A guide to stutter free playback with Reclock (1 Viewer)

[tourettes]

On a quick test 1:2 material gets really bad playback quality on some occassions (stat lines are looking in general quite worrying for 1:2).

1:1 material was playing as good as the SVN. Measured display cycle was varying between 19.977 - 20.025ms, which is a bit too much and could cause some issues (maybe for Win 7 it should be always relied on the OS reporting).

 

[emphatic]

This is a very nice idea, Owlsroost. So, is this .dll compatible fully with MePo RC2, and to be fully clear, I won't need to use ReClock as renderer with it?

Emph

 

[Owlsroost]

On a quick test 1:2 material gets really bad playback quality on some occassions (stat lines are looking in general quite worrying for 1:2).

1:1 material was playing as good as the SVN. Measured display cycle was varying between 19.977 - 20.025ms, which is a bit too much and could cause some issues (maybe for Win 7 it should be always relied on the OS reporting).

The screen grab isn't showing 'my' render stats - can you attach one using my version of the dll please ?

Tony

 

[mrmojo666]

Hello guys,
i've done more tests with this directshow dll

i'm totally excited about the results i'm sure this is THE WAY

however.....

avi (ffdshow decoder a/v) 25fps su 50 hz ---> no stutter all goes perfect
mkv (cyber10) 720 24p at 24 hz with sub -------> no stutter all goes perfect
mkv (cyber10)1080 25p at 50hz ----> no stutter all goes perfect
tv (cyber10)1080 50i at 50 hz----> no stutter all goes perfect
tv (cyber10) sd at 50 hz----> no stutter all goes perfect


these results are with OSD closed.......... these are just qualitative results (never seen MP going so smooth: i don't see any differences from my settopbox), unfortunatly i can't get any quantitative results because:

with the OSD opened the results are totally different

avi (ffdshow decoder a/v) 25fps su 50 hz ---> bad stutter, red ,green and yellow lines go mad and i can't reach more then 18 FPS
mkv (cyber10) 720 24p at 24 hz with sub -------> bad stutter, red ,green and yellow lines go mad and i can't reach more then 18 FPS
mkv (cyber10)1080 25p at 50hz ----> quite bad stutter, red ,green and yellow lines go mad and i can't reach more then 23/24 FPS
tv (cyber10)1080 50i at 50 hz----> almost perfect some framedrops no stuttering , red ,green and yellow lines sometimes display spikes
tv (cyber10) sd at 50 hz----> almost perfect some framedrops no stuttering , red ,green and yellow lines sometimes display spikes

i confirm my OSD is showing more values than usual and doesn't display vertical white lines so i think i'm using your directshow

Is OSD bugged ?
I want add that i'm using desktop at 50Hz, automatic refresh changer is ON and MP GUI is set at 50 fps

Thank you for the great work, my HTPC is really AWESOME now Actually i think to use this RC2 + your directshow in the production installation of win7

bye

 

[tourettes]

On a quick test 1:2 material gets really bad playback quality on some occassions (stat lines are looking in general quite worrying for 1:2).

1:1 material was playing as good as the SVN. Measured display cycle was varying between 19.977 - 20.025ms, which is a bit too much and could cause some issues (maybe for Win 7 it should be always relied on the OS reporting).

The screen grab isn't showing 'my' render stats - can you attach one using my version of the dll please ?

Tony

Sure, my mistake... that was some old screen shot with the SVN DLL. Please find the correct screen shot attached. When that screenshot was taken the video did stutter approx once or twice per second (stuttering is most easy to see when tearing test bar is enabled ).

Also the estimated refresh cycle is WAY OFF in that. 23.931ms vs the real 20 ms. That measuring code (taken from MPC-HC / ar-jar's renderer ) is not accurate at all (ar-jar is not using it by himself anymore ).

btw. please add some log message to the new DLL so we can distinguish it easialy so that people aren't reporting bugs with it

 

[tourettes]

Is OSD bugged ?
I want add that i'm using desktop at 50Hz, automatic refresh changer is ON and MP GUI is set at 50 fps

No, OSD is not bugged but instead it just generates extra work for CPU/GPU and it throws the EVR presenter timing off. Does the same happen with RC2 DLL?

Thank you for the great work, my HTPC is really AWESOME now Actually i think to use this RC2 + your directshow in the production installation of win7

Please remember that you shouldn't report any issues with a patched MP.

 

[Owlsroost]

Sure, my mistake... that was some old screen shot with the SVN DLL. Please find the correct screen shot attached. When that screenshot was taken the video did stutter approx once or twice per second (stuttering is most easy to see when tearing test bar is enabled ).

Also the estimated refresh cycle is WAY OFF in that. 23.931ms vs the real 20 ms. That measuring code (taken from MPC-HC / ar-jar's renderer ) is not accurate at all (ar-jar is not using it by himself anymore ).

btw. please add some log message to the new DLL so we can distinguish it easialy so that people aren't reporting bugs with it

The measurement code is still used in the MPC-HC EVR-sync renderer (take a look at 'EstimateRefreshTimings()' in SyncRenderer.cpp) except that it takes 50 frames to get a better average - I didn't think people would want to wait 2 seconds (at 24Hz) before playing starts....on my system 5 frames is enough to get good result.

The way-off refresh rate estimate is the reason it's not trying to do vsync correction - it doesn't think it can. The 'FrRat:' value indicates the state of it's display <-> video FPS ratio detection, so 2 => 2:1 ratio, 1 => 1:1 and 0 => out-of-range (which disables vsync correction).

I'll a add suitable message to the log and on the render stats screen so my version is easily identifiable

Tony

 

[tourettes]

The measurement code is still used in the MPC-HC EVR-sync renderer (take a look at 'EstimateRefreshTimings()' in SyncRenderer.cpp) except that it takes 50 frames to get a better average - I didn't think people would want to wait 2 seconds (at 24Hz) before playing starts....on my system 5 frames is enough to get good result.

Oh, didn't know that ar-jar still uses it. But in any case it is just too inaccurate to be usable for MP. I'll do some test with 1:2 material an dthe display refresh cycle coming from OS itself.

 

[mrmojo666]

Is OSD bugged ?
I want add that i'm using desktop at 50Hz, automatic refresh changer is ON and MP GUI is set at 50 fps

No, OSD is not bugged but instead it just generates extra work for CPU/GPU and it throws the EVR presenter timing off. Does the same happen with RC2 DLL?

absolutly not........ with th rc2 dll just if i put gui fps at 100 i get almost good results sometimes bad stutters, same with or without OSD or almost stutter free putting fixed 60hz for all and gui at 60 with or without OSD. with correct settings is unusable with or without OSD.

Thank you for the great work, my HTPC is really AWESOME now Actually i think to use this RC2 + your directshow in the production installation of win7

Please remember that you shouldn't report any issues with a patched MP.

dont worrie, about that i have many OS&MP installations......... i have onother one with RC2 clean

Thank you to all

 

[tourettes]

One issue that Scythe noticed in MP1 EVR presenter code is that the sample queue is not tried to fill, unless it is almost empty. This could cause some dropped frames on busy, lower end systems. Worth to check / change for the next DLL that is build for testing:

In ReturnSample()

if (tryNotify && m_iFreeSamples == 1 && m_bInputAvailable)

Should be:

if (tryNotify && m_iFreeSamples < NUM_SURFACES && m_bInputAvailable)