diff options
author | wm4 <wm4@nowhere> | 2019-10-02 21:27:07 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2019-10-02 21:27:07 +0200 |
commit | 3e02f39087029380d666cfda963084d3952582f8 (patch) | |
tree | 4cbc8395fa56cfa278c6086f954aa0ef29d1019f /misc/thread_tools.c | |
parent | 49f9146fe4dfa6fb2e76e59b7e75a99707782dd9 (diff) | |
download | mpv-3e02f39087029380d666cfda963084d3952582f8.tar.bz2 mpv-3e02f39087029380d666cfda963084d3952582f8.tar.xz |
f_auto_filters: use software conversion if hw deint is not possible
Before this commit, enabling hardware deinterlacing via the
"deinterlace" option/property just failed if no hardware deinterlacing
was available. An error message was logged, and playback continued
without deinterlacing.
Change this, and try to copy the hardware surface to memory, and then
use yadif. This will have approximately the same effect as
--hwdec=auto-copy. Technically it's implemented differently, because
changing the hwdec mode is much more convoluted than just inserting a
filter for performing the "download". But the low level code for
actually performing the download is the same again.
Although performance won't be as good as with a hardware deinterlacer
(probably), it's more convenient than forcing the user to switch hwdec
modes separately. The "deinterlace" property is supposed to be a
convenience thing after all.
As far as the code architecture goes, it would make sense to auto-insert
such a download filter for all software-only filters that need it.
However, libavfilter does not tell us what formats a filter supports
(isn't that fucking crazy?), so all attempts to work towards this are
kind of hopeless. In this case, we merely have hardcoded knowledge that
vf_yadif definitely does not support hardware formats. But yes, this
sucks ass.
Diffstat (limited to 'misc/thread_tools.c')
0 files changed, 0 insertions, 0 deletions