NAZOrip | It Is a Mystery !!! - 文献 / Documentation
一款智能化、自动化、参与操作流程，带领新手入门高级视频压制的图形化 UI/UX 软件。功能概述源验证：根据 ffprobe 读数验证源视频提供包含成功、警告和错误状态的源检查清单与强行绕过功能高级并行处理：在指定线程数量的基础上，支持逐物理核心和 NUMA 节点绑定设置编码器参数配置：提供方便的 UI 控件来控制视频压制参数，包括标签页菜单、滑条、下拉菜单等元素提供单图压制 A/B 对比预览器，实时检查参数配置对任意帧的影响自动化与自定义：自动编写基本的 AviSynth、VapourSynth 脚本（视频解码与管道输出）为 FFMPEG-VS-AVS 生成 VFR→CFR 滤镜、HDR→SDR+色彩空间转换滤镜、缩放滤镜、SAR 修复滤镜提供 FFMPEG-VS-AVS 滤镜编辑器自动生成视频压制参数，并生成音频压制命令提供可动态编辑的队列模式取段打样：使用 FFMPEG-VS-AVS 命令行生成选择时间/帧号高级监控：监控每个应用程序的内存使用情况，分别查看上游和下游（编码器）日志中断控制：可中断上游或下游程序（编码器）以一致地退出编码会话覆写保护：基于待覆盖文件大小的冷却时间防呆设计其它特点支持 x264、x265 和 SVT-AV1 编码器鼓励用户使用最新的修改版编码器软件截图本软件支持多语言，但为减少图片数量而在此统一用了英语文本截图。图片中可能会有一些过时的 UI 元素或文本，但整体布局和功能区域划分仍然适用。主页滤镜编辑器编码器/压制设置并行计算设置取段打样器压制监视器报错窗口与覆写保护功能蓝光播放列表选择器重分集编辑器设置字幕轨道编辑器（队列模式）运行要求Windows 10/11 x64推荐 1809 / 21H2（LTSC）或更高版本，最低 1607下载软件本体GitHub 发布页下载编码相关工具你可以根据此教程来寻得合适的工具：Encoding Tools Download Tutorial若需急用之，也可直接下载并直接使用附带的工具（不推荐但可以）支持的管道上游程序（解码与滤镜工具）：ffmpegvspipe（支持 API 3.0、4.0 自动识别）avs2yuvavs2pipemodSVFI支持的管道下游程序（编码器）：x264 core 165 或更新x265 v4.2 或更新SVT-AV1 v4.1 或更新使用最新版本的编码器有助于提高性能（速度、画质、压缩率），以及更小的内存泄露概率图标使用Azure icons: azureicons.com单色小图标 by NiewBie: GitHub/NiewbieNuGet 包使用蓝光播放列表解析器 by tautcony: ChapterTool Core验证状态已验证 OSWindows 10 22H2Windows 11 25H2（感谢 Lofu 帮助）已验证 CPUCore i5 7600k（4C4T）Ryzen 9 9900X（2CCD 12C24T）EPYC 7R13（6CCD 48C96T）Intel i7 14700K（感谢 Whithost 帮助）包括 L3 缓存大小与 CCD 分组辨识能力的检测长队列任务圆满完成了 30+ 4K 视频的长队列压制的测试（3 天无人值守）打赏信息开发这些工具并不容易。如果这套工具提高了你的效率，那么不妨赞助或推广一下。——Buy me a coffee 链接——PayPal 链接项目状态已完成应用框架与主界面WPF 应用启动、主窗口和主界面布局已经实现，入口在 App.xaml.cs、MainWindow.xaml、Views/MainUI.xamlMainVM 负责主界面模块编排，包括工具区、源导入区、分析区、检查卡、编码设置区和启动区模态窗口导航、遮罩状态、关闭命令和基础命令模型已经实现多语言切换机制已经接入主要界面、卡片、按钮和模态窗文本工具导入与选择支持导入、替换、删除和选择外部工具已定义并支持的上游工具包括 ffmpeg.exe、vspipe.exe、avs2yuv.exe、avs2pipemod.exe、one_line_shot_args.exe已定义并支持的编码器包括 x264.exe、x265.exe、svtav1encapp.exe已定义并支持的分析和依赖项包括 ffprobe.exe、avisynth.dll工具版本检测、文件名校验、工具分区、默认选择和依赖/来源兼容性刷新已经实现源导入与脚本生成支持导入普通视频源、AviSynth 脚本、VapourSynth 脚本和 SVFI ini 源支持源文件路径持久化，并在启动时回填仍存在的源文件一键生成 AviSynth / VapourSynth 脚本已经实现，会写出 .avs 和 .vpy 文件并回填到脚本源卡片源类型与上游工具之间的选择联动已经实现例如 vspipe.exe 对应 .vpy，avs2yuv.exe / avs2pipemod.exe 对应 .avsffprobe 源分析与源检查ffprobe JSON 分析已经实现，并可复制原始分析结果源检查卡已经解析并展示 progressive、位深、帧率、SAR、色彩元数据、chroma 等检查项源检查问题查看、检查清单状态刷新和手动绕过已经接入主流程编码前置检查编码前置检查卡已经实现硬件和软件检查项已包含 AC 电源、输出目录、磁盘空间、写权限、输出文件覆盖、AviSynth / L-SMASH 相关检查编码前置问题查看、重新评估和手动绕过已经接入启动按钮状态编码参数配置x264 / x265 / SVT-AV1 的 CRF / ABR 基础参数配置已经实现编码预设、关键帧间隔和部分第三方参数开关已经实现并持久化编码设置卡片会显示当前编码参数摘要编码管线会根据当前配置生成对应编码器参数编码命令生成与启动Y4M 管线命令生成已经实现，支持多种上游工具输出到 x264 / x265 / SVT-AV1命令生成会结合 ffprobe 信息生成色彩、range、chroma、lookahead 等参数；帧数只有在原始元数据里本来就可靠时才会使用启动编码前会弹出命令确认窗口，确认后进入编码监控窗口采样片段支持按时间或帧号选择片段，并支持时间与帧号转换采样片段会以 sample 模式打开编码监控流程SVFI / OneLineShotArgs 当前不支持采样片段，主界面已有禁用提示编码监控与进程执行支持启动上游进程和编码器进程，并将上游 stdout 管道传给编码器 stdin支持读取上游程序与下游程序（编码器）stderr、日志折叠、保存日志、查看编码命令和调整日志字号在总帧数可靠时支持编码进度、已写帧数、当前/预计输出大小、耗时、剩余时间和完成时间估算支持内存占用、工作集峰值、Page Fault、内存压力和内存范围条统计支持中断上游或编码器进程，编码完成后才能关闭窗口并行基础能力NUMA 节点枚举、CPU 拓扑读取、CPU Sets 分配和编码器线程数限制已有实现并行设置可以保存并应用到编码监控启动的上游程序与下游程序（编码器）进程编码器线程数会传给 x264 / x265 参数，SVT-AV1 当前没有线程参数生成多开（Run multiple instances）单个 1cenc 实例里，下游编码器线程一次只能绑定到一个 NUMA 节点；如果压制任务数量较多，而机器还有空余 NUMA 节点，可以启动与可用 NUMA 节点数量相同的程序实例，并让每个实例各自处理队列中的一部分任务，从而把所有节点都用满。区分这些实例很简单，只要看标题栏或任务栏里的 PID xxxxx 即可。PID 是进程的临时编号，在运行期间唯一，不同实例不会重复。应用配置与持久化应用配置、工具路径、源路径、编码参数和并行参数的 JSON 保存/加载基础逻辑已经实现语言配置已经接入保存和加载输出文件名工具支持路径预览、剪贴板、非法字符、保留名和长度检查确认后会回填输出设置卡片UI 组件卡片、按钮组、下拉菜单、设置项容器、检查清单、整数滑块、片段范围选择器、内存范围条和列文本组件已有实现当前使用到的单向 UI 转换器已经满足现有绑定需求编码参数配置细节EncoderConfM.CustomParams 会被保存，且已经被 EncodingPipeline 拼入最终编码命令"自定义参数"区域不再是第三方开关汇总，而是直接读写一个自由文本参数实现x264 / x265 / SVT-AV1 的参数覆盖范围仍有限，但已堪用脚本编辑器脚本编辑器窗口、AVS / VPY 编辑区、复制完整脚本和复制输入输出片段"另存为文件"已实现"确认"已实现脚本保存和回填为简化逻辑，实现和一键生成按钮一样会同时保存 AVS 和 VPY 脚本主界面 Best Practices 检查卡BestPracsSelfCheckCardVM 是自查参考卡，不参与编码启动前的阻塞条件无 RunAllChecks()、无 IsBypassed、无 Inspect/Bypass 按钮通过 Subtitle 属性在 UI 上明确标识为仅供参考应用设置 → 文件覆盖文件覆盖设置会在展示压制命令并确认后，如果输出文件已存在，则追加覆盖确认弹窗，并按被覆盖文件大小延迟启用确认按钮队列模式已实现并验证，确认可用合并模式已实现并验证，确认可用脚本编辑器扩展已实现并验证，确认可用重分集模式已实现并验证，确认可用未验证暂无完全没做暂无死胡同P-Core / E-Core 优化由于需要修改上游程序和编码器源码，该功能无法实现UI 中 P-Core / E-Core 相关复选框处于禁用状态这本质上属于 CISC 与 RISC 处理器厂商的职责，不是用户或应用层应该做的事情Large Pages 实现由于需要修改上游程序和编码器源码，该功能无法实现自动生成关键帧 qpfile由于行为过于复杂且耗时，实现失败必须使用比视频编码器自带方法更好的转场检测功能比视频编码器更好的转场检测功能更慢，会大幅增加整体压制耗时最终预期的压缩率和画质提升平均只有（不经过该功能压制结果的）5%主要源码位置Commands/：用户操作命令、模态窗打开关闭、保存加载和编码启动入口Pipeline/：编码命令行构建、帧数和混流FFmpeg/：ffprobe 分析和 FFmpeg 进程/参数辅助ToolManagement/：工具注册、版本检测和兼容性规则ScriptGeneration/：AVS/VPY 脚本模板CPU/ / Hardware/：CPU / NUMA 拓扑、线程集和 OpenCL 检测Persistence/：JSON 保存/加载基类FileManagement/：源路径路由、文件选择器和输出路径辅助Models/：配置模型、工具定义、语言资源、检查清单和数据 DTOViewModels/：主界面、模态窗和卡片状态管理Views/：WPF 窗口和界面 XAMLComponents/：复用 UI 控件Converters/：WPF 绑定转换器测试与工程化当前没有单元测试、集成测试或自动化 UI 测试项目许多方案还未完全支持 .Net 9.0 的项目README 中尚未包含构建、运行、依赖工具准备和典型工作流说明（不过已在用法说明窗口 / AppUsageModal 中提供）确认窗口（ConfirmationModal）出现位置启动编码前的命令确认，以及输出文件覆盖确认：Commands/StartEncCmd.cs采样片段启动前的命令确认：ViewModels/SampleClipVM.cs编码监控里的“查看编码命令”：ViewModels/EncodingMonitorVM.cs脚本生成后的复制/保存结果提示：ViewModels/ScriptScribeVM.cs、Commands/SaveLoad/OneClickScriptGenCmd.cs源分析和检查结果提示：Commands/AnalyzeSrcVideoCmd.cs、Commands/CopyRawAnalysisCmd.cs、Commands/InspectEncProblemsCmd.cs、Commands/InspectSrcProblemsCmd.cs工具导入/文件选择时的二次确认：Commands/ImportToolCmd.cs、FileManagement/SrcFilePicker.cs设置数据存储位置所有持久化配置数据以 JSON 文件 形式存储在 {应用程序基目录}\1cenc\ 下：文件内容appconfig.json应用设置（覆盖保护配置、语言选择）appdata.json工具路径/版本/大小、源视频路径、输出目录encodingconfig.json编码器参数（CRF/ABR、关键帧、预设、x264/x265/SVT-AV1 自定义参数）parallelismconfig.json并行设置（NUMA 节点 ID、CPU 偏好、线程数）持久化基类：Persistence\SaveLoadBase.cs 的配置模型继承自 SaveLoadBase<T>，通过 Save() / Load() 提供 JSON 序列化/反序列化。其他持久化数据（用户选择路径，不在 \1cenc\ 中）：生成的脚本文件（.avs / .vpy / .txt）经由 ViewModels\FilterScribeVM.cs 和 Commands\SaveLoad\OneClickScriptGenCmd.csstderr 日志文件（upstream-stderr.txt、downstream-stderr.txt）保存到输出目录，经由 ViewModels\EncodingMonitorVM.cs免责声明责任限制因使用或无法使用本软件所导致的任何直接、间接、附带、特殊或后果性损害（包括但不限于商业利润损失、业务中断、计算机系统损坏、数据丢失及商誉损害），即使已被告知此类损害的可能性，开发者亦不承担任何责任。使用者应自行承担使用本软件的一切风险。关于硬件损坏的说明视频压制属于长时间持续高负载 CPU 计算任务。在此场景下，包括但不限于以下情况可能对硬件造成损害：散热器安装不当、超频不稳定或电压设置过高，可能导致处理器加速老化、电气短路等硬件故障极端负载可能导致系统无响应、蓝屏死机，进而造成数据损坏或丢失本软件提供的保护措施x265 压力测试预设：提供用于验证系统稳定性的 x265 压力测试预设。但该测试的实际负载取决于输入视频的内容复杂度，建议使用与目标压制任务一致的测试视频作为源文件进行验证。由于该测试的压力可能会高于 Prime95 等传统压力测试工具，因此运行该测试本身就存在一定风险，只建议在全程监控温度和系统状态的前提下运行，并且在开始测试前先做好数据备份。避免进程优先级控制：本软件不会提高编码任务的进程优先级，以确保在编码器无响应时，操作系统及其他程序仍能正常响应。文件覆盖保护：在编码启动前，如果输出文件已存在，会弹出确认窗口并根据被覆盖文件大小延迟启用确认按钮，以避免误操作导致的数据丢失。建议用户采取的保护措施使用可靠的散热设备：普通的散热风扇难以承受长时间全速运行的损耗，建议选用品质可靠的方案。合理配置超频策略：应以长期高负载稳定运行为目标调整 CPU 与内存的超频参数，而非仅追求短时爆发性能。使用不间断电源（UPS）：高负载任务运行时突然断电对硬件极为危险，建议配备 UPS 以争取手动保存并关机的缓冲时间。注意电脑所处环境的湿度：高湿度环境容易造成电气短路，尤其在高负载、长时间运行的情况下更需注意。为什么不做 Linux 支持 / 为什么用 WPF本软件对 Windows 专有 API 依赖较深，这些 API 构成了核心功能的基础，因此天然绑定在 Windows 平台上：WPF 呈现层：WPF 无官方 Linux 支持Windows 内核 API（P/Invoke 调用 kernel32.dll）CPU Sets：将编码进程绑定到指定物理核心，避开超线程虚拟核心NUMA 拓扑：枚举并指定编码器使用的 NUMA 节点，使用户看到的可视化与编码器所见一致进程枚举：编码监控中的子进程追踪电源状态：编码前检查是否使用市电供电内存信息：获取物理内存总量并按 NUMA 节点比例分配估算psapi.dll：编码监控功能的工作集/内存压力统计这些 API 覆盖了并行调度、硬件检测、进程监控、编码前置检查等关键环节，是跨平台 UI 框架无法替代的。既然底层已经锁死在 Windows API 上，选择 WPF 是最自然的结果——它提供了原生 Windows 桌面集成（包括防止打开溢出画面窗口的功能）、成熟的 MVVM 数据绑定生态，且无需引入浏览器内核或第三方依赖。跨平台框架解决的是 UI 层的移植问题，但无法解决底层 API 的兼容，反而会增加一层抽象成本和测试负担。综上所述，最适合其它平台的方案是在该平台上用对应原生技术栈重新实现本项目逻辑。由于已有完整源代码和 Agent 辅助编程工具，同时为了降低门槛，本项目使用了 Apache 2.0 许可条款，因此重新开发的难度已然降低。 #post-content p, #post-content, #post-content ol {font-family: "Roboto","Helvetica","Arial","sans-serif"; font-size:100%} #post-content ul {font-size:100%} img {display: block; margin-left: auto; margin-right: auto;} body {font-family: "Roboto","Helvetica","Arial","sans-serif"; font-size: 100%; background-image: url('https://img4.yesya.net/img/5/2026-06/51-Wallpaper-v3.webp'); background-repeat: no-repeat; background-position: top left; background-attachment: fixed; background-size:cover}
关于“Token”中文翻译方案的评估，总结与理论最优解
本文在制作过程中参考了网络讨论和部分资料，并借助多个大模型工具对各个翻译选项进行检验。部分优缺点评估来源于网络信息；其中“词元”为已有的技术文档用法，其余为候选。本文选取具有代表性的 Token / Tokenizer / Tokenization 翻译方案，在统一约束条件下进行翻译测评。❀ 不推荐翻译成“新智元”❀ 本文为实验性文章，并非转行Token（/ˈtoʊkən/）形容词：标志性的、表示性的、象征性的、名义上的名词：代币、代金券、令牌、标记约束条件为保持一致性，所有量词强制统一使用“个”，以避免省略量词带来的发音通顺性不使用“分词器”的翻译，所有 Tokentizer 的翻译写作 Token 翻译结果的衍生词，从而验证译词的衍生性能一：语料、语料转换器、语料转换/语料化通过借用语言学中的既有术语实现翻译。“语料”指按照一定规则收集的大规模数据集合，且可延伸至图像、视频等非语言数据，适用于多模态模型。“语料化”一定程度具象化了 Tokenization 的技术原理。造句生成这个视频耗费了 10 万个语料，不过语料的价格倒是不贵。大模型通过语料转换器来编解码自然语言。通过语料转换处理，一句话会被拆分成单词和与其对应的标识序号，也就是语料化。评估：失败术语冲突，语义错位“语料”（Corpus）的固有定义是“集合”（复数 / Plural）。这无法指代单个最小单元。造句 1 “生成这个视频耗费了 10 万个语料”将集合概念强行可数化Tokenization 的结果是“元素序列”，而非“语料”DeepSeek：量词影响“个”暴露了迫使“语料”被当作个体名词使用的“惨状”，与其集合属性形成鲜明冲突结论：与既有术语出现严重冲突，不适合作为翻译二：词元、词元转换器、词元转换/词元化该方案是技术文档中较为常见，且在学术界受用的译法。“词元”明确指代 Tokenization 后的切分后的基本单元/标记（如子词、单词或标识符）。造句生成这个视频耗费了 10 万个词元，不过词元的价格倒是不贵。大模型通过词元转换器来编解码自然语言。通过词元转换处理，一句话会被拆分成单词和与其对应的标识序号，也就是词元化。评估：成功准确而自洽造句 1 “生成这个视频耗费了 10 万个词元”——“词元”可以稳定指代 Token 这一离散单位造句 3 “词元化”对应 Tokenization，语义基本匹配可自然扩展出“词元表”“词元嵌入”等术语DeepSeek：量词影响使用“个词元”略显冗余（技术圈习惯省略量词说“10万词元”），但语法正确、逻辑通顺，未造成歧义术语撞词与 Morpheme、Lexeme 撞词，但实际使用可以通过语境区分向后兼容差并不能兼容“代币”等翻译，但问题不大德不配位“词元”的价值过高，可以被理解为“语言的来源”，形同了大模型对语言的统治性地位ChatGPT：语义偏差“词元”的“词”使人联想到“以词为单位”，但 Token 指代的最小单位可以小于词，也可以大于词Token 的分词规则与“元”的含义相悖，容易造成误解结论：效果不俗。该方案在准确性、自洽性、可扩展性方面表现良好若放宽量词限制，通顺度将进一步提升三：吐根、吐根转换器、吐根转换/吐根化尝试结合音译和意译。“吐”指输入输出内容，“根”可被解释为基本单位（Root），效仿了“沙发”“咖啡”等成功音译词的路径。同时，“吐根”在发音上与 Token 足够相似，因此相比其它选项，“吐根”有向后兼容网页应用“令牌”的效果。造句生成这个视频耗费了 10 万个吐根，不过吐根的价格倒是不贵。大模型通过吐根转换器来编解码自然语言。通过吐根转换处理，一句话会被拆分成单词和与其对应的标识序号，也就是吐根化。评估：失败跨领域撞词“吐根”在中文中指代一种药用灌木植物 Ipecac，其根具有催吐作用，其化学成分具有特殊意义——被专门定义为“吐根碱”，且产生了“吐根糖浆”等派生词，被泛用于医药领域与文献。造句 1 “生成这个视频耗费了 10 万个吐根”——“10 万条根茎”、“10 万次催吐”、“10 万服药”，显得离谱且变态DeepSeek：量词影响量词强化了实物感——“一个吐根”听着就像是根茎，放大了歧义对“音译词最终会被接受”的反驳沙发、咖啡等音译词成功进入中文时，所指代的物体在中文中并无现存同名实物“吐根”已有数百年医药史，强行兼容是学术不端的向后兼容差并不能兼容“代币”等翻译ChatGPT：发音诡辩发音实际上差的很远，“音译”的论证站不住脚结论尽管巧妙，但歧义张冠李戴，且无法通过长期使用消除四：语片、语片转换器、语片转换/语片化该方案是对“词元”的重构，为新造词。“语片”可理解为“语言片段”、“语言分片”、“语言切片”，强调 Tokenization 将连续文本切分为离散片段的过程，以及不同分词规则和语境下的不同分词结果（不同食材选择切厚片或切薄片）。简洁易懂且优雅。造句生成这个视频耗费了 10 万个语片，不过语片的价格倒是不贵。大模型通过语片转换器来编解码自然语言。通过语片转换处理，一句话会被拆分成单词和与其对应的标识序号，也就是语片化。评估：成功无撞词风险与“语料”（Corpus）、“语素”（Morpheme）、“语篇”（Discourse）等既有术语均有区分，不会混淆。全新词缺点：用户首次接触需要理解定义优点：“片”字直观，学习成本低于“词元”（“词元”需要区分与“词”的关系）与“令牌”的呼应较弱“令牌”中的“牌”是卡片、凭证，“片”是片段，二者并非直接映射但这不影响，因为“语片”并不需要依附于“令牌”与“代币”的呼应较弱“代币”中的“币”涉及金钱，“片”是片段，二者并非直接映射但这不影响，因为“语片”可以直接作为计费单位衡量跨领域逻辑对称食品：马铃薯 → 薯片；面包 → 面包片视频编码：视频帧 → 分片影业：电影 → 样片DeepSeek：量词影响尽管通顺性也受到挫折，但与量词“个”的兼容性最好，无需省略以增加通顺性“10万个语片”、“一个语片”均自然顺畅衍生词兼容性好相比“词元化”，“语片化”能更清晰地表示切分向后兼容差并不能兼容“代币”等翻译地位合理相比“词元”避免了过高的地位，以人为本结论最优解横向对比DeepSeek 对比评估维度语料吐根词元语片术语冲突逻辑错误（集合≠元素）植物/药物重名与 lexeme/morpheme 重名无已知冲突概念准确性错误一般较高（但预设“词”）高（形象、包容子词）量词“个”通顺度通顺但逻辑错荒谬略显冗余自然形象直观性差差（歧义主导）中优（“分片”易理解）已有使用基础无无有（厂商文档）无扩展性（派生词）语料库（冲突）吐根化（药名撞词）词元化、词元表语片化、语片表、语片流最终评分（满分 10）2168.5ChatGPT 对比评估维度语料吐根词元语片术语冲突集合概念错位医学重名存在重叠无明显冲突概念准确性低低较高较高量词“个”通顺度表面通顺但语义错歧义强略冗余自然形象直观性低低中高使用基础无无有无扩展性差差强强最终评分（满分 10）2178.5 #post-content p, #post-content {font-family: "Roboto","Helvetica","Arial","sans-serif"; font-size:100%} #post-content ol, #post-content ul {font-size:95%} img {display: block; margin-left: auto; margin-right: auto;} body {font-size:100%; background-image: url(https://img4.yesya.net/img/5/2025-08/40_Background.webp); background-repeat: no-repeat; background-position: top left; background-attachment: fixed; background-size:cover}
❀原创教程，转载请注明链接和作者Opus 是由 IETF RFC 6716 指定的音频编解码规范，libopus 是该规范下的编解码器之一。相比早期的一些 AAC 音频编解码器（如 NeroAAC、FDKAAC）有明显质量（压缩率）优势（特别是 AAC-HE 针对的低码率模式），而相比 QAAC 几乎不分上下。考虑到 QAAC 是基于苹果公司的 QtAACEnc 改进而来，而 Opus 是独立第三方，因此 Opus 在商业使用上更加放心，它的下载与安装也比 QAAC 容易一些。Opus 还有个意外的优点，就是尽管音频压制速度本来就很快，但 Opus 的编码速度会比 QAAC 快很多RFC 6716 规范原文：datatracker.ietf.orgRFC 7845 指定了 Opus 音频流的封装格式规范，包括多声道封装。RFC 7845 规范原文：datatracker.ietf.org前情提要：QAAC 音频编码器命令行参数教程 或 GitHub 副本压制教程合集页 V1 或 GitHub 副本压制教程合集页 V2下载与安装直接使用 ffmpeg 的 libopus 即可。下载 ffmpeg注意事项Adobe 系列软件（CC 2026）暂不支持 Opus 音频格式与 AAC 音频流不同，单个 Opus 音频流最高支持双声道多声道音频通过 Opus 编码器的多声道映射族（Channel Mapping Family）实现，支持在多种封装格式（如 Ogg、MKV）里实现多达 255 条声道见 RFC 7845基本用法编码音频编码为 128Kbps，使用 VBR 率控制ffmpeg -i "导入文件夹\音频源.wav" -vn -c:a libopus -b:a 128000 -vbr on -compression_level 10 -frame_duration 100 "导出文件夹\导出音频.ogg"结合视频编码参数源于 x265 急用版压制教程（iavoe.github.io）视频 libx265 + 音频 libopus此处使用了 CMD 换行命令符 ^ffmpeg -i "导入文件夹\视频源.m2ts" ^ -c:v libx265 -x265-params "high-tier=1:tu-intra-depth=4:tu-inter-depth=4:max-tu-size=16:tskip=1:tskip-fast=1:me=umh:subme=3:merange=52:weightb=1:max-merge=5:early-skip=1:ref=3:open-gop=0:min-keyint=5:keyint=287:fades=1:bframes=16:b-adapt=2:bframe-bias=20:b-intra=1:bitrate=34567:crqpoffs=-3:cbqpoffs=-2:ipratio=1.6:pbratio=1.3:cu-lossless=1:psy-rdoq=2.3:rdoq-level=2:hevc-aq=1:aq-strength=0.9:qg-size=8:rd=3:limit-modes=1:limit-refs=1:rskip=1:rc-lookahead=60:rect=1:amp=1:psy-rd=1.5:splitrd-skip=1:rdpenalty=2:deblock=-1,0:limit-sao=1:sao-non-deblock=1" -fps_mode passthrough ^ -c:a libopus -b:a 128000 -vbr on -compression_level 10 -frame_duration 60 ^ "导出文件夹\导出视频.mkv"参数说明ffmpeg 调用的编码器会出现 libavcodec generic（通用）参数与 libxxx 参数混用的情况。以下为 libavcodec generic 的参数会添加 g 标记-ac<g，整数>声道数量，可用于将多声道音频降混到立体声，使 Opus 音频流适应视频封装ffmpeg 导入多音频流时需用 -ac:a:N 按导入顺序指定具体音频流，N 从 0 开始数-ar<g，整数 Hz>采样率，如 -ar 48000 代表 48KHzffmpeg 导入多音频流时需用 -ar:a:N 按导入顺序指定具体音频流，N 从 0 开始数-b:a<g，整数，lib，bit/s> 平均码率（ABR）率控制模式，如 192000 代表 192Kb/s-vbr<字符串选项 off|on|constrained，推荐 on>off：固定码率（CBR）率控制模式on：可变码率（VBR）率控制模式（默认）constrained：受限可变码率（CVBR）率控制模式-compression_level<整数 0~10，默认 10，推荐 10>0：最快，压缩率最低10：最强压缩且最慢-frame_duration<字符串选项 2.5|5|10|20|40|60|100|120，默认 20，推荐 120> 指定音频帧最大时长（毫秒）2.5：最短，编码延迟最低，音质最差20：短，兼容性好，适合古款低功耗设备40：平衡，解码的算力要求低60：长，编码延迟最高，同码率音质好（尤其是低码率），但白噪音会使音高分析的负载/延迟增加（但仍然比 QAAC 快很多），且瞬态信号（如嚓乐器）可能会产生预回声120：最长，编码延迟最高，同码率音质最好，但会进一步放大上述缺点至少这种失真理论上比 MP3 切高频的失真好多了尽管资料显示有预回声问题，或者超过 20 会出现播放卡顿问题，但在测试中均未能复现（可能需要特定版本）音高分析见 RFC 6716 5.2.3.2-packet_loss<整数 0~100，默认 0> 预期丢包百分比，用于劣网通信场景Opus 规范要求对无法正确识别的数据包丢弃，而不解码-fec<开关 0|1，默认 0（关）> 带内前向纠错（Inband FEC），用于劣网通信需 -packet_loss 大于 0 才实际生效；FEC 数据插入频率与 packet_loss 值成正比FEC 仅在 SILK 模式（语音）下有效，CELT 模式（音乐/lowdelay）不支持-application<字符串选项 voip|audio|lowdelay，默认 audio，推荐 audio> 指定编码用例voip：电话，优先保证人声质量audio：通用音频，尽可能与源一致lowdelay：低延迟，禁用人声质量优化的编码功能/模式（仅使用 CELT）-cutoff<g，整数 Hz，默认 0（关），推荐关> 切掉指定频率以上的高频信号，必须为以下固定值之一：4000：窄带（NB）6000：中带（MB）8000：宽带（WB）12000：超宽带（SWB）20000：全带（FB）码率低于 15kbps 时，libopus 会强制使用宽带截止（除非 application=lowdelay）-apply_phase_inv<开关 0|1，默认 1，需 libopus >= 1.2> 联合立体声编码的相位翻转功能0：关，提高单声道下混（声道缩减混音）质量，略微损失立体声音质1：开（默认），提高立体声质量-mapping_family<整数 -1|0|1|255，默认 -1> 多声道映射族（Channel Mapping，多声道用）-1：自动，单/双声道用 Family 0，多声道用 Family 1（启用环绕声掩蔽和 LFE 带宽优化）0：单声道/立体声模式1：多声道/环绕声模式，启用环绕声掩蔽和 LFE 带宽优化255：独立流，不指定声道布局注：联合立体声编码（Joint Stereo）通过下混得到中间声道音轨，再储存各个声道的差异而压缩音频体积的高压缩技术视频封装格式支持封装格式扩展名Opus 支持情况备注Ogg.ogg / .opus✅✅ 原生完整支持推荐音频专用；多声道由 RFC 7845 定义Matroska.mkv / .mka✅ 原生支持推荐视频封装，兼容性最广（Adobe CC 25.2 已支持 MKV）WebM.webm✅ 原生支持（Opus 为官方音频编码之一）Matroska 子集，主要用于网络视频MP4 / ISOBMFF.mp4 / .m4a⚠️ 规范支持，但播放器兼容性参差不齐部分老播放器不支持；需 -strict experimental（旧版 ffmpeg）MPEG-TS.ts⚠️ 有限支持部分实现支持，兼容性较差推荐仅音频专用选 .opus（Ogg 封装），视频选 .mkv，网站串流选 .webm多声道目前仅能使用 Ogg/MKV/WebM已知报错Experimental codec - use -strict experimental to enable在较旧版本的 ffmpeg 中，将 Opus 写入 MP4 容器时会报此错，需在输出参数中添加 -strict experimental：ffmpeg -i input.mp4 -c:a libopus -b:a 128000 -strict experimental output.mp4新版 ffmpeg（大约 4.0 以后）已不再需要此参数。Unsupported channel layout / 多声道输入报错单个 Opus 流仅支持最多 2 声道。多声道输入时若未指定 -mapping_family 1，可能报错或静默降混。解决方案：# 保留多声道（5.1） ffmpeg -i input.mkv -c:a libopus -b:a 256000 -mapping_family 1 output.mkv # 使用 libavcodec 的 ac 命令强制降混为立体声，从而使 Opus 音频以双声道形式嵌入视频封装 ffmpeg -i input.mkv -c:a libopus -b:a 128000 -ac:a:0 2 output.mkv-b:a 不生效 / 码率无法指定注意参数名为 -b:a（音频码率），写成 -b 在多流情况下可能作用于视频流。 #post-content p, #post-content, #post-content ol {font-family: "Roboto","Helvetica","Arial","sans-serif"; font-size:100%} #post-content ul {font-size:100%} img {display: block; margin-left: auto; margin-right: auto;} body {font-family: "Roboto","Helvetica","Arial","sans-serif"; font-size: 100%; background-image: url('https://img4.yesya.net/img/5/2026-03/50-Wallpaper.webp'); background-repeat: no-repeat; background-position: top left; background-attachment: fixed; background-size:cover}
为自动化「编码参数配置」而开发的脚本软件，解决了视频压缩软件需要手动配置编码参数、以及纯命令行操作需要手动输入路径的痛点。本工具会根据视频属性、程序格式、脚本补充、用户需求等规则为前提配置出编码命令（批处理）。此工具几乎消灭了视频压制的学习成本与配置操作的时间成本，快点上手试试吧~环境支持的管道上游程序：ffmpegvspipe（支持 API 3.0、4.0 自动识别）avs2yuvavs2pipemodSVFI支持的管道下游程序：x264x265SVT-AV1只要系统里有一个上游、一个下游程序即可。本工具支持高度本地化的简体、繁體、以及英语文本显示。优点✓ 图形 + 命令行交互界面：在选择文件、路径时调用高 DPI 模式的 Win Form 选窗在基本命令行选项上使用分色编码提示 + 纯选择交互逻辑（prompt）✓ 自动生成无滤镜 VS/AVS 脚本：加速完成脚本构建，或直接启动 vspipe、avs2yuv、avs2pipemod 上游✓ 独立封装命令脚本：导入视频流，音频流，字幕轨，字体✓ 深度定制编码参数：自动计算 + 用户定义实现尽可能符合需求的编码器配置✓ 快速命令行变更：在生成的批处理中，可以直接通过复制粘贴来替换先前导入的管道上游、下游工具；轻松衍生多种处理源与视频格式用法如需确保安全性，则可以通过微软官方的 PSScriptAnalyzer 检测工具来验证：Invoke-ScriptAnalyzer -Path "X:\...\Batch-batch-encoder\bbenc-source" -Settings PSGallery -RecurseWindows 11 下需要确保安装了对应文件名语言的语言包（Windows 10）例如，阿拉伯语文件名：设置 → 时间和语言 →[左栏] 语言 → 添加语言 → 阿拉伯语在设置 → 更新和安全 → 开发者选项中解除 PowerShell 的运行限制，如图：解压下载好的压缩包运行步骤 1 从而完成基本环境检测Windows 10：Windows 11：如果安装了 VSCode，则建议直接安装微软 PowerShell 插件运行VSCode 选择 文件 → 打开文件夹 → 打开脚本根目录（...\bbenc-source\ZH v1.x\）VSCode 需要确认“信任发布者”才能运行脚本运行步骤 2（生成编码管线批处理）、3（ffprobe 读取源）、4（生成编码任务）运行步骤 4 生成的批处理以开始编码若有多种格式的需求，去除备用参数的注释即可运行步骤 5 以封装编码结果脚本步骤 2 示例（仅 CLI 窗口，在 VSCode 中运行效果最佳）腳本步驟 2 示例（僅 CLI 窗口，在 VSCode 中運行效果最佳）下载链接皆同步更新，QQ 群里有很高几率能得到问题答复Github直链,谷歌盘,百度云，提取码 hevc,QQ 群存档: 691892901教程地图、工具下载见：iavoe.github.io缺陷信息用于生成备用管线（pipe 命令行）的导入命令最终都使用单一源文件，这可能是视频、.vpy 或 .avs 文件。因此，根据选择的管道上游程序不同，备用命令行中的上游程序输入/导入参数可能会导入到无效的文件。于是尽管格式正确，切换命令时需要手动编辑批处理。打赏信息开发这些工具并不容易。如果这套工具提高了你的效率，那么不妨赞助或推广一下下下。——Buy me a coffee 链接——PayPal 链接更新信息1.8.7步骤 4：修复了参数组装机制不准确导致 vspipe 输入语句出错的问题为 x264、x265 和 SVT-AV1 实现了自动颜色范围参数赋值为 x264、x265 和 SVT-AV1 实现了自动色度位置参数赋值1.8.5各个步骤脚本均修复了大量 Bug 并优化了代码1.8.0步骤 3-4:从 CSV 格式的视频元数据处理更换为 JSON 格式v1.7.9步骤 2:为程序路径添加了新的配置文件读写功能步骤 3:连接了步骤 2 的配置文件——简化了 ffprobe 导入步骤步骤 4:连接了步骤 2 的配置文件——简化了 avs2yuv 的 AviSynth 版本类型提问步骤v1.7.8步骤 4:为所有编码器新增了多种 CRF 值自定义选项简化了代码步骤 2：修复了批处理部分运行 cmd /k 过早，导致 exit 命令被输入到错误 cmd 进程的问题v1.7.2文件删除操作交互逻辑变更——输入 y 确认，输入 q 取消，Enter 循环的操作逻辑步骤 4 简化了代码，无功能性变更v1.7.1步骤 4:新增了针对 12bit 位深源视频与 SVT-AV1 不兼容的警告简化了 FPS 相关参数赋值的代码段v1.7解决了路径选择窗口没有出现在窗口最上层的问题可能解决了关闭或完成路径选择窗口时，窗口聚焦不自动切换回 CLI 窗口（无法输入）的问题（仍然不支持 VSCode CLI）解决了文件名本身触发 ffprobe 分析 JSON 解析崩溃的错误（临时切换到 UTF-8 文本编码）v1.6.5步骤 4：美化终端输出信息排版限制 ffmpeg log 信息，避免 ffmpeg 进度条与编码器进度条冲突v1.6.4步骤 3 改良了导入系统添加了脚本所在目录下的 ffprobe 模糊匹配功能添加了环境变量的 ffprobe 模糊匹配功能v1.6.3步骤 3 代码优化减少调用 ffprobe 的次数美化终端输出信息排版移除多余 if 分支v1.6.0步骤 2 改良了导入系统添加了脚本所在目录下的 ffmpeg、avs2yuv、avs2pipemod、x264、x265、SvtAv1EncApp 的模糊匹配功能添加了 PATH 路径的 ffmpeg、avs2yuv、avs2pipemod、x264、x265、SvtAv1EncApp 的模糊匹配功能v1.5.0步骤 3 添加了相对可靠的可变帧率（VFR）检测与警告添加了 ffmpeg 处理示例v1.4.7步骤 3 添加了变宽比（SAR）检测与警告添加了写入 SAR 元数据的 ffmpeg 等工具示例修复了步骤 3 运行后在运行目录产生 null 空文件的故障v1.4.6在 1.4.5 基础上进行了代码清理和美化v1.4.5实现了 VOB 格式的元数据读取支持实现了 VOB 与非 VOB 的逐行与隔行扫描识别功能添加了自动指定 avs2pipemod、x264、x265 隔行扫描参数的功能（SVT-AV1 则提示原生不支持）已完成 vspipe 到 x264、x265 测试，等待完成其他测试修复了因管道上游同时选择了 AVS 类工具以及 vspipe 工具时，只能导入 .avs 或 .vpy 触发兼容检测失败（判断为应终止脚本）的逻辑问题（修改脚本源后缀名并检测文件是否存在，提示但无视错误）步骤 3 升级为使用 ffprobe 检测真实封装文件格式的方案，不再用后缀名检测步骤 2 添加了当只有一种工具链可用时自动选择的功能v1.3.9提前了批处理的变量清理（endlocal）时机，避免编码后直接关闭 CMD 窗口产生残留添加了无法实现从 .vs，.avs 脚本读取视频源或者验证视频存在功能原因的说明v1.3.8完成了 SVFI 上游适配：自动从渲染配置 INI 获取 Task ID 和源视频路径（JSON 解析）并构建管道参数，从而跳过视频导入步骤修复了 SVT-AV1 下游参数构建的格式失误添加了导入 one_line_shot_args.exe 与 vspipe.exe 的自动路径检测功能（导入更简单）添加了导入 SVFI INI 文件的自动路径检测功能（导入更简单）添加了繁体中文支持v1.3.7重写了所有代码使用了数组、哈希表等等更合理的数据结构改进了报错逻辑进一步提高了对方括号路径、文件名的支持构建了全局脚本，简化了代码抛弃了大批量模式添加了 SVT-AV1 基础支持全部参数计算功能改写为函数，提高了模块化添加了分色处理的提示文本，统一化了外观改进了 vspipe 支持改进了 SVFI 支持添加了自动 VS、AVS 无滤镜脚本生成功能缓存数据集中导出到单一文件夹通过追加额外的 CSV，避免了步骤 4 脚本的重复导入，避免了 ffprobe 导出 CSV 兼容问题改进了步骤 1 的操作逻辑改进了 Y4M 管道支持完善了封装命令的操作逻辑、流程增加了更多优化操作相关的提示文本强化了文件导入脚本的逻辑行为变更：将 RAW 管道所需参数作为附录（Appendix）一并记录到输出批处理中添加了 SVT-AV1 的 ColorMatrix、Transfer、Primaries 参数生成功能已验证 ffmpeg 兼容性正常已验证 vspipe 兼容性正常已验证 avs2yuv 0.26+0.30 兼容性正常已验证 avs2pipemod 兼容性正常测试步骤 5（封装命令）已完成测试，弃用了所有 Invoke-Expression 来增加安全性 #post-content p, #post-content, #post-content ol {font-family: "Roboto","Helvetica","Arial","sans-serif"; font-size:100%} #post-content ul {font-size:100%} img {display: block; margin-left: auto; margin-right: auto;} body {font-family: "Roboto","Helvetica","Arial","sans-serif"; font-size: 100%; background-image: url('https://yesya.oss-ap-northeast-2.aliyuncs.com/5/2023-01/29_Background.jpg'); background-repeat: no-repeat; background-position: top left; background-attachment: fixed; background-size:cover}
AMD EPYC 7D13 处理器信息整理⚠️ 注意：本文信息皆来源于网络（主要为二手市场及技术社区），可能包含未经官方证实的内容，因此不一定反映实际使用情况。购买与使用前请务必自行核实。概述EPYC 7D13 是一颗用途单一、面向“长期开机、高多核算力、功耗敏感”场景的特殊定制版 SKU。它源自 Facebook/Meta 的 North Dome 刀片平台（Yosemite V2），已知在二手市场存在两个子型号。由于其 PCIe 通道与内存通道被裁减，兼容性和用途受到明显限制，并且可能需要购买或修改 BIOS，或搭配旧处理器更新 AGESA 到至少 1.0.0.A 才能开机，属于一款劣于 EPYC 7D12 的装机选项。规格项目说明核心/线程36C / 72T（6×6 CCD）频率0.7 GHz (base) ~ 3.2 GHz (boost)TDP≈95 W内存DDR4 3200，已知存在 4 通道 / 6 通道的物理变体（见下）PCIePCIE 4.0，存在 27 / 29 条通道的变体——注意这不是标准的完整 128 通道主要规格来源：TechPowerUp，Technical City查找 CPU 微码（Microcode）所需数据：⚠️ 注意：这是 CPU-Z 的数据，与真实 CPU 微码有误差系列（Family）：F型号（Model）：1步进（Stepping）：1扩展系列（Ext. Family）：19（指 19h）扩展型号（Ext. Model）：1 或 01修订（Revision）：无数据，但可能是 B1推测 CPUID 全称（匹配字样）：00A10F11 或 00A00F11来源（CPU-Z 截图）：eBay 店铺/motorpartners含 00A10F11、00A00F11 的 AMD 微码下载：Google Drive/microcode_amd_fam19h.bin来源：winraid.level1techs.com/KedarWolf╔════════════════════════════════════════════╗ ║ MC Extractor v1.103.0 r344 ║ ╚════════════════════════════════════════════╝ microcode_amd_fam19h.bin (1/2) ╔═══════════════════════════════════════════════════════════════╗ ║ AMD ║ ╟───┬──────────┬──────────┬────────────┬────────┬────────┬──────╢ ║ # │ CPUID │ Revision │ Date │ Size │ Offset │ Last ║ ╟───┼──────────┼──────────┼────────────┼────────┼────────┼──────╢ ║ 1 │ 00A10F11 │ 0A10113E │ 2023-06-20 │ 0x15C0 │ 0x94 │ No ║ ╟───┼──────────┼──────────┼────────────┼────────┼────────┼──────╢ ║ 2 │ 00A10F12 │ 0A10123E │ 2023-06-20 │ 0x15C0 │ 0x165C │ No ║ ╟───┼──────────┼──────────┼────────────┼────────┼────────┼──────╢ ║ 3 │ 00AA0F02 │ 0AA00212 │ 2023-06-19 │ 0x15C0 │ 0x2C24 │ No ║ ╟───┼──────────┼──────────┼────────────┼────────┼────────┼──────╢ ║ 4 │ 00A00F11 │ 0A0011D1 │ 2023-07-10 │ 0x15C0 │ 0x41EC │ No ║ ╟───┼──────────┼──────────┼────────────┼────────┼────────┼──────╢ ║ 5 │ 00A00F10 │ 0A001079 │ 2023-06-09 │ 0x15C0 │ 0x57B4 │ No ║ ╟───┼──────────┼──────────┼────────────┼────────┼────────┼──────╢ ║ 6 │ 00A00F12 │ 0A001234 │ 2023-07-10 │ 0x15C0 │ 0x6D7C │ No ║ ╟───┼──────────┼──────────┼────────────┼────────┼────────┼──────╢ ║ 7 │ 00AA0F01 │ 0AA00116 │ 2023-06-19 │ 0x15C0 │ 0x8344 │ Yes ║ ╚═══╧══════════╧══════════╧════════════╧════════╧════════╧══════╝ 已知变体以下是基于卖家描述和社区信息的变体汇总，信息可能存在重复或不准确。OPN 编号产地/外观PCIe 通道内存通道信息来源100-000001005中国产，黄塑料夹PCIe 4.0 x27 (最大 x16+x8)4 通道 DDR4-3200eBay 店铺/Integrity~No.1100-000001005马来西亚产，浅蓝塑料夹N/AN/AN/A100-000000322马来西亚产，灰塑料夹PCIe 4.0 x29 (最大 x16+x8)6 通道 DDR4-3200eBay 店铺/Integrity~No.1, eBay 店铺/Lucky-PLC Store100-000000578N/AN/AN/AN/A0322 尾号的较为常见1005 尾号的较为少见背景出处EPYC 7D13 源于 Meta (Facebook) 为其一体化单节点刀片服务器 North Dome (Yosemite V2) 定制的 EPYC 变体。它是专为 OCP (开放计算项目) 刀片设计的“平台化” SKU，用于高密度单节点服务卡，并非传统零售渠道销售。North Dome 1S 的通道分配连接 Yosemite V2 主板：PCIe x16PCIe 扩展：M.2 2280 SSD：PCIe x4M.2 22110 SSD：PCIe x4网卡：PCIe x4详细设计信息见 www.opencompute.org：North Dome 1S Server Design Specification PDF图片来源：wiwynn.com/sv7100g2主板兼容性支持 EPYC Milan（7003/ZEN3 系列）的主板单节点/单路/1P 插槽款式的主板可能需要修改 BIOS，或搭配旧型号处理器并升级到至少 AGESA 1.0.0.A符合上述条件的型号：永擎（ASRock Rack）：ROMED8 系列超微（Supermicro）：H12SSL 系列技嘉（Gigabyte）：MZ32 系列已有运行证据需特制版 BIOS 或至少 AGESA 1.0.0.AMZ32-AR0 上有两个 PCIe x8 插槽可用MZ32-AR0 需要 REV 3.0 版本（主板中心印刷文本可见）华南（Huananzhi）：H12D-8D有运行报告但无直接证据泰安 (Tyan)：S8030、S8036有运行报告但无直接证据需特制版 BIOS 或至少 AGESA 1.0.0.A性能参考基于社区跑分数据（非官方）：Cinebench R23多核：45324 分CPU-Z单核: 449.6 分多核: 21145.8 分主要限制与风险PCIe 通道严重受限所有标准 SP3 主板都按 EPYC 的 128 条 PCIe 通道进行设计。7D13 仅提供 27 或 29 条（桌面平台级别），不符合 SP3 主板的 PCIe 通道分配。影响：主板上的 M.2、Oculink、额外网卡、SAS 控制器等接口需要逐一实测才能确定哪些可用。丧失了作为高性能 NAS 或 GPU 服务器的功能更便宜的 7002 系列，如 7D12 能提供 128 条 PCIe 通道无法用于双路节点互联（需要大量 PCIe 通道实现）。内存通道缺失标准 EPYC 支持 8 通道内存，而 7D13 为 4 或 6 通道，相当于线程撕裂者的水平线程撕裂者平台的主板 + CPU 选项会更便宜，PCIe 通道数也超过 7D13需自行测试主板上具体哪几条内存插槽无法使用核心架构问题7D13 采用 6 核 CCD，而非完整的 8 核 CCD，跨 CCD 通信的延迟和频率变化高于常规型号平台特殊性作为刀片服务器定制 CPU，在标准主板上的所有功能兼容性均无官方保证修改 BIOS已知可能需要特制的 BIOS，或搭配旧处理器更新 AGESA 到至少 1.0.0.A 才能开机图片来源：TechPowerUp。这其中有 99 或 101 条 PCIe 通道被禁用，理论上至少有一条全长的 x16 通道可用未知限制不确定其他主板板载设备（如网卡、SAS/SATA、USB 等）的具体可用性在有限的 PCIe 通道下，是否还能分出一部分用于接驳足够的存储设备或者与其本来目的一样，只作为“无盘”计算节点使用注：根据某个 eBay 商品页面的“P5916CH0320M00 3.2TB”来看，该卖家使用了直连 PCIe 槽的 SSD 来亮机，这暗示了 SAS、M.2、U.2 等接口不可用的可能已知无限制无厂商锁 (Vendor Lock): 未发现锁定主板的情况驱动与支持需安装最新的 AMD SP3 I/O 驱动程序（可在如超微 H12SSL 系列主板的产品页面下载）价值分析合理价位约为 EPYC 7D12 (32核) 价格的 1~1.5 倍。尽管 7D13 核心更多，但 7D12 拥有完整的 128 条 PCIe 通道，通用性/可玩性大优如果卖家能提供主板 BIOS，并且能提供详尽的主板兼容性说明，则价格可考虑上浮至 1.75 ~ 2.25 倍整机价值对比（分布式计算场景）应低于 4 台 Ryzen 7 7840U 迷你主机 的成本。后者能效比更高，Zen4 架构单核性能更好应低于 2 台 Ryzen 9 5900X + B550 整机 的成本。后者单核性能更强，整体算力接近且更易上手应低于 1 台 Ryzen 9 7950X + B650 整机 的成本。后者单核性能碾压，PCIe 通道数相当，平台更现代、更易上手总结EPYC 7D13 是一款定制 CPU，对于绝大多数 DIY 玩家、HomeLab 玩家，或是小企业通用服务器应用而言，它因大残的 PCIe 而显得性价比极低且上手难度极高，因此不建议普通用户，包括仅有消费级电脑玩机经验的用户尝试。如果你考虑上手，应该首先查清目标主板具体哪些插槽接口不可用，再上手。打赏信息在线丢人，求个打赏，支持一下T_T——Buy me a coffee 链接——PayPal 链接 #post-content p, #post-content, #post-content ol {font-family: "Roboto","Helvetica","Arial","sans-serif"; font-size:100%} #post-content ul {font-size:96%} img {display: block; margin-left: auto; margin-right: auto;} body {background-image: url('https://img4.yesya.net/img/5/2025-11/43-Wallpaper-2.webp'); font-size:100%; background-repeat: no-repeat; background-position: top left; background-attachment: fixed; background-size:cover}
❀本教程是 x264、x265、AV1 等视频压制教程“下载版块”的整合贴。简化了查找相关工具名称、作用、下载和编译流程的步骤。免责声明本教程仅用于学习与研究目的，不构成任何形式的商业使用建议或授权。本教程所提及的软件、脚本及命令行工具均由其各自的开发者和组织独立维护，并受其原始许可证条款约束若用于商业或分发用途，请遵守相关的开源许可（如 GPL、BSD、MIT 等）以及各国/地区的专利法规本文作者不对因使用、转载所述内容造成的任何直接或间接损失承担责任读者应自行评估并承担相应的法律与技术风险某些音视频编解码器（如 H.264、H.265、AAC）在部分地区仍受专利保护。商用项目请咨询相关专利池（如 MPEG LA、Via Licensing）或使用免专利方案（如 AV1、Opus）急用版压制教程x264、x265、libx264、libx265 教程急用版主页首页：NazoRip镜像：GitHubSVT-AV1 与 libsvtav1 教程急用版主页首页：NazoRip镜像：GitHub基本工具工具简介mpv 播放器现代视频播放器，支持深度配置、定制，缺点是界面仅英语，中文支持要看第三方修改版。安装教程ffmpeg滤镜工具与编码器视频压制流程的核心，提供封装、解封装、滤镜、音视频处理与命令行调用接口Voukoder剪辑软件导出插件Premiere/Vegas/AE 开源导出插件。OBS开源直播与录制工具适合录制原素材或采集压制前后对比视频，支持命令行设定编码器，现代窗口和音频捕获方法，但也需要花时间配置。MediaInfo元数据读取工具开源媒体信息查看器。ffprobe视音频读取与分析工具CLI 媒体元数据分析工具。Excel 可视化教程DXVA Checker检测 PC 支持的硬件编解码能力Process Lasso自动优化进程优先级与电源计划工具，保证高占用软件卡死时系统正常响应注：目前没有直播平台明确支持恢复直播会话的能力。因此当大型游戏卡死，系统不响应，只能断电重启时，唯一的选择是创建新直播，然后向旧会​​话发送消息以通知观众跳转（对主播和观众来说都很麻烦）。虽然 Pro Balance 调度并非包治百病，但它在一定程度上保证了系统更容易响应用户操作，也减少了直播中断的一种可能。调用编码器的 GUI 工具工具简介ShanaEncoderffmpeg-CLI 搭配部分 GUI，上手较慢。使用了 ffmpeg 内嵌的 libx264、libx265、NVEnc。Simple x264 Launcher内嵌 AviSynth，支持便携版 VapourSynth，额外支持 x265 和 NVEnc 编码器，适合批量压制。小丸工具箱镜像：百度云 提取码 crhu操作简单、适合入门的中文软件，内嵌 MediaInfo、mp4box、Mkvtoolnix。视频画质跑分工具所有命令行工具的下载与教程见：AV1 视频压制教程总的来说，PSNR、SSIM 不准确，不可信；测量视频画质应该选择 Spearman 单调相关系数（SROCC）和 Pearson 线性相关系数（PLCC）高，并且性能可观的画质跑分工具，如：客观：块大小感知加权峰值信噪比——XPSNR主观+客观：多方法融合——Video multi-method assessment fusion（VMAF）客观：多失真识别多分辨率结构相似性——SSIMULACRA主观+客观：XYB 空间欧几里得距离心理视觉相似性——Butteraugli工具简介FFMetrics测量 PSNR、SSIM、VMAF 的开源 GUI 软件，支持实时图表显示和多版本并行排名。需 .NET Framework 4.8.0 和手动添加 ffmpeg 到程序目录（或添加 ffmpeg 到 %PATH%）XPSNR（ffmpeg 内置）计算“源与压缩结果的差异”，注重暂停画质的深度改进版 PSNR，需要源视频与压缩结果的时间基对齐VMAF（ffmpeg 内置）主观画质指标跑分，倾向于检查视觉观感体验，而非简单地差异（如高压缩下保证大体观感），需要源视频与压缩结果的时间基对齐SSIMULACRA2 VS-HIP使用英伟达和 AMD 显卡计算 SSIMULACRA2.1、Butteraugli 的准确视频画质跑分命令行工具，准确度同样受到显卡快但精度低的影响SSIMULACRA2_rs使用 CPU 多线程计算 SSIMULACRA2.1，比 VS-HIP 的更慢，且需要编译、需要 Python-VapourSynth 环境，优点是精度更高（由于和画质相关，因此得分也更高）虽然 FFMetrics 在导入文件时限制了格式范围，但它直接调用了 ffmpeg，因此可以选择“所有文件”来选中新编码格式的视频流VMAF 可在 Netflix/vmaf 获取最新版模型与运行脚本，但 ffmpeg 内置版本更容易实现多视频批量检测SSIMULACRA2_rs 支持手动指定多线程参数，从而显著提高速度时间基对齐工具总的来说，由于部分视频画质跑分需要统计帧间距离等数据，因此源与压缩视频的时间基（Time base）需要对齐，否则跑分会严重失真（变差）。详见 AV1 教程完整版、 AV1 教程精简版。GitHub：GitHub/GCDLCMCalcualtor、镜像备份：谷歌盘、百度云SSIMULACRA2_rs 下载与编译来源：GitHub/rust-av一. 编译环境下载并安装 rustup：rustup.rs完整安装 VapourSynth必须安装到 C:\Program Files\VapourSynth必须选择“Install for all users”完整安装 Python必须以管理员身份运行必须在自定义安装中选择“Install for all users”VapourSynth 的版本与 Python 版本强绑定，不能随意安装版本检查 C:\Program Files\VapourSynth\sdk\lib64 路径存在，若不存在则上述步骤执行有误，需卸载 Python 和 VapourSynth，仔细阅读并重试二. 下载与编译PowerShell 中运行 cargo install ssimulacra2_rs完成安装，过程中不应该有任何报错将 C:\Users\用户名\.cargo\bin\ssimulacra2_rs.exe 拷贝到工作路径此时可以卸载 rustup下载 LSMAS 解码器：GitHub/AkarinVS随意根据想要的缓存文件路径位置设定选择版本：官方：cachedir=""，命令行窗口当前路径，Windows 默认为 C 盘cwd：cachedir="."，即运行时的命令行路径，即打开 CMD/PowerShell/Bash 时的初始路径tmp：cachedir=%TEMP%，据操作系统设置指定缓存盘，Windows 一般为 C 盘解压并拷贝下载的 LSMASHSource.dll、LSMASHSource.pyd 到 VapourSynth 插件目录下：C:\Program Files\VapourSynth\pluginsssimulacra2_rs 在 PowerShell 中无法正常打印信息，需要使用 CMD 运行LSMAS 缓存文件代表“O__<视频文件名>.lwi” 索引文件，这些文件相当于缓存，但运行完后需要手动删除音频编码器QAAC 依赖 Aple CoreAudio，详见下方教程内容工具简介QAAC高音质 AAC 编码器，见 QAAC 音频压制教程 或 GitHub 副本视频滤镜工具建议直接学习 VCB-S 压制组的教程系列：vcb-s.nmm-hd.org工具简介VapourSynth源视频有时带有画面问题，就靠它修复。安装时应注意不同版本对 Python 环境有强绑定。安装：vapoursynth.comAviSynth+含多线程优化，添加高位深支持的老款视频处理工具 AviSynth。现已被更先进的 VapourSynth 取代，但还有些滤镜仍是独占。avs2yuv相当于 VapourSynth 中的 VSPipe.exe，使导出 AviSynth 到管道（pipe）变得容易。avs2pipemod相当于 VapourSynth 中的 VSPipe.exe，使导出 AviSynth 到管道（pipe）变得容易。视频编码器lavf（LibavFormat）是负责封装/解封装的动态链接库FFMS2（FFmpegSource2）是负责解码的动态链接库，用于给 x264 内置的 AviSynth 提供解码后的源x264来源封装支持特性Patman✅ FFMS2 解码、Lavf 封装8-10bitLigH✅ FFMS2 解码、Lavf 封装8-10bitjspdr (tMod)✅ FFMS2 解码、Lavf 封装8-10bit，MCF 线程管理x264 7mod谷歌盘百度云✅ FFMS2 Lavf 解码与封装8-10bit，hqdn3d 时域降噪Komisar (KMod)✅ FFMS2 解码、Lavf 封装8, 10bit[8-10-12bit] 表示一个可同时支持三种色深的可执行文件； 8[12]bit 表示三种不同可执行文件版本。x265不支持额外的解码与封装/解封装功能并非缺陷。视频编码器不管音频，因此音频流仍需封装x265、AV1、VVC 等较新编码的未封装格式能够提供帧率、分辨率、色彩格式等全局元数据，未封装也可在播放器中预览来源编码器封装音频色深支持特性LigH⛔ .hevc 裸流8-10-12bit附 x86 32bit 版，含 libx265.dlljpsdr⛔ .hevc 裸流8-10-12bitGCC 12.2 + MSVC_llvm 1928，支持 aq-mode 5Rigaya⛔ .hevc 裸流8-10-12bitGCC 9.3，附 32bit 版Patman⛔ .hevc 裸流8-10-12bitGCC 11 + MSVC 1925ShortKatz⛔ .hevc 裸流8-10-12bitarm64~64e 的 Mac 与安卓平台使用DJATOM-aMod⛔ .hevc 裸流10bit, 10-12bitLLVM 的针对 Intel 与 AMD 架构优化版MeteorRain-yuuki✅ Lavf 封装库8, 10, 12bitGCC 9.3 + ICC 1900 + MSVC 1916未使用 y4m 或 lavf 时应手动指定 -D 参数SVT-AV1 下载编码器由两个文件组成：SvtAv1Enc.dll、SvtAv1EncApp.exeClang（LLVM）针对当前 PC CPU 架构编译版本的性能最佳，其次是 GCC，再次为 MSVC（Visual Studio）；性能差异最高可达 10%~50%来源编码器封装音频色深支持已编译特性SVT-AV1⛔ .ivf 微封装8-10bit⛔官方版Gitlab Pipelines⛔ .ivf 微封装8-10bit✅官方 CI/CD 版，属于一种 Beta 测试版，但无需编译。找到最新通过的 Daily Run 计划，选择对应系统版本下载SVT-AV1-Essential by nekotrix⛔ .ivf .webm8-10bit✅改良默认参数预设，增加了新功能（参数），如自动计算瓦片大小，CRF 分区赋值（zones），高精度去块滤镜（dlf 2），固定线程占位等SVT-AV1-Essential by Patman86⛔ .ivf 微封装8-10bit✅改良默认参数预设（以及调整预设 5-2），增加了新功能（参数），如自动计算瓦片大小，CRF 分区赋值（zones），超高精度去块滤镜（dlf 3），色度专用 FGS，固定线程占位等SVT-AV1-HDR by Patman86⛔ .ivf 微封装8-10bit✅改良默认参数预设，增加了 HDR 优化，如针对 PQ 优化的 Variance Boost 曲线，胶片颗粒 Tune，关键帧专用 TF 衰减偏移值，空间噪声分布一致化等SVT-AV1-PSY⛔ .ivf 微封装8-10bit⛔增加了更高画质选项的修改版，目前主要的优化已经合并到了 SVT-AV1 官方版，且已停止开发，版本落后于官方，与官方版一样需要编译Windows 手动编译 SVT-AV1官方指南：Build Guide安装 Visual Studio（2017/2019/2022）并启用 C++ 桌面开发组件安装 CMake：CMake Releases安装 NASM：NASM 官方下载在打开的网盘路径中根据系统和指令集位宽找最新版程序例如，Windows 64bit 选择 最新版/win64/nasm-*-installer-x64.exe安装时可以去勾选 Manual（说明书）和 VS8 Integration（Visual Studio 8 集成）下载 SVT-AV1 源代码 并运行 Build/windows/build.bat编译输出位于 Bin\Debug，确认可执行文件存在后测试：SvtAv1EncApp.exe -v使用 Clang（LLVM）编译 SVT-AV1（推荐）所有命令建议在 CMD 或 (Git) Bash 中执行，不要使用 PowerShell。一. 编译环境LLVM（clang 支持）：LLVM Releases在打开的网盘路径中根据系统和指令集位宽找最新版程序例如，Windows 64bit 操作系统选 LLVM-*-win64.exe安装时选择 Add LLVM to the system PATH for all/current usersMicrosoft C++ Build Tools：Microsoft C++ Build Tools如果已经安装 Visual Studio，且直接下载了 C++ 桌面应用开发组件，则可以跳过这步下载并运行安装程序，选择 Desktop development with C++打开一个记事本，将实际安装位置路径拷贝进去安装页面中，可以仅选择安装 MSVC 和最新的 Windows 10/11 SDKCMake、NASM：与上方教程步骤一致Git（可选）：git-scm.com/download/win编译前确认所有工具正确安装（命令行能正确输出）:: 如果安装时选择其它路径，则修改 "C:\Program Files\LLVM\bin\clang.exe" --version :: clang version *** :: Target: x86_64-pc-windows-msvc :: Thread model: posix :: InstalledDir: C:\Program Files\LLVM\bin where clang-cl :: C:\Program Files\LLVM\bin\clang-cl.exe nasm --v :: NASM version *** compiled on *** *** *** cmake --version :: cmake version *** :: CMake suite maintained and supported by Kitware (kitware.com/cmake)二. 下载项目源代码浏览器下载将 GitLab/AOMediaCodec/SVT-AV1 项目 打包下载 并解压Git 下载若照上面安装了 Git，则打开 Git Bash，并使用下方命令下载：移动到下载路径（不同的命令行工具路径格式和要求不同）cd <下载盘>下载 SVT-AV1git clone https://gitlab.com/AOMediaCodec/SVT-AV1.gitcd svt-av1三. 编译项目完整命令行列表（仅供参考，无法一次执行）chcp 65001 call "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Auxiliary\Build\vcvars64.bat" set "CC=clang-cl" set "CXX=clang-cl" cmake --fresh -B svt_build -G Ninja ^ -DCMAKE_BUILD_TYPE=Release ^ -DBUILD_SHARED_LIBS=OFF ^ -DCMAKE_CXX_FLAGS_RELEASE="-flto /DNDEBUG /clang:-O2 -march=native"切换文本编码到 UTF-8：chcp 65001在先前下载的 VS Build Tools 路径中运行 vcvars64.bat 环境配置脚本（根据实际安装位置调整）：call "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Auxiliary\Build\vcvars64.bat"若已经有了“C++ 桌面应用开发组件”的 64bit Visual Studio，则路径可能是：C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvars64.bat图：x64 Native Tools Command Prompt for VS 20xx运行 vcvars64.bat 后会进入一个新的 CMD 界面，在此指定两个变量以定义使用 Clang-CL 编译器：set "CC=clang-cl" set "CXX=clang-cl"用 CMake 生成 Ninja 项目并配置编译选项（根据压制电脑的 CPU 架构进行调整）：如果当前目录不在 SVT-AV1 或 SVT-AV1-PSY 目录下，则使用 cd 移动过去如果 CPU 支持 AVX-512，且比 ZEN 2 架构新，则推荐 -DENABLE_AVX512=ON:: 换行符取决于终端软件，CMD 使用 `^`，Bash 使用 `\` :: 如果要编译 Debug 版而非发布版，则去掉 `-DCMAKE_BUILD_TYPE=Release` 整行 cmake --fresh -B svt_build -G Ninja ^ -DCMAKE_BUILD_TYPE=Release ^ -DBUILD_SHARED_LIBS=OFF ^ -DENABLE_AVX512=OFF ^ -DSVT_AV1_LTO=OFF ^ -DCMAKE_CXX_FLAGS_RELEASE="-flto /DNDEBUG /clang:-O2 -march=native" ^ -DCMAKE_C_FLAGS_RELEASE="-flto /DNDEBUG /clang:-O2 -march=native"最后使用 Ninja 编译，不用 -DCMAKE_BUILD_TYPE=Release 则会输出到 BinDebug ）：ninja -C svt_build :: *** warnings generated. :: D[242/242] Linking C executable *:\***\SVT-AV1-master\Bin\Release\SvtAv1EncApp.exe编码器官方开源项目基本上有以下用途：下载并检查、修改、编译源码检查变更提交（Commit）的更新信息向开发者反馈编码器问题（Issues）视频编码器项目简介x264 – VideoLANH.264/AVC 编码器，由 VideoLAN 团队维护，广泛用于 FFmpeg、OBS 等。x265 – MulticoreWareH.265/HEVC 编码器的主要开源实现。SVT-AV1 – AOMediaIntel 维护的高性能 AV1 编码器，属于 AOMedia 官方 SVT 系列。libaom – AOMediaAOMedia 官方 AV1 编码器参考实现（质量优先）。rav1e – Xiph / Mozilla用 Rust 编写的 AV1 编码器，专注安全与速度。vpx – WebM / GoogleGoogle 的 VP8/VP9 官方实现。SVT-HEVC – IntelIntel 的高性能 HEVC 编码器（面向服务器/云转码）。SVT-VP9 – IntelIntel 的 VP9 编码器实现。openh264 – CiscoCisco 开源的 H.264 编码器，轻量级且广泛用于实时通信。Theora – Xiph.Org基于 VP3 的开放视频编码标准。FFmpeg – FFmpeg.org虽非单独编码器，但整合了 x264、x265、libaom、SVT 等众多编码器。Daala – Xiph.OrgXiph 的实验性下一代视频编码器（为 AV1 提供技术基础）。VVenC – Fraunhofer HHIFraunhofer HHI 的 VVC (H.266) 开源编码器。VVC Test Model (VTM)JVET 官方 VVC/H.266 参考软件实现。音频编码器项目简介QAAC – nu774基于 Apple CoreAudio 的 AAC 编码器前端（Windows 上需 iTunes DLL）。Opus – Xiph / Mozilla / SkypeIETF 标准化的低延迟音频编码器，适用于语音与音乐。libopusenc – Xiph.Org封装 Opus 编码 API 的简易库，用于录音或实时流。FDK-AAC – Fraunhofer IISFraunhofer 官方开源 AAC 编码器（高质量 LC/HE/HEv2 模式）。LAME – HydrogenAudio著名的开源 MP3 编码器。FLAC – Xiph.Org无损音频压缩格式 FLAC 的官方实现。Vorbis – Xiph.OrgXiph.Org 的有损音频编码器，开源替代 MP3。Musepack (MPC)专注高比特率透明音质的音频编码器。WavPack无损/有损混合音频编码器。ALAC – AppleApple 无损音频编解码器（ALAC）的开源实现。TTA – True Audio无损音频编码格式 TTA 的官方实现。Monkey’s Audio (APE)高压缩率的无损音频编码器。Shorten – SoftSound早期无损音频格式（FLAC 的前身之一）。参考SVT-AV1 CLang LLVM 编译的原教程位于 Discord/AV1 weeb edition/scripts-tools-and-guides，本教程进行了本地化（如修改 set 命令、添加 chcp 命令），以及额外说明（如 Visual Studio 已经安装的 vcvars），额外引导（下载具体版本），以及额外的检查（LLVM、NASM、CMAKE 是否正确安装）等改进。 #post-content p, #post-content, #post-content ol {font-family: "Roboto","Helvetica","Arial","sans-serif"; font-size:100%} #post-content ul {font-size:87%} img {display: block; margin-left: auto; margin-right: auto;} img[src*="#gh-md-img-large"] { width: 80%; max-width: 600px; height: auto; display: block; margin: 12px auto; } body {font-family: "Roboto","Helvetica","Arial","sans-serif"; font-size: 100%; background-image: url('https://img4.yesya.net/img/5/2025-10/42-Wallpaper.webp'); background-repeat: no-repeat; background-position: top left; background-attachment: fixed; background-size:cover}
❀平行于 AV1 教程完整版的部署定位压制教程。适用于已经看过 x264 教程完整版中科普部分（即粗略了解了计算机、数据、视音频格式、显示技术等基础常识）的用户。最好搭配 AV1 教程完整版中对其标准的概述，以及 SVT-AV1 参数和测试数据一起使用（っ╹◡╹)ﾉ下载急用版教程谷歌盘, 国内: 百度云, QQ群存档: 691892901 附录: QAAC音频压缩教程或Github附录: ffprobe视频探针教程或Github完整版教程地图iavoe.github.io更新信息由于部署方案转为 GitHub page 的 HTML-JS-CSS 文档，因此直接观看提交（Commit）记录即可。打赏——Buy me a coffee 链接——PayPal 链接当前版本（年，版，改）：2025.0.94联系方式：Github：iAvoe，QQ 群 #post-content p, #post-content, #post-content ol {font-family: "Roboto","Helvetica","Arial","sans-serif"; font-size:100%} #post-content ul {font-size:87%} img {display: block; margin-left: auto; margin-right: auto;} body {font-family: "Roboto","Helvetica","Arial","sans-serif"; font-size: 100%; background-image: url('https://img4.yesya.net/img/5/2025-09/41_Background.webp'); background-repeat: no-repeat; background-position: top left; background-attachment: fixed; background-size:cover}
❀原创教程，转载请注明链接和作者大型游戏录屏是一种特殊的视频压制用例。其特点有：高实时性编码速度必须跟上 GPU 渲染出新画面的速度如果编码速度跟不上，那么越来越多的帧会被存入缓存，当达到编码器程序可用的内存上限后，就会开始丢帧、丢场景了高帧率大型游戏的视角由鼠标控制，造成了高速的大面积背景位移画面除“微软模拟飞行”以外，一般至少要录制 50~60fps 才相对流畅，而实际上只有 90+fps 才适合高速大面积背景位移画面低 CPU 算力虽然游戏平时不会大量占用 CPU，录屏的视频编码程序也不会；但到了画面复杂的场景就不一定了“大场面”下，CPU 需要计算大量角色与 NPC 和场景的互动，其复杂的动态信息也会让运行在 CPU 的软件编码器占用飙升，造成资源挤兑低显存大多数 GPU 硬件评测不考虑边游玩边录的用例，而新的大型游戏已经开始原生使用光追渲染技术，因此：如果不购买最新的大显存显卡，则不但显卡录屏会越发渺茫，游戏本身也会因为“爆显存”而大量丢帧PCIe 通道少绝大多数中低端主板，尤其是 AMD 平台的主板面临 PCIe 通道不足的问题除了给显卡的 PCIe x16 槽以外，剩下的 PCIe 通道都分给了 NVME M.2 SSD，而不是采集卡或副显卡虽然也有 PCIe x8、x16 长度的槽，但其中的针脚只有 x1 和 x2，这使得采集卡、副显卡会面临输入输出带宽不足的问题低成本绝大多数游戏玩家使用 GTX 1060 6GB、RTX 3060 6GB 显卡，并无“加钱解决问题”的选项随着 NVIDIA 显卡的供电接口质量问题和昂贵价格，大多数玩家将会转向其他平台采集卡并不便宜，且用途单一易分享如果录制有损低压缩、无损压缩或未压缩的视频，就会产生体积大，需要在录制后进一步压缩的视频，而用户不习惯这种操作如果用户还希望剪辑软件兼容（如 Adobe Premiere），那么一开始就需要使用画质更差的旧有损编码格式，或体积更大的旧无损编码格式由于兼容性广泛较差，因此不能使用可变帧率（VBR）录制根据压制三角形定理，在速度无法妥协（实时录屏）的情况下，我们可以选择妥协画质、文件体积，或者升级硬件到一定程度来保证录屏的流畅清晰。为了确立真正适用与自己的资源分配，了解电脑的存储资源和算力资源便是关键。存储资源主要分为带宽和容量两部分，其中带宽决定了每秒可以写入多大的数据，所幸视频是连续大文件写入，几乎不存在随机读写性能需求。存储技术带宽实则数据详见 TomsHardware。PCIe 4.0x4 SSD：约 63Gbps（8GBps）PCIe 3.0x4 SSD：约 31Gbps（4GBps），同时也是 PCIE 4.0x2 SSD 带宽3840x2160x120 未压缩 RGB 3×8bit 视频流 ：约 24Gbps3840x2160x90 未压缩 RGB 3×8bit 视频流 ：约 18Gbps3840x2160x120 普通无损压缩 YUV 8bit 视频流：4:2:0：约 7.2 Gbps4:2:2：约 9.6 Gbps4:4:4：约 14.4 GbpsSATA3 SSD：有效带宽约 4.8Gbps可以看到，只要不用 SATA SSD，4k120 视频流就可以随便写，甚至对于寿命长到用不完的 eMLC SSD 来说，这中负载和磨损就是预期内的工况。当然，24Gbps 的写入量太过夸张，只要 300 多秒就能达到 8000Gb（1TB）。HDMI 接口带宽（对比参考）实际上，带宽问题更多的位于显卡到显示器上。很多用户往往会抱怨现在的 4k144 显示器不支持新版本的 DisplayPort、HDMI 接口，导致显示器成为带宽瓶颈，这是因为视频的数据量本身就非常庞大导致的：HDMI VersionMax ResolutionMax Refresh RateBandwidthHDMI 2.04K @ 60Hz60Hz18.0 GbpsHDMI 2.18K @ 60Hz120Hz (4K)48 GbpsHDMI 2.1a8K @ 60Hz120Hz (4K)48 Gbps注：1MB = 8Mb；1GB = 8Gb。算力资源硬件编码算力占用 CPU（核显，如 QuickSync）与 GPU 附带（如 NVENC/VCN）的运算单元、视频采集/加速卡的 ASIC 芯片优点：同成本下算力更高，延迟更小，能耗极低缺点：压缩算法逻辑固化在电路里无法设置厂商为了平衡功耗、成本和实时性，会牺牲算法实现的复杂度，导致画质和压缩率就目前来说一直劣于软件编码不同厂商，不同代际产品的画质和压缩性能完全不同显存不够软件编码算力能够占用 CPU 核心、GPU NVENC-CUDA/AMF-ROCm/OpenCL 通用计算单元，或高端视频采集/加速卡 FPGA 芯片的编码器优点：算法由软件定义，因此用户可以对画质、体积做出取舍缺点：同成本下算力更低，发热更高，延迟更高GPU 通用计算单元可能会与游戏渲染产生资源挤兑显存不够妥协方案妥协体积妥协体积是唯一能获得高画质录屏的方案，声称录制 4K，但录制码率低于 300Mbps 红线的游戏录屏都是中低画质，这是因为高实时性的限制条件注定了编码器根本没有时间进行合理的码率分配。录制无损压缩视频包括 NVENC-h265-lossless、FFV1 等速度快的编码器，以及编码速度慢的 ProRes、DNxHD（OBS 可以通过插件支持）、x265 格式在 x264 编码器中设置恒定压缩强度 CQP 模式（qp=0）实现无损压缩注意：CQP 模式无法向 CRF 模式一样分配码率到对画质有贡献的地方，因此除了用于无损压缩以外不适合其他用途x264 中需要设置 trellis=2 来避免使用默认画质极差的死区量化器，较新的编码没有这个问题使用古早一些的 FRAPS 软件录屏妥协体积缺点工作流变更：需要在完成录制后离开电脑并进行转码才能缩减视频体积到合适的大小，否则体积过大无法分享，或剪辑软件不支持该格式妥协画质如果希望 SSD 能用的久一些，那么选用有损编码，妥协一点点画质，码率就可以下降到 0.1~0.3Gbps（100~300 Mbps）。但是上面也说了，算力和显存必然会因为游戏和硬件性能受限，因此实际的妥协方法有：降低帧率到 60fps 或更低，从一开始就减少录制的带宽和算力占用，当然，这样做的缺点也自不必说——竞技性的游戏中导致画面损失重要信息。降低分辨率，虽然这样做会损失很多画面信息，但 1280x720~1920x1080 至少还是网络视频与视频剪辑软件都兼容的大小关闭游戏中的胶片颗粒加噪效果关闭视频编码器的码率缓冲区（Video Bitrate Verifier、VBV）心理视觉优化（PSY）、率失真优化（RD）等不适合录屏工况的功能，确保画面流畅（设定编码器到快速预设时关闭）关闭或降低视频编码器中“需要等待上个编码步骤完成才能开始”的压缩功能，如使用 x264 的零延迟（zerolatency）预设，使用低强度动态搜索妥协画质缺点快速预设下，视频编码器不再是进行精确统计后做出决定，而是有些“胡来”的判断码率分配即：码率高，画面糊妥协成本购买采集卡成本中高，用途单一升级 CPU需要多核 Cinebench R23 30000+ 分，这个级别的处理器价格偏高，但好在用途广泛往往意味着需要更换主板购买副显卡成本高，用途比购买采集卡广泛需要注意主板 PCIe 通道布置（注意：不是 PCIe 接口长度，而是接口里的针脚数量）是否支持添加副显卡，至少 PCIe 4.0x4可以在录屏的同时提升帧数，还降低主显卡成本，如主显卡为 AMD RADEON 6000~7000 系、副显卡运行 DLSS/XeSS 插帧并使用 NVENC/QuickSync 录屏升级显卡到最新世代成本最高，但用途不像 CPU 一样广泛对于 1920x1080 游戏录屏，建议显卡显存至少 12GB，建议 16GB对于 3840x2160 游戏录屏，建议显存至少 18GB，建议 24~32GB英伟达显卡，尤其高端显卡只能使用有安全隐患的 12VHPWR 接口妥协成本缺点很遗憾，妥协成本本身对大多数玩家来说是不存在的选项大型游戏的录屏就是这么困难，但即使是这样，我们仍然可以通过压制三角形来找出妥协或优化的方向。降低分辨率、帧率、使用快速预设来保证不卡顿；使用较高码率或无损压缩，同时准备足够的存储空间与存储散热；如果打算升级硬件，则也也有不少成本可控的方案可以考虑。 附录：录屏须知.mp4 封装格式不适合用于录屏，一旦程序出错就会损失整个视频流。可以先录制到 .mkv，录完后再转换封装文件到 .mp4直播和录屏虽然都对编码速度有严格要求，但二者的主要区别就是直播有严格的码率限制，但录屏用例下没有这种限制所以，录屏的视频编码可以相比直播有更高的画质——不使用 CBR、ABR 等码率优先的模式打赏信息在线丢人，求个打赏，支持一下饭费 T_T——Buy me a coffee 链接——PayPal 链接 #post-content p, #post-content {font-family: "Roboto","Helvetica","Arial","sans-serif"; font-size:100%} #post-content ol, #post-content ul {font-size:95%} img {display: block; margin-left: auto; margin-right: auto;} body {font-size:100%; background-image: url(https://img4.yesya.net/img/5/2025-08/40_Background.webp); background-repeat: no-repeat; background-position: top left; background-attachment: fixed; background-size:cover}
使用 Excel 绘制逐帧 VMAF 画质图表的数据可视化教程
VMAF 简介VMAF 是一种结合了主观绝对评价、客观全参考指标、以及客观部分参考指标的多模型体系。基于人眼视觉对于失真的判断与处理特性，并结合了机器学习模型与传统算法的部分参考加全参考指标。相比其它统计画质的算法，VMAF 将原画的清晰度纳入考量（同时使用滤镜预处理原画和压缩结果）。详见 AV1 视频压制教程——画质指标、Netflix tech blog。VMAF 评分VMAF 的分数取值范围为 0~100，主要分为 4k、1080p 和 phone 3 种评分方式。VMAF 4k：播放画质，远距离观看/客厅电视/影院VMAF 1080p：播放画质，中近距离观看/桌面电脑，相比 VMAF 4K 更加苛刻视觉无损：大于等于 95优秀：大于等于 90良好：大于等于 80达标：大于等于 70注：压缩视频时，控制平均 VMAF 在 90~95 之间即可（毕竟是有损压缩）。VMAF 缺点算法原理复杂，分数构成不好说默认先输入压缩源、后输入原画源，与其它画质指标的输入顺序相反，且反直觉评价指标主要取决于提炼出的特征，而非失真图像与源的客观差距——分数变化与客观画质不一定呈正相关机器学习模型的训练数据只能涵盖部分画面内容种类，因此画面内容不够主流的视频不一定可用下载工具ffmpeggyan.devGitHub/btbnffmpeg.org时间基对齐工具下载 GCDLCMCalculator.7z（谷歌盘）（百度云）目录同急用版 x264、x265、AV1 教程下载地址；或（GitHub 项目地址中手动下载）。这是一个计算最大公约数、最小公倍数、以及分数的最大公约数的脚本/包，其中有 PowerShell、Java（.jar）、Python 和 Bash 的选项，选择适合的版本即可。对齐时间基 Timebase若源与压缩结果两个视频流的时间基不对齐，ffmpeg 就会在开始跑分前警告“DTS 未单调增加（DTS is not increasing monotonically）”：[Parsed_xpsnr_0 @ 000001e437db6e80] not matching timebases found between first input: 1/90000 and second input 1001/24000, results may be incorrect!最终画质衡量分数大概率会远低于正常（XPSNR、VMAF 等跑分受影响）：未对齐（画质 -659%）：XPSNR average, 14315 frames y: 33.8192 u: 41.5568 v: 42.3078 (minimum: 33.8192)对齐：XPSNR average, 14315 frames y: 41.9978 u: 44.6105 v: 45.2615 (minimum: 41.9978)对齐方法先运行普通版本：不使用 lavfi 标签——更改文件导入顺序ffmpeg -i ".\压缩源.ivf" -i ".\原画源.mkv" -lavfi ^ libvmaf=log_fmt=xml:log_path="X\\:/导出VMAF数据文件夹/vmaf.xml":model=version=vmaf_4k_v0.6.1\\:name=vmaf_4k|version=vmaf_v0.6.1\\:name=vmaf_1080p" ^ -f null -使用 lavfi 标签:: 使用 lavfi 标签： ffmpeg -i ".\原画源.mkv" -i ".\压缩源.ivf" -lavfi ^ [0:v][src]; [1:v][enc]; [enc][src]libvmaf="model=version=vmaf_4k_v0.6.1\\:name=vmaf_4k|version=vmaf_v0.6.1\\:name=vmaf_1080p" ^ -f null -一旦看到 not matching timebases found between first input: ??? and second input ??? 提醒时按 Ctrl+C 停止跑分，然后使用 GCDLCMCalculator 中的任意脚本/包算出共同时间基。计算共同时间基根据 ffmpeg not matching ... 反馈是否含有小数/分数：如果有就使用 GCDLCMCalculator 的分数的最大公约数（fracGCD）算法否则使用 GCDLCMCalculator 的最小公倍数（lcm）算法PowerShell 脚本（Windows、可能支持 Linux）# 参数名用法（支持乱序参数指定） .\gcdlcm.ps1 -Operation gcd -A 24 -B 1000 .\gcdlcm.ps1 -Operation lcm -A 24 -B 1000 .\gcdlcm.ps1 -Operation fracgcd -Num1 1 -Denom1 90000 -Num2 1001 -Denom2 24000 # 仅参数用法（仅支持顺序参数指定） .\gcdlcm.ps1 -Operation gcd 24 1000 .\gcdlcm.ps1 -Operation lcm 24 1000 .\gcdlcm.ps1 -Operation fracgcd 1 90000 1001 24000 # 显示帮助信息 .\gcdlcm.ps1Java 包（需安装 Java 环境）# 仅参数用法（支持乱序参数指定） java -jar .\GCDLCMCalculator.jar gcd java -jar .\GCDLCMCalculator.jar lcm java -jar .\GCDLCMCalculator.jar fracgcd # 显示帮助信息 java -jar .\GCDLCMCalculator.jarPython 脚本（需安装 Python 环境）# 参数名用法（支持乱序参数指定） python .\gcdlcm.py -o gcd -a 24 -b 1000 python .\gcdlcm.py -o lcm -a 24 -b 1000 python .\gcdlcm.py -o fracgcd -num1 1 -denom1 90000 -num2 1001 -denom2 24000 # 仅参数用法（仅支持顺序参数指定） python .\gcdlcm.py gcd 24 1000 python .\gcdlcm.py lcm 24 1000 python .\gcdlcm.py fracgcd 1 90000 1001 24000 # 显示帮助信息 python .\gcdlcm.pyBash 脚本（Linux、Git Bash、可能支持 Mac OS）# 参数名用法（支持乱序参数指定） ./gcdlcm.sh -o gcd -a 24 -b 1000 ./gcdlcm.sh -o lcm -a 24 -b 1000 ./gcdlcm.sh -o fracgcd -num1 1 -denom1 90000 -num2 1001 -denom2 24000 # 仅参数用法（仅支持顺序参数指定） ./gcdlcm.sh gcd 24 1000 ./gcdlcm.sh lcm 24 1000 ./gcdlcm.sh fracgcd 1 90000 1001 24000 # 显示帮助信息 ./gcdlcm.sh最后运行时间基对齐版本的 VMAF 跑分：set "alignedTbase=输入最小公倍数lcm，如1234、或分数小数的最大公约数fracGCD结果，如1/360000" ffmpeg -i ".\原画源.mkv" -i ".\压缩源.ivf" -lavfi ^ "[0:v]setpts=N*(%alignedTbase%)[src]; ^ [1:v]setpts=N*(%alignedTbase%)[enc]; ^ [src][enc]libvmaf=log_fmt=xml:log_path="X\\:/导出VMAF数据文件夹/vmaf.xml":model=version=vmaf_4k_v0.6.1\\:name=vmaf_4k|version=vmaf_v0.6.1\\:name=vmaf_1080p" ^ -f null -注：此例使用 CMD 批处理实现，因此使用 :: 做注释符，^ 做换行符，可以根据常用的命令行工具修改。示例——大批量 VMAF 跑分命令对于一整季的视频，源视频的时间基不变、压制结果的时间基也不变，因此可以直接预置一些 setpts 变量，然后根据第一个视频运行普通跑分的结果决定所有视频的时间基对其方案。 chcp 65001 :: 配置导入和导出路径 set "sourcePath=X:\源视频文件夹\" set "lossyPath=X:\压缩视频文件夹\" set "outTxtPath=X:\导出ffmpeg进度与报错，以及 VMAF 最终导出目录文件夹\" :: 时间基对齐参数（无需修改，如有必要则添加新项目） set "setptsCmdA=[0:v]setpts=N*(1/24000)[src]; [1:v]setpts=N*(1/24000)[enc]; [enc][src]" set "setptsCmdB=[0:v]setpts=N*(1/6000)[src]; [1:v]setpts=N*(1/6000)[enc]; [enc][src]" set "setptsCmdC=[0:v]setpts=N*(1/360000)[src]; [1:v]setpts=N*(1/360000)[enc]; [enc][src]" :: 导出 VMAF 4k、1080p 分数到 XML，也可使用 CSV（log_fmt=csv:log_path="X\\:/xxx.csv"） :: 使用缓存文件夹是因为为每个视频重写 vmafCmd 变量的出错概率大，因此使用先创建，再重命名和移动的方法更稳定可靠 set "vmafCmd=libvmaf=log_fmt=xml:log_path="X\\:/导出VMAF数据文件夹/vmaf.xml":model=version=vmaf_4k_v0.6.1\\:name=vmaf_4k|version=vmaf_v0.6.1\\:name=vmaf_1080p" :: title VMAF 测试——源视频文件名 :: :: 修改 sourceFile 和 lossyFile，outTxtFile 会直接复制前者的文件名，但替换的后缀名需要与 lossyFile 一致 :: sourceFile 和 lossyFile 只填文件名，路径已在 sourcePath、lossyPath 中定义 set "sourceFile=源视频文件1.mkv" set "lossyFile=压缩视频文件1.ivf" set "outTxtFile=%lossyFile%.txt" ffmpeg -hide_banner -an -i "%sourcePath%%sourceFile%" ^ -i "%lossyPath%%lossyFile%" ^ -lavfi "%setptsCmdB%%vmafCmd%" -f null - > "%outTxtPath%%outTxtFile%" 2>&1 :: 重命名为压缩视频文件名，并移动到导出路径 if exist "X:\vmaf结果缓存文件夹\vmaf.xml" ( ren "X:\vmaf结果缓存文件夹\vmaf.xml" "%lossyFile%.vmaf.xml" move "%lossyFile%.vmaf.xml" "%outTxtPath%" ) :: lossyFile 只填文件名，路径已在 sourcePath、lossyPath 中定义 set "lossyFile=压缩视频文件2.mp4" set "outTxtFile=%lossyFile%.txt" ffmpeg -hide_banner -an -i "%sourcePath%%sourceFile%" ^ -i "%lossyPath%%lossyFile%" ^ -lavfi "%setptsCmdB%%vmafCmd%" -f null - > "%outTxtPath%%outTxtFile%" 2>&1 :: 重命名为压缩视频文件名，并移动到导出路径 if exist "X:\vmaf结果缓存文件夹\vmaf.xml" ( ren "X:\vmaf结果缓存文件夹\vmaf.xml" "%lossyFile%.vmaf.xml" move "%lossyFile%.vmaf.xml" "%outTxtPath%" )注：此例使用 CMD 批处理实现，因此使用 :: 做注释符，^ 做换行符，可以根据常用的命令行工具修改。注：此例使用 Windows 路径，这在 ffmpeg lavfi 中完全由滤镜自己定义路径格式，导致路径写法五花八门，ChatGPT 等大模型非常容易误判，修改时应特别注意。导入 Excel 并处理ffmpeg 导出的 libvmaf XML 大概上长这样：<VMAF version="b9ac69e6"> <params qualityWidth="4096" qualityHeight="2160" /> <fyi fps="4.88" /> <frames> // ..... 省略几十万字 ...... </frames> <pooled_metrics> <metric name="integer_adm2" min="0.985634" max="0.993714" mean="0.988010" harmonic_mean="0.988009" /> <metric name="integer_adm_scale0" min="0.971787" max="0.981927" mean="0.975181" harmonic_mean="0.975179" /> // ..... 省略几百字 ...... <metric name="vmaf_4k" min="97.730270" max="100.000000" mean="99.841975" harmonic_mean="99.841396" /> <metric name="vmaf_1080p" min="93.998455" max="100.000000" mean="99.953442" harmonic_mean="99.952122" /> </pooled_metrics> <aggregate_metrics /> </VMAF>打开 Excel，不用建立新工作簿，直接将 xml 拖入其中选择“作为 xml 表打开”，点确定忽略“指定的 xml 源没有引用架构...”提示，点确定需要用到的列只有 frameNum、vmaf_4k 和 vmaf_1080p，其他列可以删除（通过拖选顶部的字母列，按右键删除）拖选 frameNum、vmaf_4k 和 vmaf_1080p 3 列，选择插入→图表→散点图，选择第一个图即可创建图表填写图表标题（文件名或压制参数）注：此时可以选择一个好看的图表样式选中 Y 轴的数据框，右键→设置坐标轴格式→坐标轴选项，设定最小值：75、最大值：100注：设定最小值是为了防止数据点挤在一起看不清选中 X 轴的数据框，右键→设置坐标轴格式→坐标轴选项，设定最大值：视频最大帧数视频的最大帧数可以通过选中 frameNum 列，按 Ctrl+↓ 查找选中图表中的数据点，右键→设置数据系列格式→填充（油漆桶）→标记→标记选项中，选择使用面积更小、颜色不同的数据点先点击标记选项中的“自动”，再点击“内置”才能全选所有的数据点，否则只会先前选中的一个数据点趋势线选中图表中的数据点，右键→添加趋势线默认会出现线性趋势线，根据需要的分析方法选择需要的趋势线：线性：单纯分析码率增长速度指数：对码率增长敏感时，看指数线曲度是否足够直对数：log，对增长不敏感，但初始变化敏感的分析多项式，阶数6：分析哪部分视频占平均码率更大移动平均，周期10：额外添加一条更平均的码率变化曲线这样就能得到可视化的跑分数据了，那么就这样。打赏信息在线丢人，求个打赏，支持一下饭费 T_T——Buy me a coffee 链接——PayPal 链接 #post-content p, #post-content, #post-content ol {font-family: "Roboto","Helvetica","Arial","sans-serif"; font-size:100%} #post-content ul {font-size:87%} img {display: block; margin-left: auto; margin-right: auto;} body {font-size:100%; background-image: url(https://img4.yesya.net/img/5/2025-08/39_Background.webp); background-repeat: no-repeat; background-position: top left; background-attachment: fixed; background-size:cover}
本教程虽然相对于 x264、x265 教程严谨，并提供了测试数据提高严谨性，但仍仅具备业余参考价值。查阅本文要求读者已经明晰视频编码器的基本原理和一定细节。点此打开往期：x264、x265、QAAC、ffprobe 教程教程架构/内容范围概览——视频编码的流程与 AV1 支持的新格式、新标准编码——AV1 标准下的算法与功能特点文图解析参数——编码器（SVT-AV1）的实现、参数说明、报错列表附录——画质指标说明，编码测试设计、实践、设定规律总结，软件下载，参考文献字体系统本文使用了正文黑体，注解圆体和代码段字体共三套字体集。正文黑体为首选煮豆黑体 Zhudou Sans（中文）附件辅以系统 Sans Serif（英文）注解圆体为 Windows 的幼圆（中英文）附件代码段的字体为传统代码段的 SFMono-Regular，Menlo，Monaco，Consolas（英文） 辅以狮尾圆体 Light（中文）附件公式段的字体为 KaTeX Math Regular（英文）附件（适配安卓）辅以 Cochin，Georgia，Times，Times New Roman，serif繁体中文支持本教程由简体中文编写，可以通过安装浏览器插件来转换繁体及变体。效果不理想则请截图，并发送到本教程 Github 仓库中的 Issues，或 QQ 群里。暗黑模式支持本教程的所有图片在编写时已设为黑色背景。目前已验证 Dark Reader 的显示效果可用。打印机支持打开教程后，在标题栏中可以将当前内容切换到打印排版。并切换回一般排版。转换效果不理想时请截图发送到本教程 Github 仓库中的 Issues，或 QQ 群里。English SupportThis tutorial has been proof-read with TWP webpage translation plugin (Google Translate API), and protects codes, pathes from being translated with HTML code tag. Despite some translation results in very long sentences, overall the sentences makes sense, and can be better with more large context ML translations.English Support: Known issuesThere are cases with the main clause in a sentence being enclosed in HTML code tag (which is ignored by translation plugin), resulting in bad context; In this case, manually copying the text to a translater would fix it:Source: ... 使用与 TM_PRED 类似的原理 ...Incorrect: ... Use with TM_PREDSimilar principles are used ...Correct: ... Uses similar principles as TM_PRED ...There are verb-noun confustions in short words:Source: 应用预测Incorrect: Application PredictionCorrect: Apply prediction参考信息见教程末尾（不是 README/当前页末尾）。后记本教程是继 x264、x265 完整版教程的“续作”，其最明显的区别是配图数量翻倍、大量折叠处理的“概述之外”内容、引用性内容均辅以超链接指向出处、以及不同于以往的测试专用版块。相比 x264、x265 教程，本教程提供了超过 90 张插图，并均匀分布到了 AV1 算法说明的版块中，以帮助读者更好地理解复杂的概念和技术细节。由于信息量庞大，教程难免会有差错遗漏，追溯来源以确认信息可靠的需求就变得呼之欲出了。引用性内容的超链接对后期纠错查证，延伸阅读起到潜在的帮助，是属于“用时恨少”的细节。新增的测试版块提供了对测试方法、涉及算法与软件、视频源的选择、测试命令与结果的内容。这些内容来自于实践，从而可以真正帮助到用户精确地了解参数值强度对编码的影响，而不再是造成思维二值化误解的“有些、较大、一定量”的形容词。“欲穷千里目，更上一层楼”。总的来说，这些条件的达成使得本教程在可靠性、专业性和原创性方面有了显著提升，同时也极大地增强了用户体验。相比于纸上谈兵、空谈一番的 x264、x265 教程的存在价值更高。更新信息由于部署方案转为 GitHub page 的 HTML-JS-CSS 文档，因此直接观看提交（Commit）记录即可。打赏——Buy me a coffee 链接——PayPal 链接当前版本（年，版，改）：2025.11.1联系方式：Github：iAvoe，QQ 群 欢迎提交 pull-request 和 issues 指正 #post-content p, #post-content, #post-content ol {font-family: "Roboto","Helvetica","Arial","sans-serif"; font-size:100%} #post-content ul {font-size:87%} img {display: block; margin-left: auto; margin-right: auto;} body {font-family: "Roboto","Helvetica","Arial","sans-serif"; font-size: 100%; background-image: url('https://img4.yesya.net/img/5/2025-04/38_Background.webp'); background-repeat: no-repeat; background-position: top left; background-attachment: fixed; background-size:cover}