summaryrefslogtreecommitdiffstats
path: root/filters/f_swresample.c
Commit message (Collapse)AuthorAgeFilesLines
* various: make filter internal function names more descriptivenanahi2024-04-101-8/+8
| | | | | | | | | Lots of filters have generic internal function names like "process". On a stack trace, all of the different filters use this name, which causes confusion of the actual filter being processed. This renames these internal function names to carry the filter names. This matches what had already been done for some filters.
* swresample: stop using deprecated {in,out}_channel_layout optionsDudemanguy2024-03-081-0/+16
| | | | | | | | | | | | These options were deprecated with the addition of the channel layout API about a couple of years ago*. Unfortunately, we never saw the deprecation messages so it went unnoticed until they were completely removed with the recent major version bump. Fix this by setting in_chlayout and out_chlayout instead if we have AV_CHANNEL_LAYOUT. Fixes #13662. *: https://github.com/FFmpeg/FFmpeg/commit/8a5896ec1f635ccf0d726f7ba7a06649ebeebf25
* various: add some missing error checksKacper Michajłow2023-11-181-0/+2
|
* options: transition options from OPT_FLAG to OPT_BOOLChristoph Heinrich2023-02-211-2/+2
| | | | | | c78482045444c488bb7948305d583a55d17cd236 introduced a bool option type as a replacement for the flag type, but didn't actually transition and remove the flag type because it would have been too much mundane work.
* various: drop unused #include "config.h"Thomas Weißschuh2023-02-201-2/+0
| | | | | | Most sources don't need config.h. The inclusion only leads to lots of unneeded recompilation if the configuration is changed.
* swresample: don't forcibly clip on every conversionNiklas Haas2022-06-231-22/+0
| | | | | | | | | | | | | This was introduced in 04257417 without a clear explanation of the bug it was solving, so I have no idea if it's still needed (or why it ever was). And it definitely creates unexpected behavior, e.g. forced clipping when converting between float and floatp. I therefore think we should simply remove this logic and see if it regresses anything else, then fix those other bugs *properly* (if they're still around). Fixes #9979
* options: change option macros and all option declarationswm42020-03-181-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change all OPT_* macros such that they don't define the entire m_option initializer, and instead expand only to a part of it, which sets certain fields. This requires changing almost every option declaration, because they all use these macros. A declaration now always starts with {"name", ... followed by designated initializers only (possibly wrapped in macros). The OPT_* macros now initialize the .offset and .type fields only, sometimes also .priv and others. I think this change makes the option macros less tricky. The old code had to stuff everything into macro arguments (and attempted to allow setting arbitrary fields by letting the user pass designated initializers in the vararg parts). Some of this was made messy due to C99 and C11 not allowing 0-sized varargs with ',' removal. It's also possible that this change is pointless, other than cosmetic preferences. Not too happy about some things. For example, the OPT_CHOICE() indentation I applied looks a bit ugly. Much of this change was done with regex search&replace, but some places required manual editing. In particular, code in "obscure" areas (which I didn't include in compilation) might be broken now. In wayland_common.c the author of some option declarations confused the flags parameter with the default value (though the default value was also properly set below). I fixed this with this change.
* options: change how option range min/max is handledwm42020-03-131-1/+1
| | | | | | | | | | | | | | | | | Before this commit, option declarations used M_OPT_MIN/M_OPT_MAX (and some other identifiers based on these) to signal whether an option had min/max values. Remove these flags, and make it use a range implicitly on the condition if min<max is true. This requires care in all cases when only M_OPT_MIN or M_OPT_MAX were set (instead of both). Generally, the commit replaces all these instances with using DBL_MAX/DBL_MIN for the "unset" part of the range. This also happens to fix some cases where you could pass over-large values to integer options, which were silently truncated, but now cause an error. This commit has some higher potential for regressions.
* Remove remains of Libav compatibilitywm42020-02-161-60/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Libav seems rather dead: no release for 2 years, no new git commits in master for almost a year (with one exception ~6 months ago). From what I can tell, some developers resigned themselves to the horrifying idea to post patches to ffmpeg-devel instead, while the rest of the developers went on to greener pastures. Libav was a better project than FFmpeg. Unfortunately, FFmpeg won, because it managed to keep the name and website. Libav was pushed more and more into obscurity: while there was initially a big push for Libav, FFmpeg just remained "in place" and visible for most people. FFmpeg was slowly draining all manpower and energy from Libav. A big part of this was that FFmpeg stole code from Libav (regular merges of the entire Libav git tree), making it some sort of Frankenstein mirror of Libav, think decaying zombie with additional legs ("features") nailed to it. "Stealing" surely is the wrong word; I'm just aping the language that some of the FFmpeg members used to use. All that is in the past now, I'm probably the only person left who is annoyed by this, and with this commit I'm putting this decade long problem finally to an end. I just thought I'd express my annoyance about this fucking shitshow one last time. The most intrusive change in this commit is the resample filter, which originally used libavresample. Since the FFmpeg developer refused to enable libavresample by default for drama reasons, and the API was slightly different, so the filter used some big preprocessor mess to make it compatible to libswresample. All that falls away now. The simplification to the build system is also significant.
* audio: fix segfault caused by incorrect number of planeszc622019-02-231-1/+1
| | | | | | | Use `mp_aframe_get_planes` to properly get the number of planes, instead of assuming it to be the number of channels. Fixes #6092
* swresample: minor simplificationwm42018-02-031-7/+6
| | | | Cosmetic and no change in behavior. At least I think this looks simpler.
* swresample: remove unnecessary request for new inputwm42018-02-031-1/+2
| | | | | | | | | | | We called mp_pin_out_request_data() if there was input _and_ output. This is not how it should be: we should request new input only if output was requested, but we could not produce any output. On the other hand, the upper half of the process() function will request new input if output is required, but all input was consumed. But this requires calling mp_filter_internal_mark_progress(), as otherwise the general filter logic would not know that we can continue.
* swresample: actually reinit resampler on large speed changeswm42018-02-031-5/+13
| | | | | | | | | | | | | | | | | | | If the speed is changed by a large amount, we need to effectively change the output rate by a large amount, and swr_set_compensation() is apparently not designed to handle such large changes well. So it's better to reinitialize the resampler on all large changes. Also, strictly reinitialize the resampler if the rate changes, otherwise it could happen that libavresample (which does not automatically initialize resampling if avresample_set_compensation() is used) would never apply speed changes properly. Also document some conditions better that handle corner cases (remove the inline condition from the if gating the compensation code). It also appears that we crashed with very large compensation ratios (when raising audio speed quickly by keeping the "[" key down), and this commit accidentally mitigates it by not allowing large compensation.
* swresample: limit output size of audio frameswm42018-02-031-35/+56
| | | | | | | | | | | | | | Similar to the previous commit, and for the same reasons. Unlike with af_scaletempo, resampling does not have a natural frame size, so we set an arbitrary size limit on output frames. We add a new option to control this size, although I'm not sure whether anyone will use it, so mark it for testing only. Note that we go through some effort to avoid buffering data in libswresample itself. One reason is that we might have to reinitialize the resampler completely when changing speed, which drops the buffered data. Another is that I'm not sure whether the resampler will do the right thing when applying dynamic speed changes.
* audio: rewrite filtering glue codewm42018-01-301-0/+717
Use the new filtering code for audio too.