Accurate target bitrates

Archive of historical feature requests.
Please use the GitHub link above to report issues.
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.

*******************************
Post Reply
ExDeus
Posts: 43
Joined: Mon Mar 02, 2009 7:13 am

Accurate target bitrates

Post by ExDeus »

To not hijack another's topic, I'm breaking this off from another thread.

http://forum.handbrake.fr/viewtopic.php?p=52290#p52290
jbrbrake wrote:As far as the bitrate thing....you're using same as source fps and detelecine. When fps varies you of course can't accurately predict the framerate before you start, so the FPS handed off to x264 is an estimate. There is a patch in the dev forum to pass through this info on second passes to correct the bitrate for the actual fps, but I haven't gotten around to testing it and prepping it for checking into the SVN since, really, HB is transitioning more and more to single-pass quality encodes instead of choosing arbitrary bitrates.
http://forum.handbrake.fr/viewtopic.php?p=52351#p52351
ExDeus wrote:Arbitrary bitrates will still often be necessary as long as storage media have specific constraints. I don't want to keep everything on a spinning disk, so I burn to DVD (spin on demand). I will always be targeting 1/4-DVD (1.07-1.09GB) per episode when backing up 1hr TV shows. That's a common sweet spot to balance quality and size. A look at the encodes out in the wild --- torrents, newsgroups, etc. --- shows that 1/2- or 1-CD encodes are common for standard def encodes, and 1/4- or 1/2-DVD encodes are common for high def.

You're the expert on where HB itself is heading, I'm just saying community demand is still very much alive for target bitrates. Anything you can do to support them will always be appreciated.
I'm hoping to establish some amount of demand for encodes with targeted bitrates / file size. In my situation, I am always targeting a bitrate to fit a particular storage medium, and from what I see in the wild, so are a lot of others.
User avatar
s55
HandBrake Team
Posts: 10350
Joined: Sun Dec 24, 2006 1:05 pm

Re: Accurate target bitrates

Post by s55 »

You should note development is not demand driven. It doesn't matter how many people want a particular feature, if there is no developer interest, it's unlikely to happen.
ExDeus
Posts: 43
Joined: Mon Mar 02, 2009 7:13 am

Re: Accurate target bitrates

Post by ExDeus »

I totally understand - I mention in my post that it is simply a matter of appreciation for anything that can be done.

I'm new here, so I don't know what the motivation is for HB to move toward CRF encodes, as jbrbrake mentioned.

Since I was inadvertently hijacking the other thread, when it seemed jbrbrake might have something to say on it, I decided to move it to a new thread and see what responses it might gather.
jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Re: Accurate target bitrates

Post by jbrjake »

Um, huh?

You started a new thread because you don't like how I triage submitted patches?

Like I told you, I haven't gotten to it yet because it's low priority. ABR encoding is not a focus of the app because we the developers care about video quality. Did I ever say the patch was not going in? What sense would that make after I shepherded shaya through the process of coding it?
ExDeus
Posts: 43
Joined: Mon Mar 02, 2009 7:13 am

Re: Accurate target bitrates

Post by ExDeus »

I started another thread because you seemed like you had something to say and didn't want to derail the other thread.

You said the patch hasn't gone in because you hadn't gotten around to it, because HB is going in a different direction. I have no idea when or if that means the patch will be implemented.

I didn't say a word about how you triage patches. I don't have the overview to weigh the outstanding issues/requests, and you're managing the project, so it wouldn't matter what I see or want, anyway.

But that doesn't mean I shouldn't express an opinion. I am making a request: I would like you to implement the patch; I would like it implemented sooner rather than later.

Regardless of what I want, it seems logical that everyone involved in the project would like the software to be useful beyond for themselves, for as many people as possible. This is a patch that increases HB's utility for a much wider audience. Regardless of what I say, I'm hoping that fact influences you even a minuscule amount.
jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Re: Accurate target bitrates

Post by jbrjake »

