summaryrefslogtreecommitdiffstats
path: root/filters/f_lavfi.c
Commit message (Collapse)AuthorAgeFilesLines
* f_lavfi: add gross workaround for af_dynaudnorm bugwm42019-12-181-0/+35
| | | | | | | | | | | | | Better do this here than deal with the moronic project we unfortunately depend on. The workaround is generic; unknown whether it works correctly with multi-input/output filters or filter graphs. It assumes that if all inputs are EOF, and all outputs are EAGAIN, the bug happened. This is pretty tricky, because anything could happen. Any time some form of progress is made, the got_eagain state needs to be reset, because the filter pad's state could have changed.
* filters: move prefix check from f_lavfi.c to user_filters.cwm42019-12-071-4/+0
| | | | | | | | It's user_filters.c which allows the "lavfi-" prefix to distinguish libavfilter filters from mpv builtin filters. f_lavfi.c is a layer below, and strictly passes anything it gets to libavfilter. So the correct place for this is in user_filters.c, which also has the code for stripping the prefix in the normal filter instantiation code.
* f_lavfi: mp_lavfi_is_usable: check for "lavfi-" prefixekisu2019-12-061-0/+4
| | | | | Without this, adding filters with the prefix would fail, and some filters that have conflicting names with mpv ones were unusable.
* options: pre-check filter names when using vf/af libavfilter bridgewm42019-11-251-0/+6
| | | | | | | | | | | | | Until now, using a filter not in mpv's builtin filter list would assume it's a libavfilter filter. If it wasn't, the option value was still accepted, but creating the filter simply failed. But since this happens after option parsing, so the result is confusing. Improve this slightly by checking filter names. This will reject truly unknown filters at option parsing time. Unfortunately, this still does not check filter arguments. This would be much more complex, because you'd have to create a dummy filter graph and allocate the filter. Maybe another time.
* f_lavfi: support setting common filter options like "threads"wm42018-04-291-1/+2
| | | | | | | | | AVFilterContext instances support some additional AVOptions over the actual filter. This includes useful options like "threads". We didn't support setting those for the "direct" wrapper (--vf=yadif:threads=1 failed). Change this. It requires setting options on the AVFilterContext directly, except the code for positional parameters still needs to access the actual filter's AVOptions.
* video: pass through container fps to filterswm42018-04-191-1/+8
| | | | | | | | | | | | This means vf_vapoursynth doesn't need a hack to work around the filter code, and libavfilter filters now actually get the frame_rate field on input pads set. The libavfilter doxygen says the frame_rate field is only to be set if the frame rate is known to be constant, and uses the word "must" (which probably means they really mean it?) - but ffmpeg.c sets the field to mere guesses anyway, and it looks like this normally won't lead to problems.
* f_lavfi: add an option to use old audio PTS handling for af_lavfiwm42018-04-151-0/+31
| | | | | The fix-pts option basically uses the old af_lavfi's (before filter rewrite) timestamp logic. The rest is explained in the manpage.
* f_lavfi: use new libavfilter iteration APIwm42018-04-031-3/+5
|
* f_lavfi: extend filter help outputwm42018-02-131-1/+41
| | | | | | Also print type and help string. Also print AV_OPT_TYPE_CONST, which are like the mpv choice option type, except different. Print them as separate lines because FFmpeg usually has help strings for them too.
* options: slightly improve filter help output for lavfi bridgewm42018-02-031-4/+47
| | | | | | | | | | | | | | --vf=help will now list libavfilter filters, and e.g. --vf=yadif=help will list libavfilter filter options. The latter is rather bare, because the AVOption API is really awful (holy shit how is it so bad), and would require us to handle _every_ option type manually. Alternatively we could call av_opt_show2(), which ffmpeg uses for help output in its CLI tools and which is much more detailed. But it's rather foreign and forces output through av_log(), so I don't really want to use it.
* audio: rewrite filtering glue codewm42018-01-301-19/+82
| | | | Use the new filtering code for audio too.
* video: rewrite filtering glue codewm42018-01-301-0/+952
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.