Commit Graph

1241 Commits

Author SHA1 Message Date
wm4 c3f93f5fdd sws_utils: use zimg by default if available
This seems stable enough to use. Change the default, and remove it from
the sw-fast profile.
2020-02-12 18:06:53 +01:00
Philip Langdale 6799f8e0e9 bash completion: complete ao/af/vo/vf options
I didn't handle these originally, but it turns out that they can be
handled with the samel logic as Choice options.
2020-02-08 09:50:58 -08:00
Philip Langdale 8676f4616c bash completion: Cache the options list
The bash completion seems to be working decently at this point, so I
feel comfortable caching the options output to improve the performance
of the completion.
2020-02-08 09:50:58 -08:00
der richter 77d42d5532 input: add new PLAYONLY and PAUSEONLY MP_KEY key codes
since the old PLAY and PAUSE key codes cycle through the pause property,
the new key codes only explicitly set the pause property.
2020-01-26 12:09:55 +01:00
Philip Langdale 3259494d9e bash completion: only generate option list when needed
Right now we are generating the fully option list before doing
anything else. That makes filename completion significantly slower
than it was before, for no gain. It's easy to only generate the
option list when it's actually needed.

I also know I could additionally cache the option list across
invocations, but I'm not doing that yet to make testing easier.
2020-01-13 17:12:25 -08:00
Philip Langdale 8b85b40b2f bash completion: add initial implementation of bash completion
While we've had a zsh completion script for a while, we haven't had
one for bash. This one is reasonably comprehensive, although there are
improvements one could imagine for certain options.
2020-01-09 12:07:05 -08:00
der richter 8a6ee7fe94 mac: remove Apple Remote support
the Apple Remote has long been deprecated and abandoned by Apple.
current macs don't come with support for it anymore. support might be
re-added with the next commit.
2019-12-15 20:07:31 +01:00
Philip Sequeira a6cb92c74a zsh completion: fix handling of aliases that are listed without --
Pretty sure they used to all have --, but I guess it was changed at some
point. More incentive to do this completion stuff in a more structured
way.
2019-12-15 14:17:00 +01:00
Philip Sequeira 0198bc13a1 zsh completion: use actual POSIX-compatible regex for whitespace
\s and \S aren't actually part of the spec, but it seems glibc supports
them anyway so I didn't notice when originally testing. This fixes the
script on Apple's libc and probably others that adhere more closely to
the spec.

The most direct replacement for \s would have been [[:space:]], but we
only expect to see spaces and tabs, so might as well just do that. Also
could have used [[:blank:]], which is basically a locale-aware version
of [ \t], but mpv isn't going to output anything but ASCII spaces and
tabs, so let's avoid unnecessary complexity and stick with the ASCII
literals.
2019-12-15 14:17:00 +01:00
Philip Sequeira a921c0628e zsh completion: actually make pcre optional
It was supposed to be optional already, but I misunderstood how the
re_match_pcre option worked. If it's set, it will try to use PCRE
matching whether it's available or not (and blow up if it's not). So,
first try to load the module it'll use, and only set the option if that
works.

Fixes #7240.
2019-12-15 14:17:00 +01:00
James Ross-Gowan b3b2cc44fa console.lua: add this script
Merged from mpv-repl git repo commit 5ea2bf64f9c239f0326b02. Some
changes were made on top of it:

- Tabs were converted to 4 spaces indentation (plus some manual
  indentation fixes in some places).
- All user-visible mentions of "repl" were renamed to "console".
- The README was converted to a manpage (with heavy changes, some
  additions taken from stats.rst; rossy converted the key bindings
  table to RST).
- The method to change the default key binding was changed.
- Change minor detail about "font" default value setting (not a
  functional change).
- Integrate into the player as builtin script, including an option to
  prevent loading it.

Above changes and commit message done by wm4.

Signed-off-by: wm4 <wm4@nowhere>
2019-12-08 02:46:44 +01:00
wm4 1ab5d829ce builtin.conf: set minimal --stream-buffer-size
Some stream inputs may have higher latency with higher buffer sizes, for
example network filesystems via normal OS filesystem interface (these
have to wait until the full buffer is read, which means higher latency).
Probably doesn't matter in practice, but why take chances.
2019-11-07 22:53:13 +01:00
wm4 00838fe0c3 zimg: make --zimg-fast=yes default
This is mostly just because of the odd RGB default gamma issue, which
shouldn't have any real impact. This also sets allow_approximate_gamma,
which I hope is fine for normal use cases.
2019-11-02 02:22:16 +01:00
wm4 a7230dfed0 sws_utils, zimg: destroy vo_x11 and vo_drm performance
Raise swscale and zimg default parameters. This restores screenshot
quality settings (maybe) unset in the commit before. Also expose some
more libswscale and zimg options.