ExDeus wrote:You said the patch hasn't gone in because you hadn't gotten around to it, because HB is going in a different direction. I have no idea when or if that means the patch will be implemented.
If the patch was refused I would have said so. Did I say it was refused? No, of course I didn't. I said I haven't gotten to it.
I didn't say a word about how you triage patches.
I would like you to implement the patch; I would like it implemented sooner rather than later.
HandBrake is an open source project.

There is a patch available to fix a minor issue.

Why does it matter when the patch goes into the official repo? Why can you not apply it yourself if it is so important to you? What, exactly, are you so concerned about?

As far as I can tell, *all* you are doing here is critiquing the way patches are triaged. It's certainly not like the patch going into the repo has any impact on whether or not you can benefit from it.
Regardless of what I want, it seems logical that everyone involved in the project would like the software to be useful beyond for themselves, for as many people as possible. This is a patch that increases HB's utility for a much wider audience. Regardless of what I say, I'm hoping that fact influences you even a minuscule amount.
...
Really?
...sigh...
http://trac.handbrake.fr/wiki/IsIsnt#Ha ... OpenSource
rhester wrote:Open source software is exactly what it sounds like: It's software written by a (usually small) group of highly-dedicated people that solved particular problems they themselves had and thought others might find useful as well. Like most things that are free, it comes with no warranty: If it does what you want, that's great - that's exactly why it was offered to you. If not, you have the freedom of choice to either modify it to suit your desires or find another software package that more closely meets your needs.

As I stated in another thread (and alluded to again here), the features you find in any open source software package are there because at least one programmer needed them and implemented them to meet their needs (more forward-thinking programmers often at least attempt to make them flexible enough to work for others with similar needs as well).

I am aware of no open source software either currently or previously available that catered to the needs, whims, or desires of end-users. That isn't what it's about.
This patch is going to go in for the same reason I told shaya it would go in when he wrote it: because despite two-pass encoding to an arbitrary bitrate being a niche feature that we are phasing out since it makes no sense in the modern world of 1TB harddrives and makes anyone who cares about video quality cry, the underlying tech necessary to do this (communicating information between sequentially processed jobs within a single instance of libhb) will be useful for other things like DABR encoding and pre-processing passes for video filters.
ExDeus
Posts: 43
Joined: Mon Mar 02, 2009 7:13 am

Re: Accurate target bitrates

Post by ExDeus »

jbrjake wrote:
ExDeus wrote:Regardless of what I want, it seems logical that everyone involved in the project would like the software to be useful beyond for themselves, for as many people as possible. This is a patch that increases HB's utility for a much wider audience. Regardless of what I say, I'm hoping that fact influences you even a minuscule amount.
...
Really?
...sigh...
I didn't just fall off the turnip truck. One man's/group's manifesto to ward off overreaching users does not constitute universal rule, and making a request to apply a patch that's already been implemented does not constitute "overreaching". You want to stomp around your playground hurling sarcasm at people, that's your prerogative. Each developer has their own balance of selfish and altruistic motivation. I believe I am among a set of developers that tips towards the altruism end of the scale. Things start for oneself, but they grow to consider others. I don't believe you'd be having a discussion or have a forum at all if that minuscule influence I mentioned doesn't impact you.

Yes - things get implemented because a developer wants it implemented. I allowed for that in my statement above. Sometimes developers want things implemented because they appreciate the utility it will provide to others. It was not unreasonable for me to attempt to explain the utility something would provide to me and many others.
jbrjake wrote:...despite two-pass encoding to an arbitrary bitrate being a niche feature that we are phasing out since it makes no sense in the modern world of 1TB harddrives and makes anyone who cares about video quality cry...
You decide the relative importance of features in HB, but none of that is true on its own. That's your viewpoint, which is not singularly valid. 2-pass encoding is neither a niche or nonsensical feature, nor is it for people that don't care about quality. But we're not really debating the relative merits of ABR vs. CRF, so I don't see the point in restating the points which you've already ignored.

When you get around to applying the patch, I will be grateful. In the meantime, I will attempt to compile my own build. If someone could tell me where to find the patch, that would be helpful.

Thanks.
Post Reply