You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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?
The text was updated successfully, but these errors were encountered: