I used to use constrained quality(pre YAC 2.0) but it actually slows down encode time from what I tested. I didn't see much benefit in it either since you either set it too high and it does nothing, or too low and you've essentially made a single-pass average bitrate encode(just about the worst of all modes).
It would be slower where the bitrate limit kicked in, and the same speed where it didn't (so slower overall).
Constrained quality might make sense for streaming data when you don't want to exceed available bandwidth, but these games are all played with locally cached files so bandwidth is irrelevant. If files are too big, just drop the quality a bit.
The problem with that is, you're dropping the quality for everything, including the files which didn't hit whatever the desired bitrate limit is. Constrained only drops the quality further on videos which are harder to encode.
I often encounter game with huge variations in video bitrate (
sometimes >100 MB/s). On my low-spec machine, vids with blu-ray esq bitrates run poorly (stutter etc.). Unnecessarily high bitrates also signifigantly increase the file size, which is a primary issue for this tool. Constrained knocks these high bitrate vids down without hammering those which had reasonable bitrates to start with.
These things are always a tradeoff, which is why I suggested using an optional variable. Most users can stick to your existing -b:v 0 as the default, while those who want constrained can set it to a desired value (and suffer the extra processing time).
Merely an idea to address FAPmasters369 request with minimal fuss. Depends how many other users might want it?