Since these options are also used for VOs like x11 and drm, this will
make x11/drm/etc. much slower. For compensation, provide a profile that
sets the old option values: sw-fast. I'm also enabling zimg here, just
as an experiment.

The core problem is that we have a single set of command line options
which control the settings used for most swscale/zimg uses. This was
done in the previous commit. It cannot differentiate between the VOs,
which need to be realtime and may accept/require lower quality options,
and things like screenshots or vo_image, which can be slower, but should
not sacrifice quality by default.

Should this have two sets of options or something similar to do the
right thing depending on the code which calls libswscale? Maybe. Or
should I just ignore the problem, make it someone else's problem (users
who want to use software conversion VOs), provide a sub-optimal
solution, and call it a day? Definitely, sounds good, pushing to master,
goodbye.
2019-10-31 16:51:12 +01:00
Cameron Cawley 619b466cef input: Add default bindings for MBTN_BACK and MBTN_FORWARD 2019-10-28 17:14:49 +01:00
wm4 4a82349900 input: disable gamepad code by default
Enabling this by default probably causes a number of issues, such as
breaking vo_sdl, or reacting to various input devices while the window
is not focused. It's also pretty obscure, or at least new. Disable it by
default.
2019-10-25 21:54:35 +02:00
Stefano Pigozzi 899e0bd16b input: add gamepad support through SDL2
The code is very basic:

- only handles gamepads, could be extended for generic joysticks in the
  future.
- only has button mappings for controllers natively supported by SDL2.
  I heard more can be added through env vars, there's also ways to load
  mappings from text files, but I'd rather not go there yet. Common ones
  like Dualshock are supported natively.
- analog buttons (TRIGGER and AXIS) are mapped to discrete buttons using an
  activation threshold.
- only supports one gamepad at a time. the feature is intented to use
  gamepads as evolved remote controls, not play multiplayer games in mpv :)
2019-10-23 09:40:30 +02:00
wm4 f0f1387145 etc/mpv.conf: update outdated use of cache options
The --cache option does not take a number anymore. (Oh boy, this is
going to break a lot of user configs?)

The cache site is now configured with those obscure-sounding --demuxer
options.

--cache-secs is not useful anymore. The default is very high, so the
obscure-sounding --demuxer options determine how much is cached.

Advertise the --cache-on-disk option a bit. I found it useful once, and
it will trick users into wearing out their SSD for no gain, or so.
2019-10-14 18:32:58 +02:00
Niklas Haas cb95ce75b5 options: rename --video-aspect to --video-aspect-override
The justification for this is the fact that the `video-aspect` property
doesn't work well with `cycle_values` commands that include the value
"-1".

The "video-aspect" property has effectively no change in behavior, but
we may want to make it read-only in the future. I think it's probably
fine to leave as-is, though.

Fixes #6068.
2019-10-04 21:34:22 +02:00
Philip Sequeira 2712db8238 zsh completion: move generation to runtime and improve
The completion function itself now parses --list-options on the first
tab press and caches the results. This does mean a slight delay on that
first tab press, but it will only do this if the argument being
completed looks like an option (i.e. starts with "-"), so there is never
a delay when just completing a file name. I've also put some effort into
making it reasonably fast; on my machine it's consistently under 100 ms,
more than half of which is mpv itself.

Installation of zsh completion is now done unconditionally because it's
nothing more than copying a file. If you really don't want it installed,
set zshdir to empty: `./waf configure --zshdir= ...`

Improvements in functionality compared to the old script:

 * Produces the right results for mpv binaries other than the one it was
   installed with (like a dev build for testing changes).

 * Does not require running mpv at build time, so it won't cause
   problems with cross compilation.

 * Handles aliases.

 * Slightly nicer handling of options that take comma-separated values
   and/or sub-options: A space is now inserted at the end instead of a
   comma, allowing you to immediately start typing the next argument,
   but typing a comma will still remove the automatically added space,
   and = and : will now do that too, so you can immediately add a
   sub-option.

 * More general/flexible handling of values for options that print their
   possible values with --option=help. The code as is could handle quite
   a few more options (*scale, demuxers, decoders, ...), but nobody
   wants to maintain that list here so we'll just stick with what the
   old completion script already did.
