summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* input: add new PLAYONLY and PAUSEONLY MP_KEY key codesder richter2020-01-263-0/+6
| | | | | since the old PLAY and PAUSE key codes cycle through the pause property, the new key codes only explicitly set the pause property.
* client API: document srand() usewm42020-01-211-0/+2
|
* player: make failure to load scripts non-fatal againwm42020-01-201-2/+1
| | | | | Restore the behavior from a few commits ago. I decided that it's strange that this is fatal, since e.g. config file errors are also non-fatal.
* stream_libarchive: more broken garbagewm42020-01-201-7/+22
| | | | Why the fuck am I even bothering with this crap?
* Revert "stream_libarchive: remove "old" rar volume pattern"wm42020-01-201-0/+8
| | | | | | | | | | This reverts commit 1b0129c4143fe73ef0ee3c3f1e2bed734c374d40. It turns out most of the files affected by the idiotic use-case actually use this old naming pattern, which I hoped was unused. This means for now we'll always assume .rar files are multi-part (until proven otherwise), but the following commit tries to fix this.
* github: rename Bug to Issue and slightly change the question templateder richter2020-01-206-9/+16
|
* input: fix cycle 2nd argument stringificationwm42020-01-191-0/+6
| | | | Triggered the fallback code that formatted the argument as "(NULL)".
* stream_libarchive: do not require leading / in archive URLswm42020-01-191-3/+3
| | | | | The / was added some time ago, because it simplifies some other things. But there is actually no reason to reject old URLs.
* scripting: make player error when attempting to load unknown scriptswm42020-01-194-10/+19
| | | | | | It's ridiculous that --script=something.dumb does not cause an error. Make it error, and extend this behavior to the scripts/ sub-dir in the mpv config dir.
* player: write watch-later config even for unseekable streamswm42020-01-171-5/+7
| | | | | | | | | | | | I think there was a user complaint that this does not restore the playlist position. There's no reason not to save the "state" for unseekable streams; what we probably don't want is to make restoring trying to issue a seek. So just don't save the position. (Although we probably could anyway, since seek requests on unseekable streams are ignored now.) Fixes: issue number forgotten, if it even exists.
* f_autoconvert: remove subfmt conversion BSwm42020-01-173-71/+1
| | | | | | This was used to convert e.g. P010 to NV12 within the filter chain, which hopefully a thing that is not needed anymore. (And has been dead code since the ANGLE "RGB" interop code was removed.)
* f_hwtransfer: extend vaapi whitelist with some working formatswm42020-01-171-1/+2
| | | | | | Notably, BGR0, which is the only additional format listed as supported by the texture mapper, results in broken colors. This is most likely not a mpv issue, so the whitelist fulfils its purpose.
* f_hwtransfer: minor debug logging improvementwm42020-01-171-2/+5
|
* vo_gpu: hwdec_vaapi: set correct hw_imgfmt valuewm42020-01-171-0/+1
| | | | | | | As documented on struct mp_hwdec_ctx, hw_imgfmt specifies the hardware surface wrapper format for which supported_formats is valid. If this was not set, f_hwtransfer ignored supported_formats, and assumed all formats were supported.
* osc: more frequent cache updates: from 10% diff to 5% or 5sAvi Halachmi (:avih)2020-01-141-2/+2
| | | | | | | | Cache display updates, especially when it's bigger than few minute, could have been be very infrequent to the point that one is not sure if it updates at all. Reduce the 10% change-threshold to 5% and add another threshold of 5s.
* bash completion: only generate option list when neededPhilip Langdale2020-01-131-5/+5
| | | | | | | | | | 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.
* osc: usability improvements for pseudo-csd title barPhilip Langdale2020-01-131-4/+21
| | | | | | | | | | | | | | | | | | | There are two improvements here: 1) Correct the right-side padding on the title box. This was messed up previously because I was passing the title box width when I should be passing the x coordinate. I've also increased the spacing to separate the title from the window controls more clearly. 2) I'ved added a mouse tracking area over the title bar so that the osc doesn't disappear if you hover over the title box. This didn't work previously because the input area only covers the actual window controls. The implementation here is simplified in that it's only a mouse area and not an input area. This is enough to keep the osc visible, but it won't stop the mouse pointer disappearing. Fixing that requires a full input area which, for now, I will say isn't worth the effort.
* osc: when fullscreened, un-maximise window control should un-fullscreenPhilip Langdale2020-01-121-2/+8
| | | | | | | | | | | | | | | It's a bit unintuitive today when you use the un-maximise control while fullscreened. Depending on the VO in use, this might silently change the maximise state without any visible effect, or it might do nothing. It's less surprising if the control exits the fullscreen state. Note that the exact behaviour is still VO dependent. If the window was maximised before being fullscreened, it might exit fullscreen back to maximised or back to regular window mode. I thought about trying to explicitly control that behaviour but it makes the osc code weird and probably wouldn't work all the time.
* wayland: support maximize/minimize on startupDudemanguy2020-01-121-0/+6
| | | | | | | Allow the --window-maximized and --window-minimized flags to actually work when the player is started on wayland. If the compositor doesn't support maximization or minimization, then these options just do nothing.
* wayland: unscrew up cursorsdudemanguy2020-01-121-6/+4
| | | | | | | | | | | | | | Fixes #7345 There was a multitude of issues with cursor handling in wayland and behavior seemed to vary for strange reasons across compositors and also bad things were being done in wayland_common. The problem is complicated and involved fullscreen states being set incorrectly under certain instances and so on. The best solution is to just remove most of the extra cruft. In handle_toplevel_config, instead of automatically assuming is_fullscreen and is_maximized are false, we should use whatever value is currently set vo_opts which matters when we initially launch the window.
* Revert "options: move cursor autohiding opts to mp_vo_opts"dudemanguy2020-01-124-12/+11
| | | | This reverts commit 65a317436df05000366af2738bdbb834e95e33db.
* f_hwtransfer: move format fields to private structwm42020-01-122-40/+37
| | | | | A user can barely do anything useful with it, and there are no users which access these anyway, so private is better.
* f_hwtransfer: restructure and error properly on broken caseswm42020-01-121-20/+24
| | | | | | | | | | | I think the previous code didn't consider the situation if the input format was not any of the upload formats. It then could have possibly tried to upload the wrong format (and not sure what the underlying APIs do with it). Take care of this, also improve logging, and change it such that mp_hwupload_find_upload_format() does not unnecessarily change the state (although it doesn't really matter).
* f_autoconvert: usw f_hwtransfer properlywm42020-01-121-2/+4
| | | | | | | | | | | | | | | With the recent change how f_hwtransfer could select formats, it's possible that the upload_fmts list contains formats that are never selected, and the filter would have failed. The way it works now is that f_hwtransfer gets to select the format (which honestly doesn't make sense, but whatever), and f_autoconvert gets only a single format. It would be more ideal if f_hwtransfer provided a list of possible input formats, but that's absurdly too complex for now. Maybe I'll change it back at some later point, but I expect this shit to be in a perpetual state of complexity and brokenness.
* input: escape command parameters when loggingwm42020-01-121-1/+9
| | | | | | | | | | | | | | Some complex commands (like commands generated by scripts to define key bindings or the OSD overlay command) contain new lines, which "corrupts" logging. Fix this by escaping the parameters C-style. Abuse the JSON writer for this, which already has code to vaguely produce C-style escapes. At first I considered stripping the quotes, but then I thought it's actually a good idea to leave them in, as it makes things clearer. Follows an idea by avih.
* f_hwtransfer: slightly better loggingwm42020-01-111-3/+4
|
* f_hwtransfer: whitelist vaapi formats that actually appear to workwm42020-01-111-3/+50
| | | | | | | | | | | | | | | | | (Oh yes, we could have skipped all the complexity, and hardcoded the cases that work in the first place. This wouldn't be an issue if FFmpeg or libva exported correct information. Also possible that FFmpeg's filter chain does not allow to do this correctly in the first place, since filters expose next to no meta information about what hw formats etc. they need.) Note that uploading yuv420p to a nv12 vaapi surface actually works, but the blacklist excludes it. So this might get a bit slower. I'm not bothering with this case because it's rarely needed, and the blacklist specification would become a bit more complex if you had to specify sw/upload format pairs. Fixes: #7350
* f_hwtransfer: change order in which hwdec upload formats are consideredwm42020-01-111-26/+28
| | | | | | | | | | | | | | | | | | | | | Basically, instead of trusting the upload format, and picking the first sw format that has a desired upload format, trust the sw format. So now we pick the sw format first, and then select from the set of upload formats supported by it. This is probably more straightforward, and works around a crash with vaapi: mpv 8bit.mkv --vf=format=vaapi --gpu-hwdec-interop=all (Forces vaapi upload if hw decoding is not enabled.) Unfortunately, this still does not work, because vaapi, FFmpeg, the VO interop code, or all of them are doing something stupid. In particular, this picks the yuv420p sw format, which doesn't really exist despiter advertised (???????????????????????????????????????), and simply breaks. See: #7350
* vaapi: reduce log levels furtherwm42020-01-112-8/+11
| | | | | Try to exclude mostly uninteresting information from verbose logging, but still include it in debug logging.
* vo_gpu: hwdec_vaapi: silence warning during probingwm42020-01-111-1/+4
| | | | | | | | | | | | | | hwdec_vaapi tries to probe all available surface formats in advance. For that, we iterate over _all_ profiles in an attempt to collect possible surface formats. This means we try profiles we normally wouldn't use for decoding or filtering, and which could be "unrelated" services. It seems some drivers report at least one profile, for which vaQueryConfigEntrypoints() fails (because the profile is not supported; not sure why it lists it, then). So turn the error message into a verbose message to avoid confusing output. Fixes: #7347
* wayland: don't set cursor before pointer idDudemanguy2020-01-111-1/+1
| | | | | | | | | | | This shouldn't really matter, but it's probably best to avoid. vo_wayland_control would execute set_cursor_visibility while wl->pointer existed but it didn't check if wl->pointer_id existed. So wl_pointer_set_cursor would be set to a null surface with an id of 0. Instead, just wait until we have an actual, non-zero pointer id so that the cursor is set with the correct, actual id and not a fictious 0 id. This ensures that the pointer isn't set until it enters the wl_surface which is what we want.
* bash completion: add initial implementation of bash completionPhilip Langdale2020-01-093-0/+116
| | | | | | 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.
* cocoa-cb: don't active window when minimized or hidden on file changeder richter2020-01-091-1/+6
| | | | Fixes #7195
* github: add several issue templates and a warning to not ignore themder richter2020-01-099-7/+238
|
* cocoa-cb: add runtime dpi change and use proper fallback for initial dpider richter2020-01-092-4/+7
| | | | | | | | at the time of the initial dpi query the window is not instantiated yet. we use a proper fallback in that case, eg the target configured screen or the main screen if none is set. also change some weird oversight and a small optimisation.
* command, vo: add a mechanism for runtime DPI scale changeswm42020-01-094-4/+10
| | | | | Follow up to commit a58585d5e063. It turned out that the OSX backend needs this.
* travis: update macOS images and make building fasterder richter2020-01-092-61/+51
| | | | | | | | | | | | don't build our own ffmpeg anymore and instead use the bottled version from homebrew. update the newest macOS image. also handle macOS 10.12 as a legacy OS since homebrew and Apple stopped supporting it. nevertheless it's helpful to build on that version since it's the last version we support building on. it's a bit special since we have to pin the homebrew-core version to a previous one where all the bottles for macOS 10.12 are still available, otherwise it would build nearly everything from source and that would take ages. also start caching the homebrew cache folder for downloads.
* client API: fix property notification from non-playloop sourceswm42020-01-091-2/+4
| | | | | | | | | | | | | | | This code assumed that the function is only called from the playloop itself (and since property notification is done at the end of it, i.e. before sleeping, it obviously would not have needed to wake up the core). But this function is actually called from some comments (such as playlist-move), so this assumption was incorrect. Use the same method as the other function. Untested. Fixes: #7339 (probably)
* client API: change event mask to event number in one placewm42020-01-091-4/+5
| | | | Cosmetic change. Slightly more convenient/readable.
* stream_libarchive: fix unnecessarily opening all volumes on openingwm42020-01-091-9/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Seems like I'm still not done with rar playback stuff... It turns out the reason for archive_read_open1() opening all volumes had nothing to do with libarchive's rar code, but was a consequence of how multi volume support is implemented in libarchive, and due to the fact that we enabled archive_read_support_format_zip_seekable() (through archive_read_support_format_zip()). The seekable zip format will seek to the end of the file and search for a zip "header" there. It could possibly be considered a libarchive bug that it does that even if it's fairly sure that it's a RAR file. We already do probing on a small buffer read from the start of the file (i.e. not giving libarchive a way to seek the stream before we think it's an archive), but that does not help, since libarchive needs to probe _again_. libarchive does not seem to provide a function to query the format (no archive_read_get_format()). Which seems quite strange, but at least I didn't find one. This commit works this around by doing some manual rar/zip probing. We could have gone only with rar probing. But detecting zip separately allows us to avoid that stream_libarchive seeks to the end during early probing. This is an additional bonus on top of "fixing" multi volume rar. The zip probing is from archive_read_format_zip_streamable_bid(). The rar signature is the common prefix of the rar and rar5 formats in libarchive (presumably the RAR fixed header parts without version). If the demuxer seeks to the end of the rar entry, this will still open all volumes; I'm not sure whether the old/removed rar code in mpv could handle this better. See: #7182
* js: use osd-dimentions for mp.get_osd_{size,margins}Avi Halachmi (:avih)2020-01-082-14/+7
| | | | | | | | | | | This matches lua's 11b9315b but with the lagacy field names which the js code used previously. Currently the property always returns an object (with dummy/last/null field values if there are no dimensions), but the code is ready for a future case where it might return null if there are no dimensions - at which case it will forward the null, breaking backward compatibility for a better API.
* vo_gpu: fix crash if dither texture fails to allocatewm42020-01-081-0/+3
| | | | | | | Theoretically possible (and quite unlikely due to the small texture size). The code was originally written with the assumption that texture allocations can't fail, and it was never updated out of laziness. Untested.
* osc: don't delay updates on resizewm42020-01-081-4/+19
| | | | | | | | | | | The idea is that if the player is resized, we do not delay redrawing (which is normally done to limit the redraw rate to something reasonable). Not sure if this even does anything. For one, reacting to osd-dimensions changes is cleaner than just polling the screen size with the next tick event, and hoping that resizes generate tick events for whatever logically unrelated reasons.
* osd: fix possible misses of osd-dimensions property updateswm42020-01-083-2/+16
| | | | | | | | | | | | | check_obj_resize() in sub/osd.c calls mp_client_broadcast_event(), which calls notify_property_events(). This is pretty unexpected, because check_obj_resize() may be called from the VO thread. While that's sort of awful, it seems to be OK locking-wise. But it breaks an assumption in notify_property_events() that the core doesn't need to be woken up, which could possibly lead to a missed/delayed property update (although rather unlikely). Fix this by explicitly waking up the core when it's called from the OSD code.
* command: cache display-hidpi-scale propertywm42020-01-081-4/+14
| | | | | | | | | | | | | | | | | | | | | | This is a gross hack for the shitty design of how VO properties are handled (which was fine with MPlayer, but became increasingly a shit tub with mpv's VO thread). The problem here is that console.lua reads display-hidpi-scale on every render, but which may take a long time for video timing and vsync blocking. It will also block the core, making osc.lua unable to react to window resizing quickly enough. This should be solved by not using the "classic" blocking VOCTRL mechanism, and instead side-stepping it with something that doesn't require any waiting (like for example the "fullscreen" property does). But this require more thinking and work my "brain" can handle at the moment. So for now add a shitty hack that will cause a lot of problems, and which will have to be replaced later. Most importantly, it'll break theoretic support for multiple screens with different DPI, or runtime DPI changes. Possibly could affect the Cocoa backend; the X11 isn't dynamic enough by nature, and other backends do not implement this.
* command: remove outdated MP_EVENT_WIN_STATE entrieswm42020-01-081-2/+1
| | | | | These properties are handled very differently now, and being in that list did pretty much nothing.
* lua: use new OSD propertywm42020-01-082-21/+6
| | | | | | | | See previous commit. A nice side-effect is that mp.get_osd_margins() is not a special Lua-only thing anymore. I didn't test whether this function still works as expected, though.
* command: add osd-dimensions propertywm42020-01-082-22/+57
| | | | | | | | | | | This "bundles" all OSD properties. It also makes some previously Lua-only values available (Lua has mp.get_osd_margins(), unsure if anything uses it). The main intention is actually to allow retrieving all fields in an "atomic" way. (Could introduce a mechanism on the level of the mpv client API to do this, but doing ti ad-hoc all the time like this commit is easier.)
* options: change option parsing when using a single dashwm42020-01-073-7/+27
| | | | | | | | | | | | | Addresses dumb things like accidentally overwriting a media file with e.g. "mpv --log-file test.mkv" (when the user thought that --log-file was a flag option, when it actually takes a filename). This example will now print an error. It still works with "-log-file overwritten.mkv", but prints a warning. Not sure if I'm being too careful or not "radical" enough. In any case, both the syntax that stops working and the syntax that produces a warning now have been discouraged and were called legacy for almost a decade.
* build: fix minimum libarchive versionwm42020-01-071-1/+1
| | | | | | Seems like 3.3.3 was not correct and too early. Fixes: #7334
* manpage: explain deprecated usage of multiple items with *-addDave2020-01-071-6/+9
|
* DOCS/encoding.rst: remove deprecated usage of multiple items with *-addDave2020-01-071-2/+6
| | | | | | 4a084c0df8fd8aaa66073839d97e544c3b6903e7 deprecated multiple -add items with d3e3bd43074ddd8f4c8829a7454b9f855454f462 explicitly warning against this usage.
* stream_libarchive: enable anger managementwm42020-01-071-6/+7
| | | | | | | | Well that was too much misery when trying to deal with an idiotic feature, so it had to be compensated for. Replace insults with proper explanation, libarchive sort of isn't guilty in the first place, and their format support is pretty good all things considered.
* wayland: don't exit the option loopDudemanguy2020-01-041-16/+12
| | | | | More than one option may change at the same time so don't break out of this loop.
* command: make sub-step command actually apply sub-delay change properlywm42020-01-043-3/+19
| | | | | | | | | The change was not propagated to the OSD/subtitle code, since that still uses an "old" method. Change it so that the propagation is actually performed. (One could argue the OSD/subtitle code should use other ways to update the options, but that would probably be more effort for now.)
* stream_libarchive: remove "old" rar volume patternwm42020-01-041-8/+0
|