summaryrefslogtreecommitdiffstats
path: root/DOCS/man/input.rst
Commit message (Collapse)AuthorAgeFilesLines
* DOCS/input: fix subprocess typoGuido Cella2021-10-261-3/+3
|
* command: with lavfi-complex, make current-tracks return the first oneGuido Cella2021-10-151-9/+2
| | | | | | | | | | | | | | | | | | | This behavior is more convenient and allows profile conditions like: [video] profile-cond=get('current-tracks/video/image') == false [image] profile-cond=get('current-tracks/video/image') Otherwise, these profiles have to be manually applied and restored in a script. The note about discouraging the use of current-tracks in scripts is removed, because it makes people avoid using this convenient property. It was added in 720bcd79d03 without leaving an explanation of why you shouldn't use it, and the only reason seems to be that it doesn't work with lavfi-complex, but this commit changes that.
* player: add track-list/N/image sub-propertyGuido Cella2021-10-141-4/+9
| | | | | | | | | | | | | | | | | | | | | | This exposes whether a video track is detected as an image, which is useful for profile conditions, property expansion and lavfi-complex. The lavf demuxer sets image to true when the existing check detects an image. When the lavf demuxer fails, the mf one guesses if the file is an image by its extension, so sh->image is set to true when the mf demuxer succeds and there's only one file. The mkv demuxer just sets image to true for any attached picture. The timeline demuxer just copies the value of image from source to destination. This sets image to true for attached pictures, standalone images and images added with !new_stream in EDL playlists, but it is imperfect since you could concatenate multiple images in an EDL playlist (which should be done with the mf demuxer anyway). This is good enough anyway since the comment of the modified function already says it is "Imperfect and arbitrary".
* Revert "player: add track-list/N/image sub-property"Jan Ekström2021-10-021-7/+4
| | | | | | | | Unfortunately, this functionality in large part based on a struct member that was made private in FFmpeg/FFmpeg@7489f632815c98ad58c3db71d1a5239b5dae266c in May. Unfortunately, this was not noticed during review. This reverts commit 0862664ac952d21fef531a8923a58ae575268fc5.
* player: add track-list/N/image sub-propertyGuido Cella2021-10-021-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This exposes whether a video track is detected as an image. This is useful for profile conditions, property expansion and lavfi-complex, and is more accurate than any detection even Lua scripts can perform, since they can't differentiate between images and videos without container-fps and audio and with duration 1 (which is the duration set by the mf demuxer with the default --mf-fps=1). The lavf demuxer image check is moved to where the number of frames is available for comparison, and is modified to check the number of frames and duration instead of the video codec. This doesn't misdetect videos in a codec commonly used for images (e.g. mjpeg) as images, and can detect images in a codec commonly used for videos (e.g. 1-frame gifs). pix files are also now detected as images, while before they weren't since the condition was checking if the AVInputFormat name ends with _pipe, and alias_pix doesn't. Both nb_frames and codec_info_nb_frames are checked because nb_frames is 0 for some video codecs (hevc, av1, vc1, mpeg1video, vp9 if forcing --demuxer=lavf), and codec_info_nb_frames is 1 for others (mpeg, mpeg4, wmv3). The duration is checked as well because for some uncommon codecs and containers found in FFMpeg's FATE suite, libavformat returns nb_frames = 0 and codec_info_nb_frames = 1. For some of them it even returns duration = 0, so they are blacklisted in order to never be considered images. The extra codecs that would have to be blacklisted without checking the duration are AV_CODEC_ID_4XM, AV_CODEC_ID_BINKVIDEO, AV_CODEC_ID_DSICINVIDEO, AV_CODEC_ID_ESCAPE130, AV_CODEC_ID_MMVIDEO, AV_CODEC_ID_NUV, AV_CODEC_ID_RL2, AV_CODEC_ID_SMACKVIDEO and AV_CODEC_ID_XAN_WC3, while the containers are film-cpk, ivf and ogg. The lower limit for duration is 10 because that's the duration of 1-frame gifs. Streams with codec_info_nb_frames 0 are not considered images because vp9 and av1 have nb_frames = 0 and codec_info_nb_frames = 0, and we can't rely on just the duration to detect them because they could be livestreams without an initial duration, and actually even if we could for these codecs libavformat returns huge negative durations like -9223372036854775808. Some more images in the FATE suite that are really frames cut from a video in an uncommon codec and container, like cine/bayer_gbrg8.cine, could be detected by allowing codec_info_nb_frames = 0, but then any present and future video codec with nb_frames = 0 and codec_info_nb_frames = 0 would need to be added to the blacklist. Some even have duration > 10, so to detect these images the duration check would have to be removed, and all the previously mentioned extra codecs and containers would have to be added added to the blacklists, which means that images that use them (if they exist anywhere) will never be detected. These FATE images aren't detected as such by mediainfo either anyway, nor can a Lua script reliably detect them as images since they have container-fps and duration > 0 and != 1, and you probably will never see files like them anywhere else. For attached pictures the lavf demuxer always set image to true, which is necessary because they have duration > 10. There is a minor change in behavior for which audio with attached pictures now has mf-fps as container-fps instead of unavailable, but this makes it consistent with external cover art, which was already being assigned mf-fps. When the lavf demuxer fails, the mf one guesses if the file is an image by its extension, so sh->image is set to true when the mf demuxer succeds and there's only one file. Even if you add a video's file type to --mf-type and open it with the mf protocol, only the first frame is used, so setting image to true is still accurate. When converting an image to the extensions listed in demux/demux_mf.c, tga and pam files are currently the only ones detected by the mf demuxer rather than lavf. Actually they are detected with the image2 format, but it is blacklisted; see d0fee0ac33a. The mkv demuxer just sets image to true for any attached picture. The timeline demuxer just copies the value of image from source to destination. This sets image to true for attached pictures, standalone images and images added with !new_stream in EDL playlists, but it is imperfect since you could concatenate multiple images in an EDL playlist (which should be done with the mf demuxer anyway). This is good enough anyway since the comment of the modified function already says it is "Imperfect and arbitrary".
* command: cycle: respect the prefix "repeatable"Avi Halachmi (:avih)2021-08-191-0/+4
| | | | | | | | | | | | | | | | | The "cycle" command _declaration_ enables repeatability by default, however, the command handler applies additional logic to augment it, based on the property which is being cycled - using some guesswork. Specifically, properties with discrete values are not repeatable (like sub or osd-level), while continuous properties are repeatable (like volume). Previously, the "repeatable" prefix could not override this additional logic. This commit changes the behavior so that the logic affects only the default repeatability (still based on the property like before), however, the "repeatable" prefix is now allowed to override it.
* command: don't hardcode commands list to be repeatableAvi Halachmi (:avih)2021-08-171-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Previously, a list of commands was always considered repeatable. This behavior was added at 6710527a (and moved around since then), in order to fix #807 (impossible to make a repeatable list). The problem was that a list doesn't have the normal repeatability flags and so it was never repeatable, so it was hardcoded to be repeatable instead. Presumably it was deemed good enough. However, this made it impossible to have a non-repeatable list. This commit changes the behavior so that a list repeatability is that of the first command at the list. This way, any list can be made either repeatable or non-repeatable using the following idiom (e.g. at input.conf), based on the fact that the "ignore" command is not repeatable by default: x ignore; cmd1...; cmd2... # non-repeatable y repeatable ignore; cmd1...; cmd2... # repeatable Fixes #7841
* DOCS/input: update osd-ass-cc documentationGuido Cella2021-08-161-3/+4
| | | | | | | | - Replace the legacy --osd-status-msg with the newer --osd-msg3. - Escape \b in show-text "This is ${osd-ass-cc/0}{\b1}bold text". - Link the Flat command syntax section because it's no longer true that you always need to escape \, since C escape sequences are not interpreted with single and custom quotes.
* manpage: clarify window-scale behaviorDudemanguy2021-08-071-5/+14
|
* command: make current-window-scale writeable, 2nd attemptDudemanguy2021-08-071-1/+8
| | | | | | | | | | | | | | | | | | | | | | The window-scale property mirrors the respective option (not the effective scale derived from the current window size), and as such setting its value to the same value it had before has no effect. Specifically - the window will not resize. This is consistent as far as property-option bridge behavior goes, but we do end up with an issue that we can't set an arbitrary scale and expect the window to always resize accordingly. We do also have a current-window-scale property which does reflect the actual window size, however, it's been read-only till now. This commit makes current-window-scale RW so that it's now always possible to set an arbitrary scale and expect the window to resize accordingly (without affecting window-scale - like manual resize). Also, mention window-scale no-effect-if-not-changed at the docs. Based on code by @Dudemanguy from commit 873ae0d, with same effect.
* Revert "command: make current-window-scale writeable"Avi Halachmi (:avih)2021-08-071-8/+14
| | | | | | | | | | | This reverts commit 873ae0de2af3bb84a11e5e57f6e3a8942b2263c2. The next commit will restore this functionality, with the following differences from the reverted commit: - Smaller and simpler code change. - On bad scale: use "Invalid value" (compared to "no such property"). - Doesn't combine the docs for window-scale and current-window-scale. - Doesn't remove the docs for window-scale behavior prior to 0.31.0.
* command: make current-window-scale writeableDudemanguy2021-08-051-14/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | Somewhat confusingly, mpv has both a window-scale option and a current-window-scale property. The documentation lists window-scale under properties (and it is technically is one), but at its core it is actually an option which means it behaves subtly different. Options in mpv are runtime-configurable, but they only change anything if the value of the option itself changes. window-scale is an option and not meant to keep track of the actual scale of the window (intended behavior introduced by d07b7f0). This causes window-scale to do nothing in certain cases (ex: the window is manually resized and window-scale is set to 1.00 again). This is logical and consistent with the behavior of the rest of the mpv options, but it also makes it a poor candidate for setting the mpv window scale dynamically. As a remedy, we can just make current-window-scale writeable instead. current-window-scale is intended to always report the actual scale of the window and keep track of any window size changes made by the user. By making this property also writeable, it allows the user to have more intuitive behavior (i.e. setting current-window-scale to 1.00 always sets the window to a scale of 1). Additionally, the default input.conf is changed to use current-window-scale instead of window-scale. The window-scale documentation under property list is removed since it is already documented under options and users should probably set the current-window-scale property instead in most cases.
* DOCS/input.rst: key names: add shift modifier notehooke0072021-07-301-0/+6
| | | | Fixes #9060
* input: arguments quoting: support single-quotesAvi Halachmi (:avih)2021-07-301-8/+15
| | | | | | | | | | | | | | | | | | | Users expect single quotes to work when the value includes literal backslashes or double-quotes (or as general quoting like in shell). The updated docs also include some previously-missing notes: - newline is only supported in double quotes. - adjacent (quoted) arguments don't join into one. Supporting mixed quoting (adjacent quoted strings) would make mpv's parsing more complete, but would require delicate effort of larger scope, for two reasons: - We'd need to also support escaping outside of quotes and do our best about backward compatibility. - The parsed value can either be a substring of the input or a newly-allocated string, which would be delicate when joining. Not critical to add right now.
* input: argument custom quotes: use ` instead of !Avi Halachmi (:avih)2021-07-301-5/+5
| | | | | | | | | | | Custom quotes were added in 4f129a3e and began with !, however, this required quoting "!reverse" (used for the cycle-values command), which is inconvenient, and was not taken into account when ! was chosen for custom quotes. Also, ` is more natural for quoting than !. This does break backward compatibility with the earlier form of custom quotes, but at least we didn't make a release yet since custom quotes were added (the last release - 0.33[.1] doesn't support it).
* options: audio-display determines cover priorityGuido Cella2021-07-291-1/+2
| | | | | | | | | | | | Let audio-display determine whether embedded images or external cover art tracks should be selected when both are present. Attached pictures are given priority by default as requested in #8539. Also updates references to attached pictures in the log and manpage to refer to cover art as well. Closes #8539.
* manpage: explain when properties are expandedGuido Cella2021-07-271-3/+13
|
* manpage: minor fixesGuido Cella2021-07-211-3/+3
| | | | | | | | - The video filter to turn the video upside-down is vflip. There is no filter called "flip" so using it just causes an error. - Reword a sentence. - Add exact and all to the values accepted by cover-art-auto. They were implemented in 029ff1049b but not added to the accepted arguments.
* command: adds support for secondary subs to sub-seek and sub-stepRipose2021-07-121-2/+16
| | | | | | | Modifies the sub-seek and sub-step commands with a second <flags> argument to specify whether to seek/step on the primary or secondary subtitles. The flag is used to index into the current_track array in cmd_sub_step_seek.
* command: add secondary-sub-start and secondary-sub-end propertiesRipose2021-07-121-0/+6
| | | | | | | Adds secondary-sub-start and secondary-sub-end properties by setting the current_track index in the m_property's priv variable which later gets accessed in get_times. Also adds a test of the secondary subtitle time properties in tests/subtimes.js bound to 'T'.
* manpage: fix typoGuido Cella2021-07-081-1/+1
|
* player: add append-play flag to loadlistGuido Cella2021-07-061-0/+4
| | | | Closes #5664.
* manpage: mention cover-art-autoGuido Cella2021-05-281-3/+3
| | | | | --cover-art-auto affects rescan-external-files, and --autoload-files affects cover art.
* win32: support the property 'focused'Avi Halachmi (:avih)2021-05-271-2/+1
| | | | | | | | | | | | | And also change the existing WM_KILLFOCUS handler to return 0 instead of 'break' (which later calls DefWindowProcW), as MSDN says we should do for WM_{KILL,SET}FOCUS. It seems that the 'focused' property is now supported by all main VOs: x11, macOS, wayland, Windows. TCT/sixel/caca probably don't support it, and unknown with SDL. Fixes #8868
* player/command: add secondary-sub-text propertyZsolt Vadasz2021-05-191-0/+3
|
* command: add display-width/display-height propertyDudemanguy2021-05-061-0/+5
| | | | | | | | | For some reason, this never existed before. Add VOCTRL_GET_DISPLAY_RES and use it to obtain the current display's resolution from each vo/windowing backend if applicable. Users can then access the current display resolution as display-width and display-height as per the client api. Note that macOS/cocoa was not attempted in this commit since the author has no clue how to write swift.
* command: new property: pid (process id)Avi Halachmi (:avih)2021-05-011-0/+3
| | | | Fixes #7562
* DOCS: clarify how client/script names workDudemanguy2021-04-291-2/+4
| | | | | This isn't really clearly stated anywhere and could understandably lead to some confusion.
* command: osd-dimensions: return ints and doc fixesDudemanguy2021-04-291-2/+2
| | | | | | Some subproperties in osd-dimensions were returned as doubles despite actually being integers. Additionally, correct a highly misleading line in the osd-width/osd-height documentation.
* player/command: add albumart argument to video-addTom Wilson2021-03-091-2/+5
| | | | | | Enables marking of specific video sources as album art. Co-authored-by: Jan Ekström <jeebjp@gmail.com>
* input.conf syntax: support custom quotes !XstringX!Avi Halachmi (:avih)2020-12-311-8/+18
| | | | | | | | | | Where X is any ASCII char chosen by the user. An argument is only interpreted as custom-quoted if it starts with '!' and the line doesn't end right after it. Custom quotes don't interpret backslash-escape. This change only affects command arguments which mpv parses (not array commands), and not tokens before the arguments (where applicable - key name, input section, command prefixes, command name).
* input.rst: fix typo commands -> argumentsAvi Halachmi (:avih)2020-12-311-1/+1
|
* doc: split BNF definitions of <command> and <argument> in separate linesEmanuele Torre2020-11-221-2/+3
| | | | | | Having them in the same line made it hard to read them in the man page since they are formatted in the same way and they look as though they are only one definition.
* docs/input.rst: document the mouse-pos propertyAvi Halachmi (:avih)2020-11-161-0/+14
|
* manpage: properties fixesGuido Cella2020-11-111-17/+21
| | | | | | | | | | | - Explain which properties are writeable. - Mark edition-list/N/id as writable. - Remove (R) from some read-only properties since none of the others have it. - Add osd-dimension/ to its subproperties. - options/<name> isn't read-only. - focused works on macOS because of 82eda2e. Though it shouldn't be possible to observe it without raising VO_EVENT_FOCUS.
* manpage: document the property-change eventGuido Cella2020-11-111-0/+11
|
* manpage: document video-frame-info sub-propertiesGuido Cella2020-11-111-5/+13
| | | | | | | The picture type is explained in /usr/include/libavutil/avutil.h Other subproperties in /usr/include/libavutil/frame.h And there is a more detailed explanation for repeat_pict in /usr/include/libavcodec/avcodec.h
* manpage: remove redundant "Return(s) "Guido Cella2020-11-111-59/+58
| | | | | | ...from the property descriptions that include it, and reformat the paragraphs. And say "Returns" in idle-active.
* manpage: document demuxer-cache-state betterGuido Cella2020-11-111-4/+11
|
* manpage: be consistent with booleansGuido Cella2020-11-111-73/+73
| | | | | | | | | | | | | When possible, refer to booleans with "Whether..." since it can refer to both yes (using input.conf and mp.get_property) and true (using the JSON IPC or mp.get_property_native/bool), else explicitly say yes/true. Say "true" for subprocess and osd-overlay named arguments since you can't use them in input.conf and you will typically use them with the boolean true in the named arguments, like the subprocess example in the manpage does (though the string "yes" also works). Subproperties that can't be accessed with the / syntax like demuxer-cache-state's bof-cached and eof-cached always return true, never yes.
* command: add delete-watch-later-configVladimir Panteleev2020-10-221-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces the delete-watch-later-config command, to complement write-watch-later-config. This is an alternative to #8141. The general problem that this change is attempting to help solve has been described in #336, #3169 and #6574. Though persistent playback position of a single file is generally a solved problem, this is not the case for playlists, as described in #8138. The motivation is facilitating intermittent playback of very large playlists, consisting of hundreds of entries each many hours long. Though the current "watch later" mechanism works well - provided that the files each occur only once in that playlist, and are played only via that playlist - the biggest issue is that the position is lost completely should mpv exit uncleanly (e.g. due to a power failure). Existing workarounds (in the form of Lua scripts which call write-watch-later-config periodically) fail in the playlist case, due to the mechanism used by mpv to determine where within a playlist to resume playback from. The missing puzzle piece needed to allow scripts to implement a complete solution to this problem is simply a way to clean up the watch-later configuration that the script asked mpv to write using write-watch-later-config. With that in place, scripts can then register an end-file event listener, check the stop playback reason, and in the "eof" and "stop" case, invoke delete-watch-later-config to delete any saved positions written by write-watch-later-config. The script can then proceed to immediately write a new one when the next file is loaded, which altogether allows mpv to resume from the correct playlist and file position upon next startup. Because events are delivered and executed asynchronously, delete-watch-later-config takes an optional filename argument, to allow scripts to clear watch-later configuration for files after mpv had already moved on from playing them and proceeded to another file. A Lua script which makes use of this change can be found here: https://gist.github.com/CyberShadow/2f71a97fb85ed42146f6d9f522bc34ef (A modification of the one written by @Hakkin, in that this one takes advantage of the new command, and also saves the state immediately when a new file is loaded.)
* command: expose underlying pixfmt for hwdecsfan52020-10-161-0/+5
|
* manpage: mark file-local-options as writableGuido Cella2020-09-171-1/+1
|
* command: add property track-list/N/main-selectionwnoun2020-09-121-0/+7
|
* manpage: "fix" some formattingwm42020-09-101-4/+8
| | | | Yeah, fuck this retarded garbage.
* command: add read-only focused propertyGuido Cella2020-09-081-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a property that returns whether the window is focused, currently only for X11 and Wayland. My use cause for this is having an equivalent of pause-when-minimize.lua for tiling window managers: make mpv play only while it's in the current workspace or is focused (I'm fine with either one but prefer focus). On X I do this by observing display-names, which is empty when the rectangles of the display and mpv don't intersect, but on Wayland its value doesn't change when mpv leaves the current workspace (and the same check doesn't work since the geometries still intersect). This could later be made writable as requested in #6252. Note that on Wayland se shouldn't consider an unactivated window with keyboard input focused. The wlroots compositors I tested set activated after changing the keyboard focus, so if you set wl->focused only in keyboard_handle_enter() and keyboard_handle_leave() to avoid adding the "has_keyboard_input" member, focused isn't set to true when first opening mpv until you focus another window and focus mpv again. Conversely, if that order can't be assumed for all compositors, we should toggle wl->focused when necessary in keyboard_handle_enter() and keyboard_handle_leave() as well as in handle_toplevel_config().
* manpage: reorder sentenceGuido Cella2020-08-281-3/+3
|
*