影片上傳提示「不支援的格式」？先診斷失敗原因

影片上傳出現「不支援的格式」錯誤，不一定是檔案大小問題。先確定失敗發生在哪一步，檢查容器以及實際的影片和音訊流，再按照目標平臺的檔案要求測試一個有代表性的小副本。每次只改變一個因素，成功的嘗試才會提供有用資訊。

不要一開始就反覆壓縮同一個檔案。檔案變小後，仍可能包含不受支援的編解碼器、不相容的音訊流或損壞的媒體。完全有效的檔案，也可能因瀏覽器、賬戶、網路或處理狀態問題而失敗。錯誤提示只是調查起點，不是完整診斷。

以下流程採用構造的上傳案例和擬議的測試矩陣。該示例沒有實際測試服務上傳失敗，也沒有測試成功的 Recapo 對照檔案。

改動檔案前，先記錄失敗情況

記下準確的提示文字、出現提示的階段，以及服務是否建立了任務或儲存了上傳內容。保留原始檔案，併為每個診斷副本使用不同名稱。

應區分三個階段：瀏覽器可能在傳輸前拒絕選擇檔案；傳輸可能在完成前中止；服務也可能接收了資料，卻在媒體處理時失敗。即使錯誤提示措辭相近，這些觀察也指向不同的檢查方向。

不要因為頁面顯示失敗，就推斷不存在任務。如果有支援的歷史記錄或狀態頁面，應先檢查，再重新提交同一個檔案。如果付費操作的狀態不明確，應通過可用的狀態查詢或支援渠道確認，而不是盲目重提。

記錄足以復現問題的背景：目標功能、瀏覽器和作業系統版本、副檔名、大致檔案大小及嘗試時間。支援報告中不要包含密碼、會話令牌、私密連結或不必要的個人素材。

截圖可以保留錯誤措辭，但如有可能，也應複製文字。「沒成功」之類的模糊記錄會丟失拒絕選擇、傳輸停滯和處理失敗之間的區別。

影片檔案有不止一層相容性要求

概念示意圖，並非產品介面截圖。

副檔名不是完整規格。容器負責包裝媒體流和後設資料；編解碼器則描述各媒體流的編碼方式。目標平臺可能接受容器，卻拒絕其中某種內容。

例如，兩個以 .mp4 結尾的檔案，不一定具有相同的影片編解碼器、音訊編解碼器、編碼檔次、畫素格式或流排列。改副檔名不會改變這些內容。

檢查與目標平臺有關的各層資訊：

層級	要記錄的內容	為什麼可能重要
容器	實際格式，而不只是副檔名	決定媒體流和時間資訊的包裝方式
影片	編解碼器、可獲取的編碼檔次、尺寸、畫素格式／位深	解碼器可能只支援某編解碼器允許範圍的一部分
音訊	編解碼器、聲道數／佈局、取樣率、所選音軌	接受影片並不代表接受每種音訊流
時間資訊	時長、起始時間、影格率表現	特定的時間結構可能導致匯入或處理失敗
額外媒體流	字幕、備用音軌、附件、資料	目標平臺可能不預期或不保留它們
檔案完整性	能否讀取完整檔案	看似合理的檔案頭不能證明媒體完整

簡單介面未必顯示每個欄位。記錄可以檢查的內容，並標明缺失資訊。不要根據裝置或副檔名，用假設填補未知值。

依據目標平臺當前的官方要求判斷哪些資訊重要。「使用 MP4」之類的籠統建議，不能替代它實際接受的影片和音訊規格。

用簡短的判斷分支定位失敗

概念示意圖，並非產品介面截圖。

如果剛選擇檔案就被拒絕，應檢查檔案說明的輸入型別、副檔名、檔案大小和時長限制，以及所選功能是否接受這類原始檔。不要假設同一網站其他工具的限制也適用。

如果傳輸開始後中止，應儲存錯誤資訊，檢查連線、瀏覽器狀態，以及服務提供的上傳狀態。格式轉換可能無法解決傳輸故障。

如果上傳完成但處理失敗，應檢查媒體流和本地可讀性。服務可能能夠接收容器，卻無法解碼所選媒體流。

如果檔案處理成功，卻沒有聲音、方向錯誤、軌道缺失或顏色改變，問題就不再只是「上傳失敗」。你需要檢查內容保留和解釋方式。綠色成功提示不代表交付影片合格。

根據這些分支選擇下一項觀察。不要同時清除瀏覽器資料、轉碼檔案、切換網路並建立新賬戶。即使下一次成功，也無法知道哪個因素起了作用。

建立變體前，先在本地檢查原始檔案

