碍于篇幅，怕大家看不过来之后直接选择从入门到放弃，所以先把两个中长篇幅的“段落”发出来，本来视频、音频、字幕这几个章节应该放在同一篇当中的，但是看了一下字数，嗯，估摸着7W+字，两眼一黑，稳定发挥。。。本篇主讲第13.3章节（程序行为）至第13.4章节（视频）的文档说明。
这部分文档中的有些配置项还是值得去研究和尝试的，不过大多数还是保持默认就好。还有就是我很想吐槽几句原文的部分表述，我个人非常讨厌在使用手册中时不时地会来几句绕弯子的描述说明，本末倒置。所以偶尔遇到我在注释中吐槽的话还请大家见谅。
以下摘取自 mpv player 官方使用手册中的OPTION章节，版本 v0.34.0，不保证内容的时效性，仅供参考，实际还是以官方发布的最新文档为准，善用 Ctrl + F 快速定位你想要的内容：
Ch.13.3 程序行为
–help, –h
显示简短的选项概括说明。
你还可以项该选项中传入一个字符串，将会列举出所有名称中包含该字符串的顶级选项帮助说明，例如，–h=scale 对应所有包含 scale 单词的（顶级）选项，特殊字符串 * 会列出全部的顶级选项说明。
注：有点类似于 ffmpeg 的 -h type=name 选项效果，如果在后面指定了需要检索的内容，则会返回这一类的选项帮助说明，比如说 ffmpeg -h encoder=h264
-v
增加（说明内容）详细级别，每个 -v 选项都能在命令行中找到对应的级别。
–version, -V
打印版本字符串信息并退出。
–no-config
不加载默认的配置文件，该选项用于阻止同时加载用户级别和系统范围的 mpv.conf 和 input.conf 文件，其他的配置文件也会被阻止加载，例如负责恢复播放的文件。
注意
那些通过命令行选项的方式明确被需要的（配置）文件，例如 –include 或者 –use-filedir-conf 选项，将仍然会被加载。
另见：–config-dir 选项说明。
–list-options
打印所有可用的选项。
–list-properties
打印可用的属性列表。
–list-protocols
打印受支持的协议列表。
–log-file=<path>
打开给定的路径用于向其中写入和打印日志信息，已存在的文件将会被截断。日志级别至少是 -v 等级，不过可以通过 –msg-level 选项进行提升（该选项无法低于其自身强制的最低日志等级）
一个特殊的情形是 macOS 的捆绑包，默认会在 ~/Library/Logs/mpv.log 路径下创建日志文件。
–config-dir=<path>
强制使用不同的配置目录。如果设置了该选项，给定的目录会被用来加载其中的配置文件，并且其他所有的配置目录都会被忽略，这也意味着全局的mpv配置目录连同每个用户的配置目录都会被忽略，以通过环境变量（MPV_HOME）进行覆盖的配置目录也会被忽略。
需要注意的是 –no-config 优先级高于该选项。
–save-position-on-quit
退出时总是保存当前播放位置，稍后再次播放该文件时，播放器会跳转到原先的播放位置开始播放，如果被播放的文件是通过退出以外的其他任何方式被终止的，那么上述的这种行为就不会发生。例如，当跳转到播放列表中的下一个文件的瞬间是不会保存当前播放位置，并且下次播放时只会在当前需要播放的文件开始。
这项行为默认是禁用的，但当你使用 Shift + Q 退出播放器时，该功能始终是可用的。
注：之前试着用过这项功能，感觉有点鸡肋，并没有想象中的那么智能，不知道最新版本有没有完善。
正常退出播放器时会将当前的播放位置、软件设置等信息保存到配置路径下的 watch_later 目录中（默认），生成一个以MD5值命名的配置文件。
不过当你加载相同的播放列表时，恰巧这个列表内容又很长，如果是图形界面用拖拽的方式播放，很难保证再次播放的首个文件就是之前退出时播放的文件。是的，这个退出保存功能只有在下次播放时恰好加载到之前退出的文件才起作用。
–watch-later-directory=<path>
指定用于存储“稍后再看”临时文件的目录。
默认是配置目录（通常是 ~/.config/mpv/ ）下一个名为“watch_later”的子目录。
–dump-stats=<filename>
向给定文件中写入精确的统计信息，文件在打开时会被截断（如果原先就存在且有内容的话）。文件中会包含原始的样本数据，每项都带有一个时间戳。为了使该文件可读，可以使用 TOOLS/stats-conv.py 脚本（以图像的形式显现）。
该选项仅在调试时会有帮助。
注：这里的可读是相对于人来说的，使用脚本将原始内容处理并转化为人可以理解的信息。
–idle=<no|yes|once>
当没有文件可以播放时让mpv进入空闲等待而不是退出，在输入模式下会很有帮助，可以通过输入命令来控制mpv播放器（默认：no）
once 表示仅在软件启用时空闲等待，并且在首个播放列表播放完毕后让播放器自行关闭。
–include=<configuration-file>
指定要在默认的配置文件之后解析的配置文件。
–load-scripts=<yes|no>
如果设置为 no，则不会自动从配置路径下的 scripts 子目录（通常是 ~/.config/mpv/scripts/ ）中加载脚本。（默认：yes）
–script=<filename>, –scripts=file1.lua:file2.lua:…
加载Lua脚本，第二个选项允许你通过使用路径分隔符（在Unix中是 : Windows下是 ; ）进行分隔的方式加载多个脚本文件。
–script 是一个路径列表选项，详情见 Ch.4.5 List Options 章节。
–script-opts=key1=value1,key2=value2,…
为脚本设置选项，可按照键值查询选项。如果对脚本使用了某个选项，则该选项具体有何语义完全取决于被加载的脚本，未被任何脚本声明过的选项值都会被忽略。
该选项是一个键值组合列表选项，详情见 Ch.4.5 List Options 章节。
–merge-files
假设将所有传给mpv的文件串联成单个大文件，在文件内容使用时间轴/EDL作支持。
–no-resume-playback
不要从配置路径下的 watch_later 子目录（通常是 ~/.config/mpv/watch_later/ ）的配置文件中恢复播放位置。参见 quit-watch-later 输入命令。
–resume-playback-check-mtime
仅在文件的修改时间与保存记录一致时，从 watch_later 目录下的配置文件中恢复播放位置。这可以防止在具有相同名称但内容不同的文件中错误地恢复播放进度。（默认：no）
–profile=<profile1,profile2,…>
使用给定的配置文件，–profile=help 选项会显示当前已定义的配置文件列表。
–reset-on-next-file=<all|option1,option2,…>
一般来说，mpv会在尝试播放列表中的下一个文件时继续保留当前所有的设置，即使这些设置在播放期间被用户修改过（该行为正好与 MPlayer 相反，后者尝试在播放下一个文件时重置所有的设置项）
默认：不要重置任何设置。
上述行为可以使用该选项做出更改，接受选项列表，并且mpv会在开始播放时将这些选项重置为初始值。初始值可以是默认值，或者是由配置文件、命令行（的选项值）进行设置。
在某些情况下，该选项可能不会如预期那样工作，比如说，–volume 选项只会在配置文件或命令行中被明确设置时才会重置。
特殊名称 all 会尽可能多的重置选项。
该选项是一个字符串列表选项，详情见 Ch.4.5 List Options 章节。
–watch-later-options=option1,option2,…
如果给定选项自从mpv开启之后被修改过的话，则会保存到”稍后再看”的文件中。这些值会在下次再次播放该文件时恢复。播放进度总是会以 start 选项的形式保存，因此将 start 添加到这个列表中是没效果的。
当移除选项时，已经存在的稍后再看数据是不会被修改的并且依旧会被完整地应用，不过新的稍后再看数据中将不再包含这些（被移除）的选项。
该选项是一个字符串列表选项，详情见 Ch.4.5 List Options 章节。
–write-filename-in-watch-later-config
采用自身指向的实际文件名作为稍后再看配置文件的命名，只是简单地在文件顶部写上注释。
注：简单来说就是用你播放过的文件名作为恢复播放状态记录文件的命名，而不是默认的MD5值。
警告
该选项可能会暴露个人隐私信息，因此默认是禁用的。
–ignore-path-in-watch-later-config
当使用稍后再看功能时忽略配置所在路径（也就是仅使用文件名）（默认：禁用）
–show-profile=<profile>
显示用户配置描述和内容，如果不指定参数则列出全部的用户配置。
–use-filedir-conf
在与被播放文件的相同目录下查找指定的配置文件，参见 Ch.5.4 File-specific Configuration Files 章节。
警告
如果播放的是未信任的媒体文件也许会有危险。
–ytdl, –no-ytdl
启用 youtube-dl 钩子脚本，查找输入的 URL 链接并播放位于网络中的视频。这项功能适用于众多直播等流媒体网站，而不仅仅是该脚本名称中所表示的网站（Youtube）
如果脚本无法对URL链接执行任何操作，那么将不执行任何操作。（搁这儿搁这儿呢？）
该脚本可接受一组选项，通过带上 –script-opts 选项就可以传入这些内容（使用 ytdl_hook- 作为选项前缀）
try_ytdl_first=<yes|no>
如果选择了 yes 将会首先尝试使用 youtube-dl 去解析 URL 链接，而不是默认的仅在mpv打开链接失败后再去用这个工具去解析。这主要取决于你的大多数链接是否都需要 youtube-dl 工具去解析。
exclude=<URL1|URL2|…
一个用 ‘ | ‘ 分隔且无需mpv使用 youtube-dl 去解析的 URL 模式列表。这些模式用于匹配 URL 链接当中 http(s):// 之后的部分。
^ 用于匹配 URL 链接的开头，$ 匹配结尾，并且你应该在 ^$()%|,.[]*+-? 这些字符之前使用 % 去匹配它们对应的字符。（类似转义符，因为这些字符在模式匹配中有特殊含义，如果需要匹配字面意思需要在前面加一个转义说明符）
参见这里以了解更多 Lua 模式匹配：https://www.lua.org/manual/5.1/manual.html#5.4.1
all_formats=<yes|no>
如果设置为 yes 将会试图添加所有由 youtube-dl 发现并上报的格式（默认：no），每种格式都会以独立的轨道流被添加进来。此外，它们都是延迟加载的，并且实际上仅当轨道流被选中时才会打开（该行为应该会把加载时间保持地和没有该选项时一样少）
添加的是平均比特率的元数据，若可用，意味着你可以使用 –hls-bitrate 选项来决定选择哪条轨道流（HLS 曾经是按类似方式公开且可选质量的唯一格式，因此被沿用至选项名称中）
代表那些由 youtube-dl 选为默认格式的轨道流将具有默认的标志集，这意味着通常mpv应该仍然会选择用 –ytdl-format 选项默认选出的格式。
尽管这个机制做到了在运行期间选择切换数据流，可出于种种技术原因上述行为并不适用于此类目的（反应慢，且不能从真正意义上修复），总之，这个选项没有那么实用，并且之所以添加上仅仅是为了展示一种可行性。
当你尝试在质量和带宽之间做选择的时候有两点必须考虑到：
-
完全独立的音频和视频流（类似DASH）。这些流当中的每一项仅包含音频或者视频，所以你可以不受限制地混合以及组合音频/视频带宽。最为直观地与按轨道流选择质量的概念相吻合（即 all_formats 选项所支持做的事）
-
独立的多路复用音频和视频流集合。各个版本的媒体流中都包含音频和视频流，并且彼此之间是交错存在的。为了避免浪费带宽，你应该仅选择其中的一个版本（例如，如果你选择了其中一个版本的音频流，那么即使你选择了从其他不同媒体流中的视频，依旧会下载该版本对应的视频）
mpv仍然会把它们表示为独立的轨道流，但是会把每个轨道流的标题设为N路复用，其中N会被替换成原始流的 youtube-dl 格式ID。
部分网站会同时混用第1点和第2点内容，不过我们仍然假设之所以这么做是为了兼容性的原因，并且毫无理由去使用它们。
force_all_formats=<yes|no>
如果设为 yes，并且 all_formats 选项同样也被设为 yes，这将会尝试把 youtube-dl 上报的全部格式表示为轨道流，即使mpv大概率会使用它所上报的直链（默认：yes）
如果 youtube-dl 工作在一个 HLS 主播放列表上，表现会与通常情况有所不同。
如果设为 no，则将此特定类型的流视为 all_formats 选项设置为 no 的情形，并且使用通过 youtube-dl 工具完成的媒体流的选择。
use_manifests=<yes|no>
让mpv将主要清单上的网址用于类似 HLS 和 DASH 的格式。若是可行的话，允许在运行期间选择音视频（默认：no），出于性能的原因默认是被禁用的（no）
ytdl_path=youtube-dl
配置指向 youtube-dl 可执行文件或兼容分支的路径。在Unix平台，路径应该通过 : 分隔，在Windows平台上用 ; 分隔。mpv会按顺序查找 PATH 环境变量和自身配置目录中的已配置路径，默认是”yt-dlp”，”yt-dlp_x86″ 以及 “youtube-dl” 这几个文件，在Windows平台上始终会加上 “.exe” 的后缀拓展名。
为什么选项名称中要混用 _ 和 – 符号？
优质回答：我不知道
–ytdl-format=<ytdl|best|worst|mp4|webm|…>
设置直接传递给 youtube-dl 的视频格式/质量。这些可能的值是特定于网站和视频而言，对于给定的URL链接，可以使用 youtube-dl –list-formats URL 命令找到可用的格式。参见 youtube-dl 的文档以获取可用的别称。（默认：bestvideo+bestaudio/best）
ytdl 的值是完全不会向 youtube-dl 传入 –format 选项的，因此也不会覆盖其自身的默认值。需要注意的是 youtube-dl 有时会返回mpv无法处理的格式，并且在这些情况下，mpv默认设置可能会运作地更好些。
–ytdl-raw-options=<key>=<value>[,<key>=<value>[,…]]
向 youtube-dl 传入任意的选项，形参（parameter）与实参（argument）都应该以键值对（key-value pair）的形式传入。不带实参的选项也必须包含 = 。
该选项没有健全的检查机制，因此可能会出问题（即向 youtube-dl 传入非法参数）
可以向 youtube-dl 传入一个代理URL链接，以便在解析网址的时候使用，这对于受到地理位置限制的网站会很有用。在 youtube-dl 完成解析后，一些URL仍然需要代理来完成播放，因此这种方式同样也能够向mpv播放器传入代理信息。注意，SOCKS 代理不受支持，并且 https 网址同样会绕过代理，这是受 FFmpeg 的限制所决定的。
该选项是一种键值对列表选项，参见 Ch.4.5 List Options 章节以获取更多细节。
注：虽然我不太了解 youtube-dl 的具体功能和高级用法，但是如果能不断尝试和仔细设置以上这些选项，让mpv配合ytdl实现对各种网络流的操作，在这方面的综合表现应该不会逊于市场上大多数媒体播放器。
–load-stats-overlay=<yes|no>
启用通用键位绑定的方式显示有用的播放信息的内置脚本（默认：yes），默认情况下，使用的是 i 键位（ I 键位是用于持久化显示）
–load-osd-console=<yes|no>
启用通过键位绑定的方式显示控制台并让你输入命令的内置脚本（默认：yes），默认是使用 ` 键位显示控制台，ESC 键再次隐藏（该功能是基于一个名为 repl.lua 的用户脚本）
–load-auto-profiles=<yes|no|auto>
启用执行自动配置文件的内置脚本（默认：yes），参见 Ch.5.7 Conditional auto profiles 章节以获取更多细节。auto 参数会加载脚本，但如果没有遇到条件配置文件的话，则会立即卸载脚本。
–player-operation-mode=<cplayer|pseudo-gui>
用来启用”伪图形界面模式”，意味着某些选项的默认值会发生改变，该选项一般不应该直接使用，而是只能由mpv在其内部使用，或者由mpv提供的脚本、配置文件或 .desktop 文件使用。参见 Ch.11 PSEUDO GUI MODE 章节以获取更多细节。
Ch.13.4 视频
–vo=<driver>
指定需要使用的视频输出后端，参见 Ch.15 VIDEO OUTPUT DRIVERS 章节以获取更多细节与可用驱动的描述。
–vd=<…>
根据家族类别和名称，指定用到的视频解码器的优先级列表。参考 –ad 选项以获取更多细节，这两个选项使用相同的语法和语义，唯一的区别是它们工作在不同的编解码器列表上。
注意
参见 –vd=help 获取可用解码器的完整列表。
–vf=<filter1[=parameter1:parameter2:…],filter2,…>
指定应用到视频流之上的视频滤镜列表，参见 Ch.17 VIDEO FILTERS 章节以获取更多细节和可用滤镜的描述。存在 –vf-add，–vf-pre，–vf-del 以及 –vf-clr 的选项变体用于修改先前指定的列表，不过你通常是不需要用到这些变形。
–untimed
输出视频帧时（电脑）不要进入睡眠模式，这在使用 –no-audio 选项进行基准测试的时候会有所帮助。
–framedrop=<mode>
在运行较慢的系统上跳过部分画面帧以维持音画（A/V）同步，或者在具有帧率上限的视频输出中播放高帧率视频。
参数是选择丢帧模式，并且可以是下列的其中一项：
<no> 禁用任何形式的丢帧，不推荐，仅测试用。
<vo> 在视频输出中丢弃延迟帧（默认），这仍然会对全部的视频帧进行解码和施加滤镜，但不会在视频输出中渲染它们（被丢弃的延迟帧），在终端状态行中指示为 Dropped: 字段。
在音频同步的模式中，这将会丢弃那些在显示时就已经过时的画面帧。如果解码器产出过慢，理论上所有的画面帧都必须被丢弃（因为所有的帧都延迟了）为了避免这种情况，如果有效帧率低于10 FPS，那么丢帧行为将会停止。
在显示同步模式下（参见 –video-sync 选项），这只会影响音画丢弃和重复画面帧的方式，如果该模式被禁用，理论上音画不同步将不再影响视频调度（非常类似：显示 – 重新采样 – 非同步的模式）。但即使被禁用，仍会按照视频与显示频率之间的比率选择跳过画面帧（也就是丢弃）
这是比较推荐的模式，并且是默认项。
<decoder> 老旧且基于解码器的丢帧模式（这与mpv 0.5.x 以及更早版本中的 –framedrop=yes 选项是一致的），这会告诉解码器跳过画面帧（除非这些帧需要被用来解码未来帧）。或许在运行较慢的系统中会有帮助，但可能会产生无法观看的间断输出，甚至是完全冻结住显示。
这种使用了启发式办法可能没有意义，并且通常无法达成较好的结果，因为无法用可预测的方式控制解码器的丢帧行为，所以不推荐。
即使你想用这个选项，推荐 decoder+vo 的方式以获取更好的结果。
–vd-lavc-framedrop 选项控制了什么样的帧需要被丢弃。
<decoder+vo> 同时启用这两种模式，不推荐，只比 decoder 模式好一点点。
注意
–vo=vdpau 选项有它自己对 vo 丢帧模式的编码方式，因此与其他视频输出可能略有不同。
–video-latency-hacks=<yes|no>
启用部分倾向于通过1~2帧来降低视频延迟的行为（默认：no），需要注意的是，一旦播放器的计时编码本身不再需要执行这些操作，则可能会在毫无通知的情况下移除该选项。
该选项会：
-
使用解复用器为丢帧行为报告FPS值，这避免了播放器需要预先解码1画面帧，有效降低了总的延迟。这也意味着如果解复用器错误地报告了FPS，或者视频滤镜链改变了FPS值（例如隔行扫描），则会丢弃过多或不足的画面帧。
-
禁用对首个视频帧的等待，通常播放器在正确开始播放前，会等待首个视频帧完全渲染。部分视频输出在渲染第一帧时会惰性地初始化内容，所以如果不这么做，渲染首帧的时间超出所需时间，那么视频输出被迫会丢弃掉一些帧。
–override-display-fps=<fps>
设置使用 –video-sync=display-* 模式来显示FPS值，默认使用检测到的值，留意设置了错误的值（即使是稍有不慎）都可能会破坏视频的播放。在接入多个显示器的系统上，检测到的错误值可能来自错误的显示器。
仅当你有足够的理由相信自动确定的值有错误时，再来设置该选项。
–display-fps=<fps>
–override-display-fps 选项的已弃用别名。
–hwdec=<api>
指定应该尽可能使用的硬件解码API，是否进行硬件解码实际上取决于视频编解码器，如果硬件解码不可用，mpv会退回到软件解码（使用CPU解码）
硬件解码默认是不开启的，因为它通常是发生错误的另一个诱因，仅当你的CPU解码特定的视频太慢时才值得去使用。
注意
使用 Ctrl + h 快捷键可以在运行期间切换硬件解码模式，让该选项在 auto 和 no 之间变换。
不推荐通过添加选项到配置文件中的方式始终开启硬解，如果你在用的是Ubuntu软件包，请删除 /etc/mpv/mpv.conf，因为软件包通过设置 hwdec=vaapi 默认会尝试开启硬解（效果不会太理想，甚至可能会导致使用次优化包装器），或者至少把它修改为 hwdec=auto-safe
如果你想要启用硬解，那么请使用自动模式当中的其中一个。显式选择模式主要用来测试和调试。如果你想要在（平台环境）更新之后继续工作，把显式选择放到配置文件中是比较糟糕的想法。
注意
即使是启用状态，硬件解码依然只会把部分编解码器列入到白名单，参考 –hwdec-codecs 选项以便在更多场景下开启硬件解码。
该选择哪种办法？
如果你只是想在播放期间启用硬解，不要设置相应参数，或者可以把 hwdec=no 放到你的 mpv.conf 配置文件里去（和在默认情况下强制启用硬解的发行版有关，例如在Ubuntu平台上），请使用 Ctrl+h 这个默认的快捷键在播放期间开启硬解。
如果你不是很确定，但想要默认始终开启硬解，把 hwdec=auto-safe 配置项放到你的 mpv.conf 配置文件里去，并且需要承认的是该用例不是”真正”支持硬解，而且可能会导致问题。
如果你想要测试可用的硬件解码方案，传入 –hwdec=auto，–hwdec-codecs=all 然后观察终端输出。
如果你是一名开发者，或者想执行详尽的测试，你可能会需要其他任何可能的选项值。
<api>的内容可以是以下其中一项：
-
no：始终使用软解（默认）
-
auto：强制启用任何能找到的硬件解码器（见下文）
-
yes：准确来说和 auto 一样
-
auto-safe：启用任何在白名单中的硬件解码器（见下文）
-
auto-copy：启用带 copy-back 功能且表现最好的硬件解码器（见下文）
-
vdpau：需要搭配 –vo=gpu 与 X11，或者 –vo=vdpau 配置项（仅Linux平台）
-
vdpau-copy：将视频拷回到系统内存（仅Linux平台和部分GPU）
-
vaapi：需要搭配 –vo=gpu 或者 –vo=vdpau 配置项（仅Linux平台）
-
vaapi-copy：将视频拷回到系统内存（仅Linux平台和部分GPU）videotoolbox：需要搭配 –vo=gpu（macOS 10.8及其以上版本），或者 –vo=libmpv 配置项（iOS 9.0及其以上版本）
-
videotoolbox-copy：将视频拷回到系统内存（macOS 10.8或者iOS 9.0以上版本）
-
dxva2：需要搭配 –vo=gpu 与 –gpu-context=d3d11，–gpu-context=angle 或者 –gpu-context=dxinterop 配置项（仅Windows平台）
-
dxva2-copy：将视频拷回到系统内存（仅Windows平台）
-
d3d11va：需要搭配 –vo=gpu 与 –gpu-context=d3d11 或者 –gpu-context=angle 配置项（仅Windows 8+平台）
-
d3d11va-copy：将视频拷回到系统内存（仅Windows 8+平台）
-
mediacodec：需要搭配 –vo=mediacodec_embed 配置项（仅Android平台）
-
mediacodec-copy：将视频拷回到系统内存（仅Android平台）
-
mmal：需要搭配 –vo=gpu 配置项（仅树莓派平台，默认如果可用的话）
-
mmal-copy：将视频拷回到系统内存（仅树莓派平台）
-
nvdec：需要配合 –vo=gpu 配置项（所有可用CUDA平台）
-
nvdec-copy：将视频拷回到系统内存（所有可用CUDA平台）
-
cuda：需要配合 –vo=gpu 配置项（所有可用CUDA平台）
-
cuda-copy：将视频拷回到系统内存（所有可用CUDA平台）
-
crystalhd：将视频拷回到系统内存（所有受硬件支持的平台）
-
rkmpp：需要配合 –vo=gpu 配置项（仅部分瑞芯微（RockChip）设备）
auto 模式会尝试使用首个可用的方案来自动启用硬件解码。这仍取决于你所使用的视频输出，例如，如果你没有使用 –vo=gpu 或者 –vo=vdpau 配置项，那么永远不会启用 vdpau 解码。另外需要注意如果首个被找到的解码方案实际不能用的话，将始终退回到软解，而不是继续尝试下一个方案（或许在某些Linux系统上情况会好一些）
auto-safe 和 auto 比较类似，但仅允许那些被认为是安全且在白名单当中的方案。默认情况下，这应该是在配置文件中启用硬件解码较为合理的方案（即使你无论如何都不应该那么做，更推荐在运行期间用 Ctrl+h 去开启），不像 auto，该模式不会尝试去启用未知或已知不良的方案。此外，在其他情形中当被认为会导致问题时可能会禁用硬件解码，但就目前而言这种机制是相当原始的（作为当前仍然会导致问题的示例：Windows平台上的HEVC和Intel芯片的某些组合往往会造成mpv的崩溃，很有可能是由于驱动程序中的bug导致）
auto-copy-safe 选择了 auto-safe 和 auto-copy 两者的联合方案。
auto-copy 仅选择在解码之后将视频数据拷回到系统内存中的模式。这种选择模式类似 vaapi-copy（等诸如此类），如果这些方案都不工作，则会禁用硬解。与软解相比（假设使用了现代编解码器和没有错误的视频流），这种模式通常能够保证不会造成额外的画面质量损失，并且允许用CPU处理视频滤镜。该模式适用于全部的视频滤镜和视频输出。
因为要将解码好的视频拷回至系统内存，效率通常会比直接模式要来得低，并且可能对软解没多大帮助。
注：copy-back 会将视频数据拷回到主内存之后再进行绘制，因此会造成性能开销，但提升了解码的稳定性
注意
大多数非拷贝方案仅适用于OpenGL GPU后端。目前，仅有 vaapi，nvdec 和 cuda 方案适用于Vulkan。
如果搭配使用了 –vo=gpu，vaapi 模式还需要 Mesa 11图形库，并且大概率仅适用于Intel和AMD的GPU，还需要opengl EGL后端。
nvdec 和 nvdec-copy 是最新模式，并且是在Nvidia的GPU上进行硬件解码的推荐方案。
注：皮衣刀客通过其精湛的刀法会阉割部分中、低端N卡的视频编解码核心，因此可能会不支持 nvdec 系列的硬解模式。
cuda 和 cuda-copy 是Nvidia GPU硬件解码较为老旧的实现，使用的是Nvidia的比特流解析器而不是FFmpeg的解析器，这可能会导致功能上的缺陷，比如说HDR内容的不正确播放，除非你特别需要Nvidia的隔行扫描算法，否则应该始终首选 nvdec/nvdec-copy。要想使用这种隔行扫描必须传入 vd-lavc-o=deint=[weave|bob|adaptive] 选项，传入 weave（或者不设置上述选项）则不会尝试任何隔行扫描操作。
使用硬件解码会带来画面质量的降低？
理论上，硬件解码不会降低视频画质（至少对于h264和HEVC编解码器来说是这样的），不过由于视频输出API的限制，同样也有实际硬件解码器当中的bug，种种因素可能会造成一些损失，甚至是明显的错误结果。
在某些模式下，RGB转换是强制的，意味着RGB转换是由硬件解码API执行的，而不是 –vo=gpu 所使用的着色器。这意味着部分色彩空间可能无法正常显示，并且部分滤镜（例如去色带（debanding））可能无法以理想的方式被应用，这通常也会强制使用低质量的色度缩放器，在其他情况下，硬件解码还可以减少被解码图像的位深，可能会导致 10-bit 色深文件的色带或精度丢失。
vdpau 始终会在硬件上进行RGB转换，不能正确支持像 BT.2020 这样较新的色彩空间。不过，vdpau 不支持 10-bit 色深或 HDR 编码，因此这些限制不太可能有关联。
vaapi 和 d3d11va 是安全的，开启隔行扫描（或者仅启用各自的后处理滤镜）至少可能会通过将输出转为8位色深的格式来降低色彩质量。
dxva2是不安全的，始终使用 BT.601 用于强制RGB转换，但实际行为取决于GPU驱动程序，某些驱动程序会将其转换为有限范围的RGB，从而会表现为褪色，除了特定的驱动程序行为以外，全局系统设置也可能会对此产生影响，即使是用完全普通的视频源也可能给出错误的结果。
rpi 始终使用硬件层面的渲染器，即使是搭配了 –vo=gpu 配置项。
cuda 通常应该是安全的，但取决于文件/数据流混合的方式，有报告称它会破坏时间戳导致故障或画面闪烁。由于未知原因，它有时也会导致大量画面被丢弃，建议谨慎采用并始终应该首选 nvdec
crystalhd 是不安全的，始终会转为 4:2:2 YUV 颜色编码，在此过程中可能会有损耗，取决于转换期间色度二次采样（Chroma Subsampling）的完成方式。出于某种原因还会丢弃每帧的左上角像素。
其他所有方案，特别是回拷（copy-back）办法（像 dxva2-copy 之类）应该是安全的，虽然依旧会导致随机的解码问题，但最起码不会影响图像的颜色。
特殊的是，auto-copy 虽然仅会选择所谓的“安全”模式（尽管可能会比其他方法要慢些），但仍然无法保证所选用的硬件解码器实际上可以正常工作。
总之除非是刚需，否则强烈建议避免使用硬件解码，也就是说如果你的CPU不足以解码一些成问题的文件。如果你遇到任何奇怪的解码问题，比如画面帧故障或者变色，并且你开启了 –hwdec 选项，那么你首先应该尝试着禁用它。
注：硬解这东西仁者见仁智者见智，如果是CPU性能捉襟见肘的机子又恰好有个支持视频编解码的核显或者独显，能用上的就尽量用上，提升能效比。
–gpu-hwdec-interop=<auto|all|no|name>
该选项用于对硬件解码器交互操作进行故障排除，由于是一个调试选项，其语义可能随时会变化。
这对于GPU和libmpv视频输出选择要使用硬件解码器的交互操作上下文会很有用，实际上，它还可以用来阻止某些后端的加载。
如果设为 auto（默认），行为将取决于视频输出：对于GPU来说，什么也不会做，并且按需加载交互操作的上下文（当解码器检测到有 –hwdec 选项支持时）；对于没有按需加载的libmpv，这等同于 all 参数。
参数为空字符串等同于 auto 参数。
如果设为 all，会尝试在GL上下文创建期间加载全部的交互操作上下文。
除此之外，可以设置特定的（视频输出）后端，并且可以借助 help 命令查询它们的列表（仅在mpv CLI 模式下）
运行期间对此所做的更改会被忽略（每当创建渲染器时都会使用当前选项值）
–opengl-hwdec-interop 以及 –hwdec-preload 等旧的别名则不再与此选项有关，但会在某些情况下部分兼容。
–hwdec-extra-frames=<N>
硬件解码应该预分配的GPU帧数（默认：见 –list-options 的输出内容），如果该数值过低，画面帧有可能会在解码过程中分配失败，并且可能会丢失或损坏视频帧；设置得过高只会浪费GPU显存且毫无优势可言。
该值仅适用于需要预分配图形表面的硬件解码API（已知的例子包括 d3d11va 和 vaapi），对于其他API，画面帧在需要时被分配。具体细节取决于 libavcodec 库当中硬件解码器的实现。
所需的表面数量取决于动态运行时的状况，默认是一个被认为可以满足大多数用途的固定值，但在某些情况下可能还不够。
–hwdec-image-format=<name>
设置由 –hwdec 选项设定的硬件解码所使用的内部像素格式（默认：no），特殊值 no 表示选择一种特定实现的标准格式。大多数解码器的实现仅支持一种格式，并且如果是不支持的格式，则无法初始化。
部分实现可能支持多种格式，特别是已知 videotoolbox 属性需要 uyvy422 格式
才能在某些较老的硬件上获得不错的性能。d3d11va 始终可以使用 yuv420p 这种无优势可言的不透明格式。
–cuda-decode-device=<auto|0..>
当使用带有OpenGL GPU后端的 cuda 或者 nvdec，以及所有使用了 cuda-copy 或者 nvdec-copy 硬件解码器的场景时，选择用于解码的GPU设备。
对OpenGL GPU后端来说，默认用于解码的设备是被用来提供GPU输出的那个（并且在绝大多数情景下，只会有一个GPU存在）
对于 copy 模式的硬件解码器，默认设备是由CUDA库枚举出来的首个设备，无论如何都是如此。
对于Vulkan GPU后端，解码始终会在显示设备中进行，并且该选项不会对此起作用。
–vaapi-device=<device file>
选择DRM设备用于 vaapi-copy，该参数应该是一个DRM设备文件的路径（默认：/dev/dri/renderD128）
注：Direct Rendering Manager（DRM）是linux内核子系统，负责与显卡交互。 DRM提供一组API，用户空间程序可以使用该API将命令和数据发送到GPU并执行诸如配置显示器的模式设置之类的操作。
–panscan=<0.0-1.0>
开启裁剪（Pan&Scan）功能（例如裁剪16:9视频的边缘画面以适应4:3的显示，且不带黑边填充）数值范围控制着图像的裁剪数量，可能不适用于所有的视频输出驱动。
如果使用了 –video-unscaled 选项则该选项不会起作用。
–video-aspect-override=<ratio|no>
覆盖视频的横纵比，以防止正在播放的文件中的横纵比信息错误或丢失。
以下的这些值具有特定的含义：
-
0：禁用横纵比处理，假设视频具有矩形像素。
-
no：作用和 0 一样
-
-1：使用视频流或容器中的比例（默认）
但要注意的是这些特定值的处理方式以后可能会改动。
–video-aspect-method=<bitstream|container>
设置默认的视频横纵比测定方法（如果横纵比未被用户使用 –video-aspect-override 或者其他选项覆盖的话）
container：严格首选容器中的横纵比，很明显是VLC的默认行为，至少在 Matroska 格式容器中是这样，注意如果容器未设置横纵比，则该行为与 bitstream 一致。
bitstream：严格首选比特流中的横纵比，除非未设置比特流横纵比，很明显是XBMC/kodi的默认行为，至少在 Matroska 格式容器中是这样。
目前对mpv来说默认是 container
通常你不应该设置该选项，如果你在mpv播放过程中遇到横纵比出错的视频，但在其他播放器中似乎又没问题，那么可以尝试不同的选择。
–video-unscaled=<no|yes|downscale-big>
禁用视频缩放，如果窗口比视频（横纵比）来的要大，（多余的部分）用黑边填上，否则视频会被裁剪，除非选项被设为 downscale-big，在这种情况下视频会适应窗口大小，但视频仍然可以受到其他 –video-… 选项的影响，该选项会禁用 –panscan 选项的效果。
需要注意的是缩放算法可能依旧会被使用，即使视频不允许被缩放。举个例子，这可以影响到色度转换（Chroma Conversion），如果视频源使用非方形像素（例如超宽屏DVD）那么视频照样会在一个维度上进行缩放。
如果使用了 –no-keepaspect 选项则该选项会被禁用。
注：当遇到屏幕窗口大小与画面横纵比不匹配的情况，为了最大程度地显示调整后的画面，需要用到缩放算法来处理原画。要么选择 Pan&Scan 模式，显示的时候把多余的画面部分裁剪丢弃掉；要么选择 Letterbox 模式，显示的时候空缺的部分用黑色边框填充；要么采用自适应，可以是填充、拉伸、平铺等等之类的处理办法，各有各的取舍和优缺点，没有谁最好谁最坏的说法。
–video-pan-x=<value>, –video-pan-y=<value>
通过给定地 X 或 Y 方位值移动显示视频的矩形区域（之外部分裁剪掉），单位是缩放视频大小的小数部分（得是完整大小，即使是因为 panscan 或其他选项导致看不到的视频的其他部分，也算在内）
例如。一个带 –video-pan-x=-0.1 参数的，且在 1680×1050 分辨率的屏幕上显示 1280×720 视频全屏画面，将会移动视频画面中的168个像素到屏幕左边（让原画中（最左边）的128个像素不可见？原文可能写错了）
如果使用了 –no-keepaspect 选项则该选项被禁用。
–video-rotate=<0-359|no>
按度数顺时针旋转视频画面，如果参数给定为 no，则无论如何都不会旋转视频画面，即使文件中包含旋转的元数据（旋转数值被添加到表示旋转的元数据中，意味着参数值设为 0 照样会参考旋转元数据来旋转视频画面）
当不带 copy-back 地使用硬件解码，只有以90°为步长的数值才会运作（例如 0，90，180，270），不过软解和那些带有把视频回拷至系统内存功能的硬解方案支持0~359之间的所有数值。
–video-zoom=<value>
通过给定的数值调节视频显示缩放比例因子，最终参数由log2公式计算给出，–video-zoom=0 表示不缩放，–video-zoom=1 表示2倍大小，–video-zoom=-2 表示1/4倍大小，依此类推。
如果使用了 –no-keepaspect 选项则该选项被禁用。
注：就是 log2(x) = value，求出 x 的数值就是参数值。比方说例子中的 value = 0，就是求 log2(params) = 0，很显然 param = 1，缩放之后的画面和原画是 1:1 的关系，所以不缩放，依此类推。
–video-scale-x=<value>, –video-scale-y=<value>
将视频显示大小与给定的数值相乘（默认：1.0），如果使用了非默认值，这将会导致和窗口大小不一致，因此视频画面要被裁剪，或者要么补上黑边。
该数值会乘上从 –video-zoom 选项推导得到的数值以及普通视频画面的横纵比，如果使用了 –no-keepaspect 选项则该选项被禁用。
–video-align-x=<-1-1>, –video-align-y=<-1-1>
在黑框边界内移动视频画面矩形区域，如果视频画面与屏幕的横纵比不一致，通常会将视频画面添加、填充到屏幕上。
–video-align-y=-1 会将视频画面移动到屏幕顶部（只留黑框边界在底部），数值 0 使画面居中（默认），以及数值 1 会将视频画面放到屏幕底部。
如果画面与屏幕的横纵比能够完美匹配，那么无需操作这些选项。
如果使用了 –no-keepaspect 选项则该选项被禁用。
–video-margin-ratio-left=<val>, –video-margin-ratio-right=<val>,
–video-margin-ratio-top=<val>, –video-margin-ratio-bottom=<val>
在各个边界上设置额外的视频画面边距（默认：0），各项数值都是相对于窗口大小的比例，使用 0.0~1.0 范围的数值。比如说，在一个大小为1000像素的窗口上设置了 –video-margin-ratio-right=0.2 的选项，那么将会在窗口右侧添加一个200像素大小的边界。
视频画面会被这些边距所“盒化”（像是放在一个黑盒子当中一样），而窗口大小不会改变，尤其是不会扩大窗口大小，并且边距默认将会造成视频画面缩放，将来会不会做出调整这个说不定。
边距会在视频旋转90°之后应用，但至少会在其他任何视频转换之前应用。
如果使用了 –no-keepaspect 选项则该选项被禁用。
字幕依然可以使用边距，具体取决于 –sub-use-margins 以及类似的选项。
这些选项使为了OSC创建的，一些奇奇怪怪的设定，例如将边距值设为比例（而不是像素值）等，也都是为了OSC。这些选项可以被使用更加普遍和有用的选项所替代，这些选项的行为也可以被改动以更好地满足OSC的需要。
–correct-pts, –no-correct-pts
–no-correct-pts 选项把mpv切换到使用固定帧率值、视频时序确定的模式上来（无论是使用 –fps 选项，或是使用文件信息），有时，时间戳极度破损的文件在这种模式下可以很好地播放。需要注意视频滤镜、字幕渲染、跳转（包括 hr-seeks 和回退），以及音频同步在该模式下都可能会被完全打断。
–fps=<float>
覆盖视频帧率，如果原数值出错或丢失时会很有用。
注意：
仅在 –no-correct-pts 模式下生效。
–deinterlace=<yes|no>
启用或禁用逐行扫描（默认：no）（写了那么多的补充说明，真的不得不吐槽一下，原文当中这句话是在说开启或关闭 interlace 隔行扫描功能，到了下面又改口说是 deinterlace 逐行扫描，以至于前后矛盾。直接说“启用或禁用逐行扫描”和选项名称含义保持一致有什么问题吗？如果硬说没问题，作为说明手册表意方面能别绕弯子嘛？），隔行扫描地视频在画面快速移动（变化）时会显示较为丑陋的梳状假影，启用该功能通常会插入 yadif 视频滤镜以便逐行扫描，或者是让视频输出用上逐行扫描，如果支持的话。
该行为同 deinterlace 输入属性基本相同（通常是被映射到 d 按键上）
请留意这会和手动插入的逐行扫描滤镜产生冲突，除非你能小心翼翼地处理好（从 mpv 0.27.0 版本起，即使是使用硬件去逐行扫描地滤镜也会产生冲突。同样是从该版本开始，–deinterlace=auto 选项被移除了，这曾经是意味着使用了可能会插入视频滤镜的隔行扫描选项。）
需要注意的是如果视频本身实际上不是逐行扫描的话，会让视频画面看上去更加糟糕。
–frames=<number>
仅播放/转换前<number>帧的视频帧，随后退出。
–frames=0 会加载文件，但是会在初始化播放之前立即退出（对于只想确定某些文件属性的脚本可能会很有用）
对于纯音频播放，任何大于 0 的值将在初始化之后立即退出，同视频一样工作方式。
–video-output-levels=<outputlevels>
表示使用了从 YUV 到 RGB 转换的 RGB 色阶（Color Levels），通常，输出设备，例如PC显示器会使用全色阶（Full Range Color Levels）。然而，一些电视以及视频监控器需要工作室级别的 RGB 色阶，向需要工作室级别的输入设备提供全色阶输出会导致黑白画面挤压，而深灰黑色和暗白色则相反。
不是所有的视频输出都支持该选项，一部分会静默忽视它。
可用的色彩范围有：
-
auto：自动选择（等同于全部范围）（默认）
-
limited：有限范围（各组件在 16~235 范围内），工作室级别
-
full：全部范围（各组件在 0~255 范围内），PC级别
注意
如果可以的话，建议使用你自己的图形设备的色彩范围选项。
–hwdec-codecs=<codec1,codec2,…|all>
仅允许使用给定列别中的编解码器来进行硬件解码，特殊值 all 始终会允许所有的编解码器。
你可以用 mpv –vd=help 命令来获取允许的编解码器列表，需要去掉前缀，比方说，使用 h264 而不是 lavc:h264
默认情况下，该项被设为 h264，vc1，hevc，vp8，vp9，，请注意，类似 h264_vdpau 这样特殊的硬件加速硬件加速编解码器不再与之（h264列表选项）相关联，实际上已经参照这种形式从 Libav 中删除了。
这通常只在出了问题的GPU中被需要，其中编解码器会被报告为受支持的，但解码导致的问题会多于解决这些问题的问题。
示例：
mpv –hwdec=vdpau –vo=vdpau –hwdec-codecs=h264,mpeg2video
仅启用针对 h264 和 mpeg2 的 vdpau 硬件解码。
–vd-lavc-check-hw-profile=<yes|no>
检查硬件解码器的配置文件（默认：yes），如果设为 no，则会无条件地选择硬件解码器最高级别的配置文件，且被用于强制解码，即使视频的配置文件级别要比前者来得高些，最有可能的结果是解码被中断，但如果检测到的或报告的配置文件存在这样那样的问题，也有可能会有帮助。
–vd-lavc-software-fallback=<yes|no|N>
如果硬件加速解码器失败则回退到软件解码（默认：3），如果该参数是一个数字N，那么在连续N帧解码失败后将触发回退，数字 1 等同于 yes。
将该数值设成较大的数字可能会中断播放并开始回退：如果发生了回退的情况，将跳过文件的一部分，大概是会跳过无法被解码的数据包数量，低于未指定计数的值不会出现该问题，因为mpv会把数据包保留下来。
–vd-lavc-dr=<yes|no>
启用直接渲染（默认：yes），如果该项被设为 yes，那么视频将会被直接解码到GPU的视频内存中去（或者是暂存缓冲区），该功能可以加快视频的载入速度，并且可能会对大分辨率的视频或速度慢的硬件有所帮助。仅在具有以下的视频输出中工作：
-
gpu：至少需要 OpenGL 4.4 或 Vulkan（尤其是，该选项无法同 opengl-cb 选项一块工作，但是对libmpv渲染API具有可选的支持）
使用写入图像数据的任何类型的视频滤镜，将会以静默的方式禁用DR码路径。
–vd-lavc-bitexact
仅在所有解码阶段中使用位精确算法（用在编解码器的测试上）
–vd-lavc-fast (仅限 MPEG-2，MPEG-4 以及 H.264)
启用不符合格式规范并且可能会导致问题的优化，例如更为简单的反量化、运动补偿；假定使用默认量化矩阵、YUV 4:2:0 并跳过若干检查以检查受损的比特流。
–vd-lavc-o=<key>=<value>[,<key>=<value>[,…]]
将 AVOption 传递给 libavcodec 解码器，AVOption 的完整列表可以在 FFmpeg 手册中找到。
部分曾经是直接选项可以使用之中机制进行设置，例如 bug，gray，idct，ec，vismv，skip_top（又写作 st），skip_bottom（又写作 sb），debug
–vd-lavc-show-all=<yes|no>
显示即使是已破损和损坏的视频帧（默认：no），如果该项被设为 no，libavcodec 将不会输出在解码初始关键帧之前解码好的帧，也不会输出被识别为已损坏的帧。
–vd-lavc-skiploopfilter=<skipvalue> (仅限 H.264)
在H.264解码期间跳过循环滤波（AKA去除块效应）。由于经过滤波处理后的帧应该用作解码关键帧的参考，这比那些不对例如MPEG-2之类的视频进行去块处理，在画质上的效果还要差。但至少对于高码率高清电视（HDTV）而言，这在几乎没有肉眼可见的画质损失下提供了非常可观的加速效果。
<skipvalue>可以是下列中的其中一个：
-
none：从不跳过。
-
default：跳过无用的处理阶段（例如AVI中大小为0的数据包）
-
nonref：跳过未被引用的帧（即未被用于解码其他的视频帧期）
-
bidir：跳过B-帧。
-
nonkey：跳过除关键帧以外的所有帧。
-
all：跳过所有帧
–vd-lavc-skipidct=<skipvalue> (仅限 MPEG-1/2)
跳过IDCT阶段，这在几乎所有情况下都会极大程度地降低画质（有关可用的 skipvalue 请参见 skiploopfilter）
–vd-lavc-skipframe=<skipvalue>
完全跳过帧解码，虽然会有较大的提速，但运动画面会变得生硬并且有时还会有假影（有关可用的 skipvalue 请参见 skiploopfilter）
–vd-lavc-framedrop=<skipvalue>
搭配使用 –framedrop 选项来设置丢帧模式（有关可用的 skipvalue 请参见 skiploopfilter）
–vd-lavc-threads=<N>
指定用来解码的线程数，实际是否支持线程取决于所用的编解码器（默认：0），0 表示自动检测并使用计算机上的内核数，最大为16，但你仍可以手动设置16个以上的线程数。
–vd-lavc-assume-old-x264=<yes|no>
假设编码视频用的是老旧且有缺陷的x264版本（默认：no），通常，这是由 libavcodec 自动检测的，但如果比特流中不包含x264版本信息（或是因为某种情况跳过了它），并且该比特流实际上是通过旧版本（150 或者更早的版本）的x264进行编码，而且如果使用了4:4:4色度，则 libavcodec 将默认显示已损坏的视频，该选项将 libavcodec x264_build 选项设为150，这就意味着如果流中不包含版本信息，或者根本不是由x264编码的，则假定它是由旧版本编码。如果你希望已损坏的文件也能够正常工作，那么启用该选项会安全很多，但从理论上来讲，这可能会在那些不是由x264编码或者是由较新x264版本且不包含版本信息的流上造成中断。
–swapchain-depth=<N>
最多允许N个 in-flight 帧，实际上是控制帧延迟。增加交换链深度可以改善流水线并放置错过画面同步，但会增加可见的延迟，该选项仅规定了上限，实现了可使用比内部请求更低的延迟。设置为 1 表示视频输出将会等待至每一帧都变得可见，随后再开始渲染下一帧（默认：3）
参考资料：
-
https://mpv.io/manual（MPV Player Reference）
-
https://mpv.io（mpv项目官网）