Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

do not expose hardware specific functionality in library interface #25

Open
bmegli opened this issue Apr 4, 2020 · 0 comments
Open
Labels
maintenance Documentation and future-proof concepts

Comments

@bmegli
Copy link
Owner

bmegli commented Apr 4, 2020

The qp options introduced in ff2b694 is VAAPI specific (codec-private option).

The current implementation of HVE translates to other hardware encoders in a straightforward way (see #5).

By using codec-private options and exposing them in the library interface the translation to other hardware encoders gets difficult, similiar with documentation of the library..

In the long term options such as qp should be probably exposed as vaapi specific or generic options should be used instead and tranlsated to codec specific in implementation.

E.g.

  • optional sub-struct in hve_config like vaapi_config, be default NULL or {0}
@bmegli bmegli added the maintenance Documentation and future-proof concepts label Apr 4, 2020
bmegli added a commit that referenced this issue Apr 10, 2020
- extend hardware config with input_width, input_height fields
- if specified and different from width/height perform hardware accelerated scaling before encoding
- update examples
- update docs
- update readme

Adds dependency on libavfilter.

Closes #24
Makes #5 more complex
Indirectly related to #25
Indirectly related to #6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
maintenance Documentation and future-proof concepts
Projects
None yet
Development

No branches or pull requests

1 participant