Disappointed to see target file size go

[randomreuben]

I have a suggestion and it may make the removal of this feature easier to bear. Would the devs consider adding a small, "greyed-out" display field next to the ABR area to indicate a guesstimate for the size of the finished encode? I think this would let the people who want to quickly shove a film onto a CD use this target size feature without having to officially call it a target size encode?

The math for a guesstimate for the encode is already outlined above in this thread by Rodeo. If a guesstimate for the size were to be put up and the tag for it read "not actual final size", then we could maybe satisfy the camp that wants to quickly put an encode on removable media.

[Deleted User 11865]

You're just suggesting to re-introduce target size with a different name. This is no different than target size + a warning.

[match]

I think I might of mentioned this earlier in the thread, but don't remember an answer...Is target size something that is being removed from the command-line version as well?

[match]

I noticed that the setting for avg bitrate is another option besides crf. I've never used that option before. How do you use this option? i.e., what kind of application/project would warrant or benefit from using this?

[randomreuben]

The AVG bitrate option is useful when encoding for a specific hardware media player. The PSP for instance, requires that AVG bitrate not exceed 768 kbps. I'm certain other hardware media players come with their own quirks, and that is where AVG bitrate is useful.

[thompson]

The AVG bitrate option is useful when encoding for a specific hardware media player. The PSP for instance, requires that AVG bitrate not exceed 768 kbps. I'm certain other hardware media players come with their own quirks, and that is where AVG bitrate is useful.

Are you sure that this requirement isn't a peak bitrate requirement?

[JohnAStebbins]

The AVG bitrate option is useful when encoding for a specific hardware media player. The PSP for instance, requires that AVG bitrate not exceed 768 kbps. I'm certain other hardware media players come with their own quirks, and that is where AVG bitrate is useful.

Actually, you should use VBV settings for this problem. ABR allows more local variation in bitrate than these devices can handle. VBV is designed specifically for these types of limits. So once again, the better choice is CRF, with the addition of VBV.

ABR is really only useful if you don't care so much about quality and want to keep stricter control over the resulting file size.

[henrikhoe]

also gutted by this

i use it to convert to the ipad, max size 2gb. i hate rf, i get one 1.8gb movie and one 3.9gb movie using rf 23, and i dont want to the encode 5 times before i get that, target size simplifed things and i loved it.

Shame, i dunno why the devs cant just hide the feature, its seems so ridiculous

[yabolus]

I just pulled Handbrake from SVN and noticed the 'updated' video settings tab. I found this topic, read a few dev responses... and it's just ridiculous. It's ridiculous to the point I'm still not sure if it's not just a bad joke.

I perfectly understand that certain users are idiots who can't be reasoned with. They will use features they don't understand and go complaining to you. I understand this makes you mad. But that doesn't justify COMPLETELY removing a feature MOST users use responsibly and understand it's shortcomings. You could:

• make the app display a big red warning: "This feature is unsupported and will probably not work as you expect. Asking about it on the forums will get you instantly BANNED!" when it's first used (or every time it's used)
• put it behind a configuration option that is disabled by default
• put it behind a freaking ./configure switch
• even do all these things together

But no, you chose to remove the feature completely. You decided to harm 90% of your users, because 10% of them are idiots. You made the idiots win. Congratulations. I hope you're proud.

[randomreuben]

@ Rodeo,

You're just suggesting to re-introduce target size with a different name. This is no different than target size + a warning.

That's exactly what I was thinking. Here's the thing. "Target Size" is simply ABR with some additional math thrown in. That's all it is. The math for it, was described earlier, quite nicely by yourself. So really it's not so much a feature being removed as some math no longer being done in the background.

Given how useful a target size setting is, and how much people seem to like it, it seems a shame to let this go by the wayside. It's not cool to be dictating how people should be doing their encodes by dissing ABR and Target Size while still allowing CRF values higher than 35, or even allowing a Theora video encoder. Nothing looks like so much rubbish as a Theora video encode.

I understand that the devs have this project and while technically it is your baby, HandBrake has grown to so much more than that. It's a verb where I am. "Just HandBrake it." is something people say. So why do remove a handy feature and give out bad vibes for the sake of some background math?

Yes, a greyed-out box of estimated target size is almost the same as Target Size. But that's all Target Size was in the first place. Write down in BIG LETTERS for the tooltip for the greyed-out box, "Target Size is an estimate of the final size. This is an unsupported feature."

You already do the warning sign for the CRF values which are too low. So why not a warning sign for an estimated Target Size?

You clearly stated that some idiotic users were ruining this for everyone. Include the feature, but call the feature "unsupported". Refuse to engage any converstation where an idiot brings up "Target Size" and how it gives him a closer shave than CRF, because it's unsupported.

Yes, Rodeo, you're right. ABR plus an estimated size is almost the same thing. That's why I'm trying to point out that you're not really removing a feature, but simply making end users do some annoying math as long as the ABR option exists.

[s55]

Again, There is more than 1 reason that this was removed.

So why not a warning sign for an estimated Target Size?

A warning sign doesn't fix the fact it has nasty bugs ...

And having warnings all over the place in the UI is just going to make the thing garbage.

Yes, a greyed-out box of estimated target size is almost the same as Target Size. But that's all Target Size was in the first place. Write down in BIG LETTERS for the tooltip for the greyed-out box, "Target Size is an estimate of the final size. This is an unsupported feature."

All that's going to do is create more frustration, confusion and complaints when Features A, B and C are supported by X, Y and Z are not.

[yabolus]

And having warnings all over the place in the UI is just going to make the thing garbage.

Not as much as removing useful features.

[thompson]

And having warnings all over the place in the UI is just going to make the thing garbage.

Not as much as removing useful features.

Again, no one has been able to articulate an actually "useful" quality that target size provides with the sole exception of storing on removable media, and given how inexpensive harddrive space is these days I'd say that's a quality with declining usefulness.

[yabolus]

And having warnings all over the place in the UI is just going to make the thing garbage.

Not as much as removing useful features.

Again, no one has been able to articulate an actually "useful" quality that target size provides with the sole exception of storing on removable media, and given how inexpensive harddrive space is these days I'd say that's a quality with declining usefulness.

True, if all you're gonna do is store it. But when I want to borrow it to a friend, I won't be handing my hard drive over to him. If I exchange movies a lot, then it's much more practical to store them on DVDs.

[match]

Again, no one has been able to articulate an actually "useful" quality that target size provides with the sole exception of storing on removable media, and given how inexpensive harddrive space is these days I'd say that's a quality with declining usefulness.

Here's one way I used it, based on a true story...
I wanted to rip/encode one of my favorite series: Star Trek Next Generation. I wanted to keep the series under 100gb. Not because I wanted to put it on removable media, but just because I didn't want it to get out of control and take up more than that on my hard drive. I thought 100gb was a good size to shoot for, so I wanted to have control over the size of my encodes. I have a terabyte hard drive that I wanted to put no less than 10 series on.

So this is how I went about it...I knew that just randomly choosing a target size wasn't going to give me the quality I wanted. So I took a good cross-sample of the dvds across the seasons and went about encoding them at 18, 18.5, 19 and 19.5. Lo and behold, the various episodes came out at very similar sizes...however, they did vary (+) or (-) 75mb or so. Once in a while you would get one that was 100mb outside the range. Since 18, 18.5, 19 and 19.5 are pretty much all acceptable to me, I chose the size that would keep the series under 100gb. It turned out that 550mb was the sweet spot (25-26 episodes x 7 seasons x 550mb ~ 100gb.). It was in the 18-19.5 crf range. And when you have a tv series, the quality of the dvds is often quite similar across dvds...however using crf could easily overshoot my target. For instance, say I instead did all episodes at crf 19 and over half of them went over 550 by 30mb. Not a big difference in quality, but gave me 580 instead...I would overshoot my target by 3 gb. And it could easily surpass that. Or it could go the other way and undershoot my target. I simply wanted to control the size. And I did just that. I watched the whole series and was very happy with the quality across the board. If I had to bet, 550mb probably was in the range of crf 18-19.5 for each and every episode. So the quality didn't vary wildly as some would suggest.

