Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
hwdec/vaapi: improve probing of supported sw formats
The logic around trying to establish what formats are supported by vaapi is confusing, and it turns out that we've been doing it wrong. Up until now, we've been going through the list of decoding profile endpoints and checking the formats declared in those profiles to build our list. However, the set of formats that the vaapi driver can actually support is potentially a superset of those supported by any given profile endpoint. This master list is exposed by libavutil via the av_hwframe_transfer_get_formats() function, and so we should use that list as our starting point. Perhaps surprisingly, this change actually removes no code, because we still want the logic that enumerates endpoints and finds supported formats for endpoints. We need this because we must have at least one known sw format to initialise the hwframe_ctx with. Additionally, while in the general case, av_hwframe_transfer_get_formats can return different formats depending on what format you initialise the hwframe_ctx with, I happen to have read the libavutil code, and it doesn't care, so we just need to call it once, we know we'll get back all known formats. In practice, with an Intel vaapi driver, this will result in us supporting a handful of extra formats for hwuploads - particularly yuv420p (so no need to convert to nv12 first) and various orderings of rgb(a).
- Loading branch information