What happened to the "Target Size" quality option?

[Deleted User 13735]

My sources for the video files may be flash\html5 captures, Usenet downloads, Bittorrent downloads . . .

Woops. Read the forum rules.

[jamiemlaw]

I have come up with a simple metric for setting the 'Target Size' which is ~500MB/hour of program content.

This is a textbook example of when you would need to use average bit rate and specifically not target file size, even if it were available.

[mappyman]

People say the feature was broken.. but it wasnt broken for what I needed.. it was a great feature which worked.

I don't encode movies.. I only encode gaming footage taken from fraps and have 100s of files which I need to fit a specific size and im not too bothered about
having a high quality.. only that I can fit some many games on a DVD / Youtube.

Now I got to mess with each file on 0.96 and tweak it.. suddenly things got so time consuming to play "fit the footage to the correct size".

I gave up and went back to 0.95... I wont be upgrading to 0.96+.

I am looking for alternatives and will probably not visit Handbrake (website & software) again.

[TedJ]

*sigh*

I wouldn't advise visiting these forums again if you're sticking to the 0.9.5 release as we no longer offer support for it.

Once again I ask, is it really that difficult to use one of the dozens of online bitrate calculators in conjunction with HandBrake's ABR encoding mode? I've been doing so in my day job for years now and the process takes no more than a few seconds... are you really that time starved?

[mlandis]

*sigh*
Once again I ask, is it really that difficult to use one of the dozens of online bitrate calculators in conjunction with HandBrake's ABR encoding mode? I've been doing so in my day job for years now and the process takes no more than a few seconds... are you really that time starved?

Not to seem too ignorant but could someone expand on the suggested procedure to select the parameters required to create a resultant file within some pre-determined maximum length. Typically the only info that I have on each individual file are filetype (avi/flv/mp4/mkv/etc..), current file size and run-length. I normally don't change any other parameters (Size/Filters/Framerate/Advanced/etc), use the normal presets and only want the resultant mp4 file to not exceed a given filesize so what do I do next using what tools in what order? Thx.

[Pawnslinger]

Okay, I am a newbie, and more than a little afraid to write anything in this thread. I confess, I haven't read the whole thread, but a couple of things seem clear to me, from the parts that I' HAVE read. First, Target Size is not coming back, and at this point, that sounds like the correct decision to me. But that doesn't mean that what we have now is perfect either. Constant Quality is very good, I have been using the heck out of it, but it does have its flaws, and one of them seems to be old grainy films. I noticed that a recent rip of an old B&W video that I did yesterday, using my normal RF setting produced a MUCH bigger file than I thought reasonable. When I checked with MediaInfo, the file had a bitrate of 5000kbps, which is just silly IMHO. So I redid the work with a much bigger RF setting. So if someone hasn't already suggested it, how about adding a bitrate cap to the Constant Quality setting?

This would insure that things didn't get out of control for people who run overnight unattended batches and save me from redundant work. Just a polite respectful thought.

[Flo]

how about adding a bitrate cap to the Constant Quality setting?

If that were the default, then the quality wouldn't be constant anymore. Noisy sources are pretty easy to identify, so why not lower the RF in advance or apply a denoise filter?

That said, the option is already there (vbv-maxrate=x, where x is the bitrate in kbit/s), it's just not exposed in the GUI. You have to manually add it in the advanced tab.

[Deleted User 11865]

how about adding a bitrate cap to the Constant Quality setting?

If that were the default, then the quality wouldn't be constant anymore. Noisy sources are pretty easy to identify, so why not lower the RF in advance or apply a denoise filter?

That said, the option is already there (vbv-maxrate=x, where x is the bitrate in kbit/s), it's just not exposed in the GUI. You have to manually add it in the advanced tab.

You also need to set a vbv-bufsize else it won't work. If unsure, just set it to the same value as vbv-maxrate.

[Pawnslinger]

how about adding a bitrate cap to the Constant Quality setting?

If that were the default, then the quality wouldn't be constant anymore. Noisy sources are pretty easy to identify, so why not lower the RF in advance or apply a denoise filter?

That said, the option is already there (vbv-maxrate=x, where x is the bitrate in kbit/s), it's just not exposed in the GUI. You have to manually add it in the advanced tab.

Okay, as I said, I am new. Thank you for the help.

