Disappointed to see target file size go

HandBrake for Windows support
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.
match
Enlightened
Posts: 111
Joined: Sun Mar 14, 2010 5:08 pm

Disappointed to see target file size go

Post by match »

Not that I expect my disappointment to change your mind about removing this feature, but I must say I was pretty surprised to see this feature go. I would think it is a pretty standard feature in any encoding software. Yes, I understand the limitations of using this, and also understand the benefits of constant-rf. But there is also a limitation to constant-rf...unpredictable file size. There are always going to be instances where one wishes to control the size of their files, even if isn't the most efficient use of bits. I can think of one right off the bat. It is nice to be able to fit a t.v. series on a single flash drive for portability. It's much easier to do that if you can predict file size. To get all the episodes to fit onto one flash drive is going to take a heck of a lot of experimenting with different rf values which kind of defeats the purpose of rf anyway.

I always use constant-rf for movies, because there usually isn't a reason that I need to control file size since all my flash drives are 8gb or larger and i've never had a movie go over that size with a reasonable rf value. And I prefer flash drives as opposed to storing/transporting movie files on dvd's. I know the argument...hard drive space is cheap. But people still use other types of removable media that may be limited by size..and may even want to limit a movie to fit onto a small flash drive or dvd, instead of a limitless hard drive.

The reason that I saw for this feature being removed was "This feature is being mis-used, doesn't really work well and is generally causing far too much confusion." First, it has worked very well for me for quite a while now. Second, "being mis-used"...This isn't some kind of illicit drug or anything. Shouldn't it be up to the user to decide how they want to use a feature and not be told they are mis-using it. There are actual legitimate reasons to properly "use" this feature. And third, if it's causing confusion for someone, then shame on them. Don't let them ruin it for the rest of us and limit the applications of your program. If they are playing with such a sophisticated piece of software with various different features such as Handbrake, they ought to know better. The "denoise filter" isn't being dropped from the program. I'm sure people "mis-use" that feature...removing detail from an otherwise sharper picture. People may de-interlace something that isn't interlaced to begin with. We don't drop that feature because some 'diot misused it or doesn't understand it. Why include it at all when there is a decomb feature that is "smarter and superior" in the same way that rf is over target size. Because people use software for different reasons and appreciate the flexibility that is there.