Sure, when it comes to movies, I never use target size. I simply use 18.5 and fill up my "movies" terabyte drive with however many fit on it. Size at a consistent crf can vary wildly from one movie disc to another, but t.v. series tend to have a similar quality across the series.

So you see, here is an example of using target size which is not for removable media. I go through this algorithm (with a few variations when necessary) just about every time I encode a t.v. series. It works out great. I don't think this is abusing the option, and has worked perfectly over many series.

And I think yabolus had a really good point as well. Say you want to bring one of your movies to a friends house...No matter how cheap hard drive space is, I'm not going to bring my computer and/or hard drive over. That's just ridiculous.

[randomreuben]

It's very strange to hear a small group of people decide how a software should and should not be used. It sounds codependent to say "I can't see why you want to use this method and so I won't let you use it." As if one day LibreOffice would decide to cut out a Table of Contents feature because if you want to write a thesis, it's better to use LaTeX and not LibreOffice. It's none of your business how I choose to enjoy my encodes. It really isn't. I encode everything at RF 16 and delete the DVD from my hard drive. Do it once, do it right is what I like to do. thompson here insists that anything less than RF 18 is a waste. I really think that's all right for thompson to disagree and I won't argue with him/her over this because it's none of his/her business what I do with HandBrake and I won't try and make him/her switch to Rf 16 because he/she can do what he/she likes with HandBrake on his/her computer.

It'll be damn weird to wake up one day to see that thompson has disabled all RF values lower than 18 because he/she can't figure out a good reason why RF values lower than 18 should be used. It's this thing that kills me about this. It's not like Target Size encodes are an unwatchable mess. They're fine. If people are happy with a target size, let them be. Why should you have to twist their arm into not using it?

I feel like this entire mess could have been avoided by simply making "Target Size" unsupported. That would be that. End of discussion. But to throw it out entirely? And what's worse is that you're not throwing it out, but only partially throwing it out by still leaving ABR mode enabled and without some helpful hint for a guess as to file size.

I really think the devs here at HandBrake are God's/Flying Spaghetti Monster's gift to video encoding. I really do. If JohnAStebbins, Rodeo and jbrjake (it's you three I've talked to the most) get a statue built in honour of their work on HandBrake, I would be the first to contribute money to building that statue. I know that you guys work hard at this and that it sucks big, hairy monkey balls to have some idiot whine at you over your hard work. But this seems like you just sprung this on us and won't implement a "Unsupported!" policy on this thing.

[match]

A warning sign doesn't fix the fact it has nasty bugs ...

