A question for convertion

[CompressorPowa]

First of all i apologize for my horrible english.
I have a question to offer, here are the details:
Having a 5.16gb video MKV file, x264, 23.976 fps, 1080p, aac, stereo, 48Hz, audio bitrate 128, no subtitles, no chapters
-using-
Codec x265, fps same as source, variable framerate, constant quality 20, preset very-fast, tune none, profile none + aac stereo 48Hz bitrate 128
How great will be the converted file?
As you may know, at least, also be made in approximate so?
Possible to know if it is worth to convert the file, you have to wait for several hours without having an idea of the possible saving of space in the conversion?
Would not it be better, set the values in the program and have a preview of the size of the output file (also approximate)? So as to see if the settings to be changed or not, or whether it is worthwhile, if only, to do the conversion.
Tnx for effort.

[rollin_eng]

If you want to know what it will look like just convert a small section or chapter and find out.

Could you please post your logs, instructions can be found here:

viewtopic.php?f=6&t=31236

[CompressorPowa]

It's okay, I'm sorry to have caused trouble.
Trying to improve the coding with new settings i noticed that unfortunately the problems are added:
-codec x265 is 1.9 not last 2.1
-the audio codec aac fdk is missing
-the function to convert in a video file -only the audio or only the video- is not present
-It does not exist the possibility to know the size of the output files automatically by the program (even in an approximate way)
calculated for each file to have even just a approximate value of the magnitude is a slow problem
i am forced to change the program
Thanks anyway.

[mduell]

Yea, HB does not intend to address any of those, for a variety of scope, architecture, policy, and political reasons.

[JohnAStebbins]

It's okay, I'm sorry to have caused trouble.
Trying to improve the coding with new settings i noticed that unfortunately the problems are added:
-codec x265 is 1.9 not last 2.1

2.1 is in the nightly builds. We don't backport new codecs to old releases. 2.1 will be in the next handbrake release.

-the audio codec aac fdk is missing

The fdk-aac license is considered incompatible with GPL. You can build HandBrake with this library enabled from source, but we can not distribute a binary with it enabled.

-the function to convert in a video file -only the audio or only the video- is not present

This is not an objective of the HandBrake project. HandBrake is a video encoder.

-It does not exist the possibility to know the size of the output files automatically by the program (even in an approximate way)
calculated for each file to have even just a approximate value of the magnitude is a slow problem

HandBrake once had a "target file size" option. It was so inaccurate that it generated a constant stream of questions on the forums. There was no way to correct the inaccuracies because they are the result of inaccuracies in the source video which we have no control over. So the feature was removed. It is not coming back.

i am forced to change the program
Thanks anyway.

Too bad. So sad. Byebye.

[CompressorPowa]

"2.1 is in the nightly builds. We don't backport new codecs to old releases. 2.1 will be in the next handbrake release."
-good to know, the rest of the beta versions always give unexpected problems.

"The fdk-aac license is considered incompatible with GPL. You can build HandBrake with this library enabled from source, but we can not distribute a binary with it enabled"
-learning how to do it, i could create a customized version of handbrake? It seems complicated but very interesting.

"This is not an objective of the HandBrake project. HandBrake is a video encoder."
-sin, a direct copy function for audio/video would solve many problems for lost time in re-compressions

"HandBrake once had a "target file size" option. It was so inaccurate that it generated a constant stream of questions on the forums. There was no way to correct the inaccuracies because they are the result of inaccuracies in the source video which we have no control over. So the feature was removed. It is not coming back."
-He had the opportunity to decide the output file or gave only as requested by many, only the information? (I repeat, would be fine too rough) than would be the output file? Believe me could definitely use a lot.

"Thanks anyway. Too bad. So sad. Byebye."
-It seems very much a who cares?! XD If you think that mine is an attack on your work you are wrong, I got to test a myriad of programs for the conversion and handbrake has distinguished himself always among the top 3 in any tests, as execution, speed, reliability, quality , etc. etc. etc., (if I have the consent and I can appoint senior programs could even make an article of why and wherefores).
Not at all, i would like many others, it had the characteristics of which i speak, making the program really, more comprehensive and better. Thanks for effort.

[mduell]

"The fdk-aac license is considered incompatible with GPL. You can build HandBrake with this library enabled from source, but we can not distribute a binary with it enabled"
-learning how to do it, i could create a customized version of handbrake? It seems complicated but very interesting.

Yes, it's open source, you can modify it as you see fit.

"This is not an objective of the HandBrake project. HandBrake is a video encoder."
-sin, a direct copy function for audio/video would solve many problems for lost time in re-compressions

There are many other programs intended for that purpose.

"HandBrake once had a "target file size" option. It was so inaccurate that it generated a constant stream of questions on the forums. There was no way to correct the inaccuracies because they are the result of inaccuracies in the source video which we have no control over. So the feature was removed. It is not coming back."
-He had the opportunity to decide the output file or gave only as requested by many, only the information? (I repeat, would be fine too rough) than would be the output file? Believe me could definitely use a lot.

They're both equally wrong. And you can't even predict the output size with the preferred ratecontrol method (quality based).

