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

tourettes

Retired Team Member
  • Premium Supporter
  • January 7, 2005
    17,301
    4,800
    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).
     

    Owlsroost

    Retired Team Member
  • Premium Supporter
  • October 28, 2008
    5,540
    5,038
    Cambridge
    Home Country
    United Kingdom United Kingdom
    Mhhh. Sometimes I got stuttering yet.

    Owl. Hold on :D

    From the render stats it looks like you are using ReClock to play 24fps material at 25/50fps (I do this too), so I think the problem is that the frame rate ratio detection is deciding to turn off the vsync correction sometimes.

    In the next version I'll widen the detection limits (it's currently within 2%, I'll take it to maybe 4%) to see if that helps. I don't want to enable it always because it will probably make frame drops/stuttering worse when the refresh rates don't match.

    mrmojo666 - it uses extra CPU & rendering time to calculate and draw the stats on screen, so this might cause problems if the CPU is already heavily loaded. When the render stats are not displayed I also disable some of the internal stats calculations as well.


    Tony

    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).

    The jumpy yellow line (which is basically the raster position when PresentImage(...) returns) is because it's hovering around the end/beginning of the raster - the 'SOP line:' number is the scanline when 'painting' starts after the vsync correction delay, 'EOP line:' is the scanline when it finishes - when PresentImage() returns.

    Tony
     

    tourettes

    Retired Team Member
  • Premium Supporter
  • January 7, 2005
    17,301
    4,800
    mrmojo666 - it uses extra CPU & rendering time to calculate and draw the stats on screen, so this might cause problems if the CPU is already heavily loaded. When the render stats are not displayed I also disable some of the internal stats calculations as well.

    If it were high CPU usage, it should have that stuttering / bad timing during the whole file, not just some parts. Stats collecting itself is not CPU hungry (modern CPUs can handle such load with ease) but the stats drawing code itself is GPU hungry, it takes many ms to draw those (at least on lower end GPUs).

    In any case, I would assume that it is more an issue with the algorithm than the CPU/GPU usage.

    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).

    The jumpy yellow line (which is basically the raster position when PresentImage(...) returns) is because it's hovering around the end/beginning of the raster - the 'SOP line:' number is the scanline when 'painting' starts after the vsync correction delay, 'EOP line:' is the scanline when it finishes - when PresentImage() returns.[/QUOTE]

    Ok, so mainly that is caused by the inaccurate "entry" to the ::paint() or in other words the inaccurate scheduling (scheduling is not v-sync accurate, only frame accurate and with 1:2 material it is not even that accurate :)). So safe to ignore with your algorithm? (it isn't with the SVN / RC2, thats why I'm wondering).
     

    tourettes

    Retired Team Member
  • Premium Supporter
  • January 7, 2005
    17,301
    4,800
    Owlsroost, any good ideas how to replace the display cycle detection code with something working? :) That current way is much too inaccurate (and cannot be used in at any MP release as such). After all, over a 10% deviation is simply just too much (23.xxx ms vs. 20.000ms). Error should be less than 0.5% to be acceptable. For Windows 7 we already have OS based API to tell, but XP and Vista users are left in cold. Maybe James could tell how ReClock does it (it has a setting for DirectX / DirectDraw, but I'm not sure what API calls it is using... and too lazy to try to spy those with anything :))
     

    mrmojo666

    MP Donator
  • Premium Supporter
  • January 24, 2006
    603
    182
    Turin
    Home Country
    Italy Italy
    e. For Windows 7 we already have OS based API to tell, but XP and Vista users are left in cold.

    that doesn't seem a sin to me..... xp in not yet sold and vista too....all new HW is sold with win7, why still supporting xp ? I know many user that are happy with the 1.0.2 version and Xp. Go ahead and make MP ok just on the ACTUAL windows 7. :)

    ;)

    byeeeeeeeeeee
     

    Users who are viewing this thread

    Top Bottom