summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* build: actually remove MediaPlayer sources from build when disabledder richter2019-12-291-1/+1
| | | | | a small oversight on my side when i added the new flag to fix an include problem for the vo_sub_opts struct.
* vo_gpu: hwdec_vaegl: remove support for old-style interopPhilip Langdale2019-12-285-134/+9
| | | | | | | | | | | | | In vaapi 1.1.0 (which confusingly is libva release 2.1.0), they introduced a new surface export API that is more efficient, and we've been supporting that and the old API ever since (Feb 2018). If we drop support for the old API, we can do some fairly nice cleanup of the code. Note that the pkgconfig entries are explicitly versioned by the API version and not the library version. I confirmed the upstream pkgconfig files.
* vo_gpu: hwdec_vdpau: remove direct_modePhilip Langdale2019-12-283-170/+47
| | | | | | | | | | | | | | | | | | | | | | | | As we are less and less interested in vpdpau, with nvdec and vaapi being better choices in general on nvidia and AMD respectively, we might consider removing direct_mode, where we bypass the vdpau mixer and work directly with yuv textures. Normally, working with yuv textures would be great, but vdpau built in an assumption that all frames are delivered as separate fields, causing us to have to re-interleave them. nvidia then introduces a new OpenGL extension that can return the yuv frames as frames, but we can't just unconditionally switch to that as we'd want to keep supporting older hardware where the drivers are no longer getting new features. The end result is that we wouldn't be able to get rid of the old code paths. Removing direct_mode means we always use the mixer, and work with rgba frame textures. There are some theoretical limitations to this, but in practice they probably don't matter much - unsupported colourspaces don't matter because without 10bit decoding support, we can't use them anyway, and apparently we're not doing separate chroma scaling these days, so scaling the rbga doesn't really lose anything (and the vdpau hq scaling option remains available).
* command: add a playlist-unshuffle commandwm42019-12-284-0/+42
| | | | | | Has a number of restrictions. See: #2491, #7294
* playlist: change from linked list to an arraywm42019-12-2811-187/+172
| | | | | | | | | | | | | | | | | | | Although a linked list was ideal at first, there are cases where it sucks, and became increasingly awkward (with the mpv command API preferring integer indexes to access the list). In future, we probably want to add more playlist-related functionality, so better change it to an array now. An array isn't always ideal either. Since playlist entries are still separate objects (because in some cases you need a stable "iterator" to it), but you still need to efficiently get the next/previous playlist entry, there's a pl_index field, that needs to be maintained. E.g. adding an entry at the start of the playlist => update the pl_index field for all other entries. Well, it's not really worth to do something more complicated to avoid these things. This commit is probably buggy as shit. It's not like I bothered to test everything. That's _your_ role.
* ta: add another funny macrowm42019-12-281-0/+15
|
* ta: document funny macroswm42019-12-281-0/+10
|
* travis: fix python3 for macOS machinesder richter2019-12-281-1/+6
| | | | | python3 couldn't be set up as system default because it was blocked by the old python2.
* stream_dvb: Remove implicit fallthroughs and consistify debug messages.Oliver Freyermuth2019-12-281-4/+12
| | | | | | The code is more explicit now and less confusing, and debug messages for the channel parsing for the several delivery systems are now more similar.
* w32_common: remove implicit fallthroughJames Ross-Gowan2019-12-291-2/+3
| | | | | | GCC 9.2 warns about this. It was always a bit sketchy, so get rid of it. VK_F10 generates WM_SYSKEYDOWN, so it only needs to be handled in the WM_SYSKEYDOWN case.
* lua: fix mp.file_info for large filesSai Ke WANG2019-12-281-2/+2
| | | | | | `size` field with `unsigned int` was truncated to 4GB Signed-off-by: wm4 <wm4@nowhere>
* Update VERSIONsfan52019-12-281-1/+1
|
* Release 0.31.0v0.31.0release/0.31sfan52019-12-283-81/+56
|
* DOCS/tech-overview.txt: some more blablawm42019-12-281-27/+67
| | | | | This file is only complete once it contains the entire mpv sourc