hello
can you add the ability to limit file destination size?
thanks
HandBrake 1.2.1
Forum rules
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
-
rollin_eng
- Veteran User
- Posts: 4859
- Joined: Wed May 04, 2011 11:06 pm
Re: HandBrake 1.2.1
This was removed from HB a long time ago, please search the message board for the various reasons.
Re: HandBrake 1.2.1
The ability to limit the size is there (set a maximum bit rate to what it will take to get to that size, you can find that with a "bit rate calculator" on line). It will work best if you use 2-pass encoding, as the first pass gathers information necessary to tell the second pass when to throw out quality to meet the bit rate requirement.
But since that is not an exact science (i.e., it doesn't really work the way you think it should work), it isn't a "click of a button" thing.
But since that is not an exact science (i.e., it doesn't really work the way you think it should work), it isn't a "click of a button" thing.
Re: HandBrake 1.2.1
What about having it calculate an estimated file size before its encoded?
CRF filesizes vary quite a bit, it would be good to know in advance if the output will be 2GB or 9GB.
CRF filesizes vary quite a bit, it would be good to know in advance if the output will be 2GB or 9GB.
Re: HandBrake 1.2.1
Trying to calculate the size before you read the data is not really possible, unless you encode with a fixed bit rate.
Different scenes require different amounts of bits to encode, and depends on the complexity of the scene (how much detail is "necessary"), how much "noise" is going to be encoded or filtered out, how fast things move, how MUCH of the screen changes, et cetera. Two 23-minute episodes of the same TV show can be wildly different in size, even with the exact same settings.
Example, 14 episodes of one series I encoded this past week varies in size from 690MB to 1012MB, even though they are all highly-compressible animated sources, compressed at RF=20. But two of them have very high-action fight scenes, while one is mostly a "talking heads" episode.
Different scenes require different amounts of bits to encode, and depends on the complexity of the scene (how much detail is "necessary"), how much "noise" is going to be encoded or filtered out, how fast things move, how MUCH of the screen changes, et cetera. Two 23-minute episodes of the same TV show can be wildly different in size, even with the exact same settings.
Example, 14 episodes of one series I encoded this past week varies in size from 690MB to 1012MB, even though they are all highly-compressible animated sources, compressed at RF=20. But two of them have very high-action fight scenes, while one is mostly a "talking heads" episode.
Re: HandBrake 1.2.1
The preview option samples many parts of a video. Maybe the preview data could be used to extrapolate an estimated file size for the output.
An estimated file size range of +/- 30% would be close enough for me.
An estimated file size range of +/- 30% would be close enough for me.
Re: HandBrake 1.2.1
This isn't practical. Even sampling could take several hours of encoding only to get a garbage result.
-
Deleted User 11865
Re: HandBrake 1.2.1
Extrapolations made from incorrectly selected samples leads to unwarranted conclusions.
One of the primary reasons for the "preview" is to determine whether or not the video has "letter boxing", which can be cropped off. It is entirely possible to take 20 samples of a video, determine that it is "safe" to crop 140 pixels off the top and bottom, and end up with an unusable video, because 20 samples happened to fall in sections of the video that were letter boxed, but the rest of the video is full-frame.
How do you "correctly" sample, so that you can make a valid extrapolation? You read the whole file - which is what the first pass does when you've setting a target bit rate. And even then, the extrapolation can be wrong - a source could be highly-compressible for 95% of its length, and be well under your target bit rate, but 5% of it is severely constrained by that bit rate.
One of the primary reasons for the "preview" is to determine whether or not the video has "letter boxing", which can be cropped off. It is entirely possible to take 20 samples of a video, determine that it is "safe" to crop 140 pixels off the top and bottom, and end up with an unusable video, because 20 samples happened to fall in sections of the video that were letter boxed, but the rest of the video is full-frame.
How do you "correctly" sample, so that you can make a valid extrapolation? You read the whole file - which is what the first pass does when you've setting a target bit rate. And even then, the extrapolation can be wrong - a source could be highly-compressible for 95% of its length, and be well under your target bit rate, but 5% of it is severely constrained by that bit rate.