summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* 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 source code in English form.
* audio: react to --ao and --audio-buffer runtime changeswm42019-12-271-3/+3
| | | | | | Before this commit, runtime changes were only applied if something else caused audio to be reinitialized. Now setting them reinitializes audio explicitly.
* m_option: fix runtime changing of --audio-channelswm42019-12-271-3/+14
| | | | | | | | This option type, used by --audio-channels, had a completely broken m_option_type.equal implementation, and thus reacted incorrectly to runtime option changes. Broken since commit b16cea750f527088be7977.
* DOCS/tech-overview.txt: add lots of irrelevant blablawm42019-12-271-0/+373
| | | | | | Thought it might be useful to document some of these things, instead of explaining them over and over again. But I can guarantee that nobody will ever read all this. (Independent of its quality and completeness.)
* cocoa-cb: force redraw when screen or size changesder richter2019-12-241-0/+2
| | | | | | | | | in certain circumstances the video was not redrawn even when the size or the backing scale factor changed. this could lead to a lower resolution output than intended. now it redraws the video when screen properties or the window size changes.
* cocoa-cb: implement hidpi scale reportingder richter2019-12-242-0/+7
|
* console: add a basic help commandwm42019-12-241-1/+50
| | | | | | | | | | | | | | | It's not really great. But I think it's good enough to save someone who's lost. Most importantly, it should become obvious _what_ the console expects (input commands), and how to exit it. Would be nice if we could show some documentation, or give a link to documentation, but that's out of scope and/or not easy. I considered implementing the "help" command as builtin command in command.c. On the other hand, this could not show console.lua specific help, so I implemented it in console.lua. The ad-hoc command parsing (that sort-of mirrors mpv input command syntax) for the "help" command is probably the worst part of this.
* console: do not strip leading spaceswm42019-12-241-0/+3
| | | | As suggested by TheAMM and avih.
* command: extend command-list outputwm42019-12-241-0/+14
| | | | Add some very basic information about arguments.
* manpage: fix example in --hwdec sectionwm42019-12-241-1/+3
|
* stats: do not use "tick" eventwm42019-12-241-2/+6
| | | | | | | | It's deprecated. The new solution works almost exactly the same way (since the still existing internal tick event triggers vsync-jitter change command), though as far as API usage goes, it's somewhat questionable. (The comment is meant to discourage anyone trying to copy the idea for external scripts.)
* build: force bootstrap.py to use python3Niklas Haas2019-12-241-1/+1
| | | | The script fails running successfully with python2.
* osc: redraw on visibility option runtime changeswm42019-12-241-0/+1
| | | | | | This affects behavior when using the "del" default key binding. Sometimes, setting visibility to always did not draw it correctly. This probably fixes it.
* vd_lavc: remove hwdec-by-default special case for RPIwm42019-12-242-1/+4
|
* vd_lavc: more hwdec autoselect nonsensewm42019-12-242-21/+85
| | | | | | | | | | | | | Add an "auto-safe" mode, mostly triggered by Ubuntu's nonsense to force hwdec=vaapi in the global config file in their mpv package. But to be honest it's probably something more people want. This is implemented as explicit whitelist. On Windows, HEVC/Intel is sometimes broken, but it's still whitelisted, and in theory we'd need a detailed whitelist of device names etc. (like for example browsers tend to do). On OSX, videotoolbox is a pretty bad choice, but unfortunately the only one, so it's whitelisted too. There may be a larger number of hwdec wrappers that work anyway, and I'm for example ignoring Android.
* build: fix build with disabled swift and Media Playerder richter2019-12-232-1/+7
| | | | | | | | | | | | | | when swift is disabled some headers are not included. one of them is the options/options.h header that is needed for the vo_sub_opts struct. we include it to fix the build without swift. the second problem is the build time check for the macOS 10.12.2 features or more specific the Media Player support. since it is a swift feature we can not use it when swift is disabled. add a separate Media Player check that also depends on swift and use that new preprocessor variable as a build time check instead. Fixes #7282
* js: support mp.create_osd_overlay (match 07287262)Avi Halachmi (:avih)2019-12-233-23/+57
| | | | | The legacy mp.set_osd_ass(...) is still supported (but also still undocumented) as a wrapper for the new mp.create_osd_overlay(...).
* js: batch key bindings updates (match 96932fe7)Avi Halachmi (:avih)2019-12-231-3/+12
| | | | | | | Implemented using one-time idle observer (i.e. setTimeout), to avoid additional function call(back) every time the event loop enters idle. The lua mp.flush_key_bindings() is also available, also undocumented.
* osc: add option to disable santa hatNicolas F2019-12-232-2/+8
| | | | | | | | | | A minority of users have expressed a dislike of hats, calling them "cancer [that] don't belong in software" describing the people who add them as "shitty circlejerks" and "chucklefuck." While I personally disagree with those opinions, it's probably easier to let them have it their way. For that reason this adds the option `greenandgrumpy` to the osc, which allows users to disable the hat.
* lua: fix guard against division by 0wm42019-12-231-1/+1
| | | | | This was incorrectly converted from the original C code. Change it to what the original code used.
* lua: fix passing non-integers to mp.set_osd_ass()wm42019-12-231-0/+2
| | | | | | | | | | | | | | libass uses integers for PlayResX/Y, so the osd-overlay command also does. Lua (pre-5.3) does not have an integer type, but the command interface makes a difference anyway. If you pass a Lua number with a fractional part to an integer parameter (using mp.command_native()), it will result in an error and complain about incompatible types. I think that's fine, but since this behavior extends to mp.set_osd_ass(), this is a compatibility problem. Fix this by explicitly coercing the resolution parameters to integer numbers.
* osc: set an arbitrary high Z-orderwm42019-12-231-0/+1
| | | | | | | | The main reason for this is just to make show the OSC always above console.lua, instead of a random order. (And this is also the only reason osc.lua was changed to the new API. The old API could have been extended, but lets not.)
* osc: use new overlay APIwm42019-12-231-5/+18
| | | | | | | | | This tries to avoid the update() call if nothing changed. This brings it more into line with the old code (the osd-overlay command simply does not skip the update if nothing changed). I don't know whether this matters; most likely not. Normally, code should try to avoid redundant updates on its own, so it's not the job of the command. However, for the OSC we simply want to reduce the differences.
* client API, lua: add new API for setting OSD overlayswm42019-12-2311-68/