summaryrefslogtreecommitdiffstats
path: root/audio
Commit message (Collapse)AuthorAgeFilesLines
* ad.h: change license to LGPLwm42017-05-051-7/+7
| | | | | | | | All authors have agreed. Commit 94d3170bd05 is a bit murky: Nick could not be reached, and arpi's changes were obviously inspired or copied from Nick's. However, the changed symbols were removed and do not exist anymore.
* audio/fmt-conversion: change license to LGPLwm42017-05-052-14/+14
| | | | | | | Although pretty similar to the probably unrelicensable video/fmt-conversion.c/h (basically using the same idea, but for audio), it was written by someone else. The format mapping was first added in commit ad95e046c2451.
* af: remove unused GET_VOLUME codewm42017-04-272-6/+0
| | | | The entire af code is going to be removed, but Ordnung muss sein.
* audio: fix replaygain volume scalewm42017-04-271-1/+1
| | | | | | | | The new replaygain code accidentally applied the linear gain as cubic volume level. Fix this by moving the computation of the volume scale out of the af_volume filter. (Still haven't verified whether the replaygain code works correctly.)
* options: remove remaining deprecated audio device selection optionswm42017-04-236-38/+3
|
* ao_openal: kill off device listingwm42017-04-231-41/+1
| | | | | Probably helps with #4311. It surely is not the correct fix, of course. But ao_openal has no business of causing trouble anyway.
* ao_wasapi_changenotify: use %ls instead of %S for wchar_twm42017-04-201-4/+4
| | | | | %ls is C99. %S is supported by some systems, including MinGW/MSVC, but no reason to use it.
* ao_wasapi_changenotify: fix potential race conditionwm42017-04-201-8/+8
| | | | | | | IMMDeviceEnumerator_RegisterEndpointNotificationCallback() will start listening for notifications, and is the point at which callbacks can start firing. These callbacks will read the fields we set after the register calls, which is a potential race condition. Move it upwards.
* vf_lavfi, af_lavfi: remove unused/deprecated includewm42017-04-051-1/+0
| | | | | Looks like Libav is going to drop it, unnecessarily making compilation fail.
* audio: deprecate most audio filterswm42017-04-044-0/+8
| | | | | Well, ok, only 4 filters. The rest will survive in one or the other form.
* af: implement generic lavfi option bridge toowm42017-04-042-10/+99
| | | | | | Literally copy-pasted from the same commit for video filters. (Once new code for filters is implemented, this will all go away or at least get unified anyway.)
* af_lavfi: remove forced "format" filterwm42017-04-041-27/+2
| | | | | | | This was supposed to restrict output to formats supported by us. But we usually support all FFmpeg sample formats anyway (if not, it will error out gracefully, and we would add the missing format). Basically, it's just useless bloat.
* audio: lower "Disabling multichannel output." warning to verbosewm42017-04-021-1/+1
| | | | Not sure why it was a warning in the first place.
* ao_wasapi: do not pass nonsense to drivers with doublewm42017-03-291-5/+23
| | | | | | | | | | | | | | | | | | | | | | This tried to use AF_FORMAT_DOUBLE as KSDATAFORMAT_SUBTYPE_IEEE_FLOAT, with wBitsPerSample==64. This is probably not allowed, and drivers appear to react inconsistently to it. (With one user, the format was accepted during format negotiation, but then rejected on actual init.) Remove it, which essentially forces it to fall back to some other format. (Looks like it'll use af_select_best_samplerate(), which would probably make it try S32 next.) The af_fmt_from_planar() is so that we don't have to care about AF_FORMAT_FLOATP. Wasapi always requires packed data anyway. This should actually handle other potentially unknown sample formats better. This changes that set_waveformat() always set the exact format. Now it might set a "close" format instead. But all callers seem to deal with this well. Although in theory, callers should probably handle the fallback. The next cleanup (if ever) can take care of this.
* command: add better runtime filter toggling methodwm42017-03-251-0/+3
| | | | | | | | | | Basically, see the example in input.rst. This is better than the "old" vf-toggle method, because it doesn't require the user to duplicate the filter string in mpv.conf and input.conf. Some aspects of this changes are untested, so enjoy your alpha testing.
* af_drc: removeJan Janssen2017-03-252-336/+0
| | | | | | | | | | | | | | | | Remove low quality drc filter. Anyone whishing to have dynamic range compression should use the much more powerful acompressor ffmpeg filter: mpv --af=lavfi=[acompressor] INPUT Or with parameters: mpv --af=lavfi=[acompressor=threshold=-25dB:ratio=3:makeup=8dB] INPUT Refer to https://ffmpeg.org/ffmpeg-filters.html#acompressor for a full list of supported parameters. Signed-off-by: wm4 <wm4@nowhere>
* ao_jack: update latency on buffer_size/graph changeCheng Sun2017-03-181-7/+34
| | | | | | | The buffer_size may be updated before the process callback is called for the first time. Or, the connection graph could change, which changes the latency of the pipeline after mpv's output. Ensure we keep on top of these changes by registering callbacks to update our latency estimation.
* ao_alsa: fix device filtering, add another exceptionwm42017-03-141-1/+3
| | | | | | | The "return false;" was debugging code. In addition, filter a plain "default", because it's not going to do anything interesting and just looks ugly.
* ao_alsa: filter fewer deviceswm42017-03-141-4/+2
| | | | | | | | | | | | It appears some device can be missing if we filter too many. In particular, I've seen devices starting with "front" and "sysdefault" being mapped to different hardware. I conclude that it's not sane trying to present a nice device list to users in ALSA. It's fucked. (Although kodi appears to attempt some intense "beautification" of the device list, which includes parsing parameters from the device name and such. Well, let's not.) No other audio API requires such ridiculous acrobatics.
* ao_alsa: POLLERR can be set even if the device is not lostwm42017-03-141-1/+5
| | | | | | | | | | Apparently POLLERR can be set if poll is called while the device is in the SND_PCM_STATE_PREPARED state. So assume that we can simply call snd_pcm_status() to check whether the error is because the device went away (i.e. we expect it to return ENODEV if this happened). This avoids sporadic device lost warnings and AO reloads. The actual device lost case is untested.
* options: add M_OPT_FILE to some more file optionsPhilip Sequeira2017-03-061-1/+1
| | | | (Helps shell completion.)
* ao_alsa: close audio device if polling returns POLLERRwm42017-02-271-1/+3
| | | | | | | | This is apparently what happens in this situation: Turn off display with DPMS, turn back on with DPMS. MPV is hung. See #4189.
* ao_alsa: fix an error checkwm42017-02-271-1/+1
| | | | Fixes #4188 as pointed out in the issue.
* ao: never set ao->device = ""Kevin Mitchell2017-02-201-2/+3
| | | | | | | For example, previously, --audio-device='alsa/' would provide ao->device="" to the alsa driver in spite of the fact that this is an already parsed option. To avoid requiring a check of ao->device[0] in every driver, make sure this never happens.
* dec_video, dec_audio: remove redundant NULL-checkswm42017-02-201-2/+1
| | | | OK, they're redundant. Now stop wasting my time, coverity.
* ao: fix potential NULL deref in ao_device_list_add()wm42017-02-201-2/+2
| | | | | | Probably didn't happen in practice, but anyway. Found by coverity.
* ao_oss: fix mixer channel messageKevin Mitchell2017-02-081-1/+1
|
* ao_oss: use --audio-device if --oss-device isn't set.Kevin Mitchell2017-02-081-6/+10
| | | | | | | | | | | | | | Fall back on PATH_DEV_DSP if nothing is set. This mirrors the behaviour of --audio-device / --alsa-device. There doesn't appear to be a general way to list devices with oss, so --audio-device=help doesn't list oss devices except for the default one if the file exists. Previously --audio-device was ignored entirely by ao_oss. fixes #4122
* player: add experimental stream recording featurewm42017-02-072-0/+6
| | | | | This is basically a WIP, but it can't remain in a branch forever. A warning is print when using it as it's still a bit "shaky".
* win32: add COM-specific SAFE_RELEASE to windows_utils.hJames Ross-Gowan2017-01-304-30/+27
| | | | | | | | | | | | | | | See: https://msdn.microsoft.com/en-us/library/windows/desktop/dd743946.aspx Microsoft example code often uses a SAFE_RELEASE macro like the one in the above link. This makes it easier to avoid errors when releasing COM interfaces. It also reduces noise in COM-heavy code. ao_wasapi.h also had a macro called SAFE_RELEASE, though unlike the version above, its SAFE_RELEASE macro accepted a second parameter which allowed it to destroy arbitrary objects other than just COM interfaces. This renames ao_wasapi's SAFE_RELEASE to SAFE_DESTROY, which should more accurately reflect what it does and prevent confusion with the Microsoft version.
* build: explicitly check for FFmpeg vs. Libav, and their exact versionswm42017-01-271-0/+3
| | | | | | | | | | | | | | | | | | In a first pass, we check whether libavcodec is present. Then we try to compile a snippet and check for FFmpeg vs. Libav. (This could probably also be done by somehow checking the pkgconfig version. But pkg-config can't deal with that idiotic FFmpeg idea that a micro version number >= 100 identifies FFmpeg vs. Libav.) After that we check the project-specific version numbers. This means it can no longer happen that we accidentally allow older, unsupported versions of FFmpeg, just because the Libav version numbers are somehow this way. Also drop the resampler checks. We hardcode which resampler to each with each project. A user can no longer force use of libavresample with FFmpeg.
* ad_lavc, vd_lavc: move mpv->lavc decoder parameter setup to common codewm42017-01-251-13/+5
| | | | | | | | This can be useful in other contexts. Note that we end up setting AVCodecContext.width/height instead of coded_width/coded_height now. AVCodecParameters can't set coded_width, but this is probably more correct anyway.
* build: replace some FFmpeg API checks with version checkswm42017-01-242-3/+3
| | | | | | The FFmpeg versions we support all have the APIs we were checking for. Only Libav missed them. Simplify this by explicitly checking for FFmpeg in the code, instead of trying to detect the presence of the API.
* ad_lavc: respect AV_FRAME_FLAG_DISCARDwm42017-01-241-0/+5
| | | | | | | Since we set "skip_manual", we can actually get frames with this set. Currently, only AV_PKT_FLAG_DISCARD will trigger this flag, and only mov.c sets the latter flags, so this is related to FFmpeg's half-broken mp4 edit list support.
* ad_spdif: log avformat errorswm42017-01-191-1/+3
|
* ad_spdif: fix obscure cases of AC3 passthroughwm42017-01-181-7/+28
| | | | | | | | | Apparently you set the native sample rate when passing through AC3. This fixes passthrough with 44100 Hz AC3. Avoid opening a decoder for this and only open the parser. (Hopefully DTS will also support this some time in the future or so - having to open a decoder just to get the profile is dumb.)
* audio: restructure decode loopwm42017-01-114-57/+85
| | | | | | | Same deal as with video. Including the EOF handling. (It would be nice if this code were not duplicated, but right now we're not even close to unifying the audio and video code paths.)
* audio/out/push: merge if branches with same conditionwm42017-01-091-4/+3
| | | | Cosmetic change.
* af_lavfi, vf_lavfi: work around recent libavfilter EOF bugwm42017-01-021-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | Looks quite like a bug. If you have a filter chain with only the dynaudnorm filter, and send call av_buffersrc_add_frame(s, NULL), then subsequent av_buffersink_get_frame() calls will return EAGAIN instead of EOF. This was apparently caused by a recent change in FFmpeg. Some other circumstances (which I didn't fully analyze and which is due to the playloop's absurd temporary-EOF behavior on seeks) then led the decoder loop to send data again, but since libavfilter was stuck in the EOF state now, it could never recover. It kept sending new input (due to missing output), until the demuxer refused to return more audio packets. Each time a filter error was printed. Fortunately, it's pretty easy to workaround. We just mark the p->eof flag as we send an EOF frame to libavfilter. The p->eof flag is used only to recover from temporary EOF: it resets the filter if new data is available again. We don't care much about av_buffersink_get_frame() returning a broken EAGAIN state in this situation and essentially ignore it, meaning if we get EAGAIN after sending EOF, we assume effectively that EOF was fully reached.
* options: deprecate codec family selection in --vd/--adwm42016-12-231-7/+4
| | | | | Useless now, so get rid of it. Also affects some user-visible display things (like reported codec in use).
* audio: change how spdif codecs are selectedwm42016-12-233-13/+48
| | | | | | | | | | | | | | Remove ad_spdif from the normal codec list, and select it explicitly. One goal was to decouple this from the normal codec selection, so they're less entangled and the decoder selection code can be simplified in the far future. This means spdif codec selection is now done explicitly via select_spdif_codec(). We can also remove the weird requirements on "dts" and "dts-hd" for the --audio-spdif option, and it can just do the right thing. Now both video and audio codecs consist of a single codec family each, vd_lavc and ad_lavc.
* ad_lavc, vd_lavc: don't set AVCodecContext.refcounted_frameswm42016-12-181-1/+0
| | | | | This field is (or should be) deprecated, and there's no need to set it with the new API.
* ad_spdif: Fix crash when spdif muxer is not availableMichael Forney2016-12-111-0/+1
| | | | | | | Currently, if init_filter fails after lavf_ctx is allocated, uninit is called which frees lavf_ctx, but doesn't clear the pointer in spdif_ctx. So, on the next call of decode_packet, it thinks it is already initialized and uses it, resulting in a crash on my system.
* Remove compatibility thingswm42016-12-075-75/+1
| | | | | | Possible with bumped FFmpeg/Libav. These are just the simple cases.
* ao_alsa: print certain ALSA errors as string instead as numberwm42016-12-071-2/+2
|
* ao_wasapi: log return code when probing audio formatswm42016-11-302-13/+9
| | | | | | | | | We log a large number of formats, but we rarely log the result of the probing. Change this. The logic in try_format_exclusive() changes slightly, but should be equivalent. EXIT_ON_ERROR() checks for FAILED(), which should be exclusive to SUCCEEDED().
* ao_wasapi_utils: remove unused variablepavelxdd2016-11-271-1/+0
| | | | | Introduced in 1a2319f3e4cc42c680e2fd3ba30022c7a9adf3fe Produced a warning during compilation on Windows.
* options: remove deprecated sub-option handling for --vo and --aowm42016-11-2518-64/+23
| | | | | | | | Long planned. Leads to some sanity. There still are some rather gross things. Especially g_groups is ugly, and a hack that can hopefully be removed. (There is a plan for it, but whether it's implemented depends on how much energy is left.)
* audio/out/push: play silence on --audio-stream-silencewm42016-11-242-13/+34
| | | | | | | | | | | | | | | | | | | Until now, this was only implemented for ao_alsa and AOs not using push.c. ao_alsa.c relied on enabling funny underrun semantics for avoiding resets on lower levels, while other AOs using push.c didn't do anything. Change this and at least make push.c copy silent data to the AO. This still isn't perfect as keeping track of how much silence was played when seems complex, so we don't do it. The consequence is that frame-stepping will essentially randomize the A/V offset (it'll recover immediately when unpausing, but still ugly). Also, in order to empty the currently buffered audio on seeks etc., we still call ao_driver->reset and so on, so the AO driver will still need to handle this specially. The intent is to make behavior with ALSA less weird (for one we can remove the code in ao_alsa.c that tries to trigger an initial underflow). Also might help with #3754.
* audio: fix --audio-stream-silence with ao_wasapiwm42016-11-211-2/+4
| | | | | Seems like wasapi will restart the HDMI stream if resume is called during playback.
* audio: fix --audio-stream-silence with ao_alsawm42016-11-211-2/+3
| | | | | | | ao_alsa.c calls this before the common code sets ao->sstride. Other than this, I'm still not sure whether this works. Seems like no, or depends.
* ao_alsa: explicitly add default device manuallywm42016-11-141-1/+4
| | | | | | | | | | | | | | The "default" entry (which is and always was mpv/mplayer's default) does not have a description set in the ALSA API. (While "sysdefault" strangely has.) Instead of an empty description, this should show something nice, so reuse the ao.c code for naming default devices (see previous commit). It's still a bit ugly that audio-device-list will have a default entry for "Autoselect device" and "Default (alsa)", but then again we probably want to allow the user to force ALSA (i.e. prevent fallbacks to other AOs) just because ALSA is so flaky and makes this a legitimate feature.
* audio: make empty device ID mean default devicewm42016-11-141-7/+14
| | | | | | | | | This will make it easier for AOs to add explicit default device entries. (See next commit.) Hopefully this change doesn't lead accidentally to bogus "Default" entries to appear, but then it can only happen if the device ID is empty, which would mean the underlying audio API returned bogus entries.
* audio: avoid returning audio-device-list entries without descriptionwm42016-11-141-0/+2
| | | | | | Use the device name as fallback. This is ugly, but still better than skipping the description entirely. This can be an issue on ALSA, where the API can return entries without proper description.
* dec_video, dec_audio: avoid full reinit on switches to the same segmentwm42016-11-091-6/+9
| | | | | | Same deal as with the previous commit. (Unfortunately, this code is still duplicated.)
* ao_alsa: fill unused ALSA channels with silencewm42016-11-081-0/+5
| | | | | | | | | | This happens when ALSA gives us more channels than we asked for, for whatever reasons. It looks like this wasn't handled correctly. The mpv and ALSA channel counts could mismatch, which would lead to UB. I couldn't actually trigger this case, though. I'm fairly sure that drivers or plugins exist that do it anyway. (Inofficial ALSA motto: if it can be broken, then why not break it?)
* ao_alsa: strictly disable chmap use for mono/stereowm42016-11-081-12/+21
| | | | | | | | | | If the input is already mono or stereo, or if channel map selection results in mono or stereo, then disable further use of the champ ALSA API (or rather, stop trusting its results). Then we behave like a simple application that only wants to output mono or stereo. See #3045 and #2905. I couldn't actually test these cases, but this commit is supposed to fix them.
* ao_alsa: _really_ disable chmap API use in cases where we shouldwm42016-11-081-3/+7
| | | | | | | | | | | set_chmap() skipped _setting_ the ALSA chmap if chmap use was requested to be disabled by setting dev_chmap.num=0 by the caller, but it still queried the current ALSA channel map. We don't trust it that much, so disable that as well. But we still query and log it, because that could be helpful for debugging. Otherwise we could skip the entire set_chmap() call in these cases.
* ao_alsa: slightly better debug loggingwm42016-11-081-6/+12
| | | | | | | Try to make it more compact, and also always list the reordered layout, but only if it's actually different. Should be the same functionally.
* audio/out: add AudioUnit output driver for iOSAman Gupta2016-11-016-5/+227
|
* ad_lavc, vd_lavc: fix a recent libavcodec deprecation warningwm42016-10-171-1/+2
| | | | | | | | | | | | | | Both AVFrame.pts and AVFrame.pkt_pts have existed for a long time. Until now, decoders always returned the pts via the pkt_pts field, while the pts field was used for encoding and libavfilter only. Recently, pkt_pts was deprecated, and pts was switched to always carry the pts. This means we have to be careful not to accidentally use the wrong field, depending on the libavcodec version. We have to explicitly check the version numbers. Of course the version numbers are completely idiotic, because idiotically the pkg-config and library names are the same for FFmpeg and Libav, so we have to deal with this explicitly as well.
* ao_alsa: try to fallback to "hdmi" before "iec958" for spdifwm42016-10-07