VD2: Windows: Thread (encode) priority not working

[stormy1777]

As subject suggests, I've unzipped the latest VD2/43073, and encode priority does not seem to take effect, all encoding happens in Normal OS priority.. I'd expect that changing the priority on the VD2 interface would take effect at the OS (Win7) level, but it doesn't seem to change anything..

This is a useful feature, as changing from 'slowest' to 'highest' could translate into a pretty big time difference..

Stormy.

[shekh]

How do you know it has no affect? This is difficult to analyze. Maybe it works as fast as it could.
There is related issue: https://sourceforge.net/p/vdfiltermod/tickets/147/
In some cases the performance is less than desired because some parts of code are single-threaded.

[Groucho2004]

This is a useful feature, as changing from 'slowest' to 'highest' could translate into a pretty big time difference.If it does translate into a big time difference then you have too much stuff running concurrently (e.g. AV software).

Using highest priority for such a job basically locks up the OS and makes it useless for any other tasks. If you want to do things while encoding, use low/idle priority. Otherwise, just leave it at normal.

You can set the priority on the command line ("start/low VirtualDub"). In this case, VDub and any threads/processes it instantiates will run with the same priority, unless these threads/processes set their own priority.

[StainlessS]

At a guess, I'de say that stormy is looking at TaskManager to establish if Priority is changed therein (dont know if it does change there).

Stormy, if there is nothing else running on the machine, changing priority will have little/no effect, you cant make hard drive accesses faster than they can go, and if encode is waiting for hard drive, then, it has to wait. (It is usually more useful to set something to low / idle priority, than to high, so as to only use 'spare' time slots, setting something High Priority can sometimes cripple other tasks with little effect on the heightened task).

EDIT: Within about last 18 months, some versions of ffmpeg were getting greedy on CPU, crippled other tasks a bit and so I found it better to set ffmpeg priority lower than it was, made almost no difference to ffmpeg speed and did not cripple other tasks, ffmpeg seems to have been fixed since then, to not be so greedy. See Here:- https://forum.doom9.org/showthread.php?p=1767035#post1767035

[stormy1777]

Without getting into OS/best way to run things, simply saying that looking at Task Manager, the PRIORITY field of the job/encode is not reflected from VD2 interface, so setting to Idle/Highest does not change the OS process, that remains on Normal.

There can be many other things running at the same time (possibly other less/more important encodes or otherwise mp3/encoding/conversions, gimp,no telling really), no way to really control that, and if I set to Highest, that means I'm perfectly fine if the entire system freezes and does just this encode as quickly as possible while i go get a drink or something :)

[StainlessS]

Set unimportant to IDLE, dont set anything to high is possibly best bet.

[stormy1777]

Set

Ok, Set. but where would that be done? in the VD2 GUI or at the OS/task manager level?

If at the OS level... (you see where I'm going with this?) it seems the GUI offers an option that does not work, and yes, unimportant encodes go to idle, and one that is important goes to highest (without crippling too much)... launching with a starting priority is not very efficient, since the clips change and they sort of decide on the priority, some important, others less so.. i may have 5 VD UI's open at any given time, so, best would be if tool passed the priority selection directly to the OS.. btw, I'm pretty sure that worked back in the days in VD-old-old versions :)

[hello_hello]

I don't fully understand this, but I did some reading and played around and from what I can tell, programs can set a "process" priority and a "thread" priority. The former shows as the "base priority" in task manager (at least for XP). The latter isn't shown. The VD option is labelled "process thread priority".

The process priority never budges from normal for VD. Best as I can tell, Windows also adjusts thread priorities based around the process priority, and adjusts them both based on workload.
The value for the "normal" process priority is 8. MeGUI sets the x264 process priority.

There's a table here (https://docs.microsoft.com/en-us/windows/desktop/procthread/scheduling-priorities) which is either badly laid out or doesn't render properly in my browser, and not all of VD's thread priority options are listed in the table, but it still explains how it works. It shows that within the "normal" process priority, an "idle" thread priority has a value of 1 as it's base priority. For the "lowest" thread priority it's 6, and near the other end of the scale, the "highest" thread priority is 10, but that's for the normal process priority. For other process priorities, the thread priority values are different.

Check the first Process Explorer screenshot below. Down the bottom of the main window (which is mostly hidden) you'll see MeGUI has set the process priority for x264 to low, which is shown as "4" on the far right. For VD, the process priority is always normal (8).

If you look at the threads in the properties windows, you'll see MeGUI's x264 threads on the left and the VD threads on the right. There's a base thread priority and a dynamic thread priority according to what Windows decides. I think the msvcrt.dll base thread priorities on the left were usually lower than the x264 base process priority, so I guess that's what Windows is doing.

On the right is a selected VD thread. Priority was set to "lowest" in VD's status window, which corresponds to a base thread priority of 6 in the table I linked to (normal process priority). The VD setting only seems to have an effect on the VD instances using CPU time. For every other thread in the list, it seemed like Windows was in control.

The second screenshot shows the thread priority set to "highest" by VD, which corresponds to 10 in the table I linked to (normal process priority).

I've no idea how effective setting a thread priority is vs a process priority, and in fact I really don't understand much about how it all works, but VD is obviously setting the thread priority rather than a process priority, and when using the File/Save menu (I haven't checked the external encoder method) it at least appears to be working. If you want to adjust the process priority (and therefore the thread priorities would change accordingly), you probably have to do that yourself via task manager.

Oh... and I did notice that when MeGUI set a process priority for x264 other than normal, the change wasn't immediately shown by either task manager or process explorer. Sometimes it took a few minutes. Possibly that's a Windows decision based on workload.

Hopefully I explained the little I understand well enough....

https://i.postimg.cc/DWMghK6Z/pe1.gif (https://postimg.cc/DWMghK6Z)

https://i.postimg.cc/Y493TS1Z/pe2.gif (https://postimg.cc/Y493TS1Z)

[shekh]

Small addition: in vd setting ("process priority" = "processing thread priority") the word "process" refers to "the conversion", not win32 object "process".

[hello_hello]

I forgot VD had a process priority setting in Preferences. So what you're saying, and going by how it seems to work, the "process priority" setting in Preferences just sets the default "process thread priority" you see in the Status window. Is that correct?

[shekh]

correct

[stormy1777]

Ah, OK, now that explains it :) :) hello=Hello nice research/work!

