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.
This might be helpful if we ever want cascading config files. Also, we
will probably need it if we change the default input.conf bindings, and
want to provide compatibility input.conf files.
This is probably useful.
Note that this includes a small, stupid hack to prevent loading of the
config file if vf_lavfi is not available. The profile by default uses
vf_lavfi, and the config parser will output errors if vf_lavfi is not
available.
As another caveat, we install the example profile even if encoding is
disabled (though we don't load it, since this would print errors).
Currently KDE will copy a media file into a temporary folder instead of
trying to stream it if a KIO slave location file is started. This change
will tell KDE to make mpv try to directly play the file. Perhaps the
proper flags should be added according to the individual enabled
features of the build but I suggest that be for the future.
Signed-off-by: wm4 <wm4@nowhere>
This readds a more or less completely new dvdnav implementation, though
it's based on the code from before commit 41fbcee. Note that this is
rather basic, and might be broken or not quite usable in many cases.
Most importantly, navigation highlights are not correctly implemented.
This would require changes in the FFmpeg dvdsub decoder (to apply a
different internal CLUT), so supporting it is not really possible right
now. And in fact, I don't think I ever want to support it, because it's
a very small gain for a lot of work. Instead, mpv will display fake
highlights, which are an approximate bounding box around the real
highlights.
Some things like mouse input or switching audio/subtitles stream using
the dvdnav VM are not supported.
Might be quite fragile on transitions: if dvdnav initiates a transition,
and doesn't give us enough mpeg data to initialize video playback, the
player will just quit.
This is added only because some users seem to want it. I don't intend to
make mpv a good DVD player, so the very basic minimum will have to do.
How about you just convert your DVD to proper video files?
The mpv.desktop file is taken from the Arch package [1]. It appears to
be based on the mplayer2 git mplayer.desktop file (e.g. very similar
MimeType field), with minor modifications applied by Arch package
maintainers.
Note that for now, this doesn't show a terminal (Terminal=false), which
might not always be ideal. For example, if the file is audio only, or
if VO initialization fails for some reason, mpv will run in the
background and play audio without showing a window. But users prefer
running it without terminal, and don't want to play audio files with
it.
Maybe a --force-window option will be added in the future, which would
always create a VO window, and compensate for these issues.
[1] https://aur.archlinux.org/packages/mpv-git/
Remove options which are too obscure and most likely not very useful in
general, or update them to something more modern. Add some comments
about how configuration files work in general.
This affects MOUSE_MOVE and MOUSE_LEAVE. Both are needed internally
(such as for the OSC), but not really useful for input.conf. Since the
warning has the purpose of notifying the user that a key is unmapped and
what key name to use for setting up a binding in input.conf, the warning
is rather useless in this case. It's also annoying in combination with
the
--no-input-default-bindings option, since that removes the default
bindings to "ignore" for these keys.
The png file added to etc/ are taken from the link mentioned in commit
303096b, except that they have been converted to 16 bit, sRGB (with
color profile info dropped, if there was one), and transparent pixels
reset for better compression.
The file x11_icon.bin is generated by gen-x11-icon.sh. I'm adding it to
the git repo directly, because the script requires ImageMagick, and we
don't want to make building even more complicated.
The way how this is done is basically a compromise between effort
required in x11_common.c and in gen-x11-icon.sh. Ideally, x11_icon.bin
would be directly in the format as required by _NET_WM_ICON, but trying
to write the binary width/height values from shell would probably be a
nightmare, so here we go.
The zlib code in x11_common.c is lifted from demux_mkv.c, with some
modifications (like accepting a gzip header, because I don't know how to
make gzip write raw compressed data).
I suspect most users will just copy etc/input.conf when they want to
remap some default bindings. But usually this means the user even copies
bindings he doesn't care about, and it's better if the user maps only
the bindings in his input.conf the user intends to remap.
Comment all bindings in etc/input.conf. Since this file also defines the
builtin defaults and is baked into the mpv binary, we have to do
something to get them anyway, even though they are commented. Do this by
having input.c "uncomment" the bindings in the baked in input.conf. (Of
course this is done only for the builtin config, not configs loaded from
disk.)
I would like to thank Chris Ward (@tenzerothree, http://tenzerothree.com/) for
working on the art for these icons and bringing some eye candy to the project.
The PSDs made by Chris are available on our Dropbox [1], along with the exports
I made to create OSX and Windows icons. The PSDs are almost completly vector
and all the resolutions look really similar, except the 16px favicon which was
handcrafted to look better and more recognizeable on the smaller pixel budget.
For Mac OS X the icons were created using iconutils on the PNGs iconsets
exported from the PSDs. These even support retina resolutions (except 512@2x).
For Windows the .ico file was created with imagemagick. The included images
are 16px, 24px, 32px, 48px 64px, 256px. These are the resolutions listed on
MSDN for supporting Windows XP [2] and Windows versions based on Aero [3].
Only 32bit PNGs were used since it is 2013.
For Linux nothing changed yet, even though @wm4 talked about using the PNGs
directly there. This will probably be dealt with in a later commit.
[1]: https://www.dropbox.com/sh/yelfoj9tbft7o06/A8vOT6JKaG
[2]: http://msdn.microsoft.com/en-us/library/ms997636.aspx
[3]: http://msdn.microsoft.com/en-us/library/aa511280.aspx
Change how the HW decoding stuff is organized, the way it's initialized
in particular. Instead of duplicating the list of supported codecs for
hwaccel decoders, add a probe function which allows each decoder to
report whether it supports a given codec.
Add an "auto" choice to the --hwdec option, which automatically enables
hardware decoding if libavcodec and/or the VO supports it.
What mpv prints on the terminal changes a bit. Now it will just print
a single line whether hw decoding is used or not (and nothing at all if
no hw decoding at all was requested). The pretty violent fallback from
hw decoding to software decoding is still quite verbose and evil-looking
though.
Support horizontal and vertical axes of input devices.
If the input device support precise scrolling with an input value then it
should first be scaled to a standard multiplier, where 1.0 is the default.
The multiplier will then applied to the following commands if possible:
* MP_CMD_SEEK
* MP_CMD_SPEED_MULT
* MP_CMD_ADD
All other commands will triggered on every axis event, without change the
values specified in the config file.
This slightly increases file size due to needless downscaling on the device due
to aspect correction, but keeps quality as is and prevents encoding errors
caused by odd height/width.
Also, implement mouse leave events for X11. But evne on other
platforms, these events will be generated if mouse crosses a section's
mouse area boundaries within the mpv window.
Before this commit, mouse movement events emitted a special command
("set_mouse_pos"), which was specially handled in command.c. This was
once special-cased to the dvdnav and menu code, and did nothing after
libmenu and dvdnav were removed.
Change it so that mouse movement triggers a pseudo-key ("MOUSE_MOVE"),
which then can be bound to an arbitrary command. The mouse position is
now managed in input.c. A command which actually needs the mouse
position can use either mp_input_get_mouse_pos() or mp_get_osd_mouse_pos()
to query it. The former returns raw window-space coordinates, while the
latter returns coordinates transformed to OSD- space. (Both are the same
for most VOs, except vo_xv and vo_x11, which can't render OSD in
window-space. These require extra code for mapping mouse position.)
As of this commit, there is still nothing that uses mouse movement, so
MOUSE_MOVE is mapped to "ignore" to silence warnings when moving the
mouse (much like MOUSE_BTN0).
Extend the concept of input sections. Allow multiple sections to be
active at once, and organize them as stack. Bindings from the top of
the stack are preferred to lower ones.
Each section has a mouse input section associated, inside which mouse
events are associated with the bindings. If the mouse pointer is
outside of a section's mouse area, mouse events will be dispatched to
an input section lower on the stack of active sections. This is intended
for scripting, which is to be added later. Two scripts could occupy
different areas of the screen without conflicting with each other. (If
it turns out that this mechanism is useless, we'll just remove it
again.)
This adds support for libquvi 0.9.x, and these features:
- start time (part of youtube URL)
- youtube subtitles
- alternative source switching ('l' and 'L' keys)
- youtube playlists
Note that libquvi 0.9 is still in development. Although this seems to
be API stable now, it looks like there will be a 1.0 release, which is
supposed to be the next stable release and the actual successor of
libquvi 0.4.x.
This commit addresses some issues with the users had with the previous
implementation in commit c39efb9. Here's the changes:
* Use Quartz Event Taps to remove Media Key events mpv handles from
the global OS X queue. This prevents conflicts with iTunes. I did this on
the main thread since it is mostly idling. It's the playloop thread that
actually does all the work so there is no danger of blocking the event tap
callback.
* Introduce `--no-media-keys` switch so that users can disable all of mpv's
media key handling at runtime (some prefer iTunes for example).
* Use mpv's bindings so that users can customize what the media keys do via
input.conf. Current bindings are:
MK_PLAY cycle pause
MK_PREV playlist_prev
MK_NEXT playlist_next
An additional benefit of this implementation is that it is completly handled
by the `macosx_events` file instead of `macosx_application` making the
project organization more straightforward.
After killing the non functional AR support in c8fd9e5 I got much complaints so
this adds AR support back in (and it works). I am using the HIDRemote class by
Felix Schwarz and that part of the code is under the BSD license. I slightly
modified it replacing [NSApplication sharedApplication] with NSApp. The code
of the class is quite complex (probably because it had to deal with all the
edge cases with IOKit) but it works nicely as a black box.
In a later commit I'll remove the deprecation warnings caused by HIDRemote's
usage of Gestalt.
Check out `etc/input.conf` for the default bindings.
Apple Remote functionality is automatically compiled in when cocoa is enabled.
It can be disabled at runtime with the `--no-ar` option.
A "watch later" command is now mapped to Shift+Q. This quits the player
and stores the playback state in a config file in ~/.mpv/watch_later/.
When calling the player with the same file again, playback is resumed
at that time position.
It's also possible to make mpv save playback state always on quit with
the --save-position-on-quit option. Likewise, resuming can be disabled
with the --no-resume-playback option.
This also attempts to save some playback parameters, like fullscreen
state or track selection. This will unconditionally override config
settings and command line options (which is probably not what you would
expect, but in general nobody will really care about this). Some things
are not backed up, because that would cause various problems. Additional
subtitle files, video filters, etc. are not stored because that would be
too hard and fragile. Volume/mute state are not stored because it would
mess up if the system mixer is used, or if the system mixer was
readjusted in the meantime.
Basically, the tradeoff between perfect state restoration and
complexity/fragility makes it not worth to attempt to implement
it perfectly, even if the result is a little bit inconsistent.
Allows stepping back one frame via the frame_back_step inout command,
bound to "," by default.
This uses the precise seeking facility, and a perfect frame index built
on the fly. The index is built during playback and precise seeking, and
contains (as of this commit) the last 100 displayed or skipped frames.
This index is used to find the PTS of the previous frame, which is then
used as target for a precise seek. If no PTS is found, the core attempts
to do a seek before the current frame, and skip decoded frames until the
current frame is reached; this will create a sufficient index and the
normal backstep algorithm can be applied.
This can be rather slow. The worst case for backstepping is about the
same as the worst case for precise seeking if the previous frame can be
deduced from the index. If not, the worst case will be twice as slow.
There's also some minor danger that the index is incorrect in case
framedropping is involved. For framedropping due to --framedrop, this
problem is ignored (use of --framedrop is discouraged anyway). For
framedropping during precise seeking (done to make it faster), we try
to not add frames to the index that are produced when this can happen.
I'm not sure how well that works (or if the logic is sane), and it's
sure to break with some video filters. In the worst case, backstepping
might silently skip frames if you backstep after a user-initiated
precise seek. (Precise seeks to do indexing are not affected.)
Likewise, video filters that somehow change timing of frames and do not
do this in a deterministic way (i.e. if you seek to a position, frames
with different timings are produced than when the position is reached
during normal playback) will make backstepping silently jump to the
wrong frame. Enabling/disabling filters during playback (like for
example deinterlacing) will have similar bad effects.