I know there is a movement by the developers to gear people towards using constant-rf. If it's education of the users that you are really after (not wanting them to "misuse" something or cause themselves confusion), why can't you just put a sticky note up stating all the wonderful benefits of rf vs target size (which actually isn't such an evil thing) and then ignore any posts that are causing you grief. Kind of like posts that don't give activity logs. Then we all win.

Whether you cut this feature or not, people will continue to try to control file size in certain cases. It already takes hours to encode a video...now they will have to go through that 2,3,4 times just to find the maximum rf they can use to fit their target size. I don't expect my lone opinion to change anything, but I thought I should throw in my 2 cents since I can't imagine I'm the only one that will suffer loss from this omission. I will continue to download the nightlies, and any future versions of Handbrake for most of my encoding using rf. But I will have to continue to use 0.95 for certain cases, and thus miss out on all the new goodness from the awesome gift that is Handbrake, that will come down in future development.
hunterk
Bright Spark User
Posts: 179
Joined: Tue Jun 03, 2008 2:27 pm

Re: Disappointed to see target file size go

Post by hunterk »

I also use(d) target file size quite a bit and hate to see it go, but average bitrate is still going to be around, right? I know it's an added hassle to divide your desired filesize by the time of the video to get the required average bitrate, but at least it's an option.
Deleted User 11865

Re: Disappointed to see target file size go

Post by Deleted User 11865 »

Target size is gone because it wasn't always reliable. There are no plans to remove average bitrate.
match
Enlightened
Posts: 111
Joined: Sun Mar 14, 2010 5:08 pm

Re: Disappointed to see target file size go

Post by match »

Just curious what you mean by reliable? I'm assuming you mean something other than the size wouldn't be reliable. I've never had it not hit my desired size. Was something else going on? And I'm not trying to be "snarky" with this next statement, but truly curious...do you think the other encoding programs that are out there are also not reliable in the same way as Handbrake's code was with target size? Is it like some fundamental problem with x264?

Also curious...are there plans to also remove this from the Mac version...or is this something that has already been removed from the Mac version?
match
Enlightened
Posts: 111
Joined: Sun Mar 14, 2010 5:08 pm

Re: Disappointed to see target file size go

Post by match »

hunterk wrote:I also use(d) target file size quite a bit and hate to see it go, but average bit-rate is still going to be around, right? I know it's an added hassle to divide your desired filesize by the time of the video to get the required average bit-rate, but at least it's an option.
Hunterk: Is there really an equation to get file size by using average bit-rate and time of video in an equation? Can you tell me exactly how to do it...maybe give me an example. I can't imagine it is really that easy, or it wouldn't have been removed from Handbrake. If the average bit-rate option works properly, then it would be extremely simple to translate your equation into the programming code. Something else must be going on there.
Deleted User 11865

Re: Disappointed to see target file size go

Post by Deleted User 11865 »

No, it's that easy. Of course, that assumes HandBrake always gets the duration and audio bitrates right, which is not the case. It often worked reasonably well, but not always.
hunterk
Bright Spark User
Posts: 179
Joined: Tue Jun 03, 2008 2:27 pm

Re: Disappointed to see target file size go

Post by hunterk »

@match
The general equation for filesize is:
size = bitrate x time
solved for bitrate, we have:
bitrate = size (in kilobits) / time (in seconds) <-- there are 8 bits in a byte, so we need to multiply our size in bytes by 8 to get it in bits

So, for a standard def, 22-min TV show at a desired final size of 175 MB:
bitrate = (175 x 1,000 x 8 ) / (22 x 60)

bitrate = (1,400,000) / (1320)
bitrate = ~1060 kbps

Now, this is for the whole thing, audio included, so we'll want to subtract the audio bitrate from this number (I've used 192 kbps as an example, but YMMV):
bitrate = 1060 - 192
bitrate = ~868 kbps

This is an average, so if a maximum size is make-it-or-break-it (burning to a CD or the flash drive example you gave), you'll want to round down a bit to be safe.

If I've messed this up anywhere, anyone is welcome to correct me ;)
Deleted User 11865

Re: Disappointed to see target file size go

Post by Deleted User 11865 »

It depends on your definition of MB. If you mean a binary MB (sometimes know as MiB), then an additional conversion is required.

overall bitrate = size (in MiB) -> convert to KiB -> convert to KB (base 10) -> convert to Kb / time (in seconds)

overall bitrate = size (MiB) x 1024 x (1024/1000) x 8 / time (seconds)

Then you subtract the sum of audio bitrates (and maybe just a few Kbps for container overhead).

Your example becomes:

overall bitrate = 175 x 1024 x (1024/1000) x 8 / 1320 = ~1112 Kbps

A CD is 700 MB in base 2 ("MiB"), not in base 10.
Note that a DVD is 4.7 GB in base 10 (so just a bit under 4.4 GB in base 2).
match
Enlightened
Posts: 111
Joined: Sun Mar 14, 2010 5:08 pm

Re: Disappointed to see target file size go

Post by match »

hmmm...sounds a little complicated to get it right. How do you figure out the bitrate of your audio when it is AC3...run media info on one of the vob's?

I just thought of something...if the gui is just an interface for the command-line version, could you use a target size with that. Just because the gui is changed, it doesn't necessarily mean the command line version is changed too, correct? I've never used the command-line version so I would need some help if anyone doesn't mind...or if you could point me in the right direction to read up on it. Or can you just somehow use the query editor?

This is the query that's generated if I use 0.95 with the target file size enabled:

Code: Select all

 -i "B:\DVD IMAGES\Quantum Leap - Season 4 Disc 2\QUANTUM_LEAP\VIDEO_TS" -t 5 -c 1-17 -o "A:\Ripped DVDs\QUANTUM_LEAP-5.mkv"  -f mkv --detelecine --decomb -w 720 --loose-anamorphic  -e x264 -S 550 -2  -r 23.976 -a 1 -E copy:ac3 -6 auto -R Auto -B auto -D 0.0 --markers="C:\Users\Chornomaz\AppData\Local\Temp\QUANTUM_LEAP-5-5-chapters.csv" -x b-adapt=2:rc-lookahead=50:me=umh:subq=9:merange=64:direct=auto:trellis=2:analyse=all:ref=8:bframes=8 --verbose=1
