Open Nutomic opened 6 years ago
During encoding FFMpeg dynamically reports:
frame= 1371 fps= 33 q=28.0 size= 22266kB time=00:00:54.12 bitrate=2815.8kbits/s speed=1.37x
From here there is number of ways to evaluate ETA.
I see the most robust, simple and flexible is:
time
here is a real-time playback timestamp in the video. So it shows us real current encoding position in the video, relatively to the total length of the video.
stream=duration
(would be aka totalTime
):ffprobe -v error -show_entries format=duration -of default=noprint_wrappers=1:nokey=1 <source_file>
We are getting duration of playback reported by container, it (container) solves the case. Mingling with streams would tend to get too complex. There is v:0 stream in 97% cases, but in others, it can be v:1, or there can be any number: v:n (VR, 3-angle camera video). Or if we support podcasts, - they often have no video stream, than we must... Streams often also have time offsets in any direction...
So we just get duration of playback from authoritative source - container, and that is it.
It would return number in seconds: 596.458333
For simplicity let's round it: totalTime = round(596.458333) = 596
During encoding we are gathering that time=...
through the regexp, rounding it, and converting it into seconds.
time = 00*3600 + 00*60 + 54 + (round 0.12) = 54
ETA = round ((totalTime - time)/speed) = round ((596 - 54)/1.37) = round (395.62043795620434) = 396 seconds.
It gives us accurate estimation, while all this works for any types of scenarios.
I propose this time-based variant and not others, because if we would go frame numbers, FPS route - there are plethora of corner cases and variants that need be accounted then, and ETA code over would become a mess.
Container&Time-based variant is universal for all cases.
At best we can only tell the position in the transcoding queue of a video, and the time left to transcode once transcoding.
Your users will still have a very vague notion of when their video will be transcoded…
As pointed out on IRC, we can easily access the progress of an active job through the API provided by fluent-ffmpeg
: http://fluent-ffmpeg.github.io/index.html#setting-event-handlers
Admins can now see transcoding progress percentage in job list: https://github.com/Chocobozzz/PeerTube/commit/3b01f4c0ac764ecb70efaadfd939ca868c28769c
Admins can now see transcoding progress percentage in job list: 3b01f4c
Why not make the percent visible to the uploader? It would them to know on their side the progress of their video.
Why not make the percent visible to the uploader?
Question goes unanswered.
Can we get the percent visible to the uploader? Or even better, an estimated time to completion?
I'm getting a lot of questions by uploaders that want to know the time until an upload of theirs is transcoded. Unfortunately, this is almost impossible to estimate, because there are a lot of factors, like:
Instead, it would be nice if Peertube could display the estimated transcoding time, probably on the upload screen.
It would also make sense to show the total length of the transcoding queue separately, and inform the admin if it is unusually long.