1
0
mirror of https://github.com/mpv-player/mpv synced 2024-12-25 16:33:02 +00:00
Commit Graph

68 Commits

Author SHA1 Message Date
wm4
ea50f6fdef msg: flush after every message for --log-file
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.
2016-09-30 14:55:59 +02:00
wm4
ef2bbd5a7a msg: make --log-file and --dump-stats accept config path expansion
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.
2016-09-28 15:04:38 +02:00
wm4
ce65ea3345 player: make --log-file and --dump-stats freely settable at runtime
Same deal as with the previous commit. We use the file paths to decide
when we should attempt to reopen them.
2016-09-19 19:56:40 +02:00
wm4
591e21a2eb osdep: rename atomics.h to atomic.h
The standard header is stdatomic.h, so the extra "s" freaks me out every
time I look at it.
2016-09-07 11:26:25 +02:00
wm4
46a3165cde msg: introduce partial line buffers per mp_log
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.
2016-03-01 22:36:05 +01:00
wm4
a5eef06225 msg: minor simplification
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.
2016-03-01 22:11:09 +01:00
wm4
e094499197 msg: use dynamic buffer for message formatting
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.
2016-03-01 21:51:59 +01:00
Dmitrij D. Czarkoff
ea442fa047 mpv_talloc.h: rename from talloc.h
This change helps avoiding conflict with talloc.h from libtalloc.
2016-01-11 21:05:55 +01:00
wm4
791228f2ab msg: remove redundant condition
Found by Coverity.
2015-12-05 23:53:24 +01:00
wm4
da496ae2fe msg: remove the useless trailing comment from stats dumping
The origin of the stats line was added as a comment (starting with '#').
It was useless and just blowing up file sizes.
2015-10-14 18:50:58 +02:00
wm4
23b83c6676 client API: allow using msg-level option for log messages
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.
2015-06-20 21:40:47 +02:00
Marcin Kurczewski
797277a233 Various spelling fixes
Signed-off-by: wm4 <wm4@nowhere>
2015-06-18 19:36:58 +02:00
wm4
91f6f2bf11 options: remove unneeded hack from command line parser
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.
2015-04-23 21:08:19 +02:00
Marcin Kurczewski
f43017bfe9 Update license headers
Signed-off-by: wm4 <wm4@nowhere>
2015-04-13 12:10:01 +02:00
wm4
01b87e509c msg: use relaxed atomics for log level test
This should be sufficient.

If stdatomic.h is not available, we make no difference.
2015-03-02 19:09:31 +01:00
wm4
ffe894ec0a options: change --msg-level option
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.
2015-02-06 16:48:52 +01:00
wm4
96f7c96da0 msg: add --log-file option
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.
2015-01-26 11:31:02 +01:00
wm4
4c3f042777 command: make the "run" command work on Windows too
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().
2015-01-01 20:37:49 +01:00
wm4
26bc6b4831 Add some missing "const"s
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).
2014-10-10 13:44:08 +02:00
Stefano Pigozzi
e99a37f635 fix -Wduplicate-decl-specifier warnings with clang 2014-10-09 22:14:41 +02:00
wm4
06ecf54fdf msg: fix unwanted blank lines
Was broken in a commit earlier this day.
2014-10-08 15:03:48 +02:00
wm4
0ec5d35d57 client API: introduce numeric log levels
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.
2014-10-08 14:17:33 +02:00
wm4
f73778ad82 msg, client API: buffer partial lines
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.
2014-10-08 13:11:55 +02:00
wm4
2632ea3de6 msg, client API: never send the status line as log message
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.
2014-10-08 12:51:12 +02:00
wm4
046ad8c5ae msg: set an explicit overflow message
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.)
2014-10-08 12:49:04 +02:00
wm4
68ff8a0484 Move compat/ and bstr/ directory contents somewhere else
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.
2014-08-29 12:31:52 +02:00
Ben Boeckel
7c0a5698eb posix: use STD*_FILENO constants
Rather than "magic" numbers, use meaningful constant names provided by
unistd.h.
2014-08-28 12:03:17 +02:00
wm4
cae22ae3b6 msg: allow duplicating a mp_log
Trivial; this is mostly just reindenting the normal codepath.
2014-08-25 00:48:56 +02:00
wm4
47b29094c3 win32: emulate some ANSI terminal escape codes
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.
2014-08-21 22:45:58 +02:00
wm4
bf5b1e9a05 Remove the last remains of slave mode
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.
2014-08-01 22:57:56 +02:00
wm4
d27a2bc546 build: allow compilation without any atomics
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
2014-07-05 17:07:16 +02:00
wm4
99f5fef0ea Add more const
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.
2014-06-11 00:39:14 +02:00
wm4
3b7402b51c client API: call wakeup callback if there are new messages
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.)
2014-06-06 19:24:30 +02:00
wm4
8e7cf4bc99 atomics: switch to C11 stdatomic.h
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.
2014-05-21 02:21:18 +02:00
Martin Herkt
48bd03dd91 options: remove deprecated --identify
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.
2014-05-04 02:46:11 +02:00
wm4
ac1a21e488 terminal: fix printing of prefix
This was subtly change in 5cfb18. Revert the change.
2014-04-23 21:16:50 +02:00
wm4
9dba2a52db player: add a --dump-stats option
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.
2014-04-17 21:47:00 +02:00
FRAU KOUJIRO
6c24a80009 msg: correct ringbuffer log level comparison 2014-04-17 01:43:07 +02:00
Evan Purkhiser
5cfb180a89 terminal: pretty print modules for --msgmodule 2014-04-12 11:37:53 +02:00
wm4
97409ec4e6 msg: add --msgtime option to add timestamps to each output message
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.)
2014-02-28 22:45:34 +01:00
wm4
8437356b6c options: add --no-terminal switch
Mostly useful for internal reasons. This code will be enabled by
default if mpv is started via the client API.
2014-02-10 00:14:52 +01:00
wm4
7f744c9a16 msg: clear lines by printing spaces on MS Windows
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).
2014-02-09 00:45:26 +01:00
wm4
5035bccb41 msg: don't clear the status line if new and previous status was empty
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.
2014-01-29 17:15:05 +01:00
wm4
8c5ea38cda msg: expose log level names 2014-01-16 23:06:40 +01:00
wm4
738dfbb2fe msg: add a mechanism to output messages to a ringbuffer
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.
2014-01-16 23:06:40 +01:00
wm4
99ee43b33b msg: move special declarations to msg_control.h
While almost everything uses msg.h, the moved definitions are rarely
needed by anything.
2014-01-16 23:06:40 +01:00
wm4
5b14db5ab1 msg: print module prefixes even if message contains newlines
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.
2014-01-16 23:06:40 +01:00
wm4
904060ad7b msg: update comment 2014-01-15 13:36:48 +01:00
wm4
44993ba0fb msg: terminal OSD uses stderr, not stdout
This is more correct. E.g. if you do "mpv file.mkv > /dev/null", stdout
will not be a terminal, but stderr (used by terminal OSD and status
line) is.
2014-01-15 13:36:39 +01:00
wm4
b51713e8e7 msg: don't clear term OSD lines that are not used 2014-01-14 17:37:55 +01:00