github
/
mpv
mirror of https://github.com/mpv-player/mpv
1
Fork 0
Code Releases Activity
mpv/options/options.h

359 lines
8.3 KiB
C
Raw Normal View History

Start of new option system First part of option restructuring. The aim is to move option values from a huge number of separate globals to a single non-global struct. This part adds some support for parsing option values into such struct instances, and moves one example option (fixed-vo) to the struct.
2008-03-31 05:19:29 +02:00
#ifndef MPLAYER_OPTIONS_H
#define MPLAYER_OPTIONS_H
vo: remove and cleanup globals Removes almost every global variabel in vo.h and puts them in a special struct in MPOpts for video output related options. Also we completly remove the options/globals pts and refresh rate because they were unused.
2013-03-04 17:40:21 +01:00
#include <stdbool.h>
core: remove a number of global variables Move them into per-instance structs. This should get rid of all global variables in mplayer.c (not counting those referenced by cfg-mplayer.h). In core/input/ar.c, just remove checking the slave_mode variable. I'm not sure what this code was supposed to achieve, but slave mode is broken, slave mode is actually infeasible on OSX (ar.c is completely OSX specific), and the correct way of doing this would be to disable this input device per command line switch.
2013-03-08 02:08:02 +01:00
#include <stdint.h>
Move options/config related files from mpvcore/ to options/ Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
2013-12-17 02:02:25 +01:00
#include "m_option.h"
player: use an array for stream ID options and such This makes the code slightly more generic.
2015-05-22 21:00:24 +02:00
#include "common/common.h"
options: rename -ss and -endpos, allow relative times Rename the -ss option to -start, and -endpos to -length. Add a -end option. The -end option always specifies an absolute end time, as opposed to -endpos/-length. All these options (--start, --end, --length) now accept relative times. Percent positions (e.g. "--start=30%") are interpreted as fractions of the file duration. Negative times (e.g. "--start=-1:00) are interpreted relative to the end of the file. Chapters (e.g. "--start=#3") yield the chapter's time position. The chapter support might be able to replace --chapter completely, but for now I am not sure how well this works out with e.g. DVDs and BDs, and a separate --chapter option is useful interface-wise.
2012-11-15 18:49:17 +01:00
vo: Separate vo options from MPOpts Separate the video output options from the big MPOpts structure and also only pass the new mp_vo_opts structure to the vo backend. Move video_driver_list into mp_vo_opts
2013-03-04 22:41:27 +01:00
typedef struct mp_vo_opts {
options: remove deprecated sub-option handling for --vo and --ao Long planned. Leads to some sanity. There still are some rather gross things. Especially g_groups is ugly, and a hack that can hopefully be removed. (There is a plan for it, but whether it's implemented depends on how much energy is left.)
2016-11-25 21:00:39 +01:00
struct m_obj_settings *video_driver_list;
vo: Separate vo options from MPOpts Separate the video output options from the big MPOpts structure and also only pass the new mp_vo_opts structure to the vo backend. Move video_driver_list into mp_vo_opts
2013-03-04 22:41:27 +01:00
win32: make taskbar progress indication optional Add --taskbar-progress command line option and property which controls taskbar progress indication rendering in Windows 7+. This option is on by default and can be toggled during playback. This option does not affect the creation process of ITaskbarList3. When the option is turned off the progress bar is just hidden with TBPF_NOPROGRESS. Closes #2535
2016-05-05 07:56:21 +02:00
int taskbar_progress;
win32: snap to screen edges Disabled by default. The snap sensitivity value depends on the screen DPI. The default value is 16px on a 96 DPI screen. Fixes #2248
2016-12-09 19:22:33 +01:00
int snap_window;
vo: Separate vo options from MPOpts Separate the video output options from the big MPOpts structure and also only pass the new mp_vo_opts structure to the vo backend. Move video_driver_list into mp_vo_opts
2013-03-04 22:41:27 +01:00
int ontop;
cocoa: add --ontop-level option for modifying ontop window level since there are different views on what ontop is, we make the ontop window level modifiable. at the moment only support for macOS was added. the default for macOS was changed from 'system' to 'window' since this fixes an unwanted behaviour in fullscreen and in general causes less issues with expected behaviour. Fixes #2376 #3974
2017-02-13 20:08:43 +01:00
int ontop_level;
video: remove fullscreen flags chaos There was a MPOpts fullscreen field, a mp_vo_opts.fs field, and VOFLAG_FULLSCREEN. Remove all these and introduce a mp_vo_opts.fullscreen flag instead. When VOs receive VOCTRL_FULLSCREEN, they are supposed to set the current fullscreen mode to the state in mp_vo_opts.fullscreen. They also should do this implicitly on config(). VOs which are capable of doing so can update the mp_vo_opts.fullscreen if the actual fullscreen mode changes (e.g. if the user uses the window manager controls). If fullscreen mode switching fails, they can also set mp_vo_opts.fullscreen to the actual state. Note that the X11 backend does almost none of this, and it has a private fs flag to store the fullscreen flag, instead of getting it from the WM. (Possibly because it has to deal with broken WMs.) The fullscreen option has to be checked on config() to deal with the -fs option, especially with something like: mpv --fs file1.mkv --{ --no-fs file2.mkv --} (It should start in fullscreen mode, but go to windowed mode when playing file2.mkv.) Wayland changes by: Alexander Preisinger <alexander.preisinger@gmail.com> Cocoa changes by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
2013-07-18 14:05:39 +02:00
int fullscreen;
x11: add --on-all-workspaces option and property Fixes #1469.
2015-01-16 23:38:47 +01:00
int border;
options: add --fit-border video option Flag that is set by default. Reseting it will result in mpv trying to fit client area with video instead of the whole window with border and decorations on the screen. Marked as (Windows only) for now until it's implemented on other platforms.
2016-04-26 03:46:49 +02:00
int fit_border;
x11: add --on-all-workspaces option and property Fixes #1469.
2015-01-16 23:38:47 +01:00
int all_workspaces;
vo: Separate vo options from MPOpts Separate the video output options from the big MPOpts structure and also only pass the new mp_vo_opts structure to the vo backend. Move video_driver_list into mp_vo_opts
2013-03-04 22:41:27 +01:00
int screen_id;
int fsscreen_id;
char *winname;
x11: replace--[x11-]fstype option with --x11-netwm Simplifies the code a lot. You can still use --x11-netwm=no to disable NetWM for whatever reasons.
2014-05-16 00:47:13 +02:00
int x11_netwm;
x11: request bypassing compositor Maybe this is a good idea. Also add an option to disable it again, for the sake of testing. Fixes #2502.
2015-11-18 21:37:38 +01:00
int x11_bypass_compositor;
x11: use mpv internal key auto-repeat handling if possible Block X11's native key repeat, and use mpv's key repeat handling in input.c instead. No configure check for XKB. Even though it's an extension, it has been part of most (all?) xlibs since 1996. If XKB appears to be missing, just refuse enabling x11. This is a potentially controversial change. mpv will use its own key repeat rate, instead of X11's. This should be better, because seeking will have a standardized "speed" (seek events per seconds when keeping a seek key held down). It will also allow disabling key repears for certain commands, though this is not done anywhere yet. The new behavior can be disabled with the --native-keyrepeat option.
2013-04-04 01:13:56 +02:00
int native_keyrepeat;
vo: Separate vo options from MPOpts Separate the video output options from the big MPOpts structure and also only pass the new mp_vo_opts structure to the vo backend. Move video_driver_list into mp_vo_opts
2013-03-04 22:41:27 +01:00
float panscan;
video: make it possible to scale/pan the video by arbitrary amounts Add --video-align-x/y, --video-pan-x/y, --video-scale options and properties. See the additions to the manpage for description and semantics. These transformations are intentionally done on top of panscan. Unlike the (now removed) --panscanrange option, this doesn't affect the default panscan behavior. (Although panscan itself becomes kind of useless if the new options are used.)
2013-06-15 00:15:32 +02:00
float zoom;
float pan_x, pan_y;
float align_x, align_y;
video: add unscaled mode with --video-unscaled
2013-09-01 03:27:03 +02:00
int unscaled;
vo: Separate vo options from MPOpts Separate the video output options from the big MPOpts structure and also only pass the new mp_vo_opts structure to the vo backend. Move video_driver_list into mp_vo_opts
2013-03-04 22:41:27 +01:00
struct m_geometry geometry;
struct m_geometry autofit;
struct m_geometry autofit_larger;
player: add --autofit-smaller option Fixes #1472. (Maybe these options should have been named --autofit-max and --autofit-min, but since --autofit-larger already exists, use --autofit-smaller for symmetry.)
2015-01-16 22:30:32 +01:00
struct m_geometry autofit_smaller;
options: fix window-scale property A recent change merged the window-scaler option and property, but forgot that the option is float for some reason, while the property uses double. This led to undefined behavior. Fix it by changing the option to double too.
2016-09-20 01:20:22 +02:00
double window_scale;
vo: Separate vo options from MPOpts Separate the video output options from the big MPOpts structure and also only pass the new mp_vo_opts structure to the vo backend. Move video_driver_list into mp_vo_opts
2013-03-04 22:41:27 +01:00
int keepaspect;
options: add --no-keepaspect-window Seems silly, but was requested.
2014-10-04 22:17:36 +02:00
int keepaspect_window;
cocoa: option to scale window by HiDPI scale factor Deactivating this options makes it possible to circumvent the default OS X behavior of using points. Windows on HiDPI resolutions won't open in double the size anymore and videos are display in their native resolution when windowed. Fixes #3716
2016-10-25 15:59:13 +02:00
int hidpi_window_scale;
cocoa: add an option to disable the native macOS fullscreen Fixes #4014
2017-07-27 21:28:33 +02:00
int native_fs;
vo: Separate vo options from MPOpts Separate the video output options from the big MPOpts structure and also only pass the new mp_vo_opts structure to the vo backend. Move video_driver_list into mp_vo_opts
2013-03-04 22:41:27 +01:00
int64_t WinID;
float force_monitor_aspect;
float monitor_pixel_aspect;
int force_window_position;
cocoa_common: add native OSX fullscreen support This adds Mission Control fullscreen functionality to mpv. Since this doesn't play well with many of mpv's features disable it by default. Users can activate this feature by using `--native-fs` when starting mpv. Fixes #34
2013-05-11 00:22:23 +02:00
win32: add option to set VO MMCSS profile This was requested.
2015-12-06 19:20:23 +01:00
char *mmcss_profile;
vo: move display-fps internal option value to VO opts Removes the awkward notification through VO_EVENT_WIN_STATE. Unfortunately, some awkwardness remains in mp_property_display_fps(), because the property has conflicting semantics with the option.
2018-03-13 12:34:26 +01:00
double override_display_fps;
video: add an option to tune waiting for video timing Probably mostly useful for the libmpv render API.
2018-03-13 11:23:23 +01:00
double timing_offset;
vo_gpu: make it possible to load multiple hwdec interop drivers Make the VO<->decoder interface capable of supporting multiple hwdec APIs at once. The main gain is that this simplifies autoprobing a lot. Before this change, it could happen that the VO loaded the "wrong" hwdec API, and the decoder was stuck with the choice (breaking hw decoding). With the change applied, the VO simply loads all available APIs, so autoprobing trickery is left entirely to the decoder. In the past, we were quite careful about not accidentally loading the wrong interop drivers. This was in part to make sure autoprobing works, but also because libva had this obnoxious bug of dumping garbage to stderr when using the API. libva was fixed, so this is not a problem anymore. The --opengl-hwdec-interop option is changed in various ways (again...), and renamed to --gpu-hwdec-interop. It does not have much use anymore, other than debugging. It's notable that the order in the hwdec interop array ra_hwdec_drivers[] still matters if multiple drivers support the same image formats, so the option can explicitly force one, if that should ever be necessary, or more likely, for debugging. One example are the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both support d3d11 input. vo_gpu now always loads the interop lazily by default, but when it does, it loads them all. vo_opengl_cb now always loads them when the GL context handle is initialized. I don't expect that this causes any problems. It's now possible to do things like changing between vdpau and nvdec decoding at runtime. This is also preparation for cleaning up vd_lavc.c hwdec autoprobing. It's another reason why hwdec_devices_request_all() does not take a hwdec type anymore.
2017-12-01 05:05:00 +01:00
// vo_drm
options: remove global variables for swscale options; rename them Additionally to removing the global variables, this makes the options more uniform. --ssf-... becomes --sws-..., and --sws becomes --sws- scaler. For --sws-scaler, use choices instead of magic integer values.
2014-06-10 22:41:14 +02:00
struct sws_opts *sws_opts;
vo_drm: change CLI options + refactors - Change connector selection to accept human readable names (such as eDP-1, HDMI-A-2) rather than arbitrary numbers. - Change GPU selection to accept GPU number rather than device paths. - Merge connector and GPU selection into one --drm-connector. - Add support for --drm-connector=help. - Add support for --drm-* in EGL backend. - Refactor KMS; reduce state sharing across drm_common.
2016-10-04 22:07:19 +02:00
// vo_drm
video : Move drm options to substruct. This allows to group them and most of all query the group config when needed and when we don't have the access to vo.
2017-10-23 08:59:58 +02:00
struct drm_opts *drm_opts;
vo: Separate vo options from MPOpts Separate the video output options from the big MPOpts structure and also only pass the new mp_vo_opts structure to the vo backend. Move video_driver_list into mp_vo_opts
2013-03-04 22:41:27 +01:00
} mp_vo_opts;
options: move most subtitle and OSD rendering options to sub structs Remove them from the big MPOpts struct and move them to their sub structs. In the places where their fields are used, create a private copy of the structs, instead of accessing the semi-deprecated global option struct instance (mpv_global.opts) directly. This actually makes accessing these options finally thread-safe. They weren't even if they should have for years. (Including some potential for undefined behavior when e.g. the OSD font was changed at runtime.) This is mostly transparent. All options get moved around, but most users of the options just need to access a different struct (changing sd.opts to a different type changes a lot of uses, for example). One thing which has to be considered and could cause potential regressions is that the new option copies must be explicitly updated. sub_update_opts() takes care of this for example. Another thing is that writing to the option structs manually won't work, because the changes won't be propagated to other copies. Apparently the only affected case is the implementation of the sub-step command, which tries to change sub_delay. Handle this one explicitly (osd_changed() doesn't need to be called anymore, because changing the option triggers UPDATE_OSD, and updates the OSD as a consequence). The way the option value is propagated is rather hacky, but for now this will do.
2017-12-29 17:19:25 +01:00
// Subtitle options needed by the subtitle decoders/renderers.
struct mp_subtitle_opts {
int sub_visibility;
int sub_pos;
float sub_delay;
float sub_fps;
float sub_speed;
int forced_subs_only;
int stretch_dvd_subs;
int stretch_image_subs;
int image_subs_video_res;
int sub_fix_timing;
int sub_scale_by_window;
int sub_scale_with_window;
int ass_scale_with_window;
struct osd_style_opts *sub_style;
float sub_scale;
float sub_gauss;
int sub_gray;
int sub_filter_SDH;
int sub_filter_SDH_harder;
int ass_enabled;
float ass_line_spacing;
int ass_use_margins;
int sub_use_margins;
int ass_vsfilter_aspect_compat;
int ass_vsfilter_color_compat;
int ass_vsfilter_blur_compat;
int use_embedded_fonts;
char **ass_force_style_list;
char *ass_styles_file;
int ass_style_override;
int ass_hinting;
int ass_shaper;
int ass_justify;
int sub_clear_on_seek;
int teletext_page;
};
struct mp_osd_render_opts {
float osd_bar_align_x;
float osd_bar_align_y;
float osd_bar_w;
float osd_bar_h;
float osd_scale;
int osd_scale_by_window;
struct osd_style_opts *osd_style;
int force_rgba_osd;
};
vo: Separate vo options from MPOpts Separate the video output options from the big MPOpts structure and also only pass the new mp_vo_opts structure to the vo backend. Move video_driver_list into mp_vo_opts
2013-03-04 22:41:27 +01:00
typedef struct MPOpts {
command: add options to property list Now options are accessible through the property list as well, which unifies them to a degree. Not all options support runtime changes (meaning affected components need to be restarted for the options to take effects). Remove from the manpage those properties which are cleanly mapped to options anyway. From the user-perspective they're just options available through the property interface.
2016-09-01 20:00:43 +02:00
int property_print_help;
options: add --no-terminal switch Mostly useful for internal reasons. This code will be enabled by default if mpv is started via the client API.
2014-02-06 16:49:50 +01:00
int use_terminal;
player: add a --dump-stats option This collects statistics and other things. The option dumps raw data into a file. A script to visualize this data is included too. Litter some of the player code with calls that generate these statistics. In general, this will be helpful to debug timing dependent issues, such as A/V sync problems. Normally, one could argue that this is the task of a real profiler, but then we'd have a hard time to include extra information like audio/video PTS differences. We could also just hardcode all statistics collection and processing in the player code, but then we'd end up with something like mplayer's status line, which was cluttered and required a centralized approach (i.e. getting the data to the status line; so it was all in mplayer.c). Some players can visualize such statistics on OSD, but that sounds even more complicated. So the approach added with this commit sounds sensible. The stats-conv.py script is rather primitive at the moment and its output is semi-ugly. It uses matplotlib, so it could probably be extended to do a lot, so it's not a dead-end.
2014-04-17 21:47:00 +02:00
char *dump_stats;
msg: remove global state
2013-12-21 23:11:12 +01:00
int verbose;
options: remove weird --really-quiet special behavior This was especially grating because it causes problems with the option/property unification, uses as only thing OPT_FLAG_STORE, and behaves weird with the client API or scripts. It can be reimplemented in a much simpler way, although it needs slightly more code. (Simpler because less special cases.)
2017-06-23 20:42:20 +02:00
int msg_really_quiet;
options: change --msg-level option Make it accept "," as separator, instead of only ":". Do this by using the key-value-list parser. Before this, the option was stored as a string, with the option parser verifying that the option value as correct. Now it's stored pre-parsed, although the log levels still require separate verification and parsing-on-use to some degree (which is why the msg-level option type doesn't go away). Because the internal type changes, the client API "native" type also changes. This could be prevented with some more effort, but I don't think it's worth it - if MPV_FORMAT_STRING is used, it still works the same, just with a different separator on read accesses.
2015-02-06 16:48:52 +01:00
char **msg_levels;
msg: remove global state
2013-12-21 23:11:12 +01:00
int msg_color;
int msg_module;
msg: add --msgtime option to add timestamps to each output message Will be helpful to track down strange wait times and such issues, as well when you have develop something timing related. (Then you may print timestamps in your debug output, and the --msgtime timestamps will help giving context.)
2014-02-28 22:45:34 +01:00
int msg_time;
msg: add --log-file option This allows getting the log at all with --no-terminal and without having to retrieve log messages manually with the client API. The log level is hardcoded to -v. A higher log level would lead to too much log output (huge file sizes and latency issues due to waiting on the disk), and isn't too useful in general anyway. For debugging, the terminal can be used instead.
2015-01-26 11:31:02 +01:00
char *log_file;
msg: change --msglevel, reduce legacy glue Basically, reimplement --msglevel. Instead of making the new msg code use the legacy code, make the legacy code use the reimplemented functionality. The handling of the deprecated --identify switch changes. It temporarily stops working; this will be fixed in later commits. The actual sub-options syntax (like --msglevel-vo=...) goes away, but I bet nobody knew about this or used this anyway.
2013-12-18 19:04:30 +01:00
player: do not let pseudo-gui override user config settings Seems like this confused users quite often. Instead of --profile=pseudo-gui, --player-operation-mode=pseudo-gui now has to be used to invoke pseudo GUI mode. The old way still works, and still behaves in the old way.
2016-09-23 21:24:50 +02:00
int operation_mode;
core: add --reset-on-next-file option This option can be used to selectively reset settings when playing the next file in the playlist (i.e. restore mplayer and mplayer2 behavior). Might remove this option again should it turn out that nobody uses it.
2013-04-10 21:06:00 +02:00
char **reset_options;
options: deprecate 'lua' based options/dirs for 'script' - --lua and --lua-opts change to --script and --script-opts - 'lua' default script dirs change to 'scripts' - DOCS updated - 'lua-settings' dir was _not_ modified The old lua-based names/dirs still work, but display a warning. Signed-off-by: wm4 <wm4@nowhere>
2014-12-15 00:31:30 +01:00
char **script_files;
char **script_opts;
Add the on-screen-controller Signed-off-by: wm4 <wm4@nowhere>
2013-09-26 00:56:41 +02:00
int lua_load_osc;
player: integrate ytdl_hook.lua
2014-11-19 18:51:53 +01:00
int lua_load_ytdl;
options: add --ytdl-format option for youtube-dl format It's passed with the '--format' option to youtube-dl. If it isn't set, we don't pass '--format best' so that youtube-dl can use the options from its configuration file. Signed-off-by: wm4 <wm4@nowhere>
2014-11-19 23:33:28 +01:00
char *lua_ytdl_format;
ytdl: add "--ytdl-params" option This option allows the user to pass non-supported options directly to youtube-dl, such as "--proxy URL", "--username USERNAME" and '--password PASSWORD". There is no sanity checking so it's possible to break things (i.e. if you pass "--version" mpv exits with random JSON error). Signed-off-by: wm4 <wm4@nowhere>
2015-02-22 21:32:42 +01:00
char **lua_ytdl_raw_options;
lua: integrate stats.lua script Signed-off-by: wm4 <wm4@nowhere> Rename --stats to --load-stats-overlay and add an entry to options.rst over the original commit. Signed-off-by: wm4 <wm4@nowhere>
2017-09-27 01:17:47 +02:00
int lua_load_stats;
options: add --ytdl-format option for youtube-dl format It's passed with the '--format' option to youtube-dl. If it isn't set, we don't pass '--format best' so that youtube-dl can use the options from its configuration file. Signed-off-by: wm4 <wm4@nowhere>
2014-11-19 23:33:28 +01:00
lua: add option to disable auto-loading of lua scripts
2014-02-28 22:25:48 +01:00
int auto_load_scripts;
core: add --reset-on-next-file option This option can be used to selectively reset settings when playing the next file in the playlist (i.e. restore mplayer and mplayer2 behavior). Might remove this option again should it turn out that nobody uses it.
2013-04-10 21:06:00 +02:00
audio/out: deprecate "exclusive" sub-options And introduce a global option which does this. Or more precisely, this deprecates the global wasapi and coreaudio options, and adds a new one that merges their functionality. (Due to the way the sub-option deprecation mechanism works, this is simpler.)
2016-09-05 21:07:34 +02:00
int audio_exclusive;
audio: add option for falling back to ao_null The manpage entry explains this. (Maybe this option could be always enabled and removed. I don't quite remember what valid use-cases there are for just disabling audio entirely, other than that this is also needed for audio decoder init failure.)
2015-10-05 18:53:02 +02:00
int ao_null_fallback;
player: add --audio-stream-silence Completely insane that this has to be done. Crap for compensating HDMI crap.
2016-08-09 16:22:06 +02:00
int audio_stream_silence;
player: add --audio-wait-open options Complements the option added in the previous commit.
2016-08-09 16:26:44 +02:00
float audio_wait_open;
core: add --force-window This commit adds the --force-window option, which will cause mpv always to create a window when started. This can be useful when pretending that mpv is a GUI application (which it isn't, but users pretend anyway), and playing audio files would run mpv in the background without giving a window to control it. This doesn't actually create the window immediately: it only does so only after initializing playback and when it is clear that there won't be any actual video. This could be a problem when starting slow or completely stuck network streams (mpv would remain frozen in the background), or if video initialization somehow is stuck forever in an in-between state (like when the decoder doesn't output a video frame, but doesn't return an error either). Well, we can pretend only so much that mpv is a GUI application.
2013-10-02 01:15:59 +02:00
int force_vo;
audio: drop --softvol=no and --softvol=auto Drop the code for switching the volume options and properties between af_volume and AO volume controls. interface-changes.rst mentions the changes in detail. Do this because this was exceedingly complex and had other problems as well. It was also very hard to test. It's just not worth the trouble. Some leftovers like AOCONTROL_HAS_PER_APP_VOLUME will be removed at a later point. Fixes #3322.
2016-07-09 18:31:18 +02:00
float softvol_volume;
audio: merge --replaygain-track and --replaygain-album into one option This is probably better than separate options. For example, the user does not have to guess which one is applied if both options are enabled.
2017-04-27 00:21:17 +02:00
int rgain_mode;
audio: move replaygain control to top-level options af_volume is deprecated, and so are its replaygain sub-options. To make it possible to use replaygain without deprecated options (and of course to make it available at all after af_volume is dropped), reintroduce them as top-level options. This also means that they are easily changeable at runtime by using them as properties. Change the "volume" property to use the new update mechanism as well. We don't actually bother sharing the implementation between new and deprecated mechanisms, as the deprecated one will simply be deleted. For the from_dB() functions, we mention anders' copyright, although I'm not sure if a mere formula is copyrightable. This will have to be determined later. This whole change is mostly untested. Our distributed human CI will take care of it.
2017-04-26 21:45:50 +02:00
float rgain_preamp; // Set replaygain pre-amplification
int rgain_clip; // Enable/disable clipping prevention
float rgain_fallback;
audio: drop --softvol=no and --softvol=auto Drop the code for switching the volume options and properties between af_volume and AO volume controls. interface-changes.rst mentions the changes in detail. Do this because this was exceedingly complex and had other problems as well. It was also very hard to test. It's just not worth the trouble. Some leftovers like AOCONTROL_HAS_PER_APP_VOLUME will be removed at a later point. Fixes #3322.
2016-07-09 18:31:18 +02:00
int softvol_mute;
options: move mixer.h options to struct
2012-01-21 08:28:07 +01:00
float softvol_max;
audio: add -gapless-audio option If the option is enabled and all audio has been buffered to the AO, then the player will move to the next file without waiting for the buffered audio to drain, while leaving the AO initialized. If the playback of the next file starts quickly enough (before the AO buffer empties) then it should continue writing audio to the same AO with no gap in between.
2010-11-12 13:06:37 +01:00
int gapless_audio;
vo: remove and cleanup globals Removes almost every global variabel in vo.h and puts them in a special struct in MPOpts for video output related options. Also we completly remove the options/globals pts and refresh rate because they were unused.
2013-03-04 17:40:21 +01:00
options: make mp_vo_opts options an actual sub-option group Just a minor refactor along the planned option change. This commit will make it easier to update (i.e. copy) the VO options without copying _all_ options. For now, behavior should be equivalent, though. (The VO options were put into a separate struct quite early - when all global variables were removed from the source code. It wasn't clear whether the separate struct would have any actual purpose, but it seems it will now. Awesome, huh.)
2016-08-30 23:50:57 +02:00
mp_vo_opts *vo;
ao: use a local option struct Instead of accessing MPOpts.
2018-05-21 15:11:19 +02:00
struct ao_opts *ao_opts;
vo: remove and cleanup globals Removes almost every global variabel in vo.h and puts them in a special struct in MPOpts for video output related options. Also we completly remove the options/globals pts and refresh rate because they were unused.
2013-03-04 17:40:21 +01:00
char *wintitle;
player: add --media-title option Requested by ChrisK2.
2014-09-02 22:28:11 +02:00
char *media_title;
vo: remove and cleanup globals Removes almost every global variabel in vo.h and puts them in a special struct in MPOpts for video output related options. Also we completly remove the options/globals pts and refresh rate because they were unused.
2013-03-04 17:40:21 +01:00
video: redo video equalizer option handling I really wouldn't care much about this, but some parts of the core code are under HAVE_GPL, so there's some need to get rid of it. Simply turn the video equalizer from its current fine-grained handling with vf/vo fallbacks into global options. This makes updating them much simpler. This removes any possibility of applying video equalizers in filters, which affects vf_scale, and the previously removed vf_eq. Not a big loss, since the preferred VOs have this builtin. Remove video equalizer handling from vo_direct3d, vo_sdl, vo_vaapi, and vo_xv. I'm not going to waste my time on these legacy VOs. vo.eq_opts_cache exists _only_ to send a VOCTRL_SET_EQUALIZER, which exists _only_ to trigger a redraw. This seems silly, but for now I feel like this is less of a pain. The rest of the equalizer using code is self-updating. See commit 96b906a51d5 for how some video equalizer code was GPL only. Some command line option names and ranges can probably be traced back to a GPL only committer, but we don't consider these copyrightable.
2017-08-22 17:01:35 +02:00
struct mp_csp_equalizer_opts *video_equalizer;
vo: remove and cleanup globals Removes almost every global variabel in vo.h and puts them in a special struct in MPOpts for video output related options. Also we completly remove the options/globals pts and refresh rate because they were unused.
2013-03-04 17:40:21 +01:00
x11: enable screensaver when paused, rename/change --stop-xscreensaver Use the recently introduced screensaver VOCTRLs to control the screensaver in the X11 backend. This means the behavior when paused changes: the old code always kept the screensaver disabled, but now the screensaver is reenabled on pausing. Rename the --stop-xscreensaver option to --stop-screensaver and make it more generic. Now it affects all backends that respond to the screensaver VOCTRLs.
2013-06-14 00:24:41 +02:00
int stop_screensaver;
options: cosmetics: move cursor_autohide_delay definition No functional changes.
2013-09-08 02:07:20 +02:00
int cursor_autohide_delay;
mplayer: add --cursor-autohide-fs-only option This option makes the cursor always visible in windowed mode. Apparently, this is what (some?) Windows and OSX users expect. It's disabled by default for now. Restructure the cursor hide logic a bit for this purpose.
2013-09-08 02:46:19 +02:00
int cursor_autohide_fs;
options: cosmetics: move cursor_autohide_delay definition No functional changes.
2013-09-08 02:07:20 +02:00
video: add --video-rotate option for controlling auto-rotation
2014-05-24 14:08:39 +02:00
int video_rotate;
core: redo how codecs are mapped, remove codecs.conf Use codec names instead of FourCCs to identify codecs. Rewrite how codecs are selected and initialized. Now each decoder exports a list of decoders (and the codec it supports) via add_decoders(). The order matters, and the first decoder for a given decoder is preferred over the other decoders. E.g. all ad_mpg123 decoders are preferred over ad_lavc, because it comes first in the mpcodecs_ad_drivers array. Likewise, decoders within ad_lavc that are enumerated first by libavcodec (using av_codec_next()) are preferred. (This is actually critical to select h264 software decoding by default instead of vdpau. libavcodec and ffmpeg/avconv use the same method to select decoders by default, so we hope this is sane.) The codec names follow libavcodec's codec names as defined by AVCodecDescriptor.name (see libavcodec/codec_desc.c). Some decoders have names different from the canonical codec name. The AVCodecDescriptor API is relatively new, so we need a compatibility layer for older libavcodec versions for codec names that are referenced internally, and which are different from the decoder name. (Add a configure check for that, because checking versions is getting way too messy.) demux/codec_tags.c is generated from the former codecs.conf (minus "special" decoders like vdpau, and excluding the mappings that are the same as the mappings libavformat's exported RIFF tables). It contains all the mappings from FourCCs to codec name. This is needed for demux_mkv, demux_mpg, demux_avi and demux_asf. demux_lavf will set the codec as determined by libavformat, while the other demuxers have to do this on their own, using the mp_set_audio/video_codec_from_tag() functions. Note that the sh_audio/video->format members don't uniquely identify the codec anymore, and sh->codec takes over this role. Replace the --ac/--vc/--afm/--vfm with new --vd/--ad options, which provide cover the functionality of the removed switched. Note: there's no CODECS_FLAG_FLIP flag anymore. This means some obscure container/video combinations (e.g. the sample Film_200_zygo_pro.mov) are played flipped. ffplay/avplay doesn't handle this properly either, so we don't care and blame ffmeg/libav instead.
2013-02-09 15:15:19 +01:00
char *audio_decoders;
char *video_decoders;
audio: add --audio-spdif as new method for enabling passthrough This provides a new method for enabling spdif passthrough. The old method via --ad (--ad=spdif:ac3 etc.) is deprecated. The deprecated method will probably stop working at some point. This also supports PCM fallback. One caveat is that it will lose at least 1 audio packet in doing so. (I don't care enough to prevent this.) (This is named after the old S/PDIF connector, because it uses the same underlying technology as far as the higher level protoco is concerned. Also, the user should be renamed that passthrough is backwards.)
2015-06-05 22:35:43 +02:00
char *audio_spdif;
core: redo how codecs are mapped, remove codecs.conf Use codec names instead of FourCCs to identify codecs. Rewrite how codecs are selected and initialized. Now each decoder exports a list of decoders (and the codec it supports) via add_decoders(). The order matters, and the first decoder for a given decoder is preferred over the other decoders. E.g. all ad_mpg123 decoders are preferred over ad_lavc, because it comes first in the mpcodecs_ad_drivers array. Likewise, decoders within ad_lavc that are enumerated first by libavcodec (using av_codec_next()) are preferred. (This is actually critical to select h264 software decoding by default instead of vdpau. libavcodec and ffmpeg/avconv use the same method to select decoders by default, so we hope this is sane.) The codec names follow libavcodec's codec names as defined by AVCodecDescriptor.name (see libavcodec/codec_desc.c). Some decoders have names different from the canonical codec name. The AVCodecDescriptor API is relatively new, so we need a compatibility layer for older libavcodec versions for codec names that are referenced internally, and which are different from the decoder name. (Add a configure check for that, because checking versions is getting way too messy.) demux/codec_tags.c is generated from the former codecs.conf (minus "special" decoders like vdpau, and excluding the mappings that are the same as the mappings libavformat's exported RIFF tables). It contains all the mappings from FourCCs to codec name. This is needed for demux_mkv, demux_mpg, demux_avi and demux_asf. demux_lavf will set the codec as determined by libavformat, while the other demuxers have to do this on their own, using the mp_set_audio/video_codec_from_tag() functions. Note that the sh_audio/video->format members don't uniquely identify the codec anymore, and sh->codec takes over this role. Replace the --ac/--vc/--afm/--vfm with new --vd/--ad options, which provide cover the functionality of the removed switched. Note: there's no CODECS_FLAG_FLIP flag anymore. This means some obscure container/video combinations (e.g. the sample Film_200_zygo_pro.mov) are played flipped. ffplay/avplay doesn't handle this properly either, so we don't care and blame ffmeg/libav instead.
2013-02-09 15:15:19 +01:00
options: move most subtitle and OSD rendering options to sub structs Remove them from the big MPOpts struct and move them to their sub structs. In the places where their fields are used, create a private copy of the structs, instead of accessing the semi-deprecated global option struct instance (mpv_global.opts) directly. This actually makes accessing these options finally thread-safe. They weren't even if they should have for years. (Including some potential for undefined behavior when e.g. the OSD font was changed at runtime.) This is mostly transparent. All options get moved around, but most users of the options just need to access a different struct (changing sd.opts to a different type changes a lot of uses, for example). One thing which has to be considered and could cause potential regressions is that the new option copies must be explicitly updated. sub_update_opts() takes care of this for example. Another thing is that writing to the option structs manually won't work, because the changes won't be propagated to other copies. Apparently the only affected case is the implementation of the sub-step command, which tries to change sub_delay. Handle this one explicitly (osd_changed() doesn't need to be called anymore, because changing the option triggers UPDATE_OSD, and updates the OSD as a consequence). The way the option value is propagated is rather hacky, but for now this will do.
2017-12-29 17:19:25 +01:00
struct mp_subtitle_opts *subs_rend;
struct mp_osd_render_opts *osd_rend;
options: Move osd_level and osd_duration to options struct
2009-03-30 01:06:58 +02:00
int osd_level;
int osd_duration;
OSD: support displaying fractional part of current position Add option -osd-fractions which enables display of fractional seconds when showing the current playback time on OSD. Based on a patch from Christian <herr.mitterlehner@gsmpaaiml.com> but with several modifications.
2011-04-12 17:11:12 +02:00
int osd_fractions;
command: add --osd-on-seek option defaulting to bar Restores behaviour prior to aef2ed5dc13e37dec0670c451b4369b151d5c65f. That change was apparently unpopular. However, given the amount of complaining over how hard it is to change the defaults by rebinding every key, I think the extra option introduced by this commit is justified. Technically not all behaviour is restored, because now --no-osd-bar will not instead display the msg text on seek. I think that feature was a little weird and is now easy enough to remedy with the --osd-on-seek option.
2018-01-22 00:36:08 +01:00
int osd_on_seek;
player: add option to disable video OSD Normally, OSD can be disabled with --osd-level=0. But this also disables terminal OSD, and some users want _only_ the terminal OSD. Add --video-osd=no, which essentially disables the video OSD. Ideally, it should probably be possible to control terminal and video OSD levels independently, but that would require separate OSD timers (and other state) for both components, so don't do it. But because the current situation isn't too ideal, add a threat to the manpage that might be changed in the future. Fixes #3387.
2016-08-28 18:15:37 +02:00
int video_osd;
mplayer: remove benchmarking/CPU accounting code The code used for benchmarking and showing CPU stats in the status line was inaccurate, misleading and fragile. The final nail in the coffin is the fact that many libav decoders are multithreaded now, and mplayer couldn't possibly measure the CPU time consumed by them. Add the --untimed option. This makes the video untimed, just like --benchmark did (still requires disabling audio synchronization).
2012-07-30 00:27:50 +02:00
int untimed;
core: re-add -dumpstream as --stream-dump Apparently useful for dumping DVD. Could also be used to rip streams with libquvi and such, but for that there are better tools. Actually I doubt there aren't better tools to dump DVDs, but whatever, this was a feature request, so I don't need a good reason.
2013-05-11 22:40:46 +02:00
char *stream_dump;
player: add experimental stream recording feature This is basically a WIP, but it can't remain in a branch forever. A warning is print when using it as it's still a bit "shaky".
2017-02-07 17:05:17 +01:00
char *record_file;
player: add an option to abort playback on partial init failures This is probably what libmpv users want; and it also improves error reporting (or we'd have to add a way to communicate such mid-playback failures as events).
2014-10-28 19:51:44 +01:00
int stop_playback_on_init_failure;
Move loop_times to option struct
2008-04-21 04:18:40 +02:00
int loop_times;
player: add a --loop-file option Unlike --loop, loops a file instead of the playlist.
2014-04-17 23:55:04 +02:00
int loop_file;
mplayer: reshuffle on every loop if --loop and --shuffle are used See github issue #194. Unfortunately, this breaks the property that going back in the playlist always works as expected. This changes, because the playlist_prev command will work on the reshuffled playlist, instead of loading the previously played files in order. If this ever becomes an issue, I might revert this commit.
2013-08-19 00:50:39 +02:00
int shuffle;
Add option -noordered-chapters.
2009-04-08 01:37:27 +02:00
int ordered_chapters;
matroska: add --ordered-chapters-files option This option takes a playlist. The playlist will then be used as list of potential segment files for use with ordered chapters.
2013-12-14 21:52:37 +01:00
char *ordered_chapters_files;
core: ordered chapters: add heuristic for merging inaccurate chapters Some Matroska files have inaccurate ordered chapter endpoints, and so parts where one chapter should end and the next begin at the same timestamp were not merged. This resulted in an unnecessary seek over a minimal distance. Add a heuristic to merge parts with a minimal gap or overlap between them. Based on patch by Hector Martin <hector@marcansoft.com>.
2010-11-26 15:56:05 +01:00
int chapter_merge_threshold;
command: more intuitive chapter seek behavior If close to chapter start, skipping back goes to previous chapter (no change). If more than <threshold> seconds in, skipping back will now go to the beginning of the current chapter instead. The threshold is set by the new option --chapter-seek-threshold and defaults to 5 seconds. A negative value disables the new functionality.
2013-08-14 03:25:50 +02:00
double chapter_seek_threshold;
player: add --chapters-file option Note that you can't pass .cue or .edl files to it, at least not yet. Requested in context of allowing to specify custom chapters. For that to work well, we probably need to add some sort of chapter metadata pseudo-demuxer.
2014-11-02 16:47:23 +01:00
char *chapter_file;
core: add a playlist demuxer Modeled after the old playlist_parser.c, but actually new code, and it works a bit differently. Demuxers (and sometimes streams) are the component that should be used to open files and to determine the file format. This was already done for subtitles, but playlists still use a separate code path.
2013-08-25 20:40:21 +02:00
int load_unsafe_playlists;
player: add --merge-files option
2013-11-19 22:36:33 +01:00
int merge_files;
options: move various mplayer.c options to option struct Following options were moved: [no]quiet, [no]autosync, softsleep, [no]rtc, rtc-device.
2010-11-12 21:04:16 +01:00
int quiet;
options: change --no-config option, make it apply to input.conf as well Simplify --no-config and make it a normal flag option, and doesn't take an argument anymore. You can get the same behavior by using --no-config and then --include to explicitly load a certain config file. Make --no-config work for input.conf as well. Make it so that --input:conf=file still works in this case. As a technically unrelated change, the file argument now works as one would expect, instead of making it relatively to "~/.mpv/". This makes for simpler code and easier to understand option semantics. We can also print better error messages.
2013-02-08 23:52:06 +01:00
int load_config;
config: add a --config-dir option to force config directory Useful for slave-mode like uses, and not as radical as --no-config.
2014-02-25 21:04:04 +01:00
char *force_configdir;
core: remove a number of global variables Move them into per-instance structs. This should get rid of all global variables in mplayer.c (not counting those referenced by cfg-mplayer.h). In core/input/ar.c, just remove checking the slave_mode variable. I'm not sure what this code was supposed to achieve, but slave mode is broken, slave mode is actually infeasible on OSX (ar.c is completely OSX specific), and the correct way of doing this would be to disable this input device per command line switch.
2013-03-08 02:08:02 +01:00
int use_filedir_conf;
player: simplistic HLS bitrate selection --hls-bitrate=min/max lets you select the min or max bitrate. That's it. Something more sophisticated might be possible, but is probably not even worth the effort.
2014-09-01 23:47:27 +02:00
int hls_bitrate;
Support for multiple editions in Matroska Add code to intelligently choose an appropriate Matroska edition when there are several. Will choose, in descending order of preference: the edition chosen by the user through the option "-edition <edition id>" if it exists, the first edition with EditionFlagDefault set to 1 if there is one, or the first edition.
2009-12-01 13:28:34 +01:00
int edition_id;
options.h: Field order cosmetics Move correct_pts and user_correct_pts next to each other. loop_times was accidentally added between them.
2008-04-25 12:30:44 +02:00
int correct_pts;
core: do initial A-V sync by modifying audio stream Add code to enforce matching pts with video when (re)starting the audio stream, by either cutting away the first samples or inserting silence at the beginning. New option -noinitial-audio-sync can be used to disable this and return to old behavior.
2010-11-13 18:27:01 +01:00
int initial_audio_sync;
player: add display sync mode If this mode is enabled, the player tries to strictly synchronize video to display refresh. It will adjust playback speed to match the display, so if you play 23.976 fps video on a 24 Hz screen, playback speed is increased by approximately 1/1000. Audio wll be resampled to keep up with playback. This is different from the default sync mode, which will sync video to audio, with the consequence that video might skip or repeat a frame once in a while to make video keep up with audio. This is still unpolished. There are some major problems as well; in particular, mkv VFR files won't work well. The reason is that Matroska is terrible and rounds timestamps to milliseconds. This makes it rather hard to guess the framerate of a section of video that is playing. We could probably fix this by just accepting jittery timestamps (instead of explicitly disabling the sync code in this case), but I'm not ready to accept such a solution yet. Another issue is that we are extremely reliant on OS video and audio APIs working in an expected manner, which of course is not too often the case. Consequently, the new sync mode is a bit fragile.
2015-08-10 18:43:25 +02:00
int video_sync;
double sync_max_video_change;
double sync_max_audio_change;
player: add audio drop/duplicate mode Not very robust in the moment.
2015-10-27 20:56:46 +01:00
double sync_audio_drop_size;
core: add support for precise non-keyframe-limited seeks Add support for seeking to an arbitrary non-keyframe position by decoding video starting from the previous keyframe. Whether to use this functionality when seeking is controlled by the new option -hr-seek and a new third argument to the "seek" command. The default is to use it for absolute seeks (like chapter seeks) but not for relative ones. Because there's currently no support for cutting encoded audio some desync is expected if encoded audio passthrough is used. Currently precise seeks always go to the first frame with timestamp equal to or greater than the target position; there's no support for "matching or earlier" backwards seeks at frame level.
2010-12-15 00:09:47 +01:00
int hr_seek;
options, core/hrseek: add --hr-seek-demuxer-offset Some demuxers do not accurately seek to a keyframe before a given time but instead start too late. This means that precise seeks cannot work either. Most notably the libavformat mpeg demuxer exhibits this behavior depending on the file being played (with the internal mpeg demuxer precise seeks don't work at all). Add new option --hr-seek-demuxer-offset which can be used as a workaround with such demuxers. The value of the option is subtracted from the seek target position given to the demuxer when doing a precise seek.
2011-11-06 15:54:57 +01:00
float hr_seek_demuxer_offset;
options: add --hr-seek-framedrop option This allows disabling of decoder framedrop during hr-seek. It's basically another useless option, but it will help exploring whether this framedropping really makes seeking faster, or whether disabling it helps with precise seeking (especially frame backstepping).
2014-05-07 22:01:17 +02:00
int hr_seek_framedrop;
core: remove a number of global variables Move them into per-instance structs. This should get rid of all global variables in mplayer.c (not counting those referenced by cfg-mplayer.h). In core/input/ar.c, just remove checking the slave_mode variable. I'm not sure what this code was supposed to achieve, but slave mode is broken, slave mode is actually infeasible on OSX (ar.c is completely OSX specific), and the correct way of doing this would be to disable this input device per command line switch.
2013-03-08 02:08:02 +01:00
float audio_delay;
float default_max_pts_correction;
options: move various mplayer.c options to option struct Following options were moved: [no]quiet, [no]autosync, softsleep, [no]rtc, rtc-device.
2010-11-12 21:04:16 +01:00
int autosync;
commands: replace --hardframedrop, change framedropping property Replace --hardframedrop with --framedrop=hard. Rename the framedrop property from "framedropping" to "framedrop" for the sake of making command line options have the same name as their corresponding property. Change the property to accept choice values instead of numeric values. Remove unused/forgotten auto_quality variable.
2012-09-17 08:38:19 +02:00
int frame_dropping;
video: add option to reduce latency by 1 or 2 frames The playback start logic explicitly waits until the first frame has been displayed. Usually this will introduce a wait of 1 vsync. For normal playback this doesn't matter, but with respect to low latency needs, this only leads to additional data getting queued up in the demuxer or network buffers. Another thing is that the timing logic decodes 1 frame ahead (= 1 frame extra latency) to determine the exact duration of a frame. To be fair, there doesn't really seem to be a hard reason why this is needed. With the current code, enabling the option does lead to A/V desync sometimes (if the demuxer FPS is too inaccurate), and also frame drops at playback start in some situations. But this all seems to be avoidable, if the timing logic were to be rewritten completely, which should probably happen in the future. Thus the new option comes with the warning that it can be removed any time. This is also why the option has "hack" in the name.
2018-03-02 15:37:34 +01:00
int video_latency_hacks;
options: more mplayer.c options moved to option struct Following options were moved: autoq, benchmark, [no]term-osd, term-osd-esc, playing-msg, [no]idle, [no]consolecontrols, list-properties.
2010-11-13 22:10:58 +01:00
int term_osd;
player: add --term-osd-bar, which shows a status bar on the terminal Feature request from github issue #451. Disabled by default, will probably stay this way.
2014-01-15 16:14:37 +01:00
int term_osd_bar;
char *term_osd_bar_chars;
options: more mplayer.c options moved to option struct Following options were moved: autoq, benchmark, [no]term-osd, term-osd-esc, playing-msg, [no]idle, [no]consolecontrols, list-properties.
2010-11-13 22:10:58 +01:00
char *playing_msg;
player: add --osd-playing-msg option
2014-09-02 00:09:03 +02:00
char *osd_playing_msg;
options: add --status-msg Replaces the status line with a custom string. This is probably useful for hacking old slave mode applications into working again. Even if not, this might be generally useful.
2012-10-02 03:12:09 +02:00
char *status_msg;
osd: add --osd-status-msg option for custom OSD status
2013-02-16 22:14:33 +01:00
char *osd_status_msg;
player: allow overriding OSD message for all OSD levels Until now, you could override only level 3 with --osd-status-msg. Extend this, add add --osd-msg1 to --osd-msg3 (one for each OSD level). OSD level 0 always means disable OSD, so that isn't included. --osd-msg3 corresponds to --osd-status-msg, but they're not exactly the same. To allow more customization, --osd-msgN do not include the OSD symbol. The symbol can be manually added with "${osd-sym-cc}". We keep the "old" option for some short-term compatibility. --osd-msg1 should be particularly useful; for example you could do: --osd-msg1='${?pause==yes:${osd-sym-cc}}' to display a "paused" symbol when paused, and nothing during normal playback. (Although admittedly, the syntax is quite a bit of work.)
2014-09-18 01:19:27 +02:00
char *osd_msg[3];
options: more mplayer.c options moved to option struct Following options were moved: autoq, benchmark, [no]term-osd, term-osd-esc, playing-msg, [no]idle, [no]consolecontrols, list-properties.
2010-11-13 22:10:58 +01:00
int player_idle_mode;
int consolecontrols;
player: add --playlist-pos option Oddly often requested.
2015-08-22 22:08:17 +02:00
int playlist_pos;
options: rename -ss and -endpos, allow relative times Rename the -ss option to -start, and -endpos to -length. Add a -end option. The -end option always specifies an absolute end time, as opposed to -endpos/-length. All these options (--start, --end, --length) now accept relative times. Percent positions (e.g. "--start=30%") are interpreted as fractions of the file duration. Negative times (e.g. "--start=-1:00) are interpreted relative to the end of the file. Chapters (e.g. "--start=#3") yield the chapter's time position. The chapter support might be able to replace --chapter completely, but for now I am not sure how well this works out with e.g. DVDs and BDs, and a separate --chapter option is useful interface-wise.
2012-11-15 18:49:17 +01:00
struct m_rel_time play_start;
struct m_rel_time play_end;
struct m_rel_time play_length;
Implement backwards playback See manpage additions. This is a huge hack. You can bet there are shit tons of bugs. It's literally forcing square pegs into round holes. Hopefully, the manpage wall of text makes it clear enough that the whole shit can easily crash and burn. (Although it shouldn't literally crash. That would be a bug. It possibly _could_ start a fire by entering some sort of endless loop, not a literal one, just something where it tries to do work without making progress.) (Some obvious bugs I simply ignored for this initial version, but there's a number of potential bugs I can't even imagine. Normal playback should remain completely unaffected, though.) How this works is also described in the manpage. Basically, we demux in reverse, then we decode in reverse, then we render in reverse. The decoding part is the simplest: just reorder the decoder output. This weirdly integrates with the timeline/ordered chapter code, which also has special requirements on feeding the packets to the decoder in a non-straightforward way (it doesn't conflict, although a bugmessmass breaks correct slicing of segments, so EDL/ordered chapter playback is broken in backward direction). Backward demuxing is pretty involved. In theory, it could be much easier: simply iterating the usual demuxer output backward. But this just doesn't fit into our code, so there's a cthulhu nightmare of shit. To be specific, each stream (audio, video) is reversed separately. At least this means we can do backward playback within cached content (for example, you could play backwards in a live stream; on that note, it disables prefetching, which would lead to losing new live video, but this could be avoided). The fuckmess also meant that I didn't bother trying to support subtitles. Subtitles are a problem because they're "sparse" streams. They need to be "passively" demuxed: you don't try to read a subtitle packet, you demux audio and video, and then look whether there was a subtitle packet. This means to get subtitles for a time range, you need to know that you demuxed video and audio over this range, which becomes pretty messy when you demux audio and video backwards separately. Backward display is the most weird (and potentially buggy) part. To avoid that we need to touch a LOT of timing code, we negate all timestamps. The basic idea is that due to the navigation, all comparisons and subtractions of timestamps keep working, and you don't need to touch every single of them to "reverse" them. E.g.: bool before = pts_a < pts_b; would need to be: bool before = forward ? pts_a < pts_b : pts_a > pts_b; or: bool before = pts_a * dir < pts_b * dir; or if you, as it's implemented now, just do this after decoding: pts_a *= dir; pts_b *= dir; and then in the normal timing/renderer code: bool before = pts_a < pts_b; Consequently, we don't need many changes in the latter code. But some assumptions inhererently true for forward playback may have been broken anyway. What is mainly needed is fixing places where values are passed between positive and negative "domains". For example, seeking and timestamp user display always uses positive timestamps. The main mess is that it's not obvious which domain a given variable should or does use. Well, in my tests with a single file, it suddenly started to work when I did this. I'm honestly surprised that it did, and that I didn't have to change a single line in the timing code past decoder (just something minor to make external/cached text subtitles display). I committed it immediately while avoiding thinking about it. But there really likely are subtle problems of all sorts. As far as I'm aware, gstreamer also supports backward playback. When I looked at this years ago, I couldn't find a way to actually try this, and I didn't revisit it now. Back then I also read talk slides from the person who implemented it, and I'm not sure if and which ideas I might have taken from it. It's possible that the timestamp reversal is inspired by it, but I didn't check. (I think it claimed that it could avoid large changes by changing a sign?) VapourSynth has some sort of reverse function, which provides a backward view on a video. The function itself is trivial to implement, as VapourSynth aims to provide random access to video by frame numbers (so you just request decreasing frame numbers). From what I remember, it wasn't exactly fluid, but it worked. It's implemented by creating an index, and seeking to the target on demand, and a bunch of caching. mpv could use it, but it would either require using VapourSynth as demuxer and decoder for everything, or replacing the current file every time something is supposed to be played backwards. FFmpeg's libavfilter has reversal filters for audio and video. These require buffering the entire media data of the file, and don't really fit into mpv's architecture. It could be used by playing a libavfilter graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 02:10:51 +02:00
int play_dir;
player: handle rebasing start time differently Most of this is explained in the DOCS additions. This gives us slightly more sanity, because there is less interaction between the various parts. The goal is getting rid of the video_offset entirely. The simplification extends to the user API. In particular, we don't need to fix missing parts in the API, such as the lack for a seek command that seeks relatively to the start time. All these things are now transparent. (If someone really wants to know the real timestamps/start time, new properties would have to be added.)
2015-11-16 22:47:17 +01:00
int rebase_start_time;
core: remove a number of global variables Move them into per-instance structs. This should get rid of all global variables in mplayer.c (not counting those referenced by cfg-mplayer.h). In core/input/ar.c, just remove checking the slave_mode variable. I'm not sure what this code was supposed to achieve, but slave mode is broken, slave mode is actually infeasible on OSX (ar.c is completely OSX specific), and the correct way of doing this would be to disable this input device per command line switch.
2013-03-08 02:08:02 +01:00
int play_frames;
command: implement A-B loops Probably needs to be polished a bit more. Also, might require a key binding that can set/clear the loop points in a more intuitive way. For now, something like this can be put into input.conf to use it: ctrl+y set ab-loop-a ${time-pos} # set A ctrl+x set ab-loop-b ${time-pos} # set B ctrl+c set ab-loop-a no # clear (mostly) Fixes #1241.
2014-11-18 00:09:42 +01:00
double ab_loop[2];
core: remove a number of global variables Move them into per-instance structs. This should get rid of all global variables in mplayer.c (not counting those referenced by cfg-mplayer.h). In core/input/ar.c, just remove checking the slave_mode variable. I'm not sure what this code was supposed to achieve, but slave mode is broken, slave mode is actually infeasible on OSX (ar.c is completely OSX specific), and the correct way of doing this would be to disable this input device per command line switch.
2013-03-08 02:08:02 +01:00
double step_sec;
core: add playback resume feature (manual/opt-in) A "watch later" command is now mapped to Shift+Q. This quits the player and stores the playback state in a config file in ~/.mpv/watch_later/. When calling the player with the same file again, playback is resumed at that time position. It's also possible to make mpv save playback state always on quit with the --save-position-on-quit option. Likewise, resuming can be disabled with the --no-resume-playback option. This also attempts to save some playback parameters, like fullscreen state or track selection. This will unconditionally override config settings and command line options (which is probably not what you would expect, but in general nobody will really care about this). Some things are not backed up, because that would cause various problems. Additional subtitle files, video filters, etc. are not stored because that would be too hard and fragile. Volume/mute state are not stored because it would mess up if the system mixer is used, or if the system mixer was readjusted in the meantime. Basically, the tradeoff between perfect state restoration and complexity/fragility makes it not worth to attempt to implement it perfectly, even if the result is a little bit inconsistent.
2013-05-05 19:37:29 +02:00
int position_resume;
int position_save_on_quit;
player: write file name to the watch later config file This simply writes the file name as a comment to the top of the watch later config file. It can be useful to the user for determining whether a watch later config file can be manually removed (e.g. in case the corresponding media file has been deleted) or not.
2014-06-01 18:25:21 +02:00
int write_filename_in_watch_later_config;
options: add option for ignoring patch in resume mechanism Whatever. Fixes #1281.
2014-12-12 23:57:49 +01:00
int ignore_path_in_watch_later_config;
player: add --watch-later-directory option This option allows the user to set the directory where "watch later" files are stored. Signed-off-by: wm4 <wm4@nowhere>
2016-09-08 16:50:39 +02:00
char *watch_later_directory;
core: simplify handling of --pause Rename the struct MPOpts "start_pause" field to "pause". Store the user- pause state in that field, so that both runtime pause toggling and the --pause switch change the same variable. Simplify the initialization of pause so that using --pause and changing the file while paused is exactly the same case (changing the file while paused doesn't unpause, this has been always this way). Also make it a bit more consistent. Before, starting with --pause would reset the pause state for every file, instead of following the usual semantics for option switches (compare with behavior of --fs).
2013-04-25 20:38:22 +02:00
int pause;
core: add --keep-open, which doesn't close the file on EOF The --keep-open option causes mpv not to close the current file. Instead, it will pause, and allow the user to seek around. When seeking beyond the end of the file, mpv does a precise seek back to the previous last known position that produced video output. In some corner cases, mpv might not be able to produce video output at all, despite having created a VO. (Possibly when only 1 frame could be decoded, but the video filter chain queues frames. Then a VO would be created, without sending an actual video frame to the VO.) In these cases, the VO window will not redraw, not even OSD. Based on a patch by coax [1]. [1] http://devel.mplayer2.org/ticket/210#comment:4
2012-11-13 00:56:20 +01:00
int keep_open;
player: add --keep-open-pause=no option Instead of pausing if --keep-open is active, stop at end but continue playing if seeking backwards. And then stop again when end is reached. Signed-off-by: wm4 <wm4@nowhere> Over the PR, the option was renamed, and the manpage additions were slightly changed/enhanced.
2017-03-27 11:34:02 +02:00
int keep_open_pause;
player: add option to control duration of image display The --image-display-duration option controls how long an image is displayed. It's also possible to display the image forever (until manual user interaction stops playback). With this, the core drops the old method to "drain" video (i.e. waiting for the last frame duration on end of playback). Instead, we reuse MPContext.time_frame. The old mechanism was disabled for non-images anyway. Fixes #3425.
2016-08-17 22:45:44 +02:00
double image_display_duration;
player: add complex filter graph support See --lavfi-complex option. This is still quite rough. There's no support for dynamic configuration of any kind. There are probably corner cases where playback might freeze or burn 100% CPU (due to dataflow problems when interaction with libavfilter). Future possible plans might include: - freely switch tracks by providing some sort of default track graph label - automatically enabling audio visualization - automatically mix audio or stack video when multiple tracks are selected at once (similar to how multiple sub tracks can be selected)
2016-02-05 23:19:56 +01:00
char *lavfi_complex;
player: use an array for stream ID options and such This makes the code slightly more generic.
2015-05-22 21:00:24 +02:00
int stream_id[2][STREAM_TYPE_COUNT];
char **stream_lang[STREAM_TYPE_COUNT];
player: add --track-auto-selection option I imagine this is useful. Or maybe it isn't.
2017-08-12 23:43:05 +02:00
int stream_auto_sel;
core: allow disabling display of "album art" in audio files ffmpeg pretends that image attachments (such as contained in ID3v2 metadata) are video streams. It injects the attached pictures as packets into the packet stream received with av_read_frame(). Add the --audio-display option to allow configuring whether attached pictures should be displayed. The default behavior doesn't change (images are displayed). Identify video streams, that are actually image attachments, with "[P]" in the terminal output. Modify the default stream selection such that real video streams are preferred over attached pictures. (This is just for robustness; I do not know of any samples where images are added before actual video streams and could lead to bad default stream selection with the old code.)
2012-12-10 18:52:06 +01:00
int audio_display;
player: filter tags, add --display-tags option This attempts to increase user-friendliness by excluding useless tags. It should be especially helpful with mp4 files, because the FFmpeg mp4 demuxer adds tons of completely useless information to the metadata. Fixes #1403.
2014-12-29 22:51:18 +01:00
char **display_tags;
sub: remove some global variables
2013-04-29 01:49:20 +02:00
options: allow adding multiple files with --audio-file At least 1 person expected that this works this way.
2014-06-18 01:40:20 +02:00
char **audio_files;
options: move some demux options to option struct Following options were moved: audiofile, audiofile-cache, subfile, demuxer, audio-demuxer, sub-demuxer, [no]extbased.
2010-11-11 15:24:17 +01:00
char *demuxer_name;
demux: add a demuxer thread This adds a thread to the demuxer which reads packets asynchronously. It will do so until a configurable minimum packet queue size is reached. (See options.rst additions.) For now, the thread is disabled by default. There are some corner cases that have to be fixed, such as fixing cache behavior with webradios. Note that most interaction with the demuxer is still blocking, so if e.g. network dies, the player will still freeze. But this change will make it possible to remove most causes for freezing. Most of the new code in demux.c actually consists of weird caches to compensate for thread-safety issues (with the previously single-threaded design), or to avoid blocking by having to wait on the demuxer thread. Most of the changes in the player are due to the fact that we must not access the source stream directly. the demuxer thread already accesses it, and the stream stuff is not thread-safe. For timeline stuff (like ordered chapters), we enable the thread for the current segment only. We also clear its packet queue on seek, so that the remaining (unconsumed) readahead buffer doesn't waste memory. Keep in mind that insane subtitles (such as ASS typesetting muxed into mkv files) will practically disable the readahead, because the total queue size is considered when checking whether the minimum queue size was reached.
2014-07-16 22:40:21 +02:00
int demuxer_thread;
player: make playback termination asynchronous Until now, stopping playback aborted the demuxer and I/O layer violently by signaling mp_cancel (bound to libavformat's AVIOInterruptCB mechanism). Change it to try closing them gracefully. The main purpose is to silence those libavformat errors that happen when you request termination. Most of libavformat barely cares about the termination mechanism (AVIOInterruptCB), and essentially it's like the network connection is abruptly severed, or file I/O suddenly returns I/O errors. There were issues with dumb TLS warnings, parsers complaining about incomplete data, and some special protocols that require server communication to gracefully disconnect. We still want to abort it forcefully if it refuses to terminate on its own, so a timeout is required. Users can set the timeout to 0, which should give them the old behavior. This also removes the old mechanism that treats certain commands (like "quit") specially, and tries to terminate the demuxers even if the core is currently frozen. This is for situations where the core synchronized to the demuxer or stream layer while network is unresponsive. This in turn can only happen due to the "program" or "cache-size" properties in the current code (see one of the previous commits). Also, the old mechanism doesn't fit particularly well with the new one. We wouldn't want to abort playback immediately on a "quit" command - the new code is all about giving it a chance to end it gracefully. We'd need some sort of watchdog thread or something equally complicated to handle this. So just remove it. The change in osd.c is to prevent that it clears the status line while waiting for termination. The normal status line code doesn't output anything useful at this point, and the code path taken clears it, both of which is an annoying behavior change, so just let it show the old one.
2018-05-19 18:41:13 +02:00
double demux_termination_timeout;
player: add --demuxer-cache-wait option
2019-05-16 16:29:45 +02:00
int demuxer_cache_wait;
player: add prefetching of the next playlist entry Since for mpv CLI, the player state is a singleton, full prefetching is a bit tricky. We do it only on the demuxer layer. The implementation reuses the old "open thread". This means there is significant potential for regressions even if the new option is not used. This is made worse by the fact that I barely tested this code. The generic mpctx_run_reentrant() wrapper is also removed - this was its only user, and its remains become part of the new implementation.
2017-01-18 19:02:50 +01:00
int prefetch_open;
options: move some demux options to option struct Following options were moved: audiofile, audiofile-cache, subfile, demuxer, audio-demuxer, sub-demuxer, [no]extbased.
2010-11-11 15:24:17 +01:00
char *audio_demuxer_name;
char *sub_demuxer_name;
Implement backwards playback See manpage additions. This is a huge hack. You can bet there are shit tons of bugs. It's literally forcing square pegs into round holes. Hopefully, the manpage wall of text makes it clear enough that the whole shit can easily crash and burn. (Although it shouldn't literally crash. That would be a bug. It possibly _could_ start a fire by entering some sort of endless loop, not a literal one, just something where it tries to do work without making progress.) (Some obvious bugs I simply ignored for this initial version, but there's a number of potential bugs I can't even imagine. Normal playback should remain completely unaffected, though.) How this works is also described in the manpage. Basically, we demux in reverse, then we decode in reverse, then we render in reverse. The decoding part is the simplest: just reorder the decoder output. This weirdly integrates with the timeline/ordered chapter code, which also has special requirements on feeding the packets to the decoder in a non-straightforward way (it doesn't conflict, although a bugmessmass breaks correct slicing of segments, so EDL/ordered chapter playback is broken in backward direction). Backward demuxing is pretty involved. In theory, it could be much easier: simply iterating the usual demuxer output backward. But this just doesn't fit into our code, so there's a cthulhu nightmare of shit. To be specific, each stream (audio, video) is reversed separately. At least this means we can do backward playback within cached content (for example, you could play backwards in a live stream; on that note, it disables prefetching, which would lead to losing new live video, but this could be avoided). The fuckmess also meant that I didn't bother trying to support subtitles. Subtitles are a problem because they're "sparse" streams. They need to be "passively" demuxed: you don't try to read a subtitle packet, you demux audio and video, and then look whether there was a subtitle packet. This means to get subtitles for a time range, you need to know that you demuxed video and audio over this range, which becomes pretty messy when you demux audio and video backwards separately. Backward display is the most weird (and potentially buggy) part. To avoid that we need to touch a LOT of timing code, we negate all timestamps. The basic idea is that due to the navigation, all comparisons and subtractions of timestamps keep working, and you don't need to touch every single of them to "reverse" them. E.g.: bool before = pts_a < pts_b; would need to be: bool before = forward ? pts_a < pts_b : pts_a > pts_b; or: bool before = pts_a * dir < pts_b * dir; or if you, as it's implemented now, just do this after decoding: pts_a *= dir; pts_b *= dir; and then in the normal timing/renderer code: bool before = pts_a < pts_b; Consequently, we don't need many changes in the latter code. But some assumptions inhererently true for forward playback may have been broken anyway. What is mainly needed is fixing places where values are passed between positive and negative "domains". For example, seeking and timestamp user display always uses positive timestamps. The main mess is that it's not obvious which domain a given variable should or does use. Well, in my tests with a single file, it suddenly started to work when I did this. I'm honestly surprised that it did, and that I didn't have to change a single line in the timing code past decoder (just something minor to make external/cached text subtitles display). I committed it immediately while avoiding thinking about it. But there really likely are subtle problems of all sorts. As far as I'm aware, gstreamer also supports backward playback. When I looked at this years ago, I couldn't find a way to actually try this, and I didn't revisit it now. Back then I also read talk slides from the person who implemented it, and I'm not sure if and which ideas I might have taken from it. It's possible that the timestamp reversal is inspired by it, but I didn't check. (I think it claimed that it could avoid large changes by changing a sign?) VapourSynth has some sort of reverse function, which provides a backward view on a video. The function itself is trivial to implement, as VapourSynth aims to provide random access to video by frame numbers (so you just request decreasing frame numbers). From what I remember, it wasn't exactly fluid, but it worked. It's implemented by creating an index, and seeking to the target on demand, and a bunch of caching. mpv could use it, but it would either require using VapourSynth as demuxer and decoder for everything, or replacing the current file every time something is supposed to be played backwards. FFmpeg's libavfilter has reversal filters for audio and video. These require buffering the entire media data of the file, and don't really fit into mpv's architecture. It could be used by playing a libavfilter graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 02:10:51 +02:00
int64_t video_reverse_size;
int64_t audio_reverse_size;
options: move some demux options to option struct Following options were moved: audiofile, audiofile-cache, subfile, demuxer, audio-demuxer, sub-demuxer, [no]extbased.
2010-11-11 15:24:17 +01:00
player: cosmetics: rename internal variable for consistency This was so annoying.
2018-01-03 21:50:04 +01:00
int cache_pause;
player: add --cache-pause-initial option to start in buffering state Reasons why you'd want this see manpage additions. Disabled by default, because it would increase latency of live streams by default. (Or well, at least it would be another problem when trying getting lower latency.)
2018-01-03 21:48:42 +01:00
int cache_pause_initial;
player: use fixed timeout for cache pausing (buffering) duration This tried to be clever by waiting for a longer time each time the buffer was underrunning, or shorter if it was getting better. I think this was pretty weird behavior and makes no sense. If the user really wants the stream to buffer longer, he/she/it can just pause the player (the network caches will continue to be filled until they're full). Every time I actually noticed this code triggering in my own use, I didn't find it helpful. Apart from that it was pretty hard to test. Some waiting is needed to avoid that the player just plays the available data as fast as possible (to compensate for late frames and underrunning audio). Just use a fixed wait time, which can now be controlled by the new --cache-pause-wait option.
2018-01-03 21:28:28 +01:00
float cache_pause_wait;
player: redo how stream caching and pausing on low cache works Add the --cache-secs option, which literally overrides the value of --demuxer-readahead-secs if the stream cache is active. The default value is very high (10 seconds), which means it can act as network cache. Remove the old behavior of trying to pause once the byte cache runs low. Instead, do something similar wit the demuxer cache. The nice thing is that we can guess how many seconds of video it has cached, and we can make better decisions. But for now, apply a relatively naive heuristic: if the cache is below 0.5 secs, pause, and wait until at least 2 secs are available. Note that due to timestamp reordering, the estimated cached duration of video might be inaccurate, depending on the file format. If the file format has DTS, it's easy, otherwise the duration will seemingly jump back and forth.
2014-08-27 01:13:20 +02:00
image_writer: add option parsing image_writer now provides its own option parsing, and screenshot.c and the mplayer frontend use it.
2012-08-06 17:48:30 +02:00
struct image_writer_opts *screenshot_image_opts;
screenshot: make screenshot filenames configurable This adds the --screenshot-template option, which specifies a template for the filename used for a screenshot. The '%' character is parsed as format specifier. These format specifiers insert metadata into the filename. For example, '%f' is replaced with the filename of the currently played file. The following format specifiers are available: %n Insert sequence number (padded with 4 zeros), e.g. "0002". %0Nn Like %n, but pad to N zeros (N = 0 to 9). %n behaves like %04n. %#n Like %n, but reset the sequence counter on every screenshot. (Useful if other parts in the template make the resulting filename already mostly unique.) %#0Nn Use %0Nn and %#n at the same time. %f Insert filename of the currently played video. %F Like %f, but with stripped file extension ("." and rest). %p Insert current playback time, in HH:MM:SS format. %P Like %p, but adds milliseconds: HH:MM:SS.mmmm %tX Insert the current local date/time, using the date format X. X is a single letter and is passed to strftime() as "%X". E.g. "%td" inserts the number of the current day. %{prop} Insert the value of the slave property 'prop'. E.g. %{filename} is the same as %f. If the property doesn't exist or is not available, nothing is inserted, unless a fallback is specified as in %{prop:fallback text}. %% Insert the character '%'. The strings inserted by format specifiers will be checked for characters not allowed in filenames (including '/' and '\'), and replaced with the placeholder '_'. (This doesn't happen for text that was passed with the --screenshot-template option, and allows specifying a screenshot target directory by prefixing the template with a relative or absolute path.)
2012-02-29 03:46:25 +01:00
char *screenshot_template;
options: fix typo in variable name
2015-05-03 14:44:42 +02:00
char *screenshot_directory;
screenshot: add jpg support The screenshot image file type can now be selected with the --screenshot-filetype option. The --screenshot-jpeg-quality option controls the compression setting of the written JPEG image file.
2011-10-06 20:46:02 +02:00
core: remove a number of global variables Move them into per-instance structs. This should get rid of all global variables in mplayer.c (not counting those referenced by cfg-mplayer.h). In core/input/ar.c, just remove checking the slave_mode variable. I'm not sure what this code was supposed to achieve, but slave mode is broken, slave mode is actually infeasible on OSX (ar.c is completely OSX specific), and the correct way of doing this would be to disable this input device per command line switch.
2013-03-08 02:08:02 +01:00
double force_fps;
options: turn --idx, --forceidx into --index Also clarify the semantics. It seems --idx didn't do anything. Possibly it used to change how the now removed legacy demuxers like demux_avi used to behave. Or maybe it was accidental. --forceidx basically becomes --index=force. It's possible that new index modes will be added in the future, so I'm keeping it extensible, instead of e.g. creating --force-index.
2014-06-13 02:05:37 +02:00
int index_mode;
core: remove a number of global variables Move them into per-instance structs. This should get rid of all global variables in mplayer.c (not counting those referenced by cfg-mplayer.h). In core/input/ar.c, just remove checking the slave_mode variable. I'm not sure what this code was supposed to achieve, but slave mode is broken, slave mode is actually infeasible on OSX (ar.c is completely OSX specific), and the correct way of doing this would be to disable this input device per command line switch.
2013-03-08 02:08:02 +01:00
audio: use --audio-channels=auto behavior, except on ALSA This commit adds an --audio-channel=auto-safe mode, and makes it the default. This mode behaves like "auto" with most AOs, except with ao_alsa. The intention is to allow multichannel output by default on sane APIs. ALSA is not sane as in it's so low level that it will e.g. configure any layout over HDMI, even if the connected A/V receiver does not support it. The HDMI fuckup is of course not ALSA's fault, but other audio APIs normally isolate applications from dealing with this and require the user to globally configure the correct output layout. This will help with other AOs too. ao_lavc (encoding) is changed to the new semantics as well, because it used to force stereo (perhaps because encoding mode is supposed to produce safe files for crap devices?). Exclusive mode output on Windows might need to be adjusted accordingly, as it grants the same kind of low level access as ALSA (requires more research). In addition to the things mentioned above, the --audio-channels option is extended to accept a set of channel layouts. This is supposed to be the correct way to configure mpv ALSA multichannel output. You need to put a list of channel layouts that your A/V receiver supports.
2016-08-04 20:49:20 +02:00
struct m_channels audio_output_channels;
options: move audio_output_channels, audio_output_format to struct
2010-10-31 06:26:40 +01:00
int audio_output_format;
core: remove a number of global variables Move them into per-instance structs. This should get rid of all global variables in mplayer.c (not counting those referenced by cfg-mplayer.h). In core/input/ar.c, just remove checking the slave_mode variable. I'm not sure what this code was supposed to achieve, but slave mode is broken, slave mode is actually infeasible on OSX (ar.c is completely OSX specific), and the correct way of doing this would be to disable this input device per command line switch.
2013-03-08 02:08:02 +01:00
int force_srate;
core: change speed option/property to double The --speed option and the speed property used float. Change them to double. Change the commands that manipulate the property (speed_mult/add) to double as well. Since the cycle command shares code with the add command, we change that as well. The reason for this change is that this allows better control over speed, such as stepping by semitones. Using floats is also just plain unnecessary.
2013-08-04 23:56:20 +02:00
double playback_speed;
audio: enable pitch correction by default when playing fast Apparently this is what users want. When playing with normal speed, nothing is done. When playing slower than normal, resampling is used instead, because scaletempo (which does the pitch correction) adds too many artifacts.
2014-10-02 02:58:52 +02:00
int pitch_correction;
options: add options that set defaults for af/vf/ao/vo There are some use cases for this. For example, you can use it to set defaults of automatically inserted filters (like af_lavrresample). It's also useful if you have a non-trivial VO configuration, and want to use --vo to quickly change between the drivers without repeating the whole configuration in the --vo argument.
2013-12-01 00:12:10 +01:00
struct m_obj_settings *vf_settings, *vf_defs;
struct m_obj_settings *af_settings, *af_defs;
video: rewrite filtering glue code Get rid of the old vf.c code. Replace it with a generic filtering framework, which can potentially handle more than just --vf. At least reimplementing --af with this code is planned. This changes some --vf semantics (including runtime behavior and the "vf" command). The most important ones are listed in interface-changes. vf_convert.c is renamed to f_swscale.c. It is now an internal filter that can not be inserted by the user manually. f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is conceptually easy, but a big mess due to the data flow changes). The existing filters are all changed heavily. The data flow of the new filter framework is different. Especially EOF handling changes - EOF is now a "frame" rather than a state, and must be passed through exactly once. Another major thing is that all filters must support dynamic format changes. The filter reconfig() function goes away. (This sounds complex, but since all filters need to handle EOF draining anyway, they can use the same code, and it removes the mess with reconfig() having to predict the output format, which completely breaks with libavfilter anyway.) In addition, there is no automatic format negotiation or conversion. libavfilter's primitive and insufficient API simply doesn't allow us to do this in a reasonable way. Instead, filters can use f_autoconvert as sub-filter, and tell it which formats they support. This filter will in turn add actual conversion filters, such as f_swscale, to perform necessary format changes. vf_vapoursynth.c uses the same basic principle of operation as before, but with worryingly different details in data flow. Still appears to work. The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are heavily changed. Fortunately, they all used refqueue.c, which is for sharing the data flow logic (especially for managing future/past surfaces and such). It turns out it can be used to factor out most of the data flow. Some of these filters accepted software input. Instead of having ad-hoc upload code in each filter, surface upload is now delegated to f_autoconvert, which can use f_hwupload to perform this. Exporting VO capabilities is still a big mess (mp_stream_info stuff). The D3D11 code drops the redundant image formats, and all code uses the hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a big mess for now. f_async_queue is unused.
2018-01-16 11:53:44 +01:00
struct filter_opts *filter_opts;
Move movie_aspect to options struct
2008-04-24 06:36:43 +02:00
float movie_aspect;
video: make container vs. bitstream aspect ratio configurable Utterly idiotic bullshit. Fixes #2259.
2015-08-30 23:01:46 +02:00
int aspect_method;
options: move sub_name, sub_auto and vobsub_name to struct
2011-02-08 00:35:51 +01:00
char **sub_name;
subs: options: add -sub-paths
2011-03-03 11:31:12 +01:00
char **sub_paths;
options: add --audio-file-paths Requested. It works like --sub-paths. This will also load audio files from a "audio" sub directory in the config file (because the same code as for subtitles is used, and it also had such a feature). Fixes #2632.
2015-12-25 13:17:11 +01:00
char **audiofile_paths;
player: add --external-file option Mostly intended for use with --lavfi-complex.
2016-02-08 21:18:35 +01:00
char **external_files;
player: add --no-autoload-files option Allt his auto-loading is getting annoying especially for testing.
2016-08-10 22:22:50 +02:00
int autoload_files;
options: move sub_name, sub_auto and vobsub_name to struct
2011-02-08 00:35:51 +01:00
int sub_auto;
player: add external audio file auto-loading Apparently some people want this. Not enabled by default. Fixes #967.
2015-02-02 21:23:12 +01:00
int audiofile_auto;
osd: add --no-osd-bar option to disable the OSD bar In addition to disabling the OSD bar physically, also add some fallbacks to OSD text in places the OSD bar would have been used.
2013-02-16 21:17:59 +01:00
int osd_bar_visible;
video: different way to enable hardware decoding, add software fallback Deprecate the hardware specific video codec entries (like ffh264vdpau). Replace them with the --hwdec switch, which requests that a specific hardware decoding API should be used. The codecs.conf entries will be removed at a later time, but for now they are useful for testing and compatibility. Instead of --vc=ffh264vdpau, --hwdec=vdpau should be used. Add a fallback if hardware decoding fails. Most hardware decoders (including vdpau) support only a subset of h264, and having such a fallback is supposed to enable a better user experience.
2012-12-11 18:16:42 +01:00
win32: implement --priority differently Does anyone actually use this? For now, update it, because it's the only case left where an option points to a global variable (and not a struct offset).
2014-06-12 00:34:20 +02:00
int w32_priority;
stream_cdda: remove global option variables
2014-06-10 20:46:15 +02:00
struct cdda_params *stream_cdda_opts;
stream_dvb: remove global option variables
2014-06-10 21:44:50 +02:00
struct dvb_params *stream_dvb_opts;
stream_lavf: allow setting AVOptions with --stream-lavf-o This commit also creates a private option struct for stream_lavf.c, but since I'm lazy, I'm not moving any existing options to it.
2014-07-30 01:15:42 +02:00
struct stream_lavf_params *stream_lavf_opts;
stream_cdda: remove global option variables
2014-06-10 20:46:15 +02:00
char *cdrom_device;
Revert "Remove DVD and Bluray support" This reverts commit 4b93210e0c244a65ef10a566abed2ad25ecaf9a1. *shrug*
2014-07-15 01:49:02 +02:00
char *bluray_device;
tv: remove global option variables Pretty much nothing changes, but using -tv-scan with suboptions doesn't work anymore (instead of "-tv-scan x" it's "-tv scan-x" now). Flat options ("-tv-scan-x") stay compatible.
2014-06-09 23:54:45 +02:00
demux_mf: remove global option variables
2014-06-10 22:48:11 +02:00
double mf_fps;
char *mf_type;
demux_raw: remove global option variables
2014-06-10 23:06:42 +02:00
struct demux_rawaudio_opts *demux_rawaudio;
struct demux_rawvideo_opts *demux_rawvideo;
demux_lavf: make option struct local Similar to previous commits.
2014-06-11 01:46:20 +02:00
struct demux_lavf_opts *demux_lavf;
demux_mkv: move global options to the demuxer The options don't change, but they're now declared and used privately by demux_mkv.c. This also brings with it a minor refactor of the subpreroll seek handling - merge the code from playloop.c into demux_mkv.c. The change in demux.c is pretty much equivalent as well.
2015-04-23 19:21:17 +02:00
struct demux_mkv_opts *demux_mkv;
demux_raw: remove global option variables
2014-06-10 23:06:42 +02:00
demux: do not access global options Don't access MPOpts directly, and always use the new m_config.h functions for accessing them in a thread-safe way. The goal is eventually removing the mpv_global.opts field, and the demuxer/stream-layer specific hack that copies MPOpts to deal with thread-safety issues. This moves around a lot of options. For one, we often change the physical storage location of options to make them more localized, but these changes are not user-visible (or should not be). For shared options on the other hand it's better to do messy direct access, which is worrying as in that somehow renaming an option or changing its type would break code reading them manually, without causing a compilation error.
2016-09-06 20:09:56 +02:00
struct demux_opts *demux_opts;
demux: add a on-disk cache Somewhat similar to the old --cache-file, except for the demuxer cache. Instead of keeping packet data in memory, it's written to disk and read back when needed. The idea is to reduce main memory usage, while allowing fast seeking in large cached network streams (especially live streams). Keeping the packet metadata on disk would be rather hard (would use mmap or so, or rewrite the entire demux.c packet queue handling), and since it's relatively small, just keep it in memory. Also for simplicity, the disk cache is append-only. If you're watching really long livestreams, and need pruning, you're probably out of luck. This still could be improved by trying to free unused blocks with fallocate(), but since we're writing multiple streams in an interleaved manner, this is slightly hard. Some rather gross ugliness in packet.h: we want to store the file position of the cached data somewhere, but on 32 bit architectures, we don't have any usable 64 bit members for this, just the buf/len fields, which add up to 64 bit - so the shitty union aliases this memory. Error paths untested. Side data (the complicated part of trying to serialize ffmpeg packets) untested. Stream recording had to be adjusted. Some minor details change due to this, but probably nothing important. The change in attempt_range_joining() is because packets in cache have no valid len field. It was a useful check (heuristically finding broken cases), but not a necessary one. Various other approaches were tried. It would be interesting to list them and to mention the pros and cons, but I don't feel like it.
2019-06-13 19:10:32 +02:00
struct demux_cache_opts *demux_cache_opts;
demux: do not access global options Don't access MPOpts directly, and always use the new m_config.h functions for accessing them in a thread-safe way. The goal is eventually removing the mpv_global.opts field, and the demuxer/stream-layer specific hack that copies MPOpts to deal with thread-safety issues. This moves around a lot of options. For one, we often change the physical storage location of options to make them more localized, but these changes are not user-visible (or should not be). For shared options on the other hand it's better to do messy direct access, which is worrying as in that somehow renaming an option or changing its type would break code reading them manually, without causing a compilation error.
2016-09-06 20:09:56 +02:00
vd_lavc: make option struct local Removes specifics from options.h and options.c, and puts everything into vd_lavc.c.
2014-06-11 01:35:39 +02:00
struct vd_lavc_params *vd_lavc_params;
ad_lavc: make option struct local Similar to previous commit.
2014-06-11 01:39:51 +02:00
struct ad_lavc_params *ad_lavc_params;
options: add option to prevent decoder audio downmixing Also rename --a52drc to --ad-lavc-ac3drc, and add --ad-lavc-o.
2013-03-31 04:24:53 +02:00
input: make option struct local Similar to previous commits. This also renames --doubleclick-time to --input-doubleclick-time, and --key-fifo-size to --input-key-fifo-size. We could keep the old names, but these options are very obscure, and renaming them seems better for consistency.
2014-06-11 01:54:03 +02:00
struct input_opts *input_opts;
encode: video encoding now supported using mencoder-like options
2012-09-14 17:51:26 +02:00
encode: make option struct local Similar to previous commits.
2014-06-11 02:04:02 +02:00
// may be NULL if encoding is not compiled-in
struct encode_opts *encode_opts;
input: implement JSON-based IPC protocol
2014-10-16 11:48:18 +02:00
char *ipc_path;
input: implement --input-file on unix using the IPC support
2014-10-15 17:48:47 +02:00
char *input_file;
vo_opengl: deprecate sub-options, add them as global options vo_opengl sub-option were always rather annoying to handle. It seems better to make them global options instead. This is simpler and easier to use. The only disadvantage we are aware of is that it's not clear that many/all of these new global options work with vo_opengl only. --vo=opengl-hq is also deprecated. There is extensive compatibility with the old behavior. One exception is that --vo-defaults will not apply to opengl-hq (though with opengl it still works). vo-cmdline is also dysfunctional and will be removed in a following commit. These changes also affect opengl-cb. The update mechanism is still rather inefficient: it requires syncing with the VO after each option change, rather than batching updates. There's also no granularity (video.c just updates "everything", and if auto-ICC profiles are enabled, vo_opengl.c will fetch them on each update). Most of the manpage changes were done by Niklas Haas <git@haasn.xyz>.
2016-09-02 15:59:40 +02:00
options: refacactor how --opengl-dwmflush is declared Same deal as previous commit, except this time we just readd it as lone global option, and read it directly.
2017-01-20 14:02:17 +01:00
int wingl_dwm_flush;
audio: add global options for resampler defaults This is part of trying to get rid of --af-defaults, and the af resample filter. It requires a complicated mechanism to set the defaults on the resample filter for backwards compatibility.
2018-01-12 04:02:55 +01:00
struct mp_resample_opts *resample_opts;
vo_opengl: deprecate sub-options, add them as global options vo_opengl sub-option were always rather annoying to handle. It seems better to make them global options instead. This is simpler and easier to use. The only disadvantage we are aware of is that it's not clear that many/all of these new global options work with vo_opengl only. --vo=opengl-hq is also deprecated. There is extensive compatibility with the old behavior. One exception is that --vo-defaults will not apply to opengl-hq (though with opengl it still works). vo-cmdline is also dysfunctional and will be removed in a following commit. These changes also affect opengl-cb. The update mechanism is still rather inefficient: it requires syncing with the VO after each option change, rather than batching updates. There's also no granularity (video.c just updates "everything", and if auto-ICC profiles are enabled, vo_opengl.c will fetch them on each update). Most of the manpage changes were done by Niklas Haas <git@haasn.xyz>.
2016-09-02 15:59:40 +02:00
struct gl_video_opts *gl_video_opts;
options: refactor how --opengl-dcomposition is declared vo_opengl used to have it as sub-option, which made it very hard to pass down option values to backends in a generic way (even if these options were completely backend-specific). For --opengl-dcomposition we used a VOFLAG to deal with this. Fortunately, sub-options are gone, and we can just add it as global option. Move the option to context_angle.c and add it as global option. I thought about adding a mechanism to let backends declare options, which would get magically picked up my m_config instead of having to add them to the global option list manually (similar to VO vo_driver.options), but decided against this complexity just for 1 or 2 backends. Likewise, it could have been added as a single option to avoid the boilerplate of an option struct, but then again there are probably going to be more angle suboptions, and it's cleaner.
2017-01-20 13:38:28 +01:00
struct angle_opts *angle_opts;
vo_opengl: refactor into vo_gpu This is done in several steps: 1. refactor MPGLContext -> struct ra_ctx 2. move GL-specific stuff in vo_opengl into opengl/context.c 3. generalize context creation to support other APIs, and add --gpu-api 4. rename all of the --opengl- options that are no longer opengl-specific 5. move all of the stuff from opengl/* that isn't GL-specific into gpu/ (note: opengl/gl_utils.h became opengl/utils.h) 6. rename vo_opengl to vo_gpu 7. to handle window screenshots, the short-term approach was to just add it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to ra itself (and vo_gpu altered to compensate), but this was a stop-gap measure to prevent this commit from getting too big 8. move ra->fns->flush to ra_gl_ctx instead 9. some other minor changes that I've probably already forgotten Note: This is one half of a major refactor, the other half of which is provided by rossy's following commit. This commit enables support for all linux platforms, while his version enables support for all non-linux platforms. Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the --opengl- options like --opengl-early-flush, --opengl-finish etc. Should be a strict superset of the old functionality. Disclaimer: Since I have no way of compiling mpv on all platforms, some of these ports were done blindly. Specifically, the blind ports included context_mali_fbdev.c and context_rpi.c. Since they're both based on egl_helpers, the port should have gone smoothly without any major changes required. But if somebody complains about a compile error on those platforms (assuming anybody actually uses them), you know where to complain.
2017-09-14 08:04:55 +02:00
struct opengl_opts *opengl_opts;
vo_gpu: vulkan: initial implementation This time based on ra/vo_gpu. 2017 is the year of the vulkan desktop! Current problems / limitations / improvement opportunities: 1. The swapchain/flipping code violates the vulkan spec, by assuming that the presentation queue will be bounded (in cases where rendering is significantly faster than vsync). But apparently, there's simply no better way to do this right now, to the point where even the stupid cube.c examples from LunarG etc. do it wrong. (cf. https://github.com/KhronosGroup/Vulkan-Docs/issues/370) 2. The memory allocator could be improved. (This is a universal constant) 3. Could explore using push descriptors instead of descriptor sets, especially since we expect to switch descriptors semi-often for some passes (like interpolation). Probably won't make a difference, but the synchronization overhead might be a factor. Who knows. 4. Parallelism across frames / async transfer is not well-defined, we either need to use a better semaphore / command buffer strategy or a resource pooling layer to safely handle cross-frame parallelism. (That said, I gave resource pooling a try and was not happy with the result at all - so I'm still exploring the semaphore strategy) 5. We aggressively use pipeline barriers where events would offer a much more fine-grained synchronization mechanism. As a result of this, we might be suffering from GPU bubbles due to too-short dependencies on objects. (That said, I'm also exploring the use of semaphores as a an ordering tactic which would allow cross-frame time slicing in theory) Some minor changes to the vo_gpu and infrastructure, but nothing consequential. NOTE: For safety, all use of asynchronous commands / multiple command pools is currently disabled completely. There are some left-over relics of this in the code (e.g. the distinction between dev_poll and pool_poll), but that is kept in place mostly because this will be re-extended in the future (vulkan rev 2). The queue count is also currently capped to 1, because of the lack of cross-frame semaphores means we need the implicit synchronization from the same-queue semantics to guarantee a correct result.
2016-09-14 20:54:18 +02:00
struct vulkan_opts *vulkan_opts;
vo_gpu: vulkan: generalize SPIR-V compiler In addition to the built-in nvidia compiler, we now also support a backend based on libshaderc. shaderc is sort of like glslang except it has a C API and is available as a dynamic library. The generated SPIR-V is now cached alongside the VkPipeline in the cached_program. We use a special cache header to ensure validity of this cache before passing it blindly to the vulkan implementation, since passing invalid SPIR-V can cause all sorts of nasty things. It's also designed to self-invalidate if the compiler gets better, by offering a catch-all `int compiler_version` that implementations can use as a cache invalidation marker.
2017-09-13 03:09:48 +02:00
struct spirv_opts *spirv_opts;
vo_gpu: d3d11: initial implementation This is a new RA/vo_gpu backend that uses Direct3D 11. The GLSL generated by vo_gpu is cross-compiled to HLSL with SPIRV-Cross. What works: - All of mpv's internal shaders should work, including compute shaders. - Some external shaders have been tested and work, including RAVU and adaptive-sharpen. - Non-dumb mode works, even on very old hardware. Most features work at feature level 9_3 and all features work at feature level 10_0. Some features also work at feature level 9_1 and 9_2, but without high-bit- depth FBOs, it's not very useful. (Hardware this old is probably not fast enough for advanced features anyway.) Note: This is more compatible than ANGLE, which requires 9_3 to work at all (GLES 2.0,) and 10_1 for non-dumb-mode (GLES 3.0.) - Hardware decoding with D3D11VA, including decoding of 10-bit formats without truncation to 8-bit. What doesn't work / can be improved: - PBO upload and direct rendering does not work yet. Direct rendering requires persistent-mapped PBOs because the decoder needs to be able to read data from images that have already been decoded and uploaded. Unfortunately, it seems like persistent-mapped PBOs are fundamentally incompatible with D3D11, which requires all resources to use driver- managed memory and requires memory to be unmapped (and hence pointers to be invalidated) when a resource is used in a draw or copy operation. However it might be possible to use D3D11's limited multithreading capabilities to emulate some features of PBOs, like asynchronous texture uploading. - The blit() and clear() operations don't have equivalents in the D3D11 API that handle all cases, so in most cases, they have to be emulated with a shader. This is currently done inside ra_d3d11, but ideally it would be done in generic code, so it can take advantage of mpv's shader generation utilities. - SPIRV-Cross is used through a NIH C-compatible wrapper library, since it does not expose a C interface itself. The library is available here: https://github.com/rossy/crossc - The D3D11 context could be made to support more modern DXGI features in future. For example, it should be possible to add support for high-bit-depth and HDR output with DXGI 1.5/1.6.
2017-09-07 12:18:06 +02:00
struct d3d11_opts *d3d11_opts;
vo_gpu: hwdec_d3d11va: allow zero-copy video decoding Like the manual says, this is technically undefined behaviour. See: https://msdn.microsoft.com/en-us/library/windows/desktop/ff476085.aspx In particular, MSDN says texture arrays created with the BIND_DECODER flag cannot be used with CreateShaderResourceView, which means they can't be sampled through SRVs like normal Direct3D textures. However, some programs (Google Chrome included) do this anyway for performance and power-usage reasons, and it appears to work with most drivers. Older AMD drivers had a "bug" with zero-copy decoding, but this appears to have been fixed. See #3255, #3464 and http://crbug.com/623029.
2017-11-01 12:38:41 +01:00
struct d3d11va_opts *d3d11va_opts;
cocoa: add option to force dedicated GPU Fixes #3242
2017-02-20 20:34:57 +01:00
struct cocoa_opts *cocoa_opts;
cocoa-cb: change border and borderless window styling the title bar is now within the window bounds instead of outside. same as QuickTime Player. it supports several standard styles, two dark and two light ones. additionally we have properly rounded corners now and the borderless window also has the proper window shadow. Also make the earliest supported macOS version 10.10. Fixes #4789, #3944
2018-02-16 13:07:15 +01:00
struct macos_opts *macos_opts;
vo_gpu/context: Let embedding application handle surface resizes The callbacks for this are Java-only and EGL does not reliably return the correct values.
2017-12-25 16:04:09 +01:00
struct android_opts *android_opts;
stream_dvd, stream_dvdnav: remove weird option parsing stuff Same deal as with stream_bluray. Untested because I don't give a fuck about your shitty DVDs.
2016-09-08 21:46:48 +02:00
struct dvd_opts *dvd_opts;
vaapi: add option to select a non-default device path On machines with multiple GPUs, /dev/dri/renderD128 isn't guaranteed to point to a valid vaapi device. This just adds the option to specify what path to use. The old fallback /dev/dri/card0 is gone but that's not a loss as its a legacy interface no longer accepted as valid by libva. Fixes #4320
2018-03-29 23:23:27 +02:00
struct vaapi_opts *vaapi_opts;
vo_opengl: hwdec_cuda: Support separate decode and display devices In a multi GPU scenario, it may be desirable to use different GPUs for decode and display responsibilities. For example, if a secondary GPU has better video decoding capabilities. In such a scenario, we need to initialise a separate context for each GPU, and use the display context in hwdec_cuda, while passing the decode context to avcodec. Once that's done, the actually hand-off between the two GPUs is transparent to us (It happens during the cuMemcpy2D operation which copies the decoded frame from a cuda buffer to the OpenGL texture). In the end, the bulk of the work is around introducing a new configuration option to specify the decode device.
2017-05-29 18:48:10 +02:00
int cuda_device;
Start of new option system First part of option restructuring. The aim is to move option values from a huge number of separate globals to a single non-global struct. This part adds some support for parsing option values into such struct instances, and moves one example option (fixed-vo) to the struct.
2008-03-31 05:19:29 +02:00
} MPOpts;
stream_dvd, stream_dvdnav: remove weird option parsing stuff Same deal as with stream_bluray. Untested because I don't give a fuck about your shitty DVDs.
2016-09-08 21:46:48 +02:00
struct dvd_opts {
int angle;
int speed;
char *device;
};
video: rewrite filtering glue code Get rid of the old vf.c code. Replace it with a generic filtering framework, which can potentially handle more than just --vf. At least reimplementing --af with this code is planned. This changes some --vf semantics (including runtime behavior and the "vf" command). The most important ones are listed in interface-changes. vf_convert.c is renamed to f_swscale.c. It is now an internal filter that can not be inserted by the user manually. f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is conceptually easy, but a big mess due to the data flow changes). The existing filters are all changed heavily. The data flow of the new filter framework is different. Especially EOF handling changes - EOF is now a "frame" rather than a state, and must be passed through exactly once. Another major thing is that all filters must support dynamic format changes. The filter reconfig() function goes away. (This sounds complex, but since all filters need to handle EOF draining anyway, they can use the same code, and it removes the mess with reconfig() having to predict the output format, which completely breaks with libavfilter anyway.) In addition, there is no automatic format negotiation or conversion. libavfilter's primitive and insufficient API simply doesn't allow us to do this in a reasonable way. Instead, filters can use f_autoconvert as sub-filter, and tell it which formats they support. This filter will in turn add actual conversion filters, such as f_swscale, to perform necessary format changes. vf_vapoursynth.c uses the same basic principle of operation as before, but with worryingly different details in data flow. Still appears to work. The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are heavily changed. Fortunately, they all used refqueue.c, which is for sharing the data flow logic (especially for managing future/past surfaces and such). It turns out it can be used to factor out most of the data flow. Some of these filters accepted software input. Instead of having ad-hoc upload code in each filter, surface upload is now delegated to f_autoconvert, which can use f_hwupload to perform this. Exporting VO capabilities is still a big mess (mp_stream_info stuff). The D3D11 code drops the redundant image formats, and all code uses the hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a big mess for now. f_async_queue is unused.
2018-01-16 11:53:44 +01:00
struct filter_opts {
int deinterlace;
};
core: make options.c compile standalone This also removes the split between "mplayer" and "common" opts (common opts used to be shared between mencoder and mplayer).
2013-06-07 22:57:00 +02:00
extern const m_option_t mp_opts[];
extern const struct MPOpts mp_default_opts;
vo: use new option update mechanism This is still rather basic. run_reconfig() and run_control() update the options because it's needed for panscan (and other video scaling options), and fullscreen, border, ontop updates. In the old model, these options could be accessed only while both playback thread and VO threads were locked (i.e. during synchronous calls like vo_control()), so this should be sufficient in order not to miss any updates. In the future, a more fine-grained update mechanism could be added to handle these updates "exactly". x11_common.c contains an evil hack, as I see no reasonable way to handle this properly. The VO thread can't "lock" the main thread, so this is not simple.
2016-09-02 15:50:54 +02:00
extern const struct m_sub_options vo_sub_opts;
stream_dvd, stream_dvdnav: remove weird option parsing stuff Same deal as with stream_bluray. Untested because I don't give a fuck about your shitty DVDs.
2016-09-08 21:46:48 +02:00
extern const struct m_sub_options dvd_conf;
options: move most subtitle and OSD rendering options to sub structs Remove them from the big MPOpts struct and move them to their sub structs. In the places where their fields are used, create a private copy of the structs, instead of accessing the semi-deprecated global option struct instance (mpv_global.opts) directly. This actually makes accessing these options finally thread-safe. They weren't even if they should have for years. (Including some potential for undefined behavior when e.g. the OSD font was changed at runtime.) This is mostly transparent. All options get moved around, but most users of the options just need to access a different struct (changing sd.opts to a different type changes a lot of uses, for example). One thing which has to be considered and could cause potential regressions is that the new option copies must be explicitly updated. sub_update_opts() takes care of this for example. Another thing is that writing to the option structs manually won't work, because the changes won't be propagated to other copies. Apparently the only affected case is the implementation of the sub-step command, which tries to change sub_delay. Handle this one explicitly (osd_changed() doesn't need to be called anymore, because changing the option triggers UPDATE_OSD, and updates the OSD as a consequence). The way the option value is propagated is rather hacky, but for now this will do.
2017-12-29 17:19:25 +01:00
extern const struct m_sub_options mp_subtitle_sub_opts;
extern const struct m_sub_options mp_osd_render_sub_opts;
video: rewrite filtering glue code Get rid of the old vf.c code. Replace it with a generic filtering framework, which can potentially handle more than just --vf. At least reimplementing --af with this code is planned. This changes some --vf semantics (including runtime behavior and the "vf" command). The most important ones are listed in interface-changes. vf_convert.c is renamed to f_swscale.c. It is now an internal filter that can not be inserted by the user manually. f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is conceptually easy, but a big mess due to the data flow changes). The existing filters are all changed heavily. The data flow of the new filter framework is different. Especially EOF handling changes - EOF is now a "frame" rather than a state, and must be passed through exactly once. Another major thing is that all filters must support dynamic format changes. The filter reconfig() function goes away. (This sounds complex, but since all filters need to handle EOF draining anyway, they can use the same code, and it removes the mess with reconfig() having to predict the output format, which completely breaks with libavfilter anyway.) In addition, there is no automatic format negotiation or conversion. libavfilter's primitive and insufficient API simply doesn't allow us to do this in a reasonable way. Instead, filters can use f_autoconvert as sub-filter, and tell it which formats they support. This filter will in turn add actual conversion filters, such as f_swscale, to perform necessary format changes. vf_vapoursynth.c uses the same basic principle of operation as before, but with worryingly different details in data flow. Still appears to work. The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are heavily changed. Fortunately, they all used refqueue.c, which is for sharing the data flow logic (especially for managing future/past surfaces and such). It turns out it can be used to factor out most of the data flow. Some of these filters accepted software input. Instead of having ad-hoc upload code in each filter, surface upload is now delegated to f_autoconvert, which can use f_hwupload to perform this. Exporting VO capabilities is still a big mess (mp_stream_info stuff). The D3D11 code drops the redundant image formats, and all code uses the hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a big mess for now. f_async_queue is unused.
2018-01-16 11:53:44 +01:00
extern const struct m_sub_options filter_conf;
audio: rewrite filtering glue code Use the new filtering code for audio too.
2018-01-18 14:44:20 +01:00
extern const struct m_sub_options resample_conf;
core: make options.c compile standalone This also removes the split between "mplayer" and "common" opts (common opts used to be shared between mencoder and mplayer).
2013-06-07 22:57:00 +02:00
Start of new option system First part of option restructuring. The aim is to move option values from a huge number of separate globals to a single non-global struct. This part adds some support for parsing option values into such struct instances, and moves one example option (fixed-vo) to the struct.
2008-03-31 05:19:29 +02:00
#endif