[CompressorPowa]

"Yes, it's open source, you can modify it as you see fit."
-there is a guide that explains how to do and if you need external programs to package the customized version?

"There are many other programs intended for that purpose"
-remains a pity he did not have this function, the rest handbrake is good program, it would be even better

"They're both equally wrong. And you can't even predict the output size with the preferred ratecontrol method (quality based)."
-I find constant quality is better. I've limited for now the probrem of this missing information with a percentage algorithm (calculated only on a fixed value of quality), although, if it were implemented in the program would be even better

I'm not a technical programmer, i'm a user, i certify things as they appear on-screen, etc, etc, that a codec or program to have "technical improvements" of any kind for me is relative if the final result to the screen not satisfies. The current most striking example are the x265 codec version 1.9, although "on paper" are technically improved, in fact, is worse than earlier for a "micro effect similar to antialiasing" you notice especially on the faces of the characters in the images, with the same settings which does not happen in version 1.8 or 2.1.

[rollin_eng]

The nightly build here has x265 v2.1:

https://handbrake.fr/nightly.php

[mduell]

"Yes, it's open source, you can modify it as you see fit."
-there is a guide that explains how to do and if you need external programs to package the customized version?

https://handbrake.fr/docs/en/latest/dev ... ndows.html

"There are many other programs intended for that purpose"
-remains a pity he did not have this function, the rest handbrake is good program, it would be even better

It requires a fundamentally different architecture to how HB is designed. HB would be in many ways worse if it supported this.

"They're both equally wrong. And you can't even predict the output size with the preferred ratecontrol method (quality based)."
-I find constant quality is better. I've limited for now the probrem of this missing information with a percentage algorithm (calculated only on a fixed value of quality), although, if it were implemented in the program would be even better

The output size of a constant quality encode is inherently unpredictable.

I'm not a technical programmer, i'm a user, i certify things as they appear on-screen, etc, etc, that a codec or program to have "technical improvements" of any kind for me is relative if the final result to the screen not satisfies. The current most striking example are the x265 codec version 1.9, although "on paper" are technically improved, in fact, is worse than earlier for a "micro effect similar to antialiasing" you notice especially on the faces of the characters in the images, with the same settings which does not happen in version 1.8 or 2.1.

So use the nightly with 2.1?

[JohnAStebbins]

i am forced to change the program
Thanks anyway.

Too bad. So sad. Byebye.

-It seems very much a who cares?! XD If you think that mine is an attack on your work you are wrong,

Just to be clear, I didn't interpret your comments as an attack or rude in any way. And I was also not meaning to be rude. My comment was meant to convey that HandBrake isn't the tool for everybody and I don't get bent out of shape when someone decides they need to look elsewhere for their needs.

[CompressorPowa]

"Just to be clear, I didn't interpret your comments as an attack or rude in any way. And I was also not meaning to be rude. My comment was meant to convey that HandBrake isn't the tool for everybody and I don't get bent out of shape when someone decides they need to look elsewhere for their needs."
- n.p XD the problem of chat is that we can not understand "the tone" of the words
I thank all of the valuable information, really appreciated.
I hope that soon exit the new stable version of handbrake, for some new tests.

A further question, according to your opinion, really should compress with: psnr and main10?

[mduell]

PSNR is for benchmarking where PSNR will be used. For real use for playback for humans you don't want PSNR.

[CompressorPowa]

"PSNR is for benchmarking where PSNR will be used. For real use for playback for humans you don't want PSNR."
-The information shows that, the Psrn profile removes some optimizations in the compression (adaptive quant, psy-rd, cutree) allowing further reduction in file size (a pure example of a 4GB file is compressed to 1.8GB and 1.4GB with active Psrn), at the expense of quality although it seems in the tiniest part. Personally i noticed on the bottom parts, one-color gradient, the presence of blocks, this does not always, it would appear most only in images less defined.
Setting Main10 (that does not change the size of the compressed file) it would seem that the colors with similar pixels are defined more clearly (the contours that distinguish the blocks are less obvious).
I also ask you feedback on the merits of Psrn/Main10, whether it is worth it, both, just one, and maybe why?
Main 10 should always be used? As opposed Psrn gave you problems or issues? Personal feedback is very welcome.

[CompressorPowa]

No feedback...

[CompressorPowa]

Sin... I would have preferred there were feedback and opinions.
After many tests in my opinion i can say and confirm that:
-Psnr: Allowing allows to disable some improvements, more compression, but unfortunately at the expense more than anything else, the fluidity in the most bustling scenes (something that perhaps only the most attentive eye perceives).
-Main10: Allows greater color spectrum for each pixel, but if the video was already lacking it, is in this case irrelevant.
I apologize if i had to be in error for my tests and findings.
A further regret is that it seems to reports the x265 codec 2.1 has bugs, we'll see, 1.9 for now seems still the best in this case.

A greeting to all and good compression XD

[mduell]

PSNR is optimized for PSNR benchmarking. If you're PSNR benchmarking you should use it. If not, you shouldn't.

Main10 is useful for 10 bit content. If you don't have 10 bit content, don't bother.