x264/5 have a zones parameter to support different encode settings for part of a video, but it only accepts frame numbers, not timestamps.
This is a minor inconvenience with constant-frame-rate video, but a major inconvenience when using an ffmpeg filter like mpdecimate to drop (almost) exact duplicate frames. Or with VFR video in general. (And if it doesn't work with ffmpeg, only an option to the stand-alone CLI, that would also be a major inconvenience.)
libx265 (and libx264) have an API that allows the caller to reconfigure some encoder parameters on the fly, so ffmpeg's libx264 and libx265 encoder wrappers could in theory adjust the CRF or other encoder parameters in a certain range of timestamps, separately from x264's own "zones" feature.
ffmpeg does have start/stop ranges for filters, so its command-line / option parsing probably has most of the code needed to handle this.
But AFAIK, this is not currently implemented. ffmpeg -h encoder=libx265 doesn't shows anything relevant; -x265-params is parsed to config the encoder once at startup and there are only a couple other options supported. (libx264 has many more ffmpeg options, but not any kind of zones that I can see.)
Is there some alternative way to encode with -vf mpdecimate (or an arbitrary VFR source) and have CRF30 for most of the video, but CRF=24 from 00:30:00 to 00:30:30, for example?
In my case, there's one visually interesting clip that's worth spending extra bits on quality, and I'd rather not chop the video up and use MKV ordered chapters just to make this happen. Although if there's some straightforward ffmpeg syntax to do that (especially in one pass), that would be nice. Something that can reasonably fit in a bash shell "one liner" is what I'm aiming for.
To do this with zones, I think I'd need to run the video through mpdecimate and find out the frame numbers of the start/end of that time region. And I think I'd need to run the video through the stand-alone x265 CLI, because I think zones are a feature of the command-line front-end, not the library itself. (And thus not supported via -x265-params to pass key/value pairs to libx265).
I checked to see if Handbrake supported any kind of zones, and I don't see it in the GUI. (And Arch Linux's Handbrake 1.0.7 package is still using x265 2.1, so it doesn't even have the updated Lambda tables from x265 2.4, which came out over 9 months ago. Handbrake is nice except for having outdated private copies of codecs instead of building against the system version, which definitely still matters for x265.)
