summaryrefslogtreecommitdiffstats
path: root/filters/f_auto_filters.c
Commit message (Collapse)AuthorAgeFilesLines
* video/filter: add field order support for built in deinterlacers1nsane0002024-03-041-3/+6
| | | | | | refqueue gets the field of the frame from mp_image which almost always(if not always) assumes bottom field order first. By default this behavior should not change but specifying the field order should bypass this.
* f_auto_filters: pass field parity to lavfi bwdif deinterlacers1nsane0002024-03-041-3/+19
| | | | | Since all of them(software, vulkan, cuda) already have a built in parity parameter
* video: don't define IMGFMT_VULKAN conditionallysfan52024-02-261-2/+0
| | | | | | We generally try to avoid that due to the #ifdef mess. The equivalent format is defined in ffmpeg 4.4 while our interop code requires a higher version, but that doesn't cause any problems.
* player/command: add deinterlace-active propertyDudemanguy2024-02-071-0/+6
|
* player: add an auto option to deinterlaceDudemanguy2024-02-071-7/+10
| | | | | | | | | | Deinterlacing required that the user set it on/off themselves, but we actually have handy flags for detecting if a frame is interlaced. So it's pretty simple to make an auto option using that. Unfortunately, life is not quite that simple and there are known cases of false positives from the ffmpeg flags so we can't make auto the default value. However, it still may have some utility for some people, and the detection could potentially be improved upon later. Closes #10358.
* f_auto_filters: use bwdif_cuda for deinterlacing with cuda hwdecDudemanguy2024-01-221-1/+1
| | | | | Followup to 45f822593f14d78fa22e74fa4e725a3ffd6f713c. vulkan hwdec uses bwdif_vulkan so no reason to not make cuda also match.
* f_auto_filters: change fallback deinterlace to bwdifDudemanguy2024-01-211-2/+2
| | | | | | | I don't actually deinterlace ever but allegedly this is better than yadif, and there's no real reason to not have this be the fallback deinterlace when we're not using hw frames. Also change various mentions of yadif to bwdif. Ref #12835.
* hwdec_vulkan: use bwdif_vulkan as deinterlacing auto filterPhilip Langdale2023-05-281-0/+6
| | | | | This is currently the only vulkan deinterlacing filter in ffmpeg and it's a very high quality algorithm.
* filters: Re-add vavpp deinterlacing auto-filterPhilip Langdale2022-03-021-0/+5
| | | | | | | | | | | | A few years ago, in 25e70f4743c44db59fe8fc902c93a966d95ba8c3, we disabled the vavpp deinterlacing auto-filter on the basis that it caused crashes on _some_ hardware with _some_ driver version(s). But since then, the situation has improved. There is still a limitation where you can't turn deinterlacing on on the fly with AMD, but it doesn't crash anymore (That is #7388). So, given that AMD users have to set up the deinterlacing filter manually either way, let's re-add the auto-filter for Intel users.
* filters/auto_filters: switch from scaletempo to scaletempo2Jan Ekström2021-02-151-2/+2
| | | | | | | Part 1 of "look how well it performs, then start cleaning up the old one." Closes #8376
* audio: redo video-sync=display-adropwm42020-05-231-12/+43
| | | | | | | | | | | | | | | | | This mode drops or repeats audio data to adapt to video speed, instead of resampling it or such. It was added to deal with SPDIF. The implementation was part of fill_audio_out_buffers() - the entire function is something whose complexity exploded in my face, and which I want to clean up, and this is hopefully a first step. Put it in a filter, and mess with the shitty glue code. It's all sort of roundabout and illogical, but that can be rectified later. The important part is that it works much like the resample or scaletempo filters. For PCM audio, this does not work on samples anymore. This makes it much worse. But for PCM you can use saner mechanisms that sound better. Also, something about PTS tracking is wrong. But not wasting more time on this.
* f_auto_filters: always fall back to hw-download+yadif if no hw deint filterwm42020-02-161-3/+8
| | | | | | | | | | | If hw decoding is used, but no hw deinterlacer is available, even though we expect that it is present, fall back to using hw-download and yadif anyway. Until now, it was over if the hw filter was somehow missing; for example, yadif_cuda apparently requires a full Cuda SDK, so it can be missing, even if nvdec is available. (Whether this particular case works was not tested with this commit.) Fixes: #7465
* f_auto_filters: use f_autoconvert for hw downloadwm42019-10-021-23/+22
| | | | | | | | Instead of using custom code. Now if only f_lavfi knew what formats FFmpeg's vf_yadif accepts, this could look much nicer, and wouldn't require the additional converter filter setup.
* f_auto_filters: use software conversion if hw deint is not possiblewm42019-10-021-7/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* video: remove vf_vavpp from automatic deinterlace propertywm42019-10-021-3/+0
| | | | | | | | | | | | | | This reverts commit 6385a5fd1b8a67c051b82d48c993a6591e8f93c6, and in addition removes the code that automatically inserts the vavpp filter. The reason is the same as the commit that is being reverted: this filter seems to trigger driver bugs. It can cause GPU freezes or just doesn't work. This variant of disabling the filter is better. There was no way to add the "force" parameter to the automatically inserted filter, so the old approach just made manual filter insertion (with the --vf option or "vf" command) more cumbersome.
* filters: Add cuda/nvdec deinterlacing auto-filter using vf_yadif_cudaPhilip Langdale2018-11-191-0/+4
| | | | | | | | | | | Historically, there's been no way to offer deinterlacing with nvdec, and for cuviddec, it required a command line flag, with no way to toggle while playing. Now that we have a cuda deinterlacing filter in ffmpeg, we can hook it up hook it up as the cuda auto-deinterlacer. In practice, this isn't going to be present very often, due to the licensing mess with the cuda sdk, but we can support it when it is there.
* f_output_chain: log status of auto filterswm42018-04-291-0/+29
| | | | | Just so users don't think the filters do anything when they don't insert any filters.
* video: fix --video-rotate in some caseswm42018-02-181-1/+1
| | | | Which idiot wrote this code? [Yeah, me.]
* video: make --deinterlace and HW deinterlace filters always deinterlacewm42018-02-131-1/+1
| | | | | | | | | | | | | | | | Before this, we made deinterlacing dependent on the video codec metadata (AVFrame.interlaced_frame for libavcodec). So even if --deinterlace=yes was set, we skipped deinterlacing if the flag wasn't set. This is very unreliable and there are many streams with flags incorrectly set. The potential problem is that this might upset people who alwase enabled deinterlace and hoped it worked. But it's likely these people were screwed by this setting anyway. The new behavior is less tricky and easier to understand, and this preferable. Maybe one day we could introduce a --deinterlace=auto, which does the right thing, but of course this would be hard to implement (esecially with hwdec). Fixes #5219.
* audio: rewrite filtering glue codewm42018-01-301-0/+90
| | | | Use the new filtering code for audio too.
* video: rewrite filtering glue codewm42018-01-301-0/+244
Get rid of the old vf.c code. Replace it with a generic filtering framework, which can potentially handle more than just --vf. At least reimplementing --af with this code is planned. This changes some --vf semantics (including runtime behavior and the "vf" command). The most important ones are listed in interface-changes. vf_convert.c is renamed to f_swscale.c. It is now an internal filter that can not be inserted by the user manually. f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is conceptually easy, but a big mess due to the data flow changes). The existing filters are all changed heavily. The data flow of the new filter framework is different. Especially EOF handling changes - EOF is now a "frame" rather than a state, and must be passed through exactly once. Another major thing is that all filters must support dynamic format changes. The filter reconfig() function goes away. (This sounds complex, but since all filters need to handle EOF draining anyway, they can use the same code, and it removes the mess with reconfig() having to predict the output format, which completely breaks with libavfilter anyway.) In addition, there is no automatic format negotiation or conversion. libavfilter's primitive and insufficient API simply doesn't allow us to do this in a reasonable way. Instead, filters can use f_autoconvert as sub-filter, and tell it which formats they support. This filter will in turn add actual conversion filters, such as f_swscale, to perform necessary format changes. vf_vapoursynth.c uses the same basic principle of operation as before, but with worryingly different details in data flow. Still appears to work. The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are heavily changed. Fortunately, they all used refqueue.c, which is for sharing the data flow logic (especially for managing future/past surfaces and such). It turns out it can be used to factor out most of the data flow. Some of these filters accepted software input. Instead of having ad-hoc upload code in each filter, surface upload is now delegated to f_autoconvert, which can use f_hwupload to perform this. Exporting VO capabilities is still a big mess (mp_stream_info stuff). The D3D11 code drops the redundant image formats, and all code uses the hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a big mess for now. f_async_queue is unused.