在合適的本地播放器或編輯器中開啟完整原始檔案，檢查開頭、中段和結尾。確認預期音訊存在、時長合理，而且檔案沒有意外提前結束。

本地播放成功可以縮小問題範圍，但不能證明與目標平臺相容。本地應用可能支援服務不支援的編解碼器或流組合。反過來，某個播放器播放失敗，也可能反映該播放器的支援範圍，而不是檔案損壞。

如果媒體似乎被截斷，應將其大小和傳輸歷史與目前最可靠的原始檔對照。對於未完整複製的檔案，應儘可能從源頭恢復，而不是反覆轉碼，指望缺失內容重新出現。

必要時使用技術檢查工具識別媒體流，並把報告副本儲存在診斷記錄中。不要假設介面中單個「格式」欄位涵蓋了容器和全部編解碼器。

選擇能回答問題、改動最少的測試

FFmpeg 區分流複製與轉碼。流複製將所選的已編碼媒體流放入輸出，不重新編碼；轉碼則進行解碼和編碼。其流選擇檔案也明確說明，選擇規則決定哪些內容進入輸出。FFmpeg 檔案

這一區別有助於選擇測試。如果媒體流符合目標平臺要求，而容器不符合，相容的重新封裝可能就足夠。如果影片編解碼器不受支援，僅重新包裝並不會產生受支援的編碼。

不要聲稱重新封裝在所有意義上都絕對無損。不重新編碼能夠保留所選的壓縮媒體，但輸出的後設資料、時間戳或包含的媒體流仍可能不同。應檢查實際保留了什麼。

如果必須轉碼，應從最可靠的原始檔出發，選擇適合目標平臺的設定。避免從先前測試輸出繼續生成一串有損副本。每次測試都應有明確目的，並保留原始檔案。

只有在確認所選媒體流可以儲存於 MP4 後，才可參考以下外部命令，進行選擇性重新封裝：

ffmpeg -n -i "sample.mov" -map 0:v:0 -map "0:a:0?" -c copy "sample-remux.mp4"

它選取第一路影片，以及存在時的第一路音訊，不保留所有額外媒體流。禁止覆蓋選項可避免替換已有目標檔案。這不是通用修復方法，也不是 Recapo 介面操作說明。

如果所選編解碼器與容器或目標平臺不相容，應停止並選擇適當的轉換，而不是改副檔名或原樣重複命令。

建立有代表性的小樣，不要掩蓋缺陷

小樣可以降低診斷測試的成本，但建立方式很重要。如果製作小樣時將影片重新編碼為另一種編解碼器，小樣成功並不能證明原始編碼受到支援。

記錄小樣是否保留了原始媒體流特徵，還是有意改變了它們。如果失敗發生在接近結尾的位置，應包含那一段。如果問題依賴某個轉場或特定音軌，應保留該特徵。

只取開頭的小樣可能遺漏後段損壞或異常時間戳。因此，小樣是對假設的測試，不是完整檔案一定能通過的保證。找到候選路線後，交付前還要驗證完整輸出。

對於敏感素材，僅使用診斷所需、已獲授權的最少內容。通用對照檔案可以測試上傳流程是否能執行，但無法復現原始檔的每個屬性。不要僅因測試方便，就把私密影片上傳到無關服務。

例項：小檔案仍然失敗

考慮一個虛構的顧問 Dana。其螢幕錄製大小低於目標平臺宣告的限制，卻在傳輸後收到「不支援的格式」提示。檔名以 .webm 結尾。Dana 以為服務需要更小的檔案，準備再次壓縮。

但 Dana 先記錄失敗階段並檢查檔案。在這個構造的場景中，假設影片為 VP9、音訊為 Opus。這些是虛構案例細節，不是對真實上傳檔案的檢查發現。

接下來應問：目標平臺的檔案要求是否接受這種組合？如果要求其他影片或音訊編解碼器，降低原有媒體流的位元速率並不能回答相容性問題。

Dana 制訂了測試計劃：

測試	有意改變的因素	要記錄的觀察	成功結果可以支援什麼
已獲授權的簡單對照	另一個已知受支援的短檔案	選擇、傳輸和處理是否完成？	流程對該對照檔案有效，不一定對原始檔有效
代表原始檔的小樣	縮短時長，同時記錄屬性	是否出現同樣的失敗？	較小的代表性單元能否復現問題
只改變容器的候選檔案	重新包裝相容的所選媒體流	處理表現是否改變？	容器／封裝可能有關
目標編解碼器候選檔案	按檔案要求編碼影片／音訊	是否處理成功並保留內容？	經測試的編碼路線可能適合該平臺
完整候選輸出	將已接受的路線應用於原始檔案	完整處理與內容檢查	實際交付檔案通過檢查，而不只是小樣通過

