Would it be possible to include in the software some sort of bitrate calculator perhaps? The main use of this, i think, would be to achieve high quality encodes that do not over-do the file size.
There are probably a few different ways this could be used but what would most interest me (and hopefully others ) would be a way to calculate the bitrate that would be the same visual quality as the source but encoded at a managable size (unlike 100% encodes). Some movies will look perfect at a certain bitrate and anything beyond that is just wasted memory. A way to find that magic bitrate would be very useful in creating great encodes at a respectable file size,
Bitrate Calculator?
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.
*******************************
*******************************
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.
*******************************
There's only 1 way to get "same visual quality as the source" and you don't need a bitrate calculator to do it: set the video quality to 100% and watch the filesize explode.
If you want to try a variety of bitrates, queue up a bunch of jobs for just the first chapter of the movie at different bitrates or quality settings.
If you want to try a variety of bitrates, queue up a bunch of jobs for just the first chapter of the movie at different bitrates or quality settings.
Re: Bitrate Calculator?
Will you provide the mystical formula for deriving this magic bitrate, or do you think we have one hidden away and just don't put it in the app to frustrate you?valmaer wrote:A way to find that magic bitrate would be very useful in creating great encodes at a respectable file size,
And if it boils down to some lame bits per pixel calculation, don't bother. Those are so misleading as to be useless, especially with h.264, especially when codec settings fluctuate.
Re: Bitrate Calculator?
Having a bad day or something? If you respond to everyone's requests with such uncivil sarcasm then I don't see how you have such a userbase.jbrjake wrote:Will you provide the mystical formula for deriving this magic bitrate, or do you think we have one hidden away and just don't put it in the app to frustrate you?valmaer wrote:A way to find that magic bitrate would be very useful in creating great encodes at a respectable file size,
You'll probably ban me now or something but it was worth pointing out.
Re: Bitrate Calculator?
Maybe he was. What you need to realize is that the devs are inundated on a regular basis with "ideas" from people who really have no idea what they are asking for.valmaer wrote:Having a bad day or something? If you respond to everyone's requests with such uncivil sarcasm then I don't see how you have such a userbase.jbrjake wrote:Will you provide the mystical formula for deriving this magic bitrate, or do you think we have one hidden away and just don't put it in the app to frustrate you?valmaer wrote:A way to find that magic bitrate would be very useful in creating great encodes at a respectable file size,
You'll probably ban me now or something but it was worth pointing out.
Now, I'm just a mod here on the forums and not a dev. I have no idea what it takes to do any of this stuff and frankly I never intend to learn. If I had the time to learn I would pitch in with a group like these guys who like doing this stuff because they want to, not because they get paid to.
Unfortunately they get "rewarded" for their free time and effort by people coming in and asking for HB to do everything for everybody and then not being happy when they don't get it. Do they get grumpy? Sure, I don't blame them. I get grumpy just mod'ing this forum some times.
This idea has been discussed ad-nauseam before, and the bottom line seems to be that there is no real reason for it, at least not in the devs collective minds. If you want to provide the code for one however, I'm sure they would be more than happy to accept it and include it.
Heuristic approach
I think this request could actually be "solved" in a few hours if we users got together and collaborated on a heuristic approach.
Pick a movie we all have. Yes different versions exist, oh well.
Pick a portion or the whole thing. Whatever.
Pick a codec.
Pick 1-pass or two.
Select your ASSIGNED bitrate.
Measure resulting file size. Report that file size back to group.
Repeat until we have a scatterplot of file size by bitrate. Fit curve to data.
Repeat with another movie. See how well curve fits.
Publish general guidelines to newbies. /end solution
Zero programming required. I'll happily run the regressions.
Volunteers?
Pick a movie we all have. Yes different versions exist, oh well.
Pick a portion or the whole thing. Whatever.
Pick a codec.
Pick 1-pass or two.
Select your ASSIGNED bitrate.
Measure resulting file size. Report that file size back to group.
Repeat until we have a scatterplot of file size by bitrate. Fit curve to data.
Repeat with another movie. See how well curve fits.
Publish general guidelines to newbies. /end solution
Zero programming required. I'll happily run the regressions.
Volunteers?
Re: Heuristic approach
The problem is deciding on whether the quality of the resultant file is equal to the quality of the source material.tc60045 wrote:I think this request could actually be "solved" in a few hours if we users got together and collaborated on a heuristic approach.
Pick a movie we all have. Yes different versions exist, oh well.
Pick a portion or the whole thing. Whatever.
Pick a codec.
Pick 1-pass or two.
Select your ASSIGNED bitrate.
Measure resulting file size. Report that file size back to group.
Repeat until we have a scatterplot of file size by bitrate. Fit curve to data.
Repeat with another movie. See how well curve fits.
Publish general guidelines to newbies. /end solution
Zero programming required. I'll happily run the regressions.
Volunteers?
Cheers, Ed.