| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
vo->aspdat is basically an outdated version of vo->params, plus some
weirdness. Get rid of it, which will allow further cleanups and which
will make multithreading easier (less state to care about).
Also, simplify some VO code by using mp_image_set_attributes() instead
of caring about display size, colorspace, etc. manually. Add the
function osd_res_from_image_params(), which is often needed in the case
OSD renders into an image.
|
| |
|
|
| |
Seems to be a reasonable assumption, but it's probably not guaranteed.
|
| |
|
|
| |
This became dead code in commit 3f594c2e.
|
| |
|
|
|
|
|
| |
Some mpv builds identify with e.g. "mpv b'0.3.3' ". The version looks
like str() was called on a Python byte string. I couldn't reproduce it
on my machine (I tried with both Python 2 and 3), so I'm not exactly
sure what's going on here, but I'm hoping this commit does fix it.
|
| |
|
|
|
| |
Paths passed to the --lua option now follow the convention for paths
starting with ~ documented in mpv.rst.
|
| |
|
|
| |
The KF_* flags work on the HIWORD of lParam. Whoops
|
| | |
|
| |
|
|
|
|
| |
This was broken yesterday: the playlist demuxer will always fall back to
plaintext playlist files, which will cause the ASX playlist parser and
some others never to be called.
|
| |
|
|
| |
This made seeking show an empty progbar if --osd-level=0 was used.
|
| |
|
|
| |
Fixes #497
|
| |
|
|
| |
This doesn't need quoting, for some reason.
|
| |
|
|
|
| |
This was implemented in playlist_parser.c. To make it use the improved
implementation of stream_read_line(), move it to demux_playlist.c.
|
| |
|
|
|
|
|
|
| |
This is probably ok. Probing could hit this case very often, since it'll
mean running this function on potentially binary data, but on the other
hand, probing usually uses a memory stream (to limit the amount of data
read), and memory streams have s->log silenced (details see
open_memory_stream()).
|
| |
|
|
| |
Text files should never contain these.
|
| |
|
|
|
|
|
|
|
| |
This simplifies the implementation and should make it more robust. For
example, we return an error if a line is longer than the provided buffer
(instead of splitting the line).
The code is much shorter, because now finding the new line and reading
characters is done in one go.
|
| |
|
|
|
|
|
|
|
| |
As of this commit, stream_read_line() can't actually error (except in
the case the passed in buffer is 0, which never happens here). This
commit is preparation for the following commit, which checks harder
whether the read data is actually text. Before this commit, an error
was treated as end-of-file, but the data read so far was considered
valid.
|
| |
|
|
|
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
This merges pull request #496. The problem was that at least the
initialization of the distance[] array accessed af_fmtstr_table[]
entries that were out of bounds. Small cosmetic changes applied to
the original pull request.
|
| | |
|
| |
|
|
|
|
|
| |
Doesn't affect the generated code, but avoids confusion
in both humans and newer Coverity versions.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@36623 b3059339-0415-0410-9bf9-f77b7e298cf2
|
| |
|
|
|
|
|
|
|
| |
The struct we need to copy is actually a cdrom_msf0, not cdrom_msf.
Even though the kernel for no good reason reads it in as a
cdrom_msf struct, but only uses the part shared with cdrom_msf0 -
this is probably a kernel bug.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@36622 b3059339-0415-0410-9bf9-f77b7e298cf2
|
| |
|
|
|
|
| |
Again from github issue #484.
Also, sorry for the typo in the earlier commit message.
|
| |
|
|
| |
Caused by the OSD changes. Fixes #490.
|
| |
|
|
| |
Stolen from github issue #484. No idea whether they're needed.
|
| |
|
|
| |
Broken by previous commit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do two things:
1. add locking to struct osd_state
2. make struct osd_state opaque
While 1. is somewhat simple, 2. is quite horrible. Lots of code accesses
lots of osd_state (and osd_object) members. To make sure everything is
accessed synchronously, I prefer making osd_state opaque, even if it
means adding pretty dumb accessors.
All of this is meant to allow running VO in their own threads.
Eventually, VOs will request OSD on their own, which means osd_state
will be accessed from foreign threads.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
|
| |
|
|
|
|
| |
These were needed before the last commit, but now they don't do anything
anymore. (They were used to decide whether to replace or stack the
previous OSD message when a new one was displayed.)
|
| |
|
|
|
|
|
|
|
|
|
| |
If certain OSD messages were displayed at the same time, the hidden
messages were put on the stack, and displayed again once the higher
priority messages disappeared. The idea was probably that lower priority
messages could not hide higher priority ones, and also that the lower
messages did not get lost.
But in practice, this gives confusing results with OSD messages randomly
reappearing for a brief time. Remove it.
|
| |
|
|
|
|
|
|
| |
Showing subtitles on terminal used the OSD message stack (which uses a
stack to "pile up" messages that were displayed at the same time). This
had a bunch of weird and annoying consequences. This accessed a certain
osd_state field, which is a minor annoyance since I want to make that
struct opaque. Implement this differently.
|
| |
|
|
|
|
| |
This was accidentally committed.
<rcombs> `mp_sleep_us(100000);` <-- are you drunk?
|
| |
|
|
|
|
|
| |
The values set by this new option can be queried by Lua scripts using
the mp.getopt() function. The function takes a string parameter, and
returns the value of the first key that matches. If no key matches, nil
is returned.
|
| | |
|
| |
|
|
| |
Output only 1 message every 5 seconds at most.
|
| |
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
|
| |
When the Lua code was written, the core didn't have names for log levels
yet (just numbers). The only user visible change is that "verbose"
becomes "v", since this level had different names.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds the following Lua function to enable message events:
mp.enable_messages(size, level)
size is the maximum number of messages the ringbuffer consists of. level
is the minimum log level for a message to be added to the ringbuffer,
and uses the same values as the mp.log() function. (Actually not yet,
but this will be fixed in the following commit.)
The messages will be delivered via the mp_event() in the user script,
using "message" as event name. The event argument is a table with the
following fields:
level: log level of the message (string as in mp.log())
prefix: string identifying the module of origin
text: contents of the message
As of currently, the message text will contain newline characters. A
message can consist of several lines. It is also possible that a
message doesn't end with a newline, and a caller can use multiple
messages to "build" a line. Most messages will contain exactly 1 line
ending with a single newline character, though.
If the message buffer overflows (messages are not read quickly enough),
new messages are lost until the queued up messages are read. At the
point of the overflow, a special overflow message is inserted. It will
have prefix set to "overflow", and the message text is set to "".
Care should be taken not to print any messages from the message event
handler. This would lead to an infinite loop (the event handler would be
called again after returning, because a new message is available). This
includes mp.log() and all mp.msg.* functions. Keep in mind that the Lua
print() function is mapped to mp.msg.info().
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
While almost everything uses msg.h, the moved definitions are rarely
needed by anything.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Why didn't I put it there from the start?
|
| |
|
|
| |
With the old code and pos == width - 2 one character too many is drawn.
|
| |
|
|
|
| |
If the terminal width is large enough the position marker jumps over
several characters because currently pos only increases in 1/100th steps.
|
| |
|
|
| |
... to decide wether the seekbar should be enabled or not.
|
| |
|
|
|
|
|
| |
Before that, it just returned -1.
The print case is inconsistent with that, but I'll leave it for now,
because it's consistent with status line / show_progress behavior.
|
| |
|
|
| |
Also VK_APPS/MP_KEY_MENU was missing.
|
| |
|
|
|
| |
Feature request from github issue #451. Disabled by default, will
probably stay this way.
|
| | |
|
| | |
|
wm4
Stefano Pigozzi
James Ross-Gowan
Bilal Syed Hussain
11rcombs
reimar
Tomáš Chvátal
Martin Herkt
Johannes Nixdorf
ChrisK2