First, a little clarification, what I was suggesting was a bitrate cap, one that would affect the overall bitrate as seen in the MediaInfo display. I guess it is called average bitrate. So I wouldn't be in favor of a cap for the peak bitrate. That, of course, would defeat the purpose of Constant Quality. Right? But what if the program could monitor the average bitrate as it proceeded, and then detect when it was getting larger than a user specified value, the RF could be adjusted, and a do over could be started automatically. This, of course, would take some time, but it would be faster than doing the same thing manually.

As for recognizing this manually ahead of time... I guess that an experienced hand might be able to do that. On the other hand, I appear to be surprised almost daily! So maybe I am still too new to recognize these things ahead of time. And I know that many people run HandBrake batches unattended, and almost without consideration of the type of material (the beauty of Constant Quality is that this almost works). Folks that run such batches may get surprises in the morning or whenever they return.

The vbv-maxrate... does it control the peak or average bitrate? If the peak rate, then I wouldn't want to use it.

[TedJ]

Not to seem too ignorant but could someone expand on the suggested procedure to select the parameters required to create a resultant file within some pre-determined maximum length. Typically the only info that I have on each individual file are filetype (avi/flv/mp4/mkv/etc..), current file size and run-length. I normally don't change any other parameters (Size/Filters/Framerate/Advanced/etc), use the normal presets and only want the resultant mp4 file to not exceed a given filesize so what do I do next using what tools in what order? Thx.

The only information you need are the runtime, desired file size and audio bitrate. You simply enter the relevant details into one of many bitrate calculators available online or for download then copy the resulting video bitrate into the average bitrate field in HandBrake.

[Iketh]

I think I'm still missing something. Are you saying that forcing a size most likely wastes space

Correct. By letting the encoder chose the bitrate you will probably save space and get better quality (the encoder is smarter than you and I).

Ahh.. Yea that makes sense. I always kind of figured that, I just liked the target size because of convenience. It would be cool/convenient if you could input a 'target size' and then the program/encoder would calculate a bit-rate that would make the size roughly around the target size. The program could even prompt with some kind of warning message about loss of quality, etc. This action would be very helpful for the average user (most of handbrakes 'market'). Its not about laziness, just convenience for those in a hurry/don't want to calculate things for every conversion. And for those that really cared about getting the most efficient conversion could do the calculating. As I said Im not trying to demand something, this function would just be very nice and is standard in other applications.

As of right now, I was happy just downgrading to Handbrake 0.9.5 to re-enable that function, but as time passes I might have to start looking for a new solution.

I have huge respect for you guys and everything you have done! Me and others (all the other forum post and the numerous articles on other websites only a few days after the update) are just really hoping that the Handbrake team will either re-enable or look for a similar solution.

-Tamuuli

You're the prime example why that feature needed to be removed. Most uninformed are using target bitrate to save space just like you and aren't realizing they're doing the complete opposite instead. So, the feature was removed. Kudos to the design team for the public service despite the "resistance."

[Iketh]

Removing this feature was kinda silly I mean what was there to gain by removing this feature? My gf liked using the target file size so she could email some videos sure its not for every situation but removing a feature is never a good idea.

see my post above

[Iketh]

I would like to explain why I am a 'Target Size' quality option user and why it provides the desired results when using HandBrake. I maintain a family TV/Movie video archive stored on a 4TB NAS. The total available video storage space is ~2TB with music and ebook files allocated for the remaining 1TB of the total usable 3TB on the NAS. As content is consumed it is deleted while new content is constantly being added.

My sources for the video files may be flash\html5 captures, Usenet downloads, Bittorrent downloads or rips from DVD/BD media. The advent of hi-def and the improvements in uplink bandwidth available to many has resulted in much downloadable content being available as larger and larger files since the uploaders have increasing bandwidth to use. Many times a desired program may only be available as a 1080p file (approx 2.5-3GB/hour) or a 720p file (approx 1-2GB/hour) which are too large to archive and stay within my storage constraints. I use HandBrake to re-encode and reduce file size when the file size is greater than 750MB-1GB/hour of program material. I have come up with a simple metric for setting the 'Target Size' which is ~500MB/hour of program content. This simple rule serves me well and the resulting video files are quite watchable.

