Am 30.12.2017 um 23:06 schrieb dick balaska:
> This is more of a general Linux issue I guess.
> I run povray at nice -19. It doesn't behave as expected. That is, it
> doesn't really yield to other processes.
> When I run povray at low priority on Windows, he basically stops for
> anything else. Like here, povray should be stopped, and ffmpeg given
> 800% of CPU.

Technically, no, that's not what should happen.

What should happen is that ffmpeg should be given (virtially) as much
CPU time _as it can use_. Which may be significantly less than 800% if...

- it spends a lot of time waiting for file I/O to complete (which I
guess may be quite significant when creating a movie);

- it spends a lot of time synchronizing its threads.

- it uses a limited number of threads as there are (virtual) cores;

- it lets the GPU do most of the work, rather than the CPU;

CPU power ffmpeg makes no use of for any of the above reasons is free
for the taking.

(Also, with a niceness of 19 rather than the maximum of 20, the
scheduler would still give POV-Ray a bit of CPU time even if ffmpeg
would be able to use it all up.)

>   PID USER      PR  NI    VIRT   SHR S  %CPU %MEM     TIME+ COMMAND
>  8976 dick      39  19 1301940  4512 S 539.4  2.6  32:43.18 povray
> 11804 dick      20   0 3873964 31452 S 194.4  1.1   5:25.79 ffmpeg
> 
> This can't be just the way things are?

Judging from the numbers, my guess would be that ffmpeg only uses 2
worker threads (giving it a theoretical maximum of 200%), each of which
occasionally blocks due to file I/O or synchronization (dropping the
actual value to 194%).

The internerds make various contradicting claims about the number of
threads used by ffmpeg, some of which coincide with the value you get.
(See
https://superuser.com/questions/155305/how-many-threads-does-ffmpeg-use-by-default)

The internerds also claim that using ffmpeg's `-threads N` option should
help.

Post a reply to this message