[Rejected] File size estimate
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.
*******************************
*******************************
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.
*******************************
[Rejected] File size estimate
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.
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.
Re: File size estimate
You will find through a search here, that it is no
longer a practical option because it would not be accurate.
longer a practical option because it would not be accurate.
Re: File size estimate
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/
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/
Re: File size estimate
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.that shows "current avg. Bitrate * length of the movie" which shouldn't be hard to implement, right?
Any rudimentary bitrate calculator will do just as well, and that's what I use (I'm a producer). Best.
-
- Posts: 15
- Joined: Sun Oct 30, 2011 5:40 pm
Re: File size estimate
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"musicvid wrote: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.that shows "current avg. Bitrate * length of the movie" which shouldn't be hard to implement, right?
Any rudimentary bitrate calculator will do just as well, and that's what I use (I'm a producer). Best.
Re: File size estimate
]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!!!
Re: File size estimate
]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.
Re: File size estimate
And that final climactic 20 minute scene where the universe explodes changes the whole game. Been there.If you did it on progress so far it would converge on the eventual file size, just like time remaining converges.
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.
-
- Veteran User
- Posts: 4859
- Joined: Wed May 04, 2011 11:06 pm
Re: File size estimate
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.
-
- Posts: 15
- Joined: Sun Oct 30, 2011 5:40 pm
Re: File size estimate
Sorry to bring up the dead, but I was thinking about this today and decided to knock out some code that would do this.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.
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.
Re: File size estimate
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.
In a single pass CRF, nothing is going to be accurate enough to please the average peahead, so best just to leave it out.
-
- Experienced
- Posts: 93
- Joined: Mon Jun 30, 2014 10:39 pm
Re: File size estimate
It would be great to implement file size estimate for 2-Pass CBR projects.
Re: File size estimate
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.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 . . .
-
- Posts: 15
- Joined: Sun Oct 30, 2011 5:40 pm
Re: File size estimate
Well I'll continue to just check the file size of the movie on the desktop!
Re: File size estimate
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.
Bitrate (Mbps) X Time (Sec) X .125 = File Size (MB)
You have to add your audio bitrate to be more accurate.
Re: File size estimate
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?
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?
Re: File size estimate
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.
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.