我第一次為客戶端轉換螢幕錄影時，我按照每個人的方式做：將 MOV 放入轉換器，等待 11 分鐘，然後發送 MP4。 該文件更小 40%，明顯更柔軟，客戶詢問為什麼演示中的文字看起來模糊不清。 答案是首先不需要轉換。 那個 MOV 裡面的影片已經是 H.264，這正是 MP4 所擁有的。 11 分鐘的重新編碼已經放棄了品質，以產生一個在大約兩秒鐘內可以與位元相同的檔案。 這就是背後的全部想法 視訊轉換器 在 工具。dev，值得了解您使用哪種工具。
TL;DR: 大多數 MOV 檔案已經包含 H.264 視訊和 AAC 音訊，這與 MP4 包含的內容相同，因此在它們之間轉換根本不需要重新編碼。 流被複製到一個新的容器中，這個過程稱為重變體。 它需要幾秒鐘而不是幾分鐘，並且不會丟失任何東西，因為沒有像素被解碼或重新壓縮。 工具 視訊轉換器 預設複製並且僅在格式真正需要時重新編碼，並且它透過編譯為 WebAssembly 編譯到 WebAssembly 的 ffreeg 運行，因此影片永遠不會上傳。
什麼是容器，為什麼重要？
影片檔案有兩層，幾乎所有關於影片轉換的令人困惑的事情都來自將它們混合在一起。
的 箱 是包裝器。 它保存流，記錄它們的長度，每個畫面的起點，音軌的語言是什麼，以及顯示哪種縮圖。 MP4、MOV、WebM、AVI 和 MKV 是容器。 檔案的副檔名命名容器，而不是影片。
的 編碼 是內部的壓縮。 H.264、H.265、VP9 和 AV1 壓縮圖片。 AAC、OPUS、MP3 和 FLAC 壓縮聲音。 編解碼器決定了檔案是否在給定設備上播放，而這需要時間來更改。
一旦你將這兩個想法分開，有用的問題就不再是「這是什麼格式？」變成「我要改變哪一層？」更換容器很便宜。 更改編解碼器既昂貴又有損。 不區分它們的工具會每次都向您收取昂貴的工作費用。
為什麼 MOV 到 MP4 幾乎是即時的？
因為 MOV 和 MP4 是近親。Quicktime& 檔案格式是 MP4 建立在 ISO 基礎媒體檔案格式的基礎，因此兩個容器以幾乎相同的方式組織其資料。 其中的串流通常是相同的串流：iPhone 錄製、Mac 螢幕截圖、DSLR 剪輯和 Premiere Export 都會產生具有 AAC 音訊的 H.264 視訊，無論它們是用 .mov 還是 .mp4 包裹。
所以轉換是 複合: 讀取每個流的開始和結束的地方，將這些位元組寫入一個新的容器，寫一個新的索引。 沒有幀被解碼。 沒有檢查像素。 輸出是不同包裝器中的相同視訊資料，嚴格意義上是無損的，因為解碼的幀是一分位數相同。
在實踐中，這意味著兩分鐘的剪輯在大約一秒鐘或更長的時間內完成，並且檔案大小幾乎不會移動，因為視訊數據沒有改變。 一個在這項工作上需要幾分鐘並交還較小檔案的轉換器已經重新編碼，大小下降是您不再擁有的品質。
這是每條路徑適用的時間。
| 來源 | 目標 | 發生什麼事了 | 速度 | 品質成本 |
|---|---|---|---|---|
| 移動 (H.264/AAC) | mp4 | Remux，流複製的流 | 秒 | 沒有 |
| MP4 (H.264/AAC) | 移動 | Remux，流複製的流 | 秒 | 沒有 |
| 移動或 mp4 | 網路 | 再 - 編碼到 VP9/OPUS | 分鐘 | 有些，取決於設定 |
| 任何影片 | GIF | 再 -encode, palette 減少到 256 種顏色 | 分鐘 | 嚴厲，設計 |
| GIF | mp4 | 再 - 編碼到 H.264 | 幾秒到一分鐘 | 次要，通常是看不見的 |
什麼時候必須重新編碼？
三例，只有三種。
目標容器無法容納編解碼器。 WebM 接受 VP8、VP9 和 AV1 的視訊和 Vorbis 或 Opus 的音訊。 它不接受 H.264。 所以 MP4 到 WebM 總是一個真正的轉換，它需要實時。
源編解碼器不是 H.264 包裝器中的 H.264。 相機的 ProRes MOV，DV 捕捉，舊的 DIVX AVI：那些擁有 MP4 在某些情況下可以攜帶的編解碼器，但大多數玩家會拒絕。 轉換它們意味著解碼和重新壓縮。
你故意改變畫面。 降低解析度，降低位元率，改變幀速率。 沒有重新壓縮它就無法使影片變小，這就是為什麼縮小檔案與更改其格式是不同的工作。 為此，使用 視訊壓縮機，這正是因為壓縮和轉換是人們合理地混淆的不同操作。
為什麼轉換成 GIF 比聽起來更糟？
一個 GIF 最多可容納整個影像的 256 種顏色。 這是格式的定義限制，設定在 GIF89A 規格 1989 年，沒有編碼器可以解決它。 因此，從影片到 GIF 的每個轉換都必須在來源可能包含的 1,670 萬種顏色中選擇哪 256 種。
天真地完成，逐幀，每個框架都選擇自己最好的 256。 結果是同一款襯衫在連續鏡框中顏色略有不同，整個畫面似乎都爬行和閃爍。 這是關於視訊到 GIF 輸出的最常見抱怨，它完全是每幀調色板的產物。
修復是一個兩通道的編碼：首先掃描整個剪輯，建立一個服務於所有內容的調色板，然後對每個框架對共享的調色板進行編碼。 爬行消失，因為顏色停止移動。 Toolz 轉換器可以運行兩個通道，這就是為什麼它比單次工具需要更長的時間，並且看起來更穩定的原因。
第二個驚喜是大小。 GIF 儲存了整個畫面，而不是它們之間的差異，沒有使現代視訊編解碼器高效的運動補償。 作為 MP4 的 400 KB 的 5 秒剪輯通常為 4 MB 作為 GIF。 這導致轉換比人們意識到的更頻繁地做。
我應該將 GIF 轉換為 MP4 嗎？
幾乎總是，是的。 與 H.264 編碼的相同動畫通常是大小的十分之一，在大型 GIF 停滯或節流的行動瀏覽器上播放，並支援硬體解碼，因此不會加熱手機。 正是出於這些原因，每個主要的社交平台都會悄悄地將您上傳的 GIF 轉換為影片，這是一個合理的信號，說明哪種格式適合這項工作。
一個細節決定了轉換是否有效。 H.264 需要偶數像素尺寸，因為如何 標準 組織色度採樣，GIF 經常有奇數：601 像素寬的 GIF 是完全正常的。 編碼員交出奇數維度要么直接失敗，要么通過神秘的信息直接失敗，要么默默地貼上框架。 這裡的轉換器在編碼之前將大小四捨五入到最接近的偶數，這是一個沒有人能看到的單像素作物以及檔案和錯誤之間的區別。
影片會在任何地方上傳嗎？
不，這是改變您可以使用它的方式的部分。 轉換貫穿 ffmpeg 編譯為 webassembly，在您的瀏覽器標籤中執行。 該檔案從您的磁碟讀取到頁面記憶體中，在那裡轉換，然後作為下載傳回。
這有三個實際的後果：
- 沒有任何東西離開你的機器。 開啟 DevTools、切換到網路面板、轉換檔案並觀看：無請求攜帶影片。 對於 NDA 下的鏡頭，未發布的產品演示，任何不同意第三方上傳的人，這就是可用和不使用之間的區別。
- 沒有隊列，也沒有大小上限。 您不會在其他人的工作後面等待，也沒有計劃將您限制為 100 MB。 真正的限制是您的瀏覽器標籤的記憶體，它在普通筆記型電腦上可以舒適地處理數百兆位元組的檔案。
- 第一次運行比其他運行慢。 FFMPEG WebAssembly 套件必須下載一次，即幾秒鐘。 之後它被緩存，然後立即開始轉換。
交易是誠實的：具有專用編碼器的伺服器在非常大的檔案上更快。 對於大多數人轉換的剪輯，上傳和下載的往返時間比編碼節省的時間多。
哪些設定有影響？
對於 Remux，沒有。 沒有什麼可配置的，因為沒有重新決定。
對於重新編碼，兩個。
決議 比任何其他設定都多。 將寬度和高度減半 像素計數，文件大致如下。 從 1080p 到 720p 是最有效的變化，在手機螢幕上很難看到差異。
位元率或品質目標 是另一個。 大多數工具都將其暴露為優質滑桿而不是數字，這是正確的呼叫：固定位元率在簡單的場景上浪費位元並使複雜的場景缺少，而高品質的目標則花費每個場景所需的東西。
幀速率是人們達到的第三個槓桿，通常不應該。 將 30fps 降至 15fps 會使幀減半，但會使運動明顯保持不變，並且它節省的分辨率變化少於分辨率變化，因為無論如何連續幀相互壓縮得很好。
# What a remux looks like at the command line. -c copy is the whole trick:
# copy the streams, do not decode them.
ffmpeg -i input.mov -c copy output.mp4
# Compare to a real conversion, which decodes and re-compresses every frame.
ffmpeg -i input.mov -c:v libx264 -crf 23 -c:a aac output.mp4
第一個命令在讀取檔案所需的時間內結束。 第二個需要的時間與影片複雜一樣長。 任何值得使用的基於瀏覽器的轉換器在內部做出相同的區分，並且 視訊轉換器 做。
當容器變更時，音訊會發生什麼變化？
在 Remux 上，什麼都沒有。 AAC 軌道與視訊一起透過位元組複製，這就是為什麼 MOV 到 MP4 轉換不能降級聲音的原因：相同的壓縮音訊資料最終會出現在新包裝器中。
在重新編碼上，它取決於目標。 WebM 無法攜帶 AAC，因此音訊會重新壓縮到 Opus，這是應用於已經有損音的音訊的有損步驟。 它在語音上很少聽見，偶爾在音樂上聽得出很多高頻細節，例如鈸。
有時音訊是您唯一想要的。 錄製的訪談，該採訪被拍攝，但將作為播客發布，您想要在手機上進行的講座，您正在轉錄的配樂。 轉換整個影片然後丟棄圖片是慢慢的。 那個 抽象器 直接拉出聲音，對於 MP4 和 MOV 來源，它可以將現有的 AAC 軌道複製到 M4A 而無需重新編碼，這與 Remux 完全相同。 如果您擁有的檔案已經是音訊，並且只有格式錯誤，則 音頻轉換器 處理那一邊。
值得了解的一件事：視訊檔案可以攜帶多個音軌，用於不同的語言或單獨的評論。 大多數基於瀏覽器的工具，包括這個，都可以使用第一個軌道。 如果您的來源有多個並且您需要一個特定的，那麼這是具有明確流選擇器的命令列的 FFMPEG 的工作。
您應該發送哪種格式，以及發送給誰？
大多數的轉換工作真的是偽裝成這個問題。 誠實的答案是，H.264 視訊和 AAC 音訊的 MP4 比任何其他組合更頻繁地選擇正確的選擇，因為它是唯一一個基本上無處不在地播放的系統。
| 它要去哪裡？ | 派 | 為什麼 |
|---|---|---|
| 客戶、同事、電子郵件 | MP4 (H.264/AAC) | 玩了這十年來製作的每一部手機、筆記型電腦和瀏覽器 |
| 一個你控制的網站 | MP4，以 WebM 為第二個來源 | WebM 品質相同，MP4 是後備 |
| 社交平台 | mp4 | 他們重新編碼您發送的任何內容，因此請給他們最乾淨的輸入 |
| 編輯時間表 | 原始文件 | 編輯前的每次轉換都會花費品質，您無法返回 |
| 一個有大小上限的聊天應用程式 | mp4，壓縮 | 更改大小，而不是格式 |
| 在電子郵件簽名或自述文件中內聯 | MP4 如果允許，只有在沒有的情況下才 gif | GIF 是拒絕影片的地方的後備，不是選擇 |
最悲傷的一行是編輯一行。 人們在導入鏡頭之前轉換鏡頭，失去品質，然後編輯和導出，失去更多。 如果時間線接受原始，請將其提供原始並最終轉換一次。
另一個常見的錯誤是在您打算壓縮時進行轉換。 「這個檔案對於上傳限制來說太大了」不是格式問題。 將 MOV 變更為 MP4 無濟於事，因為視訊資料相同。 使其變小意味著故意重新編碼，這就是 視訊壓縮機 用於或修剪您不需要的零件 視訊修剪器 首先。 三十秒是三十秒沒有人需要編碼，它勝過任何品質設定。
這與轉換圖像相比如何？
圖像存在相同的容器與編解碼器拆分，但結果相同：有些轉換既便宜又無損，有些則丟棄資訊。 將 PNG 轉換為 BMP 會保留每個像素；將其轉換為 JPEG 不會。 那個 影像格式轉換器指南 覆蓋那一邊，和 影像壓縮指南 比這裡更深入地涵蓋了無損的無損區別。
實際差異是規模。 糟糕的圖像轉換花費您一張照片。 糟糕的影片轉換花費您 11 分鐘，而客戶詢問文字為什麼看起來模糊不清。
常見問題
MOV 還是 MP4 更好？ 就大多數目的而言，它們也不是，因為它們通常包含相同的影片。 MP4 具有更廣泛的設備支援，因此它是更安全的共享預設。 MOV 是 Apple 工具生產的，它包含一些 MP4 沒有的專業編解碼器。
為什麼我的轉換檔案變大了？ 您轉換為效率較低的編解碼器或容器，或 GIF。 remux 永遠不會有意義地改變大小；編碼到舊編解碼器可以輕鬆增長。
為什麼我的 MP4 不在舊設備上播放？ 容器很好；編解碼器不是。 MP4 包裝器中的 H.265 串流不會在僅解碼 H.264 的硬體上播放，儘管擴充功能看起來很熟悉。 這是層次重要的最明顯的情況。
