After some (e.g. 5) percent of the source file have been transcoded calculate and show the estimated filesize of the target file.
This would help users to see whether the current transcoding options will meet their expectation wrt. resulting filesize.
Especially high quality options together with filter options (like denoising) might result in a very long transcoding time and unexpected/unwanted filesizes.
Of course the early estimates could be rather inaccurate but with increasing transcoding time I would expect it to be quite accurate, just like the estimated remaining time.
Unless you constrain handbrake to a specific bit rate, the rate needed to encode sections of the source varies with the complexity of the source. It still does with a constrained bit rate, but the encoder will sacrifice quality to maintain the bit rate.
You can see this by using the same preset to encode a typical anime and an action film. If the action is at the end of the film, the early estimates could be wildly inaccurate.
If that weren't enough, most movies contain more action at the end rather than the beginning, so average bitrates based on the first 20% will fall short for lack of an adequate sample.
If the values are too inaccurate to show them then remaining transcoding time and average pps should be removed from HB's output since all of the arguments above against estimated filesize apply to these two values as well.
I think the general consensus is that although the current estimates can be inaccurate most people don’t rely on them that much, whereas putting a file size estimate would generate more complaints/support requests as more people would rely on it.
One thing I have seen in another program is displaying the current bitrate, this allows the user to get a rough estimate of size while always being accurate.
Using this trick you can also display 'çurrent filesize' since it would only take into account the already transcoded part of the video which will definitely be part of the final video.
The user then could do his own calculations to get an educated guess for the final transcoding result.
I am using Windows and the target file shows 0 bytes until the end of the transcoding process.
I have not searched for the intermediate file so far which obviously must exist since I don't think that HB keeps everything in memory until the very end.
Thanks
I would have never expected that this is a stupid issue with updating the file's info on Windows.
This is not as easy as an estimated filesize shown by HB but better than no information at all.
Handbrake CRF does not make a scan pass.
Bitrate varies throughout the encode, as much as 10,000%.
Taking a bitrate snapshot says nothing!
Everything else is wishful thinking, unless one believes in time travel or uses ABR.
I'll be glad to post the equation again if you decide to go that route.
musicvid wrote: ↑Fri Jan 01, 2021 8:43 pm
Handbrake CRF does not make a scan pass.
Bitrate varies throughout the encode, as much as 10,000%.
Taking a bitrate snapshot says nothing!
Everything else is wishful thinking, unless one believes in time travel or uses ABR.
I'll be glad to post the equation again if you decide to go that route.
If you look at my tests you would see this isn’t true for commercial blu rays, while I am happy to concede there are exceptions as far as estimating size you can do it.
Obviously one could generate a file to illustrate your point that file would probably also cause the FPS and estimated time to be wonky too.
If you do know of any commercial movies that you think cannot be estimated in this way please let me know their name.
tromsoe wrote: ↑Fri Jan 01, 2021 5:00 pm
If the values are too inaccurate to show them then remaining transcoding time and average pps should be removed from HB's output since all of the arguments above against estimated filesize apply to these two values as well.
Encoding time/speed doesn't vary nearly as much as bitrate does based on the content.
This thread has outlived it's usefulness. locking.
The formal stance on this is Target file size or derivative features such as file size estimation are not coming back to HandBrake due to accuracy issues.
