summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | | | | | | This turned every "normal" .rar filename into a multi-volume one accidentally. Since the detection is purely by filename (due to lack of support by libarchive I guess), it causes the nasty message added in the previous commit to appear for every .rar file. Just drop it.
* stream_libarchive: add annoying message regarding multi-volume archiveswm42020-01-041-2/+13
| | | | I'm done.
* libarchive: some shitty hack to make opening slightly fasterwm42020-01-044-4/+39
| | | | | | | | See manpage additions. The libarchive behavior mentioned in the last paragraph there is technically unrelated, but makes this new option mostly pointless. See: #7182
* stream_libarchive: log each opened volumewm42020-01-041-0/+1
| | | | To annoy the user.
* demux: add per-demuxer sub-optionswm42020-01-042-0/+14
| | | | | | Until now, they were all just added to options.c (e.g. demux_mkv_conf). This adds a mechanism which can be used to add future options in a (very) slightly more elegant way.
* options: add mechanism to add sub-options from component listswm42020-01-042-0/+15
| | | | | | | | | | | | | There are a lot of ad-hoc component lists in mpv: for example the stream and demuxer lists. It doesn't seem to make sense to add any abstractions around it since they are completely trivial and have very specific probing mechanisms and so on, so they will remain ad-hoc. This commits add a way to let these add arbitrary per-component options, without giving up the ad-hoc way, and without having to dump them into options.c with lots of ifdeffery (like it was done until now). Also see next commit.
* stream_libarchive: remove unnecessary string list of volumeswm42020-01-041-34/+25
| | | | Just add the entries as volumes directly.
* stream_libarchive: some more hacks to improve multi-volume archiveswm42020-01-043-33/+39
| | | | | | | | | | Instead of opening every volume on start just to see if it's there, all all volumes that could possibly exist, and "handle" it on opening. This requires working around some of libarchive's amazing stupidity and using some empirically determined behavior. Will possibly break if libarchive changes some of this behavior. See: #7182
* stream_libarchive: enable rar5 supportwm42020-01-042-1/+2
| | | | | | | | | | We whitelist formats (and not all of them). RAR v5 is a separated format entry for inexplicable reasons. (It's a separate implementation, but who really wants to support only either of the rar formats?) I'm not sure if it was libarchive 3.3.3. Their git history is absolutely chaotic. These people do not know how to use git. I couldn't be bothered to dig deeper.
* demux_edl: restore relative path resolutionwm42020-01-021-0/+12
| | | | | | | Playing e.g. "dir/f.edl" should make all non-absolute paths in f.edl relative to "dir". Commit 0e98b2ad8ec accidentally broke this.
* osc: reset input handling state on a change in visibility modePhilip Langdale2020-01-021-0/+7
| | | | | | | | | | | | | | | | | Currently, the activation and deactivation of input handling is done inside the render() loop, but this does not run when the osc mode is `never` - which does make sense. That means that if you are cycling the visibility mode, the input state will be whatever it was at the time of the mode change. And, as our modes are ordered `auto` -> `always` -> `never`, the input state will be enabled when you cycle to `never`. There are various ways you can imagine fixing this, and in this change I propose we reset the input state to disabled on a mode change, and then let render() re-enable input if that's appropriate. Fixes #7298.
* wayland: disable by default for gnomeDudemanguy2020-01-011-0/+4
| | | | | | | | | It turns out that gnome wayland still has very serious issues that make it unusable for playback with mpv. Other compositors mostly behave fine (Plasma is just missing feature but it's not seriously broken), so GNOME gets the special honor of having a warning printed out. The only solution for GNOME users at this time of writing is to either use the Xorg session or use another wayland compositor.
* Revert "vo_gpu: move wayland below X11 in autoprobe order"Dudemanguy2020-01-011-6/+6
| | | | This reverts commit a6d8e9b7ff0166ee6db69c41c0cfc319e03f4c80.
* Bump copyright yearwm42019-12-311-1/+1
| | | | Merry Christmas or whatever it fucking is now.
* demux: make track switching instant with certain mpegts fileswm42019-12-311-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When switching tracks, the data for the new track is missing by the amount of data prefetched. This is because all demuxers return interleaved data, and you can't just seek the switched track alone. Normally, this would mean that the new track simply gets no data for a while (e.g. silence if it's an audio track). To avoid this, mpv performs a special "refresh seek" in the demuxer, which tries to resume demuxing from an earlier position, in a way that does not disrupt decoding for the non-changed tracks. (Could write a lot about the reasons for doing something so relatively complex, and the alternatives and their weaknesses, but let's not.) This requires that the demuxer can tell whether a packet after a seek was before or after a previously demuxed packet, sort of like an unique ID. The code can use the byte position (pos) and the DTS for this. The DTS is normally strictly monotonically increasing, the position in most sane file formats too (notably not mp4, in theory). The file at hand had DTS==NOPTS packets (which is fine, usually this happens when PTS can be used instead, but the demux.c code structure doesn't make it easy to use this), and pos==-1 at the same time. The latter is what libavformat likes to return when the packet was produced by a "parser" (or in other words, packets were split or reassembled), and the packet has no real file position. That means the refresh seek mechanism has no packet position and can't work. Fix this by making up a pseudo-position if it's missing. This needs to set the same value every time, which is why it does not work for keyframe packets (which, by definition, could be a seek target). Fixes: #7306 (sort of)
* configfiles: Fix utime retcode checkChris Down2019-12-311-1/+1
| | | | | In final fixups for #7139 it seems I managed to screw up utime error checks. Everything still works, but we MP_WARN when we don't need to.
* player: make unpausing directly after seek work with --keep-openwm42019-12-301-0/+3
| | | | | | | | | | | | | | | When using --keep-open, and the end of the file is reached, the player's "pause" property is set to true. Attempting to set it to false reverts it back to true immediately. That's how it's designed, for better or worse. Running "seek -10 ; set pause no" did not work, because the seek is first queued and pause is unset, but then the decoding functions determine that EOF is still a thing, and "mpctx->stop_play = AT_END_OF_FILE;" is set again. handle_keep_open() then sets pause again. Only then the seek is actually run. Fix this by not setting stop_play if a seek is queued.
* vo_gpu: move wayland below X11 in autoprobe orderwm42019-12-301-6/+6
| | | | | | | I'm sick of mpv being accused of not doing it right. You can't do it right on Wayland? Long live X11. Fixes: #7307
* manpage: update discussion of nvidia hardware accelerationPhilip Langdale2019-12-291-26/+25
| | | | | The text here has become somewhat outdated over the years, and it's worth updating to reflect the current situation.
* video: cuda: add explicit context creation for copy hwaccelsPhilip Langdale2019-12-297-14/+72
| | | | | | | | | | | | | | | | | | | | | In the distant past, the cuviddec backed copy hwaccel could be configured directly using lavc options. However, since that time, we gained support for automatic hw ctx creation which ended up bypassing the lavc options. Rather than trying to find a way to pass those options again, a better idea is to make the 'cuda-decode-device' option, used by the interop hwaccels, work for the copy hwaccels too. And that's pretty simple: we have to add a create function that checks the option and passes it on to ffmpeg. Note that this does require a slight re-jig to the configuration flags, as we now have a scenario where we want to build with support for the cuda copy hwaccels but not the interop ones. So we need a distinct configuration flag for that combination. Fixes #7295.
* demux: fix --stream-record runtime change handlingwm42019-12-291-1/+1
| | | | Well, if that wasn't particularly dumb.
*