diff options
author | wm4 <wm4@nowhere> | 2016-07-06 14:08:47 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2016-07-06 14:08:47 +0200 |
commit | 771a8bf5c67417b7aad07fac0913c37b4633a205 (patch) | |
tree | 41a2e929fb25f3199b48ce141576cd3e06c4f90b /audio | |
parent | 08cd50b84b853fc525a9074099fbf0a12830afe2 (diff) | |
download | mpv-771a8bf5c67417b7aad07fac0913c37b4633a205.tar.bz2 mpv-771a8bf5c67417b7aad07fac0913c37b4633a205.tar.xz |
video: fix deinterlace filter handling for VFCTRL_SET_DEINTERLACE filters
Some filters support VFCTRL_SET_DEINTERLACE. This affects most hardware
deinterlace filters. They can be inserted by the user manually, or auto-
inserted by vf.c itself as conversion filter (vf_d3d11vpp). In these
cases, we shouldn't insert or remove filters outselves, and instead
VFCTRL_SET_DEINTERLACE should be invoked to switch the mode.
This wasn't done correctly in the recently refactored code and could
have broken with --deinterlace. (The refactor only considered switching
via property in this case.) Fix it by making it a proper part of the
filter_reconfig() function, and making set_deinterlacing() (which is
called by the property handler) merely call filter_reconfig() in all
cases to do the real work.
We can even avoid rebuilding the filter chain - though only if no other
auto-filters are inserted. It probably also provides a slightly cleaner
way to implement functionality in the VO while still inserting video
filter fallbacks correctly if required.
Diffstat (limited to 'audio')
0 files changed, 0 insertions, 0 deletions