Open Grauhaar opened 6 years ago
Not so easily, actually. One reason is that the detected size lags behind the actual encoding percent as there is often a lot of data that still exists in buffers and not yet written to disk. Another is that in quality-targeting encoding situations (which should be most of the time), you don't know how much data each part of the video is going to require. For example the end might be much more complex than the beginning, which would throw off the calculation even more.
Thanks for looking in it. I agree that this is complex and noone knows what datarates coming later. But my intention was to have a very rough estimation of the output file size based on the already processed part. Currently I do this with an calculator by using the two values to check it the size is in the expected range using the specified QTY encoding level.
It's not that it could be off by a little bit, it's that it could be off by a lot. And then I get bug reports about something I cannot possibly fix. And that will vary in unpredictable ways based on the encoder settings and the internal implementation of the encoder, since you don't know how big the encoding buffer will be.
I miss in the Encoding Window an estimate for the current output filesize to control and re-adjust the encoding settings. This can easily be calculated by "Current size / Percent processed" which are both already present in the window.