The more I think about it, the more I’m starting to get convinced VEA isn’t ideally suited for ‘end-result’ streams. It does lossless fine (TIFF, PNG, 4:4:4 Predictive h264, ProRes). Yet its end-stream options are limited; like only being able to set CRF (Constant Rate Factor) for H264.
So, I was suggesting that if VEA wants to compete in the end-stream market, as it were, we’d need a more fine-grained control over the output compression, like for H264. Otherwise we’re stuck with a superb upscaler, but with a suboptimal end-stream encoding scheme.
Like I said, though, maybe I was asking too much of VEA, and I should be content with a preprocessor that delivers flawless, lossless output, and then take it from there, in a final pass with an encoder and settings of my choice.
You said: " Yet its end-stream options are limited; like only being able to set CRF (Constant Rate Factor) for H264."
Where is that option in the user interface of the program. I see something mysterious called compression factor with no measurement unit , but I don’t see CRF (Constant Rate Factor).
“But why? Other programs offer ability to calculate output bitrate and output size right away? Seems like Topaz needs to implement that as well. Converting to ProRes is not really good option, because a) its freaking huge file size and I can’t tell how large it is, because there is no way to know until you get a message, run out of disk space.”
TIFF16 outputs a fixed-size file. So, your estimated filesize will be exactly TOTAL FRAMES x TIFF file size. (which amounted to over 4T for my recent movie, which I didn’t have the space for, so I went with the h264 High 4:4:4 Predictive Profile, resulting in a file a bit over ‘only’ 350G).
Also, some people seem overly interested in costant bitrate somehow; which is rather overrated, really. Probably because it feels high-quality. But it’s often rather inefficient, and can even backfire on you. Practically, it means that large portions of your encode, you’ll be wasting bitrate on scenes that don’t really need it, and subsequently starve scenes that actually DO benefit from a higher bitrate. Unless you set constant bitrate very high for everything – which is where the waste comes in. So, Constant Rate Factor (CRF) is really the place to be.
“I’m still not clear what Constant Rate Factor or Compression factor actually means.”
CRF, in a nutshell, is basically quality-based VBR; aka, a way to vary the bitrate, per scene, but aiming for a constant quality factor. That was the TL;DR version of it. A more indepth look can be found, say, here CRF
No you don’t understand. I know what CRF and VBR means, but Topaz only offers something “compression factor”, this threat is not called CRF its called “Compression factor”.
‘Compression Factor’ is a rather limited term, as it can only be used with a contant bitrate output. If you take a video with a constant 20,000 kbs bitrate, and you were to set cbr to 4000 kbs for your output (just arbitrary numbers), that would amount to a compression factor of 5. Likewise, if you force a constant bitrate on a vbr video (and VEA knows the lenght of the input file, of course), then VEA can tell you what the compression factor will be, upfront.
For anything else, ‘compression factor’ can only be used as an end-result term, but not a true predictive one (although more-and-more accurate predictions can be made while encoding further). Like a RAR file. At the end, you could say ‘Okay, apparently output made my original file 5x smaller.’ But you can’t use such ‘compression factor’ as an initial parameter, simply because the RAR program has no clue what data to expect. Same with video output set to vbr: it’s cute to conclude your encoding had a compression factor of almost 5, but impossible to set as a parameter for VEA, as complexity of upcoming scenes are all unknown, of course. Like I said, though, barring strange things, along the way you could increasingly make better predictions as to the final size, though (kinda like x264/x265 do). Like this UHD ‘2001, A Space Odyssey’ movie I am currenty denoising. x265 bravely started out predicting final size would be 48MB (Sic!) That’s because like the first minute or so it’s just a black screen.
“What does ‘Compression Factor’ of 20 mean?”
Tt;dr: on a video with cbr output, it would simply mean ‘Output size will be a factor 20 smaller than input size.’ For anything else, that statement would be meaningless.
P.S. CRF option can be found under MP4 → H.264 output option.
Compression factor is merely a term chosen by the devs to indicate the CRF mode (perhaps to make it more noob friendly/easier to understand by people unfamiliar with the concept), and not some sort of secret rate control mode unique to VEAI alone or w/e…
" Compression factor is merely a term chosen by the devs to indicate the CRF mode (perhaps to make it more noob friendly/easier to understand by people unfamiliar with the concept), and not some sort of secret rate control mode unique to VEAI alone or w/e…"
Its a plausible explanation, but that makes no sense. Compression factor with no measurement unit only arbitrary number set by default to 20, 20 something that it has no explanation or label and it supposed to mean CRF which already is used and exists with a measurement units (bit rate kb/s)
If that is what it really is, it has to be the dumbest decisions ever made by any developer, ever. Unreal. How is that even possible. Who is product manager on this? Where is quality control?
Then that is flat-out wrong. Compression factor != CRF. A factor is ‘a number or quantity that when multiplied with another produces a given number or expression.’ CRF produces a non-predetermined bitrate, hence the multiplication (c.q. division) element of ‘factor’ is undefined, making a ‘compression factor’ parameter, in that context, a gobbledygook definition.
Dude, i can’t stop liking your posts. It seems that no one wants to understand that we want at least an APPROXIMATE value of the final result. These CF numbers say absolutely nothing.
If I needed lossless quality, I would put 999999 bitrate, and not guess what to put CF 1 or 30.
I’m already going crazy with all the answers here except yours. We are simply not heard and are poked in the face with these CF numbers, which simply do not mean anything.
Oh, we understand alright. And we heard you, but it seems you’re lacking some fundamental knowledge on how things work. THAT is why people (including yours truly) are explaining why essentially demanding ‘at least an APPROXIMATE value of the final result’, upfront, is, in most cases (except for a fixed bitrate output), a rather meaningless request. It’s like demanding WINRAR tells you upfront, what its compression rate will be. Compression simply doesn’t work that way. Especially not video compression, like H264/H265. It’s using incredibly complex algorithms, and largely based on scene analysis, motion prediction, etc. As I explained, the best you can hope for, is to examine the output; and then, as encoding progresses, make increasingly accurate predictions as to what the ‘value of the final result’ will be. That’s all. And then, perhaps VEAI could show you the projected size (like ETA), but never upfront. Except for cbr encoding – which, as I also explained, is, for the most part, also not really what you want, as it doesn’t give you the constant quality I fear you think it will.
And pray to whatever deity you adhere to, that they won’t ever actually let you set a bitrate of 999999.
999999 was an exaggerated joke with some idea, that for an ultimate quality you can just rise up bitrate drastically.
So let they delete this useless CF, that does NOTHING useful, and implement Constant bitrate.
Rendering for 2 days and guessing what in the end I will get… Nightmare.
What’s up with the religious arguments people give in this thread? lol
“Its good because I like it. I don’t know what it means, I cannot explain it I just now I like it and therefore it should be the only option.”
Unreal.
It does start to feel that this compression factor, whatever it is, is used as placebo effect. People go by feeling. As if they are judging modern art piece.
Perhaps you should take this argument up with the developers of x264/x265. They can probably explain CRF better than the forum members here. There are also many articles online about CRF (and one already given in this thread).
It seems that the VEAI developers may have made a rod for their backs by renaming CRF to Compression Factor.
“It seems that the VEAI developers may have made a rod for their backs by renaming CRF to Compression Factor.”
But that makes no sense, because CRF has a measurement unit, kb/s. Compression factor if it mean the same as CRF, than why would the measurement unit also change from kb/s, to arbitrary number with no measurement unit? Makes zero sense.
(which amounted to over 4T for my recent movie, which I didn’t have the space for, so I went with the h264 High 4:4:4 Predictive Profile, resulting in a file a bit over ‘only’ 350G).