2019-09-27 13:19:29 +02:00
wm4 ad20f808af builtin.conf: add clarifications
Just in case a confused user or developer finds this file and wonders
why it's "incomplete".
2019-09-19 20:37:05 +02:00
sfan5 7c565547b8 docs: add removed properties and options to interface-changes.rst 2018-12-06 19:14:14 +01:00
Anton Kindestam 8b83c89966 Merge commit '559a400ac36e75a8d73ba263fd7fa6736df1c2da' into wm4-commits--merge-edition
This bumps libmpv version to 1.103
2018-12-05 19:19:24 +01:00
Niklas Haas 7ad60a7c5e vo_gpu: split --linear-scaling into two separate options
Since linear downscaling makes sense to handle independently from
linear/sigmoid upscaling, we split this option up. Now,
linear-downscaling is its own option that only controls linearization
when downscaling and nothing more. Likewise, linear-upscaling /
sigmoid-upscaling are two mutually exclusive options (the latter
overriding the former) that apply only to upscaling and no longer
implicitly enable linear light downscaling as well.

The old behavior was very confusing, as evidenced by issues such
as #6213. The current behavior should make much more sense, and only
minimally breaks backwards compatibility (since using linear-scaling
directly was very uncommon - most users got this for free as part of
gpu-hq and relied only on that).

Closes #6213.
2018-10-19 22:58:01 +02:00
wm4 a4321cf687 screenshot: change async behavior to be in line with new semantics
Basically reimplement the async behavior on top of the async command
code. With this, all screenshot commands are async, and the "async"
prefix basically does nothing. The prefix now behaves exactly like with
other commands that use spawn_thread.

This also means using the prefix in the preset input.conf is pointless
(without effect) and misleading, so remove that.

The each_frame mode was actually particularly painful in making this
change, since the player wants to block for it when writing a
screenshot, and generally doesn't fit into the new infrastructure. It
was still relatively easy to reimplement by copying the original command
and then repeating it on each frame. The waiting is reentrant now, so
move the call in video.c to a "safer" spot.

