Looks like you’re talking about yourself. You show no interest in learning how things actually work, you rail against CRF, while admitting you have no clue as to what it does; and you are unwilling to listen to anyone explaining to you (aka, yours truly) why upfront ‘estimated output size’ is inherently impossible, except for cbr encodings. All you do, is continually cry
“I know not how things work, nor do I care to find out; all I want is to set constant bitrate, because I once heard that is good. And I am going to continue to stick my fingers in my ears until I get what I want!”
Good luck with that. Damnant quod non intelligunt.
Dude, I know what CRF means and how to use it and I would not mind having it in the program, but Compression Factor is not CRF. Its like talking to a wall. This thread is hopeless.
The Constant Rate Factor (CRF) is the default quality (and rate control) setting for the x264 and x265 encoders, and it’s also available for libvpx. With x264 and x265, you can set the values between 0 and 51, where lower values would result in better quality, at the expense of higher file sizes. Higher values mean more compression, but at some point you will notice the quality degradation.
For x264, sane values are between 18 and 28. The default is 23, so you can use this as a starting point.
And that means what, exactly? Cooke eggs until they feel right? There is no measurement unit there a quality slider but no actual feedback in real time and to my knowledge where can I see after the fact what Compression factor or Constant Rate Factor or whatever you want to call it.
Bit rate is something I can see after the encoding and I can use that as reference of quality. It is also a logical standard. This CRF is not. Its not a standard, especially if Constant Rate Factor is for no obvious reason or explanation renamed to Compression factor and its used by whom? I don’t know professional linear editor programs that use it. So why would Topaz developers use it? Why would anyone use it? And why would you rename it so randomly?
Please stop defending lazy and sloppy developers and come over to the light side.
[This isn’t so much about the ‘debate’ in this thread as it is to explain what CRF is and how to approach it.]
When saving a JPEG in an image editor like Photoshop, we’re given a slider from 0 to 12 that says “Quality” on it. It’s just a simple, arbitrary number. We don’t control how many “pixels per byte” there are, and we don’t have to know what discrete cosine transform means. We just decide how compressed it should look visually, using a number. It’s the same deal with CRF; it’s a quality slider.
WIth CBR and VBR, you adjust the bitrate in order to try to improve the quality of the video. So you’re adjusting one thing while trying to change another. With CRF, you pick the quality level and then it adjusts things frame by frame to maintain that quality level. It avoids situations where a complex scene turns into a blocky mess just because you didn’t set the VBR threshold quite high enough, forcing you to rerender. It’s essentially a smarter variable bit rate which aims for overall consistency throughout the video. It’s a set it and forget it type of thing, something anybody can use, not just people who know what a kilobyte means.
Just like with any other time you’re doing lossy encoding of images, video, and audio, you have to experiment a little to find what works best. Render a minute or two of the video to test out the CRF value and make sure it looks good enough. That’s just something people should be doing anyway with any program dealing with video compression. You can’t apply the codec settings that you used in one program and assume it’ll work in another - that includes CRF values, as well. Don’t just copy values you got from playing with Handbrake, you should actually test them in VEAI.
I had decided I was kinda done with this topic, but just wanted to make one last comment about CRF.
VEAI is clearly ill-equiped to deal with ‘expert’ H264 settings (let alone HEVC). So, way I figure this, best to just treat it as one would a somewhat ‘clunky’, intermediate filter for. say, vapoursynth, and just set CRF = 0. This forces an edge-case of 4:4:4 Predictive H264 encoding (officially lossless). Either that, or just write to TIFF/PNG. Because VEAI is clearly not ready for expert end-stream output. As soon as I made peace with that, it was all good.
N.B. On the latter, I suggest the command line interface, along the lines of treating VEAI as a filter, doesn’t start the whole GUI.
I probably misspoke because of frustration in this thread. I meant constant bit rate ( CBR ) or a variable bit rate (VBR). Something that I can work with.
Since CRF and CBR as similar acronyms and I was not paying attention I wrote the wrong one.
“When saving a JPEG in an image editor like Photoshop, we’re given a slider from 0 to 12 that says “Quality” on it. It’s just a simple, arbitrary number. We don’t control how many “pixels per byte” there are, and we don’t have to know what discrete cosine transform means. We just decide how compressed it should look visually, using a number. It’s the same deal with CRF; it’s a quality slider.”
This is true, but it is not a good comparison since JPEG’s have always had the same slider since it was introduced and everyone who uses it, pretty much everyone has at this point, has been using it the same way since the beginning.
Video is not the same. I’ve not even encountered this CRF or Compression factor or however you want to call this thing. And why is everyone using darn acronyms that are so similar, it just raises confusion levels. Copy / paste was invented even before JPEG.
“It’s a set it and forget it type of thing, something anybody can use, not just people who know what a kilobyte means.”
Well than leave it as option for people who want to use it and give people who don’t want to use it a standard they are used to and use in other programs. Simple solution.
CRF is very well known entity to ppl who encode with, say, x264 since it was introduced (around 2003, when MPEG-4 Part 10 became a codec); and everyone who uses it – and pretty much everyone has at this point – has been using it the same way since the beginning. And among the plethora of very complex parameters, CRF has always been one of the easiest to get: lower number is better, higher number makes things worse – with well-documented optima for various types of video.
CRF will likely be less known to peeps who have traditionally been doing video-editing the Mac way (Apple tends to hide such parameters from its users, and resorts to proprietary codecs like ProRes, instead of just using what the rest of the world uses). In the PC word of encoding, however, anyone who’s ever been serious about encoding H264, will know what CRF means.
Ultimately, to get back on-topic, the problem is not CRF, but with the devs allegedly having called it ‘compression factor’.
Well I’ve been doing video editing and color grading with Premier Pro, After Effects, Davinci Resolve, and I have used verity of consumer grade video converter programs, all on PC and non of them used this CRF, they all had bit rate and size and option to choose wrapper, codec for audio and codec for video etc.
I don’t know which crowed using using it with other options, must be the people who use open source programs and either like scripting or have no problem getting around that kind of interface.
I wonder what the ratio of people is who use one vs the other. But either way, developers should have both options. Or at least ability to preview compression before export.
“Ultimately, to get back on-topic, the problem is not CRF, but with the devs allegedly having called it ‘compression factor’.”
That is only one part of the problem. But yes among the other things that is a problem.
The problem why this thread was started is that there is no clear explanation about compression factor and there are no other options that would be standard in all professional applications.
I don’t know what is your background and what kind of work you do, probably using something from the open source free market, but in professional video applications, its quite clear that there are standards and why they are there.
At the moment Video Enhance AI seems to fall in neither category. Its neither very user friends , its neither super complex and similar to some open source programs and its not following standards found in professional video applications, instead we have weird labels seemingly arbitrarily made by developers for no apparent reason that would justify it.
[quote=“itunes663, post:51, topic:25087”]
I don’t know which crowed using using it with other options, must be the people who use open source programs and either like scripting or have no problem getting around that kind of interface.[/quote]
True. I am used to command line interfaces (like that of OpenSource programs x264), and equally OpenSource frame servers like avisynth, or vapoursynth. Those are generally scripted environments, and require some minimal programming experience. People involved with creating such tools (like, for instance, a RIFE filter for vapoursynth), are generally total experts in their respective fields. Programs like x264 come with various wrappers too (like staxrip or ripbot264, etc), but are typically still catering for a frame server type audience.
It’s true that you don’t typically see an option like CRF in paid-for programs (the reason being, I reckon, that people pay for consumer oriented video tools, precisely because they don’t want to be bothered with the minutia). They just want options like ‘Lossless’, ‘High quality’, ‘Medium’, etc, and call it the day.
Thing is, VEAI hovers a bit in the middle: it’s not nearly offering enough fine-tuning of the final output, yet tries a bit with CRF. The latter can be said to be confusing for people who are, in their respective paid-for software, are not used to suddenly being confronted with what are basically just internal settings in any other professional environment.
Yes that is pretty much true. I come from Photoshop and artistic background and I do color grading etc in video. Some 3D, motion graphics etc. So I tend to use mostly programs that are lets called them “professional” and by that I simply mean they a re payed programs used by people who work in these fields for a living.
While scripting is something that exists in these programs it is considered a more specialized way to automate very, very specific workflows. So when you talk in terms like…
" People involved with creating such tools (like, for instance, a RIFE filter for vapoursynth), are generally total experts in their respective fields. Programs like x264 come with various wrappers too (like staxrip or ripbot264, etc), but are typically still catering for a frame server type audience."
It is like greek to most creative types who are visual and use tools to create something else, and export that something else, any scripting itself is more for people who develop the tools the others use. There are people who can do both, but its generally rare to find such people.
For example, where you might be familiar with command line interfaces, if I asked you to retouch a high end commercial fashion picture, or color grade a feature film… I assume you would be fish out of water just like I am when it comes to command line interfaces.
That is why Video Enhance AI user interface should ideally accommodate for both types of users.
When CRF was new and they tested it against 2-pass VBR encoding, they found CRF ended up being more consistent (and obviously twice as fast). I compared them myself in MSU’s Video Quality Measurement Tool (VQMT) years ago and concluded that unless I specifically need a certain file size or I’m doing streaming video, then CRF is just the way to go. CRF does things a person can’t do by manually adjusting some “average bitrate” at the start. It’s like setting the VBR to “?” and saying “just get it looking this good”, and then it shifts the settings every frame to match that quality level. In simple terms, the “quality” is determined by directly comparing the uncompressed frame with the compressed one and seeing how different they are. (There’s various algorithms like PSNR and SSIM; I’m not sure what’s being used.)
Yes, in a sense it’s like we’re “giving up” a little bit of control in terms of what the final file size will be. But it ends up being less work and the results are the same, if not better, because a computer can instantaneously figure out what the quality level is. WIth manual bitrate tinkering, the user needs to keep the complexity of every scene in the video in mind when picking a threshold. And let’s face it, we’re really just guessing what’s going to be “enough” without seeing it. And with CBR it’s worse, because you need to find a single magic goldilocks number for each video. CRF tosses out all that guess work and figures it all out on the fly.
Having said all of that, VEAI’s implementation of CRF is pretty different from that of other software I’ve encountered. I’m not kidding when I say people should test these things. I’ve tested dozens of settings with VQMT and decided that, depending on the resolution, I’m going to keep it around 12-15 for videos I care about. For professional projects, I would personally skip H.264 altogether and go with ProRes or image sequences, despite being massive. MPEG actually really sucks, I hate it and I can’t wait until we’ve all ditched them for open standards like AV1, which can’t come soon enough.
Well than leave it as option for people who want to use it and give people who don’t want to use it a standard they are used to and use in other programs. Simple solution.
The problem is, you would still need to be doing test renders even if they had manual bitrate adjustments. It would not be saving you that step. You’re saying bitrate is a “standard” but it really isn’t. Bitrates between programs are just as arbitrary as CRF at the end of the day; you absolutely cannot assume that they’re going to be utilized the same way by every encoder, universally. I’ve been dealing with encoding since the 90s and learned long ago that you shouldn’t trust programs to behave identically - even if they’re using the same encoder - because they’re all set up differently for each use case.
I use DaVinci Resolve, Adobe Media Encoder etc. and it works the same and they all use bit rate one of the clear marked settings. These are professional programs used in video production. I don’t know what you have been doing since the 90’s, but it amounts to not very much. So your argument is not really strong here. And why would anyone but a fundamentalist argue against both options?
I want as many options as I can get and if you want to use what you are used to, by all means. But give me what I want to use as well.
As for AV1 argument, yeah I had high hopes for it as well, but without support for hardware encoding with GPU, its pretty useless compared to h.265. If AV1 can get GPU support, great, but until than its just not a valid option, it takes way too long to export something.
ProRes, is a problem because of it size, and I’m not using it for advantage of fast editing, which is why its often used, its used as a easy to work with , but large , intermediate format for video editing or color grading. Sometimes its used as capture format, but its not normally used as delivery format in online environment. so I have re-encode again using program that actually support bit rate. That is a waste of time and takes way too much hard drive space for no advantage. Since Video Enhance AI already invents new frames there is no point is using ProPhoto unless you plan to edit video or something later. If you don’t, you have to repeat the process to get it in more manageable format like h.265. Its bad enough we don’t get h.265 export from Video Enhance AI.
If anything, it’s Adobe and Blackmagic who need to add CRF into their software. In fact, if I render MP4s in the Adobe Suite, I’ll do it with the Voukoder plugin because it can handle CRF (and much more). They also make a version for Resolve, incidentally.
Anyway, I already said I’m not arguing anything as far as what Topaz should do. It’s not my problem, because h.264 has been outdated garbage for a while now. It’s the option to use for personal bullshit, not for work. When you’re dealing with video files during production, the image needs to be as free of artifacts as possible. This unfortunately requires huge files on massive hard drives; that just comes with the territory. If a client needs an h.264, then that’s what separate encoding software is for, and it’s done as a last step. If you’re rendering to a severely lossy format like h.264 during production, you’re just sullying your own hard work.
As far as AV1 goes (and I wasn’t “arguing” about it), I know it’s not here yet. Well, it’s probably already the most seen codec on the planet since it’s what Netflix and YouTube use. But the encoders for the rest of us are still coming. Intel’s new GPU supports AV1 decoding and it’s slowly being phased in elsewhere, with practically every software and hardware maker on board. It’s going to make dealing with MPEG and all their royalties and licensing bullshit a thing of the past, and I can’t wait.
Strange way to put it. You argue that Adobe and Blackmagic need to add this CRF to their software , but than when it comes to Topaz, for which you seem to be beta tester, you say "I’m not arguing anything as far as what Topaz should do. It’s not my problem, "
Sounds like contradictions to me. I also don’t understand why is adding bit rate control to Topaz product even a problem for you, since what you use now does not need to be removed. What are you really arguing for or against? If anything.
Adobe and Blackmagic should definitely put CRF in their software, for both their h.264 and h.265 encoders, because it has so many proven advantages to VBR. It’s frankly weird that they don’t have it. The reason I’m talking about them and what they should do is because they’re massive companies making software that’s specifically geared for encoding video.
Topaz, on the other hand, is a tiny company that teaches tensorflow neural networks how to manipulate images in useful ways, typically to remove compression artifacts. The video encoding and image saving parts are incidental and for everything I’ve done with it, it’s been perfectly fine. The reason I don’t care if they added a VBR mode or not is because I wouldn’t use it. I already know the results would be inconsistent, which is why I and many others ditched it years ago. If they decided to add it, that’s fine, whatever. It’s not something I’m “arguing” against.
Look, all I’m saying is, just because the software you happen to use doesn’t have CRF or something like it, that doesn’t mean it isn’t already a widely-accepted compression scheme used throughout the video compression world.
Here is what I have in Davinci resolve. Everything I need, including what seems to be Compression Factor but under the name “quality”, but also I have three pages of options for anything one might need. Compare that to Video Enhance AI interface and you can see why I feel Topaz need to start working on updating their feature set and labeling of those features in a way that makes sense.
Hell, if you want some real options, check out what Voukoder can add to Resolve and other editors (for free):
I think one big problem Topaz is having is that they’re trying to fit so much into that one panel on the right-hand side, so adding more options just makes it more unwieldy. Maybe if they made image/video encoding options into its own separate pop-up window, it could work better. It would be cool if they could get Vouk or some other compression guru to design an encoding window for them.
BTW, I’d stay away from NVIDIA’s encoder (in your pic). Sure, it’s blazingly fast, but that’s because it’s really just meant for real-time stuff like streaming games to Twitch.
