summaryrefslogtreecommitdiffstats
path: root/audio/filter
Commit message (Collapse)AuthorAgeFilesLines
* audio: log replaygain values in af_volume instead demuxerwm42016-08-131-6/+10
| | | | | | | The demuxer layer usually doesn't log per-stream information, and even the replaygain information was logged only if it came from tags. So log it in af_volume instead.
* audio/filter: remove delay audio filterPaul B Mahol2016-08-122-196/+0
| | | | Similar filter is available in libavfilter.
* af_lavcac3enc: allow passing options to libavcodecwm42016-08-091-0/+7
|
* audio: use --audio-channels=auto behavior, except on ALSAwm42016-08-041-8/+8
| | | | | | | | | | | | | | | | | | | | | | | This commit adds an --audio-channel=auto-safe mode, and makes it the default. This mode behaves like "auto" with most AOs, except with ao_alsa. The intention is to allow multichannel output by default on sane APIs. ALSA is not sane as in it's so low level that it will e.g. configure any layout over HDMI, even if the connected A/V receiver does not support it. The HDMI fuckup is of course not ALSA's fault, but other audio APIs normally isolate applications from dealing with this and require the user to globally configure the correct output layout. This will help with other AOs too. ao_lavc (encoding) is changed to the new semantics as well, because it used to force stereo (perhaps because encoding mode is supposed to produce safe files for crap devices?). Exclusive mode output on Windows might need to be adjusted accordingly, as it grants the same kind of low level access as ALSA (requires more research). In addition to the things mentioned above, the --audio-channels option is extended to accept a set of channel layouts. This is supposed to be the correct way to configure mpv ALSA multichannel output. You need to put a list of channel layouts that your A/V receiver supports.
* af_lavcac3enc: skip output if there was no input framewm42016-08-021-0/+3
| | | | Unrealistic corner case: drainning was initiated right after a seek.
* af_lavcac3enc: fix buffering timestamps calculationswm42016-08-011-3/+9
| | | | In theory, an encoder could buffer some data.
* af_lavcac3enc: fix memory leakwm42016-08-011-1/+1
| | | | A major one. Oops.
* af_lavcac3enc: fix a debug messagewm42016-07-311-1/+1
|
* af_lavcac3enc: error out properly if encoding failswm42016-07-311-0/+4
|
* af_lavcac3enc: fix aspects of AVFrame handlingwm42016-07-311-0/+3
| | | | | | | | | | We send a refcounted frame to the encoder, but then disrespect refcounting rules and write to the frame data without making sure the buffer is really writeable. In theory this can lead to reallocation on every frame is the encoder really keeps a reference. If we really cared, we could fix this by providing a buffer pool. But then again, we don't care.
* af_lavcac3enc: use common code for AVFrame setupwm42016-07-241-11/+2
|
* af: avoid rebuilding filter chain in another minor casewm42016-07-151-0/+3
| | | | | No need to create additional noise of we can trivially see that rebuiding the chain won't change anything.
* audio: fix code for adjusting conversion filterswm42016-07-111-4/+5
| | | | | | | | | | | | | | | This code was supposed to adjust existing conversion filters (to make them output a different format). But the code was just broken, apparently a refactoring accident. It accessed af instead of af->prev. The bug tended to add new conversion filters, even if an existing one could have been used. (Can be tested by inserting a dummy lavrresample filter followed by a format filter which forces conversion.) In addition, it's probably better to return the actual error code if reinitializing the filter fails. It would then respect an AF_FALSE return value, which means format negotiation failed, instead of a generic error.
* af_volume: don't let softvol overwrite af_volume volumedb sub-optionwm42016-07-111-2/+2
| | | | | | | | | | af_volume has a volumedb sub-option, which allows the user to set an explicit volume. Until recently, the player read back this value and used it as initial softvol volume. But now it just overwrites it. Instead of overwriting it, multiply the different gain values. Above all, this will do the right thing if only softvol is used, or if the user only adds the af_volume filter manually.
* audio: add heuristic to move auto-downmixing before other filterswm42016-07-101-7/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Normally, you want downmixing to happen first thing in the filter chain. This is reflected in codec downmixing, which feeds the filter chain downmixed audio in the first place. Doing this has the advantage of needing less data to process. But the main motivation is that if there is a drc filter in the chain, you want to process it the downmixed audio. Add an idiotic heuristic to achieve this. It tries to detect whether the audio was indeed automatically downmixed (or upmixed). To detect what the output format is going to be, it builds the filter chain normally, and then retries with the heuristic applied (and for extra paranoia, retries without the heuristic again if it fails to successfully rebuild the filter chain for unknown reasons). This is simple and will work in almost all cases. Doing it in a more complete way is rather hard, because filters are so generic. For example, we know absolutely nothing about the behavior of af_lavfi, which creates an opaque filter graph with libavfilter. We don't know why a filter would e.g. change the channel layout on its output. (Our heuristic bails out in this case.) We're also slave to the lowest common denominator of how our format negotiation works, and how libavfilter's works. In theory, we could make this mechanism explicit by introducing a special dummy filter. The filter chain would then try to convert between input and output formats at the dummy filter, which would give the user more control over how downmix happens. On the other hand, the user could just insert explicit conversion filters instead, so this would probably have questionable value.
* audio: add auto-inserted flag to filter list loggingwm42016-07-101-0/+2
| | | | Like the video filter chain.
* audio: cleanup audio filter format negotiationwm42016-07-103-149/+62
| | | | | | | | | | | | | | | | | | The algorithm and functionality is the same, but the code becomes much simpler and easier to follow. The assumption that there is only 1 conversion filter (lavrresample) helps with the simplification, but the main change is to use the same code for format/channels/rate. Get rid of the different AF_CONTROL_SET_* controls, and change the af->data parameters directly. (af->data is badly named, but essentially is a placeholder for the output format.) Also, instead of trying to use the af_reinit() loop to init inserted conversion filters or filters with changed output formats, do it inline, and move the common code to a filter_reinit() function. This gets rid of the awful retry variable. In general, this should not change any runtime behavior.
* audio: insert audio-inserted filters at end of chainwm42016-07-091-34/+1
| | | | | | This happens to be better for the af_volume filter (for softvol), and saves some code too. It's "better" because you want to affect the final filtered audio, such as after a manually inserted drc filter.
* vf, af: print filter labels in verbose modewm42016-07-061-0/+2
|
* Fix misspellingsstepshal2016-06-261-1/+1
|
* af_lavcac3enc: use av_err2str() call (fixes Libav build)wm42016-06-231-2/+1
| | | | | I added this call because I thought it'd be nice, but Libav doesn't have this function (macro, actually).
* af_lavcac3enc: make encoder configurablewm42016-06-231-2/+5
|
* af_lavcac3enc: implement flushing on seekwm42016-06-231-0/+7
| | | | | There's a lot of data that could have been buffered, and which has to be discarded.
* af_lavcac3enc: port to new encode APIwm42016-06-231-9/+57
|
* af_lavcac3enc: automatically configure most encoder parameterswm42016-06-231-29/+57
| | | | | | | | | | | Instead of hardcoding what the libavcodec ac3 encoder expects, configure it based on the AVCodec fields. Unfortunately, it doesn't export the list of sample rates, so that is done manually. This commit actually fixes the rate always to 48Khz. I don't even know whether the other rates worked. (Possibly did, but they'd still change the spdif parameters, and would work differently from ad_spdif.c.)
* af_lavcac3enc: drop log message prefixeswm42016-06-231-9/+7
| | | | MPlayer leftover. They're already added by the logging code.
* af_lavcac3enc: fix custom bitrateswm42016-06-231-2/+3
| | | | | | Probably has been broken for ages. (Not sure why anyone would use this feature, though.)
* build: make libavfilter mandatorywm42016-02-051-2/+0
| | | | | | The complex filter support that will be added makes much more complex use of libavfilter, and I'm not going to bother with adding hacks to keep libavfilter optional.
* af_lavrresample: change fudged channelswm42016-02-041-2/+2
| | | | | | | | | | | | | Remove flc-frc <-> sl<->sr. This was just plain wrong, and a mistaken change to make 7.1 work properly on CoreAudio with 7.1(rear) layout. Also see the following commit. Add br-br <-> sl<->sr, because we decided that it makes sense. Note that this "fudging" is applied only if the channel pairs are replaced, i.e. they would get dropped and be replaced with silence. This is done to compensate for libswresample's default rematrixing (which takes care of some more common cases).
* audio: move mp_audio->AVFrame conversion to a functionwm42016-01-291-20/+3
| | | | | | | | | This also makes it refcounted, i.e. the new AVFrame will reference the mp_audio buffers, instead of potentially forcing the consumer of the AVFrame to copy the data. All the extra code is for handling the >8 channels case, which requires very messy dealing with the extended_ fields (not our fault).
* af_lavfi, vf_lavfi: fix compilation on Libavwm42016-01-221-0/+1
| | | | It has no avfilter_graph_send_command().
* command: add af-command commandwm42016-01-223-0/+21
| | | | Similar to vf-command. Requested. Untested.
* audio: change downmix behavior, add --audio-normalize-downmixwm42016-01-203-4/+10
| | | | | | This is probably the 3rd time the user-visible behavior changes. This time, switch back because not normalizing seems to be the more expected behavior from users.
* Relicense some non-MPlayer source files to LGPL 2.1 or laterwm42016-01-192-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
* af_lavrresample: fudge some channel layout conversionwm42016-01-181-0/+33
| | | | | | | | | | | | Prevents channels from being dropped, e.g. when going 7.1 -> 7.1(wide) and similar cases. The reasoning here is that channel layouts over HDMI don't work anyway, and not dropping a channel and playing it on a slightly "wrong" (but expected) speaker is preferable to playing silence on these speakers. Do this to remove issues with ao_coreaudio. Frankly I'm not sure whether our mapping (between CA and mpv/FFmpeg speakers) is correct, but on the other hand due to the reasons stated above it's not all that meaningful.
* af_lavrresample: fix build on Libavwm42015-11-261-1/+1
| | | | | | | Of course, only FFmpeg has av_clipd(), while Libav does not. (Nevermind that it doesn't do much more than the mpv MPCLAMP() macro. Supposedly, libavutil can provide optimized platform-specific versions for av_clip*, but of course nothing actually does for av_clipf() or av_clipd().)
* af_lavrresample: clamp float output to rangewm42015-11-251-0/+12
| | | | | | | libswresample doesn't do it - although it should, but the patch is stuck in limbo. Probably reduces problems with artifacts on downmixing in some cases.
* af_lavrresample: simplify set_compensation usagewm42015-11-111-13/+12
| | | | | | | | | | | | | Just set the ratio directly by working around the intended semantics of the API function. The silly rounding stuff we had isn't needed anymore (and not entirely correct anyway). Note that since the compensation is virtually active forever, we need to reset if it's not needed. So always run this code to be sure to reset it. Also note that libswresample itself had a precision issue, until it was fixed in FFmpeg commit 351e625d.
* audio: do not require full audio chain reinit for speed changeswm42015-11-041-3/+0
| | | | | | | | | | | | | | | Actually, it didn't really require that before (most work was avoided), but some bits had to be run anyway. Separate the speed change into a light-weight function, which merely updates already created filters, and a heavy-weight one which messes with filter insertion. This also happens to fix the case where the filters would "forget" the current speed (force resampling, change speed, hit a volume control to force af_volume insertion - it will reset speed and desync). Since we now always run the light-weight function, remove the af_scaletempo verbose message that is printed on speed setting. Other than that, all setters are cheap.
* af_lavcac3enc: simplify/fix AVPacket handlingwm42015-11-041-16/+21
| | | | | | For some reason, the encoder didn't like that the AVPacket already had fields set. I'm not quite sure, but this might just be invalid API usage. Do it as it's recommended.
* Revert "af_lavrresample: don't drop sl/sr channels for 7.1 on ALSA"wm42015-11-041-28/+5
| | | | | | | | | | | This reverts commit 4e358a963604af8746a059d7388cb202be0f919d. Testing shows the channel pairs must indeed be swapped (details see commit message of the reverted commit). Making the downmix code move sl/sr to sdl/sdr is not an appropriate solution anymore, and it's better to fix the unusual channel layout in ao_alsa.c directly. (Not reverting the change in chmap.c; this is still correct.)
* af_lavrresample: don't drop sl/sr channels for 7.1 on ALSAwm42015-11-031-5/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ao_alsa: attempt to fix 7.1 over HDMI The last 2 channels of 7.1 (RLC/RRC in ALSA) were exported as sdl/sdr instead of sl/sr (I don't even know why I chose sdl/sdr, but SL/SR and RLC/RRC are different in the ALSA API). libsw/avresample do not move the sl/sr channels to sdl/sdr when rematrixing, so silence was sent for 2 channels. If my selection of sdl/sdr is essentially API abuse, there's no reason why they should do this differently. The mess here is really that ALSa doesn't map the HDMI layouts cleanly. Most ALSA drivers export 7.1 in a way compatible to our expectations, but Intel HDA/HDMI does not: mpv/ffmpeg: fl-fr-fc-lfe-bl-br-sl-sr ALSA/generic: FL FR FC LFE RL RR SL SR [1] ALSA/HDMI: FL FR LFE FC RL RR RLC RRC [2] The HDMI layout is layout 0x13 (going by CEA-861-B). The comment in the kernel code has to be correct too. The early standard defines only 1 other layout, which replaces RLC/RRC with FRC/FLC - this probably corresponds to what we call "7.1(wide)". So it appears when ALSA requests RLC/RRC, we should feed it sl/sr. To make it more complicated, Kodi/xbmc apparently also have to deal with ALSA being special, but instead of sending sl/sr to RLC/RRC, they swap the last two pairs of the layout, and send sl/sr to RL/RR and bl/br to RLC/RRC. Or I might have misunderstood their code. I don't have a 7.1-capable A/V receiver, so I can't test this. For now, go with the simpler solution, and wait until someone tests it. If the speakers end up swapped, a completely different solution will be needed. [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/sound/core/pcm_lib.c?id=refs/tags/v4.3#n2434 [2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/sound/pci/hda/patch_hdmi.c?id=refs/tags/v4.3#n307
* Replace deprecated av_free_packet() callswm42015-10-281-1/+1
| | | | | | av_free_packet() got finally deprecated. Use av_packet_unref() instead, which has almost the same semantics, has existed for a while, and is available in all FFmpeg and Libav versions we support.
* audio: use AVFrames with more than 8 channels correctlywm42015-10-261-3/+5
| | | | | | | Requires messy dealing with the extended_ fields. Don't bother with af_lavfi and ao_lavc for now. There are probably no valid use-cases for these.
* af_lavrresample: make planarization pass work with >8 channelswm42015-10-261-4/+5
| | | | | | | | | | av_get_default_channel_layout() fails with channel counts larger than 8. The channel layout doesn't need to make sense, so pick an arbitrary fallback. libswresample also has options for setting the channel counts directly, but better not introduce new concepts in the code. Also, libavresample doesn't have these options.
* af: prevent endless loop when removing filters due to spdifwm42015-10-261-1/+2
| | | | | | | | | | | | | | | | | | | | | This code removes filters which can not take spdif inout. This was made so that PCM filters are transparently dropped in spdif mode. This entered an endless loop with: --af=lavcac3enc:::2 --audio-channels=5.1 The forced number of output channels is incompatible with spdif. It's trying to insert af_lavrresample as conversion filter to compensate for it. Of course this doesn't work, which triggers the PCM filter removal. Then it goes on normally - since the new state is exactly as before, it will try the same thing again, forever. Fix by reusing the retry counter, which is a very dumb but very effective measure against these cases of filter negotiation failure. We could try to be more clever (for example, if the removed filter is a conversion filter, we can be sure this won't work, and error out immediately). But better keep it simple and robust.
* af_lavrresample: fix unintended audio drift when setting playback speedwm42015-10-141-3/+9
| | | | | | | | | | | | | | Small adjustments to the playback speed use swr_set_compensation() to stretch the audio as it is required. But since large adjustments are now handled by actually reinitializing libswresample, the small adjustments get rounded off completely with typical frame sizes. Compensate for this by accounting for the rounding error and keeping track of fractional samples that should have been output to achieve the correct ratio. This fixes display sync mode behavior, which requires these adjustments to be relatively accurate.
* af_lavrresample: reinit resampler on large speed changeswm42015-10-121-15/+19
| | | | | | swr/avresample_set_compensation() was made for small speed adjustments. Non-documentation says it should be used for changes not larger than 1%, so reinitialize the sampler if the change is larger than that.
* af_lavrresample: use libswsresample dynamic rate adjustment featurewm42015-10-071-9/+26
| | | | | | | | | | swr_set_compensation() changes the apparent sample rate on the fly (who would have guessed). It is thus very well-suited for adjusting audio speed on the fly during playback (like needed by the display-sync mode). It skips the relatively slow resampler reinitialization. If this doesn't work (libswresample soxr backend), then fall back to the old method.
* audio/filter: remove reentrancy flagwm42015-09-205-22/+1
| | | | | | | | | | This flag was used by some filters and made sure none of these filters were inserted twice. This triggers only if the user explicitly tries to add multiple filters (and not e.g. due to auto-insertion), so at best this warned the user from doing something potentially pointless. At worst, it blocked some (mildly) legitimate use-cases. Get rid of it. Also see #2322.
* af_lavfi: implement af-metadata propertywm42015-09-113-0/+37
| | | | | | | Works like vf-metadata. Unfortunately requires some code duplication (even though it's not much). Fixes #2311.
* af: use generic statuc codeswm42015-09-111-7/+7
| | | | | | | The reason MPlayer traditionally duplicated them all over the place is that it wanted every component to be a self-contained library (e.g. audio filters were in "libaf"). But this is not necessarily helpful, and this change makes the following commit a bit simpler.
* af_lavrresample: remove unnecessary indirectionswm42015-09-081-35/+30
| | | | | | | Not sure why struct af_resample_opts even exists. It seems useful to group the fields set by user options. But storing the current format conversion parameters doesn't seem very elegant, and having a separate instance in the "ctx" field isn't helpful either.
* af_lavrresample: add normalize suboptionwm42015-09-081-1/+6
|
* af_lavrresample: add missing include statementwm42015-09-041-0/+1
| | | | | | Apparently, this broke compilation with Libav under some circumstances. Looking at it again, it shouldn't have, but this change doesn't hurt anyway.
* audio/filter: remove af_bs2b toowm42015-09-042-171/+0
| | | | | | | Some