The bitrate calculator spreadsheet referenced may be useful if I was interested in or had knowledge of the items that are specified but I have no idea what the audio or video rates of the source file are nor do I care. I've tried using various constant quality settings with different source files but after much trial and error cannot intuit what settings will produce what file size for a given source file knowing only program length and current file size. Given the implicit raison d’être for software as being a tool to simplify complex tasks, the path to the desired result in my case is now much more complex and may even be unreachable without the 'Target Size' option.

I hope this illustrates that there are uses for your tool which provide results emminently desireable by some but which are diametrically opposed to what you the developer see as valuable. I'm not suggesting that there be any reversal in your approach but that there be begrudging acknowledgement that sub-optimal use of a tool like HandBrake can be worthwhile when the desired end result is accomplished.

SMH

[justsomeguy]

I registered to comment on this particular subject.

I only recently came to need a program that could convert videos, and everything I could find pointed to handbrake as my best option.

I don't have a clue about bit rates and all that nonsense, not for lack of trying mind you. I have spent the last two days trying to wrap my head around all this terminology and what it means. I have been to some of these calculators everyone is linking to, I even downloaded a couple and tried to play with them. no matter how much I read im still staring at all of this like a neanderthal trying to figure out how a circuit board works. when you say "is it really that hard?" I have to reply "yes, very much so."
if constant quality or whatnot is important that's fine, but at least build one of these calculators into the program and put a little "estimated filesize" widget in there somewhere so as im fiddling with numbers who's meanings are beyond my understanding I have a clue if im getting close to the filesize I need.

I apologies if this came across wrong im just very frustrated as I don't know what to do now.

[Pawnslinger]

The first thing I noticed when I started using HandBrake about 10 days ago ---- using the default Constant Quality setting produced the smallest filesizes I had ever seen (for videos that looked great anyhow).

Bitrates aren't hard, if one understands this basic relationship:

Filesize = Duration x Bitrate

Now, I admit that is somewhat of an over-simplification. But that is it, in a nutshell.

[JohnAStebbins]

I registered to comment on this particular subject.

I only recently came to need a program that could convert videos, and everything I could find pointed to handbrake as my best option.

I don't have a clue about bit rates and all that nonsense, not for lack of trying mind you. I have spent the last two days trying to wrap my head around all this terminology and what it means. I have been to some of these calculators everyone is linking to, I even downloaded a couple and tried to play with them. no matter how much I read im still staring at all of this like a neanderthal trying to figure out how a circuit board works. when you say "is it really that hard?" I have to reply "yes, very much so."
if constant quality or whatnot is important that's fine, but at least build one of these calculators into the program and put a little "estimated filesize" widget in there somewhere so as im fiddling with numbers who's meanings are beyond my understanding I have a clue if im getting close to the filesize I need.

I apologies if this came across wrong im just very frustrated as I don't know what to do now.

In all that monologue, you never mentioned why you *need* target file size. Do you *really* need it or are you just choosing it because it is all you understand? If the latter, I strongly suggest investing a little time in learning about constant quality mode. It will always give consistently better quality than target file size will, and it is a very easy set-it-and-forget-it setting. Once you've settled on a value that gives quality you find acceptable, you never have to change it again.

[jamiemlaw]

Is it just me or is Target FIle Size like nicotine?

"But I ne-e-e-e-e-d it!"

[sgtrobo]

Perhaps it should go in the FAQ then.

Perhaps it should. Can't guarantee that anyone will read it prior to asking anyway, just like the release notes.

perhaps the release notes should be linked in the How to Request Support for Handbrake thread. I know I would've read them if they were linked in the thread that gives very specific directions about what to read prior to posting a question.

). Its not about laziness, just convenience for those in a hurry/don't want to calculate things for every conversion.

But it seems rather than just try using the new settings and see if they work you are going to downgrade to an obsolete version. Sounds pretty lazy to me.

wow, someone receives insults because he wants to use a convenient setting in an application, or are you in the habit of randomly accusing people of being lazy because they like to use what works? Did you ever revert back to a previous edition of software because you liked it better? Did you "un-upgrade" from Windows ME to 98 back in the day because ME didn't do what you liked? What about 'downgrading' from Office 2007 to Office XP because you didn't like the ribbon? Was that laziness? That's a ridiculous statement to make.

Handbrake takes a few hours per disk to work it's magic, and if you don't know what settings to adjust, you will end up with hours of wasted time and a large file you'll end up deleting. That's not laziness, that's a desire to avoid wasting an entire workday.