One way to observe how the new semantics interact with everything is
using the mpv repl script and sending a screenshot command through it.
Without async flag, the script will freeze while writing the screenshot
(while playback continues), while with async flag it continues.
2018-05-24 19:56:34 +02:00
TheAMM a469554594 encode: remove removed encode options from presets 2018-05-03 01:09:46 +03:00
wm4 6c8362ef54 encode: rewrite half of it
The main change is that we wait with opening the muxer ("writing
headers") until we have data from all streams. This fixes race
conditions at init due to broken assumptions in the old code.

This also changes a lot of other stuff. I found and fixed a few API
violations (often things for which better mechanisms were invented, and
the old ones are not valid anymore). I try to get away from the public
mutex and shared fields in encode_lavc_context. For now it's still
needed for some timestamp-related fields, but most are gone. It also
removes some bad code duplication between audio and video paths.
2018-04-29 02:21:32 +03:00
wm4 f2b026f941 encoding: deprecate a bunch of obscure options
--audio-delay does not work correctly yet, but hopefully this can be
fixed later.
2018-04-20 12:37:15 +02:00
emersion a04ac8204f
mpv.desktop: fix French translation consistency
This makes the French version consistent with the English one.
2018-03-18 23:01:53 +00:00
wm4 496b13227b input: minor additions to default key bindings
This adds key bindings for some semi-popular features. It also tries to
cleanup some old bindings. For example w/e for panscan is now changed to
w/W. In all cases, the old bindings are still kept and work, though.

Part of an ongoing attempt to cleanup the default key bindings.
See #973 for some context.
2018-03-04 16:27:49 -08:00
wm4 775b86212d video: add option to reduce latency by 1 or 2 frames
The playback start logic explicitly waits until the first frame has been
displayed. Usually this will introduce a wait of 1 vsync. For normal
playback this doesn't matter, but with respect to low latency needs,
this only leads to additional data getting queued up in the demuxer or
network buffers.

Another thing is that the timing logic decodes 1 frame ahead (= 1 frame
extra latency) to determine the exact duration of a frame.

To be fair, there doesn't really seem to be a hard reason why this is
needed. With the current code, enabling the option does lead to A/V
desync sometimes (if the demuxer FPS is too inaccurate), and also frame
drops at playback start in some situations. But this all seems to be
avoidable, if the timing logic were to be rewritten completely, which
should probably happen in the future. Thus the new option comes with the
warning that it can be removed any time. This is also why the option has
"hack" in the name.
2018-03-03 02:38:01 +02:00
wm4 8288fa6978 options: add a builtin low-latency profile
Well I guess it doesn't help that much.

Also add some stuff that might help to the manpage.

The fundamental problem with some "live" sources (e.g. x11grab) is
actually that the player gets behind initially, and never thinks it has
to catch up. This is also why --untimed can help.
2018-03-03 02:38:01 +02:00
wm4 d6890c19dd input: add a keybinding to toggle hardware decoding
We sure as hell won't enable hardware decoding by default, but we can
make it more accessible with a key binding.
2018-02-13 17:45:29 -08:00
wm4 196950e905 input.conf: use exact value for [ binding
This is supposed to undo the ] binding. This uses a value closer to the
inverse. (Although it's not fully exact since the values are still
stored as floating point instead as fractions.)
2018-01-30 03:10:27 -08:00
sfan5 0cd501dac1 mpv.desktop: update mime type list
see https://wiki.debian.org/DebianMultimedia/PlayerSupport
2018-01-22 10:08:51 +01:00
wm4 69d062ce37 client API: remove ytdl=no default
With the recent changes to the script it does not incur a startup delay
by default due to starting youtube-dl and waiting for it. This was the
main reason for making libmpv have a different default.

Starting sub processes from a library can still be a bit fishy, but I
think it's ok. Still mention it in the libmpv header. There were already
other cases where libmpv would start its own processes, such as the X11
backend calling xdg-screensaver. (The reason why this is fishy is
because UNIX process management sucks: SIGCHLD and the wait() syscall
make sub processes non-transparent and could potentially introduce
conflicts with code trying to use them.)
2018-01-13 03:26:45 -08:00
wm4 d690ee0959 client API: change --stop-playback-on-init-failure default
This was off for mpv CLI, but on for libmpv. The motivation behind this
was that it would be confusing for applications if libmpv continued
playback in a severely "degraded" way (without either audio or video),
and that it would be better to fail early.

In reality the behavior was just a confusing difference to mpv CLI, and
has confused actual users as well. Get rid of it.

Not bothering with a version bump, since this is so minor, and it's easy
to ensure compatibility in affected applications by just setting the
option explicitly.

(Also adding the missing next-release-marker in client-api-changes.rst.)
2017-12-17 15:45:24 -08:00
wm4 36630585f6 osc: make cycling visibility an input.conf key binding
As builtin script, it should not register global key bindings, and add
them to input.conf instead. This is similar to what stats.lua does.
2017-11-03 14:41:18 +01:00
James Ross-Gowan 23da3ed21a restore-old-bindings.conf: add old macOS/Wayland AXIS bindings
These were changed in 7897f79217 to match X11 and Windows.
2017-10-16 22:51:12 +11:00
Julian 57654cc19e input.conf: explicit bindings for stats overlay 2017-10-13 00:28:41 +02:00
Niklas Haas 65979986a9 vo_opengl: refactor into vo_gpu
This is done in several steps:

1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
   (note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
   it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
   ra itself (and vo_gpu altered to compensate), but this was a stop-gap
   measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten

Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.

Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.

Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-21 15:00:55 +02:00
James Ross-Gowan 7897f79217 input: merge mouse wheel and axis keycodes
Mouse wheel bindings have always been a cause of user confusion.
Previously, on Wayland and macOS, precise touchpads would generate AXIS
keycodes and notched mouse wheels would generate mouse button keycodes.
On Windows, both types of device would generate AXIS keycodes and on
X11, both types of device would generate mouse button keycodes. This
made it pretty difficult for users to modify their mouse-wheel bindings,
since it differed between platforms and in some cases, between devices.

To make it more confusing, the keycodes used on Windows were changed in
18a45a42d5 without a deprecation period or adequate communication to
users.

This change aims to make mouse wheel binds less confusing. Both the
mouse button and AXIS keycodes are now deprecated aliases of the new
WHEEL keycodes. This will technically break input configs on Wayland and
macOS that assign different commands to precise and non-precise scroll
events, but this is probably uncommon (if anyone does it at all) and I
think it's a fair tradeoff for finally fixing mouse wheel-related
confusion on other platforms.
2017-09-03 20:31:44 +10:00
James Ross-Gowan 957e9a37db input: use mnemonic names for mouse buttons
mpv's mouse button numbering is based on X11 button numbering, which
allows for an arbitrary number of buttons and includes mouse wheel input
as buttons 3-6. This button numbering was used throughout the codebase
and exposed in input.conf, and it was difficult to remember which
physical button each number actually referred to and which referred to
the scroll wheel.

In practice, PC mice only have between two and five buttons and one or
two scroll wheel axes, which are more or less in the same location and
have more or less the same function. This allows us to use names to
refer to the buttons instead of numbers, which makes input.conf syntax a
lot easier to remember. It also makes the syntax robust to changes in
mpv's underlying numbering. The old MOUSE_BTNx names are still
understood as deprecated aliases of the named buttons.

This changes both the input.conf syntax and the MP_MOUSE_BTNx symbols in
the codebase, since I think both would benefit from using names over
numbers, especially since some platforms don't use X11 button numbering
and handle different mouse buttons in different windowing system events.

This also makes the names shorter, since otherwise they would be pretty
long, and it removes the high-numbered MOUSE_BTNx_DBL names, since they
weren't used.

Names are the same as used in Qt:
https://doc.qt.io/qt-5/qt.html#MouseButton-enum
2017-09-03 20:31:44 +10:00
Ricardo Constantino 4a2f268f67
etc/encoding_profiles: remove deprecated usage of *-add 2017-07-03 13:47:33 +01:00
Xu Zhao 1097c1416f x11: add 128x128 sized icon support 2017-07-02 13:07:36 +02:00
wm4 24b2d672ee input.conf: drop TV/DVB bindings
Is anyone still using them? Well, I'm removing them anyway.
2017-06-27 11:04:30 +02:00
wm4 d8ad8ae015 etc/encoding-profiles.conf: use new option syntax
This is only for the comments, but since the old syntax is "discouraged"
(and might change semantics one day), we should use the new syntax in
all documentation-like things.
2017-06-25 19:02:24 +02:00
Ricardo Constantino 72ef74dab5
encoding-profiles: remove useless noformat vf from enc-v-h264
Instead, add instructions on how to properly restrict output video
to a relatively compatible profile/level.
2017-06-25 14:36:10 +01:00
Ricardo Constantino 3e49133a25
etc/encoding-profiles: use correct formats for noformat
These alias were removed in 937dcc25a.
2017-06-21 21:28:35 +01:00
wm4 2e84934be7 input: change license to LGPL
cehoyos adds the step_property command in 7a71da01d, and it could be
argued that copyright of this still applies to the later add/cycle
commands (a668ae0ff9). While I'm not sure if this is really the case,
stay conservative for now and mark these commands as GPL-only. Mark the
command.c code too, although that is not being relicensed yet.

I'm leaving the MP_CMD_* enum items, as they are obviously different.

In commit 116ca0c768, "veal" (essentially an anonymous author) adds an
"osd_show_property_text" command (well, the commit message says "based
on" that person's code, so it's not clear how much is from him or from
albeu, who agreed to LGPL). This was later merged again with the
"osd_show_text" command, and then all original code was removed in
commit 58cc0f637f, so I claim that no copyright applies anymore. (Though
technically the input.conf addition still might be copyrighted, so I'm
just dropping it to get rid of the thought.)

"kiriuja" added 2f376d1b39 (sub_load etc.) and be54f4813 (switch_audio).
The latter is gone. I would argue that the former is fully rewritten
with commits b7052b431c and 0f155921b0. But like in the step_property
case, I will be overly conservative for now, and mark them as GPL-only,
as this is potentially shaky and should be thought through first. (Not
bothering with the command define/enum in the header, as it will be
unused in LGPL mode anyway.)

keycodes.c/h can be GPL, except for commit 2b1f95dcc2, which is a
patch by someone who wasn't asked yet. Before doing something radical, I
will wait for a reply.
2017-06-19 13:28:19 +02:00