summaryrefslogtreecommitdiffstats
path: root/player/audio.c
Commit message (Collapse)AuthorAgeFilesLines
* player: fix exiting if both audio and video fail initializingwm42014-10-231-4/+1
| | | | | | | | | | | | | The player was supposed to exit playback if both video and audio failed to initialize (or if one of the streams was not selected when the other stream failed). This didn't work; for one this check was missing from one of the failure paths. And more importantly, both checked the current_track array incorrectly. Fix these issues, and move the failure handling code into a common function. CC: @mpv-player/stable
* audio: don't go to sleep after audio reinitwm42014-10-171-0/+1
| | | | | | | It possibly goes to sleep without actually starting to decode audio. Possibly fixes a problem with --no-osc --no-video reported on IRC. CC: @mpv-player/stable
* player: fix crash on early audio uninitwm42014-10-161-2/+2
| | | | | | | Could crash when exiting playback in very early stages of initialization. CC: @mpv-player/stable
* player: exit if audio init fails and there's no videowm42014-10-101-0/+2
| | | | | | Seems logical. For some reason, the player allows deselecting both audio and video stream without quitting (a deliberate feature of which I have no idea why it was added years ago), so this is needed.
* player: remove central uninit_player() function and flags messwm42014-10-031-13/+36
| | | | | | | | | | | | | | Each subsystem (or similar thing) had an INITIALIZED_ flag assigned. The main use of this was that you could pass a bitmask of these flags to uninit_player(). Except in some situations where you wanted to uninitialize nearly everything, this wasn't really useful. Moreover, it was quite annoying that subsystems had most of the code in a specific file, but the uninit code in loadfile.c (because that's where uninit_player() was implemented). Simplify all this. Remove the flags; e.g. instead of testing for the INITIALIZED_AO flag, test whether mpctx->ao is set. Move uninit code to separate functions, e.g. uninit_audio_out().
* player: don't print audio/video init failure message twicewm42014-10-021-1/+2
| | | | | | | The messages "Audio: no audio" and "Video: no video" could be printed twice each if initializing them failed. Prevent his silliness. CC: @mpv-player/stable
* audio: enable pitch correction by default when playing fastwm42014-10-021-2/+37
| | | | | | | Apparently this is what users want. When playing with normal speed, nothing is done. When playing slower than normal, resampling is used instead, because scaletempo (which does the pitch correction) adds too many artifacts.
* command: move setting playback speed to a separate functionwm42014-10-021-0/+13
|
* audio: refactor some aspects of filter chain setupwm42014-10-021-37/+37
| | | | | | | | | | | There's no real reason why audio_init_filter() should exist. Just use af_init or af_reinit directly. (We lose a useless message; the same information is printed in a quite close place with more details.) Requires less code, and the way the filter chain is marked as having failed to initialize allows just switching off audio instead of crashing if trying to insert a volume filter in mixer.c fails, and recreating the old filter chain fails too.
* audio: remove --audiodropwm42014-09-301-14/+0
| | | | | | | | | | | | | | | This would play some silence in case video was slower than audio. If framedropping is already enabled, there's no other way to keep A/V sync, short of changing audio playback speed (which would give worse results). The --audiodrop option inserted silence if there was more than 500ms desync. This worked somewhat, but I think it was a silly idea after all. Whether the playback experience is really bad or slightly worse doesn't really matter. There also was a subtle bug with PTS handling, that apparently caused A/V desync anyway at ridiculous playback speeds. Just remove this feature; nobody is going to use it anyway.
* audio: cleanup spdif format definitionswm42014-09-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this commit, there was AF_FORMAT_AC3 (the original spdif format, used for AC3 and DTS core), and AF_FORMAT_IEC61937 (used for AC3, DTS and DTS-HD), which was handled as some sort of superset for AF_FORMAT_AC3. There also was AF_FORMAT_MPEG2, which used IEC61937-framing, but still was handled as something "separate". Technically, all of them are pretty similar, but may use different bitrates. Since digital passthrough pretends to be PCM (just with special headers that wrap digital packets), this is easily detectable by the higher samplerate or higher number of channels, so I don't know why you'd need a separate "class" of sample formats (AF_FORMAT_AC3 vs. AF_FORMAT_IEC61937) to distinguish them. Actually, this whole thing is just a mess. Simplify this by handling all these formats the same way. AF_FORMAT_IS_IEC61937() now returns 1 for all spdif formats (even MP3). All AOs just accept all spdif formats now - whether that works or not is not really clear (seems inconsistent due to earlier attempts to make DTS-HD work). But on the other hand, enabling spdif requires manual user interaction, so it doesn't matter much if initialization fails in slightly less graceful ways if it can't work at all. At a later point, we will support passthrough with ao_pulse. It seems the PulseAudio API wants to know the codec type (or maybe not - feeding it DTS while telling it it's AC3 works), add separate formats for each codecs. While this reminds of the earlier chaos, it's stricter, and most code just uses AF_FORMAT_IS_IEC61937(). Also, modify AF_FORMAT_TYPE_MASK (renamed from AF_FORMAT_POINT_MASK) to include special formats, so that it always describes the fundamental sample format type. This also ensures valid AF formats are never 0 (this was probably broken in one of the earlier commits from today).
* player: reset last_av_difference if not applicablewm42014-09-201-0/+1
| | | | | | Don't let stale values linger around. Also fix a slightly related case in audio.c.
* audio: fix initial sync with huge AO bufferwm42014-09-061-1/+1
| | | | | | | | | | | | | | With e.g --start=-3 --audio-buffer=10 the decoder entered EOF state before the initial sync was finished, entered STATUS_EOF, and just started playing audio from a random position. This doesn't handle seeking outside of the file, which is a different case. E.g. --start=30:00 with audio and video enabled in a file shorter than 30:00 will play a random last part of audio. This could perhaps be fixed by using the hr-seek target for cutting audio, instead of the video PTS, but that would be kind of intrusive, so don't do it for now. The simpler solution, assuming audio EOF on video EOF, wouldn't work, because we allow audio to start before video, or to last after video.
* audio: correctly initialize output bufferwm42014-09-051-0/+6
| | | | | | | Just like the previous commit, this takes care of fallout from commit 7ab228, which fixed a bug, but introduced some new ones. CC: @mpv-player/stable
* audio: fix obscure audio resync failure with timelineswm42014-09-051-3/+3
| | | | | | | | | | | | | | | | | Somehow, there was a larger misunderstanding in the code: ao_buffer does not need to be preserved over audio reinit for proper support of gapless audio. The actual AO internal buffer takes care of this. In fact, preserving ao_buffer just breaks audio resync. In the ordered chapter case, end_pts is used, which means not all audio data in the buffer is played, thus some data is left over when audio decoding resumes on the next segment. This triggers some code that aborts resync if there's "audio decoded" (ao_buffer contains something), but no PTS is known (nothing was actually decoded yet). Simplify, and always bind the output buffer to the decoder. CC: @mpv-player/stable (maybe)
* cosmetics: remove a stray ';'wm42014-09-051-1/+1
|
* audio: go to draining state instead of EOF if audio starts laterwm42014-08-311-2/+2
| | | | | | Probably no observable effect, but it's more correct. Setting audio to EOF could have bad effects otherwise (anywhere the player logic for example decides whether EOF was reached, and such).
* audio: restore old speed change behaviorwm42014-08-281-2/+0
| | | | | | | | | | | | | | | | | | | | Don't attempt to resync after speed changes. Note that most other cases of audio reinit (like switching tracks etc.) still resync, but other code paths take care of setting the audio_status accordingly. This restores the old behavior of not trying to fix audio desync, which was probably changed with commit 261506e3. Note that the code as of now wasn't even entirely correct, since the A/V sync values are slightly shifted. The dsync depends on the audio buffer size, so a larger buffer size will show more extreme desync. Also see mplayer2 commit 213a224e, which should fixed this - it was not merged into mpv, because it disabled audio for too long, resulting in a worse user experience. This is similar to the issue this commit attempts to fix. Fixes: #1042 (probably) CC: @mpv-player-stable
* player: minor changeswm42014-08-251-5/+1
| | | | | | | | | | | | This shouldn't change anything functionally. Change the A/V desync message. --framedrop is enabled by default now, so the text must be changed a little. I've never heard of audio outputs messing up A/V sync recently, so remove that part. Remove the unused ao_pts field. Reorder 2 A/V sync related expressions so that they look the same.
* audio: minor improvements to timeline switchingwm42014-08-231-7/+0
| | | | | | | | In theory, timestamps can be negative, so we shouldn't just return -1 as special value. Remove the separate code for clearing decode buffers; use the same code that is used for normal seek reset.
* player: fix recent speed change regressionwm42014-08-221-2/+2
| | | | | | | | | | | | | | Commit 5afc025c broke this. The reason is that mpctx->delay is updated when a new video frame is added. This value is also needed to resync audio, but it will be for the wrong PTS. They must be consistent with each other, and if they aren't, initial sync will be off by N video frames, which results at least in worse user experience. This can be reproduced by for example heavily switching between normal and 2x speed, or similar. Fix by readding the video_next_pts field (keeping its use minimal, instead of reverting the commit that removed it).
* video: get rid of video_next_pts fieldwm42014-08-221-2/+2
| | | | | | Not really needed anymore. Code should be mostly equivalent. Also get rid of some other now-unused or outdated things.
* audio: add a mode to insert silence on severe A/V desyncwm42014-08-151-4/+17
| | | | | | This is probably a stupid idea, but it can't be denied that this actually allows playing video without larger desync, even if video is too slow.
* player: use virtual time for --audio-file with ordered chapterswm42014-08-151-1/+2
| | | | | | | | | Apparently users prefer this behavior. It was used for subtitles too, so move the code to calculate the video offset into a separate function. Seeking also needs to be fixed. Fixes #1018.
* audio: fix inverted conditionwm42014-08-061-6/+4
| | | | | Recent regression. Could perhaps make gapless audio fail to work correctly.
* audio: simplify conditionwm42014-07-311-1/+1
| | | | | The expression added with the previous commit (0cce8fe6) looked slightly more complicated than it has to be. The code is equivalent.
* audio: fix A/V sync in encoding modewm42014-07-311-0/+5
| | | | | | | | | | | | | | | | | | | | | In encoding mode, the AO pretends to be infinitely fast (it will take whatever we write, without ever rejecting input). Commit 261506e3 broke this somehow. It turns out an old hack dealing with this was accidentally dropped. This is the hunk of code whose semantics were (partially) dropped: if (mpctx->d_audio && (mpctx->restart_playback ? !video_left : ao_untimed(mpctx->ao) && (mpctx->delay <= 0 || !video_left))) { int status = fill_audio_out_buffers(mpctx, endpts); // Not at audio stream EOF yet audio_left = status > -2; } This if condition is pretty wild, and it looked like it was pretty much for audio-only mode, rather than subtle handling for encoding mode.
* player: move video display code out of the playloopwm42014-07-301-1/+2
| | | | | | | | | | Basically move the code from playloop.c to video.c. The new function write_video() now contains the code that was part of run_playloop(). There are no functional changes, except handling "new_frame_shown" slightly differently. This is done so that we don't need new a new MPContext field or a return value for write_video() to signal this condition. Instead, it's handled indirectly.
* player: split seek_reset()wm42014-07-301-0/+8
| | | | | | | | This also reduces some code duplication with other parts of the code. The changfe is mostly cosmetic, although there are also some subtle changes in behavior. At least one change is that the big desync message is now printed after every seek.
* audio: better sync behavior on bogus EOFwm42014-07-301-1/+3
| | | | | | | In situations when the demuxer reports EOF, but immediately "recovers" after that and returns new data, it could happen that audio sync was skipped. Deal with this by actually entering the EOF state, instead of assuming this will happen later.
* audio: better initial sync for files where audio starts laterwm42014-07-301-5/+15
| | | | | | | Some files have the first audio much later into the video (for whatever reasons). Instead of appending large amounts of silence to the audio buffer (and refusing to sync if the audio to append is "too large"), just wait until enough video has played.
* audio: cosmetics: remove unused return valuewm42014-07-301-10/+8
|
* audio: ignore (some) decoding errors on initializationwm42014-07-291-1/+4
| | | | | | | | | | | | It probably happens relatively often that the first packet (or even the first N packets) of a stream will fail to decode, but decoding will eventually succeed at a later point. Before commit 261506e3, this was handled by an explicit retry loop (although this was also for other purposes), but with then was changed to abort on the first error. This makes it impossible to decode some audio streams. Change this so that errors are ignored for the first 50 packets, which should make it equivalent to the old code.
* player: fix desync when seeking and switching external trackswm42014-07-291-1/+1
| | | | | | | | | | | | If you for example use --audio-file, disable the external track, seek, and enable the external track again, the playback position of the external file was off, and you would get major A/V desync. This was actually supposed to work, but broke at some time ago (probably commit 2b87415f). It didn't work, because it attempted to seek the stream if it was already selected, which was always true due to reselect_demux_streams() being called before that. Fix by putting the initial selection and the seek together.
* audio: change playback restart and resyncingwm42014-07-281-136/+162
| | | | | | | | | | | | | | | | | | | | | This commit makes audio decoding non-blocking. If e.g. the network is too slow the playloop will just go to sleep, instead of blocking until enough data is available. For video, this was already done with commit 7083f88c. For audio, it's unfortunately much more complicated, because the audio decoder was used in a blocking manner. Large changes are required to get around this. The whole playback restart mechanism must be turned into a statemachine, especially since it has close interactions with video restart. Lots of video code is thus also changed. (For the record, I don't think switching this code to threads would make this conceptually easier: the code would still have to deal with external input while blocked, so these in-between states do get visible [and thus need to be handled] anyway. On the other hand, it certainly should be possible to modularize this code a bit better.) This will probably cause a bunch of regressions.
* audio: cosmetics: collapse a functionwm42014-07-241-14/+6
| | | | | There's no need for build_afilter_chain() to be a separate function anymore.
* audio: fix race condition in EOF codewm42014-07-241-1/+1
| | | | | | | | | | Don't return an EOF code if there's still buffered data. Also, don't call demux_stream_eof() in the playloop. There's probably nothing wrong with it, but it's cleaner not to use it. Also give AD_EOF its own value, so that a decoding error doesn't drain audio by causing an EOF condition.
* audio: remove unused metadata fieldwm42014-07-211-1/+0
| | | | | This was used for replaygain at some point, until replaygain info was passed through explicitly.
* audio: use symbolic constants instead of magic integerswm42014-07-201-4/+3
| | | | Similar to commit 26468743.
* ao_lavc: Fix design of audio pts handling.Rudolf Polzer2014-07-161-1/+1
| | | | | | | | | There was confusion about what should go into audio pts calculation and what not (mainly due to the audio push thread). This has been fixed by using the playing - not written - audio pts (which properly takes into account the ao's buffer), and incrementing the samples count only by the amount of samples actually taken from the buffer (unfortunately this now forces us to keep the lock too long for my taste).
* demux: make replaygain per-trackwm42014-07-051-1/+1
| | | | | | It's unlikely that files with multiple audio tracks and with replaygain actually happen, but this change might help avoid minor corner cases with later changes.
* audio: add a "weak" gapless mode, and make it defaultwm42014-06-091-1/+11
| | | | | | | | | | | | | | Basically, this allows gapless playback with similar files (including the ordered chapter case), while still being robust in general. The implementation is quite simplistic on purpose, in order to avoid all the weird corner cases that can occur when creating the filter chain. The consequence is that it might do not-gapless playback in more cases when needed, but if that bothers you, you still can use the normal gapless mode. Just using "--gapless-audio" or "--gapless-audio=yes" selects the old mode.
* audio: change handling of an EOF corner casewm42014-05-301-7/+1
| | | | | | This code handles buggy AOs (even if all AOs are bug-free, it's good for robustness). Move handling of it to the AO feed thread. Now this check doesn't require magic numbers and does exactly what's it supposed to do.
* af: add replaygain_data field to af_stream and af_instanceAlessandro Ghedini2014-04-041-0/+1
| | | | Closes #664
* command: allow changing filters before video chain initializationwm42014-03-301-2/+2
| | | | | | | Apparently this is more intuitive. Somewhat tricky, because of the odd state after loading a file but before initializing the VO.
* audio: remove sample rate limit checkswm42014-03-301-7/+1
| | | | | | | | | | | This played the file at a wrong sample rate if the rate was out of certain bounds. A comment says this was for the sake of libaf/af_resample.c. This resampler has been long removed. Our current resampler (libav/swresample) checks supported sample rates on reconfiguration, and will error out if a sample rate is not supported. And I think that is the correct behavior.
* af: add metadata field to af_stream and af_instanceAlessandro Ghedini2014-03-131-0/+1
| | | | | | This allows to propagate metadata information to audio filters. Closes #632
* audio: don't downmix when doing digital passthroughwm42014-03-101-1/+2
| | | | | | This obviously doesn't work. It wasn't much of a problem in the past because most passthrough formats use 2 channels, which is also the default for downmix.
* audio: make --channels option always force the output layoutwm42014-03-101-6/+1
| | | | | | Use the --channels value directly on the AO, instead of doing it only in the --channels=stereo (default) case and if the decoder output is not stereo.
* audio: don't write audio when pausedwm42014-03-091-0/+5
| | | | | | | | | | This is probably "safer". Without it, we will play 1 sample, because the logic was written in a way to decode 1 sample if audio is paused. 1 sample usually will initialize the audio PTS, but not play any real audio. Also see previous commit. In ancient times, this actually used 1 byte (instead of 1 sample), so clearly no sample was written, unless the audio was 8-bit mono.
* audio: remove handling of partially written datawm42014-03-091-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove the ao_buffer_playable_samples field. This contained the number of samples that fill_audio_out_buffers() wanted to write to the AO (i.e. this data was supposed to be played at some point), but ao_play() rejected it due to partial fill. This could happen with many AOs, notably those which align all written data to an internal period size (often called "outburst" in the AO code), and the accepted number of samples is rounded down to period boundaries. The left-over samples at the end were still kept in mpctx->ao_buffer, and had to be played later. The reason ao_buffer_playable_samples had to exist was to make sure that at EOF, the correct number of left-over samples was played (and not possibly other data in the buffer that had to be sliced off due to endpts in fill_audio_out_buffers()). (You'd think you could just slice the entire buffer, but I suspect this wasn't done because the end time could actually change due to A/V sync changes. Maybe that was the reason it's so complicated.) Some commits ago, ao.c gained internal buffering, and ao_play() will never return partial writes - as long as you don't try to write more samples than ao_get_space() reports. This is always the case. The only exception is filling the audio buffers while paused. In this case, we decode and play only 1 sample in order to initialize decoding (e.g. on seeking). Actually playing this 1 sample is in fact a bug, but even of the AO doesn't have period size alignment, you won't notice it. In summary, this means we can safely remove the code.
* audio/out: make ao struct opaquewm42014-03-091-42/+56
| | | | | | We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
* encode: don't access ao->ptswm42014-03-071-0/+4
| | | | | | | | | | This field will be moved out of the ao struct. The encoding code was basically using an invalid way of accessing this field. Since the AO will be moved into its own thread too and will do its own buffering, the AO and the playback core might not even agree which sample a PTS timestamp be