summaryrefslogtreecommitdiffstats
path: root/common/msg.c
Commit message (Collapse)AuthorAgeFilesLines
* msg: use nanosecond precisionDudemanguy2023-09-291-3/+3
| | | | | | | | | | The timestamps when making a log file is actually dependent on MP_START_TIME. This is a 10 microsecond offset that was added to the timer as an offset. With the nanosecond change, this unit needs to be converted as well so the offset is the same as before. After doing that, we need to change the various mp_time_us calls in msg to mp_time_ns and do the right conversion. This fixes the logs timestamps (i.e. so they aren't negative anymore).
* msg: print MSGL_WARN and higher error messages to stderrDudemanguy2023-07-241-1/+2
| | | | | | | | mpv has a convention of printing everything to stdout. The reasons for this are pretty unclear and in certain situations rather unintuitive. It leads to some bad behavior in fringe cases with encoding mode and isn't the norm for programs so just adjust it so warnings and up are printed to stderr. Fixes #8608.
* msg: log-file set at mpv.conf: don't ignore early messagesAvi Halachmi (:avih)2023-01-231-9/+74
| | | | | | | | | | | | | | | | | Previously, if log-file was set not via a CLI option (e.g. set via mpv.conf or other config file, or set from a script init phase), then meaningful early log messages were thrown away because the log file name was unknown initially. Such early log messages include the command line arguments, any options set from mpv.conf, and possibly more. Now we store up to 5000 early messages before the log file name is known, and flush them once/if it becomes known, or destroy this buffer once mpv init is complete. The implementation is similar and adjacent, but not identical, to an existing early log system for mpv clients which request a log buffer.
* msg: log-file buffer size: don't use magic number (no-op)Avi Halachmi (:avih)2023-01-231-1/+3
|
* various: replace abort() with MP_ASSERT_UNREACHABLE() where appropriatesfan52023-01-121-1/+1
| | | | | | | | In debug mode the macro causes an assertion failure. In release mode it works differently and tells the compiler that it can assume the codepath will never execute. For this reason I was conversative in replacing it, e.g. in mpv-internal code that exhausts all valid values of an enum or when a condition is clear from directly preceding code.
* msg: fix really-quiet option to only affect terminal outputder richter2021-02-231-2/+2
| | | | | | | | | | | | if log-file and really-quiet options were used together it could lead to a completely empty log-file. this is unexpected because we need the log-file option to work in all cases and produces at least a log of verbosity -v -v. this is a regression of commit a600d152d21ef398eb72b008ee3fe266696eb638 move the really quiet check back up, so it's set before the evaluation of the actual log level, where check for log file, terminal, etc take place.
* 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).
* player: add --term-title optionwm42020-05-251-0/+10
| | | | | | | | | | | | | | 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
* msg: add function to reduce log levelwm42020-05-101-2/+17
| | | | | | | | | | 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.
* 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-291-53/+168
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.)
* 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-181-1/+59
| | | | | | | | | | | | | | | | | | | | | | 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.
* 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
* msg: remove unnecessary conditionwm42019-09-191-4/+0
| | | | Atomics were made mandatory some time ago.
* vo_gpu: vulkan: use libplacebo insteadNiklas Haas2019-04-211-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | This commit rips out the entire mpv vulkan implementation in favor of exposing lightweight wrappers on top of libplacebo instead, which provides much of the same except in a more up-to-date and polished form. This (finally) unifies the code base between mpv and libplacebo, which is something I've been hoping to do for a long time. Note: The ra_pl wrappers are abstract enough from the actual libplacebo device type that we can in theory re-use them for other devices like d3d11 or even opengl in the future, so I moved them to a separate directory for the time being. However, the rest of the code is still vulkan-specific, so I've kept the "vulkan" naming and file paths, rather than introducing a new `--gpu-api` type. (Which would have been ended up with significantly more code duplicaiton) Plus, the code and functionality is similar enough that for most users this should just be a straight-up drop-in replacement. Note: This commit excludes some changes; specifically, the updates to context_win and hwdec_cuda are deferred to separate commits for authorship reasons.
* player: get rid of mpv_global.optswm42018-05-241-9/+2
| | | | | | | | This was always a legacy thing. Remove it by applying an orgy of mp_get_config_group() calls, and sometimes m_config_cache_alloc() or mp_read_option_raw(). win32 changes untested.
* msg: bump up log level of --log-fileNiklas Haas2017-12-151-2/+2
| | | | This now logs -v -v by default, instead of -v.
* msg: make --msg-level affect --log-file toowm42017-10-041-1/+1
| | | | | | | But --msg-level can only raise the log level used for --log-file, because the original idea with --log-file was that it'd log verbose messages to disk even if terminal logging is lower than -v or fully disabled.
* build: add preliminary LGPL modewm42017-09-211-9/+7
| | | | | | | See "Copyright" file for caveats. This changes the remaining "almost LGPL" files to LGPL, because we think that the conditions the author set for these was finally fulfilled.
* options: unbreak -vwm42017-06-231-1/+1
| | | | Sigh... broken with the --really-quiet commit. I hate -v.
* options: remove weird --really-quiet special behaviorwm42017-06-231-1/+5
| | | | | | | | | This was especially grating because it causes problems with the option/property unification, uses as only thing OPT_FLAG_STORE, and behaves weird with the client API or scripts. It can be reimplemented in a much simpler way, although it needs slightly more code. (Simpler because less special cases.)
* player: make sure version information is always included in --log-filewm42017-05-221-0/+13
| | | | | | | If --log-file was used in config files, this could be missing due to the exact timing when the messages are print, and when the options are applied. Fix this by always dumping the version again when a log file is opened.
* msg.c/h: partially change license to LGPLwm42017-05-051-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | msg.c is "partial" due to "michael", whose work can be changed to LGPL only once the core is LGPL. It's explained in the Copyright file. I prefer to do the relicensing incrementally (due to the overwhelming workload). Changing the license before that happens would be legally questionable, but nothing can stop us from essentially marking it as "will be LGPL". All authors have agreed to LGPL, with the following exceptions: 9df11ee8bf: the author (probably) didn't agree, but the line that is added is later fully removed. 35e90f1556: was not asked, but all iconv code was 100% removed from the mp_msg mechanism (we alwas require UTF-8 now). 4e4f3f806e: the change by michael. 50a86fcc34: the identify variable was move, and completely removed the latest in commit 48bd03dd91232. 1f6c494641: did not agree, but due to a major mp_msg change the added line became unnecessary and was removed. da63498bf9: was not reachable, but the MPlayer GUI is gone from mpv anyway (also commit fc4d6e617d8d removed these specific additions a long time ago).
* msg: flush after every message for --log-filewm42016-09-301-0/+1
| | | | | | We'd like to get log messages on the output as soon as possible in the output. I also feel like using fflush() is nicer than using setvbuf(). Who knows how the latter behaves on win32.
* msg: make --log-file and --dump-stats accept config path expansionwm42016-09-281-17/+27
| | | | | | | | | Seems like a valid use-case. Not sure if I like it calling back into the config code. Care has to be taken for not letting the config path resolving code dead-lock (which is why locking details in the msg.c code are changed). Fixes #3591.
* player: make --log-file and --dump-stats freely settable at runtimewm42016-09-191-20/+37
| | | | | Same deal as with the previous commit. We use the file paths to decide when we should attempt to reopen them.
* osdep: rename atomics.h to atomic.hwm42016-09-071-1/+1
| | | | | The standard header is stdatomic.h, so the extra "s" freaks me out every time I look at it.
* msg: introduce partial line buffers per mp_logwm42016-03-011-25/+28
| | | | | | | | | | | | | | | | The goal is reducing log messups (which happen surprisingly often) by buffering partial lines in mp_log. This is still not 100% reliable, but better. The extrabuffers for MSGL_STATUS and MSGL_STATS are not needed anymore, because a separate mp_log instance can be used if problems really occur. Also, give up, and replace the snprintf acrobatics with bstr. mp_log.partial has a quite subtle problem wrt. talloc: talloc parents can not be used, because there's no lock around the internal talloc structures associated with mp_log. Thus it has to be freed manually, even if this happens through a talloc destructor.
* msg: minor simplificationwm42016-03-011-11/+6
| | | | | Instead of playing ugly tricks with the buffer to append a \r or \n to the text buffer, extend print_terminal_line() to print a second string.
* msg: use dynamic buffer for message formattingwm42016-03-011-11/+19
| | | | | | | | | | | | | | | | | Until now, a rather large stack buffer was used for this, and also a static buffer in mp_log_root. The latter was added to buffer partial lines, and the stack buffer was used only for MSGL_STATUS and MSGL_STATS (I guess because these are the most likely/severe to clash with partial line buffering). Make the buffer in mp_log_root dynamically sized, so we don't get cut off log lines if the text is excessively large. (The OpenGL extension list dumped by vo_opengl is such an example.) Since we still have to support partial line buffering (FFmpeg's log callbacks leave no other choice), keep the stack buffer. But make it smaller; there's no way all ~6KB are going to be needed in any situation.
* mpv_talloc.h: rename from talloc.hDmitrij D. Czarkoff2016-01-111-1/+1
| | | | This change helps avoiding conflict with talloc.h from libtalloc.
* msg: remove redundant conditionwm42015-12-051-1/+1
| | | | Found by Coverity.
* msg: remove the useless trailing comment from stats dumpingwm42015-10-141-4/+2
| | | | | The origin of the stats line was added as a comment (starting with '#'). It was useless and just blowing up file sizes.
* client API: allow using msg-level option for log messageswm42015-06-201-11/+10
| | | | | | | | | | | | | | | | Client API users can enable log output with mpv_request_log_messages(). But you can enable only a single log level. This is normally enough, but the --msg-level option (which controls the terminal log level) provides more flexibility. Due to internal complexity, it would be hard to provide the same flexibility for each client API handle. But there's a simple way to achieve basically the same thing: add an option that sends log messages to the API handle, which would also be printed to the terminal as by --msg-level. The only change is that we don't disable this logic if the terminal is disabled. Instead we check for this before the message is output, which in theory can lower performance if messages are being spammed. It could be handled with some more effort, but the gain would be negligible.
* Various spelling fixesMarcin Kurczewski2015-06-181-1/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* options: remove unneeded hack from command line parserwm42015-04-231-10/+1
| | | | | | | | | | | | | | | This was traditionally needed to silence terminal output from errors during command line parsing preparsing. Preparsing is done so that options controlling the terminal and config files are parsed and applied first, with a second command line parsing pass applying all other options, _and_ printing error messages for the preparsed ones. But the hack silencing log output during the preparse pass is actually not needed anymore, since the terminal is enabled only after preparsing is finished. update_logging() in main.c does this. So as long as update_logging() is called before m_config_preparse_command_line(), this will work.
* Update license headersMarcin Kurczewski2015-04-131-5/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* msg: use relaxed atomics for log level testwm42015-03-021-1/+4
| | | | | | This should be sufficient. If stdatomic.h is not available, we make no difference.
* options: change --msg-level optionwm42015-02-061-31/+16
| | | | | | | | | | | | | | Make it accept "," as separator, instead of only ":". Do this by using the key-value-list parser. Before this, the option was stored as a string, with the option parser verifying that the option value as correct. Now it's stored pre-parsed, although the log levels still require separate verification and parsing-on-use to some degree (which is why the msg-level option type doesn't go away). Because the internal type changes, the client API "native" type also changes. This could be prevented with some more effort, but I don't think it's worth it - if MPV_FORMAT_STRING is used, it still works the same, just with a different separator on read accesses.
* msg: add --log-file optionwm42015-01-261-0/+22
| | | | | | | | | This allows getting the log at all with --no-terminal and without having to retrieve log messages manually with the client API. The log level is hardcoded to -v. A higher log level would lead to too much log output (huge file sizes and latency issues due to waiting on the disk), and isn't too useful in general anyway. For debugging, the terminal can be used instead.
* command: make the "run" command work on Windows toowm42015-01-011-2/+3
| | | | | | | | | Do so by using mp_subprocess(). Although this uses completely different code on Unix too, you shouldn't notice a difference. A less ncie thing is that this reserves an entire thread while the command is running (which wastes some memory for stack, at least). But this is probably still the simplest way, and the fork() trick is apparently not implementable with posix_subprocess().
* Add some missing "const"swm42014-10-101-1/+1
| | | | | | | The one in msg.c was mistakenly removed with commit e99a37f6. I didn't actually test the change in ao_sndio.c (but obviously "ap" shouldn't be static).
* fix -Wduplicate-decl-specifier warnings with clangStefano Pigozzi2014-10-091-2/+2
|
* msg: fix unwanted blank lineswm42014-10-081-1/+3
| | | | Was broken in a commit earlier this day.
* client API: introduce numeric log levelswm42014-10-081-0/+14
| | | | | | | | | | | | | | | | Maybe using strings for log levels was a mistake (too broad and too impractical), so I'm adding numeric log level at least for the receiver side. This makes it easier to map mpv log levels to other logging systems. I'm still too stingy to add a function to set the log level by a numeric value, though. The numeric values are not directly mapped to the internal mpv values, because then almost every file in mpv would have to include the client API header. Coalesce this into API version 1.6, since 1.6 was bumped just yesterday.
*