summaryrefslogtreecommitdiffstats
path: root/audio
Commit message (Collapse)AuthorAgeFilesLines
* af_scaletempo2: use gcc vectors to speed up inner loopNiklas Haas2021-05-261-3/+72
| | | | | | | | | | This brings my scaletempo2 benchmark down from ~22s to ~7s on my machine (-march=native), and down to ~11s with a generic compile. Guarded behind an appropriate #ifdef to avoid being ableist against people who have the clinical need to run obscure platforms. Closes #8848
* build: address AVCodec, AVInputFormat, AVOutputFormat const warningssfan52021-05-013-3/+3
| | | | FFmpeg recently changed these to be const on their side.
* ao/pulse: fix incorrect state reported after resetsfan52021-04-291-0/+1
| | | | fixes #8768
* audio/aframe: reuse data buffer if less than 8 channelssfan52021-04-081-6/+12
| | | | | | | | This fixes audio encoding crashing under ASan. When extended_data != data, FFmpeg copies more pointers from extended_data (= the number of channels) than there really are for non-planar formats (= exactly 1), but that's not our fault. Regardless, this commit makes it work in all common cases.
* ao_oss: add this audio output againrim2021-03-152-0/+414
| | | | | | | | | | | Changes: - code refactored; - mixer options removed; - new mpv sound API used; - add sound devices detect (mpv --audio-device=help will show all available devices); - only OSSv4 supported now; Tested on FreeBSD 12.2 amd64.
* ao/pulse: signal the mainloop when ops are doneThomas Weißschuh2021-03-111-2/+5
| | | | | | | | Without the explicit signal the call to pa_threaded_mainloop_wait() will not return as soon as possible. Fixes 4f07607888541e6eb40fc5c3a1edfeb84aacb0f7 See #8633
* ao/pulse: wait for command completion when setting volume or muteThomas Weißschuh2021-03-091-13/+8
| | | | | | | | | | | | | | | | This makes the behavior of all control messages consistent, fixing an inconsistency that has been with us since 4d8266c739915184d3787d7ab727ac03378b341b - which is the initial rework of the polyaudio AO into the pulseaudio AO. Muting the stream also directly triggers an update to the OSD. When not waiting for the command completion this read of the mute property may read the old state. A stale read. Note that this somehow was not triggered on native Pulseaudio, but it is an issue on Pipewire. See https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/868
* af_scaletempo2: fix crash for speed >= 16Dorian Rudolph2021-02-151-9/+13
| | | | | | | The input buffer size was fixed, but the required size depends on the speed. Now the buffer will be resized dynamically. Fixes #8081
* ao_alsa: handle -EPIPE XRUNs from snd_pcm_statusJan Ekström2020-11-091-2/+11
| | | | | | | | | Set pcm state to SND_PCM_STATE_XRUN in case -EPIPE is received, and handle this state as per the usual logic. This way snd_pcm_prepare gets called, and the loop continued. Inspired by a patch posted by malc_ on #mpv.
* ao_alsa: always initialize state if passedJan Ekström2020-11-091-9/+7
| | | | | Based on ao_play_data's assert, we are always expected to give non-default values back from an AO's get_state.
* audio: take paused state into account in ao_start()sfan52020-09-201-1/+1
| | | | | It makes no sense to instruct the AO to start the pull callbacks when we know there's nothing to play (only affects pull AOs).
* audio: move start() calls outside of locksfan52020-09-201-3/+10
| | | | | Pull based AOs might want to call ao_read_data() inside start(). This fixes ao_opensles deadlocking.
* ao_alsa: make partial writes an error messagewm42020-09-031-2/+2
| | | | And I think "partial write" is easier to understand than "short write".
* audio: fix stream-silence with push AOs (somewhat)wm42020-09-031-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | --audio-stream-silence is a shitty feature compensating for awful consumer garbage, that mutes PCM at first to check whether it's compressed audio, using formats advocated and owned by malicious patent troll companies (who spend more money on their lawyers than paying any technicians), wrapped in a wasteful way to make it constant bitrate using a standard whose text is not freely available, and only rude users want it. This feature has been carelessly broken, because it's complicated and stupid. What would Jesus do? If not getting an aneurysm, or pushing over tables with expensive A/V receivers on top of them, he'd probably fix the feature. So let's take inspiration from Jesus Christ himself, and do something as dumb as wasting some of our limited lifetime on this incredibly stupid fucking shit. This is tricky, because state changes like end-of-audio are supposed to be driven by the AO driver, while playing silence precludes this. But it seems code paths for "untimed" AOs can be reused. But there are still problems. For example, underruns will just happen normally (and stop audio streaming), because we don't have a separate heuristic to check whether the buffer is "low enough" (as a consequence of a network stall, but before the audio output itself underruns).
* ao_lavc: slightly simplify filter usewm42020-09-031-12/+12
| | | | | | Create a central function which pumps data through the filter. This also might fix bogus use of the filter API on flushing. (The filter is just used for convenience, but I guess the overall result is still simpler.)
* ao_alsa: log more information on short writeswm42020-09-021-2/+4
|
* audio: fix AVFrame allocation (crash with opus encoding)wm42020-09-011-0/+2
| | | | | | | | | | | | AVFrame doesn't have public code for pool allocation, so mpv does it manually. AVFrame allocation is very tricky, so we added a bug. This crashed with libopus encoding, but not some other audio codecs, because the libopus libavcodec wrapper accesses AVFrame.data. Most code tries to avoid accessing AVFrame.data and uses AVFrame.extended_data, because using the former would subtly corrupt memory on more than 8 channels. The fact that this problem manifested only now shows that most AVFrame consuming FFmpeg code indeed uses extended_data for audio.
* ao_openal: restore working condition with new push APILAGonauta2020-08-311-8/+10
|
* ao: remove unused fieldwm42020-08-311-1/+0
|
* audio: fix inefficient behavior with ao_alsa, remove period_size fieldwm42020-08-297-24/+13
| | | | | | | | | | | | | | | | | | | | It is now the AO's responsibility to handle period size alignment. The ao->period_size alignment field is unused as of the recent audio refactor commit. Remove it. It turns out that ao_alsa shows extremely inefficient behavior as a consequence of the removal of period size aligned writes in the mentioned refactor commit. This is because it could get into a state where it repeatedly wrote single samples (as small as 1 sample), and starved the rest of the player as a consequence. Too bad. Explicitly align the size in ao_alsa. Other AOs, which need this, should do the same. One reason why it broke so badly with ao_alsa was that it retried the write() even if all reported space could be written. So stop doing that too. Retry the write only if we somehow wrote less. I'm not sure about ao_pulse.
* audio_buffer: remove thiswm42020-08-292-199/+0
| | | | | | Unused, was terrible garbage. It was (or at least its implementation was) always a make-shift solution, and just gross bullshit. It is unused now, so delete it.
* audio: refactor how data is passed to AOwm42020-08-294-371/+304
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This replaces the two buffers (ao_chain.ao_buffer in the core, and buffer_state.buffers in the AO) with a single queue. Instead of having a byte based buffer, the queue is simply a list of audio frames, as output by the decoder. This should make dataflow simpler and reduce copying. It also attempts to simplify fill_audio_out_buffers(), the function I always hated most, because it's full of subtle and buggy logic. Unfortunately, I got assaulted by corner cases, dumb features (attempt at seamless looping, really?), and other crap, so it got pretty complicated again. fill_audio_out_buffers() is still full of subtle and buggy logic. Maybe it got worse. On the other hand, maybe there really is some progress. Who knows. Originally, the data flow parts was meant to be in f_output_chain, but due to tricky interactions with the playloop code, it's now in the dummy filter in audio.c. At least this improves the way the audio PTS is passed to the encoder in encoding mode. Now it attempts to pass frames directly, along with the pts, which should minimize timestamp problems. But to be honest, encoder mode is one big kludge that shouldn't exist in this way. This commit should be considered pre-alpha code. There are lots of bugs still hiding.
* audio: clarify set_pause() documentationwm42020-08-271-0/+1
|
* audio: adjust frame clipping for spdif formatswm42020-08-271-2/+4
| | | | | | Allow mp_aframe_clip_timestamps() to discard a spdif frame if it's entirely out of the timestamp range. Just a minor thing that might make handling these dumb formats easier.
* audio: remove unused ring.h includeswm42020-08-272-2/+0
| | | | | From what I can tell, this has been copy-pasted from times when ao_coreaudio still used its own ringbuffer, instead of the common code.
* ao/pulse: create the stream corkedsfan52020-08-261-1/+1
| | | | | | | | | Previously get_state() would keep setting the cork status while paused, but it only does for that after underflows now. Correct this oversight by creating the stream corked for start() to uncork it at a later time. fixes #8026
* ao/lavc: add channels and channel_layout to AVFrameekisu2020-08-071-0/+2
| | | | | | FFmpeg expects those fields to be set on the AVFrame when encoding audio, not doing so will cause the avcodec_send_frame call to return EINVAL (at least in recent builds).
* af_scaletempo2: fix bug where speed was not setDorian Rudolph2020-07-271-1/+0
| | | | | | the --speed parameter did not work with mpv --no-config whatever.mp3 --video=no --speed=2 --af=scaletempo2 (https://github.com/mpv-player/mpv/pull/7865#issuecomment-664243401)
* af_scaletempo2: M_PI is always definedwm42020-07-271-4/+0
| | | | I forgot why/how (C99?), but other code also uses it.
* audio: add scaletempo2 filter based on chromiumDorian Rudolph2020-07-273-0/+1095
| | | | | | | | scaletempo2 is a new audio filter for playing back audio at modified speed and is based on chromium commit 51ed77e3f37a9a9b80d6d0a8259e84a8ca635259. It sounds subjectively better than the existing implementions scaletempo and rubberband.
* ao/pulse: fix reporting of playing statesfan52020-07-121-2/+7
| | | | | | | When get_state() corks the stream after an underrun happens priv->playing is incorrectly reset to true, which can cause the player to miss the underrun entirely. Stop resetting priv->playing during corking (but not uncorking) to fix this.
* ao/pulse: flush stream on underrunsfan52020-07-121-1/+1
| | | | | | | | | | The underflow callback introduced in d27ad96 can be called when the buffer is still full, causing playback to never resume afterwards since get_state() reports free_samples == 0. Fix this by fully resetting on underrun, which flushes the stream and ensures free buffer space. fixes #7874
* audio: don't lock ao_control for pull mode driversKevin Mitchell2020-06-171-2/+7
| | | | | | | | | | | | | The pull mode APIs were previously required to have thread-safe ao_controls. However, locks were added in b83bdd1 for parity with push mode. This introduced deadlocks in ao_wasapi. Instead, only lock ao_control for the push mode APIs. fixes #7787 See also #7832, #7811. We'll wait for feedback to see if those should also be closed.
* audio: require certain AOs to set device_bufferwm42020-06-092-3/+3
| | | | | | | | | | AOs which use the "push" API must set this field now. Actually, this was sort of always required, but happened to work anyway. The future intention is to use device_buffer as the pre-buffer amount, which has to be available right before audio playback is started. "Pull" AOs really need this too conceptually, just that the API is underspecified. From what I can see, only ao_null did not do this yet.
* ao/pulse: properly set device_bufferNicolas F2020-06-071-0/+8
| | | | | | | | | Previously, device_buffer defaulted to 0 on pulse. This meant that commit baa7b5c would always wait with a timeout of 0, leading to high CPU usage for PulseAudio users. By setting device_buffer to the number of samples per channel that PulseAudio sets as its target, this commit fixes this behaviour.
* audio: fix deadlock on drainingwm42020-06-041-1/+1
| | | | | | | | | | | The playback thread may obviously still fill the AO'S entire audio buffer, which means it unset p->draining, which makes no sense and broke ao_drain(). So just don't unset it here. Not sure if this really fixes this, it was hard to reproduce. Regression due to the recent changes. There are probably many more bugs like this. Stupid asynchronous nightmare state machine. Give me a language that supports formal verification (in presence of concurrency) or something.
* audio: adjust wait durationwm42020-06-031-6/+4
| | | | | | | | | | | | | | | I feel like this makes slightly more sense. At least it doesn't include the potentially arbitrary constant latency that is generally included in the delay value. Also, the buffer status doesn't matter - either we've filled the entire buffer (then we can wait this long), or there's not enough data anyway (then the core will wake up the thread if new data is available). But ultimately, we have to guess, unless the AO does notify us with ao_wakeup_playthread(). Draining may now wait for no reason up to 1/4th of the total buffer time. Shouldn't be a disimprovement in practice.
* audio: avoid possible deadlock regression for some AOswm42020-06-021-2/+17
| | | | | | | | | | | | | | | It's conceivable that ao->driver->reset() will make the audio API wait for ao_read_data() (i.e. its audio callback) to return. Since we recently moved the reset() call inside the same lock that ao_read_data() acquires, this could deadlock. Whether this really happens depends on how exactly the AO behaves. For example, ao_wasapi does not have this problem. "Push" AOs are not affected either. Fix by moving it outside of the lock. Assume ao->driver->start() will not have this problem. Could affect ao_sdl, ao_coreaudio (and similar rotten fruit AOs). I'm unsure whether anyone experienced the problem in practice.
* audio: further simplify internal audio API somewhatwm42020-06-025-47/+41
| | | | | | | | | | | | Instead of the relatively subtle underflow handling, simply signal whether the stream is in a playing state. Should make it more robust. Should affect ao_alsa and ao_pulse only (and ao_openal, but it's broken). For ao_pulse, I'm just guessing. How the hell do you query whether a stream is playing? Who knows. Seems to work, judging from very superficial testing.
* audio: slightly better condition for still_playingwm42020-06-021-1/+1
| | | | | | Just a detail. If wrong (not unlikely because I'm just guessing my own messy state machine), this will make the player freeze due to waiting for something that never happens. Enjoy.
* af_scaletempo: handle obscure integer overflowwm42020-06-021-4/+4
| | | | | Saw it once, not really reproducible. This should fix it, and in any case it's harmless.
* audio: reduce extra wakeups caused by recent changeswm42020-06-011-5/+4
| | | | | | | | | | | | | | | | The feeder thread basically woke up the core and itself too often, and caused some CPU overhead. This was caused by the recent buffer.c changes. For one, do not let ao_read_data() wake up the core, and instead rely on the feeder thread's own buffer management. This is a bit strange, since the change intended to unify the buffer management, but being more consequent about it is better deferred to later, when the buffer management changes again anyway. And also, the "more" condition in the feeder thread seems outdated, or at least what made it make sense has been destroyed, so do something that may or may not be better. In any case, I'm still not getting underruns with ao_alsa, but the wakeup hammering is gone.
* audio: redo internal AO APIwm42020-06-0118-821/+633
| | | | | | | | | | | | | | | | | | | | | | | | | This affects "pull" AOs only: ao_alsa, ao_pulse, ao_openal, ao_pcm, ao_lavc. There are changes to the other AOs too, but that's only about renaming ao_driver.resume to ao_driver.start. ao_openal is broken because I didn't manage to fix it, so it exits with an error message. If you want it, why don't _you_ put effort into it? I see no reason to waste my own precious lifetime over this (I realize the irony). ao_alsa loses the poll() mechanism, but it was mostly broken and didn't really do what it was supposed to. There doesn't seem to be anything in the ALSA API to watch the playback status without polling (unless you want to use raw UNIX signals). No idea if ao_pulse is correct, or whether it's subtly broken now. There is no documentation, so I can't tell what is correct, without reverse engineering the whole project. I recommend using ALSA. This was supposed to be just a simple fix, but somehow it expanded scope like a train wreck. Very high chance of regressions, but probably only for the AOs listed above. The rest you can figure out from reading the diff.
* audio: fix unpausing with some AOswm42020-05-311-1/+1
| | | | | | | | | wasapi/coreaudio/sdl were affected, alsa/pusle were not. The confusion here was that resume() has different meaning with pull and push AOs. Fixes: #7772
* ao_null: remove unreferenced functionwm42020-05-271-8/+0
| | | | Forgot in the previous commit to this file.
* audio: stop applying volume twice for some AOswm42020-05-271-1/+0
| | | | | | | Regression since the recent refactor. How did nobody notice? This happened because the push code now calls the function for the pull code. Both the former and latter apply the volume, so oops.
* audio: remove ao_driver.drainwm42020-05-277-48/+12
| | | | | | | | | | The recent change to the common code removed all calls to ->drain. It's currently emulated via a timed sleep and polling ao_eof_reached(). That is actually fallback code for AOs which lacked draining. I could just readd the drain call, but it was a bad idea anyway. My plan to handle this better is to require the AO to signal a underrun, even if AOPLAY_FINAL_CHUNK is not set. Also reinstate not possibly waiting for ao_lavc.c. ao_pcm.c did not have anything to handle this; whatever.
* audio: merge pull/push ring buffer glue codewm42020-05-255-1004/+761
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is preparation to further cleanups (and eventually actual improvements) of the audio output code. AOs are split into two classes: pull and push. Pull AOs let an audio callback of the native audio API read from a ring buffer. Push AOs expose a function that works similar to write(), and for which we start a "feeder" thread. It seems making this split was beneficial, because of the different data flow, and emulating the one or other in the AOs directly would have created code duplication (all the "pull" AOs had their own ring buffer implementation before it was cleaned up). Unfortunately, both types had completely separate implementations (in pull.c and push.c). The idea was that little can be shared anyway. But that's very annoying now, because I want to change the API between AO and player. This commit attempts to merge them. I've moved everything from push.c to pull.c, the trivial entrypoints from ao.c to pull.c, and attempted to reconcile the differences. It's a mess, but at least there's only one ring buffer within the AO code now. Everything should work mostly the same. Pull AOs now always copy the audio data under a lock; before this commit, all ring buffer access was lock-free (except for the decoder wakeup callback, which acquired a mutex). In theory, this is "bad", and people obsessed with lock-free stuff will hate me, but in practice probably won't matter. The planned change will probably remove this copying-under-lock again, but who knows when this will happen. One change for the push AOs now makes it drop audio, where before only a warning was logged. This is only in case of AOs or drivers which exhibit unexpected (and now unsupported) behavior. This is a risky change. Although it's completely trivial conceptually, there are too many special cases. In addition, I barely tested it, and I've messed with it in a half-motivated state over a longer time, barely making any progress, and finishing it under a rush when I already should have been asleep. Most things seem to work, and I made superficial tests with alsa, sdl, and encode mode. This should cover most things, but there are a lot of tricky things that received no coverage. All this text means you should be prepared to roll back to an older commit and report your problem.
* audio: add frame alloc functionwm42020-05-252-0/+14
| | | | Meh, why is this so roundabout?
* audio: redo video-sync=display-adropwm42020-05-231-0/+114
| | | | | | | | | | | | | | | | | 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.
* af_scaletempo: fix theoretical UBwm42020-05-231-1/+2
| | | | | Passing NULL to memset() is undefined behavior, even if the size argument is 0. Could happen on init errors and such.
* options: cleanup .min use for OPT_CHANNELSwm42020-04-091-2/+4
| | | | | | | | Replace use of .min==1 with a proper flag. This is a good idea, because it has nothing to do with numeric limits (also see commit 9d32d62b61547 for how this can go wrong). With this, m_option.min/max are strictly used for numeric limits.
* ao_oss: remove this audio outputwm42020-03-282-661/+0
| | | | | | | | | | Ancient Linux audio output. Apparently it survived until now, because some BSDs (but not all) had use of this. But these should work with ao_sdl or ao_openal too (that's why these AOs exist after all). ao_oss itself has the problem that it's virtually unmaintainable from my point of view due to all the subtle (or non-subtle) difference. Look at the ifdef mess and the multiple code paths (that shouldn't exist) in the removed source code.
* ao_rsound: remove this audio outputwm42020-03-282-157/+0
| | | | | | I wonder what this even is. I've never heard of anyone using it, and can't find a corresponding library that actually builds with it. Good enough to remove.
* ao_sndio: remove this audio outputwm42020-03-282-323/+0
| | | | | | It was always marked as "experimental", and had inherent problems that were never fixed. It was disabled by default, and I don't think anyone is using it.
* encode: fix occasional init crash due to initialization order issueswm42020-03-221-1/+0
| | | | | | | | Looks like the recent change to this actually made it crash whenever audio happened to be initialized first, due to not setting the mux_stream field before the on_ready callback. Mess a way around this. Also remove a stray unused variable from ao_lavc.c.
* encode: add some shit that does some shitwm42020-03-221-3/+6
| | | | | | | | ????????????? Makes no sense, can endless loop, but whatever. Part of #7524.
* encode: restore audio muxer timebase usewm42020-03-221-0/+3
| | | | | | Seems to crash hard if an error happens somewhere at init. Who cares. Part of #7524.
* ao_wasapi: try mix format except for chmapKevin Mitchell2020-03-191-11/+36
| | | | | | | | | | | | | | | | | In shared mode, we previously tried to feed the full native format to IsFormatSupported in the hopes that the "closest match" returned was actually that. Turns out, IsFormatSupported will always return the mix format if we don't use the mix format's sample rate. This will also clobber our choice of channel map with the mix format channel map even if our desired channel map is supported due to surround emulation. The solution is to not bother trying to use anything other than the mix format sample rate. While we're at it, we might as well use the mix format PCM sample format (always float32) since this conversion will happen anyway and may avoid unecessary dithering to intermediate integer formats if we are already resampling or channel mixing.
* ao_wasapi: handle S_FALSE in mp_format_res_strKevin Mitchell2020-03-191-2/+3
| | | | | IsFormatSupported may return S_FALSE (considered SUCCESS) if the requested format is not suppported, but is close to one that is.
* options: change option macros and all option declarationswm42020-03-1818-101/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* ao_pcm: fix double free on exitwm42020-03-141-6/+8
| | | | | | | | This seems to be an older bug. It set priv->outputfilename to a new talloc-allocated string, but the field is also managed as string option, so talloc will free it first, then m_option_free() is called on the dangling pointer. Possibly this is caused by the earlier ta destruction order change.
* options: change how option range min/max is handledwm42020-03-133-6/+7
| | | | | | | | | | | | | | | | | 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.
* ao_lavc: don't spam underrun warningswm42020-03-131-0/+1
| | | | | Like ao_pcm, this is (conceptually) in perpetual underrun, as long as dumping is fast enough.
* options: split m_config.c/hwm42020-03-131-1/+1
| | | | | | | | | | | | | | | | | Move the "old" mostly command line parsing and option management related code to m_config_frontend.c/h. Move the the code that enables other part of the player to access options to m_config_core.c/h. "frontend" is out of lack of creativity for a better name. Unfortunately, the separation isn't quite clean yet. m_config_frontend.c still references some m_config_core.c implementation details, and m_config_new() is even left in m_config_core.c for now. There some odd functions that should be removed as well (marked as "Bad functions"). Fixing these things requires more changes and will be done separately. struct m_config is left with the current name to reduce diff noise. Also, since there are a _lot_ source files that include m_config.h, add a replacement m_config.h that "redirects" to m_config_core.h.
* ad_lavc: disable decoder downmix by defaultwm42020-02-291-1/+1
| | | | | | | | Let's see how much everyone hates this. Leaving it enabled seems problematic, because libavcodec returns an unspecific error if it doesn't like it. Fixes: #6300
* Remove remains of Libav compatibilitywm42020-02-163-18/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: slightly simplify pull underrun message printingwm42020-02-132-19/+7
| | | | | | | | | | | | | | | A previous commit moved the underrun reporting to report_underruns(), and called it from get_space(). One reason was that I worried about printing a log message from a "realtime" callback, so I tried to move it out of the way. (Though there's little justification other than a bad feeling. While an older version of the pull code tried to avoid any mutexes at all in the callback to accommodate "requirements" from APIs like jackaudio, we gave up on that. Nobody has complained yet.) Simplify this and move underrun reporting back to the callback. But instead of printing the message from there, move the message into the playloop. Change the message slightly, because ao->log is inaccessible, and without the log prefix (e.g. "[ao/alsa]"), some context is missing.
* player: consider audio buffer if AO driver does not report underrunswm42020-02-137-17/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AOs can report audio underruns, but only ao_alsa and ao_sdl (???) currently do so. If the AO was marked as not reporting it, the cache state was used to determine whether playback was interrupted due to slow input. This caused problems in some cases, such as video with very low video frame rate: when a new frame is displayed, a new frame has to be decoded, and since there it's so much further into the file (long frame durations), the cache gets into an underrun state for a short moment, even though both audio and video are playing fine. Enlarging the audio buffer didn't help. Fix this by making all AOs report underruns. If the AO driver does not report underruns, fall back to using the buffer state. pull.c behavior is slightly changed. Pull AOs are normally intended to be used by pseudo-realtime audio APIs that fetch an audio buffer from the API user via callback. I think it makes no sense to consider a buffer underflow not an underrun in any situation, since we return silence to the reader. (OK, maybe the reader could check the return value? But let's not go there as long as there's no implementation.) Remove the flag from ao_sdl.c, since it just worked via the generic mechanism. Make the redundant underrun message verbose only. push.c seems to log a redundant underflow message when resuming (because somehow ao_play_data() is called when there's still no new data in the buffer). But since ao_alsa does its own underrun reporting, and I only use ao_alsa, I don't really care. Also in all my tests, there seemed to be a rather high delay until the underflow was logged (with audio only). I have no idea why this happened and didn't try to debug this, but there's probably something wrong somewhere. This commit may cause random regressions. See: #7440
* ao: avoid unnecessary wakeupswm42020-02-133-9/+14
| | | | | | | | | | | | | If ao_add_events() is used, but all events flags are already set, then we don't need to wakeup the core again. Also, make the underrun message "exact" by avoiding the race condition mentioned in the comment. Avoiding redundant wakeups is not really worth the trouble, and it's actually just a bonus in the change making the ao_underrun_event() function return whether a new underrun was set, which is needed by the following commit.
* ao_wasapi_utils: remove invalid audio session icon path (fixes #7269)Rafael Rivera2020-01-311-2/+1
|
* audio: react to --ao and --audio-buffer runtime changeswm42019-12-271-3/+3
| | | | | | Before this commit, runtime changes were only applied if something else caused audio to be reinitialized. Now setting them reinitializes audio explicitly.
* options: get rid of GLOBAL_CONFIG hackwm42019-11-291-1/+1
| | | | | | | Just an implementation detail that can be cleaned up now. Internally, m_config maintains a tree of m_sub_options structs, except for the root it was not defined explicitly. GLOBAL_CONFIG was a hack to get access to it anyway. Define it explicitly instead.
* audio: add ao_audiotrack for androidAman Gupta2019-11-192-0/+721
|
* audio: fix minor whitespace issue in out/internal.hAman Gupta2019-11-191-1/+1
|
* audio: more alignment nonsensewm42019-11-101-1/+5
| | | | | | | | | | | It's hard to see what FFmpeg does or what its API requires. It looks like the alignment in our own allocation code might be slightly too lenient, but who knows. Even if this is not needed, upping the alignment only wastes memory and doesn't do anything bad. (Note that the only reason why we have our own code is because FFmpeg doesn't even provide it as API. API users are forced to recreate this, even if they have no need for custom allocation!)
* audio: work around ffmpeg being a piece of shitwm42019-11-101-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "amultiply" filter crashes in AVX mode on unaligned access if an audio pointer is unaligned (on 32 or 64 bytes I assume). A requirement that audio data needs to be aligned isn't documented anywhere. In our case, the data is still sample- and channel-aligned, which is completely sane. Sure, you can imagine optimizations which make some algorithms even faster by requiring higher alignment. But, and this is a big but, you shouldn't crash api users because you just invented a new undocumented requirement. And even more importantly, your user-crashing optimization won't matter because it's just a trivial algorithm working on audio. You don't need to pretend to be an optimization devil, and nobody will give you a prize for this. But no, lets random make API users crash (and then probably blame them for it!) for something that wouldn't matter at all. Not to mention that they do "document" some requirements on _video_ data, yet their vf_crop probably can still produce unaligned video pointers. Oh how hilarious that the same documentation also talks about libswscale alignment requirements. (This is weird because libswscale is just one of many, many things which consume video data. Also did you know that zimg, written in C++ and using intrinsics, i.e. the antithesis to FFmpeg development, is much faster than libswscale, easier to use, and produces more correct results, even if you ignore that libswscale flat out doesn't support some very important features?) Fucking tired of this bullshit. Can't wait until someone comes up with a better framework than this... (well let's not write this out). Fix this by copying instead of adjusting the start pointer when skipping samples. This makes general operations slower just to fix interoperating with a single filter. Thank you for your "optimization", FFmpeg. Go die in a fire. Didn't check whether this is correct. It probably is? If the frame needs to be copied (due to COW), and memory allocation fails, it just silently (or audibly lol) doesn't skip samples, because a never-fail function can suddenly fail. Well, who cares. Fixes: #7141
* Replace uses of FFMIN/MAX with MPMIN/MAXwm42019-10-311-2/+2
| | | | And remove libavutil includes where possible.
* ad_lavc, vd_lavc: return full error codes to shared decoder loopwm42019-10-241-14/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ad_lavc and vd_lavc use the lavc_process() helper to translate the FFmpeg push/pull API to the internal filter API (which completely mismatch, even though I'm responsible for both, just fucking kill me). This interface was "slightly" too tight. It returned only a bool indicating "progress", which was not enough to handle some cases (see following commit). While we're at it, move all state into a struct. This is only a single bool, but we get the chance to add more if needed. This fixes mpv falling asleep if decoding returns an error during draining. If decoding fails when we already sent EOF, the state machine stopped making progress. This left mpv just sitting around and doing nothing. A test case can be created with: echo $RANDOM >> image.png This makes libavformat read a proper packet plus a packet of garbage. libavcodec will decode a frame, and then return an error code. The lavc_process() wrapper could not deal with this, because there was no way to differentiate between "retry" and "send new packet". Normally, it would send a new packet, so decoding would make progress anyway. If there was "progress", we couldn't just retry, because it'd retry forever. This is made worse by the fact that it tries to decode at least two frames before starting display, meaning it will "sit around and do nothing" before the picture is displayed. Change it so that on error return, "receiving" a frame is retried. This will make it return the EOF, so everything works properly. This is a high-risk change, because all these funny bullshit exceptions for hardware decoding are in the way, and I didn't retest them. For example, if hardware decoding is enabled, it keeps a list of packets, that are fed into the decoder again if hardware decoding fails, and a software fallback is performed. Another case of horrifying accidental complexity. Fixes: #6618
* input: add gamepad support through SDL2Stefano Pigozzi2019-10-231-1/+1
| | | | | | | | | | | | | | | The code is very basic: - only handles gamepads, could be extended for generic joysticks in the future. - only has button mappings for controllers natively supported by SDL2. I heard more can be added through env vars, there's also ways to load mappings from text files, but I'd rather not go there yet. Common ones like Dualshock are supported natively. - analog buttons (TRIGGER and AXIS) are mapped to discrete buttons using an activation threshold. - only supports one gamepad at a time. the feature is intented to use gamepads as evolved remote controls, not play multiplayer games in mpv :)
* audio/out: rip out old unused app/softvolume reportingwm42019-10-117-21/+0
| | | | | | | | | | | This was all dead code. Commit 995c47da9a (over 3 years ago) removed all uses of the controls. It would be nice if AOs could apply a linear gain volume, that only affects the AO's audio stream for low-latency volume adjust and muting. AOCONTROL_HAS_SOFT_VOLUME was supposed to signal this, but to use it, we'd have to thoroughly check whether it really uses the expected semantics, so there's really nothing useful left in this old code.
* audio/out/pull, ao_sdl: implement new underrun reportingwm42019-10-112-2/+8
| | | | | | | | | | | | | | | | See previous commits. ao_sdl is worthless, but it might be a good test for pull-based AOs. This stops using the old underrun reporting if the new one is enabled. Also, since the AO's behavior can in theory not be according to expectations, this needs to be enabled for every single pull AO separately. For some reason, in certain cases I get multiple underrun warnings while cache-pausing is active. It fills the cache, restarts the AO, immediately underruns again, and then fills the cache again. I'm not sure why this happens; maybe ao_sdl tries to catch up when it shouldn't. Who knows.
* audio/out/pull: fix underflow reportingwm42019-10-111-2/+2
| | | | | | | | I think this was _always_ wrong. Due to the line above the first changed line, buffered_bytes==bytes always. I can only hope I broke this in a less under-tested edit when I originally wrote this. Fixes: c5a82f729bd097
* ao_alsa: use AO underrun reportingwm42019-10-111-1/+3
| | | | This enables the change introduced in the previous commit for ao_alsa.
* ao: add API for underrun reportingwm42019-10-113-1/+23
| | | | | | | | | | | | | | AOs can now call ao_underrun_event() (in any context) if an underrun has happened. It will print a message. This will be used in the following commits. But for now, audio.c only clears the underrun bit, so that subsequent underruns still print the warning message. Since the underrun flag will be used in fragile ways by the playback state machine, there is the "reports_underruns" field that signals strong support for underrun reporting. (Otherwise, underrun events will not be used by it.)
* ao_alsa: handle underruns in get_space() toowm42019-10-111-0/+2
| | | | | This is essentially optional. But it will give the higher level code a better guarantee that underruns were tested.
* ao_alsa: mess with underrun handling againwm42019-10-111-6/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit tries to prepare for better underrun reporting. The goal is to report underruns relatively immediately. Until now, this happened only when play() was called. Change this, and abuse that get_delay() is called "relatively often" - this reports the underrun immediately in practice. Background: In commit 81e51a15f7e1 (and also e38b0b245ed4), we were quite confused about ALSA underrun handling. The commit message showed uncertainty how case 3 happened, but it's blindingly obvious and simple. Actually reading the code shows that ALSA does not have a concept of a "final chunk" (or we don't use it). It's obvious we never pass the AOPLAY_FINAL_CHUNK flag along to the ALSA API in any way. The only thing we do is simply writing a partial fragment. Of course this will cause an underrun. Doing a partial write saves us the trouble to pad the last frame with silence, or so. The main reason why the underrun message was avoided was that play() was never called with a non-0 sample count again (except if reset() was called before that). That was OK, at least the goal of avoiding the unwanted message was reached. (And the original "bogus" message at end of playback was perfectly correct, as far as ALSA goes.) If network stalls, play() will called again only once new data is available. Obviously, this could take a long time, thus it's too late.
* ao_alsa: don't silence legitimate underrun if final chunk underrunswm42019-10-061-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out that case 2) mentioned in the previous commit happened quite often when playback ended normally. There is probably a legitimate underrun with normal buffer sizes (100 ms, 4 fragments, gapless audio in "weak" mode). This is a result of the player waiting for video to end, and/or the time needed to kill the video window. The former case means that it depends on your test case whether it happens (a file where video ends slightly before audio is less likely to trigger it). This in turn is due to how gapless playback works. Achieving not having a "gap" requires queuing the audio of the next file without playing a partial chunk (as AOPLAY_FINAL_CHUNK would do). The partial chunk is then played as part of the first chunk played from the next file. But if it detects "later" that there is no next file, it still needs to get rid of the last fragment with AOPLAY_FINAL_CHUNK. At this point it's too late, and an underrun may have actually happened. The way the player uninits and reinits the entire playback engine for the next file in a "serial" manner means it cannot know in advance whether this works. This is the reason why the idiot who added the underrun exception for the last chunk in play() was wrong (I wrote that btw., before you accuse me of being rude). Yes, it's a real underrun, and you could probably hear it.
* ao_alsa: remove sometimes bogus XRUN messagewm42019-10-061-9/+2
| | | | | | | | | | | | | | | | | | | This XRUN (aka underrun) message was printed in the following situations: 1) legitimate underrun during playback 2) legitimate underrun when playing final chunk 3) bogus underrun when playing final chunk The old underrun case (in play()) happens in cases 1) and 2) as well, but 3) did not happen. It appears 3) is indeed something that happens, although it's not known for sure. It's still pretty annoying, so remove the new XRUN message. When testing, care should be taken to play with buffer sizes, video versus no video, and gapless enabled/disabled. Also, suspending the player with Ctrl+Z in the terminal (SIGSTOP) and then resuming is a good way to trigger a "normal" underrun.
* audio/filter: remove no longer used headerPaul B Mahol2019-10-051-47/+0
|
* audio: fix copy&paste errorwm42019-09-271-1/+1
| | | | | | | This wasn't used at all in my tests, because it simply passed the frame directly to libswsresample. (And, by the way, will always do that, because s64 is so obscure literally NOTHING uses it except a sample specifically created to test this code. Screw FFmpeg.)
* ad_lavc: log on failure to read AVFramewm42019-09-271-1/+3
| | | | | | | | This can be due to unsupported sample formats (see previous commits), minor allocation failures, and similar things. For identifying the exact cause it's buried too deep in abstractions. But most time it doesn't happen anyway, since it's extremely rare that new audio formats are added.
* audio: add support for AV_SAMPLE_FMT_S64*wm42019-09-273-0/+8
| | | | | | | | | | What an idiotic format. It makes no sense, and should have been converted to S32 in the demuxer, rather than plague everyone with another extremely obscure nonsense format. Why doesn't ffmpeg add S24 instead? That's an actually useful format. May cause compilation failure with old FFmpeg or Libav libs, but I don't care.
* options: add M_OPT_FILE to some more options that take filesPhilip Sequeira2019-09-271-1/+1
|
* ao_pulse: add the newly added mappings for TrueHD/DTS-HD formatsJan Ekström2019-09-271-6/+11
| | | | | Originally DTS-HD was mapped to PA_ENCODING_DTS_IEC61937 which I'm actually not sure if it ever worked.
* ao_oss: Fallback to stereo when the device does not support >2 channelsLeonardo Taccari2019-09-211-6/+10
| | | | | | | | ioctl(..., SNDCTL_DSP_CHANNELS, &nchannels) for not supported nchannels does not return an error and instead set nchannels to the default value. Instead of failing with no audio, fallback to stereo.
* ao_pulse: add --pulse-allow-suspendedTérence Clastres2019-09-211-1/+3
| | | | | | | | | | This flag makes mpv continue using the PulseAudio driver even if the sink is suspended. This can be useful if JACK is running with PulseAudio in bridge mode and the sink-input assigned to mpv is the one JACK controls, thus being suspended. By forcing mpv to still use PulseAudio in this case, the user can now adjust the sink to an unsuspended one.
* audio: remove unreferenced af_lavrresamplewm42019-09-191-112/+0
| | | | | | | | | | | | | | This filter wasn't referenced anywhere and thus was dead code. It should have been in the audio filter list in user_filters.c. This was intended as compatibility wrapper (to avoid breaking old command lines and config files), and has no real use. Apparently I forgot to add it to the filter list (did I even test this shit?), and so it was rotting around for 1.5 years doing nothing (just like myself). Note that users can just use the libavfilter provided filter to force resampling, just that it has a different name and different options. There's also af_format to force inserting auto conversion through the internal f_swsresample filter.
* audio_buffer: fix some more theoretical UBwm42019-09-191-0/+3
| | | | | | | This may call memmove() with size==0 and a NULL data pointer. In addition to this being UB with memmove(), I think it's UB to do arithmetic on a NULL pointer too. Of course, this doesn't matter in practice at all, and is just stupidity to torture programmers.
* ad_lavc: skip fully skipped frameswm42019-09-191-1/+5
| | | | | | | | | | | Fixes stupid messages with a opus/mkv test file that had an absurdly huge codec delay. This file fully skips several frames at the start. ad_lavc.c trimmed these frames to 0 samples and returned them. The next layer (f_decoder_wrapper.c) saw discontinuous PTS values, because the PTS values increased by a frame, but amounted to 0 audio samples. This was harmless, but logged PTS discontinuity errors.
* Implement backwards playbackwm42019-09-192-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See manpage additions. This is a huge hack. You can bet there are shit tons of bugs. It's literally forcing square pegs into round holes. Hopefully, the manpage wall of text makes it clear enough that the whole shit can easily crash and burn. (Although it shouldn't literally crash. That would be a bug. It possibly _could_ start a fire by entering some sort of endless loop, not a literal one, just something where it tries to do work without making progress.) (Some obvious bugs I simply ignored for this initial version, but there's a number of potential bugs I can't even imagine. Normal playback should remain completely unaffected, though.) How this works is also described in the manpage. Basically, we demux in reverse, then we decode in reverse, then we render in reverse. The decoding part is the simplest: just reorder the decoder output. This weirdly integrates with the timeline/ordered chapter code, which also has special requirements on feeding the packets to the decoder in a non-straightforward way (it doesn't conflict, although a bugmessmass breaks correct slicing of segments, so EDL/ordered chapter playback is broken in backward direction). Backward demuxing is pretty involved. In theory, it could be much easier: simply iterating the usual demuxer output backward. But this just doesn't fit into our code, so there's a cthulhu nightmare of shit. To be specific, each stream (audio, video) is reversed separately. At least this means we can do backward playback within cached content (for example, you could play backwards in a live stream; on that note, it disables prefetching, which would lead to losing new live video, but this could be avoided). The fuckmess also meant that I didn't bother trying to support subtitles. Subtitles are a problem because they're "sparse" streams. They need to be "passively" demuxed: you don't try to read a subtitle packet, you demux audio and video, and then look whether there was a subtitle packet. This means to get subtitles for a time range, you need to know that you demuxed video and audio over this range, which becomes pretty messy when you demux audio and video backwards separately. Backward display is the most weird (and potentially buggy) part. To avoid that we need to touch a LOT of timing code, we negate all timestamps. The basic idea is that due to the navigation, all comparisons and subtractions of timestamps keep working, and you don't need to touch every single of them to "reverse" them. E.g.: bool before = pts_a < pts_b; would need to be: bool before = forward ? pts_a < pts_b : pts_a > pts_b; or: bool before = pts_a * dir < pts_b * dir; or if you, as it's implemented now, just do this after decoding: pts_a *= dir; pts_b *= dir; and then in the normal timing/renderer code: bool before = pts_a < pts_b; Consequently, we don't need many changes in the latter code. But some assumptions inhererently true for forward playback may have been broken anyway. What is mainly needed is fixing places where values are passed between positive and negative "domains". For example, seeking and timestamp user display always uses positive timestamps. The main mess is that it's not obvious which domain a given variable should or does use. Well, in my tests with a single file, it suddenly started to work when I did this. I'm honestly surprised that it did, and that I didn't have to change a single line in the timing code past decoder (just something minor to make external/cached text subtitles display). I committed it immediately while avoiding thinking about it. But there really likely are subtle problems of all sorts. As far as I'm aware, gstreamer also supports backward playback. When I looked at this years ago, I couldn't find a way to actually try this, and I didn't revisit it now. Back then I also read talk slides from the person who implemented it, and I'm not sure if and which ideas I might have taken from it. It's possible that the timestamp reversal is inspired by it, but I didn't check. (I think it claimed that it could avoid large changes by changing a sign?) VapourSynth has some sort of reverse function, which provides a backward view on a video. The function itself is trivial to implement, as VapourSynth aims to provide random access to video by frame numbers (so you just request decreasing frame numbers). From what I remember, it wasn't exactly fluid, but it worked. It's implemented by creating an index, and seeking to the target on demand, and a bunch of caching. mpv could use it, but it would either require using VapourSynth as demuxer and decoder for everything, or replacing the current file every time something is supposed to be played backwards. FFmpeg's libavfilter has reversal filters for audio and video. These require buffering the entire media data of the file, and don't really fit into mpv's architecture. It could be used by playing a libavfilter graph that also demuxes, but that's like VapourSynth but worse.
* ao_opensles: fix delayed audiosfan52019-09-021-1/+1
| | | | | This was forgotten in commit 5a8c48fde2a26fe00c3552e3ccf83a965b6d3576 when the number of buffers was reduced to 1.
* ao/audiounit: include AVAudioSession buffer in latency calcAman Gupta2019-04-051-1/+1
| | | | Signed-off-by: Aman Gupta <aman@tmm1.net>
* ao/audiounit: improve a/v syncAman Gupta2019-04-053-4/+18
| | | | | | | This more closely mimics ao_coreaudio, on which this driver was originally based. Signed-off-by: Aman Gupta <aman@tmm1.net>
* Merge commit '559a400ac36e75a8d73ba263fd7fa6736df1c2da' into ↵Anton Kindestam2018-12-053-5/+33
|\ | | | | | | | | | | wm4-commits--merge-edition This bumps libmpv version to 1.103
| * player: get rid of mpv_global.optswm42018-05-241-2/+4
| | | | | | | | | | | | | | | | This was always a legacy thing. Remove it by applying an orgy of mp_get_config_group() calls, and sometimes m_config_cache_alloc() or mp_read_option_raw(). win32 changes untested.
| * ao: use a local option structwm42018-05-242-3/+29
| | | | | | | | Instead of accessing MPOpts.
* | ad_spdif: cosmetic alignmentJan Ekström2018-10-301-1/+1
| |
* | ad_spdif: fix DTS-HD HRA handlingJan Ekström2018-10-301-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | Apparently, for bit streaming DTS-HD MA is specified to be handled as an eight channel (7.1) bit stream, while DTS-HD HRA is specified to be handled as a stereo bit stream. Define a variable for this, and utilize it to set the correct values for both the DTS-HD bit streaming rate, as well as the channel count for the SPDIF encoder. Fixes #6148
* | ao_audiounit: rename pause function to resetJosh Lehman2018-09-301-1/+1
| | | | | | | | | | AudioUnit output driver uses the pull based api so it should have a reset function instead of a pause function.
* | ao_alsa: log the ALSA state if we get a non-XRUN errorJan Ekström2018-09-291-2/+4
| | | | | | | | | | The ALSA state generally can tell us more information in case we get an unexpected error.
* | ao_alsa: handle XRUNs separately from other errorsJan Ekström2018-09-291-2/+7
| | | | | | | | | | | | | | | | | | According to ALSA doxy, EPIPE is a synonym to SND_PCM_STATE_XRUN, and that is a state that we should attempt to automatically recover from. In case recovery fails, log an error and return zero. A warning message will still be output for each XRUN since those are not something we should generally be receiving.
* | ao_alsa: early exit get_space if paused or ALSA is not readyJan Ekström2018-09-291-0/+5
| | | | | | | | | | | | | | | | | | | | | | This has been way too long coming, and for me to notice that a whole lot of ao_alsa functions do an early return if the AO is paused. For the STATE_SETUP case, I had this reproduced once, and never since. Still, seems like we can start calling this function before the ALSA device has been fully initialized so we might as well early exit in that case.
* | ao_jack: only auto-connect to audio portsNiklas Haas2018-09-261-1/+2
| | | | | | | | | | This prevents ao_jack from auto-connecting to MIDI ports (or other, hypothetical future port types).
* | ao_pulse: fix tlength calculationTom Yan2018-09-013-17/+3
| | | | | | | | also remove the now unused non-sensical af_fmt_seconds_to_bytes.
* | Revert "ao_openal: enable building on OSX"Michael Hoang2018-08-261-14/+0
| | | | | | | | | | | | This reverts commit af6126adbe61fb2b6cc780025246d33df93072e6. Apple's OpenAL support is ridiculously out of date, revert back to just using OpenAL Soft on macOS (fixes #4645).
* | af_rubberband: reset delay to 0 on resetHector Martin2018-08-251-0/+2
| | | | | | | | This fixes A-V drift on seeking
* | ao_opensles: set numBuffers to 8Tom Yan2018-08-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Apparently some Android builds/forks require this for Bluetooth audio to work as they unexpectedly accept fast flag for it. Shouldn't cause any side-effect (e.g. buffer requirement increased when on wired audio). It's a hardcoded default in the upstream AAudio implementation anyway. Ref.: https://android.googlesource.com/platform/frameworks/av/+/android-8.0.0_r1/media/libaaudio/src/legacy/AudioStreamTrack.cpp#109 https://android.googlesource.com/platform/frameworks/wilhelm/+/android-8.0.0_r1/src/android/AudioPlayer_to_android.cpp#1680 https://android.googlesource.com/platform/frameworks/av/+/android-8.0.0_r1/media/libaudioclient/AudioTrack.cpp#488
* | audio/format: decouple af_fmt_is_planar from af_fmt_to_planarTom Yan2018-08-111-16/+15
| | | | | | | | | | so that af_fmt_to_planar (and hence af_fmt_from_planar) can just return the input when it is not an interleaved (planar) format.
* | ao_opensles: rework the heuristic of buffer/enqueue size settingTom Yan2018-08-051-18/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ao->device_buffer will only affect the enqueue size if the latter is not specified. In other word, its intended purpose will solely be setting/guarding the soft buffer size. This guarantees that the soft buffer size will be consistent no matter a specific enqueue size is set or not. (In the past it would drop to the default of the generic audio-buffer option.) opensles-frames-per-buffer has been renamed to opensles-frames-per -enqueue, as it was never purposed to set the soft buffer size. It will only make sure the size is never smaller than itself, just as before. opensles-buffer-size-in-ms is introduced to allow easy tuning of the relative (i.e. in time) soft buffer size (and enqueue size, unless the aforementioned option is set). As "device buffer" never really made sense in this AO, this option OVERRIDES audio-buffer whenever its value (including the default) is larger than 0. Setting opensl-buffer-size-in-ms to 1 allows you to equate the soft buffer size to the absolute enqueue size set with opensl-frames-per -enqueue conveniently (unless it is less than 1ms). When both are set to 0, audio-buffer will be the ultimate fallback. If audio-buffer is also 0, the AO errors out.
* | ao_opensles: allow s32 and float outputTom Yan2018-08-051-27/+15
| | | | | | | | | | OpenSLES (and its AudioTrack backend) in Android can take 32-bit fixed and floating point input since Android L (API 21).
* | audio/format: minor fix for af_fmt_from_planarTom Yan2018-08-051-2/+4
| | | | | | | | See af_fmt_to_planar.
* | ao_alsa: simplify get_space()Jan Ekström2018-06-041-6/+10
| |
* | ao_alsa: replace snd_pcm_status() with snd_pcm_avail() in get_space()Muhammad Faiz2018-06-041-5/+4
|/ | | | | | | | | | Fixes a bug with alsa dmix on Fedora 29. After several minutes, audio suddenly becomes bad and muted. Actually, I don't know what causes this. Probably this is a bug in alsa. In any case, as snd_pcm_status() returns not only 'avail', but also other fields such as tstamp, htstamp, etc, this could be considered a good simplification, as only avail is required for this function.
* build: make encoding mode non-optionalwm42018-05-031-2/+0
| | | | Makes it easier to not break the build by confusing the ifdeffery.
* encode: get rid of the output packet queuewm42018-05-035-3/+33
| | | | | | | | | | | | Until recently, ao_lavc and vo_lavc started encoding whenever the core happened to send them data. Since audio and video are not initialized at the same time, and the muxer was not necessarily opened when the first encoder started to produce data, the resulting packets were put into a queue. As soon as the muxer was opened, the queue was flushed. Change this to make the core wait with sending data until all encoders are initialized. This has the advantage that we don't need to queue up the packets.
* encode: remove old timestamp handlingwm42018-05-031-46/+6
| | | | | This effectively makes --ocopyts the default. The --ocopyts option itself is also removed, because it's redundant.
* encode: rewrite half of itwm42018-04-291-185/+55
| | | | | | | | | | | | | The main change is that we wait with opening the muxer ("writing headers") until we have data from all streams. This fixes race conditions at init due to broken assumptions in the old code. This also changes a lot of other stuff. I found and fixed a few API violations (often things for which better mechanisms were invented, and the old ones are not valid anymore). I try to get away from the public mutex and shared fields in encode_lavc_context. For now it's still needed for some timestamp-related fields, but most are gone. It also removes some bad code duplication between audio and video paths.
* encode: cosmeticswm42018-04-201-25/+29
| | | | Mostly whitespace changes; some semantic preserving transformations.
* ao_alsa: actually report underruns to userwm42018-04-151-5/+5
| | | | | | | | | Print them as a warning. Note that there may be some cases where it underruns, without being a bad condition. This could possibly happen e.g. if the last chunk is written, and then it resumes playback some time after that. Eventually I want to add more code to avoid such spurious warnings.
* ao_pulse: reduce requested device buffer sizewm42018-04-151-1/+1
| | | | | | Same deal as with the previous commit for ALSA. Untested.
* ao_alsa: reduce requested buffer sizewm42018-04-151-2/+2
| | | | | | There is a dedicated thread for feeding audio to the ALSA API from a buffer with a larger size. There is little reason to have such a large device buffer.
* ao_alsa: add options for controlling period/buffer sizewm42018-04-151-8/+16
|
* ao_openal: document the muted↔gain conversionJan Ekström2018-04-151-0/+3
| | | | This struck me as odd for a moment, so adding a comment.
* ao/openal: Add option to set buffering characteristicsLAGonauta2018-04-151-23/+62
| | | | | | | | | One can now set the number of buffers and the buffer size. This can reduce the CPU usage and the total latency stays mostly the same. As there are sync mechanisms the A/V sync continue intact and working. It also modifies 6.1 channel order, as per OpenAL spec and add AOPLAY_FINAL_CHUNK support
* ao/openal: Add better sample format and channel layout selectionLAGonauta2018-04-151-139/+73
| | | | Also re-added floating-point support.
* ao/openal: Add OpenAL Soft extension to get the correct latencyLAGonauta2018-04-151-1/+16
| | | | | | | | OpenAL Soft's AL_SOFT_source_latency extension allows one to correctly get the device output latency, facilitating the syncronization with video. Also added a simpler generic fallback that does not take into account latency of the device.
* ao/openal: Add support for direct channels outputLAGonauta2018-04-151-0/+10
| | | | | | | Uses OpenAL Soft's AL_DIRECT_CHANNELS_SOFT extension and can be controlled through a new CLI option, --openal-direct-channels. This allows one to send the audio data direrctly to the desired channel without effects applied.
* ao/openal: Add hardware mute supportLAGonauta2018-04-151-0/+12
| | | | | While the volume is set on the listener, mute is set on the sound source. Seemed easier that way.
* ao/openal: Use only one source for audio outputLAGonauta2018-04-151-52/+153
| | | | Floating point audio not supported on this commit.
* ao_opensles: let cfg_frames_per_buffer accept buffer size up to 0.5s at 192kHzTom Yan2018-04-051-1/+1
|
* ao_opensles: remove useless cfg_sample_rateTom Yan2018-04-051-5/+0
| | | | We should always use the ao-neutral --audio-samplerate option.
* ao_opensles: bump device buffer size to 250msTom Yan2018-04-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although half (non-fast track on sink rate) or one-third (non-fast track not on sink rate) of the buffer size of the created AudioTrack instance as the SL Enqueue buffer size is basically enough for dropout-free playback, only using the full size can avoid stutter upon (re)start of playback. Here are the various buffer sizes on different track/sink rate when on Bluetooth audio on Android O: aptX @ 48kHz: Sink rate: 48000 Hz 44100 Hz: 10632 frames (241.09 ms) 48000 Hz: 11544 frames (240.50 ms) 88200 Hz: 21216 frames (240.54 ms) 96000 Hz: 23088 frames (240.50 ms) 176400 Hz: 42384 frames (240.27 ms) 192000 Hz: 46128 frames (240.25 ms) SBC/AAC/aptX @ 44.1kHz: Sink rate: 44100 Hz 44100 Hz: 10776 frames (244.35 ms) 48000 Hz: 11748 frames (244.75 ms) 88200 Hz: 21552 frames (244.35 ms) 96000 Hz: 23448 frames (244.25 ms) 176400 Hz: 43056 frames (244.08 ms) 192000 Hz: 46848 frames (244.00 ms) The above results were produced with the following code: import android.media.AudioAttributes; import android.media.AudioFormat; import android.media.AudioTrack; class AudioInfo { public static void main(String[] args) { int nosr = AudioTrack.getNativeOutputSampleRate(3); System.out.printf("Sink rate: %d Hz\n", nosr); int[] rates = {44100,48000,88200,96000,176400,192000}; for (int rate: rates) { AudioAttributes aa = new AudioAttributes.Builder().setFlags(256).build(); AudioFormat af = new AudioFormat.Builder().setSampleRate(rate).build(); AudioTrack at = new AudioTrack(aa, af, 4, 1, 0); int sr = at.getSampleRate(); int bs = at.getBufferSizeInFrames(); float ms = bs * (float) 1000 / sr; at.release(); System.out.printf("%d Hz: %d frames (%.2f ms)\n", sr, bs, ms); } } } Therefore bumping the device buffer size to 250ms.
* ao_opensles: do one buffer onlyTom Yan2018-04-051-15/+8
| | | | Doing two buffers causes stutters upon (re)start of playback on Android O for all kinds of sinks.
* ao_opensles: re-flow interface/configuration retrievalJan Ekström2018-03-241-9/+18
| | | | | This manages to make the code more readable. Thanks to MakeGho@IRCnet for the snippet on which this was based.
* ao_opensles: fix audio sync using device latency extensionAman Gupta2018-03-231-3/+20
|
* ao_sdl: fix default buffer sizewm42018-03-081-5/+6
| | | | | | | | If you set desired.samples to 0, SDL will return a default buffer size on obtained.samples. This was broken, because ceil_power_of_two(0) returns 1. Since 0 is usually not considered a power of two, this is probably correct, but we still want to set desired.samples to 0 in this case.
* ao: do not allow actual buffer size of 0wm42018-03-081-0/+1
| | | | | | | | | You can use --audio-buffer=0 to minimize the audio buffer size. But if the AO reports no device buffer size (like e.g. ao_jack does), then the buffer size is actually 0, and playback can never work properly. Make it fallback to a size of 1, which is unlikely to work properly, but you get what you asked for, instead of a freeze.
* ao_opensles: bump device buffer size to 200mstomty892018-03-071-1/+1
| | | While the soft buffer size is already by default 200ms, it is not enough to guarantee dropout-free playback on Bluetooth audio. Bumping the device buffer size to the same value seems to suffice.
* ao_opensles: remove set_play_state()tomty892018-03-071-10/+1
| | | Set play state to playing in init() instead. We no longer touch the play state afterwards.
* ao_opensles: clear buffer queue in reset()tomty892018-03-071-1/+2
| | | Avoid resume() from causing SL_RESULT_BUFFER_INSUFFICIENT ("Failed to Enqueue: 7" when seek or resume from pause).
* audio: don't touch spdif frames in mp_aframe_clip_timestamps()wm42018-02-131-0/+3
| | | | It can't work for this type of format.
* build: drop support for SDL1wm42018-02-131-1/+1
| | | | | For some reason it was supported for ao_sdl because we've only used SDL1 API.
* af_scaletempo: output minimally sized audio framewm42018-02-031-57/+76
| | | | | | | | | | | | | | | | | | | | This helps the filter to adapt much faster to speed changes. Before this commit, the filter just converted and output the full input frame, which could cause problems with large input frames. This was made worse by certain filters like dynaudnorm or loudnorm outputting pretty large frames. This commit changes the filter from trying to convert all input at once to only outputting a single internally filtered frame. Internally, this filter already output data in units of 60ms by default (controlled by the "stride" sub-option), and concatenated as many output frames as necessary to consume all input. Behavior is still kind of bad when inserting the filter. This is because the large frames can be buffered up after the insertion point, so the speed change will be performed with a larger latency. The scaletempo filter can't do anything against this, although it can be fixed by inserting scaletempo as user filter as part of --af.
* codecs: remove unused family fieldwm42018-02-011-1/+1
| | | | | | | | | | MPlayer used this to distinguish multiple decoder wrappers (such as libavcodec vs. binary codec loader vs. builtin decoders). It lost meaning in mpv as non-libavcodec things were dropped. Now it doesn't serve any purpose anymore. Parsing was removed quite a while ago, and the recent filter change removed any use of the internal family field. Get rid of it.
* audio: move to decoder wrapperwm42018-01-305-549/+163
| | | | | | | | | | | | | | | | Use the decoder wrapper that was introduced for video. This removes all code duplication the old audio decoder wrapper had with the video code. (The audio wrapper was copy pasted from the video one over a decade ago, and has been kept in sync ever since by the power of copy&paste. Since the original copy&paste was possibly done by someone who did not answer to the LGPL relicensing, this should also remove all doubts about whether any of this code is left, since we now completely remove any code that could possibly have been based on it.) There is some complication with spdif handling, and a minor behavior change (it will restrict the list of codecs to spdif if spdif is to be used), but there should not be any difference in practice.
* ao_null: add --ao-null-format option for debuggingwm42018-01-301-0/+5
| | | | Helpful especially to test spdif fallback and so on.
* audio: rewrite filtering glue codewm42018-01-3017-3805/+1119
| | | | Use the new filtering code for audio too.
* ao_alsa: reduce verbosity at -vwm42018-01-251-10/+10
| | | | | | | Always make the hw params dump function use MSGL_DEBUG, and remove the MSGL_V use. That means you need -v -v to see them. The detailed information is usually not very interesting, so this reduces the log noise.
* audio: fix annyoing af_get_best_sample_formats() definitionwm42018-01-258-9/+10
| | | | | | | | | | | | | | | | The af_get_best_sample_formats() function had an argument of int[AF_FORMAT_COUNT], which is slightly incorrect, because it's 0 terminated and should in theory have AF_FORMAT_COUNT+1 entries. It won't actually write this many formats (since some formats are fundamentally incompatible), but it still feels annoying and incorrect. So fix it, and require that callers pass an AF_FORMAT_COUNT+1 array. Note that the array size has no meaning in C function arguments (just another issue with C static arrays being weird and stupid), so get rid of it completely. Not changing the af_lavcac3enc use, since that is rewritten in another branch anyway.
* Fix undefined preprocessor behaviorwm42018-01-182-3/+10
| | | | | | | | | | | This commit eliminates the following clang warning: warning: macro expansion producing 'defined' has undefined behavior [-Wexpansion-to-defined] Going by the clang commit message, this seems to be explicitly specified as UB by the standard, and they added this warning because MSVC apparently results in different behavior. Whatever, we can just avoid the warning with some small changes.
* af_rubberband: add af-command to multiply current pitchVobe2018-01-151-6/+16
| | | | | | | | | | | | | This commit introduces the multiply-pitch af-command. Users may bind keys to this command in order to incrementally adjust the pitch of a track. This will probably mostly be useful for musicians trying to transpose up and down by semi tones without having to calculate the correct ratio beforehand. As an example, here is an input.conf to test this feature: { af-command all multiply-pitch 0.9438743126816935 } af-command all multiply-pitch 1.059463094352953
* af_lavrresample: deprecate this filterwm42018-01-132-2/+12
| | | | | | The future direction might be not having such a user-visible filter at all, similar to how vf_scale went away (or actually, redirects to libavfilter's vf_scale).
* audio: add global options for resampler defaultswm42018-01-135-10/+53
| | | | | | | | This is part of trying to get rid of --af-defaults, and the af resample filter. It requires a complicated mechanism to set the defaults on the resample filter for backwards compatibility.
* audio/aframe: add missing include statementswm42018-01-131-0/+2
| | | | Otherwise it doesn't compile if they are not indirectly included before.
* video, audio: don't actively wait for demuxer inputwm42018-01-091-0/+2
| | | | | | | | | | | | If feed_packet() ended with DATA_WAIT, the player should have gone to sleep, until the demuxer wakes it up again when there is new data. But the call to read_frame() unconditionally overwrote this status code, so it never waited. The consequence was that the core burned CPU by effectively polling the demuxer status, which was noticeable especially when seeking in network streams (since seeking is async, decoders will start out with having to wait for network). Regression since commit 33e5755c.
* video, audio: always read all frames before getting next packetwm42018-01-011-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The old code tried to make sure at all times to try to read a new packet. Only once that was read, it tried to retrieve new video or audio frames the decoder might already have decoded. Change this to strictly read frames from the decoder until it signals that it wants a new packet, and only then read and feed a new packet. This is in theory nicer, follows the libavcodec recommended data flow, and and reduces the minimum latency by 1 frame. This merely requires switching the order in which those calls are done. Normally, the decoder will return only 1 frame until a new packet is required. If we would just feed it 1 packet, return DATA_AGAIN, and wait until the next frame is decoded, we would run the playloop 1 time too often for no reason (which is fine but might have some overhead). To avoid this, try to read a frame again after possibly feeding a packet. For this reason, move the feed/read code to its own functions each, instead of merely moving the code. The audio and video code for this particular thing is basically duplicated. The idea is to unify them one day, so make the change to both. (Doing this for video is the real motivation for this change, see below.) The video code change is slightly more complicated, because we have to care about the framedrop counting (which is just a heuristic, but for now considered better than nothing, and possibly considered required to warn the user of framedrops happening - maybe). Apparently this change helps with stalling streams on Android with the mediacodec wrapper and mpeg2 decoder implementations which deinterlace on decoding (and return 2 frames per packet). Based on an idea and observations by tmm1.
* options: drop some previously deprecated optionswm42017-12-251-1/+0
| | | | | | | | A release has been made, so drop options deprecated for that release. Also drop some options which have been deprecated a much longer time before. Also fix a typo in client-api-changes.rst.
* Fix various typos in log messagesNicolas F2017-12-033-3/+3
|
* ao: minor simplification to gain processing codewm42017-11-301-4/+3
| | | | | Cosmetic move of a variable, and consider an adjustment below 1/256 or so not worth applying (even in the float case).
* ao: simplify hack for float atomicswm42017-11-302-16/+4
| | | | | | | stdatomic.h defines no atomic_float typedef. We can't just use _Atomic unconditionally, because we support compilers without C11 atomics. So just create a custom atomic_float typedef in the wrapper, which uses _Atomic in the C11 code path.
* audio: add audio softvol processing to AOwm42017-11-297-3/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This does what af_volume used to do. Since we couldn't relicense it, just rewrite it. Since we don't have a new filter mechanism yet, and the libavfilter is too inconvenient, do applying the volume gain in ao.c directly. This is done before handling the audio data to the driver. Since push.c runs a separate thread, and pull.c is called asynchronously from the audio driver's thread, the volume value needs to be synchronized. There's no existing central mutex, so do some shit with atomics. Since there's no atomic_float type predefined (which is at least needed when using the legacy wrapper), do some nonsense about reinterpret casting the float value to an int for the purpose of atomic access. Not sure if using memcpy() is undefined behavior, but for now I don't care. The advantage of not using a filter is lower complexity (no filter auto insertion), and lower latency (gain processing is done after our internal audio buffer of at least 200ms). Disavdantages include inability to use native volume control _before_ other filters with custom filter chains, and the need to add new processing for each new sample type. Since this doesn't reuse any of the old GPL code, nor does indirectly rely on it, volume and replaygain handling now works in LGPL mode. How to process the gain is inspired by libavfilter's af_volume (LGPL). In particular, we use exactly the same rounding, and we quantize processing for integer sample types by 256 steps. Some of libavfilter's copyright may or may not apply, but I think not, and it's the same license anyway.
* af: remove deprecated audio filterswm42017-11-296-878/+0
| | | | | | | | | | | | These couldn't be relicensed, and won't survive the LGPL transition. The other existing filters are mostly LGPL (except libaf glue code). This remove the deprecated pan option. I guess it could be restored by inserting a libavfilter filter (if there's one), but for now let it be gone. This temporarily breaks volume control (and things related to it, like replaygain).
* ao_alsa: change license to LGPLwm42017-11-231-27/+15
| | | | | | | | | | | | | | | | | | | | | | | | Looks like this is covered by LGPL relicensing agreements now. Notes about contributors who could not be reached or who didn't agree: Commit 7fccb6486e has tons of mp_msg changes look like they are not copyrightable (even if they were, all mp_msg calls were rewritten in mpv times again). The additional play() change looks suspicious, but the function was rewritten several times anyway (first time after that commit in 4f40ec312). Commit 89ed1748ae was rewritten in commit 325311af3 and then again several times after that. Basically all this code is unnecessary in modern mpv and has been removed. No code survived from the following commits: 4d31c3c53, 61ecf838f2, d38968bd, 4deb67c3f. At least two cosmetic typo fixes are not considered as well. Commit 22bb046ad is reverted (this wasn't a valid warning anyway, just a C++-ism icc applied to C). Using the constants is nicer, but at least I don't have to decide whether that change was copyrightable.
* ao_alsa: don't convert twice on retrywm42017-11-231-2/+1
| | | | Obscure corner case.
* build: make it easier to force FFmpeg upstreamwm42017-11-011-1/+1
| | | | | | | | | | | Apparently some people want this. Actually making it compile is still their problem, though, and I expect that build with FFmpeg upstream will occasionally be broken (as it is right now). This is because mpv also relies on API provided by Libav, and if FFmpeg hasn't merged that yet, it's not our problem - we provide a version of FFmpeg upstream with those changes merged, and it's called ffmpeg-mpv. Also adjust the README which still talked about FFmpeg releases.
* Bump libav* API usewm42017-10-301-2/+2
| | | | (Not tested on Windows and OSX.)
* Get rid of deprecated AVFrame accessorswm42017-10-302-4/+4
| | | | | | Fist we were required to use them for ABI compat. reasons (and other BS), now they're deprecated and we're supposed to access them directly again.
* audio/out: initialize an array to avoid confusing static analyzerwm42017-10-271-1/+1
| | | | | | | I _think_ this confuses Coverity and it thinks there is uninitialized data to be read. Initialize the array to change/remove the warning, or if there's a real problem, to make it easier to detect. (Basically apply defensive coding.)
* af_lavfi: fix small memory leakwm42017-10-271-6/+10
| | | | Plus restructure the error path to make this simpler.
* demux: get rid of demux_packet.new_segment fieldwm42017-10-241-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | The new_segment field was used to track the decoder data flow handler of timeline boundaries, which are used for ordered chapters etc. (anything that sets demuxer_desc.load_timeline). This broke seeking with the demuxer cache enabled. The demuxer is expected to set the new_segment field after every seek or segment boundary switch, so the cached packets basically contained incorrect values for this, and the decoders were not initialized correctly. Fix this by getting rid of the flag completely. Let the decoders instead compare the segment information by content, which is hopefully enough. (In theory, two segments with same information could perhaps appear in broken-ish corner cases, or in an attempt to simulate looping, and such. I preferred the simple solution over others, such as generating unique and stable segment IDs.) We still add a "segmented" field to make it explicit whether segments are used, instead of doing something silly like testing arbitrary other segment fields for validity. Cached seeking with timeline stuff is still slightly broken even with this commit: the seek logic is not aware of the overlap that segments can have, and the timestamp clamping that needs to be performed in theory to account for the fact that a packet might contain a frame that is always clipped off by segment handling. This can be fixed later.
* aframe: fix logically dead codewm42017-10-181-1/+1
| | | | Detected by a well known static analyzer.
* Add checks for HAVE_GPL to various GPL-only source fileswm42017-10-103-0/+12
| | | | | | | | This should actually cover all of them, if you take into account that some unchanged GPL source files include header files with such checks. Also this was done already for the libaf derived code. This is only for "safety" and to avoid misunderstandings.
* command: drop "audio-out-detected-device" propertywm42017-10-093-11/+0
| | | | | | Coreaudio stopped setting it a few releases ago (66a958bb4fa). There is not much of a user- or API-visible change, so remove it without deprecation.
* audio: fix channel conversion with NA channelswm42017-09-271-1/+1
| | | | | | | | The case at hand was 5.1 -> fl-fr-fc-lfe-na-na (apparently triggered by ALSA). That means only the NA channels have to be cleared, but the result was actually that fc and lfe were cleared. This is due to a simple regression in the reorder code, which quite obviously got the index of the first NA channel wrong.
* audio: fix resamplingwm42017-09-211-0/+5
| | | | | | | Let's blame FFmpeg for just overwriting the samplerate in av_frame_copy_props(). Can't fully hide my own brain damage though, since mp_aframe_config_copy() expected that the rate is copied (that function also copies format and channel layout).
* build: add preliminary LGPL modewm42017-09-211-2/+2
| | | | | | | See "Copyright" file for caveats. This changes the remaining "almost LGPL" files to LGPL, because we think that the conditions the author set for these was finally fulfilled.
* audio: make libaf derived code optionalwm42017-09-214-3/+9
| | | | | | | | | | | | | | | This code could not be relicensed. The intention was to write new filter code (which could handle both audio and video), but that's a bit of work. Write some code that can do audio conversion (resampling, downmixing, etc.) without the old audio filter chain code in order to speed up the LGPL relicensing. If you build with --disable-libaf, nothing in audio/filter/* is compiled in. It breaks a few features, such as --volume, --af, pitch correction on speed changes, replaygain. Most likely this adds some bugs, even if --disable-libaf is not used. (How the fuck does EOF notification work again anyway?)
* audio: move libswresample wrapper out of audio filter codewm42017-09-219-461/+773
| | | | | | | | | Move it from af_lavrresample.c to a new aconverter.c file, which is independent from the filter chain code. It also doesn't use mp_audio, and thus has no GPL dependencies. Preparation for later commits. Not particularly well tested, so have fun.
* audio_buffer: remove dependency on mp_audiowm42017-09-213-125/+112
| | | | | | | | | Just reimplement it in some way, as mp_audio is GPL-only. Actually I wanted to get rid of audio_buffer.c completely (and instead have a list of mp_aframes), but to do so would require rewriting some more player core audio code. So to get this LGPL relicensing over quickly, just do some extra work.
* audio: fix spdif modewm42017-08-231-2/+2
| | | | | Not sure how this was not caught before. It crashed when trying to use spdif mode.
* ao_rsound: allow setting the hostwm42017-08-211-0/+3
| | | | | | | | Completely untested (rsound dev libs unavailable on my system). Trivial enough that it's very likely that it'll just work. No port selection, but could be added by parsing it as part of the device name. Should fix #4714.
* audio: fix uninitialized data accesswm42017-08-181-0/+1
| | | | | | dst was not supposed to be initialized, the mp_audio_ setters (which initialize dst's fields) assume it is -> shit happens. Regression from recent changes. Was probably harmless.
* audio: fix build on Libavwm42017-08-161-0/+1
| | | | Sigh...
* audio: introduce a new type to hold audio frameswm42017-08-1611-67/+591
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is pretty pointless, but I believe it allows us to claim that the new code is not affected by the copyright of the old code. This is needed, because the original mp_audio struct was written by someone who has disagreed with LGPL relicensing (it was called af_data at the time, and was defined in af.h). The "GPL'ed" struct contents that surive are pretty trivial: just the data pointer, and some metadata like the format, samplerate, etc. - but at least in this case, any new code would be extremely similar anyway, and I'm not really sure whether it's OK to claim different copyright. So what we do is we just use AVFrame (which of course is LGPL with 100% certainty), and add some accessors around it to adapt it to mpv conventions. Also, this gets rid of some annoying conventions of mp_audio, like the struct fields that require using an accessor to write to them anyway. For the most part, this change is only dumb replacements of mp_audio related functions and fields. One minor actual change is that you can't allocate the new type on the stack anymore. Some code still uses mp_audio. All audio filter code will be deleted, so it makes no sense to convert this code. (Audio filters which are LGPL and which we keep will have to be ported to a new filter infrastructure anyway.) player/audio.c uses it because it interacts with the old filter code. push.c has some complex use of mp_audio and mp_audio_buffer, but this and pull.c will most likely be rewritten to do something else.
* af_lavrresample: don't call swr_set_compensation() unless necessarywm42017-08-121-5/+9
| | | | | | | | | | | | | | This was _always_ called, even if the resampling was static, or the filter was inserted for format conversion only. This should have been fine, as I expected the function not to enable resampling when the compensation is unset, and the source/target rates are the same. But this is not the case, and it always enables resampling. So explicitly avoid the call. If we have already called it successfully, it's better not do avoid it (to overwrite the previous compensation value), but it will also be cheap/no-op then. Probably fixes #4716.
* ao_wasapi: remove old commentKevin Mitchell2017-08-071-1/+1
|
* ao_wasapi: reorganize wasapi.hKevin Mitchell2017-08-072-12/+8
| | | | | Remove dead declarations. Move macro only used in wasapi_utils.c closer to use. Rearrange declaration order.
* ao_wasapi: deduplicate wasapi sample format selectionKevin Mitchell2017-08-071-49/+40
|
* ao_wasapi: clean up find_formats logicKevin Mitchell2017-08-071-75/+45
| | | | | There were too many functions within functions, too much going on in if clauses and duplicated code. Fix it.
* ao_wasapi: return bool instead of HRESULT from thread_initKevin Mitchell2017-08-073-38/+48
| | | | | | | | Any bad HRESULTs should have been printed already and lots of failure modes don't have an HRESULT leading to awkward hr = E_FAIL business. This also checks the exit status of GetBufferSize in the align hack. A final fatal message is added if either of the retry hacks fail.
* ao_oss: fix a dumb calculationwm42017-07-211-2/+3
| | | | | | | period_size used the wrong unit, and even if the unit had been correct, was assigned the wrong value. Probably fixes #4642.
* Replace remaining avcodec_close() callswm42017-07-162-8/+2
| | | | | | | | This API isn't deprecated (yet?), but it's still inferior and harder to use than avcodec_free_context(). Leave the call only in 1 case in af_lavcac3enc.c, where we apparently seriously close and reopen the encoder for whatever reason.
* ao_wasapi: remove redundant / outdated commentKevin Mitchell2017-07-101-1/+0
| | | | | Where this was moved from, it made slightly more sense. Here what the comment is trying to say is already pretty obvious from the code.
* ao_waspi: use switch for handling fix_format errorsKevin Mitchell2017-07-101-5/+8
|
* ao_wasapi: don't repeat format negotiation on align hackKevin Mitchell2017-07-101-4/+7
| | | | | Even if it did return a different result, the bufferFrameCount from the align hack would be wrong anyway.
* ao_wasapi: fix leak on align hackKevin Mitchell2017-07-101-1/+1
|
* ad_spdif: minor cleanupswm42017-07-101-3/+5
| | | | | | | | Use avcodec_free_context() unstead of random other calls. Actually it was already used in the second case, but calling avcodec_close() is redundant. Don't crash if allocating a codec context fails.
* audio/out: fix comment typoKevin Mitchell2017-07-091-1/+1
|
* ao_wasapi: enable packed 24 bit outputKevin Mitchell2017-07-091-1/+1
|
* audio/out: correct copy length in ao_read_data_convertedKevin Mitchell2017-07-091-6/+7
| | | | | | | | | | | | | Previously, the entire convert_buffer was being copied to the desination without regard to the fact that it may be packed and therefore smaller. The allocated conversion buffer was also way to big bytes * (channels * samples) ** 2 instead of bytes * channels * samples
* ao_wasapi: reorder channels and samplerates to speed up searchKevin Mitchell2017-07-091-4/+4
| | | | | | | This shouldn't affect which are chosen, but it should speed up the search by putting more common configurations earlier so that a working sample format and sample rates can be found sooner obviating the need to search them for each iteration of the outer loops.
* ao_wasapi: minor cosmetic fixesKevin Mitchell2017-07-091-3/+3
|
* ao_wasapi: try correct initial formatKevin Mitchell2017-07-091-1/+4
| | | | | | | | | The loop to select the native wasapi_format for the incoming audio was not breaking correctly when it found the most desirable format. It therefore executed completely leaving the least desirable format (u8) as the choice. fixes #4582
* audio: drop AF_FORMAT_S24wm42017-07-073-44/+2
| | | | | | | | | | | This is the last sample format that was only in mpv and not in FFmpeg (except the spdif special formats). It was a huge pain, even if the removed code in af_lavrresample is pretty small after all. Note that this drops S24 from the ao_coreaudio AOs too. I'm not sure about the impact, but I expect it doesn't matter. af_fmt_change_bytes() was unused as well, so remove that too.
* ao_pcm: drop AF_FORMAT_S24 usagewm42017-07-071-1/+0
| | | | | | | I'd actually be somewhat interested in supporting this, as it could help testing the S24 conversion code. But then again it's only a pain, there's no immediate need, and it would require new options to make ao_pcm.c select this output format at all.
* ao_oss: drop AF_FORMAT_S24 usagewm42017-07-071-7/+0
| | | | Can't test / don't care.
* ao_sndio: drop AF_FORMAT_S24 usagewm42017-07-071-3/+0
| | | | | | I can't test it, so I'm dropping it without replacement. If anyone is interested in readding support, it would be done like the ao_alsa.c change.
* ao_wasapi_utils: be slightly more clever when converting channel mapwm42017-07-071-0/+5
|
* ao_wasapi: drop use of AF_FORMAT_S24wm42017-07-073-117/+133
| | | | | | | | | | | Do conversion directly, using the infrastructure that was added before. This also rewrites part of format negotation, I guess. I couldn't test the format that was used for S24 - my hardware does not report support for it. So I commented it, as it could be buggy. Testing this with the wasapi_formats[] entry for 24/24 uncommented would be appreciated.
* ao_alsa: drop use of AF_FORMAT_S24wm42017-07-071-21/+56
| | | | | | | | | | | | | Instead of the infrastructure added in the previous commit to do the conversion within the AO. If this is used, and snd_pcm_status_get_avail() returns more frames than snd_pcm_write*() actually accepts, you will get some nice audio corruption. Also, this mutates the data passed via play(), which is rather fishy, but sort of doesn't matter for now. Surely this will cause unintended bugs and WTFs.
* audio/out: add helper code to do 24 bit conversion in AOwm42017-07-073-0/+129
| | | | | | | | | | | | | | | | | | | | | | | | | I plan to remove the S24 sample formats in mpv. It seems like we should still support this _somehow_ in AOs though. So the idea is to convert the data to more obscure representations (that would not be useful for filtering etc. anyway) within the AO. This commit adds helper to enable this. ao_convert_fmt is meant to provide mechanisms for this, rather than a generic audio format description (as the latter leads only to overly generic misery). The conversion also supports only cases which we think will be needed at all. The main advantage of this approach is that we get S24 out of sight, and that we could support other crazy formats (like S20). The main disadvantage is that usually S32 will be selected (if both S32 and S24 are available), and there's no user control to force S24. That doesn't really matter though, and at worst makes testing harder or will lead to unpleasant arguments with audiophiles (they'd be wrong anyway). ao_convert_fmt.pad_lsb is ignored, although if we ever find a case in which playing S32 with data in the LSBs breaks when playing it as padded 24 bit format. (For example, WAVEFORMATEXTENSIBLE recommends setting the unused bits to 0 if wValidBitsPerSample implies LSB padding.)
* ad_lavc, vd_lavc, sd_lavc: consistently use avcodec_free_context()wm42017-07-061-7/+1
| | | | | Instead of various ad-hoc ways to achieve the same thing. (The API was added only later.)
* ao_coreaudio: insane hack for passing through AC3 as float PCMwm42017-06-301-5/+65
| | | | | This uses the same hack as Kodi uses, and I suspect MPlayer/ancient mpv also did this (but didn't research that).
* ao_wasapi: UWP wrapper hack supportwm42017-06-292-7/+40
| | | | | | | | | | | UWP does not support the whole IMMDevice API. Instead, you need to use a new API (available starting from Windows 8), which is in addition not in MinGW, and extremely unpleasant to use. The wasapiuwp2.dll wrapper is a small custom MSVC DLL, which does this instead, and returns a normal IAudioClient. Before this, ao_wasapi did not initialize on UWP.
* Universal Windows Plaform (UWP) supportPedro Pombeiro2017-06-291-0/+4
| | | | | | | | libmpv only. Some things are still missing. Heavily reworked. Signed-off-by: wm4 <wm4@nowhere>
* ao_wasapi: do not use deprecated wchar functionsPedro Pombeiro2017-06-292-2/+2
| | | | These break on UWP. Based on a patch by Pedro Pombeiro.
* Avoid calling close(-1)wm42017-06-291-2/+5
| | | | | | | | | | While this is perfectly OK on Unix, it causes annoying valgrind warnings, and might be otherwise confusing to others. On Windows, the runtime can actually abort the process if this is called. push.c part taken from a patch by Pedro Pombeiro.
* ao_wasapi: remove subtly duplicated codewm42017-06-281-7/+6
| | | | Seems like this can be slightly simplified.
* ao_wasapi: remove duplicate code for creating IAudioClientwm42017-06-281-34/+24
| | | | | | | | | | | | The code accounting for the terrible AUDCLNT_E_BUFFER_SIZE_NOT_ALIGNED semantics (which MSDN claims can happen "starting with Windows 7" - so probably on Windows 10 too) duplicated the call for creating the IAudioClient. That's not great, so get rid of it. Let wasapi_thread_init() handle this. It has a retry loop anyway. This redoes device lookup and format negotiation, but potential failures due to race conditions (what if the driver decides to change behavior) shouldn't be worse than before.
* audio/out/pull: detect and log underflowswm42017-06-281-0/+20
| | | | Mostly for debugging, I guess.
* audio/out: require AO drivers to report period size and correct bufferwm42017-06-259-4/+39
| | | | | | | | | | | | | | | | Before this change, AOs could have internal alignment, and play() would not consume the trailing data if the size passed to it is not aligned. Change this to require AOs to report their alignment (via period_size), and make sure to always send aligned data. The buffer reported by get_space() now always has to be correct and reliable. If play() does not consume all data provided (which is bounded by get_space()), an error is printed. This is preparation for potential further AO changes. I casually checked alsa/lavc/null/pcm, the other AOs might or might not work.
* ao_openal: change license to LGPLwm42017-06-241-7/+7
| | | | All authors have agreed.
* chmap: remove misleading "downmix" channel layout namewm42017-06-241-1/+0
| | | | | | | | I'm not even sure when/if FFmpeg produces those. It's just confusing. If you really need this, you can still use dl-dr. I expect that most use is unintentional. Probably fixes #4545.
* ao_pulse: reorder format choiceNiklas Haas2017-06-231-2/+2
| | | | | | | | | | | | Right now, the current order pretty much means that pulse defaults to S16 for arbitrary unsupported formats, but fallback to float would make more sense since it's the easiest to convert everything to without requiring dithering, and PA will probably just internally convert things to float anyway. Also move S32 above S16, which essentially means format_maps is sorted by preference. (Although ao_pulse currently ignores this and always picks the first as a fallback)
* build: simplify OSS checks and remove changes by "bugmen0t"wm42017-06-221-6/+3
| | | | | | | | | | | | | | | | | | The user bugmen0t was apparently a shared github account with publicly available login. Thus, we can't get LGPL relicensing permission from the people who used this account. To relicense successfully, we have to remove all their changes. This commit should remove 20d1fc13, f26fb009, defbe48d. It also should remove whatever test fragments were copied from the ancient configure, as well as some configure logic (potentially that device path stuff). I think this change still preserves the most important use-cases of OSS: BSDs, and the Linux OSS emulation (the latter for testing only). According to an OSS user, the 4front checks were probably broken anyway. The SunAudio stuff was probably for (Open)Solaris, which is dead. ao_oss.c itself will remain GPL, and still contains bugmen0t changes.
* audio/format: change license to LGPLwm42017-06-202-23/+14
| | | | | | | | | | | | | | | | | | | | | | | | | Although the origins lie somewhere in libaf, which was written by "anders" and who explicitly disagreed with the LGPL relicensing, we can change the license of these files, because all code was written by "alex", who agreed with the relicensing. The only things that remain from anders' code is the AF_FORMAT_ and af_ prefixes (see e.g. 66f4e563). It was alex who redid this file and added the format identifiers we have today (507121f7). It's also nice to see that alex actually claimed copyright on format.c (221a599f). In commit efb50cab even the bitmask concept (which anders introduced with his early af_format.c code) was removed, and essentially all lines and symbols by anders were dropped. To put it into perspective: the original af_format code was for converting actual sample data and relied on OSS sample format identifiers, mpv's format.c/h provides its own sample formats, but does not do any data conversion. Remove an now inaccurate comment from format.c (it somehow even survived the typo that was present in the original commit). Also remove most of the format.c include statements - most of them are technically anders' code. We keep limits.h though.
* dec_audio, ad_lavc: change license to LGPLwm42017-06-144-22/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All relevant authors of the current code have agreed. As always, there are the usual historical artifacts that could be mentioned. For example, there used to be a large number of decoders by various authors who were not asked, but whose code was all 100% removed. (Mostly due to FFmpeg providing all codecs.) One point of contention is that Nick Kurshev might have refactored the old audio decoder code in 2001. Basically, there are hints that it might have been done by him, such as Arpi's commit message stating that the code was imported from MPlayerXP (Nick's fork), or all the files having his name in the "maintainer" field. On the other hand, the murky history of ad.h weakens this - it could be that Arpi started this work, and Nick took it (and possibly finished it). In any case, Nick could not be reached, so there is no agreement for LGPL relicensing from him. We're changing the license anyway, and assume that his change in itself is not copyrightable. He only moved code, and in addition used the equivalent video decoder framework (done by Arpi, who agreed) as template. For example, ad_functions_s was basically vd_functions_s, which the signature of the decode callback changed to the same as audio_decode(). ad_functions_s also had a comment that said it interfaces with "video decoder drivers" (I'm fixing this comment in this commit). I verified that no additional code was added that is copyright-relevant, still in today's code, and not copied from the existing code at the time (either from the previous audio decoder code or the video framework code). What apparently matters here is that none of the old code was not written by Nick, and the authors of the old code have given his agreement, and (probably) that Nick didn't add actual new code (none that would have survived), that was not trivially based on the old one (i.e. no new copyrightable "work"). A copyright expert told me that this kind of change can be considered not relevant for copyright, so here we go. Rewriting this would end with the same code anyway, and the naming conventions can't be copyrighted.
* encode_lavc: move from GPL 2+ to LGPL 2.1+.Rudolf Polzer2017-06-131-7/+8
|
* af, vf: improvements to libavfilter bridgewm42017-05-312-1/+8
| | | | | | Add the "lavfi-" prefix (details see manpage additons). Tag the filter name as "(lavfi)" in the verbose filter list output.
* ad_spdif: change license to LGPLwm42017-05-211-7/+7
| | | | | All authors have agreed. (Even the main author, if you wonder about the entry in the Copyright file.)
* ao_pcm: change license to LGPLwm42017-05-201-7/+7
| | | | | | | | | | | | | | | | | | | | | All relevant authors have agreed to the relicensing. Problem cases: eca47b1a5edae: someone else gets credited for the "idea" of this change, but it doesn't seem like it was a patch (otherwise reimar would have said "patch"). Also, the associated code got essentially removed again anyway. (The option parsing was rewritten fully.) ffb529e4eb2a9: anonymous/unknown author, but the code was fully removed anyway. The struct was removed, and the modern code does explicit read/write calls. 40789473d215b: author was not contacted, but this code was removed anyway. The magic number (0x7ffff000) is still in the new code, but I don't think that is copyright relevant. c750b8ab2d3c8: the message was entirely removed.
* audio/out: change license of some core files to LGPLwm42017-05-204-28/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | All contributors of the current code have agreed. ao.c requires a "driver" entry for each audio output - we assume that if someone who didn't agree to LGPL added a line, it's fine for ao.c to be LGPL anyway. If the affected audio output is not disabled at compilation time, the resulting binary will be GPL anyway, and ootherwise the code is not included. The audio output code itself was inspired or partially copied from libao in 7a2eec4b59f4 (thus why MPlayer's audio code is named libao2). Just to be sure we got permission from Aaron Holtzman, Jack Moffitt, and Stan Seibert, who according to libao's SVN history and README are the initial author. (Something similar was done for libvo, although the commit relicensing it forgot to mention it.) 242aa6ebd40: anders mostly disagreed with the LGPL relicensing, but we got permission for this particular commit. 0ef8e555735: nick could not be reached, but the include statement was removed again anyway. 879e05a7c17: iive agreed to LGPL v3+ only, but this line of code was removed anyway, so ao_null.c can be LGPL v2.1+. 9dd8f241ac2: patch author could not be reached, but the corresponding code (old slave mode interface) was completely removed later.
* ao_wasapi: set name of event threadJames Ross-Gowan2017-05-181-0/+2
|
* af_format: change license to LGPLwm42017-05-111-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This case is a bit weird, because MPlayer certainly also has a file named af_format.c. Both appear to have the function of converting audio data between sample formats. However, mpv's af_format.c is a rewrite, and doesn't actually do conversion by itself. It's similar to vf_format.c, and forces the generic filter chain code to insert conversion filters, instead of doing conversion explicitly. mpv's current af_format.c started out as af_force.c in d9582ad0a41. It was renamed to af_format.c in e60b8f181d, while the old af_format.c was split into two new filters. In 943c785619 the filename was changed to af_format.c as well. The new af_format.c does not contain any libaf code, except for some potentially copy & pasted skeleton and boilerplate code. (We don't account for this in per-filter file licenses, as the old libaf code has to be removed fully, at which point the filters will have to be ported to another framework, which will removed that boilerplate code.) The old filters based on af_format.c were progressively replaced and removed. Support for non-native endian and formats with signedness different from native FFmpeg was completely removed in 831d7c3c400b. The old 24 bit conversion code was removed in 552dc0d564 (made unnecessary by 5a9f817bfde8). Also list hwdec_vaglx.c as GPL-only, which doesn't have anything to do with this commit.
* af_scaletempo: change license to LGPLwm42017-05-091-7/+7
| | | | | | | | | | | | All authors have agreed. The initial commit d33703496c as well as the current code contain this line: * inspired by SoundTouch library by Olli Parviainen We assume this is about the algorithm (not the code), and the author of the original patch actually wrote all code himself.
* af_lavcac3enc: change license to LGPLwm42017-05-091-7/+7
| | | | | | | All authors have agreed. As usual with these things, this probably does not include residues from the libaf framework.
* ao_pulse, ao_rsound: change license to LGPLwm42017-05-082-14/+14
| | | | | | | | All authors have agreed. One exception is 71247a97b35, whose author was not asked, but we deem the change as trivial. (And technically it was replaced when the audio chain dropped non-native endian sample formats.)
* ao_coreaudio: change license to LGPLwm42017-05-087-49/+49
| | | | | | | | | | | | | | | | All authors have agreed to the relicensing. The code was pretty much rewritten by Stefano Pigozzi. Since the rewrite happened incrementally, and seems to include refactored portions of older code, this relicensing was done on the pre-refactor code do. The original commit adding this AO (as ao_macosx.c) credits Timothy J. Wood as original author. He was asked and agreed to LGPL. It's not entirely sure from which project this code came from, but it's probably libao. In that project, Stanley Seibert made some changes to it (who as a major developer of libao was asked just to be sure), and also Ralph Giles and Ben Hines made two small changes. The latter were not asked, but none of their code survived anyway.
* 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-071-5/+10
| | | | | | | | | | | | | If the "default" device refuses to be opened as spdif device (i.e. it errors due to the AES0 etc. parameters), we were falling back to the iec958 device. This is needed on some systems for smooth operation with PCM vs. spdif. Now change it to try "hdmi" before "iec958", which supposedly helps in other situations. Better suggestions welcome. Apparently kodi does this too, although I didn't check directly.
* audio/out: prevent underruns with spdif under certain conditionswm42016-10-041-0/+2
| | | | | | | | | | | | | | | | | The player tries to avoid splitting frames with spdif (sample alignment stuff). This can in certain corner cases with certain drivers lead to the situation that ao_get_space() returns a number higher than 0 and lower than the audio frame size. The playloop will round this down to 0 bytes and do nothing, leading to a missed wakeup. This can lead to underruns or playback completely getting stuck. It can be reproduced by playing AC3 passthrough with no video and: --ao=null --ao-null-buffer=0.256 --ao-null-outburst=6100 This commit attempts to fix it by allowing the playloop to write some additional data (to get a complete frame), that will be buffered within the AO ringbuffer even if the audio device doesn't want it.
* audio: dump timestamp differencewm42016-10-021-1/+5
| | | | | Can help to analyze timestamp jitter or seeing completely bogus timestamps.
* win32: build with -DINITGUIDJames Ross-Gowan2016-09-282-2/+0
| | | | | | | | | | | | We always want to use __declspec(selectany) to declare GUIDs, but manually including <initguid.h> in every file that used GUIDs was error-prone. Since all <initguid.h> does is define INITGUID and include <guiddef.h>, we can remove all references to <initguid.h> and just compile with -DINITGUID to get the same effect. Also, this partially reverts 622bcb0 by re-adding libuuid.a to the build, since apparently some GUIDs (such as GUID_NULL) are not declared in the source file, even when INITGUID is set.
* ao_openal: enable building on OSXJosh de Kock2016-09-211-0/+14
| | | | Signed-off-by: Josh de Kock <josh@itanimul.li>
* af_pan: fix typoHector Martin2016-09-191-2/+3
| | | | | | | | | This was in the parser code all along. As far as I can tell, *cp was intended. There is no need to check cp for NULL (nor does it make any sense to do so every time around the loop) for AF_CONTROL_COMMAND. However, s->matrixstr can be NULL, so checking for that separately is in order.
* af_rubberband: default to channels=togetherHector Martin2016-09-191-0/+1
| | | | | | | | For stereo and typical L/R-first channel arrangements, this avoids undesirable phasing artifacts, especially obvious when speed is changed and then reset. Without this, there is a very audible change in the stereo field even when librubberband is no longer actually making any speed changes.
* af_rubberband: add af-command and option to change the pitchHector Martin2016-09-191-0/+25
| | | | | This allows both fixed and dynamic control over the audio pitch using librubberband, which was previously not exposed to the user.
* af_pan: add af-command support to change the matrixHector Martin2016-09-191-19/+31
| | | | | This allows for seamless changes in the downmixing matrix without having to reinitialize the filter chain.
* af_pan: coding style fixesHector Martin2016-09-191-103/+104
|
* options: simplify M_OPT_EXITwm42016-09-171-1/+1
| | | | | | | | | | | | | There were multiple values under M_OPT_EXIT (M_OPT_EXIT-n for n>=0). Somehow M_OPT_EXIT-n either meant error code n (with n==0 no error?), or the number of option valus consumed (0 or 1). The latter is MPlayer legacy, which left it to the option type parsers to determine whether an option took a value or not. All of this was changed in mpv, by requiring the user to use explicit syntax ("--opt=val" instead of "-opt val"). In any case, the n value wasn't even used (anymore), so rip this all out. Now M_OPT_EXIT-1 doesn't mean anything, and could be used by a new error code.
* player, ao, vo: don't call mp_input_wakeup() directlywm42016-09-165-23/+35
| | | | | | | | | | | | | Currently, calling mp_input_wakeup() will wake up the core thread (also called the playloop). This seems odd, but currently the core indeed calls mp_input_wait() when it has nothing more to do. It's done this way because MPlayer used input_ctx as central "mainloop". This is probably going to change. Remove direct calls to this function, and replace it with mp_wakeup_core() calls. ao and vo are changed to use opaque callbacks and not use input_ctx for this purpose. Other code already uses opaque callbacks, or has legitimate reasons to use input_ctx directly (such as sending actual user input).
* ao_rsound: fix compilationwm42016-09-071-1/+1
| | | | Probably fixes #3501.
* ao_pcm: remove some useless messageswm42016-09-071-2/+0
| | | | | | The first one is printed even if the user disabled video (or there's no video), so just remove it. The second one uses deprecated sub-option syntax, so remove that as well.
* osdep: rename atomics.h to atomic.hwm42016-09-075-5/+5
| | | | | The standard header is stdatomic.h, so the extra "s" freaks me out every time I look at it.
* audio/out: deprecate "exclusive" sub-optionswm42016-09-053-2/+10
| | | | | | | And introduce a global option which does this. Or more precisely, this deprecates the global wasapi and coreaudio options, and adds a new one that merges their functionality. (Due to the way the sub-option deprecation mechanism works, this is simpler.)
* audio/out: deprecate device sub-optionswm42016-09-058-8/+15
| | | | | We have --audio-device, which can force the device. Also add something describing to this extent to the manpage.
* options: deprecate suboptions for the remaining AO/VOswm42016-09-0511-0/+11
|
* options: add automagic hack for handling sub-option deprecationswm42016-09-052-0/+2
| | | | | | | | | | | | | | | | | I decided that it's too much work to convert all the VO/AOs to the new option system manually at once. So here's a shitty hack instead, which achieves almost the same thing. (The only user-visible difference is that e.g. --vo=name:help will list the sub-options normally, instead of showing them as deprecation placeholders. Also, the sub-option parser will verify each option normally, instead of deferring to the global option parser.) Another advantage is that once we drop the deprecated options, converting the remaining things will be easier, because we obviously don't need to add the compatibility hacks. Using this mechanism is separate in the next commit to keep the diff noise down.
* ao_jack: move to global optionswm42016-09-051-22/+42
|
* options: add a mechanism to make sub-option replacement slightly easierwm42016-09-053-1/+4
| | | | | | | | Instead of requiring each VO or AO to manually add members to MPOpts and the global option table, make it possible to register them automatically via vo_driver/ao_driver.global_opts members. This avoids modifying options.c/options.h every time, including having to duplicate the exact ifdeffery used to enable a driver.
* ao_alsa: change sub-options to global optionswm42016-09-023-31/+53
| | | | | | Same deal as with vo_opengl. Also edit the outdated information about multichannel output a little.
* m_config: add helper function for initializing af/ao/vf/vo suboptionswm42016-09-022-8/+8
| | | | | | | | Normally I'd prefer a bunch of smaller functions with fewer parameters over a single function with a lot of parameters. But future changes will require messing with the parameters in a slightly more complex way, so a combined function will be needed anyway. The now-unused "global" parameter is required for later as well.
* vo, ao: disable positional parameter suboptionswm42016-09-011-0/+1
| | | | | | | | | | | | | | | | Positional parameters cause problems because they can be ambiguous with flag options. If a flag option is removed or turned into a non-flag option, it'll usually be interpreted as value for the first sub-option (as positional parameter), resulting in very confusing error messages. This changes it into a simple "option not found" error. I don't expect that anyone really used positional parameters with --vo or --ao. Although the docs for --ao=pulse seem to encourage positional parameters for the host/sink options, which means it could possibly annoy some PulseAudio users. --vf and --af are still mostly used with positional parameters, so this must be a configurable option in the option parser.
* vd_lavc, ad_lavc: set pkt_timebase, not time_basewm42016-08-291-1/+4
| | | | | | | | | These are different AVCodecContext fields. pkt_timebase is the correct one for identifying the unit of packet/frame timestamps when decoding, while time_base is for encoding. Some decoders also overwrite the time_base field with some unrelated codec metadata. pkt_timebase does not exist in Libav, so an #if is required.
* ad_lavc: actually tell decoder about the timebasewm42016-08-231-0/+1
| | | | Essentially forgotten in commit 05e4df3f.
* ao_alsa: log if retrieving supported channel maps failswm42016-08-221-1/+3
| | | | It's a sign that the driver doesn't implement the channel map API.
* af_lavrresample: better swr reinitializationPaul B Mahol2016-08-201-4/+5
|
* af_lavrresample: fix error if resampler could not be recreatedwm42016-08-191-4/+5
| | | | | | | | There are situations where the resampler is destroyed and recreated during playback. If recreating the resampler unexpectedly fails, the filter function is supposed to return an error. This wasn't done correctly, because get_out_samples() accessed the resampler before the check. Move the check up to fix this.
* video/audio: always provide "proper" timestamps to libavcodecwm42016-08-191-1/+1
| | | | | | | | | | | | | | | | | | | Instead of passing through double float timestamps opaquely, pass real timestamps. Do so by always setting a valid timebase on the AVCodecContext for audio and video decoding. Specifically try not to round timestamps to a too coarse timebase, which could round off small adjustments to timestamps (such as for start time rebasing or demux_timeline). If the timebase is considered too coarse, make it finer. This gets rid of the need to do this specifically for some hardware decoding wrapper. The old method of passing through double timestamps was also a bit questionable. While libavcodec is not supposed to interpret timestamps at all if no timebase is provided, it was needlessly tricky. Also, it actually does compare them with AV_NOPTS_VALUE. This change will probably also reduce confusion in the future.
* audio: improve aspects of EOF handlingwm42016-08-182-0/+7
| | | | | | | | | | | The code actually kept going out of EOF mode into resync mode back into EOF mode when the playloop had to wait after an audio EOF caused by the endpts. This would break seamless looping (as added by the next commit). Apply endpts earlier, to ensure the filter_audio() function always returns AD_EOF in this case. The idiotic ao_buffer makes this an amazing pain in the ass.
* af_lavrresample: work around libswresample misbehaviorwm42016-08-161-10/+10
| | | | | | | | | | | | | | | | | | The touched code is for seek resets and such - we simply want to reset the entire resample state. But I noticed after a seek a tiny bit of audio is missing (mpv's audio sync code inserted silence to compensate). It turns out swr_drop_output() either does not reset some internal state as we expect, or it's designed to drop not only buffered samples, but also future samples. On the other hand, libavresample's avresample_read(), does not have this problem. (It is also pretty explicit in what it does - return/skip buffered data, nothing else.) Is the libswresample behavior a bug? Or a feature? Does nobody even know? Who cares - use the hammer to unfuck the situation. Destroy and deallocate the libswresample context and recreate it. On every seek.
* 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.
* ao_alsa: make pause state more robust, reduce minor code duplicationwm42016-08-091-22/+25
| | | | | | | | | With the previous commit, ao_alsa.c now has 3 possible ways to pause playback. Actually all 3 of them need get_delay() to fake its return value, so don't duplicate that code. Also much of the code looks a bit questionable when considering inconsistent pause/resume calls from outside, so ignore redundant calls.
* ao_alsa: handle --audio-stream-silencewm42016-08-091-9/+51
| | | | | | | | | | | | | | | | | push.c does not handle this automatically, and AOs using push.c have to handle it themselves. Also, ALSA is low-level enough that it needs explicit support in user code. At least I haven't found any option that does this. We still can get away relatively cheaply by abusing underflow-handling for this. ao_alsa.c already configures ALSA to handle underflows by playing silence. So we purposely induce an underflow when opening the device, as well as when pausing or resetting the device. This introduces minor misbehavior: it doesn't account for the additional delay the initial silence adds, unless the device has fully played the fragment of silence when the player starts sending data to it. But nobody cares.
* player: add --audio-stream-silencewm42016-08-094-2/+11
| | | | | Completely insane that this has to be done. Crap for compensating HDMI crap.
* ao_coreaudio: actually use stop callbackwm42016-08-092-2/+2
| | | | | | The .pause callback is never used for pull.c-based AOs. This means this always streamed silence instead of deactivating audio.
* af_lavcac3enc: allow passing options to libavcodecwm42016-08-091-0/+7
|
* ao_wasapi: in exclusive mode do not output multichannel by defaultwm42016-08-051-1/+1
| | | | | | | | Exactly the same situation as with ao_alsa in commit 0b144eac (except that we can detect the situation better under wasapi). Essentially, wasapi will allow us to output any sample format, and not just the one configured by the user in the audio system settings.
* ao_null: use channel list option type for channel-layouts suboptionwm42016-08-051-11/+5
|
* audio: use --audio-channels=auto behavior, except on ALSAwm42016-08-049-18/+68
| | | | | | | | | | | | | | | | | | | | | | | 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.
* player: remove special-case for DL/DR speakerswm42016-08-042-41/+0
| | | | | | Pointless anyway. With superficial checking I couldn't find any decoder which actually outputs this, and AO chmap negotiation would properly ignore them anyway in most cases.
* 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.
* audio: make mp_audio_realloc[_min] ensure frame is writeablewm42016-07-311-1/+10
| | | | | | | | This is logical: the function makes sense only in situations where you are going to write to the audio data. To make it worse, av_buffer_realloc() also handles this situation, but only if the buffer size changes (simply because it can't realloc memory in use), so we have to explicitly force reallocation by unreffing the buffers first.
* osdep/io: introduce mp_flush_wakeup_pipe()Rostislav Pehlivanov2016-07-301-4/+2
| | | | Makes a fairly common occurence with wakeup_pipes easier to handle.
* audio: use idiotic FFmpeg ABI rules for public-except-not-public fieldswm42016-07-241-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FFmpeg API is incredibly weird and inconsistent about this. This is also a FFmpeg-only issue and nothing like this is in Libav - which doesn't really show FFmpeg in a very positive light. (To make it even worse: this is a full-blown Libav API incompatibility, even though this crap was added for Libav ABI-compatibility. It's absurd.) Quoting the FFmpeg header for the AVFrame.channels field: /** * number of audio channels, only used for audio. * Code outside libavutil should access this field using: * av_frame_get_channels(frame) * - encoding: unused * - decoding: Read by user. */ int channels; It says "should" not must, and it doesn't even mention av_frame_set_channels(). It's also in the section for public fields (not below a marker that indicates private fields in a public struct, like it's done e.g. in AVCodecContext). But not using the accessor will cause silent failures on ABI changes. The failure that happened due to this code didn't even make it apparent what was wrong. So just use the idiotic accessor. Also harmonize the FFmpeg-cursing in the code. (It's fully justified.) Fixes #3295. Note that mpv will still check the exact library version numbers, and reject mismatches - to protect itself from such issues in the future.
* af_lavcac3enc: use common code for AVFrame setupwm42016-07-243-16/+22
|
* audio: refactor mixer code and delete mixer.cwm42016-07-172-190/+0
| | | | | | | | | | | | | | | | | mixer.c didn't really deserve to be separate anymore, as half of its contents were unnecessary glue code after recent changes. It also created a weird split between audio.c and af.c due to the fact that mixer.c could insert audio filters. With the code being in audio.c directly, together with other code that unserts filters during runtime, it will be possible to cleanup this code a bit and make it work like the video filter code. As part of this change, make the balance code work like the volume code, and add an option to back the current balance value. Also, since the balance semantics are unexpected for most users (panning between the audio channels, instead of just changing the relative volume), and there are some other volumes, formally deprecate both the old property and the new option.
* audio: fix crashes due to broken uninit checkwm42016-07-151-5/+0
| | | | | | Since mixer->ao is always NULL now (it was really just forgotten to be removed), the uninit call never actually cleared the af field, leaving a dangling pointer that could be accessed by volume control.
* 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.
* ao_pulse: fix some volume control rounding issueswm42016-07-141-2/+3
| | | | | Volume could get easily "stuck" or making too huge steps when doing things like "add ao-volume 1".
* ao_creoaudio: print OSStatus as decimal signed integer toowm42016-07-131-1/+1
| | | | | OSStatus is quite inconsistent. Sometimes it's a FourCC, sometimes it reads as decimal signed number.
* ao_coreaudio: use correct free function on errorswm42016-07-131-1/+1
|
* 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.
* audio: don't crash when changing volume if no audio is initializedwm42016-07-091-0/+3
| | | | Oversight.
* audio: drop --softvol=no and --softvol=autowm42016-07-092-275/+14
| | | | | | | | | | | | | | Drop the code for switching the volume options and properties between af_volume and AO volume controls. interface-changes.rst mentions the changes in detail. Do this because this was exceedingly complex and had other problems as well. It was also very hard to test. It's just not worth the trouble. Some leftovers like AOCONTROL_HAS_PER_APP_VOLUME will be removed at a later point. Fixes #3322.
* ao_coreaudio: error out when selecting invalid devicewm42016-07-081-0/+7
| | | | | | | | | | | | | | | | When selecting a device that simply doesn't exist with --audio-device, AudioUnit will still initialize and start playback without complaining. But it will never call the audio render callback, which leads to audio playback simply not progressing. I couldn't find a way to get AudioUnit to report an error at all, so here's a crappy hack that takes care of this in most cases. We assume that all devices have a kAudioDevicePropertyDeviceIsAlive property. Invalid devices will error when querying the property (with 'obj!' as status code). This is not the correct fix, because we try to double-guess AudioUnit's behavior by accessing a lower label API. Suggestions welcome.
* vf, af: print filter labels in verbose modewm42016-07-061-0/+2
|
* ad_lavc: work around braindead ffmpeg behaviorwm42016-07-011-0/+6
| | | | | | | | | | | | | | | | | | | | | The libavcodec wmapro decoder will skip some bytes at the start of the first packet and return each time. It will not return any audio data in this state. Our own code as well as libavcodec's new API handling (avcodec_send_packet() etc.) discard the PTS on the first return, which means the PTS is never known for the first packet. This results in a "Failed audio resync." message. Fixy it by remember the PTS in next_pts. This field is used only if the decoder outputs no PTS, and is updated after each frame - and thus should be safe to set. (Possibly this should be fixed in libavcodec new API handling by not setting the PTS to NOPTS as long as no real data has been output. It could even interpolate the PTS if the timebase is known.) Fixes the failure message seen in #3297.
* ao_oss: do not add an entry to audio-device-list if device file missingwm42016-06-291-0/+7
| | | | | This effectively makes it go away on Linux (unless you have OSS emulation loaded).
* audio: don't add default entry to audio-device-list if AO support listingwm42016-06-291-3/+2
| | | | | | | In such cases there isn't really a reason to do so, and using such an entry would probably fail anyway. Also convenient for the following commit.
* audio: add a helper for getting frame end PTSwm42016-06-272-2/+11
| | | | Although I don't see any use for it yet, why not.
* dec_audio: fix segment boudnary switchingwm42016-06-271-3/+6
| | | | | | | | | | | | | Some bugs in this code are exposed by e.g. playing lossless audio files with --ad-lavc-threads=16. (libavcodec doesn't really support threaded audio decoding, except for lossless files.) In these cases, a major amount of audio can be buffered, which makes incorrect handling of this buffering obvious. For one, draining the decoder can take a while, so if there's a new segment, we shouldn't read audio. The segment end check was completely wrong, and used the start value.
* ao_lavc, vo_lavc: Migrate to new encoding API.Rudolf Polzer2016-06-271-76/+121
| | | | | Also marked some places for possible later refactoring, as they became quite similar in this commit.
* Fix misspellingsstepshal2016-06-263-3/+3
|
* 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.)
* ad_lavc: resume from mid-stream EOF conditions with new decode APIwm42016-06-221-0/+7
| | | | | | | | | | | | | | | | Workaround for an awful corner-case. The new decode API "locks" the decoder into the EOF state once a drain packet has been sent. The problem starts with a file containing a 0-sized packet, which is interpreted as drain packet. This should probably be changed in libavcodec (not treating 0-sized packets as drain packets with the new API) or in libavformat (discard 0-sized packets as invalid), but efforts to do so have been fruitless. Note that vd_lavc.c already does something similar, but originally for other reasons. Fixes #3106.
* audio: apply an upper bound timeout when drainingwm42016-06-121-3/+13
| | | | | | | | | | | | | | | | | | | | | | | | This helps with shitty APIs and even shittier drivers (I'm looking at you, ALSA). Sometimes they won't send proper wakeups. This can be fine during playback, when for example playing video, because mpv still will wakeup the AO outside of its own wakeup mechanisms when sending new data to it. But when draining, it entirely relies on the driver's wakeup mechanism. So when the driver wakeup mechanism didn't work, it could hard freeze while waiting for the audio thread to play the rest of the data. Avoid this by waiting for an upper bound. We set this upper bound at the total mpv audio buffer size plus 1 second. We don't use the get_delay value, because the audio API could return crap for it, and we're being paranoid here. I couldn't confirm whether this works correctly, because my driver issue fixed itself. (In the case that happened to me, the driver somehow stopped getting interrupts. aplay froze instead of playing audio, and playing audio-only files resulted in a chop party. Video worked, for reasons mentioned above, but drainign froze hard. The driver problem was solved when closing all audio output streams in the system. Might have been a dmix related problem too.)
* audio: do not wake up core during EOFwm42016-06-121-3/+4
| | | | | | | | | | | | | When we're draining, don't wakeup the core on every buffer fill, since unlike during normal playback, we won't actually get more data. The wakeup here conceptually works like wakeups with condition variables, so redundant wakeups do not hurt, so this is just a minor change and nothing of consequence. (Final EOF also requires waking up the core, but there is separate code to send this notification.) Also dump the p->still_playing field in trace logging.
* build: silence -Wunused-resultNiklas Haas2016-06-072-3/+3
| | | | | | | | For clang, it's enough to just put (void) around usages we are intentionally ignoring the result of. Since GCC does not seem to want to respect this decision, we are forced to disable the warning globally.
* ao_wasapi: initialize COM in main thread with MTAKevin Mitchell2016-06-051-2/+2
| | | | | | Since the main thread is shared by other things in the player, using STA (single threaded aparement) may have caused problems. Instead initialize in MTA (multithreaded apartment).
* ao_opensles: remove 32bit audioJosh de Kock2016-05-221-1/+0
| | | | It's unsupported by android, and can cause problems when trying to play 32bit audio. Removing 32bit fixes it by forcing 16 bit or 8 bit audio.
* ao_alsa: add more shitty workaroundswm42016-05-061-9/+25
| | | | | | | | | | | | | | | This reportedly makes it work on ODROID-C2. The idea for this hack is taken from kodi; they unconditionally set some or all of those flags. I don't trust ALSA enough to hope that setting these flags couldn't break something else, so we try without them first. It's not clear whether this is a driver bug or a bug in the ALSA libs. There is no ALSA bug tracker (the ALSA website has had a dead link to a deleted bug tracker fo years). There's not much we can do other than piling up ridiculous hacks. At least I think that at this point invalid API usage by mpv can be excluded as a cause. ALSA might be the worst audio API ever.
* ao_alsa: log final hwparams toowm42016-05-031-1/+2
| | | | snd_pcm_hw_params() updates them.
* win32: replace libuuid.a usage with initguid.hJames Ross-Gowan2016-05-011-0/+1
| | | | | | | | | | | | | | | Including initguid.h at the top of a file that uses references to GUIDs causes the GUIDs to be declared globally with __declspec(selectany). The 'selectany' attribute tells the linker to consolidate multiple definitions of each GUID, which would be great except that, in Cygwin and MinGW GCC 6.1, this method of linking makes the GUIDs conflict with the ones declared in libuuid.a. Since initguid.h obsoletes libuuid.a in modern compilers that support __declspec(selectany), add initguid.h to all files that use GUIDs and remove libuuid.a from the build. Fixes #3097
* ao_alsa: log hwparams while restricting themwm42016-04-281-0/+43
| | | | | | They can sometimes fail, so I want logging to determine what's going on. Most of them are at debug log-level, except the final hwparams.
* ao_coreaudio: remove detected_devicewm42016-04-261-5/+0
| | | | | | | | | | | Setting this here is a race condition. It's called from a CoreAudio callbacks, and there are no locks. It's a string, so this can be potentially severe. It's hard to fix and only CoreAudio supported it, so remove it. This causes the "audio-out-detected-device" property to return nothing on all platforms.
* ad_spdif: take care of deprecated libavcodec API usagewm42016-04-201-0/+7
|
* ao_coreaudio_exclusive: list formats when searching substreamwm42016-04-151-0/+3
| | | | Should help debug problems with AC3 passthrough not working.
* ao_coreaudio: remove unused functionwm42016-04-152-25/+0
|
* encode_lavc: Migrate to codecpar API.Rudolf Polzer2016-04-111-41/+41
|
* ao_coreaudio_exclusive: add missing newline to log messagewm42016-04-011-1/+1
|
* demux_lavf, ad_lavc, ad_spdif, vd_lavc: handle FFmpeg codecpar API changewm42016-03-312-2/+5
| | | | | | | | | AVFormatContext.codec is deprecated now, and you're supposed to use AVFormatContext.codecpar instead. Handle this for all of the normal playback code. Encoding mode isn't touched.
* ad_lavc, vd_lavc: support new Libav decoding APIwm42016-03-241-0/+14
| | | | For now only found in Libav.
* ad_lavc: add codec_timebase hack toowm42016-03-241-2/+5
| | | | | vd_lavc.c had this, and soon I'll need it in ad_lavc.c too. For now it's unused.
* ao_lavc: use new af_select_best_samplerate functionKevin Mitchell2016-03-171-0/+5
| | | | | | | | This is particularly useful for opus which allows only a fairly restrictive set of samplerates. If the codec doesn't provide a list of samplerates, just continue to try the requsted one and hope for the best. fixes #2957
* ao_wasapi: use new af_select_best_samplerate functionKevin Mitchell2016-03-171-11/+3
| | | | It duplicates the logic that was previously used here.
* audio: add af_select_best_samplerate functionKevin Mitchell2016-03-172-0/+32
| | | | | | This function chooses the best match to a given samplerate from a provided list. This can be used, for example, by the ao to decide what samplerate to use for output.
* ao_wasapi: make wait for audio thread termination infiniteKevin Mitchell2016-02-261-4/+3
| | | | | The time-out was a terrible hack for marginally better behaviour when encountering #1773, which appears to have been resolved by a previous commit.
* ao_wasapi: further flatten/simplify volume controlKevin Mitchell2016-02-261-39/+34
|
* ao_wasapi: use MP_FATAL for stuff that leads to init failureKevin Mitchell2016-02-262-5/+5
|
* ao_wasapi: move pre-resume reset into resume functionKevin Mitchell2016-02-261-16/+14
|
* ao_wasapi: move resetting the thread state into main loopKevin Mitchell2016-02-261-11/+3
| | | | | This was previously duplicated between the reset/resume functions, and not properly handled in the "impossible" invalid thread state case.
* ao_wasapi: set buffer size to device period in exclusive modeKevin Mitchell2016-02-261-7/+12
| | | | | | | | | | | | | This eliminates some intermittent pops heard in a HRT MicroStreamer DAC uncorrelated with user interaction. As a bonus, this resolves #1773 which I can o longer reproduce as of this commit. Leave the 50ms buffer for shared mode since that seems to be working quite well. This is also the way exclusive mode is done in the MSDN example code: https://msdn.microsoft.com/en-us/library/windows/desktop/dd370844%28v=vs.85%29.aspx This was originally increased in c545c40 to mitigate glitches that subsequent refactorings have eliminated.
* ao_wasapi: replace laggy COM messaging with mp_dispatch_queueKevin Mitchell2016-02-263-175/+80
| | | | | | | | | | A COM message loop is apparently totally inappropriate for a low latency thread. It leads to audio glitches because the thread doesn't wake up fast enough when it should. It also causes mysterious correlations between the vo and ao thread (i.e., toggling fullscreen delays audio feed events). Instead use an mp_dispatch_queue to set/get volume/mute/session display name from the audio thread. This has the added benefit of obviating the need to marshal the associated interfaces from the audio thread.
* ao_wasapi: avoid under-run cascade in exclusive mode.Kevin Mitchell2016-02-261-24/+36
| | | | | | | | | | | | | | | | Don't wait for WASAPI to send another feed event if we detect an underfull buffer. It seems that WASAPI doesn't always send extra feed events if something causes rendering to fall behind. This causes every subsequent playback buffer to under-run until playback is reset. The fix is simply to do a one-shot double feed when this happens, which allows rendering to catch up with playback. This was observed to happen when using MsgWaitForMultipleObjects to wait for the feed event and toggling fullscreen with vo=opengl:backend=win. This commit improves the behaviour in that specific case and more generally makes exclusive mode significantly more robust. This commit also moves the logic to avoid *over*filling the exclusive mode buffer into thread_feed right next to the above described underfil logic.
* ao_wasapi: fix typo in commentKevin Mitchell2016-02-261-1/+1
|
* ao_wasapi: use SUCCEEDED/FAILED macrosKevin Mitchell2016-02-262-13/+9
|
* ao: initial OpenSL ES supportIlya Zhuravlev2016-02-272-0/+254
| | | | | | | | OpenSL ES is used on Android. At the moment only stereo output is supported. Two options are supported: 'frames-per-buffer' and 'sample-rate'. To get better latency the user of libmpv should pass values obtained from AudioManager.getProperty(PROPERTY_OUTPUT_FRAMES_PER_BUFFER) and AudioManager.getProperty(PROPERTY_OUTPUT_SAMPLE_RATE).
* audio: make mp_audio_skip_samples() adjust the PTSwm42016-02-222-3/+3
| | | | Slight simplification/cleanup.
* ad_lavc: skip AVCodecContext.delay samples at beginningwm42016-02-221-0/+9
| | | | | | | | Fixes correctness_trimming_nobeeps.opus. One nasty thing is that this mechanism interferes with the container-signalled mechanism with AV_FRAME_DATA_SKIP_SAMPLES. So apply it only if that is apparently not present. It's a mess, and it's still broken in FFmpeg CLI, so I'm sure this will get fucked up later again.
* ad_lavc: make sample trimming symmetric to skippingwm42016-02-221-6/+8
| | | | | | I'm not quite sure what the FFmpeg AV_FRAME_DATA_SKIP_SAMPLES API demands here. The code so far assumed that skipping can be more than a frame, but not trimming. Extend it to trimming too.
* ad_lavc: move skipping logic out of the HAVE_AVFRAME_SKIP_SAMPLES blockwm42016-02-221-10/+13
|
* ad_lavc: interpolate missing timestampswm42016-02-221-0/+9
| | | | | | | | | | This is actually already done by dec_audio.c. But if AV_FRAME_DATA_SKIP_SAMPLES is applied, this happens too late here. The problem is that this will slice off samples, and make it impossible for later code to reconstruct the timestamp properly. Missing timestamps can still happen with some demuxers, e.g. demux_mkv.c with Opus tracks. (Although libavformat interpolates these itself.)
* audio: move frame clipping to a generic functionwm42016-02-213-33/+37
|
* Rewrite ordered chapters and timeline stuffwm42016-02-152-1/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This uses a different method to piece segments together. The old approach basically changes to a new file (with a new start offset) any time a segment ends. This meant waiting for audio/video end on segment end, and then changing to the new segment all at once. It had a very weird impact on the playback core, and some things (like truly gapless segment transitions, or frame backstepping) just didn't work. The new approach adds the demux_timeline pseudo-demuxer, which presents an uniform packet stream from the many segments. This is pretty similar to how ordered chapters are implemented everywhere else. It also reminds of the FFmpeg concat pseudo-demuxer. The "pure" version of this approach doesn't work though. Segments can actually have different codec configurations (different extradata), and subtitles are most likely broken too. (Subtitles have multiple corner cases which break the pure stream-concatenation approach completely.) To counter this, we do two things: - Reinit the decoder with each segment. We go as far as allowing concatenating files with completely different codecs for the sake of EDL (which also uses the timeline infrastructure). A "lighter" approach would try to make use of decoder mechanism to update e.g. the extradata, but that seems fragile. - Clip decoded data to segment boundaries. This is equivalent to normal playback core mechanisms like hr-seek, but now the playback core doesn't need to care about these things. These two mechanisms are equivalent to what happened in the old implementation, except they don't happen in the playback core anymore. In other words, the playback core is completely relieved from timeline implementation details. (Which honestly is exactly what I'm trying to do here. I don't think ordered chapter behavior deserves improvement, even if it's bad - but I want to get it out from the playback core.) There is code duplication between audio and video decoder common code. This is awful and could be shareable - but this will happen later. Note that the audio path has some code to clip audio frames for the purpose of codec preroll/gapless handling, but it's not shared as sharing it would cause more pain than it would help.
* audio/video: expose codec info as separate fieldwm42016-02-153-6/+6
| | | | | Preparation for the timeline rewrite. The codec will be able to change, the stream header not.
* ad_lavc: fix --ad-lavc-threads rangewm42016-02-111-1/+1
| | | | | | | The code is shared with the --vd-lavc-threads option, so using 0 for auto-detection just works. But no, this is not useful. Just change it for orthogonality.
* Initial Android supportJan Ekström2016-02-101-0/+1
| | | | | * Adds an 'android' feature, which is automatically detected. * Android has a broken strnlen, so a wrapper is added from FreeBSD.
* audio: minor simplificationwm42016-02-051-3/+0
| | | | | These fields are already deallocated by uninit_decoder(). Also remove the wrong/useless log message.
* 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.
* ao_coreaudio: fix 7.1(rear) channel mappingwm42016-02-041-0/+27
| | | | | | | | | | | | | | I can't explain this, but it seems to be a similar case to the ALSA HDMI one. I find it hard to tell because of the slightly different names and conventions in use in libavcodec, WAVEEXT channel masks, decoders, codec specifications, HDMI, and platform audio APIs. The fix is the same as the one for ao_alsa (see commit be49da72). This should fix at least playing 7.1 sources on OSX with 7.1(rear) selected in Audio MIDI Setup. The ao_alsa commit mentions XBMC, but I couldn't find out where it does that or if it also does that for CoreAudio. It's woth noting that PHT (essentially an old XBMC fork) also exhibited the incorrect behavior (i.e. side and back speakers were swapped).
* 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/video: merge decoder return valueswm42016-02-012-16/+11
| | | | | | Will be helpful for the coming filter support. I planned on merging audio/video decoding, but this will have to wait a bit longer, so only remove the duplicate status codes.
* Fix build on Libavwm42016-01-301-0/+1
| | | | I hope.
* audio: move pts reset checkwm42016-01-292-14/+1
| | | | Reduces the dependency of the filter/output code on the decoder.
* audio: move mp_audio->AVFrame conversion to a functionwm42016-01-293-20/+76
| | | | | | | | | 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).
* ao_wasapi: add "wasapi" prefix to non-static find_deviceID functionKevin Mitchell2016-01-283-3/+3
|
* ao_wasapi: correct check for specified device on default changeKevin Mitchell2016-01-283-5/+11
| | | | | | Correctly avoid a reload if the current device was specified by the user through --audio-device. Previously, we only recognized if the user had specified --ao=wasapi:device=.
* ao_wasapi: fix check for already found deviceKevin Mitchell2016-01-281-1/+1
| | | | | oops, forgot to change this when I made get_deviceID a more proper function. state->deviceID is not set or read here - that's for the caller to do.
* command: always allow setting volume/mute propertieswm42016-01-261-0/+1
| | | | | | | | | | | | | | | | | | | | | | | This seems generally easier when using libmpv (and was already requested and implemented before: see commit 327a779a; it was reverted some time later). With the weird internal logic we have to deal with, in particular the --softvol=no case (using system volume), and using the audio API's mixer (--softvol=auto on some systems), we still can't avoid all glitches and corner cases that complicate this issue so much. The API user is either recommended to use --softvol=yes or auto, or to watch the new mixer-active property, and assume the volume/mute properties have significant values if the mixer is active. Remaining glitches: - changing the volume/mute properties has no effect if no internal mixer is used (--softvol=no) and the mixer is not active; the actual mixer controls do not change, only the property values - --volume/--mute do not have an effect on the volume/mute properties before mixer initialization (the options strictly are only applied during mixer init) - volume-max is 100 while the mixer is not active
* 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.
* ao_wasapi: use correct UINT type for device enumerationKevin Mitchell2016-01-221-5/+5
| | | | | | Notably, the address of the enumerator->count member is passed to IMMDeviceCollection::GetCount(), which expects a UINT variable, not an int. How did this ever work?
* ao_wasapi: exit earlier if there are zero playback devices foundKevin Mitchell2016-01-221-0/+5
| | | | | | | | Previously, if the enumerator found no devices, attempting to get the default device with IMMDeviceEnumerator::GetDefaultAudioEndpoint would result in the cryptic (and undocumented) E_PROP_ID_UNSUPPORTED. This way, the user is given a better indication of what exactly is wrong and isolates any other possible triggers for this error.
* audio: refactor: work towards unentangling audio decoding and filteringwm42016-01-224-148/+102
| | | | | | | | | Similar to the video path. dec_audio.c now handles decoding only. It also looks very similar to dec_video.c, and actually contains some of the rewritten code from it. (A further goal might be unifying the decoders, I guess.) High potential for regressions.
* ad_spdif: if DTS-HD is requested, and profile unknown, use DTS-HDwm42016-01-201-1/+2
| | | | | This means there will be no loss if profile detection failed for some reason.
* 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.
* audio: remove initial decoding retry limitationwm42016-01-191-3/+0
| | | | | | | | | | | | | | | Seems useless. This only helped in one case: one audio stream in the sample av_find_best_stream_fails.ts had a AC3 packets which couldn't be decoded, and for which avcodec_decode_audio4() returned 0 forever. In this specific case, playback will now not start, and you have to deselect audio manually. (If someone complains, the old behavior might be restored, but differently.) Also remove the stale "bitrate" field.
* audio: move direct packet reading from decoders to common codewm42016-01-195-29/+27
| | | | Another bit of preparation.
* audio: move dec_audio.pool to ad_spdifwm42016-01-192-2/+3
| | | | That's where its only use is.
* ao_coreaudio_chmap: change license to LGPLwm42016-01-192-14/+14
| | | | | | While the situation is not really clear for the other rewritten coreaudio code, it's very clear for the channel mapping code. It was all written by us. (MPlayer doesn't even have any channel map handling.)
* Relicense some non-MPlayer source files to LGPL 2.1 or laterwm42016-01-1915-105/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* ao_wasapi: use share_mode value instead of raw option opt_exclusiveKevin Mitchell2016-01-181-1/+1
| | | | | | | Previously used opt_exclusive option to decide which volume control code to run. The might not always reflect the actual state, for example if passthrough is used. Admittedly, none of the volume controls will work anyway with passthrough, but this is the right thing to do.
* ao_openal: wipe out global context on init errorKevin Mitchell2016-01-181-0/+1
| | | | | Previously this would break all further attempts to init the driver after one had failed.
* 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.
* demux: merge sh_video/sh_audio/sh_subwm42016-01-122-18/+17
| | | | | | | | | | This is mainly a refactor. I'm hoping it will make some things easier in the future due to cleanly separating codec metadata and stream metadata. Also, declare that the "codec" field can not be NULL anymore. demux.c will set it to "" if it's NULL when added. This gets rid of a corner case everything had to handle, but which rarely happened.
* mpv_talloc.h: rename from talloc.hDmitrij D. Czarkoff2016-01-1110-10/+10
| | | | This change helps avoiding conflict with talloc.h from libtalloc.
* ao_coreaudio: replace fourcc_repr()wm42016-01-113-35/+7
| | | | Replace with the more general mp_tag_str().
* ao_wasapi: move out some utility functionswm42016-01-112-76/+1
| | | | | | Note that hresult_to_str() (coming from wasapi_explain_err()) is mostly wasapi-specific, but since HRESULT error codes are unique, it can be extended for any other use.
* player: detect audio PTS jumps, make video PTS heuristic less aggressivewm42016-01-092-1/+14
| | | | | | | | | | | | | | | | | | | | | | This is another attempt at making files with sparse video frames work better. The problem is that you generally can't know whether a jump in video timestamps is just a (very) long video frame, or a timestamp reset. Due to the existence of files with sparse video frames (new frame only every few seconds or longer), every heuristic will be arbitrary (in general, at least). But we can use the fact that if video is continuous, audio should also be continuous. Audio discontinuities can be easily detected, and if that happens, reset some of the playback state. The way the playback state is reset is rather radical (resets decoders as well), but it's just better not to cause too much obscure stuff to happen here. If the A/V sync code were to be rewritten, it should probably strictly use PTS values (not this strange time_frame/delay stuff), which would make it much easier to detect such situations and to react to them.
* ao_dsound: remove this audio outputwm42016-01-062-711/+0
| | | | | | | It existed for XP-compatibility only. There was also a time where ao_wasapi caused issues, but we're relatively confident that ao_wasapi works better or at least as good as ao_dsound on Windows Vista and later.
* ao_wasapi: remove unnecessary header fileKevin Mitchell2016-01-055-74/+31
| | | | | All the wasapi files were including both ao_wasapi.h and ao_wasapi_utils.h. Just merge them into a single file.
* ao_wasapi: initialize change notify in main threadKevin Mitchell2016-01-052-3/+6
| | | | This is something else that has nothing to do with audio rendering.
* ao_wasapi: remove old vistablob prototypeKevin Mitchell2016-01-051-2/+0
| | | | this function was removed earlier, but the prototype was missed
* ao_wasapi: make find_deviceID read only wrt struct aoKevin Mitchell2016-01-053-19/+20
| | | | This makes it clearer that state->device is being allocated.
* ao_wasapi: move device selection to main threadKevin Mitchell2016-01-053-8/+10
| | | | In attempt to simplify the audio event thread, this can now be moved out.
* ao_wasapi: avoid some redundant error messages in device selectionKevin Mitchell2016-01-051-15/+7
| | | | | If these error conditions are triggered, the called function will have already output a sufficiently informantive error message.
* ao_wasapi: alloc later to avoid free on errorKevin Mitchell2016-01-051-2/+1
| | | | | In get_device_desc, don't alloc the return value until we know there wasn't an error.
* ao_pulse: attempt to fall back to an arbitrary sample formatwm42016-01-051-2/+7
| | | | | | | | | | | | | | | | | | | | | | | Normally, PulseAudio accepts any combination of sample format, sample rate, channel count/map. Sometimes it does not. For example, the channel rate or channel count have fixed maximum values. We should not fail fatally in such cases, but attempt to fall back to a working format. We could just send pass an "unset" format to Pulse, but this is not too attractive. Pulse could use a format which we do not support, and also doing so much for an obscure corner case is not reasonable. So just pick a format that is very likely supported. This still could fail at runtime (the stream could fail instead of going to the ready state), but this sounds also too complicated. In particular, it doesn't look like pulse will tell us the cause of the stream failure. (Or maybe it does - but I didn't find anything.) Last but not least, our fallback could be less dumb, and e.g. try to fix only one of samplerate or channel count first to reduce the loss, but this is also not particularly worthy the effort. Fixes #2654.
* ao_pulse: check for sample rate boundswm42016-01-051-1/+1
| | | | | | | pa_format_info_valid() does not do this. (Although there is a proposed patch on the PulseAudio mailing list.) See #2654.
* ao_pulse: move format setting into a functionwm42016-01-051-20/+26
| | | | No real functional changes.
* ao_wasapi: remove +x flag from fileswm42016-01-044-0/+0
|
* chmap_sel: prefer inexact equivalents over perfect upmixwm42016-01-041-8/+14
| | | | | | | | | | | | | Given 5.1(side), this lets it pick 5.1 from [5.1, 7.1]. Which was probably the original intention of this replacement stuff. Until now, the opposite was done in some cases. Keep the old heuristic if the replacement is not perfect. This would mean that a subset of the channel layout is an inexact equivalent, but not all of it. (My conclusion is that audio output APIs should be designed to simply take any channel layout, like the PulseAudio API does.)
* ao_wasapi: just use a pointer to the deviceID in change_notifyKevin Mitchell2016-01-041-3/+1
| | | | | Rather than creating a new string from the device instance. This will allow moving the change_init to the main thread before the device is loaded.
* ao_wasapi: correctly name the IMMNotificationClientVtblKevin Mitchell2016-01-041-2/+2
|
* ao_wasapi: make persistent enumerator local to change_notifyKevin Mitchell2016-01-044-21/+12
| | | | This is no longer required by anything else
* ao_wasapi: rewrite device listing and selectionKevin Mitchell2016-01-042-225/+187
| | | | | | | | | | | | | Unify and clean up listing and selection. Use common enumerator code for both operations to avoid duplication or inconsistencies. Maintain, but significatnly simplify manual device selection by id, name or number. This actually fixes loading by name which didn't really work before since the "name" displayed by --audio-device=help differed from that used to match the selection, which used the device "description" instead. Save the selected deviceID in the private structure for later loading. This will permit moving the device selection into the main thread in a future commit.
* ao_wasapi: fix delay calculation againKevin Mitchell2016-01-021-6/+12
| | | | | | | | Apparently it's only wine where the qpc_position returned by IAudioClock_GetPosition can be overflowed. So actually do the rescaling correctly, but throw away the result if it looks unreasonable. this fixes a regression in 5afa68835ade9f21f9c709f791319bf9d2e35265
* ao_wasapi: fix delay calculationKevin Mitchell2015-12-211-21/+36
| | | | | | | | | | | | | | | | | | | Make sure that subtraction of performance counters is done correctly. Follow the *exact* instructions for converting performance counter to something comparable to the QPCposition returned by IAudioClient::GetPosition https://msdn.microsoft.com/en-us/library/windows/desktop/dd370889%28v=vs.85%29.aspx Also make sure that subtraction of unsigned integers is stored into a signed integer to avoid nastiness. Also be more careful about overflow in the conversion of the device position into number of samples. Avoid casting mp_time_us() to a double, and use llrint to convert the double precision delay_us back to integer for ao_read_data. Finally, actually check the return value of ao_read_data and add a verbose message if it is not the expected value. Unfortunately, there is no way to tell WASAPI when this happens since the frame_count in ReleaseBuffer must match GetBuffer.
* Fix some typos in code commentsAman Gupta2015-12-211-1/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* ao_wasapi: move volume control init to it's own functionKevin Mitchell2015-12-211-21/+34
| | | | also make failure non-fatal
* ao_wasapi: correctly handle audio session display failureKevin Mitchell2015-12-211-10/+14
| | | | | In particular, try and release/null the interface so that it won't be marshalled.
* ao_wasapi: non-fatal error handling for COM marshallingKevin Mitchell2015-12-213-55/+65
| | | | | Also make sure that CoReleaseMarshalData is called if errors occur before unmarshalling.
* ao_wasapi: wrap long lines and use only c99 comment styleKevin Mitchell2015-12-214-119/+172
| | | | | also remove a log message in AOCONTROL_UPDATE_STREAM_TITLE since none of the other controls have one.
* ao_wasapi: reorganize private structureKevin Mitchell2015-12-211-37/+36
|
* ao_wasapi: remove useless buffer_block_sizeKevin Mitchell2015-12-212-7/+0
| | | | this was only ever used for a verbose message
* ao_wasapi: move exclusive and shared-specific controls to functionsKevin Mitchell2015-12-211-75/+87
|
* ao_wasapi: call the class-specific release functionsKevin Mitchell2015-12-201-6/+6
| | | | | IUnknown_Release() might be alright, but stay on the safe side.
* ao_wasapi: check for proxy availability in controlKevin Mitchell2015-12-201-22/+37
| | | | | Make sure that the proxy has been created before using it. This will be used when a future commit makes proxy setup optional.
* ao_wasapi: actually use hw volume support information for exclusive modeKevin Mitchell2015-12-202-17/+30
| | | | | | | | | Do not try and set/get master volume in exclusive if there is no hardware support. This would just uselessly change the master slider, but have no effect on the actual volume. Furthermore if getting hardware volume support information fails, then assume it has none.
* ao_wasapi: don't cast control arg to something it isn'tKevin Mitchell2015-12-201-9/+14
| | | | | the ao_control_vol_t cast was happening outside AOCONTROL_GET/SET_VOLUME which is the only place that would be valid
* ao_wasapi: remove volume "restore" on exitKevin Mitchell2015-12-203-48/+10
| | | | | | It was complicated and not even very intuitive to the user. If you are controlling the master volume, you just have to be prepared to deal with the consequences.