當你調整影片大小時，奇數尺寸會被減少一個像素，因為最常見的瀏覽器型影片編碼器——包括為分頁內工具(如 影片尺寸調整工具)提供動力的 VP8 和 VP9 WebM 編解碼器——只有在寬度和高度都是偶數像素時才能可靠地編碼。當編碼器接收到奇數尺寸時，可能會悄悄地將其四捨五入，或拋出「height not divisible by 2」或「width not divisible by 2」的錯誤，或產生某些播放器拒絕開啟的檔案。為了避免下載到損壞的檔案，調整工具會自行執行四捨五入:像 1281 這樣的奇數值會變成 1280，而像 719 這樣的奇數值會變成 718。你仍然會得到你輸入的尺寸，只是向下取整到最接近的、對編解碼器安全的偶數。這是許多影片工具的標準安全機制，並非你的瀏覽器獨有的怪癖，這也是當你要求 FFmpeg 將片段縮放至奇數解析度時，它會標記「width not divisible by 2」錯誤的相同原因。
如果你曾經看過 1281 乘 720 的請求卻回傳為 1280 乘 720，你就碰到了管理所有常見影片編解碼器家族的對齊規則——H.264、H.265、VP8、VP9 和 AV1 都預期尺寸可被 2 整除，許多更期望是 4 或 8 的倍數，以獲得最乾淨的宏塊佈局。無論你使用的是桌面命令列工具、手機應用程式，或是瀏覽器型調整工具，行為都相同;差別在於工具是否會告訴你四捨五入的動作，還是在背後悄悄進行。
為什麼瀏覽器編碼器要求偶數像素尺寸
影片編解碼器會將每個畫面分割成矩形區塊——H.264 通常為 16 乘 16 像素，VP8 和 VP9 也使用類似的宏塊大小網格——以便每個區塊都能獨立預測、轉換和儲存。當畫面寬度或高度為奇數時，最後一列或一行的像素無法填滿一個完整的區塊。較舊的編碼器會直接拒絕奇數尺寸，而現代的編碼器仍然難以有效編碼部分區塊，並可能在畫面邊緣產生可見的瑕疵，或在擷取時無聲地失敗。
為了避免這些故障模式，瀏覽器錄製管線採用 canvas → captureStream → MediaRecorder 鏈，這在 MDN 上有針對 HTMLCanvasElement.captureStream 和 MediaRecorder 的文件說明。MediaRecorder 步驟會選擇支援的 VP9 或 VP8 WebM 設定，而底層編解碼器會向 canvas 要求偶數大小的畫面。在 canvas 移交給錄製器之前，調整工具會將奇數的 canvas 尺寸向下取整，因此編碼器永遠不會看到無法安全處理的數字。
這也是為什麼輸出永遠是 WebM 檔案而非 MP4:瀏覽器原生支援 VP8 和 VP9，而 H.264 和 H.265 需要大型外部相依套件或伺服器。偶數尺寸規則同樣適用於所有這些編解碼器——並非 WebM 專屬——但在僅限瀏覽器的工具中，執行此規則的是 WebM 編碼器。
1281 乘 720 調整尺寸會發生什麼，逐步說明
一旦了解規則，四捨五入就一目了然，你可以在點擊調整之前用腦袋驗證。以要求的尺寸 1281 乘 720 為例:
- 寬度:1281 是奇數，所以調整工具會套用 floor(1281 / 2) × 2 = 640 × 2 = 1280。輸出寬度:1280 像素。
- 高度:720 已經是偶數 (720 / 2 = 360 整除)，所以不會變動。輸出高度:720 像素。
- 最終 canvas 尺寸:1280 乘 720，比你輸入的窄了一個像素。
同樣的規則套用於奇數高度，例如 719，會得到 floor(719 / 2) × 2 = 359 × 2 = 718。如果你同時要求 1281 和 719，兩個尺寸都會損失一個像素，你會收到 1280 乘 718。這個算術夠簡單，讓你能在開始編碼之前預測任何奇數輸入的輸出尺寸，當你需要像 1920 乘 1080 這樣的目標尺寸並想確保沒有四捨五入的偏差時，這非常有用。
如何在知道奇數值會被四捨五入的情況下調整影片大小
影片尺寸調整工具會為你處理四捨五入，所以工作流程與任何其他調整相同——你只需要規劃好目標尺寸，使四捨五入後的結果仍然是你真正想要的尺寸。
- 在瀏覽器中開啟影片尺寸調整工具，選擇一個支援的本地影片 (MP4、WebM、MOV、M4V 或 Ogg)，大小上限為 500 MiB，長度上限為五分鐘。等待瀏覽器完成中繼資料載入後再繼續。
- 決定你要保留長寬比還是精確幾何。如果來源比例很重要，選擇適配並輸入你希望的最大寬度和高度作為邊界框。如果你需要精確矩形並願意允許失真，選擇拉伸並輸入精確的寬度和高度。
- 檢查你的數字。如果任一值是奇數，請記住編碼器會將其向下取整一個像素。如果奇數值仍然足夠接近你的目標，就輸入該奇數值;或者預先自行進位(若希望輸出 1282 像素，請輸入 1282 而非 1281，這仍然是偶數且對編解碼器安全)。
- 選擇調整影片大小，並在即時編碼期間保持分頁開啟。瀏覽器會解碼來源、以最高 30 fps 將畫面繪製到調整大小後的 canvas 上、擷取瀏覽器公開的音軌，並透過 MediaRecorder 錄製 canvas。
- 當錄製器停止後，下載產生的 WebM。使用任何媒體檢查器確認實際像素尺寸，並在刪除來源之前檢查檔案能否在你的目標播放器中正常播放。
如果你想再次查看相同的目標尺寸，只要來源和輸入的尺寸保持一致，上述步驟即可重現。這使得確認四捨五入行為變得容易，這也是 如何重複調整影片大小並獲得相同結果 指南中涵蓋的相同可重現性原則。
適配模式 vs 拉伸模式:四捨五入如何影響兩者
兩種模式都透過相同的編碼器處理 canvas，因此都會將奇數尺寸向下取整。差別在於四捨五入發生之前如何計算幾何。
| 模式 | 幾何計算 | 對四捨五入的影響 |
|---|---|---|
| 適配 (保留長寬比) | 選擇寬度縮放和高度縮放中較小者，使整個畫面能容納於框內而不被裁切。 | 四捨五入後的輸出保留來源比例。單一奇數尺寸仍可能使最終尺寸偏移一個像素，但畫面不會失真。 |
| 拉伸 (精確) | 獨立使用所要求的寬度和高度，將畫面映射到該矩形。 | 四捨五入後的輸出正是四捨五入後的框。縱橫比失真是刻意的，一個像素的損失直接來自於奇數的那個尺寸。 |
實際上，如果你只想知道檔案最終大小，適配模式是較安全的選擇，因為縮放比例源自來源，而四捨五入是可預測的。當目標播放器或平台有嚴格的像素要求(例如 1080 乘 1920 直向匯出)且你準備好接受失真時，應使用拉伸模式。無論哪種方式，一個像素的四捨五入規則都相同。
一個像素的損失在何時重要，何時不重要
在大多數觀看情境下，單一像素是看不見的。1280 乘 720 的畫面和 1281 乘 720 的畫面在相同螢幕上以相同播放大小看起來相同，檔案大小差異遠低於一個百分點。這種損失僅在少數狹窄情況下才有意義:
- 像素精確的比較，例如將重新編碼的片段與參考畫面進行差異比對以進行品質測試。
- 鏈式操作，你進行調整、裁剪，然後再次調整——一個像素的偏移可能會累積，使最終檔案與目標相差幾個像素。
- 硬體或編解碼器管線嚴格拒絕奇數輸入，且若中繼資料謊報真實畫面大小，則會產生損毀的檔案。
如果上述任何情況適用，請從一開始就在調整工具中輸入偶數值。預先輸入 1282 而非 1281，可使輸出保持你預期的、對編解碼器安全的精確偶數尺寸，並消除工作流程中的猜測。如需更深入的準備，調整影片前需要知道的事項 清單涵蓋了來源限制、音訊行為和 WebM 容器權衡等相關決策。
影片尺寸調整工具專為在瀏覽器分頁內執行的快速本地調整而打造，這正是奇數輸入損失一個像素是正確權衡的用例。如果你需要畫面精準的交付、真正的 MP4 輸出、精確的位元率控制，或色彩管理的母版製作，正確的做法是使用一款能公開完整編解碼器設定的專用桌面編碼器——瀏覽器工具不會承諾這些保證，也不應被強行套用於它並非為此設計的角色。對於讓片段符合目標矩形的日常工作，了解奇數尺寸會被向下取整一個像素，能把令人困惑的結果變成可預測的結果。