該表沒有報告任何已經完成的結果。它展示的是如何解釋未來觀察，而不誇大結論。

如果目標編碼小樣成功，但完整輸出失敗，Dana 不應宣佈問題已解決。應檢查時長、後段損壞、媒體流變化或處理限制等差異。如果連簡單對照也失敗，應先調查上傳流程，再製作更多媒體變體。

明確轉碼器可以合理幫助什麼

Recapo 的 H.264 轉碼器公開介紹了將 HEVC、VP9 等源編碼轉換為 H.264，並提供位元速率和解析度選擇。如果目標平臺接受的規格包含 H.264，這些功能可能有用。

公開說明並未確認所有高階流選擇、音訊編碼、編碼檔次、時間戳、HDR 或瀏覽器上傳診斷控制。如果支援的選項符合要求，可使用它們；如果缺少所需控制，則使用有檔案說明的外部編輯器或轉碼器。

不要把產品的一般相容性定位變成「任何原始檔在任何地方都能用」的承諾。目標平臺仍決定接受什麼，而檔案也可能存在與影片編碼無關的問題。

轉換後應驗證音訊、時長、方向、顏色和必要軌道。僅有 H.264 標籤，不能證明完整交付約定已經滿足。

區分瀏覽器問題與媒體問題

採用清晰對照，而不是堆積猜測。只有在任務範圍允許時，才在另一個受支援的瀏覽器或環境中嘗試同一個已獲授權的對照檔案。記錄版本與結果。

如果一個瀏覽器在傳輸前失敗，而另一個接受同一檔案，線索指向客戶端流程。但這不能證明最終媒體處理一定成功。如果兩者都能上傳，服務卻拒絕處理，更換瀏覽器可能無法解決媒體不相容。

檢查瀏覽器擴充套件、過期會話或本地限制是否可能影響流程，但不要不加區分地關閉保護措施。優先使用改動最少且獲准的環境。不要向支援人員分享會話 Cookie 或身份驗證令牌。

如果目標平臺報告賬戶或配額問題，就按該問題處理。重新編碼同一檔案不能補足缺失的賬戶許可權。同樣，不要僅因瀏覽器標籤頁無響應，就推斷付費任務已經無害地失敗。

避免把不合格結果當作成功

上傳成功卻缺少音訊，不算交付成功。轉換後的小樣看起來正確，卻丟掉字幕，仍可能不符合使用者要求。大幅縮小尺寸後被接受的檔案，也可能不適合預期展示。

選擇測試前先定義驗收標準。對於簡單的口述教程，標準可能包括完整畫面、預期旁白音軌、可讀的介面文字和正確時長。多語言交付可能需要多條音軌或獨立字幕包，而基礎轉換未必保留這些內容。

檢查實際輸出，不只檢查源設定。確認包含哪些媒體流，並播放有代表性的位置。如果重要資訊依賴螢幕文字，應按交付尺寸檢查。

如果某條路線必須刪除必要功能才能成功，應明確說明取捨，而不是隱瞞。下一項決策可能是改變交付格式或工作流程，而不是繼續壓縮。

讓接手者能夠繼續診斷的支援報告

上傳失敗報告
目標功能及預期任務：
準確的錯誤文字：
失敗階段：選擇／傳輸／處理／交付後播放
嘗試時間及不含敏感資訊的任務標識：
已檢查的當前任務狀態：
原始檔案來源：
容器與副檔名：
影片編解碼器／編碼檔次／畫素格式／尺寸：
音訊編解碼器／聲道／取樣率：
時長與檔案大小：
必須保留的額外媒體流：
本地播放發現：
對照／小樣測試，以及每次測試唯一改變的變數：
預期結果：
實際結果：
已脫敏的截圖或媒體報告：
仍未知的內容：

除非確有必要、已獲授權且通過適當渠道傳送，否則不要附上機密源素材。脫敏的媒體報告和最小可復現小樣，可能就足以啟動調查。

關閉問題前，確認完整交付檔案能夠處理、正確播放、保留必要媒體流和時長，並符合實際目標平臺要求。保留已接受的處理路線，供下一份檔案對照檢查，但不要假設未來原始檔都完全相同。

關於依賴某項服務前應提出的更廣泛問題，可參考線上影片工具檢查清單。本文的具體原則是：用最小且有用的實驗診斷失敗層級。

先記錄準確的失敗階段，再檢查實際媒體流。這兩項觀察通常比另一個內容同樣未知、只是更小的檔案，更能讓下一次測試提供有效資訊。