ETA calculation: do not count time spent in user-paused state

[HuBandiT]

When calculating the ETA of an encoding job, do not consider the time while the job was paused as part of the job's running time.

Currently, when I pause a job, and then restart it later - often hours or days later, as I often run multiple experiments and quality checks -, the ETA calculation extrapolates from the wall-clock time elapsed since the job start.

I would like to have the option to have this calculation only count the running time.

Thank you in advance.

[lordmulder]

Hello.

Simple-x264-Launcher is a GUI front-end. It displays the output of the underlying encoder program. So, the "ETA" computation happens inside of the encoder program, e.g. x264.exe or x265.exe.

Therefore, I can not do much on my side. I'm pretty sure that x264 simply reads the system timer once when the encoding process starts, and then periodically checks the system timer again to see how much time has elapsed since then. As the system timer advances even when the process is suspended, this will confuse the "ETA" computation. Same when you run x264 in the terminal and put your computer to "hibernation".

You would have to file a feature request to x264 developers. But I don't think there is a straight-forward solution to implement this. That's because, on a modern multi-tasking operating system, it is perfectly normal that a process does not exclusively "own" the CPU. Instead an individual process will be suspended and resumed all the time – possibly several times per second – even while that process is running "normally". This is done in order to "interleave" all the various processes running on the system. Consequently, between two instants at which x264 reads the system timer, the x264 process will have been suspended and resumed many times – always. How do you detect that a "longer than normal" suspension has happended?

Regards, MuldeR

[HuBandiT]

the "ETA" computation happens inside of the encoder program, e.g. x264.exe or x265.exe.

Ahh, I see; sorry, I did not know that. Apologies for taking your time.

One possible way would be to parse the output and make sense of it, and then post-process it - essentially, recompute our own version of it - and then display that. But that is prone to breaking if the format of the received output changes.

Feel free to close, unless you feel it would be worth trying this.

[lordmulder]

I currently don't like the idea to move/duplicate the "ETA" computation into the GUI.

Think a better solution would be to change the way how x264/x265 computes the ETA. Instead of computing the FPS as "total frames completed so far / total time elapsed so far" it would be better to use something like "number of frames completed in the last interval / length of interval", for some reasonable time interval. That combined with a "rolling average" window in order to avoid too much fluctuation of the FPS.

[HuBandiT]

Yeah, I cannot argue with that.

Do you have experience with x264/x265 developers? Would they potentially be responsive to such a suggestion?

[lordmulder]

Not sure. Probably you would at least need to provide a ready-to-use patch.

It's not rocket science, but not a "one-liner" either.

But development of x264 has slowed down a lot recently. Mostly "maintenance", no new features.

[HuBandiT]

Thank you; I'll weigh my options.