Strange behavior with VDM 1.5.10.1 while merging

[Manao]

I have a VDM running an encoding with dev-api-4 to an avi, at priority 'lowest'. I also have an avi ( dev-api-4 ), an ac3, both are on an external drive ( interfaced with firewire ). I want to mux them into a mkv file. I launch a second VDM, load the two files, click on save as mkv. But then, the speed achieved while muxing is strongly and weirdly dependant of the process priority used for the muxing thread :idle ---> 0.0 fps ( ok )
lowest ---> 350 - 700 fps ( ok )
even lower & lower ---> 0 - 60 fps ( ??? )
normal ---> 1500 fps ( ok )
higher ---> 0 - 60 fps ( ??? )So whose fault is it ? VDM ? The external drive ?

[ermannob]

I'm having problems too. I was compressing a movie to ogm using XviD 1.0b and muxing a vorbis track.
I changed thread priority from "even lower" to "normal", but now, no matter what priority I choose, video rendering rate goes from 0 (mainly) to 2 fps. CPU usage is still at 100%.
Before the rendering rate was between 6 and 10 fps.

If I restart the encode job, it works fine again.

I use WinXP SP1.

[ermannob]

No more problems with XviD 1.0 beta 2.

[Manao]

Not for me. I encountered the same behavior while demuxing mp3 track with one VDM, and encoding ( in XviD beta 2 ) with another. If I put the priority of the encoding on idle, everything works fine, but if I raise it to lowest, the other VDM behaves as explained previously.

Edit : I posted on the tracker on Sourceforge. I just saw the sticky :rolleyes:

[Tom|420]

I am a programmer. Eventhough I don't play that often with thread priorities, I will attempt to answer with the best of my knowledge, but keep in mind I might be wrong.

Here is the list of priority levels allowed by windows (confirmed from documentation):

0 idle
1 lowest
2 lower
3 normal
4 higher
5 highest
6 real-time

0 = the thread will only run if no other thread on the system is requesting attention
3 = the default priority level when a thread is launched, allowing equal CPU attention for all threads (if other thread are not set to a different level after they are launched)
6 = the thread will request all CPU attention and won't allow any other thread to run on the system (this should only be used by device drivers and the like, and my guess is that VD doesn't allow this and it is not an available option)

Now let's take a look at VD list of priority levels (in parentheses my guess to what windows priority levels those correspond):

Idle (0)
Lowest (1)
Even Lower (???)
Lower (2)
Normal (3)
Higher (4)
Even Higher (???)
Highest (5)

Based on my knowledge and the sources I could check, 'Even Lower' and 'Even Higher' do not exist. What they actually do is a total black spot, but my guess is that the programming language (or tool) used to write the software might offer these options as a kind of compatibility or conformance to levels offered on other systems and their actual values might be set to the wrong levels (eventhough the programmer might expect them to be set to a close one i.e. Even Lower corresponding to either Lower or Lowest where it seems to corresponds to something else).

Now there is something to understand about thread priorities: they are not supposed to be used this way. They are designed to be used so that intensive processes (such as compressing a video) should be set to a lower priority so to let other processes run more or less normally, and processes which spend more time waiting for other processes (network connection waiting for data) can be set to a higher priority class so that it can catch faster once the data or event arrives. In any case, setting the thread to a higher priority won't give it access to more CPU time, it will only take more time on other processes. If you want the thread to get more CPU time, than stopping other threads (closing applications) is a better choice. The fact that VirtualDub gives this option of adjusting thread priority is something I always found weird, but well it happens at time that I use it to lower the priority and thus allowing me to do other things, but never to higher it, and certainly not to encode another movie in parallele.

Hope this has been of help to anyone else

Tom :)