summaryrefslogtreecommitdiffstats
path: root/player/audio.c
Commit message (Collapse)AuthorAgeFilesLines
* audio: check ao driver init failure to avoid use after freeShreesh Adiga2021-07-131-9/+12
| | | | | | | | reinit_audio_filters_and_output function will free mpctx->ao_chain when there is a failure during audio initialization. So modify it to return -1 in case of init failure. The return value is checked to avoid use after free. Reported by Address Sanitizer when manually specifying --ao which triggers "Failed to initialize audio driver" error.
* audio: fix replaygain being completely brokenYour Name2021-05-071-0/+1
| | | | | | | | | | | | | | | | | | Switching to a new file while keeping the AO didn't update the volume. While there's an explicit audio_update_volume() call in reinit_audio_chain_src(), it doesn't work, because at that point ao_chain->ao is still NULL, and it does nothing. That's pretty weird and might cause other problems (what happens if you try to mute while the AO is "floating"?). Regarding gapless, trying to use the AO gain for replaygain is also gross nonsense, because the new replaygain computed gain would affect audio from the previous file. It looks like replaygain should be in an af_volume filter maybe. On the other hand, I enjoy setting ridiculous replaygain-preamp values and compensating with a low volume setting, which would not work well if both gains were applied to the audio independently. For now, just add the missing call. This is orthogonal to fixing replaygain "properly".
* Revert "audio: set audio chain ao on reinit"Your Name2021-05-071-3/+1
| | | | | | | | | | | | This reverts commit 3239e41277173bace5ecc2a22910c4660642429c. I'm fairly sure this is wrong, and my next commit should fix it properly. I'm not really sure, though. Normally, the AO is set again by reinit_audio_filters_and_output() after the new audio chain has decoded a frame and knows the new format. The reason replaygain (and apparently the thing the reverted commit tried to fix) didn't work is because they work asynchronously to the audio played by the AO (i.e. buggy and hard to fix).
* audio: add two minor log messagessfan52021-04-291-2/+6
| | | | | This would have made the problem fixed in the previous commit a bit more obvious from the log output.
* audio: set audio chain ao on reinitDudemanguy2021-04-181-1/+3
| | | | | | | | | Seems to be a slight corner case with the audio API rewrite. When switching from one file to another one, the volume of the ao would never be set because the audio chain's ao wasn't set. This caused a bug with the reset-set-on-file option. The volume/property would be correctly set internally, but the gain was not actually set when the file switched. Fixes #8287.
* audio: prevent uninit_audio_out during encodingTom Wilson2021-03-151-1/+2
| | | | | | | | | | | There was a simple oversight that meant audio outputs were uninitialized during an encoding, which is not allowed, the encoding would stop with numerous errors. I added a single line to prevent the call of uninit_audio_out in reinit_audio_chain if the encoder was active and this appears to have fixed the problem without breaking anything else. Fixes #8568
* player: fix another nightmarish corner casewm42020-10-081-3/+14
| | | | Pretty much fuck this shit.
* encode: remove early EOF failure handlingwm42020-09-031-1/+0
| | | | | | | I don't see the point of this. Not doing it may defer an error to later. That's OK? For now, it seems better to reduce the encoding internal API. If someone can demonstrate that this is needed, I might reimplement it in a different way.
* audio: slightly simplify audio_start_ao()wm42020-09-031-10/+4
| | | | Get rid of an indirection; no behavior change.
* audio: reduce excessive logging of delayed audio startwm42020-09-031-2/+7
| | | | | | | Since this is a messy and fragile mechanism, I want it logged (even if it's somewhat in conflict with the verbose logging policy). On the other hand, it's unconditionally logged on every playloop iteration. So add some nonsense to log it only on progress.
* audio: do not show audio draining message when it does not make sensewm42020-09-011-1/+3
| | | | | | Just for the redundant message. The function which is called here, ao_drain(), does not care in which state it is called, and already handled this gracefully.
* audio: do not wake up player when waiting for audio state and pausedwm42020-09-011-1/+2
| | | | Bullshit.
* audio: refactor how data is passed to AOwm42020-08-291-356/+313
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: remove delay debug loggingwm42020-08-231-25/+0
| | | | Some absurd useless stuff.
* audio: redo internal AO APIwm42020-06-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* player: remove some display-adrop leftoverswm42020-05-231-5/+0
| | | | | Forgotten in one of the previous commits. Also undeprecates display-adrop since it's out of sight now.
* audio: redo video-sync=display-adropwm42020-05-231-34/+7
| | | | | | | | | | | | | | | | | 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.
* f_decoder_wrapper: replace most public fields with setters/getterswm42020-02-291-5/+5
| | | | | | | | | | | | | | | | | | | I may (optionally) move decoding to a separate thread in a future change. It's a bit attractive to move the entire decoder wrapper to there, so if the demuxer has a new packet, it doesn't have to wake up the main thread, and can directly wake up the decoder. (Although that's bullshit, since there's a queue in between, and libavcodec's multi-threaded decoding plays cross-threads ping pong with packets anyway. On the other hand, the main thread would still have to shuffle the packets around, so whatever, just seems like better design.) As preparation, there shouldn't be any mutable state exposed by the wrapper. But there's still a large number of corner-caseish crap, so just use setters/getters for them. This recorder thing will inherently not work, so it'll have to be disabled if threads are used. This is a bit painful, but probably still the right thing. Like speculatively pulling teeth.
* player: dumb seeking related stuff, make audio hr-seek defaultwm42020-02-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Try to deal with various corner cases. But when I fix one thing, another thing breaks. (And it's 50/50 whether I find the breakage immediately or a few months later.) So results may vary. The default for--hr-seek is changed to "default" (not creative enough to find a better name). In this mode, audio seeking is exact if there is no video, or if the video has only a single frame. This change is actually pretty dumb, since audio frames are usually small enough that exact seeking does not really add much. But it gets rid of some weird special cases. Internally, the most important change is that is_coverart and is_sparse handling is merged. is_sparse was originally just a special case for weird .ts streams that have the corresponding low-level flag set. The idea is that they're pretty similar anyway, so this would reduce the number of corner cases. But I'm not sure if this doesn't break the original intended use case for it (I don't have a sample anyway). This changes last-frame handling, and respects the duration of the last frame only if audio is disabled. This is mostly "coincidental" due to the need to make seeking past EOF trigger player exit, and is caused by setting STATUS_EOF early. On the other hand, this might have been this way before (see removed chunk close to it).
* audio: remove outdated commentwm42020-02-191-2/+0
| | | | | | Neither does it (directly) mess with filters, nor does it return a bool. As noticed by a comment in #6333.
* audio: slightly simplify pull underrun message printingwm42020-02-131-1/+4
| | | | | | | | | | | | | | | 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.
* command: shuffle some crap aroundwm42019-11-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | This is preparation to get rid of the option-to-property bridge (mp_on_set_option). This is a pretty insane thing that redirects accesses to options to properties. It was needed in the ever ongoing transition from something to... something else. A good example for the need of this bridge is applying profiles at runtime. This obviously goes through the config parser, but should also make all changes effective, for which traditionally the property layer is used. There isn't much left that needs this bridge. This commit changes a bunch of options (which also have a property implementation) to use option change notifications instead. Many of the properties are still left, but perform unrelated functions like OSD formatting. This should be mostly compatible. There may be some subtle behavior changes. For example, "hwdec" and "record-file" do not check for changes anymore before applying them, so writing the current value to them suddenly does something, while it was ignored before. DVB changes untested, but should work.
* player: remove some unnecessary coverart special caseswm42019-11-171-2/+1
| | | | | | | | These should not be needed, since video is in EOF mode in this case anyway. Not too sure about the video.c case to be honest, well, here goes nothing.
* audio: log A/V initial sync statuswm42019-11-171-0/+3
|
* player: partially rework --cache-pausewm42019-10-111-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The --cache-pause feature (enabled by default) will pause playback for a while if network runs out of data. If this is not done, then playback will go on frame-wise (as packets are slowly read from the network and then instantly decoded and displayed). This feature is actually useless, as you won't get nice playback no matter what if network is too slow, but I guess I still prefer this behavior for some reason. This commit changes this behavior from using the demuxer cache state only, to trying to use underrun information from the AO/VO. This means if you have a very large audio buffer, then cache-pausing will trigger once that buffer is depleted, which will be some time _after_ the demuxer cache has run out. This requires explicit support from the AO. Otherwise, the behavior should be mostly the same as before this commit. This does not care about the AO buffer. In theory, the AO may underrun, then the player will write some data to the AO buffer, then the AO will recover and play this bit of data, then the player will probably trigger the cache-pause behavior. The probability of this happening should be pretty low, so I will hold off fixing this until the next refactor of the AO chain (if ever). The VO underflow detection was devised and tested in 5 minutes, and may not be correct. At least I'm fairly sure that the combination of all the factors should make incorrect behavior relatively unlikely, but problems are possible. Also, the demux_reader_state.underrun field may be inaccurate. It's only the present state at the time demux_get_reader_state() was called, and may exclude past underruns. In theory, this could cause "close" cases to be missed. Then you might get an audio underrun without cache-pausing acting on it. If the stars align, this could happen multiple times in the row, effectively making this feature not work. The most user-visible consequence of this change is that the user will now see an AO underrun warning every time the cache runs out. Maybe this cache-pause feature should just be removed...
* ao: add API for underrun reportingwm42019-10-111-0/+2
| | | | | | | | | | | | | | 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.)
* audio: raise log level of playback reset on audio timestampwm42019-10-061-1/+1
| | | | | Make it a warning. This is such an intrusive and shitty hack (but of course my fault) that it should not be hidden.
* audio: do not try gapless if video is still ongoingwm42019-10-061-1/+5
| | | | | | | | | | In this case, gapless will most likely not work. It will result in (very slight) desync, or (more commonly with small buffer sizes), in an underflow. I think it would be legitimate to disable gapless at end of playback completely if video is enabled at all. But this would need an exception for cover art mode, so I guess the current solution is OK as well.
* audio: make playback end with --end and --audio-spdifwm42019-09-261-0/+3
| | | | | | | | | | | | | In spdif mode, there are hacks that try to cut audio on frame boundaries (blame spdif, which is a hack in itself). The "alignment" is used in a bunch of places, but --end does not respect it. This leads to some audio that can't be pushed because the alignment is off (I don't know why, not do I care), which puts audio into an underrun state forever. Fix this by discarding unusable extra samples if no new data can be expected. Fixes: #6935
* audio: fix use-after-free with fuzzed filewm42019-09-211-0/+2
| | | | | | | | | reinit_audio_filters_and_output() can fully shutdown the audio chain on failure. Specifically, it will deallocate mpctx->ao_chain. The value of that field was cached in ao_c. The code after the call did not account that the audio chain can be shutdown, and used the stale ao_c value. Fixes: #6808
* player: ensure backward playback state is propagated on track switchingwm42019-09-191-1/+5
| | | | | | | | Track switching doesn't run reset_playback_state(), so a track enabled at runtime during backward playback would lead to a messed up state. This commit just does a bad code monkey fix to this. It feels like there needs to be a much better way to propagate this state.
* player: fix --end for backwards playbackwm42019-09-191-0/+2
| | | | | | | | We need to transform the timestamp returned by get_play_end_pts(). I considered making it return the transformed timestamp directly. There are 4 callers; 2 need a transformed timestamps, 2 don't. So I guess it doesn't matter.
* audio: increase a buffer sizeBen Boeckel2018-10-311-1/+1
| | | | | | The buffer is written to in `audio_config_to_str_buf` using `snprintf` with a `%s` formatting of a 128-byte buffer. This can overflow the target buffer of 80 causing a truncated output.
* 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-031-0/+6
| | | | | | | | | | | | 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.
* audio: fix EOF handling if there was no data at allwm42018-04-201-0/+7
| | | | | | It stopped and did nothing, instead of terminating (or just letting video play, if there was any video). Regression due to recent filter changes.
* audio: don't recreate AO if a filter changes the output formatwm42018-04-151-1/+28
| | | | | | | | | | | | | | | | | | | | | | | Until recently, the AO was reinitialized strictly only on decoder format changes. But the commit for simplifying audio format negotiation removed this. Now the AO is recreated for any format change. This is sort of annoying if you change playback speed. The insertion/removal of af_scaletempo can change the sample format. For example, the acompressor filter will convert output to double, so toggling scaletempo will force the format back to float. This recreates the AO under the --gapless-audio=weak default. This likely affects a lot of other filters too. Work this around by allowing sample format changes, and keeping the current AO format in these cases. This is probably not a big problem. Most audio APIs force the output format to float anyway. This means you actually have to worry about what the default gapless mode does to your audio. If you start with a file that uses 8 bit per sample, and then continue playing a 24 bit FLAC, it will be converted down to 8 bit per sample. (Assuming they are played in a way that uses the gapless logic.)
* audio: improve behavior if filters output nothing during probingwm42018-02-211-0/+5
| | | | | | | | | | Just bail out immediately (and disable audio) if format probing has no result, instead of doing nothing and then apparently freezing. This can happen with bogus filters, cases where the first audio frame is essentially dropped by filters (can happen with large resampling factors), and if the audio track contains no packets at all, or all packets fail to decode.
* audio: move back PTS jump detection to before filter chainwm42018-02-131-19/+4
| | | | | | | | | | | The recent changes to player/audio.c moved PTS jump detection to after audio filtering. This was mostly done for convenience, because dataflow between decoder and filters was made "automatic", and jump detection would have to be done as filter. Now move it back to after decoders, again out of convenience. The future direction is to make the dataflow between filters and AO automatic, so this is a bit in the way. Another reason is that speed changes tend to cause jumps - these are legitimate, but get annoying quickly.
* audio: move to decoder wrapperwm42018-01-301-158/+62
| | | | | | | | | | | | | | | | 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.
* video: make decoder wrapper a filterwm42018-01-301-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes a source filter. vd.h mostly disappears, because mp_filter takes care of the dataflow, but its remains are in struct mp_decoder_fns. One goal is to simplify dataflow by letting the filter framework handle it (or more accurately, using its conventions). One result is that the decode calls disappear from video.c, because we simply connect the decoder wrapper and the filter chain with mp_pin_connect(). Another goal is to eventually remove the code duplication between the audio and video paths for this. This commit prepares for this by trying to make f_decoder_wrapper.c extensible, so it can be used for audio as well later. Decoder framedropping changes a bit. It doesn't seem to be worse than before, and it's an obscure feature, so I'm content with its new state. Some special code that was apparently meant to avoid dropping too many frames in a row is removed, though. I'm not sure how the source code tree should be organized. For one, video/decode/vd_lavc.c is the only file in its directory, which is a bit annoying.
* player: replace old lavfi wrapper with new filter codewm42018-01-301-3/+19
| | | | | lavfi.c is not necessary anymore, because f_lavfi.c (which was actually converted from it) can be used now.
* audio: rewrite filtering glue codewm42018-01-301-365/+164
| | | | Use the new filtering code for audio too.
* player: redo hack for video keyframe seeks with external audiowm42018-01-181-22/+0
| | | | | | | | | | | | | | | | | | | | | | | | If you play a video with an external audio track, and do backwards keyframe seeks, then audio can be missing. This is because a backwards seek can end up way before the seek target (this is just how this seek mode works). The audio file will be seeked at the correct seek target (since audio usually has a much higher seek granularity), which results in silence being played until the video reaches the originally intended seek target. There was a hack in audio.c to deal with this. Replace it with a different hack. The new hack probably works about as well as the old hack, except it doesn't add weird crap to the audio resync path (which is some of the worst code here, so this is some nice preparation for rewriting it). As a more practical advantage, it doesn't discard the audio demuxer packet cache. The old code did, which probably ruined seeking in youtube DASH streams. A non-hacky solution would be handling external files in the demuxer layer. Then chaining the seeks would be pretty easy. But we're pretty far from that, because it would either require intrusive changes to the demuxer layer, or wouldn't be flexible enough to load/unload external files at runtime. Maybe later.
* af_lavrresample: deprecate this filterwm42018-01-131-3/+7
| | | | | | 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).
*