Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Estimated output file size #385

Closed
danielfalsetti opened this issue Nov 7, 2016 · 6 comments
Closed

Estimated output file size #385

danielfalsetti opened this issue Nov 7, 2016 · 6 comments

Comments

@danielfalsetti
Copy link

A suggestion is try to calculate and show the output file size.

Sometimes we try to convert a file and the new file size is bigger then original. Sometime we expect some filesize to any reason.

Thanks
Daniel

@sr55
Copy link
Contributor

sr55 commented Nov 7, 2016

Variations of this have been requested numerous times before. This is not something we are going to implement as it's not possible to do so reliabally enough to be useful. Sorry.

@MajorHeadrush
Copy link

MajorHeadrush commented Jun 4, 2019

obviously the people who wrote the program would be able to come up with the best estimate of the finished file size... any estimate would be greatly appreciated over the way i have been doing it for years now by trial and error... so scotts answer is a little rediculous... its not like anyone would hold them responsible for their estimate being off... just let people know its just the best guess and it may be way off sometimes

@jstebbins
Copy link
Contributor

obviously the people who wrote the program would be able to come up with the best estimate of the finished file size

scott is one of the developers of HandBrake and is in fact currently the senior active member of the dev team.

its not like anyone would hold them responsible for their estimate being off

History indicates you are incorrect in this assumption. The forums are littered with counter examples.

scott is correct in his statement that the value of such a feature would be marginal. It is marginal in multiple senses of the word. The number of people requesting this is relatively small compared to the user base and it's usefulness is questionable given how much file size varies with source material characteristics. Users that don't understand how the number is being computed (which is pretty much all of them) would be mislead by the number until they learned to just ignore it.

The HandBrake dev team is very small. So we purposefully are very selective about what HandBrake does and doesn't do. Every feature requires someone to field support requests that arise from that feature and someone to maintain the code for that feature. So if nobody in our small team has interest in doing these things for some given feature request, it is unlikely to be accepted.

@MajorHeadrush
Copy link

and so what if some idiot did complain??? who cares... the important thing is that the people who write the program do their best to offer a solution... in fact you could offer it as a seperate program with all the weaknesses laid out to the user in full so no one would have any right to complain.., its important to do this... look online... look how many people are asking about this feature... its not like its just me... we tie up our machines doing some serious crunching to get an mkv file to shrink and end up with a bigger file than we started with... this is time consuming and has even over heated my machine if i remember right... anyway if no one over there at handbrake is interested in writing something that will look at the file and match it up with the handbrake settings and make a best guess maybe i can get some of gethubs members to write a program to do it

@MajorHeadrush
Copy link

oh and btw ive found you can go up to 39 cq when youre trying to shrink a stubborn mkv file without getting blocks... and a very good output file... this only worked once for me but it took a 5gb mkv down to 800k with very nice results... i think i started with the very fast 720p setting

@MajorHeadrush
Copy link

my guess is you could take the full range of file types... as in files that have different atributes and run them through the range of settings and use that as a data base to base youre estimates on or even better i dont see why you cant just write it as part of the preview... so when someone does a preview .... lets just say its 10 seconds... ok so lets say the previe is 10 mb lets say the movie is 1000 seconds long... so you would say the output file would be 100 times 10mb which would be 1000 mbs or something like that... i dont see why that wouldnt give a very accurate estimate of the final file size... in fact i think i will try it the next time i try to shrink down something and let you know how it worked out

@HandBrake HandBrake locked as resolved and limited conversation to collaborators Jun 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

No branches or pull requests

5 participants