This is the query that's generated if I use the latest nightly, using 18.5 rf.

Code: Select all

 -i "B:\DVD IMAGES\Quantum Leap - Season 4 Disc 2\QUANTUM_LEAP\VIDEO_TS" -t 5 -c 1-17 -o "A:\Ripped DVDs\QUANTUM_LEAP-5.mkv"  -f mkv --detelecine --decomb -w 720 --loose-anamorphic  -e x264 -q 18.5 -2  -r 23.976 -a 1 -E copy:ac3 -6 auto -R Auto -B auto -D 0.0 --markers="C:\Users\Chornomaz\AppData\Local\Temp\QUANTUM_LEAP-5-5-chapters.csv" -x b-adapt=2:rc-lookahead=50:me=umh:subq=9:merange=64:direct=auto:trellis=2:analyse=all:ref=8:bframes=8 --verbose=1
Instead of using the CLI, could I even just use the gui, but replace "-q 18.5" with "-S 550" to get my target size? Or will this not work now that the option has been removed. I guess...was the option just hidden from the gui, or was something eliminated even deeper?
User avatar
s55
HandBrake Team
Posts: 10350
Joined: Sun Dec 24, 2006 1:05 pm

Re: Disappointed to see target file size go

Post by s55 »

Fwiw,

Target filesize doesn't work properly with VFR, Occasionally had problems with CFR content, got triped up by mis-reported audio bitrates, durations of tracks etc and various other problems. (Hence numerous complaints about it not working properly).
There isn't a simple fix for it, and zero developer interest, nor have there been any patches submitted for any of the many fundamental problems with it. It's just confusing folks and annoying them when they end up encoding a bunch of stuff and it all needs to be done again.