set handbrake to work it's magic. leave for work. return, only to find out you wasted the day because the file is way larger than you wanted. Wanting to avoid this is hardly "laziness". It's sensible.

If you use Constant Quality, there is always the likelihood of an encode coming out smaller than you expected. Given the poor quality encoders that people have used in the past, I get the feeling that they often overestimate the bit rate required to get good quality video. In your case, you suggested 2GB for a movie. That's 3000kbps. Very few SD movies encoded in HandBrake with constant quality ever reach that. Most are around 2000kbps and in the case of some cartoons, 1000kbps.

would suggest you encode maybe a dozen or so movies - enough for you to get a feel for the kind of file sizes it produces. Because the file sizes will vary. But it depends on the type of film. After a while, either you'll find it works brilliantly, like most people here think it does. If after you've encoded a bunch of videos you find that they're consistently coming out larger than you like, or smaller, you can raise or lower the RF respectively to correct this (lower RF = better quality). What we're hoping here is that you'll find that while some movies come out larger than you were expecting, some come out smaller, and they average out at being the right size.

looks like an excellent post to include in the FAQ. Excellent information, thank you.

The problem for me and my clueless newbness is that i have 0 concept of what the file sizes will end up as, and with an i3-2310 SandyBridge CPU, that's a good 6+ hours of time wasted each 'screw-up', so a dozen or so encodes is about a week's worth of time.

2) Anyone producing original, legitimate video files for streaming or download has absolutely no use for such an option, because they already know the math.
700MB is dead. So is torrent.

well, I'm pretty ignorant, so I have no clue whatsoever what you are going on about here, especially #2 above. Are you trying to say that, implicit within the original purchase of a BluRay drive and a BluRay disk, is the knowledge of how to use Handbrake? obviously that's not what you meant, so please dumb it down for the rest of us dummies.

I've said this dozens of times. I suppose one more time isn't going to kill me. The feature was broken and getting more broken with each release. None of the developers used it, and therefor it got no testing and very little attention as we developed new features. The target size feature impeded our ability to "push this fantastic program further". It resulted in numerous special case scenarios that added complexity to the code. It also added complexity to the gui design since it required disabling certain features whenever it was enabled. Certain options just mysteriously vanish from the UI when target size is enabled, or worse, they don't vanish, but they have no effect when selected.

THIS is a response that makes perfect sense. Thank you. I'd be willing to bet the last several pages of bickering would not have occurred were this simple fact stated earlier.

Now, someone linked this handy-dandy calculator and it is quite accurate from the testing I've done so far (which is minimal). Some of the others had a gajillion and one settings which all flew over my head. This one is easy.

Here's how I have begun to 'figure out' how the filesizes are affected. I started with a Thor 1080p mkv I made with all the subtitles and such removed. 3.74 GB, with a 1920x816 resolution.

I created a spreadsheet and tracked the changes as I made them. Using 'regular high profile', I made the following changes with the resultant file sizes:

RF19, 1280x544, 2256 video Kbps, 160 Audio Kbps = 1.98 GB
RF21, 1280x544, 1666 video Kbps, 160 Audio Kbps = 1.49 GB
RF22, 1280x544, 1440 video Kbps, 160 Audio Kbps = 1.31 GB
RF22, 1280x544, 1365 video Kbps, 80 Audio Kbps = 1.28 GB

So here's the last 4 pages, summed up:
1. Target size is gone
2. Target size isn't coming back because it's broken
3. use the "Constant Quality" setting, and make adjustments to the RF slider and audio bitrate in conjunction with the bitrate calculator if you need to get a target file size
4. Insert random, completely unnecessary insults along the way

Before I crash tonight, I'm going to use RF22, 1280x544, and I'm going to set the audio Kbps to 64 AC3, and I'll report back in the morning about the file size. Don't know if that'll help or not, but I'd say it beats arguing back and forth for no real reason.

[sgtrobo]

Here's how I have begun to 'figure out' how the filesizes are affected. I started with a Thor 1080p mkv I made with all the subtitles and such removed. 3.74 GB, with a 1920x816 resolution.

I created a spreadsheet and tracked the changes as I made them. Using 'regular high profile', I made the following changes with the resultant file sizes:

