我运气不太好，但不确定是不是字幕的问题。
日志已附上。我完全不够资格下结论，不过我觉得问题可能出在这句：
2018-02-11T21:47:17 MCEBuddy.AppWrapper.FFmpeg → 请使用 -b:a 或 -b:v，-b 存在歧义
详细日志如下：
NFL Football (2002) - 2018-02-04 - Philadelphia Eagles vs. New England Patriots.ts-Profile Test-2018-02-11T18-19-59.9641097-05-00.log.zip (4.3 MB)
有什么想法吗？
谢谢
BrianGGG
與字幕完全無關。
您的錄影視訊串流有缺陷。
2018-02-11T20:52:13 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000021729d1a240] start time for stream 0 is not set in estimate_timings_from_pts
2018-02-11T20:52:13 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000021729d1a240] Could not find codec parameters for stream 0 (Video: h264 ([27][0][0][0] / 0x001B), none): unspecified size
因此 ffmpeg 卡住並失敗。
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → Stream #0:0 → #0:0 (h264 (native) → h264 (libx264))
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → Stream #0:1 → #0:1 (ac3 (native) → aac (libfdk_aac))
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → Press [q] to stop, [?] for help
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → Too many packets buffered for output stream 0:1.
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → [libfdk_aac @ 00000215284102e0] 2 frames left in the queue on closing
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → Conversion failed!
我還注意到您已從編碼器順序中移除了 handbrake，因此它不會嘗試退回 handbrake 進行編碼：
order=ffmpeg,mencoder
請嘗試在 ffmpeg 之後加入 handbrake。
然而根本原因在於錄影裝置故障，產生不符合規格的影片檔案。可能是裝置韌體有問題或驅動程式損壞。
感谢你的关注。自从录制视频以来，我已经对驱动、配置文件等做了大量修改（为了成功实现硬件编码），以至于我不确定是否还能解开这个谜团。
不过没关系，因为在后续录制中我再也没遇到过类似问题……
这里有几个问题：
1）我在原帖中列出的错误（“请使用 -b:a 或 -b:v，-b 存在歧义”）是否有用，还是只是干扰信息？
2）我卸载了 Handbrake，因为这是唯一能确保 FFMPEG 在 NVIDIA 上进行硬件编码的方法。由于我有一张支持 CUDA 的 NVIDIA 卡和一张支持 QuickSync 的 Intel 卡……当前的顺序会导致 Handbrake 使用软件编码。
我想我只能先让 Handbrake 占满 CPU，把这段视频转码完再说……
谢谢
BrianGGG
沒有影響，ffmpeg 有多種輸入樣式，我們使用的是較舊且相容性更高的那一種。
了解了，在下個版本中我們也會修補這個問題，因此如果兩者都支援硬體編碼，就不會重新排序編碼器。
好的，已在今天的 2.4.9 测试版中修复。试试看。
很可能我沒搞懂這個修補檔會做什麼，但我認為這次並未成功。下方有兩份範例記錄。
安裝 2-12 beta 時，我保留了預設的設定檔，心想演算法最終會選擇 FFMPEG，因為理想情況下應該用我的 NVIDIA 進行硬體編碼。
然而事實並非如此，記錄顯示兩個工作都用了 HandBrake……而且沒有硬體加速。
如果我對運作方式的假設有誤，請告訴我。
log.zip (230.2 KB)
謝謝
BrianGGG
此修補程式是為了在有多個編碼器支援硬體編碼時，保留使用者所選的編碼器順序。以你的情況來說，HandBrake 與 FFmpeg 都支援硬體編碼，因此它確保不會重新排列你的偏好設定。
你的設定檔看起來像：
order=handbrake,ffmpeg,mencoder
你要求 MCEBuddy 先使用 HandBrake，然後才是 FFmpeg，而它正是這麼做的。
我想你真正想寫的應該是：
order=ffmpeg,handbrake,mencoder
先使用 FFmpeg（硬體）編碼器，若失敗再退回 HandBrake。
謝謝 Goose。這解決了燃眉之急。我調整了順序，並已確認 FFMPEG 正在我的 NVIDIA 顯示卡上進行硬體編碼（在 2.4.8 版中並非如此）。
這讓我產生幾個問題／建議：
首先……我想我誤解了運作方式。保留順序確實能讓我強制使用 ffmpeg，但更彈性的做法是讓 MCEBuddy 根據設定自行決定採用哪條路徑。
我建議，理想情況下 MCEBuddy 應先嘗試所有硬體編碼途徑，再退到軟體編碼。2.4.8 版的原始問題是 MCEB 先嘗試 Handbrake 硬體編碼，失敗後退回 Handbrake 軟體編碼，這對我的設定來說並不理想。
或許是個遙不可及的願景，但最理想的情況應該是：先嘗試 Handbrake 硬體，失敗後改試 ffmpeg 硬體；若再失敗，再重新掃描清單改用軟體編碼。
另外，我能否針對目前的 Profile.conf 提出功能請求？每次安裝新版或測試版時，我都得把每個使用 Handbrake 的設定檔順序改一遍，這並不理想。
一個可能的替代方案是引入「使用者設定檔檔案」的概念，放在使用者目錄（而非程式目錄）中。升級時該檔案可保持不變，並具備兩項用途：
可建立並維護自訂使用者設定檔，這些設定檔會與系統設定檔一起顯示在選單中。
可覆寫現有設定檔中的值。如此一來，諸如 ffmpeg 參數等可變項目可在新版發布時自動更新，同時保留使用者偏好（如轉檔器順序）。
只是一些想法，我佔了完全不懂複雜度的便宜。
此致
BrianGGG
是的，这已经在我们的待办清单上了，这个功能稍微复杂一些，所以需要一些时间来完成。
已经有了 → 系统设置
感謝您的回覆。
很高興知道「硬體優先」排序已經在開發藍圖上。
關於上述的自訂設定檔討論，我會提交一項功能請求，因為我認為使用者設定檔應該是「取代」檔案，而非「附加」檔案。我的建議是，如果你在標準設定檔中有 10 個設定檔，而在使用者設定檔中有兩個，那麼 MCEbuddy 應該顯示全部 12 個，而不只是使用者設定檔中的兩個。我認為這樣會更有價值且更具彈性……
謝謝
BrianGGG
请开一个功能请求，这个之所以棘手，只有一个原因：有时用户不会重命名配置文件，于是你就有了两个配置文件，一个来自主配置，一个来自自定义配置，我们得决定哪一个优先。
我會另外開一個請求。我對重複問題的做法是，在使用者檔案中的任何項目前面加上「USER_」。這樣一來，官方 Profile 檔案中的「MP4 Normal」就會與使用者檔案中的「USER MP4 Normal」區分開來。