記錄影片縮放流程意味著把從載入來源檔到下載完成 WebM 之間所做的每一個輸入、限制與決策都寫下來，讓同樣的工作流程日後可以重複執行或接受稽核。針對短片的一份完整縮放記錄包含四個部分:來源檔的限制、目標寬度與高度、所選擇的縮放模式，以及編碼後所做的驗證。使用 影片縮放工具 時，這四個部分都在你目前的瀏覽器分頁中完成，因為這個工具會在本機解碼、縮放並錄製 WebM，而不是上傳來源檔。這種本機設計正是讓這些步驟值得記錄的原因，因為日後執行此流程的人將會在自己的機器上得到相同的輸出，而不需要把檔案傳送到伺服器。本指南的其餘部分將說明那份記錄中的每一個部分、實際操作的步驟，以及該寫下哪些內容，讓這套流程在下週換成不同影片時仍然適用。
為何一份記錄下來的縮放流程值得保留
縮放流程就是一份小型 runbook，跟任何 runbook 一樣，只有在捕捉到那些原本藏在某個人腦中的隱性決策時才有用。當你把步驟寫下來，就是把隱性變成顯性:你接受哪種檔案格式、目標尺寸為何、選擇哪個模式，以及你信賴哪種驗證。少了這份記錄，兩個人從同一個來源可能會產出截然不同的 WebM 檔，例如猜測奇怪的尺寸、選錯模式，或跳過大小檢查。文件記錄也能幫助除錯:當輸出看起來有問題時，你可以掃描書面記錄，看看是來源、所要求的尺寸、模式決定，還是驗證步驟出了問題。流程越久沒寫成文件，就會隨著瀏覽器更新以及執行者改變而越偏離原貌。
在操作任何控制項之前要記錄的來源限制
在縮放控制項有用之前，你的流程應該先記錄工具會接受與不會接受什麼，因為答案會決定「縮放」這一步是否真的是對的一步。影片縮放工具接受 MP4、WebM、MOV、M4V 與 Ogg 影片。來源檔最大可達 500 MiB、長度不超過 5 分鐘、單邊不超過 4096 像素、總像素面積不超過 3840 × 2160 像素。一份有完整文件的流程會把這些整理成單一檢查清單的一行，讓讀者知道在進入縮放控制項之前應該先轉檔或裁切來源。若來源在上述任何一項檢查中失敗，記錄中的下一步就應該把檔案交給裁剪、剪裁或壓縮工具，而不是交給縮放工具，因為再多的文件也無法讓工具接受超出其限制的檔案。
選擇縮放模式並寫進流程
任何縮放流程中最大的單一決定就是「適配」與「拉伸」，而流程應該在尺寸旁邊明確標示模式，這樣日後才不用猜。「適配」模式會把你的寬度與高度視為一個外框，套用兩者中較小的縮放比例，保留來源長寬比，且絕不裁切。「拉伸」模式則會獨立使用你所要求的寬度與高度，因此會產出你所輸入的精確像素尺寸，但可能會刻意讓影像失真。這項取捨很簡單，值得記錄下來:當來源比例很重要時，「適配」是安全的預設;而只有在目標尺寸為強制需求、且能接受任何失真時，才適合選擇「拉伸」。
| 執行面向 | 適配模式 | 拉伸模式 |
|---|---|---|
| 你的數字代表什麼 | 一個外框 | 精確的目標尺寸 |
| 來源長寬比 | 保留 | 可能改變，可能失真 |
| 是否裁切畫面 | 否 | 否 |
| 是否讓畫面失真 | 否 | 是，刻意為之 |
| 輸出尺寸 vs 所要求 | 較小或相等 | 只有在兩個輸入皆為偶數時才相等，否則每個奇數值會向下四捨五入為偶數 |
| 最適合情境 | 社群貼文、來源混雜 | 嚴格的像素規格、橫幅 |
如何縮放影片並記錄每一步驟
- 在全新的瀏覽器分頁中開啟影片縮放工具，並選擇一個支援的本機檔案，格式為 MP4、WebM、MOV、M4V 或 Ogg。請等待瀏覽器完成中繼資料載入後再繼續，接著在流程日誌的最上方記錄檔名、位元組大小、時長與來源尺寸。
- 輸入最大寬度與最大高度，兩者皆為介於 2 到 1920 像素之間的整數。工具會將奇數值向下四捨五入到最接近的偶數像素，以維持 WebM 編碼器的可靠性，因此日誌應記錄工具實際接受的值，而不只是鍵入的值。
- 決定此次執行要使用「適配」或「拉伸」，並把這個決定寫在尺寸旁的流程記錄中。如果來源比例必須在框內保持完整，「適配」是預設選擇;當目標尺寸為強制需求，並能接受任何失真時，「拉伸」才是正確選擇。
- 選擇「縮放影片」，並在即時編碼期間保持分頁開啟。瀏覽器會把解碼後的影格繪製到 canvas 上、以最高 30 fps 擷取 canvas，並錄製一支可從來源讀取所有音訊軌的 WebM。流程中應註明處理耗時大約等於影片本身的長度，因為這是真正的重新編碼，而非僅修改中繼資料。
- 透過工具提供的連結下載完成的 WebM，並立即執行驗證檢查:確認檔案可播放、記錄新的位元組大小、註明實際的寬度與高度，並在日誌中並排比較來源與目標尺寸。
- 在流程日誌條目上署名並註明日期。只要一行，例如「2025-03-14:clip-04.mp4，來源 1920x1080，以適配模式放入 1280x720，輸出 1280x720 WebM，已驗證」，就足以讓此次執行日後可被稽核，並成為可重複使用的 runbook 種子。
為何偶數尺寸很重要，以及如何記錄
影片縮放工具會在編碼前將奇數尺寸減少一個像素，這個行為應該寫進流程，而不是當作口耳相傳的傳奇。如果你輸入寬度 1281，工具會以 1280 儲存並編碼;如果你輸入高度 719，編碼器會以 718 執行。原因很直接:常見的瀏覽器影片編碼器對偶數像素尺寸較為可靠，因此工具會向下四捨五入到最接近的偶數，以避免輸出錯位。把這條規則寫進流程，比略過它更有用，因為下一位讀日誌的人會知道當奇數滲入時，「你輸入的值」與「工具儲存的值」可能會差一個像素。
日誌的演算範例:
- 來源:1920 × 1080 橫向影片
- 要求的寬度:1281
- 要求的高度:720
- 步驟 1:1281 為奇數，因此工具將其縮減為 1280。
- 步驟 2:720 為偶數，因此保持 720。
- 最終編碼尺寸:1280 × 720。
把四捨五入的步驟記錄下來，代表下一位讀者不會浪費時間去找那消失的兩個像素。
WebM 下載後要記錄的驗證步驟
沒有驗證步驟的流程只是願望，不是工作流程。WebM 下載後，流程日誌應捕捉四項事實:輸出檔案大小、實際的輸出尺寸(而非所要求的尺寸)、音訊軌數量，以及一行關於播放的備註。這個工具會透過一個經稽核的共用 Matroska duration writer 產生一支有明確時長的 WebM，因此該檔案應能在任何現代播放器中開啟，並在與來源相同的位置結束。若這些檢查中有任何一項失敗，這份有文件記錄的流程現在就把失敗模式與成功案例一併記下，而這正是讓 runbook 值得為下一支影片保留下來的原因。若要交叉檢查你自己瀏覽器中的 canvas 擷取行為，MDN canvas captureStream 參考資料說明了縮放管線所使用的底層串流。
何時應停止記錄此流程，並交棒給其他工具
這份流程涵蓋常見情境:一支需要新像素尺寸與 WebM 輸出的短片、本機編碼。它並不涵蓋影格精準交付、長片、必須輸出 MP4、色彩管理工作流程，或精確的位元率控制。這個工具同樣不會進行細節升頻、移除黑邊、裁切主體、保留字幕或多軌，或繞過 DRM，而流程也不應假裝它有這些能力。若任務需要上述任何一項，文件記錄就應該把工作交棒給一套專用的桌面編碼器，而不是靜默地期待瀏覽器工具能涵蓋。除了上述情況之外，上述步驟已夠簡潔，可以列印、貼進工單，或放在來源資料夾旁作為可重複使用的 runbook。若工作流程開始在多個專案中重複出現，同一份流程可以提升為一份同時涵蓋裁剪、剪裁與壓縮的檢查清單，而影片縮放工具則繼續作為專門處理像素尺寸變更的一個步驟。
若想深入了解，請參閱記錄擷取影片影格的步驟。
若想深入了解，請參閱修正縮放後看起來有誤的影片結果。