Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Improve time estimate accuracy #170

Open
fabiospampinato opened this issue Jan 16, 2020 · 3 comments
Open

Improve time estimate accuracy #170

fabiospampinato opened this issue Jan 16, 2020 · 3 comments
Labels
bug Something isn't working help wanted Extra attention is needed

Comments

@fabiospampinato
Copy link

fabiospampinato commented Jan 16, 2020

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.

@sindresorhus sindresorhus added bug Something isn't working help wanted Extra attention is needed labels Jan 16, 2020
@sindresorhus
Copy link
Owner

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

@allewun
Copy link
Contributor

allewun commented Jan 26, 2020

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

@fabiospampinato
Copy link
Author

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 0100 range, while in the old formula it's probably a number in the 01 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.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
bug Something isn't working help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants