[Rejected] File size estimate

Archive of historical feature requests.
Please use the GitHub link above to report issues.
Forum rules
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.

*******************************
Locked
tmcdanel
Posts: 11
Joined: Tue Nov 25, 2008 12:18 am

[Rejected] File size estimate

Post by tmcdanel »

I am usually working where there is no Internet access, as every summer, and i miss the file size tools left behind in v .94 And often staying under particular file size is an issue. Old dead whiny thread here:
viewtopic.php?f=5&t=26986
I tried downloading the Open Office thing but i couldn't keep the app on my computer.

So here's a suggestion:

On the bottom, where it has current encoding information (Pass #, % done, current FPS, avg. FPS, ETA).
I suggest adding Estimated Size (or Est. Sz) that projects the expected approximate size of the file being created. This would be really helpful to me. More convenient than online calculators and the run can be aborted if the user doesn't like the projected size.
Deleted User 13735

Re: File size estimate

Post by Deleted User 13735 »

You will find through a search here, that it is no
longer a practical option because it would not be accurate.
Djfe
Bright Spark User
Posts: 178
Joined: Tue May 13, 2014 8:01 pm

Re: File size estimate

Post by Djfe »

he doesn't want an option like "pls stay below this file size",
but a bar/text next next to the avg fps that shows "current avg. Bitrate * length of the movie" which shouldn't be hard to implement, right?

of course it isn't accurate, but he was asking for an estimated file size

if there is a lot of black at the end of the movie it will of course result in a smaller file size and vice versa if tehre is a lot of complex stuff

but still: it would be easier than making this calculation manually based on the avg bitrate of a preview file, which you can make beforehand


it would be a little bit more complex but more accurate if you base it on a 2-pass encoding, but that's not what the TE was asking for
he was just asking for a simple interface element


EDIT:
@tmcdanel you could switch to Vidcoder (Windows only)
it supports the option "target size" still
https://vidcoder.codeplex.com/
Deleted User 13735

Re: File size estimate

Post by Deleted User 13735 »

that shows "current avg. Bitrate * length of the movie" which shouldn't be hard to implement, right?
If you will but do the search, as was requested of the OP, you will find the reasons from the developers why an "estimated file size" option, either static or dynamic, is no longer practical. The issue was laid to rest long before you joined the forum, and there is absolutely no need to reopen that can of worms.

Any rudimentary bitrate calculator will do just as well, and that's what I use (I'm a producer). Best.
ClickClick5
Posts: 15
Joined: Sun Oct 30, 2011 5:40 pm

Re: File size estimate

Post by ClickClick5 »

musicvid wrote:
that shows "current avg. Bitrate * length of the movie" which shouldn't be hard to implement, right?
If you will but do the search, as was requested of the OP, you will find the reasons from the developers why an "estimated file size" option, either static or dynamic, is no longer practical. The issue was laid to rest long before you joined the forum, and there is absolutely no need to reopen that can of worms.

Any rudimentary bitrate calculator will do just as well, and that's what I use (I'm a producer). Best.
Not an estimated size for quality, but an estimated size of the finished movie. So when you click Start to encode, it will tell you this in the status bar "03.89%, FPS: 032.9, Time Remaining: 01:14:37, Elapsed: 00:03:12, Estimated Size: 3.67GB, Pending Jobs 0"
Deleted User 13735

Re: File size estimate

Post by Deleted User 13735 »

Not an estimated size for quality, but an estimated size of the finished movie. So when you click Start to encode, it will tell you this in the status bar "03.89%, FPS: 032.9, Time Remaining: 01:14:37, Elapsed: 00:03:12, Estimated Size: 3.67GB, Pending Jobs 0"
]

Absolutely ridiculous. Such an indication would fluctuate wildly with each scene change, and would never approach parity with the encoded file size until the very end of the encode. Please try to understand, there is no encoder scan pass with CRF, so no prediction!!!
mduell
Veteran User
Posts: 8187
Joined: Sat Apr 21, 2007 8:54 pm

Re: File size estimate

Post by mduell »

musicvid wrote:Not an estimated size for quality, but an estimated size of the finished movie. So when you click Start to encode, it will tell you this in the status bar "03.89%, FPS: 032.9, Time Remaining: 01:14:37, Elapsed: 00:03:12, Estimated Size: 3.67GB, Pending Jobs 0"
]

Absolutely ridiculous. Such an indication would fluctuate wildly with each scene change, and would never approach parity with the encoded file size until the very end of the encode. Please try to understand, there is no encoder scan pass with CRF, so no prediction!!![/quote]

If you did it on progress so far it would converge on the eventual file size, just like time remaining converges.
Deleted User 13735

Re: File size estimate

Post by Deleted User 13735 »

If you did it on progress so far it would converge on the eventual file size, just like time remaining converges.
And that final climactic 20 minute scene where the universe explodes changes the whole game. Been there.
There is no abr prediction possible in a single crf pass; with "convergence" possibly becoming apparent only right near the end, as I said.

That all being said (again), I would be in favor of such an indicator being exposed when 2-pass abr, cfr encoding is checked, only, because it at least stands a chance of being reasonably accurate.

I own some very expensive NLE suites for my work, and none has ever had even a rudimentary file size estimator built-in.
The reason, I suspect, is because third-party bitrate calculators and 5th grade mental math solutions (for abr) abound. People could simply learn to use them. That's how broadcasters and web delivery types do it.
rollin_eng
Veteran User
Posts: 4840
Joined: Wed May 04, 2011 11:06 pm

Re: File size estimate

Post by rollin_eng »

Maybe instead of estimated file size it could display the current file size. That way you could tell if the file is getting too big to soon and would also give you a rough idea of final size.
ClickClick5
Posts: 15
Joined: Sun Oct 30, 2011 5:40 pm

Re: File size estimate

Post by ClickClick5 »

rollin_eng wrote:Maybe instead of estimated file size it could display the current file size. That way you could tell if the file is getting too big to soon and would also give you a rough idea of final size.
Sorry to bring up the dead, but I was thinking about this today and decided to knock out some code that would do this.

In short, having the system create a steady "this will be the final size" is doable, but VERY hard to keep accurate within any realm of usefulness. Thus this is a no go.

However, having Handbrake show the size "thus far" is much more doable, but still not super accurate. x264 shows the current bitrate that it is doing at a given interval. With this, the total movie size could be roughly estimated. Tacking on the size of the audio would be a different task.
Something like:

completedSize = (kiloBits*8.00) + completedSize;

Each time x264 updates its output stats, grab the current kilobit per second value, divide by eight, add onto itself, and keep going. This though would only add the current kb/s output stat onto the previous output stat, thus not adding in the sizes in between stat outputs.

My only wall here is if Handbrake uses libx264 as the encoder, as this does not give the final (overhead included) kb/s. EDIT: Doh, it does.

If anyone has any other ideas to implement this, I'm game. Just some thoughts I had today at work on how this could be done.
Last edited by ClickClick5 on Fri Nov 14, 2014 1:50 pm, edited 1 time in total.
Deleted User 13735

Re: File size estimate

Post by Deleted User 13735 »

Well, most action/drama movies save the big action scenes for the very end. Could gobble up bits at many times the average rate of the preceding two hours . . .

In a single pass CRF, nothing is going to be accurate enough to please the average peahead, so best just to leave it out.
Hanbrakeur
Experienced
Posts: 93
Joined: Mon Jun 30, 2014 10:39 pm

Re: File size estimate

Post by Hanbrakeur »

It would be great to implement file size estimate for 2-Pass CBR projects.
TedJ
Veteran User
Posts: 5388
Joined: Wed Feb 20, 2008 11:25 pm

Re: File size estimate

Post by TedJ »

musicvid wrote:Well, most action/drama movies save the big action scenes for the very end. Could gobble up bits at many times the average rate of the preceding two hours . . .
Came across a great example of this the other day. I was encoding Ice Age 2 for my kids and the flood sequence at the end of the movie caused an impressive bitrate spike. It would appear that even CGI water is challenging to encode. ;)
ClickClick5
Posts: 15
Joined: Sun Oct 30, 2011 5:40 pm

Re: File size estimate

Post by ClickClick5 »

Well I'll continue to just check the file size of the movie on the desktop!
Deleted User 13735

Re: File size estimate

Post by Deleted User 13735 »

With ABR/CBR it's:
Bitrate (Mbps) X Time (Sec) X .125 = File Size (MB)
You have to add your audio bitrate to be more accurate.
zhossein
Posts: 1
Joined: Sat Apr 18, 2015 9:08 am

Re: File size estimate

Post by zhossein »

I've used MeGui before and it has a feature to estimate output file size before conversion
adding this feature in "Handbreak" would improve scheduling and conversion management
Please consider adding this feature "Estimated output file size" for later releases.
How can I submit this feature request other than replying here??? or is it already in some kinda queue in feature requests?
User avatar
s55
HandBrake Team
Posts: 10350
Joined: Sun Dec 24, 2006 1:05 pm

Re: File size estimate

Post by s55 »

Feature Request has been rejected numerous times for the reasons already listed in this thread.
Closing thread as there is nothing more to be said on this.

To answer your other question, Just posting in the Requests forum is sufficient.
Locked