刚把我的服务器从 p2200 升级到 a2000。在 a2000 上用 mcebuddy 内置的 ffmpeg 编码速度是 5.11 倍；换成 v6.0 后，速度超过两倍，达到 11.9 倍。我再次请求更新 mcebuddy 中的 ffmpeg。
@techpro2004，在等待期间，你可以尝试将较新的 FFMPEG 复制到 MCEBuddy 程序文件夹中的“ffmpeg”目录。只需用新版本中的 ffmpeg.exe 和 ffprobe.exe 文件替换即可。
我使用的是来自 Builds - CODEX FFMPEG @ gyan.dev 的 FFMPEG 6.0 的“essentials”版本，适用于 Win10x64。
如果你自己编译，需要包含你的 GPU 库并静态链接所有内容。
我比較喜歡使用官方的 mcebuddy ffmpeg 版本，因為它已經被徹底檢查過了。
Goose，再次請你更新 mcebuddy 中的 ffmpeg 版本，也請讓我們知道你在處理這件事。
謝謝。
鵝，你在嗎？
你好，Goose。
仔細查看 Handbrake 後，他們似乎根本沒用 FFMPEG 來做硬體 AV1 編碼，而是使用 SVT-AV1。
- 新增 SVT-AV1（軟體，v1.4.1）與 Intel QSV AV1（硬體）影像編碼器
所以，要求升級 FFMPEG 可能不是正確的訴求。這或許也能解釋 Goose 稍早說的「這很複雜」。
如果你馬上就需要，你有個解法：直接換上你挑的新版 FFMPEG，甚至可以針對你的平台、作業系統、CPU 與 GPU 自行編譯與最佳化（你還沒提供這些資訊，順帶一提）。
如果你願意等（如你先前所說），就等 Goose 與 MCEBuddy 開發者完成所有平台、作業系統、CPU 與 GPU 組合的測試與回歸測試，這些組合涵蓋所有 MCEBuddy 使用者。
如果你只有個人急用，也可以隨時詢問客製化開發合約的報價，專門為你打造，依照你的規格與雙方同意的時程。
没有紧急需求，只是想确认他们正在处理。
五天前也说过我的服务器用的是什么GPU，而Goose从帖子的第一条就知道我的另一台系统用的是什么。
鵝？？？有任何消息嗎？？？
我們在 Intel 硬體上遇到穩定性問題
我现在在 mcebuddy 的构建版本以及 NVIDIA 硬件的当前版本中都遇到了稳定性问题。问题并非由 ffmpeg 构建引起，请查看我的另一个帖子。我猜测（仅仅是猜测）可能与硬件解码器有关，请尝试调整一下。谢谢。
Goose，這件事有更新嗎？謝謝。
顺便提一句。查看 nVidia A2000 的 GPU 编解码支持列表，它并不支持 AV1 的 GPU 加速。
来源：Video Encode and Decode Support Matrix | NVIDIA Developer
此外，MCEBuddy 在使用 Comskip 时，会调用内嵌在 Comskip 二进制文件中的 FFMPEG；而当 MCEBuddy 使用 Handbrake 进行转码时，Handbrake 又会调用内嵌在 Handbrake CLI 二进制文件中的 FFMPEG。
因此，仅替换一个更新的 FFMPEG 只会影响直接通过 FFMPEG 完成的转码环节。根据你在 MCEBuddy 中的工作流设置，不同阶段可能会调用多个不同版本的 FFMPEG。
我有兩套系統，一台配備 4080 負責編碼，另一台配備 a2000 負責服務。
我不擔心 comskip，只關心編碼。
Goose，你有測試過不使用硬體解碼嗎？謝謝。
我还注意到，虽然我将转码设置为使用 HandBrake，但处理过程中的“快速 Remux”部分使用的是 ffmpeg，并且它没有启用硬件解码。不确定在使用 ffmpeg 或 comskip 时是否有办法为 MCEBuddy 添加自定义命令行选项。虽然可以为 comskip 指定自定义路径，但似乎无法包含仅在较新捐赠版本中可用的命令行选项（没有对应的配置项，必须通过命令行传入 --cuvid）。
我在 MCEBuddy 中将转码配置为使用 HandBrakeCLI，它确实在使用 nVidia 转码为 x.265（使用的是 2060）。
Mike808，mcebuddy 只在 ffmpeg 的編碼步驟使用硬體解碼。感謝你確認 HandBrake 沒有使用 cuvid 且運作正常，接下來或許你可以用各種素材測試 ffmpeg 編碼，來驗證我的推論；我使用 OTA 天線，有時收訊不佳。我覺得 HandBrake 比 ffmpeg 寬容得多，猜測是因為沒有 cuvid。請這樣測試。
Goose，有消息測試「無 cuvid」嗎？
我认为你误解了我的观察结果。
MCEBuddy 处理媒体大致分为 3 个步骤。
第 1 步由 Comskip 完成。MCEBuddy 自带的 Comskip 是捐赠版，但当 Comskip 提到 HWAssist 时，它并不是指 GPU，而是指 Intel CPU 和 AMD APU 中集成的 CPU（核显）原生媒体编解码功能。因此，Comskip 不会使用你的独立显卡，完全受限于 CPU。
最新版 Comskip 确实 带有 GPU 解码选项，但 MCEBuddy 目前并未开放这些功能。我已提交功能请求，希望增加传入 “-cuvid” 或 “-vdpau” 这类命令行参数的开关。再次强调，即使使用自定义的最新捐赠版 Comskip，它目前依旧只能跑在 CPU 上。
第 2 步是解复用，将视频与音频流拆分，并进行 解码。此处 MCEBuddy 似乎调用的是 FFMPEG（无论你是否把 编码/转换 设为 Handbrake）。该版本 FFMPEG 虽有 GPU 编码器，却 没有 GPU 解码器；只有最新版 FFMPEG 才支持，而 MCEBuddy 不会主动启用 GPU 解码 选项，因为它无法预知未来版本的 FFMPEG 是否支持，即便你手动替换二进制文件也是如此。
第 3 步是视频转换，将 Comskip 生成的广告切割文件（EDL）应用到已拆分的音视频流（再次解码），并编码成最终无广告的输出格式。
在第 3 步中，流解码部分似乎仍用 CPU，而合并与转码环节才会用到 GPU。因此第 3 步同时受限于 CPU 和 GPU。Handbrake 使用其内部静态链接的 FFMPEG，不会用 GPU 解码，但会利用 CPU 内置的集成显卡回放与编码功能（若存在），并在 MCEBuddy 启用相关设置时使用 GPU。若你在 MCEBuddy 里改用 FFMPEG 而非 Handbrake，情况相同。
我认为 MCEBuddy 自带的 Handbrake CLI 所集成的 FFMPEG 版本（1.3.3？）并不支持 GPU 解码；而最新版（1.6.1？）即使被你手动替换进去，MCEBuddy 也不会调用那些旧版本不存在的选项。因此，这部分“视频转换”依旧受限于 CPU。
总之，MCEBuddy 何时、能否使用这些子组件的更新版本相当复杂；即便可以，也需要分别在 Comskip、FFMPEG 以及 Handbrake CLI 中单独实现。更何况，Handbrake 的任何选项都完全取决于其内部静态链接的 FFMPEG，与 MCEBuddy 单独调用的独立 FFMPEG 是两回事。
鹅，怎么回事？你试过关闭硬件解码吗？谢谢。
建議你與 Goose 改用私人訊息繼續討論。
當你在論壇上發文時，目的是讓社群一起提供協助。攻擊一位正在嘗試幫忙或釐清主題的人，並不會有任何助益。
好主意，顺便说一句，我并不认为我在攻击。我觉得我已经容忍很久了。
你说过，我引用原话：
“当使用 ffmpeg 进行编码时，mcebuddy 会自动添加用于 GPU 解码的选项。”
我注意到这根本不可能是真的。MCEBuddy 自带的 FFMPEG 版本无法利用 GPU 进行解码，因为该版本根本不具备这一能力。
我自愿花时间研究了你的说法，并公布了我的测试结果——因为我也想要更新的二进制文件（正是本帖的主题）。结果发现，你对 MCEBuddy 行为的理解与软件实际能做什么、不能做什么完全相反。
我还指出了新版软件确实具备你想要的功能，但当前版本既未实现也无法实现。
此外，我还为你、Goose 以及其他 MCEBuddy 开发者指出了可能增加更多 GPU 加速的方向。然而，并非所有 GPU 都相同，专用编解码引擎的数量可能是他们面向最广泛用户群调优时的关键因素。例如，我的 2060 只有 1 条编解码管线，对于“转码”（MCEBuddy 状态显示的“视频转换”）来说，让 TS 解码在 CPU 上完成（借助 CPU 的硬件加速），同时编码在 GPU 上并行进行，这才是合理的；否则就必须串行执行两个纯 GPU 步骤，无法并行提速。
如果 MCEBuddy 的实际工作原理比你想象的更复杂，那我很抱歉。
如果你想要一个仅针对你的硬件和使用场景优化的定制版 MCEBuddy，也许你应该和 MCEBuddy 谈谈，为这项定制开发提供资金。即便如此，如果开源组件（FFMPEG、Handbrake）和专有组件（comskip 的捐赠版）都不支持你要的功能，那也根本无法实现。
也许，MCEBuddy 终究不是适合你需求的工具。