I hate to even bring it up, because I don't want to see average bitrate taken out since I will have to use it to make my own calculations for file size...but the wiki states that this is basically the same as target size. To quote: "Target size, really, is just the flip-side of average bitrate. The size of a video is the bitrate times the length. So when you set a target size, HandBrake just divides it by the movie's length to get a bitrate the encoder should use as an average. It's really the exact same thing." So doesn't that imply that average bitrate has nasty bugs as well? (btw..please please don't take that away too...that is the only way to predict file size now).

And having warnings all over the place in the UI is just going to make the thing garbage.

A box called "estimated" file size and a small note in the tooltip isn't going to garbage anything up. There are already other warnings in the tooltips of other u/i features.

All that's going to do is create more frustration, confusion and complaints when Features A, B and C are supported by X, Y and Z are not.

I agree that you can't be doing that. But there really isn't any support needed to use a feature called, "estimated file size". It is what it is. A user can't complain if it is just an estimate. I would guess 99 times out of 100 it works properly anyway. I have encoded 100's of files using it and have never had it not work properly. I've yet to run into any "nasty" bugs.

I still say a sticky at the top of the forums would be sufficient. Add a link to the wiki: https://trac.handbrake.fr/wiki/AvgBitrateAndTargetSize and give an explanation of the imperfections (which I have still yet to see anyway) of the feature that can apparently occasionally arise. How many times do users not post their activity logs? Yes, annoying...but we don't throw out the forums because people abuse the forums or annoy with their ignorance. They are simply ignored or asked to read the sticky.

This reaction is just from a change in the nightlies...probably most who use the nightlies know more about the benefits of crf and only use target size for certain circumstances. I imagine there is an even higher ratio of stable release users who use the target size option. Once you release the next stable version without this feature, you're going to hear a lot more aggravation from users than you ever got for buggy target size experiences.

[thompson]

It's very strange to hear a small group of people decide how a software should and should not be used. It sounds codependent to say "I can't see why you want to use this method and so I won't let you use it." As if one day LibreOffice would decide to cut out a Table of Contents feature because if you want to write a thesis, it's better to use LaTeX and not LibreOffice. It's none of your business how I choose to enjoy my encodes. It really isn't. I encode everything at RF 16 and delete the DVD from my hard drive. Do it once, do it right is what I like to do. thompson here insists that anything less than RF 18 is a waste. I really think that's all right for thompson to disagree and I won't argue with him/her over this because it's none of his/her business what I do with HandBrake and I won't try and make him/her switch to Rf 16 because he/she can do what he/she likes with HandBrake on his/her computer.

It'll be damn weird to wake up one day to see that thompson has disabled all RF values lower than 18 because he/she can't figure out a good reason why RF values lower than 18 should be used. It's this thing that kills me about this. It's not like Target Size encodes are an unwatchable mess. They're fine. If people are happy with a target size, let them be. Why should you have to twist their arm into not using it?

I feel like this entire mess could have been avoided by simply making "Target Size" unsupported. That would be that. End of discussion. But to throw it out entirely? And what's worse is that you're not throwing it out, but only partially throwing it out by still leaving ABR mode enabled and without some helpful hint for a guess as to file size.

I really think the devs here at HandBrake are God's/Flying Spaghetti Monster's gift to video encoding. I really do. If JohnAStebbins, Rodeo and jbrjake (it's you three I've talked to the most) get a statue built in honour of their work on HandBrake, I would be the first to contribute money to building that statue. I know that you guys work hard at this and that it sucks big, hairy monkey balls to have some idiot whine at you over your hard work. But this seems like you just sprung this on us and won't implement a "Unsupported!" policy on this thing.

No one's forcing you to upgrade once TFS is removed, and it's open source so if you and others feel strongly enough, fork it and add it back in.

[randomreuben]

Fork HandBrake? Really? You really think that Target Size is so FUBAR that the only option on the table is to fork HandBrake to get it back in? Not an "unsupported" warning and not an "estimated file size" display box, not any other solution, but to fork HandBrake? Shall I go to university for a computer science degree first? Then perhaps I can get to forking HandBrake? I love HandBrake. It's one of my favourite software packages. You think if I was able to fork HandBrake, I'd still be jawing on the sidelines? I would have happily contributed my time to HandBrake by now. Not fork HandBrake. Good grief. That seems a bit drastic, non?

Fine. Maybe "Target Size" was indeed so FUBAR that the earth weeped blood and kittens were born blind everytime someone used "Target File Size". I give up. Show us that you can take your ball and go away every time some jerk starts whining and ruining it for everyone.

[thompson]

I'm not a developer so I don't have a pony in this race, so to speak. But I have been around the bored long enough and seen enough requests related to TFS to understand exactly why the devs want to get rid of it. I've also been encoding video long before I found handbrake, and I know enough to see the huge number of flaws with TFS versus something like CRF, or even ABV with VBV.

As of now, it seems the only feature is removable media. I'm going to have to assume that we're talking about CD-R, as I strongly doubt any encode you're doing is going to come in over 4.7GB on a DVD-R. Fine, that's a legitimate benefit, but you can literally just make up a little Excel spreadsheet with the math that works out ABV->TFS and plug it in for those times when portability is necessary.

I think the reason handbrake is so successful is, in some sense, that it utilizes the "Apple model" for development: promote the good, abandon the bad, regardless of whether the "bad" is used by a minority of your user base. Remember when Apple dropped floppy disks? Or modem ports? People howled. I'm not saying that I don't understand your frustration, but for every person who knows exactly how to use TFS properly for the few cases it might be useful, there are 10s or 100s who have no idea what they're talking about, who are using some "Video Encoding Guide" they found on the web from 2003 that says to use X kbps for action DVDs and Y kbps for romantic comedies.

[Deleted User 11865]

A warning sign doesn't fix the fact it has nasty bugs ...

I hate to even bring it up, because I don't want to see average bitrate taken out since I will have to use it to make my own calculations for file size...but the wiki states that this is basically the same as target size. To quote: "Target size, really, is just the flip-side of average bitrate. The size of a video is the bitrate times the length. So when you set a target size, HandBrake just divides it by the movie's length to get a bitrate the encoder should use as an average. It's really the exact same thing." So doesn't that imply that average bitrate has nasty bugs as well? (btw..please please don't take that away too...that is the only way to predict file size now).

Average bitrate is not going away.

Note that the video average bitrate mode works as advertized (at least when using x264). The principal issues with target size were that:

- audio average bitrate isn't quite as accurate (especially with Core Audio and Vorbis)

- subtitles aren't taken into account (it's not possible to accurately predict the bitrate of a subtitles track; nor is it possible to control it)

- duration detection isn't bug-free and could cause target bitrate to select the wrong video bitrate

- audio bitrate detection (e.g. in case of passthrough audio) isn't bug-free either and could also cause target bitrate to select the wrong video bitrate

- annoying users, which the developers do have to deal with

Even if these issues are not always a problem, they're still present.

Also, it could be said that people who (actually) understand these issues and limitations should be able to target a specific file size using average bitrate, even if it's obviously less convenient.

And having warnings all over the place in the UI is just going to make the thing garbage.

A box called "estimated" file size and a small note in the tooltip isn't going to garbage anything up. There are already other warnings in the tooltips of other u/i features.

Yes, and the developers feel there are enough warnings as it is.

All that's going to do is create more frustration, confusion and complaints when Features A, B and C are supported by X, Y and Z are not.

I agree that you can't be doing that. But there really isn't any support needed to use a feature called, "estimated file size". It is what it is. A user can't complain if it is just an estimate.

Users can and will complain about anything.

This reaction is just from a change in the nightlies...probably most who use the nightlies know more about the benefits of crf and only use target size for certain circumstances. I imagine there is an even higher ratio of stable release users who use the target size option. Once you release the next stable version without this feature, you're going to hear a lot more aggravation from users than you ever got for buggy target size experiences.

It won't make the devs bring back target size.

It's very strange to hear a small group of people decide how a software should and should not be used. It sounds codependent to say "I can't see why you want to use this method and so I won't let you use it."

In any case, the developers are in charge of HandBrake, and (this is important) you're only users, not customers. Whether you like it or not, the devs are entitled to make that kind of decision.

As if one day LibreOffice would decide to cut out a Table of Contents feature because if you want to write a thesis, it's better to use LaTeX and not LibreOffice.

If they felt it was in their best interest, they would do it.

Also, HandBrake is neither developed by dozens of developers nor supported by several large companies. HandBrake is developed during people's free time, and the core dev team is less than 10 people. So the project's goals are quite a bit different.

It's none of your business how I choose to enjoy my encodes. It really isn't.

And it's none of your business to decide what features the developers should or shouldn't keep. If HandBrake doesn't have a feature you like, you can attempt work around it by using other features, or use other software that has the feature you want. You can also complain, but the decision's already been taken - it's highly unlikely the feature will come back.

You know, all devs and many regulars don't need the main downloads, the nightly builds or maybe even the forum. Many of us don't really care that much if HandBrake is used by millions vs dozens of people. Luckily for you, the devs (especially s55 and titer) spend a lot of time maintaining the infrastructure so that people who don't know how to compile from source can still use HandBrake. Since HandBrake (unlike LibreOffice*) is 100% not-for-profit, there is no real incentive to do so; as arrogant as it may sound, the truth is they're just being nice.

* Many companies have a vested interest in having a suite like OpenOffice/LibreOffice available on their platform as an alternative or replacement to Microsoft Office; there's a lot of money involved, even if somewhat indirectly.

[match]

but you can literally just make up a little Excel spreadsheet with the math that works out ABV->TFS and plug it in for those times when portability is necessary.

Could someone show me how to make this spreadsheet. I know how to use Excel, so it doesn't need to be dumbed down too much. I tried an online bitrate calculator (from videohelp.com) to produce a 575mb file with Handbrake and my target size was off by 105mb (and yes, I included the audio in my calculation). I aced Calculus 2, so I'm no dummy when it comes to math (or computers). I've never used average bitrate before, so I admit maybe I got something wrong there. Anyway, the calculator told me to use 1375kbps, so I popped that into Handbrake and checked of 2-pass. However, like I said, my target size was too high by 105mb (680mb instead of 575). The one thing I'm confused about is that when I run mediainfo on the file, it says my bitrate is 1667. Is it because mediainfo doesn't display the average bitrate? So where is mediainfo getting the bitrate from if it isn't taking the average...the peak? Handbrake was never off by more than 2 mb when I used the target size.

[randomreuben]

You know, all devs and many regulars don't need the main downloads, the nightly builds or maybe even the forum. Many of us don't really care that much if HandBrake is used by millions vs dozens of people. Luckily for you, the devs (especially s55 and titer) spend a lot of time maintaining the infrastructure so that people who don't know how to compile from source can still use HandBrake. Since HandBrake (unlike LibreOffice*) is 100% not-for-profit, there is no real incentive to do so; as arrogant as it may sound, the truth is they're just being nice.

This is just pointless. Was I being ungrateful about the forums or the nightlies or the hard work you do here? Of course I love the whole deal behind HandBrake. It's all the forums and nightlies and active support that makes HandBrake what it is. Even paid software doesn't take in nearly a tenth of the input you guys take in. HandBrake is one of the best developed/maintained and supported open source projects out there. No doubt about it. What was the point of that paragraph? Save the veiled threats for a John Doe who doesn't appreciate what you do.

I promise you that if you charged me $100 for the privilege of using HandBrake, I would pony up the cash. It's a bargain at that price. I think HandBrake is worth a lot more than that for what I get out of it.

My issue is with the logic behind how "Target File Size" was dropped. I am worried that in the future, if some tightly wound nut decides to complain endlessly, some other useful feature might go out the window. If the decision to drop TFS was made because it really was a horrible piece of code, that's fine. Nothing to worry about there. I support fine tuning HandBrake on its path to being focussed on its mission to produce great x264 encodes. But if the dev team thinks that annoyance by users on a matter of preference ("I'm paranoid. I do all my encodes at RF 0") is best dealt with by lopping off some part of HandBrake, that's worrisome.

That being said, I'm done commenting on this thread. "Finally!" is what you're thinking, no doubt, but I wanted to voice my concern around how TFS was dropped.

[randomreuben]

What you said is also correct and fair. It is the devs' project. They can do what they want with it.

[TedJ]

Wow, I honestly didn't expect this level of dispute over dropping TFS... this thread is easily as bad as some of the xvid/avi [Censored] I've tended to.