trial 1=RF19, 1280x544, 2256 video Kbps, 160 Audio Kbps = 1.98 GB
trial 2=RF21, 1280x544, 1666 video Kbps, 160 Audio Kbps = 1.49 GB
trial 3=RF22, 1280x544, 1440 video Kbps, 160 Audio Kbps = 1.31 GB
trial 4=RF22, 1280x544, 1365 video Kbps, 80 Audio Kbps = 1.28 GB
trial 5=RF22, 1280x544, 1442 video Kbps, 64 Audio Kbps = 1.29 GB

so added the results from my overnight encode, and I have no flippin' clue how the heck that happened. Why would the video Kbps change so drastically from trial 3 to 4, then 4 to 5, if I left the slider alone?

[Deleted User 11865]

Without logs, it's impossible to tell.

[sgtrobo]

Without logs, it's impossible to tell.

right, reading up on that now. I'm slow, sorry.

EDIT -

Wife: "oh, by the way honey, the dog knocked the cord out of the external hard drive, so I plugged it in and started your Brake thingee for you again"

so yeah. Let's just redo that one. I'm going to post the log of my "1280.RF22.AUDIO80" though, but I'll do it in a separate subject since it's nothing to do with this one, sorry to get it off track.

[Deleted User 13735]

"musicvid wrote:2) Anyone producing original, legitimate video files for streaming or download has absolutely no use for such an option, because they already know the math.
700MB is dead. So is torrent."

well, I'm pretty ignorant, so I have no clue whatsoever what you are going on about here, especially #2 above. Are you trying to say that, implicit within the original purchase of a BluRay drive and a BluRay disk, is the knowledge of how to use Handbrake? obviously that's not what you meant, so please dumb it down for the rest of us dummies.

What I said was, people use Handbrake for other purposes than it was originally envisioned; i.e., transferring movies on disc to compressed files for personal use. Such legitimate uses include preparing original and commercial content for Youtube, presentations, ENG, Indie filmmaking, and Web and intranet delivery. Handbrake is so good and fast that it is for many the preferred method of preparation; even TV stations are beginning to adopt it over QT. These are serious editors and IT professionals who already know how to adjust bitrate (or not) to achieve their particular quality vs. streaming bandwidth requirements. They, along with the average home user, for whom storage is cheap, have relatively little use for an inefficient "target size" option, other than as a novelty.
http://www.jazzythedog.com/testing/DNxHD/HD-Guide.aspx

If you do not know what the last line in my quote means, then it was not intended for you. It was meant for the "other" content distributors, same ones who cry loudest and longest that the feature they "need" was removed, all the while loudly proclaiming their innocent intentions and legitimacy. They know who they are. For the rest of us, learning to use a bitrate calculator for occasional needs is not going to seem like such a monstrous inconvenience.

[Deleted User 13735]

THIS is a response that makes perfect sense. Thank you. I'd be willing to bet the last several pages of bickering would not have occurred were this simple fact stated earlier.

Now, that is ridiculous. Mr. Stebbins has stated exactly the same facts, over and over and over again, going back a couple of years.

[match]

THIS is a response that makes perfect sense. Thank you. I'd be willing to bet the last several pages of bickering would not have occurred were this simple fact stated earlier.

Here is the simple fact that if stated earlier, the last several pages of bickering would not have occurred...one word...Vidcoder. Another program that does the same thing as Handbrake but the author had decided to keep the target file size option (along with CRF) when it disappeared from Handbrake some time ago. Handbrake is open source software. Vidcoder takes the same code/encoding engine, etc. as Handbrake and just provides a different interface that some prefer over Handbrake. Personally, I think Handbrake's interface is better...or maybe I'm just more used to it. But there are a couple of nice items that Vidcoder's interface has that Handbrake doesn't. If you don't mind using a different interface, and want the same hi quality video files and same simple, yet powerful encoding options as Handbrake, then Vidcoder is your solution.

Summary:
- Target file size is not dead nor broken. Vidcoder is proof of that. There are certainly uses, albeit on the rare side, that call for that option.
- Vidcoder is Handbrake with a different interface. It will produce the same exact files, the same way as Handbrake.
- Vidcoder provides same options as Handbrake plus a couple more. One of those options is target file size.

End of discussion.

[asdaff]

Wow, thanks this useful link, i need target size, and Vidcoder is better, powerfull than HB, so bye-bye HB, welcome Vidcoder. Also, i just say, respect to the programmers for their work...but this arrogant, rude style with the customers is not acceptable+1 reason why i uninstall HB, the VC author is more likeable, helpful person, then this arrogant guyz....