summaryrefslogtreecommitdiffstats
path: root/audio/decode
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* 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: use --audio-channels=auto behavior, except on ALSAwm42016-08-041-2/+2
| | | | | | | | | | | | | | | | | | | | | | | 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.
* 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.
* 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.
* 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.
* ad_spdif: take care of deprecated libavcodec API usagewm42016-04-201-0/+7
|
* 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.
* audio: make mp_audio_skip_samples() adjust the PTSwm42016-02-221-2/+0
| | | | 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-211-33/+3
|
* 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.
* audio: minor simplificationwm42016-02-051-3/+0
| | | | | These fields are already deallocated by uninit_decoder(). Also remove the wrong/useless log message.
* 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.
* audio: move pts reset checkwm42016-01-292-14/+1
| | | | Reduces the dependency of the filter/output code on the decoder.
* 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: 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.
* 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-111-1/+1
| | | | This change helps avoiding conflict with talloc.h from libtalloc.
* 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.
* dec_audio: add missing includewm42015-11-081-0/+1
| | | | Was masked by FFmpeg's terrible headers, but failed with Libav.
* audio: interpolate audio timestampswm42015-11-081-2/+12
| | | | | | | | | | | | Deal with jittering Matroska crap timestamps. This reuses the mechanism that is needed for frames without PTS, and adds a heuristic to it. If the interpolated timestamp is less than 1ms away from the real one, it might be due to Matroska timestamp rounding (or other file formats with such rounding, or files remuxed from Matroska). While there actually isn't much of a need to do this (audio PTS jittering by such a low amount doesn't negatively influence much), it helps with identifying jitter from other sources.
* audio: move PTS setting out of the decoderwm42015-11-083-18/+14
| | | | | | | Instead of requiring the decoder to set the PTS directly on the dec_audio context (including handling absence of PTS etc.), transfer the packet PTS to the decoded audio frame. Marginally simpler, and gives more control to the generic code.
* audio: make spdif re-probe from normal decoding workwm42015-10-061-1/+1
| | | | | | | | The previous commit handled not falling back to normal decoding if the AO was reloaded (I think...), and this tries to re-engage spdif pass- through if it was previously falling back to normal decoding (e.g. because it temporarily switched to an audio device incapable of passthrough).
* demux: merge extradata fieldswm42015-06-211-5/+1
| | | | | | | MPlayer traditionally had completely separate sh_ structs for audio/video/subs, without a good way to share fields. This meant that fields shared across all these headers had to be duplicated. This commit deduplicates essentially the last remaining duplicated fields.
* demux: rename sh_stream.format to sh_stream.codec_tagwm42015-06-211-1/+1
| | | | | Why not. "format" sounds too misleading for the actual importance and meaning of this field.
* audio: fix crash on uninitwm42015-06-151-1/+1
| | | | Shit.
* audio: add --audio-spdif as new method for enabling passthroughwm42015-06-052-8/+21
| | | | | | | | | | | | | This provides a new method for enabling spdif passthrough. The old method via --ad (--ad=spdif:ac3 etc.) is deprecated. The deprecated method will probably stop working at some point. This also supports PCM fallback. One caveat is that it will lose at least 1 audio packet in doing so. (I don't care enough to prevent this.) (This is named after the old S/PDIF connector, because it uses the same underlying technology as far as the higher level protoco is concerned. Also, the user should be renamed that passthrough is backwards.)
* ad_spdif: use a pseudo codec entry to select DTS-HD instead of an optionwm42015-06-051-1/+10
| | | | | | | | | This deprecates the --ad-spdif-dtshd option, and replaces it with a pseudo decoder. This means ad_spdif will report two decoders, "dts" and "dts-hd", of which the second simply enables what the option did. The --ad-spdif-dtshd option will actually be deprecated in the next commit.
* ad_spdif: use DTS-HD passthrough only if the audio is really DTS-HDwm42015-05-191-4/+54
| | | | | | | | | | | | | | | | | | | | | | | Apparently some A/V receivers do not behave well if "normal" DTS is passed through using the high bitrate spdif format normally used for DTS-HD (other receivers are fine with it). Parse the first packet passed to ad_spdif by decoding it with libavcodec in order to get the profile. Ignore the --ad-spdif-dtshd if it's not DTS-HD. (If the codec profile changes midstream, the user is out of luck. But this is probably an insignificant corner case.) I thought about parsing the bitstream, but let's not. While it probably wouldn't be that much effort, we are trying to keep it down on codec details here - otherwise we could just do our own spdif framing instead of using libavformat's spdif pseudo-muxer. Another possibility, using the codec parameters signalled by libavformat, is disregarded. Our builtin Matroska decoder doesn't do this, and also we do not want on the demuxer having to decode some packets in order to retrieve codec params (as libavformat does). Fixes #1949.
* ad_spdif: set output format lazilywm42015-05-191-15/+27
| | | | | Preparation for the following commit, which looks at the packet data before deciding what to output.
* player: change video-bitrate and audio-bitrate propertieswm42015-04-201-3/+0
| | | | | | | | | | | | | | Remove the old implementation for these properties. It was never very good, often returned very innaccurate values or just 0, and was static even if the source was variable bitrate. Replace it with the implementation of "packet-video-bitrate". Mark the "packet-..." properties as deprecated. (The effective difference is different formatting, and returning the raw value in bits instead of kilobits.) Also extend the documentation a little. It appears at least some decoders (sipr?) need the AVCodecContext.bit_rate field set, so this one is still passed through.
* Update license headersMarcin Kurczewski2015-04-135-26/+21
| | | | Signed-off-by: wm4 <wm4@nowhere>
* ad_lavc: disable AC3 DRC by defaultwm42015-03-301-2/+2
|
* audio: remove internal libmpg123 wrapperwm42015-03-242-309/+0
| | | | | | | We've been prefering the libavcodec mp3 decoder for half a year now. There is likely no benefit at all for using the libmpg123 one. It's just a maintenance burden, and tricks users into thinking it's a required dependency.
* player: better handling of video with no timestampswm42015-03-201-0/+3
| | | | | | | | | | | Trying to handle such video is almost worthless, but it was requested by at least 2 users. If there are no timestamps, enable byte seeking by setting ts_resets_possible. Use the video FPS (wherever it comes from) and the audio samplerate for timing. The latter was already done by making the first packet emit DTS=0; remove this again and do it "properly" in a higher level.
* audio: fix spdif packet size unitwm42015-03-101-2/+0
| | | | | | | | | | | In commit 5f8b060e I blindly assumed that the packet sizes were in pseudo-samples, but they were actually in bytes. Oops. (The effect was that cutting the audio was a bit less precise than it can be.) Also remove the packet size from ad_spdif.c; it didn't actually use it, and simply takes what the spdif "muxer" returns.
* ad_spdif: move frame sizes to a general functionwm42015-03-101-7/+1
| | | | | | Needed for the next commit. This commit should probably be reverted as soon as we're working with full audio frames internally, instead of "flat" FIFOs.
* ad_spdif: remove per-packet messagewm42015-03-041-1/+0
| | | | It was annoying and didn't ever help with anything.
* audio: fix initial audio PTSwm42015-01-141-24/+25
| | | | | | | | | | Commit 5e25a3d2 broke handling of the initial frame (the one decoded with initial_audio_decode()). It didn't update the pts_offset field, leading to a shift in timestamps by one audio frame. Fix by calling the actual decode function in a single place. This requires slightly more changes than what would be necessary to fix the bug, but it also somewhat simplifies the data flow.
* audio: fix assertion failure on audio decodingwm42015-01-141-2/+2
| | | | | | | There are several cases in which a decoder may need several packets to produce some output audio. Commit 5e25a3d2 broke this. Fixes #1471.
* audio: use refcounted frames in the filter chainwm42015-01-131-24/+37
| | | | | | | | | | | | | | | | | | | The goal is switching the whole audio chain to using refcounted frames. This brings the architecture closer to FFmpeg, enables better integration with libavfilter, will reduce useless copying somewhat, and will probably allow better timestamp tracking. For now, every filter goes through a semi-awful wrapper in af_do_filter(), though. This will be fixed step by step, and the wrapper should eventually be removed. Another thing that will have to be done is improving the timestamp handling and avoiding extra copies for the AO. Some of the new code is rather similar to the video filter code (the core filter code basically just has types replaced). Such code duplication is normally very unwanted, but in this case there's probably no other choice. On the other hand, this code is pretty simple (even if somewhat tricky). Maybe there will be unified filter code in the future, but this is still far away.
* player: print used number of threads in verbose modewm42015-01-051-1/+1
| | | | Also, don't use av_log() for mpv output.
* audio: make decoders output refcounted frameswm42014-11-106-194/+107
| | | | | | | | | | | | | | This rewrites the audio decode loop to some degree. Audio filters don't do refcounted frames yet, so af.c contains a hacky "emulation". Remove some of the weird heuristic-heavy code in dec_audio.c. Instead of estimating how much audio we need to filter, we always filter full frames. Maybe this should be adjusted later: in case filtering increases the volume of the audio data, we should try not to buffer too much filter output by reducing the input that is fed at once. For ad_spdif.c and ad_mpg123.c, we don'