summaryrefslogtreecommitdiffstats
path: root/common/msg.c
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* msg, client API: buffer partial lineswm42014-10-081-61/+73
| | | | | | | | | | | | | | | The API could return partial lines, meaning the message could stop in the middle of a line, and the next message would have the rest of it (or just the next part of it). This was a pain for the user, so do the nasty task of buffering the lines ourselves. Now only complete lines are sent. To make things even easier for the API user, don't put multiple lines into a single event, but split them. The terminal output code needed something similar (inserting a prefix header on start of each line). To avoid code duplication, this commit refactors the terminal output so that lines are split in a single place.
* msg, client API: never send the status line as log messagewm42014-10-081-1/+1
| | | | | | | | | | | | | The status line is a bit special; for example it uses special control codes by design and is not terminated with a newline character in order to update it on the terminal without scrolling. It's not helpful for client API users either, and would require special-casing them (emulating aspects of a terminal?). Also, the status line code is explicitly disabled on osd.c unless the --terminal option is enabled, so there was no good way to even enable the status line for the API. Just pretend that the status line does not exist as far as the client API is concerned. It won't be sent as MPV_EVENT_LOG_MESSAGE.
* msg: set an explicit overflow messagewm42014-10-081-1/+1
| | | | | | | | So client API users don't have to worry about this specifically. Also document the overflow case. (Not sure if we really need to do this; maybe it'd be better not to, since this just adds more noise to the docs.)
* Move compat/ and bstr/ directory contents somewhere elsewm42014-08-291-2/+2
| | | | | | | | | bstr.c doesn't really deserve its own directory, and compat had just a few files, most of which may as well be in osdep. There isn't really any justification for these extra directories, so get rid of them. The compat/libav.h was empty - just delete it. We changed our approach to API compatibility, and will likely not need it anymore.
* posix: use STD*_FILENO constantsBen Boeckel2014-08-281-2/+2
| | | | | Rather than "magic" numbers, use meaningful constant names provided by unistd.h.
* msg: allow duplicating a mp_logwm42014-08-251-15/+20
| | | | Trivial; this is mostly just reindenting the normal codepath.
* win32: emulate some ANSI terminal escape codeswm42014-08-211-12/+16
| | | | | | | | | | | | | | We already redirect all terminal output through our own wrappers (for the sake of UTF-8), so we might as well use it to handle ANSI escape codes. This also changes behavior on UNIX: we don't retrieve some escape codes per terminfo anymore, and just hardcode them. Every terminal should understand them. The advantage is that we can pretend to have a real terminal in the normal player code, and Windows atrocities are locked away in glue code.
* Remove the last remains of slave modewm42014-08-011-1/+1
| | | | | | | | | | | Almost nothing was left of it. The only thing this commit actually removes is support for reading input commands from stdin. But you can emulate this via: --input-file=/dev/stdin --input-terminal=no However, this won't work on Windows. Just use a named pipe.
* build: allow compilation without any atomicswm42014-07-051-0/+4
| | | | | | | | | | | | | | | | | | | Not all compilers on all platforms have atomics available (even if they could, technically speaking). We don't use atomics that much, only the following things rely on it: 1. the audio pull code, and all audio outputs using it 2. updating global msg levels 3. reading log messages through the client API Just disable 1. and 3. if atomics are not available. For 2., using fake- atomics isn't too bad; at worst, message levels won't properly update under certain situations (but most likely, it will work just fine). This means if atomics are not available, the client API function mpv_request_log_messages() will do nothing. CC: @mpv-player/stable
* Add more constwm42014-06-111-1/+1
| | | | | | | While I'm not very fond of "const", it's important for declarations (it decides whether a symbol is emitted in a read-only or read/write section). Fix all these cases, so we have writeable global data only when we really need.
* client API: call wakeup callback if there are new messageswm42014-06-061-1/+9
| | | | | | | | | | | | | | | | | | Listening on messages currently uses polling (every time mpv_wait_event() has no new events, the message buffer is polled and a message event is possibly created). Improve this situation a bit, and call the user-supplied wakeup callback. This will increase the frequency with which the wakeup callback is called, but the client is already supposed to be able to deal with this situation. Also, as before, calling mpv_wait_event() from the wakeup callback is forbidden, so the client can't read new messages from the callback directly. The wakeup pipe is written either. Since the wakeup pipe is created lazily, we can't access the pipe handle without creating a race condition or a deadlock. (This is actually very silly, since in practice the race condition won't matter, but for now let's keep it clean.)
* atomics: switch to C11 stdatomic.hwm42014-05-211-17/+14
| | | | | | | | | | | | | | | | | | | | | | | | | In my opinion, we shouldn't use atomics at all, but ok. This switches the mpv code to use C11 stdatomic.h, and for compilers that don't support stdatomic.h yet, we emulate the subset used by mpv using the builtins commonly provided by gcc and clang. This supersedes an earlier similar attempt by Kovensky. That attempt unfortunately relied on a big copypasted freebsd header (which also depended on much more highly compiler-specific functionality, defined reserved symbols, etc.), so it had to be NIH'ed. Some issues: - C11 says default initialization of atomics "produces a valid state", but it's not sure whether the stored value is really 0. But we rely on this. - I'm pretty sure our use of the __atomic... builtins is/was incorrect. We don't use atomic load/store intrinsics, and access stuff directly. - Our wrapper actually does stricter typechecking than the stdatomic.h implementation by gcc 4.9. We make the atomic types incompatible with normal types by wrapping them into structs. (The FreeBSD wrapper does the same.) - I couldn't test on MinGW.
* options: remove deprecated --identifyMartin Herkt2014-05-041-8/+3
| | | | | | | 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.
* terminal: fix printing of prefixwm42014-04-231-2/+3
| | | | This was subtly change in 5cfb18. Revert the change.
* player: add a --dump-stats optionwm42014-04-171-2/+40
| | | | | | | | | | | | | | | | | | | | | | | 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.
* msg: correct ringbuffer log level comparisonFRAU KOUJIRO2014-04-171-1/+1
|
* terminal: pretty print modules for --msgmoduleEvan Purkhiser2014-04-121-2/+26
|
* msg: add --msgtime option to add timestamps to each output messagewm42014-02-281-2/+9
| | | | | | | Will be helpful to track down strange wait times and such issues, as well when you have develop something timing related. (Then you may print timestamps in your debug output, and the --msgtime timestamps will help giving context.)
* options: add --no-terminal switchwm42014-02-101-13/+21
| | | | | Mostly useful for internal reasons. This code will be enabled by default if mpv is started via the client API.
* msg: clear lines by printing spaces on MS Windowswm42014-02-091-1/+7
| | | | | | | | | | | | | | | On Windows, no ANSI control sequences are available, so we can't easily clear lines, move the cursor, etc. It's yet to be decided how this should be handled (emulate ANSI escapes in osdep/terminal-win.c, or provide abstracted terminal API functions to unify the Linux and Windows code). For now, this fixes the regression that was introduced earlier by the status line rewrite. It doesn't fix all aspects of status line and terminal OSD handling, as can be clearly seen by the unconditional use of terminal_erase_to_end_of_line further down the changed code. Fixes github issue #499 (sort of).
* msg: don't clear the status line if new and previous status was emptywm42014-01-291-0/+3
| | | | | | | | | | | | | This avoids stray newlines when: 1. Some (non-status line) text was output 2. Then an empty status line is output According to the logic, 2. should print an empty line to show the blank status line. Don't do that, and instead output nothing in this case. This caused problems with mpv_identify.sh, and also looked ugly when using --quiet.
* msg: expose log level nameswm42014-01-161-3/+3
|
* msg: add a mechanism to output messages to a ringbufferwm42014-01-161-18/+140
| | | | | | | | | | | | | | | | | | | | | | | | | Until now, mp_msg output always went to the terminal. There was no way to grab the stream of output messages. But this will be needed by various future changes: Lua scripts, slave mode, client library... This commit allows registering a ring buffer. A callback would be more straight-forward, but since msg.c sits at the bottom of the lock hierarchy (it's used by virtually everything), this would probably be a nightmare. A ring buffer will be simpler and more predictable in the long run. We allocate new memory for each ringbuffer entry, which is probably a bit expensive. We could try to be clever and somehow pack the data directly into the buffer, but I felt like this wouldn't be worth the complexity. You'd have to copy the data a bunch of times anyway. I'm hoping that we can get away with using the ringbuffer mechanism for low frequency important messages only (and not e.g. for high volume debug messages), so the cost doesn't matter that much. A ringbuffer has a simple, single log level. I considered allowing --msglevel style per-prefix configuration for each ringbuffer, but that would have been pretty complicated to implement, and wouldn't have been that useful either.
* msg: move special declarations to msg_control.hwm42014-01-161-1/+2
| | | | | While almost everything uses msg.h, the moved definitions are rarely needed by anything.
* msg: print module prefixes even if message contains newlineswm42014-01-161-12/+23
| | | | | | | | | | | | | | This makes mp_msg(x, y, "a\nb\n") behave the same as mp_msg(x, y, "a\n") mp_msg(x, y, "b\n") which is probably what one would expect. Before this commit, the "b" line didn't have a prefix when using ths single mp_msg call.
* msg: upda