Improve time estimate accuracy #170

fabiospampinato posted onGitHub

Moving issue from #111 as requested.

The remaining time estimate is a bit off. Looking at the progress circle it looks like the remaining time should be pretty predictable as it seems like each percentage point takes roughly a constant amount of time to process. I think perhaps the time estimate should be recalculated after each percentage point with the following formula: ( ( 100 / number_of_percentage_points_so_far ) - 1 ) * time_elapsed_so_far.

I've timed it and converting a video took ~40s for me over a ~60s estimate, nothing particularly off but for me the countdown seems to be counting down a little faster than it should.

I've just tried converting a video with Gifski and at the point where the app said there were 40s left, after about ~60% of the video had been processed already, I started a stopwatch and when the app finished the stopwatch was at ~32s.

// @allewun In case you have time and interest in looking into this. No worries if not though.

posted by sindresorhus about 5 years ago

Seems to be the same formula?

Old: (timeElapsed / percentComplete) * (1 - percentComplete)
New: ((100 / percentagePointsComplete) - 1) * timeElapsed

    timeElapsed => t
    percentComplete => p
    percentagePointsComplete => p*100

Old: (t/p) * (1-p)
  = t/p - t
New: ((100/(100*p)) - 1) * t
  = t/p - t

posted by allewun about 5 years ago

New: ((100/(100*p)) - 1) * t

There's an extra 100 there, I think it should instead be:

New: ((100/p) - 1) * t
  = 100t/p - t

But I'm not sure in both expressions p is the same number, like in mine I'm expecting it to be a number in the 0~~100 range, while in the old formula it's probably a number in the 0~~1 range or it wouldn't make a lot of sense, and I think this makes the two expressions effectively equivalent.

Given how the expressions are equivalent, and they seem rational, maybe the problem is somewhere else.

I don't have many ideas on how to tackle this, mainly because I'm not sure how the video -> gif conversion actually works, but maybe the issue is that different portions of the video get converted at different rates, and/or that the computer stars converting slower/faster at some point (maybe another CPU-heavy process gets spawned, maybe it hits thermal throttling or whatever), to which a possible improvement could be to extrapolate a conversion speed from the last 30s or so rather than looking back at the entire history.

posted by fabiospampinato about 5 years ago

Fund this Issue

$0.00

Funded

Only logged in users can fund an issue

Pull requests

Do you want to work on this issue?

Improve time estimate accuracy #170

Company

Community

Support

Connect