RepoMirrors
/
mpv
mirror of https://github.com/mpv-player/mpv
1
0
Fork 0
Code Issues Releases Wiki Activity
mpv/etc/builtin.conf

81 lines
2.0 KiB
Plaintext
Raw Normal View History

etc/builtin.conf: minor edits The previous commit merely copied the profile string to a file (plus changing how RPI-specific defaults are initialized), now make some changes on top of it. In particular, remove the --input-lirc option, which was removed a long time ago, but forgotten from the libmpv profile.
2016-09-15 11:47:50 +00:00
# This file is baked into the mpv binary at compile time, and automatically
# loaded at early initialization time. Some of the profiles are automatically
# applied at later stages during loading.
builtin.conf: add clarifications Just in case a confused user or developer finds this file and wonders why it's "incomplete".
2019-07-12 23:23:46 +00:00
# Note: this contains profiles only. The option defaults for normal options
# (i.e. the default profile) are defined in C code. Do NOT set any
# options in the default profile here. It won't work correctly in subtle
# ways.
#
# To see the normal option defaults, run: mpv --list-options
player: move builtin profiles to a separate file Move the embedded string with the builtin profiles to a separate builtin.conf file. This makes it easier to read and edit, and you can also check it for errors with --include=etc/builtin.conf. (Normally errors are hidden intentionally, because there's no way to output error messages this early, and because some options might not be present on all platforms or with all configurations.)
2016-09-15 11:45:23 +00:00
[pseudo-gui]
player: allow opts in pseudo-gui set by the user to override user's default This should still allow user-set default options to override built-in pseudo-gui while respecting user-set pseudo-gui options. Pros: - user option in default profile overrides built-in pseudo-gui's options Ex: screenshot-directory overrides built-in pseudo-gui's - user can "fix" pseudo-gui if some option like "force-window=no" is set in default by setting "force-window=yes" in [pseudo-gui] - `mpv --profile=pseudo-gui` will work as before Cons: - --show-profile=pseudo-gui won't display the built-in's options Original idea from wm4. Documentation edits mostly by wm4. Signed-off-by: wm4 <wm4@nowhere>
2016-09-23 22:36:17 +00:00
player-operation-mode=pseudo-gui
[builtin-pseudo-gui]
player: move builtin profiles to a separate file Move the embedded string with the builtin profiles to a separate builtin.conf file. This makes it easier to read and edit, and you can also check it for errors with --include=etc/builtin.conf. (Normally errors are hidden intentionally, because there's no way to output error messages this early, and because some options might not be present on all platforms or with all configurations.)
2016-09-15 11:45:23 +00:00
terminal=no
force-window=yes
idle=once
options: rename --screenshot-directory to --screenshot-dir Less characters is better? Other options use -dir for directory so consistency I guess.
2023-10-15 15:56:12 +00:00
screenshot-dir=~~desktop/
player: move builtin profiles to a separate file Move the embedded string with the builtin profiles to a separate builtin.conf file. This makes it easier to read and edit, and you can also check it for errors with --include=etc/builtin.conf. (Normally errors are hidden intentionally, because there's no way to output error messages this early, and because some options might not be present on all platforms or with all configurations.)
2016-09-15 11:45:23 +00:00
[libmpv]
config=no
idle=yes
terminal=no
input-terminal=no
osc=no
input-default-bindings=no
input-vo-keyboard=no
etc/builtin.conf: minor edits The previous commit merely copied the profile string to a file (plus changing how RPI-specific defaults are initialized), now make some changes on top of it. In particular, remove the --input-lirc option, which was removed a long time ago, but forgotten from the libmpv profile.
2016-09-15 11:47:50 +00:00
# OSX/Cocoa global input hooks
player: move builtin profiles to a separate file Move the embedded string with the builtin profiles to a separate builtin.conf file. This makes it easier to read and edit, and you can also check it for errors with --include=etc/builtin.conf. (Normally errors are hidden intentionally, because there's no way to output error messages this early, and because some options might not be present on all platforms or with all configurations.)
2016-09-15 11:45:23 +00:00
input-media-keys=no
[encoding]
vo=lavc
ao=lavc
keep-open=no
force-window=no
gapless-audio=yes
resume-playback=no
load-scripts=no
osc=no
framedrop=no
builtin.conf: modernize internal profiles The goal is to provide simple to understand quality/performance level profiles for the users. Instead of default and gpu-hq profile. There main profiles were added: - fast: can run on any hardware - default: balanced profile between quality and performance - high-quality: out of the box high quality experience. Intended mostly for dGPU. Summary of three profiles, including default one: [fast] scale=bilinear cscale=bilinear (implicit) dscale=bilinear dither=no correct-downscaling=no linear-downscaling=no sigmoid-upscaling=no hdr-compute-peak=no [default] (implicit mpv defaults) scale=lanczos cscale=lanczos dscale=mitchell dither-depth=auto correct-downscaling=yes linear-downscaling=yes sigmoid-upscaling=yes hdr-compute-peak=yes [high-quality] (inherits default options) scale=ewa_lanczossharp cscale=ewa_lanczossharp (implicit) hdr-peak-percentile=99.995 hdr-contrast-recovery=0.30 allow-delayed-peak-detect=no deband=yes scaler-lut-size=8
2023-09-12 21:25:20 +00:00
[fast]
scale=bilinear
dscale=bilinear
dither=no
correct-downscaling=no
linear-downscaling=no
sigmoid-upscaling=no
hdr-compute-peak=no
options: disable --allow-delayed-peak-detect by default Peak detection greatly increases HDR experience. Performance hit of non-delayed detection is not that significant and is in line with current default settings.
2023-10-06 21:54:37 +00:00
allow-delayed-peak-detect=yes
builtin.conf: modernize internal profiles The goal is to provide simple to understand quality/performance level profiles for the users. Instead of default and gpu-hq profile. There main profiles were added: - fast: can run on any hardware - default: balanced profile between quality and performance - high-quality: out of the box high quality experience. Intended mostly for dGPU. Summary of three profiles, including default one: [fast] scale=bilinear cscale=bilinear (implicit) dscale=bilinear dither=no correct-downscaling=no linear-downscaling=no sigmoid-upscaling=no hdr-compute-peak=no [default] (implicit mpv defaults) scale=lanczos cscale=lanczos dscale=mitchell dither-depth=auto correct-downscaling=yes linear-downscaling=yes sigmoid-upscaling=yes hdr-compute-peak=yes [high-quality] (inherits default options) scale=ewa_lanczossharp cscale=ewa_lanczossharp (implicit) hdr-peak-percentile=99.995 hdr-contrast-recovery=0.30 allow-delayed-peak-detect=no deband=yes scaler-lut-size=8
2023-09-12 21:25:20 +00:00
[high-quality]
scale=ewa_lanczossharp
builtin.conf: add --hdr-peak-percentile=99.995 to gpu-hq This is higher quality but comes with a slight performance hit, especially for weaker iGPUs, so I don't want to enable it out of the box even when --hdr-compute-peak=auto.
2023-08-04 14:24:57 +00:00
hdr-peak-percentile=99.995
builtin.conf: add --hdr-contrast-recovery to gpu-hq The first change to the gpu-hq profile in aeons.
2023-07-17 14:48:06 +00:00
hdr-contrast-recovery=0.30
player: move builtin profiles to a separate file Move the embedded string with the builtin profiles to a separate builtin.conf file. This makes it easier to read and edit, and you can also check it for errors with --include=etc/builtin.conf. (Normally errors are hidden intentionally, because there's no way to output error messages this early, and because some options might not be present on all platforms or with all configurations.)
2016-09-15 11:45:23 +00:00
deband=yes
builtin.conf: modernize internal profiles The goal is to provide simple to understand quality/performance level profiles for the users. Instead of default and gpu-hq profile. There main profiles were added: - fast: can run on any hardware - default: balanced profile between quality and performance - high-quality: out of the box high quality experience. Intended mostly for dGPU. Summary of three profiles, including default one: [fast] scale=bilinear cscale=bilinear (implicit) dscale=bilinear dither=no correct-downscaling=no linear-downscaling=no sigmoid-upscaling=no hdr-compute-peak=no [default] (implicit mpv defaults) scale=lanczos cscale=lanczos dscale=mitchell dither-depth=auto correct-downscaling=yes linear-downscaling=yes sigmoid-upscaling=yes hdr-compute-peak=yes [high-quality] (inherits default options) scale=ewa_lanczossharp cscale=ewa_lanczossharp (implicit) hdr-peak-percentile=99.995 hdr-contrast-recovery=0.30 allow-delayed-peak-detect=no deband=yes scaler-lut-size=8
2023-09-12 21:25:20 +00:00
# Deprecated alias
[gpu-hq]
profile=high-quality
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 06:04:55 +00:00
options: add a builtin low-latency profile Well I guess it doesn't help that much. Also add some stuff that might help to the manpage. The fundamental problem with some "live" sources (e.g. x11grab) is actually that the player gets behind initially, and never thinks it has to catch up. This is also why --untimed can help.
2018-03-02 13:21:35 +00:00
[low-latency]
audio-buffer=0 # minimize extra audio buffer (can lead to dropouts)
vd-lavc-threads=1 # multithreaded decoding buffers extra frames
cache-pause=no # do not pause on underruns
demuxer-lavf-o-add=fflags=+nobuffer # can help for weird reasons
demuxer-lavf-probe-info=nostreams # avoid probing unless absolutely needed
demuxer-lavf-analyzeduration=0.1 # if it probes, reduce it
video-sync=audio # DS currently requires reading ahead a frame
interpolation=no # requires reference frames (more buffering)
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 14:37:34 +00:00
video-latency-hacks=yes # typically 1 or 2 video frame less latency
builtin.conf: set minimal --stream-buffer-size Some stream inputs may have higher latency with higher buffer sizes, for example network filesystems via normal OS filesystem interface (these have to wait until the full buffer is read, which means higher latency). Probably doesn't matter in practice, but why take chances.
2019-11-07 20:05:15 +00:00
stream-buffer-size=4k # minimal buffer size; normally not needed
options: add a builtin low-latency profile Well I guess it doesn't help that much. Also add some stuff that might help to the manpage. The fundamental problem with some "live" sources (e.g. x11grab) is actually that the player gets behind initially, and never thinks it has to catch up. This is also why --untimed can help.
2018-03-02 13:21:35 +00:00
sws_utils, zimg: destroy vo_x11 and vo_drm performance Raise swscale and zimg default parameters. This restores screenshot quality settings (maybe) unset in the commit before. Also expose some more libswscale and zimg options. Since these options are also used for VOs like x11 and drm, this will make x11/drm/etc. much slower. For compensation, provide a profile that sets the old option values: sw-fast. I'm also enabling zimg here, just as an experiment. The core problem is that we have a single set of command line options which control the settings used for most swscale/zimg uses. This was done in the previous commit. It cannot differentiate between the VOs, which need to be realtime and may accept/require lower quality options, and things like screenshots or vo_image, which can be slower, but should not sacrifice quality by default. Should this have two sets of options or something similar to do the right thing depending on the code which calls libswscale? Maybe. Or should I just ignore the problem, make it someone else's problem (users who want to use software conversion VOs), provide a sub-optimal solution, and call it a day? Definitely, sounds good, pushing to master, goodbye.
2019-10-31 15:45:28 +00:00
[sw-fast]
# For VOs which use software scalers, also affects screenshots and others.
sws-scaler=bilinear
sws-fast=yes
zimg-scaler=bilinear
zimg-dither=no