Skip to content
New issue

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

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

Already on GitHub? Sign in 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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