In preferences I had it on Highest since a long time, however, looking at the OS process, it is normal, and the THREADS inside, most of the ones doing the WORK are all set to LOWEST??!@$%^&? :) :)

Notice only one or two not so cpu intensive threads are at the selected priority.

My 'workaround' has been to go to process explorer, change the PROCESS priority, then get results quicker, at least, so i think :)

See attached screenshot of an encoding session, notice the cycles, and to which threads they are counted against, during all this time , in VD2 the "priority" is set to highest...

So yeah, changing the "VD2 priority" is not showing much differences, b/c it is only changing the THREAD, and not the key thread so it seems ? :)

BTW: Not complaining at all, this is great conversation/discoveries!

Stormy.

[shekh]

Yes if you encode x264 for example it will create its own threads not controlled by these priority options. Same for decoders.

[stormy1777]

I'm now using all VD encoders, not external...

So... maybe change that to real PROCESS priority :) b/c as it stands this option really doesn't do much :) If u do change; it might be good to exclude "real-time" to prevent users from hurting themselves too much :) :)

[shekh]

This is very unfortunate option. I don't find it interesting to switch process priorities, and properly propagating per-thread priorities is next to impossible. And the usefulness is questionable.
Don't want to remove it completely either, somebody would complain :)

[stormy1777]

Agree, thread priorities is pointless, it can even hurt with inter-process "race"/starvation.

To claim that process priorities are not beneficial, well, not sure I can agree on that one. That (greatly) depends on work-habits, practices.. in a perfect world (with a single well-trained human or AI), one would queue the jobs in just the right order to job control, release them in right time, and nothing else would run on the server :)

However, that is not reality :) i find it often enough that changing the process priorities can make a BIG difference, just try to run 2-4 encodes (and again, lets put job control to the side, b/c that encode could just as well be something else, Blender, or other program) let the system become CPU bound, then set one to HIGH, and other 3 to LOW, and see the difference... Sure, I/O will always block/slow, but these days someone may be running all on SSD/flash/memory, not that it would be ME :) :) really :) and even without I/O, if system is really CPU bound, then process priorities will definitely come into play, so long as user is aware of what 'real-time' is, if u ever do implement this, realtime should not be allowed from the UI :)

anyways, we can call it a day on this thread :)

Stormy.

[hello_hello]

Sure, I/O will always block/slow, but these days someone may be running all on SSD/flash/memory, not that it would be ME

Setting I/O priority is a thing too these day. ;)
I think it only applies to Win7 or newer.

https://i.postimg.cc/LhxR4D4W/Me-GUI-workers.gif (https://postimg.cc/LhxR4D4W)

[stormy1777]

right.... VD2 has "background I/O", seems to sloooow down I/O :)

[hello_hello]

I'm not sure it's the same thing for VD2. Unless I haven't found the correct option.....

[shekh]

Same, the option is not visible in XP.
It controls the flag PROCESS_MODE_BACKGROUND_BEGIN if anyone wants to find out what is it.

[stormy1777]

Thanks!! yeah, definitely it slows things down as designed :)


PROCESS_MODE_BACKGROUND_BEGIN
0x00100000

Begin background processing mode. The system lowers the resource scheduling priorities of the process (and its threads) so that it can perform background work without significantly affecting activity in the foreground.

This value can be specified only if hProcess is a handle to the current process. The function fails if the process is already in background processing mode.

Windows Server 2003 and Windows XP: This value is not supported.

[stormy1777]

Don't mean to wake up an old thread:

Just for sake of completeness, the other day had 4 jobs running (among many other things), yeah, i know it could be sequential jobs, but these are crafted/run from different VD GUI windows, so each has a separate job-queue, anyways, this:

https://i.imgur.com/SWwc02K.jpg

shows them with normal OS priority, then this shows one process modified to run with Higher priority:

https://i.imgur.com/b6QFh3k.jpg

As you can imagine, it *greatly* sped up that encode compared to the others, shown by estimated total elapsed, and FPS going almost 10 times faster than before..

In a perfect world, we'd all have plenty of time, however often, we end up running things in parallel, at least I have to, since need to move on to next file/thing/task :)

Stormy