#768 Process Priority isn't set correctly for x264 encodes



recently changing the processing priority from the status dialog has been inconsistent (on Win7x64). The job is stated with the correct priority (as defined in settings, in my case 'Low'), but changing it doesn't have the expected effect. When switching it to 'Below Normal' (and checking with Process Explorer) the avs4x264mod.exe process is correctly changed to this ("Below normal: 6"), but the child process x264_64.exe which is actually doing the work is only changed to "Backgroud: 4 (Low I/O and memory priority)".
I couldn't figure out a pattern when x264_64.exe is changed to "Idle" and when to "Background" (or if that even makes a difference), but it doesn't seem to correlate with whatever you've set in the status window (and therefore what avs4x264mod.exe is set to) and for me it's never changed to anything else than those two.

(I'm on development update server, version is 2500, added a small log I had from a few days ago for system information)


1 Attachments


  • Zathor

    Zathor - 2014-06-14
    • status: open --> pending
  • Zathor

    Zathor - 2014-06-14

    This part surely hasen't changed in years. My understunding of this part of the program is that only for the direct processes started by MeGUI the priority set. It is then the job of the child processes to set the priority for their child processes.

    For me this is not a bug but a missing feature that also for child-child-processes the priority will be set.

  • Sebastian Fischer

    An alternative way would be to slightly patch avs4x264mod so that it 'forwards' any priority set to it. Which approach makes more sense basically depends on how often there are intermediate (wrapper-) processes in MeGUI. If this is the only case, or at least the only one that will usually run for a rather long time, it might be simpler to just have avs4x264mod check for a priority change to itself every X frames (or every Y seconds) and set the child process priority accordingly. This would probably have to be done in the main loop at lines 1084+ (from the code on github), but weather such a patch would be accepted/integrated (or even how expensive such a priority check is), I have no idea...


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks