summaryrefslogtreecommitdiffstats
path: root/player/audio.c
Commit message (Collapse)AuthorAgeFilesLines
* audio: introduce a new type to hold audio frameswm42017-08-161-20/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* player: make refresh seeks slightly more robustwm42017-08-141-6/+2
| | | | | | | | | | | | | | | | | | | | | | Refresh seeks are automatically issued when changing filters, which improves user experience if these filters change buffering or such. The refresh seek could actually overwrite a previously ongoing seek: set pause yes set time-pos 10 set vf "" Here, the video code issued a refresh seek to the previous video position, which could be different from the previously triggered (and still ongoing) seek, this overwriting the seek. Factor all refresh seek handling into a new function, and make it handle ongoing seeks correctly. Remove the weird new canonical_pts field, which actually had no use. Fixes #4757.
* player: fix another audio resync issuewm42017-08-121-1/+1
| | | | | | | | | | | This oddly triggers bogus EOF when switching filter graphs between two audio files (in this case, "[vid1]f[vo];[aid2]f[ao]"->"[aid1]f[ao]", with aid2 being an external audio source). This commit also fixes desync when seeking with an external file connected via --lavfi-complex. (Yes, the audio resync code is cursed.)
* player: make --lavfi-complex changeable at runtimewm42017-08-121-21/+13
| | | | | | | | Tends to be somewhat glitchy if subtitles are enabled, and you enable and disable tracks. On error, this will disable --lavfi-complex, which will result in whatever behavior.
* player: fix --lavfi-complex freezewm42017-08-111-1/+3
| | | | | | | | | | | | | | | | | | | Commit 0e0b87b6f3297 fixed that dropped packets did not trigger further work correctly. But it also made trivial --lavfi-complex freeze. The reason is that the meaning if DATA_AGAIN was overloaded: the decoders meant that they should be called again, while lavfi.c meant that other outputs needed to be checked again. Rename the latter meaning to DATA_STARVE, which means that the current input will deliver no more data, until "other" work has been done (like reading other outputs, or feeding input). The decoders never return DATA_STARVE, because they don't get input from the player core (instead, they get it from the demuxer directly, which is why they still can return DATA_WAIT). Also document the DATA_* semantics in the enum. Fixes #4746.
* player: fix confusion in audio resync codewm42017-08-081-2/+6
| | | | | | | | | | Just the audio resync code in its normal state: buggy. This time, AD_NO_PROGRESS was handled about the same as AD_WAIT. But it means the decoder didn't output data, even though input is still readily available. This happened in particular when the timeline code was used (potentially skipping many packets), and thus should fix #4688.
* player: fix --end with large valueswm42017-08-081-2/+5
| | | | | | Causea a simple integer overflow. Fixes #4650.
* player: change license of most core files to LGPLwm42017-06-231-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These files have all in common that they were fully or mostly taken from mplayer.c. (mplayer.c was a huge file that contains almost all of the playback core, until it was split into multiple parts.) This was probably the hardest part to relicense, because so much code was moved around all the time. player/audio.c still does not compile. We'll have to redo audio filtering. Once that is done, we can probably actually provide an actual LGPL configure switch. Here is a relatively detailed list of potential issues: 8d190244: author did not reply, parts were made GPL-only in a previous commit. 7882ea9b: author could not be reached, but the code is gone. wscript still has --datadir switch, but I don't think this is relevant to copyright. f197efd5: unclear origin, but I consider the code gone anyway (replaced with generic OSD mechanisms). 8337d9c2: author did not reply, but only the option still exists (under a different name), other code was removed. d8fd7131: did not reply. Disabled in a previous commit. 05258251: same author as above. Both fields actually seem to have vanished (even when tracking renames), so no action taken. d459e644, 268b2c1a: author did not reply, but we reuse only the options (with different names and slightly or fully different semantics, and completely different implementations), so I don't think this is relevant for copyright. 09e742fe, 17c39c4e: same as above. e8a173de, bff4b3ee: author could not be reached. The commands were reworked to properties, and the code outside of the TV code were moved back to the TV code. So I don't think copyright applies to the current command.c parts (mp_property_tv_color, mp_property_tv_freq, mp_property_tv_scan). The TV parts remain GPL. 0810e427: could not be reached. Disabled in a previous commit. 43744a2d: unknown author, but this was replaced by dynamic alloc (if the change is even copyrightable). 116ca0c7: unknown author; reasoning see input.c relicensing commit. e7e4d1d8: these semantics still exist, but as generic code, and this code was fully removed. f1175cd9: the author of the cited patch is unknown, and upon inspection it turns out that I was only using the idea to pause the player on EOF, so I claim it's not copyright relevant. 25affdcc: author could not be reached (yet) - but it's only a function rename, not copyrightable. 5728504c was committed by Arpi (who agreed), but hints that it might be by a different author. In fact it seems to be mostly this patch: http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2001-November/002041.html The author did not respond, but it all seems to have been removed later. It's a terrible mess though. Arpi reverted the A-V sync code at first, but left the RTC code for a while. The following commits remove these changes 100%: 14b35442, 7181a091, 31482783, 614f8475, df58e822. cehoyos did explicitly not agree to LGPL, but was involved in the following changes: c99d8fc8: applied a patch and didn't modify it, the original author agreed. 40ac0d31: author could not be reached, but all code is gone anyway. The "af" command has a similar function, but works completely different and actually reuses a mechanism older than this patch. 54350436: applied a patch, but didn't modify it, except for adding a German translation, which was removed later. a2dda036: same situation as above 240b743e: this was made GPL-only in a previous commit 7b25afd7: same as above (for now) kirijua could not be reached, but was a regular patch contributor: c2c997fd: video equalizer code move; probably not copyrightable. Is GPL due to Nick anyway. be54f481: technically, this became the audio track property later. But all what is left is the fact that you pass a track ID to it, so consider the original coypright non-relevant. 2f376d1b: this was rewritten in b7052b43, but for now we can afford to be careful, so this was marked as GPL only in a previous commit. 43844d09: remaining parts in main.c were reverted in a previous commit. anders has mostly disagreed with the LGPL relicensing. Does not want libaf to become LGPL, but made some concessions. In particular, he granted us permission to relicense 4943e9c52c and 242aa6ebd4. We also consider some of his changes remaining in mpv not relevant for copyright (such as 735de602 - we won't remove the this option completely). We will completely remove his other contributions, including the entire audio filter chain. For now, this stuff is marked as GPL only. The remaining question is how much code in player/audio.c (based on the former mplayer.c and dec_audio.c) is under his copyright. I made claims about this in a previous commit. Nick(ols) Kurshev, svn username "nick" and "nickols_k", could not be reached. He had a lot of changes in early MPlayer. It seems all of that was removed, at least in mpv. His main work, like VIDIX or libswscale work, does not exist in mpv anymore, but the changes to mplayer.c and other core parts still deserve attention: a4119f6b, fb927549, ad3529b8, e11b23dc, 5f2178be, 93c371d5: removed in b43d67e0, d1628d12, 24ed01fe, df58e822. 0a83c6ec, 104c125e, 4e067f62, aec5dcc8, b587a3d6, f3de6e6b: DR, VAA, and "tune" stuff was fully removed later on or replaced with other mechanisms. 340183b0: screenshots were redone later (the VOCTRL was even removed, with an independent implementation using the same VOCTRL a few years later), so not relevant anymore. Basically only the 's' shortcut remains (but not its implementation). 92c5c274, bffd4007, 555c6766: for now marked as GPL only in a previous commit. Might contain some trace amounts of "michael"'s copyright, who agreed to LGPL only once the core is relicensed. This will still be respected, but I don't think it matters at this in this case. (Some code touched by him was merged into mplayer.c, and then disappeared after heavy refactoring.) I tried to be as careful and as complete as possible. It can't be excluded that amends to this will be made later. This does not make the player LGPL yet.
* player/audio: mark some libaf interfacing parts as GPL onlywm42017-06-231-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | "anders" has not agreed to relicense most of his changes (although he gave permission for 4943e9c52c and 242aa6ebd4). Note that commit 3053a8b7f is in part also affected. The commit message hides this, but it seems some code was based on anders': http://mplayerhq.hu/pipermail/mplayer-dev-eng/2002-October/011773.html Much of the final commit was by Arpi, but it's still grating that there was no proper attribution (and in a case that turned out to be so important). This means player/audio.c won't even compile (and other parts of the player also use audio/audio.h, which is still GPL). But whether the end result compiles doesn't matter for copyright. Due to the heavy refactoring applied over the year, the boundaries are rather fuzzy and also somewhat arbitrary, though. Most of this code will have to be replaced with a new filter chain later.
* audio: replace from_dB functionwm42017-05-051-8/+4
| | | | | | | | The author of the old code disagreed with LGPL. The new code is a clean room reimplementation by Niklas Haas. It lacks the clamping, but we decided it doesn't matter. Untested, bugs can be fixed later anyway.
* audio: merge --replaygain-track and --replaygain-album into one optionwm42017-04-271-2/+2
| | | | | This is probably better than separate options. For example, the user does not have to guess which one is applied if both options are enabled.
* audio: fix replaygain volume scalewm42017-04-271-0/+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.)
* audio: move replaygain control to top-level optionswm42017-04-261-0/+49
| | | | | | | | | | | | | | | | | | | | | af_volume is deprecated, and so are its replaygain sub-options. To make it possible to use replaygain without deprecated options (and of course to make it available at all after af_volume is dropped), reintroduce them as top-level options. This also means that they are easily changeable at runtime by using them as properties. Change the "volume" property to use the new update mechanism as well. We don't actually bother sharing the implementation between new and deprecated mechanisms, as the deprecated one will simply be deleted. For the from_dB() functions, we mention anders' copyright, although I'm not sure if a mere formula is copyrightable. This will have to be determined later. This whole change is mostly untested. Our distributed human CI will take care of it.
* player: close audio device on no audio trackMarko Hauptvogel2017-04-251-1/+3
| | | | | | | | | Close the audio device if there is no audio track (or stream) in the current file. It will be opened again if the next file should contain audio. Signed-off-by: Marko Hauptvogel <marko.hauptvogel@googlemail.com> Signed-off-by: wm4 <wm4@nowhere>
* audio: deprecate most audio filterswm42017-04-041-1/+2
| | | | | Well, ok, only 4 filters. The rest will survive in one or the other form.
* player: specifically log audio EOF toowm42017-03-141-1/+3
|
* audio: stop being dumbwm42017-01-081-1/+1
| | | | | | | | | | | | | | | | | Obvious mistake: we entered EOF drain mode if the decoder returned AD_WAIT, which is very wrong. AD_WAIT means we should retry after waiting for a while (or to be precise, until the demuxer/decoder have more data). We should just pass down this status, and not change the audio chain state. This was exposed by a libavfilter EOF handling bug. Feeding a filter chain with af_dynaudnorm, and sending an EOF before a frame is returned makes it stuck and keeps returning EAGAIN, instead of returning the buffered audio. In combination with the bug at hand, which entered EOG drain mode, it could happen that it got stuck due to libavfilter discarding buffered data each time the demuxer ran out of data. Fixes #3997.
* audio: force pts_reset only when pts jumps forward more than 5sAman Gupta2016-10-211-2/+2
| | | | | | i've seen several mpegts samples where pts jumps backwards and repeats itself. this usually happens on live tv streams from cable providers, particularly when the stream switches from one advertisement to another.
* audio: move some fallback handling to common AO reload functionwm42016-10-051-19/+33
| | | | | | | | | Now a reload requested by an AO behaves in exactly the same way as changing an AO-related options (like --audio-channels or --audio-exclusive). This is good for testing and uniform behavior. (You could go as far as saying it's a necessity, because the spotty and obscure AO reload behavior is hard to reproduce and thus hard to test at all.)
* audio: fix late audio startwm42016-10-021-1/+3
| | | | | | | | | Regression since commit bbcd0b6a. This code is just cursed, because it's a fragile state machine with no proper tests, and which could be done in a much simpler way. Without doubt this change will cause a regression in some ridiculous corner case as well. Fixes #3610 (the cause of it, not the behavior it resulted in).
* audio: fix segfault when yanking USB DACKevin Mitchell2016-09-201-0/+1
| | | | | The ao_c pointer was stale after the mpctx entry was freed / NULLed. This prevented the correct early exit from fill_audio_out_buffers.
* player: litter code with explicit wakeup callswm42016-09-161-11/+11
| | | | | | | | | | | | | This does 3 kinds of changes: - change sleeptime=x to mp_set_timeout() - change sleeptime=0 to mp_wakeup_core() calls (to be more explicit) - change commands etc. to call mp_wakeup_core() if they do changes that require the playloop to be rerun This is preparation for the following changes. The goal is to process client API requests without having to rerun the playloop every time. As of this commit, the changes should not change behavior. In particular, the playloop is still implicitly woken up on every command.
* player, ao, vo: don't call mp_input_wakeup() directlywm42016-09-161-2/+2
| | | | | | | | | | | | | 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).
* audio: fix missed wakeup when changing audio output devicewm42016-09-151-1/+1
| | | | | | | | When playing audio-only, and changing the audio output device, playback froze until the next time the playback core happened to wakeup (like moving the mouse, or OSD redrawing). This is probably because of the awful statemachine in fill_audio_out_buffers() - just make it recreate the AO directly instead.
* audio/out: deprecate "exclusive" sub-optionswm42016-09-051-0/+3
| | | | | | | 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: avoid missed wakeups with ab-loopswm42016-08-241-1/+5
| | | | Could get "stuck".
* audio: do not apply --audio-channels if spdif passthrough is in usewm42016-08-221-5/+9
| | | | | | | | If spdif is enabled, the channel layout has no meaning other than setting the number of channels. The number of channels must be fixed to achieve the exact bitrate required. Fixes #3445.
* audio: improve aspects of EOF handlingwm42016-08-181-19/+40
| | | | | | | | | | | 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.
* player: allow passing flags to queue_seek()wm42016-08-151-1/+1
| | | | | | | | | | | | Change the last parameter from a bool to an int, which is supposed to take bit-flags. The at this point only flag is MPSEEK_FLAG_DELAY, which replaces the previous bool parameter. The old false parameter becomes 0, the old true parameter becomes MPSEEK_FLAG_DELAY. Since the old "immediate" parameter is now essentially inverted, two coalesced immediate and delayed seeks end up as delayed instead of immediate. This change doesn't matter, since there are no relative immediate seeks anyway.
* player: add --audio-wait-open optionswm42016-08-091-0/+9
| | | | Complements the option added in the previous commit.
* player: add --audio-stream-silencewm42016-08-091-0/+3
| | | | | Completely insane that this has to be done. Crap for compensating HDMI crap.
* player: gross hack to improve non-hr seeking with external audio trackswm42016-08-071-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Relative seeks backwards with external audio tracks does not always work well: it tends to happen that video seek back further than audio, so audio will remain silent until the audio's after-seek position is reached. This happens because we strictly seek both video and audio demuxer to the approximate desirted target PTS, and then start decoding from that. Commit 81358380 removes an older method that was supposed to deal with this. It was sort of bad, because it could lead to the playback core freezing by waiting on network. Ideally, the demuxer layer would probably somehow deal with such seeks, and do them in a way the audio is seeked after video. Currently this is infeasible, because the demuxer layer assumes a single demuxer, and external tracks simply use separate demuxer layers. (MPlayer actually had a pseudo-demuxer that joined external tracks into a single demuxer, but this is not flexible enough - and also, the demuxer layer as it currently exists can't deal with dynamically removing external tracks either. Maybe some time in the future.) Instead, add a gross hack, that essentially reseeks the audio if it detects that it's too far off. The result is actually not too bad, because we can reuse the mechanism that is used for instant track switching. This way we can make sure of the right position, without having to care about certain other issues. It should be noted that if the audio demuxer is used for other tracks too, and the demuxer does not support refresh seeking, audio will probably be off by even a higher amount. But this should be rare.
* player: fix mid-stream audio sync conditionwm42016-08-071-3/+3
| | | | | | | | | | This code is for resyncing audio-only streams (e.g. switching between audio tracks if no video track is active). This must not be run if the video PTS just isn't known yet. (Although the case in which this changes anything is probably very obscure, if it can even happen. Still, it's a bit more correct.) This is a correction to commit 91a3bda6.
* player: sync audio as well when enabling it mid-streamwm42016-08-061-0/+3
| | | | | | If an audio track is enabled during playback, then make it resume at the exact "current position", instead of playing audio before that position. This was already done for video.
* audio: use --audio-channels=auto behavior, except on ALSAwm42016-08-041-3/+15
| | | | | | | | | | | | | | | | | | | | | | | 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-041-2/+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.
* audio: refactor mixer code and delete mixer.cwm42016-07-171-4/+68
| | | | | | | | | | | | | | | | | 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: drop --softvol=no and --softvol=autowm42016-07-091-1/+1
| | | | | | | | | | | | | | 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.
* player: really start audio only once video is readywm42016-04-201-5/+10
| | | | | | | | | | | | | | | The check whether video is ready yet was done only in STATUS_FILLING. But it also switched to STATUS_READY, which means the next time fill_audio_out_buffers() was called, audio would actually be started before video. In most situations, this bug didn't show up, because it was only triggered if the demuxer didn't provide video packets quickly enough, but did for audio packets. Also log when audio is started. (I hate fill_audio_out_buffers(), why did I write it?)
* player: add missing audio reconfig eventswm42016-03-131-0/+4
| | | | | | | This also takes care of sending the required property change notifications. Fixes #2929 and maybe fixes #2920.
* player: minor simplificationwm42016-02-271-1/+2
| | | | |