You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
Moving issue from #111 as requested.
The text was updated successfully, but these errors were encountered: