summaryrefslogtreecommitdiffstats
path: root/common
Commit message (Collapse)AuthorAgeFilesLines
* msg: make --msg-time show time in secondswm42020-09-181-1/+1
| | | | | More readable, similar to what --log-file will use (although the terminal code shows microseconds and uses less left padding).
* encode: disable unsupported media types automaticallywm42020-09-032-18/+47
| | | | | | | If you encode to e.g. an audio-only format, then video is disabled automatically. This also takes care of the very cryptic error message. It says "[vo/lavc] codec for video not found". Sort of true, but obscures the real problem if it's e.g. an audio-only format.
* encode: remove early EOF failure handlingwm42020-09-032-27/+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.
* encode: undeprecatewm42020-08-291-2/+1
| | | | I guess the audio timestamp corruption problem is probably solved now.
* audio: refactor how data is passed to AOwm42020-08-293-20/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* build: change filenames of generated fileswm42020-06-041-1/+1
| | | | Force them into a more consistent naming schema.
* player: add --term-title optionwm42020-05-252-0/+11
| | | | | | | | | | | | | | This simply printf()s a concatenation of the provided string and the relevant escape sequences. No idea what exactly defines this escape sequence (is it just a xterm thing that is now supported relatively widely?), and this simply uses information provided on the linked github issue. Not much of an advantage over --term-status-msg, though at least this can have a lower update frequency. Also I may consider setting a default value, and then it shouldn't conflict with the status message. Fixes: #1725
* common: add helper for subtracting rectangleswm42020-05-222-0/+24
| | | | Not sure if generally useful; the following commit uses it.
* msg: add function to reduce log levelwm42020-05-102-2/+19
| | | | | | | | | | Sometimes it's helpful to override this for specific mp_log instances, because in some specific circumstances you just want to suppress log file noise you never want to see. -1 is an allowed value (for suppressing MSGL_FATAL==0). It looks like the libplacebo wrapper still does this wrong, so it will probably trigger UB in some cases. I guess I don't care, though.
* common: fix mp_round_next_power_of_2()wm42020-04-101-5/+6
| | | | | | | Who write this dumb shit¹? It didn't handle 1<<31, and was unnecessarily slow. ¹ it was me
* player, stats: more silly debug stuffwm42020-04-102-0/+19
| | | | | In addition to stats.c being gross, I don't think master branch code should be littered with debug code. But it's a helpful abomination.
* stats: some more performance graphswm42020-04-093-0/+356
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add an infrastructure for collecting performance-related data, use it in some places. Add rendering of them to stats.lua. There were two main goals: minimal impact on the normal code and normal playback. So all these stats_* function calls either happen only during initialization, or return immediately if no stats collection is going on. That's why it does this lazily adding of stats entries etc. (a first iteration made each stats entry an API thing, instead of just a single stats_ctx, but I thought that was getting too intrusive in the "normal" code, even if everything gets worse inside of stats.c). You could get most of this information from various profilers (including the extremely primitive --dump-stats thing in mpv), but this makes it easier to see the most important information at once (at least in theory), partially because we know best about the context of various things. Not very happy with this. It's all pretty primitive and dumb. At this point I just wanted to get over with it, without necessarily having to revisit it later, but with having my stupid statistics. Somehow the code feels terrible. There are a lot of meh decisions in there that could be better or worse (but mostly could be better), and it just sucks but it's also trivial and uninteresting and does the job. I guess I hate programming. It's so tedious and the result is always shit. Anyway, enjoy.
* client API: report IDs of inserted playlist entries on loading playlistwm42020-03-272-8/+14
| | | | | | May or may not help when dealing with playlist loading in scripts. It's supposed to help with the mean fact that loading a recursive playlist will essentially edit the playlist behind the API user's back.
* encode: fix occasional init crash due to initialization order issueswm42020-03-221-8/+7
| | | | | | | | Looks like the recent change to this actually made it crash whenever audio happened to be initialized first, due to not setting the mux_stream field before the on_ready callback. Mess a way around this. Also remove a stray unused variable from ao_lavc.c.
* encode: deprecate encoding modewm42020-03-221-1/+2
| | | | | While I'd like to keep it, I'm apparently the maintainer now, and I have no idea what the heck some of this code does, so it's deprecated.
* encode: restore audio muxer timebase usewm42020-03-222-0/+9
| | | | | | Seems to crash hard if an error happens somewhere at init. Who cares. Part of #7524.
* encode: fix whitespacewm42020-03-221-1/+1
|
* client API: add a playlist entry unique IDwm42020-03-212-0/+6
| | | | | | This should make dealing with some async. things easier. It's intentionally not a globally unique ID.
* player: add a number of new playlist contol commands/propertieswm42020-03-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | Should give a good deal more explicit control and insight over the player state. Some feel a bit pointless, and/or expose internal weirdness. However, it's not like the existing weirdness didn't exist before, or can be made go away. (In part, the weirdness is because certain in-between states are visible. Hiding them would make things simpler, but less flexible.) Maybe this actually gives users a better idea how the API _should_ look like, too. On a side note, this tries to really guarantee that mpctx->playing is set between playback start/end. For that, the loadfile.c changes assume that mpctx->playing is set (guaranteed by code above the change), and that playing->filename is set (probably could never be false; was broken before and actually would have crashed if that could ever happen; in any case, also add an assert to playlist.c for this). playlist_entry_to_index() now tolerates playlist_entrys that are not part of the playlist. This is also needed for mpctx->playing.
* options: change option macros and all option declarationswm42020-03-181-26/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change all OPT_* macros such that they don't define the entire m_option initializer, and instead expand only to a part of it, which sets certain fields. This requires changing almost every option declaration, because they all use these macros. A declaration now always starts with {"name", ... followed by designated initializers only (possibly wrapped in macros). The OPT_* macros now initialize the .offset and .type fields only, sometimes also .priv and others. I think this change makes the option macros less tricky. The old code had to stuff everything into macro arguments (and attempted to allow setting arbitrary fields by letting the user pass designated initializers in the vararg parts). Some of this was made messy due to C99 and C11 not allowing 0-sized varargs with ',' removal. It's also possible that this change is pointless, other than cosmetic preferences. Not too happy about some things. For example, the OPT_CHOICE() indentation I applied looks a bit ugly. Much of this change was done with regex search&replace, but some places required manual editing. In particular, code in "obscure" areas (which I didn't include in compilation) might be broken now. In wayland_common.c the author of some option declarations confused the flags parameter with the default value (though the default value was also properly set below). I fixed this with this change.
* player: rearrange libav* library checkwm42020-03-082-9/+10
| | | | No need to be nice. Also hopefully breaks idiotic distro patches.
* Remove remains of Libav compatibilitywm42020-02-162-21/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Libav seems rather dead: no release for 2 years, no new git commits in master for almost a year (with one exception ~6 months ago). From what I can tell, some developers resigned themselves to the horrifying idea to post patches to ffmpeg-devel instead, while the rest of the developers went on to greener pastures. Libav was a better project than FFmpeg. Unfortunately, FFmpeg won, because it managed to keep the name and website. Libav was pushed more and more into obscurity: while there was initially a big push for Libav, FFmpeg just remained "in place" and visible for most people. FFmpeg was slowly draining all manpower and energy from Libav. A big part of this was that FFmpeg stole code from Libav (regular merges of the entire Libav git tree), making it some sort of Frankenstein mirror of Libav, think decaying zombie with additional legs ("features") nailed to it. "Stealing" surely is the wrong word; I'm just aping the language that some of the FFmpeg members used to use. All that is in the past now, I'm probably the only person left who is annoyed by this, and with this commit I'm putting this decade long problem finally to an end. I just thought I'd express my annoyance about this fucking shitshow one last time. The most intrusive change in this commit is the resample filter, which originally used libavresample. Since the FFmpeg developer refused to enable libavresample by default for drama reasons, and the API was slightly different, so the filter used some big preprocessor mess to make it compatible to libswresample. All that falls away now. The simplification to the build system is also significant.
* msg: slightly improve --msg-time outputwm42020-02-141-1/+1
| | | | Cut the arbitrary offset, and document what unit/timesource it uses.
* msg: move central msg lock to mp_log_rootwm42020-01-301-34/+36
| | | | | | | | | | | | This is a central lock (that is to stay and has no reason to go away), and it was simply made global. This reduces complexity when the original MPlayer code was changed from single thread + global state to a context handle. Having the global lock was still a bit silly if there were multiple mpv instances in the process, because it would make the instances wait for each other for no reason. So move it to the per-instance context, which is trivial enough.
* msg: fix some locking issueswm42020-01-301-7/+8
| | | | | | | | | | | | | | | | | | | | | | The wakeup_log_file callback was still assuming that mp_msg_lock was used to control the log file thread, but this changed while I was writing this code, and forgot to update it. (It doesn't change any state, which is untypical for condition variable usage. The state that is changed is protected by another lock instead. But log_file_lock still needs to be acquired to ensure the signal isn't sent while the thread is right before the pthread_cond_wait() call, when the lock is held, but the signal would still be lost.) Because the buffer's wakeup callback now acquires the lock, the wakeup callback must be called outside of the buffer lock, to keep the lock order (log_file_lock > mp_log_buffer.lock). Fortunately, the wakeup callback is immutable, or we would have needed another dumb leaf lock. mp_msg_has_log_file() made a similar outdated assumption. But now access to the log_file field is much trickier; just define that it's only to be called from the thread that manages the msg state. (The calling code could also just check whether the log-file option changed instead, but currently that would be slightly more messy.)
* msg: make --log-file buffered through a threadwm42020-01-292-53/+170
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now --log-file performed a blocking write to the log file, which made any calling thread block for I/O. It even explicitly flushed after every line (to make it tail-able, or to ensure a hard crash wouldn't lose any of the output). This wasn't so good, because it could cause real playback problems, which made it infeasible to enable it by default. Try to buffer it through a ring buffer and a thread. There's no other choice but to use a thread, since async I/O on files is generally a big and unportable pain. (We very much prefer portable pain.) Fortunately, there's already a ring buffer (mp_log_buffer, normally for the client API logging hook). This still involves some pretty messy locking. Give each mp_log_buffer its own lock to make this easier. This still makes calling threads block if the log buffer is full (unlike with client API log buffers, which just drop messages). I don't want log messages to get lost for this purpose. This also made locking pretty complicated (without it, mp_log_buffer wouldn't have needed its own lock). Maybe I'll remove this blocking again when it turns out to be nonsense. (We could avoid wasting an entire thread by "reusing" some other thread. E.g. pick some otherwise not real time thread, and make it react to the log buffer's wakeup callback. But let's not. It's complicated to abuse random threads for this. It'd also raise locking complexity, because we still want it to block on a full buffer.)
* command: add a playlist-unshuffle commandwm42019-12-282-0/+26
| | | | | | Has a number of restrictions. See: #2491, #7294
* playlist: change from linked list to an arraywm42019-12-282-122/+131
| | | | | | | | | | | | | | | | | | | Although a linked list was ideal at first, there are cases where it sucks, and became increasingly awkward (with the mpv command API preferring integer indexes to access the list). In future, we probably want to add more playlist-related functionality, so better change it to an array now. An array isn't always ideal either. Since playlist entries are still separate objects (because in some cases you need a stable "iterator" to it), but you still need to efficiently get the next/previous playlist entry, there's a pl_index field, that needs to be maintained. E.g. adding an entry at the start of the playlist => update the pl_index field for all other entries. Well, it's not really worth to do something more complicated to avoid these things. This commit is probably buggy as shit. It's not like I bothered to test everything. That's _your_ role.
* stream, demux: redo origin policy thingwm42019-12-203-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mpv has a very weak and very annoying policy that determines whether a playlist should be used or not. For example, if you play a remote playlist, you usually don't want it to be able to read local filesystem entries. (Although for a media player the impact is small I guess.) It's weak and annoying as in that it does not prevent certain cases which could be interpreted as bad in some cases, such as allowing playlists on the local filesystem to reference remote URLs. It probably barely makes sense, but we just want to exclude some other "definitely not a good idea" things, all while playlists generally just work, so whatever. The policy is: - from the command line anything is played - local playlists can reference anything except "unsafe" streams ("unsafe" means special stream inputs like libavfilter graphs) - remote playlists can reference only remote URLs - things like "memory://" and archives are "transparent" to this This commit does... something. It replaces the weird stream flags with a slightly clearer "origin" value, which is now consequently passed down and used everywhere. It fixes some deviations from the described policy. I wanted to force archives to reference only content within them, but this would probably have been more complicated (or required different abstractions), and I'm too lazy to figure it out, so archives are now "transparent" (playlists within archives behave the same outside). There may be a lot of bugs in this. This is unfortunately a very noisy commit because: - every stream open call now needs to pass the origin - so does every demuxer open call (=> params param. gets mandatory) - most stream were changed to provide the "origin" value - the origin value needed to be passed along in a lot of places - I was too lazy to split the commit Fixes: #7274
* msg: fix "terminal-default" logging modewm42019-12-161-2/+5
| | | | | | | | | | | | | | | | | | | | | | | console.lua uses "terminal-default" logging, which is supposed to return all messages logged to the terminal to the API. Internally, this is translated to MP_LOG_BUFFER_MSGL_TERM, which is MSGL_MAX+1, because it's not an actual log level (blame C for not having proper sum types or something). Unfortunately, this unintentionally raised the internal log level to MSGL_MAX+1. It still functioned as intended, because log messages were simply filtered at a "later" point. But it led to every message being formatted even if not needed. More importantly, it made mp_msg_test() pointless (code calls this to avoid logging in "expensive" cases and if the messages would just get discarded). Also, this broke libplacebo logging, because the code to map the log messages did not expect a level higher than MSGL_MAX (mp_msg_level() returned MSGL_MAX+1 too). Fix this by not letting the dummy level value be used as log level. Messages at terminal log level will always make it to the inner log message dispatcher function (i.e. mp_msg_va() will call write_msg_to_buffers()), so log buffers which use the dummy log level don't need to adjust the actual log level at all.
* msg: show how many messages were droppedwm42019-11-221-1/+3
| | | | Although repl.lua will probably not use this.
* msg: drop old instead of new messages on overflowwm42019-11-221-43/+57
| | | | | | | | | | | | It did that because there was no other way. It used a lock-free ring buffer, which does not support this. Use a "manual" ring buffer with explicit locks instead, and drop messages from the start. (We could have continued to use mp_ring, but it was already too late, and although mp_ring is fine, using it for types other than bytes looked awkward, and writing a ring buffer yet again seemed nicer. At least it's not C++, where mp_ring would have been a template, and everything would have looked like shit soup no matter what.)
* msg: fix missing wakeup callback in terminal-default log levelwm42019-11-221-0/+2
| | | | | | | | | In the referenced commit, I forgot about this part, and a client which tried to use this was actually not woken up when needed. (Also why the hell does the subject line of that commit say "removed"?) Fixes: 8c2d73f11205
* player: remove mechanisms for better logging with repl.luawm42019-11-182-1/+61
| | | | | | | | | | | | | | | | | | | | | | As preparation for making repl.lua part of the core (maybe), add some mechanisms which are supposed to improve its behavior. Add a silent mode. Calling mpv_request_log_messages() with the log level name prefixed with "silent:" will disable logging from the API user's perspective. But it will keep the log buffer, and record new messages, without returning them to the user. If logging is enabled again by requesting the same log level without "silent:" prefix, the buffered log messages are returned to the user at once. This is not documented, because it's far too messy and special as that I'd want anyone to rely on this behavior, but it will be perfectly fine for an internal script. Another thing is that we record early startup messages. The goal is to make the repl.lua script show option and config parsing file errors. This works only with the special "terminal-default" log level. In addition, reduce the "terminal-default" capacity to only 100 log messages. If this is going to be enabled by default, it shouldn't use too much resources.
* options: remove M_OPT_FIXEDwm42019-11-101-15/+15
| | | | | | | | | | | | | | | | | | | | | | | Options marked with this flag were changed to strictly read-only after initialization (mpv_initialize() in the client API, after option parsing and config file loading with the CLI player). This used to be necessary, because there was a single option struct that could be accessed by multiple threads. For example, --config-dir sets MPOpts.force_configdir, which was read whenever anything accessed the mpv config dir (which could be on different threads, e.g. font initialization tries to lookup fonts.conf from an arbitrary thread). This isn't needed anymore, because threads now access these in a thread safe way. In the case of --config-dir, the path is actually just copied on init. This M_OPT_FIXED mechanism is thus not strictly needed anymore. It still prevents writing to some options that cannot take effect at runtime, but even that can be dropped. In general, all mpv options can be changed any time at runtime, even if they never take effect, and there's no need to make an exception for a very low number of options. So just get rid of it.
* msg: try to document purpose of log levels betterwm42019-11-071-8/+9
| | | | (But I bet nobody ever reads this anyway.)
* common: add a helper to round up to next power of 2wm42019-11-062-0/+15
| | | | | | This is something relatively frequently needed, and there must be half a dozen ad-hoc implementations in mpv. The next commit uses this, the suspected duplicate implementations are hiding.
* common: add mp_log2()wm42019-10-312-0/+20
| | | | | | | | | | | To be used in the next commit. According to compiler explorer, __builtin_clz is very widely available, and it barely makes sense to provide a fallback. clang also eats this (and identifies at least as GCC 4). Actually, there's doubt that a fast log2 implementation is needed at all (I guess UTF-8 parsing needs it, but something UTF-8-specific would probably make it faster than using log2). So the fallback is just something naive.
* Replace uses of FFMIN/MAX with MPMIN/MAXwm42019-10-312-9/+9
| | | | And remove libavutil includes where possible.
* msg: always use terminal control codes for status linewm42019-10-241-6/+3
| | | | | | | | | | | Before this commit, the status line used terminal control codes only if stderr was a terminal. I'm not sure why this was done, and git blame tracks it back to a huge commit by me, which changed all of the terminal handling. A user complained, so just stop treating this specially for no reason. Fixes: #6617
* player: accept compatible later FFmpeg library runtime versionswm42019-10-111-1/+2
| | | | | | | | | | | | | | | | | | mpv warned if the FFmpeg runtime library version was not exactly the same as the build version. This seemed to cause frequent conflicts. At this point, most mpv code probably adheres to the FFmpeg ABI rules, and FFmpeg stopped breaking ABI "accidentally". Another source of problems were mixed FFmpeg/Libav installations, something which nobody does anymore. It's not "our" job to check and enforce ABI compatibility either. So I guess this behavior can be removed. OK, still check for incompatible libraries (according to FFmpeg versioning rules), i.e. different major versions, or if the build version is newer than the runtime version. For now. The comment about ABI problems is still true. In particular, the bytes_read field mentioned in the removed comment is still accessed, and is still an ABI violation. Have fun.
* av_log: use proper FFmpeg version extraction macroswm42019-10-111-1/+3
| | | | Though not like they will or can never change them.
* recorder: don't use a magic index for mp_recorder_get_sink()wm42019-09-292-5/+12
| | | | | | | | | | | | | | | | | | | Although this was sort of elegant, it just seems to complicate things slightly. Originally, the API meant that you cache mp_recorder_sink yourself (which would avoid the mess of passing an index around), but that too seems slightly roundabout. In a later change, I want to change the set of streams passed to mp_recorder_create(), and then I'd have to keep track of the index for each stream, which would suck. With this commit, I can just pass the unambiguous sh_stream to it, and it will be guaranteed to match the correct stream. The disadvantages are barely worth discussing. It's a new linear search per packet, but usually only 2 to 4 streams are active at a time. Also, in theory a user could want to write 2 streams using the same sh_stream (same metadata, just writing different packets or so), but in practice this is never done.
* recorder: always mux all packets on discont/closewm42019-09-191-2/+1