alexheretic
commented
9 months ago I'm not against making the tool more flexible, though it does depend on the complexity cost of the code. It sounds worth trying at least.
Can you provide some ffmpeg arg examples you have in mind?
veryprogram
I've been able to implement the use of Videotoolbox hardware encoding. But it uses either constant bitrate or constant quality as a metric for encoding. Just using the existing code outputs options that are not compatible and cause ffmpeg to fail. This is due to some of the options within ab-av1 being hardcoded that are specific to the libsvtab1 encoder.
I'm interested in adding support for this alternative encoder, but it would require some re-architecting of the code. Specifically, I'm thinking of breaking the Encode Struct out to be a trait that has more generic encode functions. Then create encoder specific structs for each type so that you can implement the specific options that are available for that encoder. This would also mean adding the ability to do a search for settings, similar to crf-search, but specific to that encoder. This would also make it more flexible to add new encoders as they become available. This would address #135 without creating a workaround.
My question is whether this fits into your intent of this project? If you do not think this fits, then I will keep this for myself. But if you do, I can work on it through a pull request. If you want me to submit this, are there any specifics in your intended architecture or project setup that you want me to adhere to?