summaryrefslogtreecommitdiffstats
path: root/audio/decode
Commit message (Collapse)AuthorAgeFilesLines
* player: hide audio/video codec and file format messageswm42014-05-311-2/+1
| | | | | None of these are very important usually. For error analysis, the plain log is useless anyway, and this information is still printed with "-v".
* ad_lavc: don't overwrite lavc bitrateMarcoen Hirschberg2014-05-281-2/+3
| | | | | If the bitrate is already known in avcodec there is no need to overwrite it again with the value from sh_audio.
* af_fmt2bits: change to af_fmt2bps (bytes/sample) where appropriateMarcoen Hirschberg2014-05-281-1/+1
| | | | | | In most places where af_fmt2bits is called to get the bits/sample, the result is immediately converted to bytes/sample. Avoid this by getting bytes/sample directly by introducing af_fmt2bps.
* audio: rename i_bps to 'bitrate' to avoid confusionMarcoen Hirschberg2014-05-283-6/+6
| | | | Since i_bps now contains bits/sec, rename it to reflect this change.
* audio: change values from bytes-per-second to bits-per-secondMarcoen Hirschberg2014-05-282-8/+10
| | | | | | | The i_bps members of the sh_audio and dev_video structs are mostly used for displaying the average audio and video bitrates. Keeping them in bits-per-second avoids truncating them to bytes-per-second and changing them back lateron.
* options: remove deprecated --identifyMartin Herkt2014-05-041-3/+0
| | | | | | | Also remove MSGL_SMODE and friends. Note: The indent in options.rst was added to work around a bug in ReportLab that causes the PDF manual build to fail.
* player: add a --dump-stats optionwm42014-04-171-5/+6
| | | | | | | | | | | | | | | | | | | | | | | This collects statistics and other things. The option dumps raw data into a file. A script to visualize this data is included too. Litter some of the player code with calls that generate these statistics. In general, this will be helpful to debug timing dependent issues, such as A/V sync problems. Normally, one could argue that this is the task of a real profiler, but then we'd have a hard time to include extra information like audio/video PTS differences. We could also just hardcode all statistics collection and processing in the player code, but then we'd end up with something like mplayer's status line, which was cluttered and required a centralized approach (i.e. getting the data to the status line; so it was all in mplayer.c). Some players can visualize such statistics on OSD, but that sounds even more complicated. So the approach added with this commit sounds sensible. The stats-conv.py script is rather primitive at the moment and its output is semi-ugly. It uses matplotlib, so it could probably be extended to do a lot, so it's not a dead-end.
* af: add replaygain_data field to af_stream and af_instanceAlessandro Ghedini2014-04-042-0/+3
| | | | Closes #664
* ad_lavc: use new AVFrame APIwm42014-03-161-2/+4
| | | | | | | Set refcounted_frames, because in some versions of libavcodec mixing the new AVFrame API and non-refcounted decoding could cause memory corruption. Likewise, it's probably still required to unref a frame before calling the decoder.
* ad_lavc: remove deprecated downmixing by channel countwm42014-03-161-4/+0
| | | | | Downmixing by channel layout now hopefully works with all supported libavcodec versions.
* af: add metadata field to af_stream and af_instanceAlessandro Ghedini2014-03-132-0/+4
| | | | | | This allows to propagate metadata information to audio filters. Closes #632
* Factor out setting AVCodecContext extradatawm42014-01-111-10/+4
|
* codecs: mp_msg conversionwm42013-12-211-1/+1
|
* audio/fmt-conversion.c: remove unknown audio format messageswm42013-12-211-1/+4
| | | | Same deal as with video/fmt-conversion.c.
* audio: mp_msg conversionswm42013-12-215-49/+42
|
* ad_lavc: work around deprecation warningwm42013-12-181-1/+4
| | | | | | | | | | request_channels has been deprecated for years (request_channel_layout is the replacement), but it appears it's still needed despite the deprecation at least on older libavcodec versions. So still set request_channels, but to it with the avoption API, which hides the deprecation warning. This should also prevent mpv getting trashed when libavcodec happens to bump its major version.
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-175-11/+11
|
* Move options/config related files from mpvcore/ to options/wm42013-12-172-2/+2
| | | | | | | | | Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
* Replace mp_tmsg, mp_dbg -> mp_msg, remove mp_gtext(), remove set_osd_tmsgwm42013-12-162-10/+10
| | | | | | | | | The tmsg stuff was for the internal gettext() based translation system, which nobody ever attempted to use and thus was removed. mp_gtext() and set_osd_tmsg() were also for this. mp_dbg was once enabled in debug mode only, but since we have log level for enabling debug messages, it seems utterly useless.
* audio: flush remaining data from the filter chain on EOFwm42013-12-051-1/+5
| | | | | | | | | | | | | | | | | This can be reproduced with: mpv short.wav -af 'lavfi="aecho=0.8:0.9:5000|6800:0.3|0.25"' An audio file that is just 1-2 seconds long should play for 8-9 seconds, which audible echo towards the end. The code assumes that when playing with AF_FILTER_FLAG_EOF, the filter will either produce output, or has all remaining data flushed. I'm not really sure whether this really works if there are multiple filters with EOF handling in the chain. To handle it correctly, af_lavfi should retry filtering if 1. EOF flag is set, 2. there were input samples, and 3. no output samples were produced. But currently it seems to work well enough anyway.
* audio/filter: change filter callback signaturewm42013-12-051-9/+8
| | | | | | | | | The new signature is actually closer to how it actually works, and someone who is not familiar to the API and how it works might make fewer fatal mistakes with the new signature than the old one. Pretty weird. Do this to sneak in a flags parameter, which will later be used to flush remaining data of at least vf_lavfi.
* ad_lavc: handle decoder EAGAIN only if there was an input packetwm42013-12-041-3/+3
| | | | | Otherwise, it'd probably get stuck if the decoder still returns EAGAIN at EOF on e.g. a shortened data stream.
* ad_lavc: expose an option to enable threadingwm42013-12-041-0/+3
|
* ad_lavc: deal with arbitrary decoder delaywm42013-12-041-16/+24
| | | | | | | | | | | | | | | | | | | | Normally, audio decoder don't have a decoder delay, so the code was fine. But FFmpeg supports multithreaded decoding for some audio codecs, which introduces such a delay. The delay means that we won't get decoded audio for the first few packets, and that we need to do something to get the trailing audio still buffered in the decoder when reaching EOF. Two changes are needed to deal with the delay: - If EOF is reached, pass a "flush" packet to the decoder to return the buffered audio. Such a flush packet is automatically setup when calling mp_set_av_packet() with a NULL packet. - Use the PTS returned by the decoder, instead of the packet's. This is important to get correct timestamps for decoded audio. Ignoring this would result into offsetting the audio playback time by the decoder delay. Note that we can still use the timestamp of the first packet to get the timestamp for the start of the audio.
* av_common: add timebase parameter to mp_set_av_packet()wm42013-12-042-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | If the timebase is set, it's used for converting the packet timestamps. Otherwise, the previous method of reinterpret-casting the mpv style double timestamps to libavcodec style int64_t timestamps is used. Also replace the kind of awkward mp_get_av_frame_pkt_ts() function by mp_pts_from_av(), which simply converts timestamps in a way the old function did. (Plus it takes a timebase parameter, similar to the addition to mp_set_av_packet().) Note that this should not change anything yet. The code in ad_lavc.c and vd_lavc.c passes NULL for the timebase parameters. We could set AVCodecContext.pkt_timebase and use that if we want to give libavcodec "proper" timestamps. This could be important for ad_lavc.c: some codecs (opus, probably mp3 and aac too) have weird requirements about doing decoding preroll on the container level, and thus require adjusting the audio start timestamps in some cases. libavcodec doesn't tell us how much was skipped, so we either get shifted timestamps (by the length of the skipped data), or we give it proper timestamps. (Note: libavcodec interprets or changes timestamps only if pkt_timebase is set, which by default it is not.) This would require selecting a timebase though, so I feel uncomfortable with the idea. At least this change paves the way, and will allow some testing.
* Move some code from player to audio/video reset functionswm42013-11-271-2/+6
|
* cosmetics: rename video/audio reset functionswm42013-11-275-7/+7
| | | | | | | | | | These used the suffix _resync_stream, which is a bit misleading. Nothing gets "resynchronized", they really just reset state. (Some audio decoders actually used to "resync" by reading packets for resuming playback, but that's not the case anymore.) Also move the function in dec_video.c to the top of the file.
* audio: better rejection of invalid formatswm42013-11-272-20/+21
| | | | | | | | | This includes the case when lavc decodes audio with more than 8 channels, which our audio chain currently does not support. the changes in ad_lavc.c are just simplifications. The code tried to avoid overriding global parameters if it found something invalid, but that is not needed anymore.
* ad_lavc: increase number of packets for initial decodewm42013-11-261-2/+5
| | | | | | | | | | | Apparently just 5 packets is not enough for the initial audio decode (which is needed to find the format). The old code (before the recent refactor) appeared to use 5 packets, but there were apparently other code paths which in the end amounted to more than 5 packets being read. The sample that failed (see github issue #368) needed 9 packets. Fixes #368.
* demux: remove gsh field from sh_audio/sh_video/sh_subwm42013-11-231-6/+7
| | | | | | | | | This used to be needed to access the generic stream header from the specific headers, which in turn was needed because the decoders had access only to the specific headers. This is not the case anymore, so this can finally be removed again. Also move the "format" field from the specific headers to sh_stream.
* audio: remove ad_driver.preinitwm42013-11-236-34/+13
| | | | | This never had any real use. Get rid of dec_audio.initialized too, as it's redundant.
* audio: don't write decoded audio format to sh_audiowm42013-11-235-47/+42
| | | | | | | | sh_audio is supposed to contain file headers, not whatever was decoded. Fix this, and write the decoded format to separate fields in the decoder context, the dec_audio.decoded field. (Note that this field is really only needed to communicate the audio format from decoder driver to the generic code, so no other code accesses it.)
* audio: move decoder context from sh_audio into new structwm42013-11-236-191/+219
| | | | | | | | | Move all state that basically changes during decoding or is needed in order to manage decoding itself into a new struct (dec_audio). sh_audio (defined in stheader.h) is supposed to be the audio stream header. This should reflect the file headers for the stream. Putting the decoder context there is strange design, to say the least.
* audio: use the decoder buffer's format, not sh_audiowm42013-11-181-2/+2
| | | | | | | | | | | | | | | | | | When the decoder detects a format change, it overwrites the values stored in sh_audio (this affects the members sample_format, samplerate, channels). In the case when the old audio data still needs to be played/filtered, the audio format as identified by sh_audio and the format used for the decoder buffer can mismatch. In particular, they will mismatch in the very unlikely but possible case the audio chain is reinitialized while old data is draining during a format change. Or in other words, sh_audio might contain the new format, while the audio chain is still configured to use the old format. Currently, the audio code (player/audio.c and init_audio_filters) access sh_audio to get the current format. This is in theory incorrect for the reasons mentioned above. Use the decoder buffer's format instead, which should be correct at any point.
* audio: fix mid-stream audio reconfigurationwm42013-11-182-1/+10
| | | | | | | | | | | | | | | | | | | | | Commit 22b3f522 not only redid major aspects of audio decoding, but also attempted to fix audio format change handling. Before that commit, data that was already decoded but not yet filtered was thrown away on a format change. After that commit, data was supposed to finish playing before rebuilding filters and so on. It was still buggy, though: the decoder buffer was initialized to the new format too early, triggering an assertion failure. Move the reinit call below filtering to fix this. ad_mpg123.c needs to be adjusted so that it doesn't decode new data before the format change is actually executed. Add some more assertions to af_play() (audio filtering) to make sure input data and configured format don't mismatch. This will also catch filters which don't set the format on their output data correctly. Regression due to planar_audio branch.
* audio: drop "_NE"/"ne" suffix from audio formatswm42013-11-151-3/+3
| | | | | | You get the native format by not appending any suffix to the format. This change includes user-facing names, e.g. for the --format option.
* dec_audio: adjust "large" decoding amountwm42013-11-151-5/+5
| | | | | | | | | | This used to be in bytes, now it's in samples. Divide the value by 8 (assuming a typical audio format, float samples with 2 channels). Fix some editing mistake or non-sense about the extra buffering added (1<<x instead of x<<5). Also sneak in a s/MPlayer/mpv/.
* ad_spdif: fix regressionswm42013-11-142-9/+9
| | | | | | | | | | Apparently this was completely broken after commit 22b3f522. Basically, this locked up immediately completely while decoding the first packet. The reason was that the buffer calculations confused bytes and number of samples. Also, EOF reporting was broken (wrong return code). The special-casing of ad_mpg123 and ad_spdif (with DECODE_MAX_UNIT) is a bit annoying, but will eventually be solved in a better way.
* Merge branch 'planar_audio'wm42013-11-126-526/+331
|\ | | | | | | | | Conflicts: audio/out/ao_lavc.c
| * audio: add support for using non-interleaved audio from decoders directlywm42013-11-125-446/+316
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most libavcodec decoders output non-interleaved audio. Add direct support for this, and remove the hack that repacked non-interleaved audio back to packed audio. Remove the minlen argument from the decoder callback. Instead of forcing every decoder to have its own decode loop to fill the buffer until minlen is reached, leave this to the caller. So if a decoder doesn't return enough data, it's simply called again. (In future, I even want to change it so that decoders don't read packets directly, but instead the caller has to pass packets to the decoders. This fits well with this change, because now the decoder callback typically decodes at most one packet.) ad_mpg123.c receives some heavy refactoring. The main problem is that it wanted to handle format changes when there was no data in the decode output buffer yet. This sounds reasonable, but actually it would write data into a buffer prepared for old data, since the caller doesn't know about the format change yet. (I.e. the best place for a format change would be _after_ writing the last sample to the output buffer.) It's possible that this code was not perfectly sane before this commit, and perhaps lost one frame of data after a format change, but I didn't confirm this. Trying to fix this, I ended up rewriting the decoding and also the probing.
| * ad_mpg123: reduce ifdefferywm42013-11-121-47/+2
| | | | | | | | Drop support for anything before 1.14.0.
| * dec_audio: fix behavior on format changeswm42013-11-121-3/+1
| | | | | | | | | | Decoder overwrites parameters in sh_audio, but we still have old audio in the old format to filter.
| * audio/filter: fix mul/delay scale and valueswm42013-11-121-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Before this commit, the af_instance->mul/delay values were in bytes. Using bytes is confusing for non-interleaved audio, so switch mul to samples, and delay to seconds. For delay, seconds are more intuitive than bytes or samples, because it's used for the latency calculation. We also might want to replace the delay mechanism with real PTS tracking inside the filter chain some time in the future, and PTS will also require time-adjustments to be done in seconds. For most filters, we just remove the redundant mul=1 initialization. (Setting this used to be required, but not anymore.)
| * audio: switch output to mp_audio_bufferwm42013-11-122-39/+22
| | | | | | | | | | | | Replace the code that used a single buffer with mp_audio_buffer. This also enables non-interleaved output operation, although it's still disabled, and no AO supports it yet.
| * audio/filter: prepare filter chain for non-interleaved audiowm42013-11-121-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on earlier work by Stefano Pigozzi. There are 2 changes: 1. Instead of mp_audio.audio, mp_audio.planes[0] must be used. 2. mp_audio.len used to contain the size of the audio in bytes. Now mp_audio.samples must be used. (Where 1 sample is the smallest unit of audio that covers all channels.) Also, some filters need changes to reject non-interleaved formats properly. Nothing uses the non-interleaved features yet, but this is needed so that things don't just break when doing so.
* | demux_mkv: support some raw PCM variantswm42013-11-111-23/+11
|/ | | | | | | | | | This affects 64 bit floats and big endian integer PCM variants (basically crap nobody uses). Possibly not all MS-muxed files work, but I couldn't get or produce any samples. Remove a bunch of format tags that are not needed anymore. Most of these were used by demux_mov, which is long gone. Repurpose/abuse 'twos' as mpv-internal tag for dealing with the PCM variants mentioned above.
* ad_spdif: change API usage so that it works on Libavwm42013-11-101-3/+9
| | | | | | | | | | | Apparently we were using FFmpeg-specific APIs. I have no idea whether this code is correct on both FFmpeg and Libav (no examples, bad doxygen... why do they even complaint aht people are using their APIs incorrectly?), but it appears to work on FFmpeg. That was also the case before commit ebc4ccb though, where it used internal libavformat symbols. Untested on Libav, Travis will tell us.
* Remove sh_audio->samplesizewm42013-11-093-8/+3
| | | | | | | | | This member was redundant. sh_audio->sample_format indicates the sample size already. The TV code is a bit strange: the redundant sample size was part of the internal TV interface. Assume it's really redundant and not something else. The PCM decoder ignores the sample size anyway.
* ad_spdif: fix libavformat API usagewm42013-11-091-107/+76
| | | | | | | This accessed tons of private libavformat symbols all over the place. Don't do this and convert all code to proper public APIs. As a consequence, the code becomes shorter and cleaner (many things the code tried are done by libavformat APIs).
* audio: replace af_fmt2str_short -> af_fmt_to_strwm42013-11-071-1/+1
| | | | Also, remove all af_fmt2str usages.
* configure: uniform the defines to #define HAVE_xxx (0|1)Stefano Pigozzi2013-11-031-1/+1
| | | | | | | | | | | | | | | | | | | | | The configure followed 5 different convetions of defines because the next guy always wanted to introduce a new better way to uniform it[1]. For an hypothetic feature 'hurr' you could have had: * #define HAVE_HURR 1 / #undef HAVE_DURR * #define HAVE_HURR / #undef HAVE_DURR * #define CONFIG_HURR 1 / #undef CONFIG_DURR * #define HAVE_HURR 1 / #define HAVE_DURR 0 * #define CONFIG_HURR 1 / #define CONFIG_DURR 0 All is now uniform and uses: * #define HAVE_HURR 1 * #define HAVE_DURR 0 We like definining to 0 as opposed to `undef` bcause it can help spot typos and is very helpful when doing big reorganizations in the code. [1]: http://xkcd.com/927/ related
* demux: rename Windows symbolswm42013-11-021-1/+1
| | | | | | | | | | | | | | | | | | | | There are some Microsoft Windows symbols which are traditionally used by the mplayer core, because it used to be convenient (avi was the big format, using binary windows decoders made sense...). So these symbols have the exact same definition as the Windows one, and if mplayer is compiled on Windows, the symbols from windows.h are used. This broke recently just because some files were shuffled around, and the symbols defined in ms_hdr.h collided with windows.h ones. Since we don't have windows binary decoders anymore, there's not the slightest reason our symbols should have the same names. Rename them to reduce the risk for collision, and to fix the recent regression. Drop WAVEFORMATEXTENSIBLE, because it's mostly unused. ao_dsound defines its own version if the windows headers don't define it, and ao_wasapi is not available on systems where this symbol is missing. Also reindent ms_hdr.h.
*