Rendering time estimates (ETA) should be smarter
@jeff
Submitted by Jeff F.T. Assigned to Jeff F.T. @jeff
Description
Created attachment 177588
graph and gnumeric spreadsheet of the measured times estimates
As long as the time estimate is over 1 or 2 minutes, we shouldn't show seconds, because they fluctuate too much and it's a bit silly.
Furthermore, in some scenarios, time estimates can get very wrong when the beginning of the timeline is something "easy" to render followed by "complex" contents to encode (ex: encoding 720p to VP8 in 720x405).
I have a project (texture) where the ETA starts at a few minutes then keeps going up slowly until it reaches an hour or so; and since it goes up only a few seconds at a time (because it has to move the average?), it takes at least 4 minutes until you start having a somewhat meaningful estimate.
Notes:
- the "beautify_length" method in utils.py is used for both rendering ETAs and in other places such as the sources list/media library... so I guess this would require a separate method, or maybe an optional parameter that toggles seconds on/off for ETAs
- the method for getting ETAs is "_positionCb" in actioner.py. The algorithm is this: totaltime = (timediff * float(length) / float(position)) - timediff
Which translates to:
ETA = (elapsed_time * timeline_length / position) - elapsed_time
But this algorithm seems to fail in the case described above (see attachment).
Imported from https://bugzilla.gnome.org/show_bug.cgi?id=638754