summaryrefslogtreecommitdiffstats
path: root/player/lua
<
Commit message (Collapse)AuthorAgeFilesLines
* command: change "window-scale" property behaviorwm42019-12-161-1/+1
| | | | | | | | | This is similar to the "edition" change. I considered making this go through deprecation, but didn't have a good idea how to do that. Maybe it's fine, because this is pretty obscure. But it might break some API users/scripts (it certainly broke stats.lua), and all I have to say is sorry for that.
* osc: set the wrap style for the title shown with window controlsPhilip Langdale2019-12-121-1/+1
| | | | | | I missed adding this when defining the style used for the video title in the window control bar. The default behaviour is to wrap, but we want to cut the title off when we run out of space.
* osc: use custom symbols for window controlsPhilip Langdale2019-12-111-10/+26
| | | | | | | | | | | | | | | | | | | | | | | | I was recently informed that unicode has official symbols for window controls, and I put together a change to use them, which worked, as long as a suitable font was installed. However, it's not that hard to get a normal system that lacks an appropriate font, and libass wants to print warnings if the symbols aren't in the default font, which will almost always be true. So, I gave up and added the symbols to the custom osd font that we already have. This ensures they are always available, and that they are aligned consistently on all platforms. I took the symbols from the `symbola` font, as this has a suitable licence and the symbols look nice enough. Symbola Licence: Fonts are free for any use; they may be opened, edited, modified, regenerated, packaged and redistributed. Finally, as we now have access to an un-maximize symbol, I added logic to use it when the window is maximized.
* osc: explicitly re-init the osc on a change in border visibilityPhilip Langdale2019-12-091-0/+1
| | | | | | | | | | | | | | I had previously wondered whether to do this, but in my testing with x11 and wayland, the osc was being re-inited on a border toggle already so I didn't add it. However, on win32, things are different and there is no re-init when toggling borders. I belive this is because the active window size doesn't change in anyway, while on x11/wayland, toggling the border actually changes the window size - and that trigger a re-init. So, let's just be explicit and request a re-init when the border is toggled.
* console.lua: add this scriptJames Ross-Gowan2019-12-081-0/+701
| | | | | | | | | | | | | | | | | | | | | 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>
* lua: make later key bindings always have higher prioritywm42019-12-071-2/+13
| | | | | | | | | | | | | | | | | | | Later calls to mp.add_key_binding() should take priority over previous calls with the same key. Until now, the order was random (due to using table pairs() iteration order). Do this by simply sorting by a counter that is never reset. Since input.c also gives later bindings priority, this works out. Calling mp.remove_key_binding() on a newer binding makes an older still existing binding with the same key active again. New bindings override older ones, but do not overwrite them. I think these are good semantics for most use cases. (Note that the Lua code cannot determine whether two bindings use the same key. Keys are strings, and two different strings could refer to the same key. The code does not have access to input.c's key name normalization, so it cannot compare them.)
* osc: rework window control configuration to add auto modePhilip Langdale2019-12-041-17/+46
| | | | | | | | | | | | | | | | To aid in discoverability, and to address the most common case directly, I'm adding an 'auto' mode for the window controls. In this case, we will show the controls if there is no window border and hide them if there are borders. This also respects the option being toggled at runtime. To ensure that it works in the wayland case, I've also made sure that the wayland code explicitly forces the option to false if decoration support is missing. Based on feedback, I've split the config in two, with one option for whether controls are active, and one for alignment. These are new enough that we can get away with ignoring compatibility.
* osc: ensure that window control show/hide zone is handled dynamicallyPhilip Langdale2019-12-041-6/+6
| | | | | | | | | | | | | | | | | | | As preparation for adding the auto mode for window controls, we need to make sure that the controls can be successfully toggled at runtime, rather than only being able to configure them once at startup. Right now, there is a problem with the handling of the show/hide zone for the window controls. The previous fix for #7212 was to avoid registering the input mapping for the window control show/hide zone. If there is no input mapping, then there is no input, and the zone is a no-op, even if it exists. But this only happens at startup. After that point, the input mapping doesn't exist and cannot be turned on. In this change, I'm switching the approach; we now go back to always registering the input mapping, and instead, we zero out the show/hide zone if window controls are disabled, and set its size appropriately if they are enabled.
* osc: don't show error if windowcontrols=yesPhilip Langdale2019-12-021-1/+2
| | | | | | | | I always intended for this to be accepted and mean "right" but I made it show an error for any value that's not explicitly recognised (while considering all unrecognised values to mean "right"). So let's explicitly recognise "yes".
* osc: don't always set window control keybindingsDudemanguy2019-12-011-4/+6
| | | | | Only set the window control keybindings if the window control option is actually enabled. Fixes #7212.
* osc: ensure the window-controls mouse area is initially zero sizedPhilip Langdale2019-11-301-0/+1
| | | | | | This is necessary to avoid breaking input behaviour in the 'idle' state when not playing a video. Otherwise, the mouse area starts off covering the whole window and blocks normal input.
* lua: unbreak mp.add_key_binding(key, fn)Avi Halachmi (:avih)2019-11-301-1/+1
| | | | | | | Commit 311cc5b6 added the ability use flags while omitting name, but broke the case where both name and flags are omitted. Now omitting either name or flags or both works as documented.
* osc: fix typo wsc_geo -> wc_geoPhilip Langdale2019-11-301-1/+1
|
* osc: apply boxvideo margins to the window controlsPhilip Langdale2019-11-301-0/+3
| | | | | | It seems logical to account for the window controls if `boxvideo` is in use (which has the effect of reducing the size of the video so that the osc is not covering the video).
* osc: fix operation when window controls are disabledwm42019-11-291-2/+4
| | | | | It seems this area is simply not defined when window controls are disabled, so ipairs() will crash on it.
* osc: handle deadzone and barmargin for window controlsPhilip Langdale2019-11-291-6/+28
| | | | | | | | | | | | | | | | I missed these due to only testing with my personal osc config. The deadzone needs to be correctly handled for the window controls, or they will fail to appear when the mouse is close to or over them. In the process of doing that, I realised that the controls should respect the barmargin, if set. This is because the controls should remain aligned when layout=topbar and as the control bar is top aligned, it should be equally affected if the user needs to set the barmargin. I also fixed a mistake in trying to the use the mpv-osd-symbols font for the window controls.
* osc: implement pseudo client side decorations via OSCPhilip Langdale2019-11-291-7/+145
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Today, if window decorations are not present, either because they were disabled, or because the platform doesn't support them (eg: gnome-shell on wayland), there are no window controls, meaning it is not possible to minimize/maximize/close a window without knowing keyboard shortcuts. While you can imagine various ways of offering client side decorations, it is attractive to consider using OSC because that is functionality that we already have. The main work here is defining a separate input area from the main OSC box with its own buttons, etc. While we could probably handle auto-detection based on whether decorations are present or not, it's manually controlled for now. The window control logic is mostly disconnected from the OSC itself, except in the case of the `topbar` layout, where there has to be coordination so that the controls don't get drawn on top of each other. I had to do fine-positioning of the buttons based on the font on my system, so don't be surprised if it looks wrong elsewhere. You could also argue that window controls should be unscaled, even if the main OSC box is scaled, but I've not tried to do this.
* lua: make add_key_binding() rotate optional arguments correctlywm42019-11-231-1/+5
| | | | | | | | add_key_binding() makes the name argument optional (in weird Lua fashion), which did not work if there were additional arguments. So there is no way to avoid specifying a name while passing a rp argument. Fix this, declare this way of skipping the argument as deprecated, and allow passing name=nil as the preferred way to skip the name argument.
* input: add text produced by key to script key eventswm42019-11-221-3/+7
| | | | | | | Particularly for "any_unicode" mappings, so they don't have to special-case keys like '#' and ' ', which are normally mapped to symbolic names for input.conf reasons. (Though admittedly, this is a pretty minor thing, since API users could map these manually.)
* lua: complex key binding: use key_name like the docs sayAvi Halachmi (:avih)2019-11-201-1/+1
|
* lua: report key name for "complex" key bindingswm42019-11-191-4/+5
| | | | This might make certain use cases less of a mess.
* stats, demux: log byte level stream seekswm42019-11-071-0/+1
|
* lua: change config file loggingwm42019-11-011-2/+3
| | | | | | | | Make the existing "not found" messages debug only, and add a new verbose message if a config file was opened. The idea is that logging should make it apparent whether or not config files are loaded, and it's more common to use scripts without config files, leading to fewer log messages in verbose mode.
* osc: calculate osc_geo position after aspect correctionJan Janssen2019-10-291-6/+8
| | | Fixes #7098
* osc: Unify bottom and topbar codeJan Janssen2019-10-281-179/+31
| | | | | | Among the pointless duplication the right timecode label was given some extra space that wasn't needed. Fixes: #6904
* lua: actually unobserve properties in mp.unobserve_property()wm42019-10-241-0/+1
| | | | | | | | | Not doing this looked like a memory leak. This looks like an oversight in the commit that added it: a94020e25bc5f, possible brain damage? Fixes: #6823
* ytdl_hook: --vid=no should not ignore --ytdl-format in config filewm42019-10-241-3/+1
| | | | | | Do this only if ytdl-format was not set at all. Fixes: #6636
* ytdl_hook: check youtube-dl version if it breaksNicolas F2019-10-131-2/+32
| | | | | | | | | | | | | | | | | | Some failures by youtube-dl prompt the user to submit a bug report. If such a failure occurs, we can compare youtube-dl's version to the current calendar date to see how old it is. We don't make this check on every youtube-dl failure, as failing to extract an URL is quite common, and waiting for a second blocking python interpreter startup for every such case would be a bit unpleasant. Here the assumption is made that any youtube-dl version older than 3 months is probably severely out of date. Users will be warned about this. We also output the trimmed stderr of youtube-dl with msg.error, as this appeared to have been the behaviour of utils.subprocess without stderr capturing. Since this uses mp.command_native now, we'll have to do this ourselves where appropriate.
* player: update for --video-aspect deprecationNiklas Haas2019-10-041-2/+2
| | | | We had some dangling references to this option.
* osc: add mouse mid-button as alias to shift+left buttonRicardo Constantino2019-09-211-0/+3
|
* stats.lua: add graphs for readahead time and total byte usagewm42019-09-191-6/+58
| | | | | | | | | | | | | The readahead time should be interesting for latency vs. underruns (which idiot protocols like HLS suffer from). The total byte usage is less interesting than I hoped; maybe the frequency at which it samples should be reduced. (Kind of dumb - you want high frequency for the readahead field, but much lower for byte usage.) Of course, the code was copy&pasted from the DS ratio/jitter stuff. Some of the choices may not make any sense for the new code.
* osc: add feature to bottombar to not cover the videowm42019-09-191-1/+47
| | | | | | | | | | | | | | | | | | | | | | Normally I use the OSC like this: not at all, but have a key binding that does "cycle osc" to show it. And in that case, I don't really want it to overlap the damn video. I could use the zoom/pan options to move the video out of the way, but this is also sort of annoying. Likewise, you could write a script or so which does this automatically if the OSC appears, but that's still annoying, and computing values for these options such that the video is moved correctly is tricky. So I added a bunch of options that set explicit video borders (previous commit), and a option for the OSC to use them (this commit). Disabled by default, since I'm afraid this is too awkward and unpolished, especially with OSC default settings. I'm also using "osc-visibility=always". Effectively, making the OSC appear will box the video, and making it disappear (by unloading osc.lua) will restore the video back to normal.
* stats.lua: add cache info pagewm42019-09-191-4/+69
| | | | Uses page 3, which was apparently reserved for filter info.
* demux_edl, cue, mkv: clean up timeline stuff slightlywm42019-09-191-2/+2
| | | | | | | | | | | | | | | | | | | | | Remove the singly linked list hack, replace it with a slightly more proper data structure. This probably gets rid of a few minor bugs along the way, caused by the awkward nonsensical sharing/duplication of some fields. Another change (because I'm touching everything related to timeline anyway) is that I'm removing the special semantics for parts[num_parts]. This is now strictly out of bounds, and instead of using the start time of the next/beyond-last part, there is an end time field now. Unfortunately, this also requires touching the code for cue and mkv ordered chapters. From some superficial testing, they still seem to mostly work. One observable change is that the "no_chapters" header is per-stream now, which is arguably more correct, and getting the old behavior would require adding code to handle it as special-case, so just adjust ytdl_hook.lua to the new behavior.
* ytdl_hook: use no_clip for separate audio streamswm42019-09-191-1/+1
| | | | | | | | | | | | I noticed that some ytdl streams have a start time other than 0. There's currently no mechanism inside of the EDL stuff that determines this start time correctly, so it can happen that if the start time is high, demux_timeline.c tries to clip off the entire video and audio, resulting in failure of playback. As a counter measure, use the no_clip header, which entirely disables clipping against time ranges in demux_timeline.c. (It's basically a hack.)
* ytdl_hook: fix pseudo-DASH if no init fragment is presentwm42019-09-191-5/+11
| | | | | | | | | | | | | | Init fragments are not a necessity for DASH, but this code assumed so. Maybe the check was to prevent worse. But using normal EDL here leads to very shitty behavior where it tries to open hundreds or thousands of fragments, each with its own demuxer and HTTP connection. (This behavior is fine for normal uses of EDLs, but completely unacceptable when emulating fragmented streaming protocols. I'm not sure why the normal EDL code is needed here, but I think someone claimed some obscure sites just need it.) This happens in the same situation as the one described in the previous commit.
* ytdl_hook: audio can use fragmented DASH toowm42019-09-191-1/+1
| | | | | | | | | | | | | | Otherwise we'd just use the base URL as media URL, which would fail with a 404 error. Not sure if there's a deeper reason why the audio path was explicitly different from the video one. But this actually works now for a video that returned fragmented DASH audio with the default format selection. (This affects streams on that well known site of a big evil Silicon Valley company. Typically happens after live stream gets converted to a normal video, though after some time passes, this fragmented version is deleted, and replaced by a non-fragmented one. I've observed this several times and this seems to be the "normal" behavior.)
* ytdl_hook: disable EDL-generated useless chapters when merging streamswm42019-09-191-1/+2
| | | | (Yes, a bit odd how this header is needed only for the first stream.)
* ytdl_hook: merge separate audio tracks via EDLwm42019-09-191-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This merges separate audio and video tracks into one virtual stream, which helps the mpv caching layer. See previous EDL commit for details. It's apparently active for most of evil Silicon Valley giant's streaming videos. Initial tests seem to work fine, except it happens pretty often that playback goes into buffering immediately even when seeking within a cached range, because there is not enough forward cache data yet to fully restart playback. (Or something like this.) The audio stream title used to be derived from track.format_note; this commit stops doing so. It seemed pointless anyway. If really necessary, it could be restored by adding new EDL headers. Note that we explicitly don't do this with subtitle tracks. Subtitle tracks still have a chance with on-demand loading or loading in the background while video is already playing; merging them with EDL would prevent this. Currently, subtitles are still added in a "blocking" manner, but in theory this could be loosened. For example, the Lua API already provides a way to run processes asynchronously, which could be used to add subtitles during playback. EDL will probably be never flexible enough to provide this. Also, subtitles are downloaded at once, rather than streamed like audio and video. Still missing: disabling EDL's pointless chapter generation, and propagating download speed statistics through the EDL wrapper.
* loadfile, ytdl_hook: don't reject EDL-resolved URLs through playlistwm42019-09-191-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ytdl wrapper can resolve web links to playlists. This playlist is passed as big memory:// blob, and will contain further quite normal web links. When playback of one of these playlist entries starts, ytdl is called again and will resolve the web link to a media URL again. This didn't work if playlist entries resolved to EDL URLs. Playback was rejected with a "potentially unsafe URL from playlist" error. This was completely weird and unexpected: using the playlist entry directly on the command line worked fine, and there isn't a reason why it should be different for a playlist entry (both are resolved by the ytdl wrapper anyway). Also, if the only EDL URL was added via audio-add or sub-add, the URL was accessed successfully. The reason this happened is because the playlist entries were marked as STREAM_SAFE_ONLY, and edl:// is not marked as "safe". Playlist entries passed via command line directly are not marked, so resolving them to EDL worked. Fix this by making the ytdl hook set load-unsafe-playlists while the playlist is parsed. (After the playlist is parsed, and before the first playlist entry is played, file-local options are reset again.) Further, extend the load-unsafe-playlists option so that the playlist entries are not marked while the playlist is loaded. Since playlist entries are already verified, this should change nothing about the actual security situation. There are now 2 locations which check load_unsafe_playlists. The old one is a bit redundant now. In theory, the playlist loading code might not be the only code which sets these flags, so keeping the old code is somewhat justified (and in any case it doesn't hurt to keep it). In general, the security concept sucks (and always did). I can for example not answer the question whether you can "break" this mechanism with various combinations of archives, EDL files, playlists files, compromised sites, and so on. You probably can, and I'm fully aware that it's probably possible, so don't blame me.
* stats.lua: silence annoying fontconfig warningswm42019-09-191-2/+2
| | | | Apparently I don't have this font.
* osc: improve look of seekrangesJan Janssen2019-09-022-93/+261
|
* Merge branch 'master' into pr6360Jan Ekström2019-03-112-10/+7
|\ | | | | | | | | | | Manual changes done: * Merged the interface-changes under the already master'd changes. * Moved the hwdec-related option changes to video/decode/vd_lavc.c.
| * stats: merge multiple properties into one lineJulian2019-01-161-4/+4
| | | | | | | | | | | | | | Merge file-size/file-format and audio channel-count/format into one line respectively. This fixes stats overflowing the screen in larger than 19:6 aspect ratios. In this case a problem was reported for ~21:9 which should be common enough for us to "support" it.
| * lua: execute idle handlers after timers have been processedOlivier Perret2019-01-161-6/+3
| | | | | | | | | | | | | | Idle handlers used to not be executed when timers were active Now they are executed: * After all expired timers have been executed * After all events have been processed (same as when there are no timers)
* | stats: remove duplicate cache sizessfan52018-12-061-7/+4
| | | | | | | | The stream cache no longer exists, so there is no need to show the demuxer cache separately anymore.
* | Merge commit '559a400ac36e75a8d73ba263fd7fa6736df1c2da' into ↵Anton Kindestam2018-12-051-0/+62
|\ \ | |/ |/| | | | | | | wm4-commits--merge-edition This bumps libmpv version to 1.103
| * lua: expose mpv_abort_async_command()wm42018-05-241-3/+17
| | | | | | | | Also somewhat cleans up mp.command_native_async() error handling.