As has been started, you can simply use Average bit-rate to achieve the same effect. (and yes, it's not going anyway).
skoenig
Posts: 2
Joined: Tue Feb 22, 2011 3:20 am

Re: Disappointed to see target file size go

Post by skoenig »

I liked Target Size too...despite it's few failings it's a lot easier and simpler to say you want a 2.5GB mp4 (even if it comes out a 2.65 or 2.4) then to work backwards from the time. I'd rather have it back too and continue to accept that on some occasions it going to get it wrong and on very rare occasions it's going to get it very wrong.

It sounds to me like it's mainly going wrong with VFR - I don't know how common it is to use that but I suspect if you use VPR you'll understand that this is likely to mess up Target Size calculations. So is it at all possible to re-enable it providing VFR/Peak FR (is that the same?) is not ticked ?

Regardless I would have thought a little note about it being an approximate target size based off a best guess would be sufficient (which the documentation does state but the GUI does not explicitly)... honestly the utility to me and what seems like others for a such a useful, human like feature, is worth it the occasional error (which I've never noticed by the way).

Please reconsider it's removal?

Regards

Steph
User avatar
s55
HandBrake Team
Posts: 10350
Joined: Sun Dec 24, 2006 1:05 pm

Re: Disappointed to see target file size go

Post by s55 »

Instead of using the CLI, could I even just use the gui, but replace "-q 18.5" with "-S 550" to get my target size? Or will this not work now that the option has been removed. I guess...was the option just hidden from the gui, or was something eliminated even deeper?
It'll work for the moment.
Deleted User 11865

Re: Disappointed to see target file size go

Post by Deleted User 11865 »

TBH HandBrake has an interjob and x264 now features full VFR-aware ratecontrol, so as long as you're using 2-pass I'm not sure VFR is much of an issue anymore.

Loose ABR audio and incorrect duration detection would probably be more common.
Sheppard
Posts: 3
Joined: Wed Sep 09, 2009 6:34 am

Re: Disappointed to see target file size go

Post by Sheppard »

Well thats dissappointing all my encodes are done by target file size and out of thousands of encodes ive never had any problems with it.

Looks like ill be finding some other software then.
match
Enlightened
Posts: 111
Joined: Sun Mar 14, 2010 5:08 pm

Re: Disappointed to see target file size go

Post by match »

Sheppard, I imagine there's a large chunk (I wouldn't doubt a 1/4 of the users) that are being alienated by the removal of this feature. I too have never had any problems with it over 100's of encodes. I hate to go to another program. I love Handbrake and have had so much success with creating great encodes with it. It's easy to use, yet powerful at the same time. I may post in the General section to ask this question...but since this thread kind of lends itself to the topic...do you have any suggestions of other software that can produce the same quality rips as Handbrake. Most of these encoding programs are just a window into x264, correct? Or is it not that simple? Is there any way I could just drop the generated query string into another program and then tick off target file size? So far my research leads me to megui. It seem powerful and in pretty active development like Handbrake. However, I really don't feel like learning another program, especially if it's not going to produce the same quality rips as Handbrake. Dropping a query string into it would be really nice if possible.
hunterk
Bright Spark User
Posts: 179
Joined: Tue Jun 03, 2008 2:27 pm

Re: Disappointed to see target file size go

Post by hunterk »

MeGUI, AVISynth and FFmpeg are all good alternatives and generally have access to the exact same libraries and algorithms as HandBrake (minus the HB devs' patches, custom filters and settings). However, these programs all have a much steeper learning curve than HandBrake and lack HB's fantastic cross-platform consistency. They also have an everything-including-the-kitchen-sink approach to options and filters (in contrast to the HB devs' cutting of unused or inconsistent features, such as target filesize :wink: ), which can necessitate tedious testing and tweaking to find settings that work for you.
thompson
Bright Spark User
Posts: 356
Joined: Sat Dec 12, 2009 8:04 pm

Re: Disappointed to see target file size go

Post by thompson »

Reading this thread is how I imagined conversations went in various taverns when the motorized vehicle was introduced—"Well, my horse and buggy has served me well for thousands of trips, why do I need a 'car'?"

Can anyone articulate an actual advantage that target file size provides over constant quality? It seems like most people are just more familiar with it and are afraid of change.
randomreuben
Veteran User
Posts: 468
Joined: Mon Nov 02, 2009 2:18 pm

Re: Disappointed to see target file size go

Post by randomreuben »

@thompson,

Look. It's not like users are begging the devs to reintroduce Xvid (that would be the correct horse and buggy analogy). Let's say you have a 512 MB USB stick and you'd like to have HandBrake make up an encode to fit in it. Sure, you could do it with a little bit of math and a target ABR, but for sheer convenience, this sort of precalculated encode target size is great!

It's not like the users are saying that target encodes are the best way to encode a video. Between CRF with ABR, CRF wins every time given that the CRF is set low enough. It filled a need for them in re getting an encode at a specified size. "I need something at or near 2 GB without breaking out my trusty HP 42S and now I don't have it."

You're really missing the whole point of this thread. It's NOT CRF vs. Target Size. It's the convenience that goes along with being able to get a target filesize without calculating for it.

The logic that assumes that the devs should remove everything that isn't CRF or ABR is poorly thought out. If the devs were (and I don't think they are) so concerned about video quality being forced onto the end user, they would have disabled CRF values like RF 30 and higher. Clearly a CRF 35 value is going to be horrible compared to a 700 MB target size for a DVD source.

A bunch of users who got their panties in a knot over setting 712 MB as a target filesize and then complaining when HandBrake produced a 689 MB file is really what got the devs to kick this feature out. They just didn't want to put up with more whiney posts from end users who couldn't take things easy over this.

I'm not saying that the devs have to reenable target filesize. I don't use it and I don't care for it. But what gets my goat is this weird inability on your part to see that setting a target file size sometimes is just plain handy.
User avatar
JohnAStebbins
HandBrake Team
Posts: 5712
Joined: Sat Feb 09, 2008 7:21 pm

Re: Disappointed to see target file size go

Post by JohnAStebbins »

It's not like the users are saying that target encodes are the best way to encode a video.
Actually, numerous users have said this. It was a session with one particular user that was doing this that pushed me over the edge. I had been a hold-out on removing target file size for a long time. The other devs were ready to remove it ages ago. It is remarkable how many people are mis-using this feature.
randomreuben
Veteran User
Posts: 468
Joined: Mon Nov 02, 2009 2:18 pm

Re: Disappointed to see target file size go

Post by randomreuben »

Again, like I was trying to say, a case of some idiot end users' reactions being the issue here. It's not the "target filesize" option that's the problem. It's the [Censored] and whining and FUD created by some idiot's over-reaction to the setting that's causing the devs to pull it.
skoenig
Posts: 2
Joined: Tue Feb 22, 2011 3:20 am

Re: Disappointed to see target file size go

Post by skoenig »

@thompson

I disagree with your claim that it's like going from horse drawn cart to vehicle. The concepts of constant quality (and RF) or avg bitrate (and the calculations necessary to actually use it) put both beyond the realm of the average user. Setting a target size equal to the sizes users see in their folders or files from others is a lot easier than pulling out a calculator and thinking about bits and bytes and # of seconds... seriously, I can do it but there's no way my dad would do it.

To quote randomreuben (who also doesn't want to do a bunch of extra work simply to get a rough target size).
The logic that assumes that the devs should remove everything that isn't CRF or ABR is poorly thought out. If the devs were (and I don't think they are) so concerned about video quality being forced onto the end user, they would have disabled CRF values like RF 30 and higher. Clearly a CRF 35 value is going to be horrible compared to a 700 MB target size for a DVD source.
Yeah I get that but seriously imagine if a non-experienced user saw that: CFR, ABR? 35, 20 etc... what?

and the very helpful hunterk
So, for a standard def, 22-min TV show at a desired final size of 175 MB:
bitrate = (175 x 1,000 x 8 ) / (22 x 60)

bitrate = (1,400,000) / (1320)
bitrate = ~1060 kbps

Now, this is for the whole thing, audio included, so we'll want to subtract the audio bitrate from this number (I've used 192 kbps as an example, but YMMV):
bitrate = 1060 - 192
bitrate = ~868 kbps
Again I get that but seriously? I've seen regular users get confused between kbps and kBps ... we're all forgetting how little of this stuff regular people actually know about.

Instead of simply:
How big do you want the file? We'll try to get close.
In this sense it's like moving from an automatic car to manual car when you have no idea what a clutch, gear ratios or gearboxes are. Simplifying things and making things easier is generally progress. In actual fact I'd say thompson's analogy is backwards.

As a compromise, why not put a simple calculator right there in the lower right of the Video dialog box which takes to source video length, an entered target size and displays a 'suggested avg bitrate'...users can then copy that bit rate into the field above. People that seem to give themselves a headache

This way HB becomes just a little bit more accessible instead of a little bit less accessible.

~ Steph
User avatar
JohnAStebbins
HandBrake Team
Posts: 5712
Joined: Sat Feb 09, 2008 7:21 pm

Re: Disappointed to see target file size go

Post by JohnAStebbins »

Setting a target size equal to the sizes users see in their folders or files from others is a lot easier than pulling out a calculator and thinking about bits and bytes and # of seconds... seriously, I can do it but there's no way my dad would do it.
And this thinking is exactly why it was removed. This is an absolutely awful way to determine the quality of your output. Using constant quality mode, one HD movie that is approx. 2hrs long will come out to about 4GB in size, while another, also 2hrs, will come out to 24GB in size. These are real examples. I have such movies. Using the same size as what you see other files are will result in *drastically* different quality.
thompson
Bright Spark User
Posts: 356
Joined: Sat Dec 12, 2009 8:04 pm

Re: Disappointed to see target file size go

Post by thompson »

I am particularly fond of the person in some thread who said he consulted a "chart" that told him what the target size should be based upon what "type" of movie it was.

What's easier for the end user: trying to figure out what target file size is going to be best for each and every encode, based upon some combination of factors unique to each movie? Or merely telling the end user to use RF21 for good file sizes, and RF18 for almost transparent encodes, and then let the encoder itself determine how many bits are needed for that quality?

I'll say it again, just because this is how it was done doesn't mean that it's the right way to do it.
match
Enlightened
Posts: 111
Joined: Sun Mar 14, 2010 5:08 pm

Re: Disappointed to see target file size go

Post by match »

JohnAStebbins wrote:And this thinking is exactly why it was removed. This is an absolutely awful way to determine the quality of your output. Using constant quality mode, one HD movie that is approx. 2hrs long will come out to about 4GB in size, while another, also 2hrs, will come out to 24GB in size. These are real examples. I have such movies. Using the same size as what you see other files are will result in *drastically* different quality.
I don't think the point of this thread is being understood. Like someone said earlier, this isn't a crf vs target size. It's about wanting to use one option over the other in certain circumstances. The original post laid out a couple examples. It's hard to believe that it was really removed because the devs were so worried about our encoding health, feeling that it was "misused"...like we were abusing narcotics or something. Or like someone said, RF 51 would be taken out because it consistently turns out crappy encodes. Or RF 0 should be taken out because some people think that it means 100% quality. How many times has that feature been abused?...so let's take out CRF. But wait...when you choose RF 0, a warning comes up, saying "RF0 is x264's lossless mode. This will result in a very large output which may not be compatible with your playback software." Why can't a similar warning be displayed when a user chooses target size. It's another case of a few users ruining it for the rest of us.

Guys...if the devs don't see a need for this feature, then it simply aint coming back. We can scream till we're blue in the face, but ultimately, you can't fight city hall. I haven't been around forever...but I've never seen a feature return after it's removed. We could get a petition filled, but I don't think it would help. It's a shame, because there were no doubt thousands and thousands of encodes done using this feature with great success (100's by me alone without one single problem)...and then a small fraction came to these boards to complain. That, along with the fact that the devs must not put their encodes on removable media that can sometimes have limited space...i fear led to the demise of an integral encoding feature. I don't know of any other encoding software that doesn't include this feature...unfortunately they aren't as easy to use : (
User avatar
JohnAStebbins
HandBrake Team
Posts: 5712
Joined: Sat Feb 09, 2008 7:21 pm

Re: Disappointed to see target file size go

Post by JohnAStebbins »

It's hard to believe that it was really removed because the devs were so worried about our encoding health, feeling that it was "misused"...like we were abusing narcotics or something.
Of coarse this is only part of the reason, but believe it, this was the largest factor for myself. Not the part about your "encoding health". I don't care as much about your encoding health as I do about the spread of bad advice and FUD on the forums. This is a large factor because it creates support issues that absorb time and frustrate the developers and other forum contributors.
Or like someone said, RF 51 would be taken out because it consistently turns out crappy encodes.
This has been considered. Limiting the RF scale to values that make sense has been put on the table several times. The difference here is that I don't recall ever getting a support request from a user that abused RF 51.
Or RF 0 should be taken out because some people think that it means 100% quality.
This was a very big problem. We eliminated the 0-100% scale for this very reason. We added a tooltip that educates the user about RF 0 and lossless mode. We added text to the displayed RF value when 0 is reached that emphasizes that they have selected lossless mode. By doing all these things, we are able to reduce the cost of this feature to a tolerable level. It is still a problem, but less bothersome now.

Let me put this another way. Every feature has a cost. When the cost of a feature is above some threshold, it gets considered for removal or a rework to reduce it's cost. Target file size has been in this consideration phase for at least a couple years. The cost of target file size is high in user support and high in maintenance. The user support issues come in 2 major varieties. Failure of the feature to perform as expected, and abuse of the feature for purposes it was not intended for. There is no way to fix some of the problems that the target file size feature has, so this cost is not going to be reduced. There is an endless supply of users who abuse the feature. And most do not understand their error even after explaining in great detail.
Why can't a similar warning be displayed when a user chooses target size.
If the collective efforts of the forum can't persuade these folks, a warning dialog is going to do nothing but irritate them.

What do we get for our investment in this feature? None of the developers use it, so no return on investment. The math is pretty simple.
Guys...if the devs don't see a need for this feature, then it simply aint coming back.
It's not that we don't see the need. It's that the marginal benefit outweighs the hassle factor of the feature. It really comes down to basic economics. We have limited time and patience. The core dev team isn't very large.
Locked