| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
This was subtly change in 5cfb18. Revert the change.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Add the event FD after preinit, remove it before destroy. There's no
need to do it on vo_config, and there's no need to remove the event
FD when vo_config fails.
|
| |
|
|
| |
Group together related functionality.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should fix some issues, such as not being able to set the
"no-video" option with MPV_FORMAT_FLAG.
Note that this changes semantics a bit. Now setting an option strictly
overwrite it, even if the corresponding command line option does not.
For example, if we change --sub to append by default, then setting the
"sub" option via the client API would still never append. (Oddly, this
also applies to --vf-add, which will overwrite the old value when using
the client API.)
I'm doing this because there's no proper separation between the command
line parser and setting an option using the MPV_FORMAT_STRING format.
Maybe the solution to this mess would be adding format aware code (i.e.
m_option_set_node) to every option type, and falling back to strings
only if needed - but this would mean that you couldn't set e.g. an
integer option using MPV_FORMAT_STRING, which doesn't seem to be ideal
either.
In conclusion, the current approach seems to be most robust, but I'm
open to suggestions should someone find that these semantics are a
problem.
|
| |
|
|
|
|
|
|
|
| |
glob() is mandated by POSIX. For the only non-POSIX platform we support,
Windows, we have our own replacement. So the ifdeffery is not needed.
Still leave the checks in the configure scripts, because they have to
decide whether to compile the replacement or not. (Although this could
be special cased to mingw-only, the wscript seems to make this hard.)
|
| |
|
|
| |
For completeness.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Unfortunately, if a VO can't display something as intended, we can just
complain to the user, and leave it at it. But it's still better than
silently displaying things differently with different VOs.
For now, this is used for rotation only. Other things that we should
check includes colorspace and colorlevels stuff.
|
| |
|
|
|
|
|
| |
When using rotation with hw decoding, and the VO does not support
rotation, vf_rotate is attempted to be inserted. This will go wrong, and
after that it can't recover because a vf_scale filter was autoinserted.
Just removing all autoinserted filters before reconfig fixes this.
|
| |
|
|
|
|
| |
The Windows port uses CommandLineToArgvW, which doesn't expand wildcards
in command line arguments. Use glob to expand them instead, but only for
non-option arguments.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
glob-win.c wasn't big, so it was easier to rewrite it. The new version
supports Unicode, handles directories properly, sorts the output and
puts all its allocations in the same talloc context to simplify the
implementation of globfree.
Notably, the old glob had error checking code, but didn't do anything
with the errors since the error reporting code was commented out. The
new glob doesn't copy this behaviour. It just treats errors as if there
were no more matching files, which shouldn't matter for mpv, since it
ignores glob errors too.
To match the other Windows I/O helper functions, the definition is moved
to osdep/io.h.
|
| |
|
|
|
|
|
| |
If the VO can't do rotation, insert a filter to do this. Note that this
doesn't reuse the filter insertion code from command.c (used by "vf"
input command), because that would end up more complicated: we don't
even want to change the user filter option.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This turned out much more complicated than I thought. It's not just a
matter of adjusting the texture coordinates, but you also have to
consider separated scaling and panscan clipping, which make everything
complicated.
This actually still doesn't clip 100% correctly, but the bug is only
visible when rotating (or flipping with --vf=flip), and using something
like --video-pan-x/y at the same time.
|
| |
|
|
|
|
| |
For rotation, we assume that the source image will be rotated within the
VO, so the aspect/panscan code needs to calculate its param using
rotated coordinates. VOs which support rotation natively can use this.
|
| |
|
|
|
| |
Shuffle the special cases around so that it looks cleaner. The result
should be equivalent to the code before.
|
| |
|
|
|
| |
Now the rotation hint is propagated everywhere. It just isn't used
anywhere yet.
|
| | |
|
| |
|
|
|
| |
Minor cleanup, so that we can stuff more information into
mp_image_params later.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This couldn't rotate by 180°. Add this, and also make the parameter in
degrees, instead of magic numbers.
For now, drop the flipping stuff. You can still flip with --vf=flip or
--vf=mirror. Drop the landscape/portrait stuff - I think this is
something almost nobody will use. If it turns out that we need some of
these things, they can be readded later.
Make it use libavfilter. Its vf_transpose implementation looks pretty
simple, except that it uses slice threading and should be much faster.
|
| |
|
|
|
| |
The previous commit doesn't handle additionally loaded config files,
such as the playback resume mechanism.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Often, user configs set options that are not suitable for encoding.
Usually, playback and encoding are pretty different things, so it makes
sense to keep them strictly separate. There are several possible
solutions. The approach taken by this commit is to basically ignore the
default config settings, and switch to an [encoding] config profile
section instead. This also makes it impossible to have --o in a config
file, because --o enables encode mode.
See github issue #727 for discussion.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Fix all include statements of the form:
#include "libav.../..."
These come from MPlayer times, when FFmpeg was somehow part of the
MPlayer build tree, and this form was needed to prefer the local files
over system FFmpeg.
In some cases, the include statement wasn't needed or could be replaced
with mpv defined symbols.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not needed anymore. I'm not opposed to having asm, but inline asm is too
much of a pain, and it was planned long ago to eventually get rid fo all
inline asm uses.
For the note, the inline asm use that was removed with the previous
commits was almost worthless. It was confined to video filters, and most
video filtering is now done with libavfilter. Some mpv filters (like
vf_pullup) actually redirect to libavfilter if possible.
If asm is added in the future, it should happen in the form of external
files.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Becomes a bit slower (tested with progressive solid color video only),
but this filter is pretty obscure and I'm not even sure what it's useful
for.
|
| |
|
|
|
|
| |
No change in speed (or even slightly faster, though I tested with
progressive solid color video only), and normally we use libavformat's
vf_pullup anyway.
|
| |
|
|
|
|
|
|
| |
I didn't test the speed, but by default, this filter diverts to
libavfilter already. So this would help only if libavfilter is disabled,
or libavfilter doesn't have vf_noise (like on Libav). For these cases,
we still provide the (possibly but not necessarily) slower C
implementation of vf_noise.
|
| |
|
|
|
|
|
|
| |
This makes it multiple times slower. However, the output format (packed
YUV) isn't handled efficiently by anything to begin with, and I have no
clue we even have this filter. I guess it's one of these filters which
find some use sometimes, but are not of higher importance, which
justifies removing the faster inline asm.
|
| |
|
|
|
| |
Compiled with -O2, the C code runs just as far (or even slightly faster)
then the MMX inline asm.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This can be used to easily extent the status line for one's own needs.
I'm not experienced with lua so a few things could probably be done a
better way.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is for the sake of multi-key commands again. This could break:
SPACE ignore
SPACE-SPACE command
while this worked:
SPACE-SPACE command
SPACE ignore
The reason being that if the shorter command was first in the list,
it would obviously match, and searching was stopped.
|
| |
|
|
|
|
| |
This is for the sake of multi-key combinations (see github issue #718).
Now a multi-key sequence isn't matched if any of the previous keys were
actually mapped.
|
| | |
|
| |
|
|
| |
Just in case something adds shift/alt/ctrl state to it.
|
| |
|
|
|
| |
The explanation is kind of obvious, but on the other it'd probably be
confusing not to clarify this.
|
| |
|
|
| |
There's no need to wakeup the core in this situation.
|
| | |
|
| |
|
|
|
|
|
| |
MP_KEY_EMIT_ON_UP and MP_NO_REPEAT_KEY are not modifiers, just static
flags that some keycodes set.
This is just a cosmetic change.
|
| |
|
|
|
|
|
|
|
| |
We only need to track key up/down for a single key. There may be some
minor loss of robustness, but this can (probably) happen only if a VO or
user sends strange or complicated sequences of events. In the normal
case, what we do is more than enough. Most simplification comes from the
fact that mpv is not a game console, and users normally execute only one
action at once.
|
| |
|
|
| |
Squashing this with the following commit would be confusing.
|
| |
|
|
|
| |
I admit I don't really understand anymore why this was needed. Delete it
anyway. It was added with commit 42fa7cbbf.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The window close button is usually mapped to the CLOSE_WIN pseudo-key.
Until now, --input-test treated this pseudo-key like any other key (like
the rest of the input handling code), so you couldn't close the window
in this mode. The manpage had silly instructions and warnings how to
deal with this.
Just always quit when CLOSE_WIN is received, and improve the
instructions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The input code always supported combinations of multiple keys (even in
MPlayer, although there the code was active really only for mouse
buttons). This was arcance and also made the code more complicated. I
only know of a single person who ever made use of this feature.
Remove this feature, and repurpose some of the support code (e.g.
parsing, display of key combinations, etc.) to handle such multi-
combinations as sequences, instead of keys to be pressed at the same
time. This is much simpler and implements the feature requested in
github issue #718.
This commit will probably cause a bunch of regressions, since the input
handling code has some weird corner cases. I couldn't find any problems
when testing, though.
|
| |
|
|
|
|
| |
This avoids too many realloc() calls if the caller is appending to an
audo buffer. This case is actually quite noticeable when using something
that buffers a large amount of audio.
|
| |
|
|
| |
Was forgotten in commit 1b398e99.
|
| |
|
|
|
| |
This considered audio to never reach EOF when audio was disabled,
instead of always being EOF.
|
| |
|
|
| |
Unlike --loop, loops a file instead of the playlist.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some reason, the buffered_audio variable was used to "cache" the
ao_get_delay() result. But I can't really see any reason why this should
be done, and it just seems to complicate everything.
One reason might be that the value should be checked only if the AO
buffers have been recently filled (as otherwise the delay could go low
and trigger an accidental EOF condition), but this didn't work anyway,
since buffered_audio is set from ao_get_delay() anyway at a later point
if it was unset. And in both cases, the value is used _after_ filling
the audio buffers anyway.
Simplify it. Also, move the audio EOF condition to a separate function.
(Note that ao_eof_reached() probably could/should whether the last
ao_play() call had AOPLAY_FINAL_CHUNK set to avoid accidental EOF on
underflows, but for now let's keep the code equivalent.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This replaces translate_key_input with a solution that gives mpv more
control over how keyboard input is converted to unicode. As a result:
- Key up/down events are generated the same way for all keys.
- Dead keys generate their base character instead of being combined with
the following character.
- Many Ctrl and Ctrl+Alt key combinations that were previously broken
are fixed, since it's possible to discover the base keys.
- AltGr doesn't produce special characters when mp_input_use_alt_gr is
false.
This also fixes some logic to do with detecting AltGr and adds proper
UTF-16 decoding.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This was reported with PulseAudio 2.1. Apparently it still has problems
with reporting the correct delay. Since ao_pulse.c still has our custom
get_delay implementation, there's a possibility that this is our fault,
but this seems unlikely, because it's full of workarounds for issues
like this. It's also possible that this problem doesn't exist on
PulseAudio 5.0 anymore (I didn't explicitly retest it).
The check is general and works for all push based AOs. For pull based
AOs, this can't happen as pull.c implements all the logic correctly.
|
| |
|
|
|
|
| |
This should probably be an AO function, but since the playloop still has
some strange stuff (using the buffered_audio variable instead of calling
ao_get_delay() directly), just leave it and make it more explicit.
|
| |
|
|
|
| |
This EOF problems happen at least with PulseAudio, but since it's hard
to reproduce, let ao_null optionally simulate it.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This was accidentally completely destroyed with commit 24f1878e. I
didn't notice it when testing, because forward seeking still worked
mostly.
The issue was that dvd_seek_to_time() actually called stream_seek(),
which was supposed to call the byte-level seek function dvd_seek(). So
we have to restore this function, and replace all generic stream calls
with stream_dvd.c internal ones. This also affects stream->pos (now a
random number as far as stream_dvd.c is concerned) and stream_skip().
|
| |
|
|
| |
It did nothing; the real check is in push.c.
|
| |
|
|
|
| |
Set a zero sized input region for the osd surfaces in order to avoid getting
input for the subsurfaces which might dissapear any time.
|
| | |
|
