Improvement: Add DeepFilter Abstraction Layer to Core

[omeryusufyagci]

See, the in-place, hardcoded command here.

Updated issue scope and description:

• DeepFilterSettingsManager: This is a singleton to take care of the user settings specific to DeepFilter. It will not handle configurations -that is still done by the centralized ConfigManager.
• DeepFilterCommandBuilder: A builder to construct the DeepFilte OS command. An alternative approach is being built for RT use, nevertheless we should update the current OS call implementation with this builder.
• DeepFilterControllerBuilder: Builds a DeepFilterController via the user settings from DeepFilterSettingsManager and uses the DeepFilterCommandBuilder to construct the high level controller API.
• DeepFilterController: A high level API responsible for orchestrating DeepFilter functionality. Currently, it will most likely have a single public method to filter a given chunk or file, but as mentioned, likely this will expand soon.

[VarunParab]

Hi @omeryusufyagci. Could you please assign this issue to me? I'd like to work on implementing the filter abstraction layer.

[omeryusufyagci]

Thanks @VarunParab, you got it! Just a few adjustments:

Please take a quick look at the discussion in #4, where we decided to introduce a dedicated class for similar functionality (FFmpegController). The same principles apply here: we'll need a FilterController class to abstract the filter usage, making it generic and adaptable for future changes.

Feel free to reach out if you need more details!

[omeryusufyagci]

Hi @VarunParab, we've had a very similar objective for providing an abstraction layer for FFmpeg operations. Although what we have for filtering currently is a lot more straightforward, we can imagine in the future we may have multiple ML models and we may introduce more functionality with them.

In that sense, I'd prefer to follow the same principles we've decided during these discussions. Please see #45 for a global overview of the subject.

To provide a summary for you, here's what we'll be aiming for:

• DeepFilterSettingsManager: This is a singleton to take care of the user settings specific to DeepFilter. It will not handle configurations -that is still done by the centralized ConfigManager.
• DeepFilterCommandBuilder: A builder to construct the DeepFilte OS command. An alternative approach is being built for RT use, nevertheless we should update the current OS call implementation with this builder.
• DeepFilterControllerBuilder: Builds a DeepFilterController via the user settings from DeepFilterSettingsManager and uses the DeepFilterCommandBuilder to construct the high level controller API.
• DeepFilterController: A high level API responsible for orchestrating DeepFilter functionality. Currently, it will most likely have a single public method to filter a given chunk or file, but as mentioned, likely this will expand soon.

I realize this is quite an update, and indeed it's come from discussions with Scott as he was building the FFmpeg related functionality. If you're up for it, you can continue to work on the full package. Please let me know if the updated scope won't fit with your schedule and what you'd like to work on and we can readjust the workload. I will preemptively update this issue title and description, and I look forward to your feedback. Thanks!

[omeryusufyagci]

This is cancelled as the recently added DeepFilterCommandBuilder provides a good balance for its singular use within our core. Moving forward we'll prioritize using directly the DeepFilterNetFFI instead, which would likely require a different hierarchy. Please monitor our issues page if you'd like to work on these or other open issues.