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.
Forced display cycle to the 20ms solves the stuttering issue on 1:2 material. I would say the estimation needs wither to be as exact as the result we get from Windows 7 or it cannot be used in MP.
Do you have any clue why the stat lines are quite jumpy with your version on 1:2 material? Playback itself is ok since the presentation time will fit into the window where the v-sync is not yet done.
Overall with the forced display cycle duration I get the same playback quality as with SVN / RC2 dshowhelper.dll. (of course testing would require much more time than I have currently at my disposal).