diff options
author | Philip Langdale <philipl@overt.org> | 2022-09-27 14:27:01 -0700 |
---|---|---|
committer | Philip Langdale <github.philipl@overt.org> | 2022-10-15 09:57:09 -0700 |
commit | 28526915879b42865e074e49d8677b453b93f493 (patch) | |
tree | d2312bf8eb95f8b5a3cd4a209ebdf10d498ef239 /demux | |
parent | 1bca62e58b6be4b530ffde12922bf555aefa412f (diff) | |
download | mpv-28526915879b42865e074e49d8677b453b93f493.tar.bz2 mpv-28526915879b42865e074e49d8677b453b93f493.tar.xz |
f_hwtransfer: allow hw uploads to implicitly convert formats
vaapi allows for implicit conversion on upload, which has some
relevance as the set of supported source formats is larger than the
set of displayable formats. In theory, this allows for offloading the
conversion to the GPU - if you have any confidence in the hardware
and/or driver's ability to do the conversion.
Today, we actually track the 'input' and 'output' upload formats
separately all the way up until the point we do a check as to whether
the original source format is an accepted 'output' format and then
reject it if it is not.
This means that we're essentially ignoring all the work we did to track
those 'input' formats in the first place. But it also means that it's a
simple change to compare against the 'input' format instead. The logic
is already in place to do best format selection on both sides.
I imagine that if I read through the history here, wm4 tried to
implement all of this properly and then gave up in disgust after seeing
vaapi mangle various conversions.
This is particularly interesting for vo-dmabuf-wayland where it is only
possible to display the subset of valid vaapi formats that are
supported by the compositor, yet all playback has to go through vaapi.
Users will then be able to take advantage of all possible vaapi formats
to avoid having to do software format conversion.
Diffstat (limited to 'demux')
0 files changed, 0 insertions, 0 deletions