sigstop and x264

[Chengbin]

I remember reading a thread where x264 was sigstopped, and the fps number kept dropping. The response was x264 cannot detect a sigstop.

If my understanding is correct, sigstop stops a process, and you can resume it later. If you have a sigstop applied on x264, why is the fps moving?

[LoRd_MuldeR]

Because FPS is defined as follows:
FPS = frames_encoded / time_elapsed

If you suspend the x264 process, it will stop encoding frames for obvious reasons. But this won't stop the universe. Time will move on ;)

So if you resume the x264 process later, a lot of time has elapsed in which not one single frame was encoded. Consequently the FPS value will drop!

The only easy way to "fix" this would be calculating FPS over an interval (e.g. the last minute) instead over the whole encoding process.

But that would change the meaning of FPS! At the moment FPS is the average FPS throughout the whole encoding process.

[Chengbin]

So even with a sigstop, the process can get the CPU power to calculate fps?

[LoRd_MuldeR]

So even with a sigstop, the process can get the CPU power to calculate fps?

No. A suspended process will do nothing at all! However time (in the real world) still moves one, whether your process sleeps or not :D

So at the first FPS update right after you resumed the process, the FPS value will have dropped significantly...

[kemuri-_9]

the underlying principle of why the fps drops on resuming is the following:
x264 takes the clock time of when the processing started,
and then takes the current clock time to generate a difference and then uses it in combination with the number of encoded frames to give you an average fps rate.

the starting clock time won't change, so the difference from the starting lock time to the current continues to increase as time flows, whether x264 is allowed to process or not.

[ACoolie]

There's a patch written a while back (by Loren?) that should fix this: http://akuvian.org/src/x264/pause.diff
It probably needs some updating though.