基於瀏覽器的影片剪輯工具，並無法在您指定的時間點上產生影格精準（frame-accurate）的剪輯；下載片段的編碼結尾，可能會落在您所輸入時間的前後一小段時間之外。當某個工具跳轉到起始時間、在播放過程中錄製媒體串流，並在結束時間停止錄製時，實際編碼出來的影格，取決於瀏覽器如何對播放內容進行取樣，而不是對來源檔案進行封包層級的檢查。Lizely 的 影片剪輯工具（Video Trimmer） 正是採用這種運作方式：它會擷取瀏覽器所公開的媒體串流、即時錄製，並將選定的時長寫入新產生的 WebM 檔案的 Segment Info 中。因此，雖然您可以輸入精確到毫秒的起始與結束時間，工具也會回報您所要求的時長，但最後一個編碼影格，仍可能會落在您指定的時間戳記之前或之後一點點。「方便且保護隱私」與「影格精準」之間的差異，是這個問題的核心所在，也決定了您在下載結果之前，應該抱持怎樣的期待。
剪輯影片時，「影格精準」代表什麼意思
影格精準是指剪輯後的成品，其第一個編碼影格，與來源影片在指定起始時間的影格完全對齊；而最後一個編碼影格，則與來源影片在指定結束時間的影格完全對齊。在非線性剪輯軟體中，這項特性是透過剖析容器（container）以及關鍵影格索引（keyframe index），然後在 GOP 邊界或播放頭所指向的精確影格上進行剪輯來達成。輸出結果可能是這些封包的串流拷貝（stream copy），或是對齊到選定影格的精確重新編碼，而剪輯軟體可以透過讀回時間軸來驗證對齊的正確性。
瀏覽器內建的剪輯功能，預設情況下無法達成這點。網頁可以播放本機影片、跳轉到特定時間戳記，並透過 MediaStream Recording API 擷取解碼後的輸出，但它無法讀取來源影片的封包、關鍵影格索引，或是每個影格的容器結構。瀏覽器所產生的錄製結果，是綁定在播放時脈（playback clock）上，而非容器的剪輯點上。根據 MDN 的 MediaRecorder 說明文件，所錄製的資料來自播放過程中所擷取到的 MediaStream，這代表每個區塊（chunk）都是以瀏覽器被要求播放時的實際時間作為時間戳記。
實際上的結果是：WebM 的第一個編碼影格，會對應到瀏覽器在跳轉到起始時間後所繪製的第一個影格；而最後一個編碼影格，則對應到錄製器在結束時間附近停止前，所繪製的最後一個影格。最後一個編碼影格可能會在任一方向上偏移一小段時間，具體取決於關鍵影格的位置、編解碼器的行為，以及瀏覽器清除錄製緩衝區的積極程度。使用者介面上所顯示的回報時長，就是您所要求的時長；而檔案中實際編碼的時長，則是瀏覽器真正擷取到的內容。
為何編碼後的邊界會偏離您所要求的時間
造成這種偏移的原因主要有三個，而它們全都源自於錄製管線的建構方式，而非工具中的任何單一設定。
第一個原因是即時擷取。影片剪輯工具會跳轉到指定的起始時間、擷取媒體元素的串流，並持續錄製直到播放到達指定的結束時間。錄製過程是以即時速度進行，因此任何暫停、卡頓，或是播放速率的變動，都會影響編碼器停止的位置。在效能正常的機器上處理短片時，這通常看不出來。但在處理較長的影片，或是使用效能較低的裝置時，這是最可能造成偏移的原因，而且這是工具本身在事後無法補償的。
第二個原因是編解碼器的緩衝行為（codec flush behavior）。當錄製器停止時，瀏覽器會將管線中目前正在處理的影格編碼完成。這個結尾的區塊可能會包含多出來的幾個影格，也可能恰好在精確邊界前停下來，這取決於編解碼器的實作方式。VP9、VP8，以及可選的 Opus 音訊路徑，在這裡的行為都可能略有不同，而且瀏覽器並沒有提供可倒轉並修剪結尾影格的機制。接著，WebM 的 Segment Info 會被寫入您所要求的時長，讓相容的播放器能回報一個有限的時間軸，但編碼後的影格本身並不會被倒轉或修剪以對齊該時長。
第三個原因是跳轉精準度。瀏覽器中的解碼影片是依「時間」定位，而不是依「影格編號」定位。如果來源影片的關鍵影格間隔並不規律，瀏覽器可能必須從前一個關鍵影格開始播放，才能到達您所指定的起始時間，這可能會在實際可見內容開始之前，引入幾個影格的延遲。這三個因素綜合起來，就是為什麼「在 12.500 秒處剪輯」的指令，最後在編碼後的 WebM 中，可能會顯示為 12.43 秒或 12.57 秒，也是為什麼使用介面上顯示的要求時長，與檔案內部實際的時長，雖然接近但並不完全相同。
如何在瀏覽器中於本機剪輯影片
對於大多數日常的剪輯工作——例如分享一段影片、從錄影中剪掉某個段落、發布一小段摘錄——這種邊界上的偏移小到可以忽略。以下是使用影片剪輯工具時的工作流程，但前提是您接受其結果是即時重新編碼，而非影格精準的剪輯。
- 選擇一個支援的本機影片檔案（MP4、WebM、MOV、M4V 或 Ogg），大小不超過 500 MiB，並等待其時長在使用介面中顯示出來。該檔案永遠不會被上傳；解碼作業會在當前的瀏覽器分頁中進行。
- 以秒為單位輸入起始時間，必要時可使用小數表示毫秒，數值必須為零或正數。以相同的格式輸入結束時間，確保它晚於起始時間，且不晚於解碼後的總時長。
- 確認所選的範圍至少涵蓋 0.1 秒，並確認來源影片本身在解碼後的時長不超過五分鐘，長寬任一邊不超過 4096 像素，總面積不超過 3840 × 2160 像素。
- 選擇「剪輯影片」。工具會跳轉到起始時間、擷取媒體元素的串流，並持續錄製直到播放到達結束時間。
- 檢視使用介面所顯示的回報時長與輸出檔案大小。在作業進行中，可以隨時取消。
- 下載產生的 WebM 檔案。輸出格式會使用瀏覽器所支援的 VP9、VP8，或是可選的 Opus 組合，並將選定的時長寫入 Segment Info 中。
請注意，副檔名熟悉並不保證成功：瀏覽器必須支援容器內實際使用的編解碼器，而不僅僅是認得檔名。如果某個步驟明顯失敗——例如範圍無效或顛倒、編解碼器不支援，或是產生空白的錄製檔案——工具會直接回報錯誤，而不會擅自猜測或調整您的數值。
輸入、輸出與限制條件
剪輯的精準度並非輸入與輸出之間唯一會改變的項目。下表總結了影片剪輯工具所強制執行的限制，以及輸出檔案的相關特性。如果違反了任何一列的限制，工具將無法完成工作，並會顯示錯誤，而不會默默地降低結果的品質。
| 限制條件 | 可接受的值 |
|---|---|
| 支援的容器格式 | MP4、WebM、MOV、M4V、Ogg |
| 來源檔案大小限制 | 不超過 500 MiB |
| 解碼後時長限制 | 不超過五分鐘 |
| 解碼後尺寸 | 任一邊不超過 4096 像素；總面積最多 3840 × 2160 像素 |
| 編解碼器需求 | 瀏覽器必須支援容器內實際使用的編解碼器 |
| 起始值 | 零或正數；可包含毫秒 |
| 結束值 | 晚於起始時間；不晚於解碼後的總時長 |
| 最短選取片段 | 至少 0.1 秒 |
| 輸出容器 | WebM（VP9、VP8 或 Opus 組合） |
| 輸出尺寸 | 保留自來源影片 |
| 品質、關鍵影格、色彩中繼資料、音訊配置 | 可能與來源不同 |
| 輸出檔案大小 | 可能與來源不同 |
| 處理位置 | 本機瀏覽器分頁；不會上傳任何資料 |
對於顛倒或超出範圍的輸入——例如起始時間晚於結束時間、結束時間超過解碼後的總時長，或是選取的片段短於 0.1 秒——系統會明確顯示錯誤，而不會默默地調整或位移數值。這種明確的錯誤顯示，正是造成「要求時長」與「編碼時長」可能出現差異的原因之一：工具會回報您所要求的時長，而編碼後的影格，則會落在瀏覽器實際處理的時間點上。
何時影格精準的剪輯很重要，以及替代方案
在某些情況下，上述微小的邊界偏移是完全不可接受的，這時影片剪輯工具就不是合適的選擇。事先了解這些限制，可以避免日後重做工作。
- 廣播或戲院發行。像是「精準對在拍手聲上」或「對在重拍上」這類剪輯決策，需要影格對齊的輸出。請使用專業的桌面非線性剪輯軟體，並逐格檢查輸出的時間軸。
- 精確的關鍵影格剪輯。如果您需要新片段從來源影片的關鍵影格開始，以便下游工具可以不重新編碼直接進行串流拷貝，那麼瀏覽器擷取是無法達成的。您需要封包層級的存取權，這代表必須使用能剖析容器結構的工具。
- 保留字幕、章節或標記。剪輯後的 WebM 並不保證會保留每一項中繼資料欄位。如果您的來源影片包含嵌入式字幕、多軌音訊或章節標記，新檔案很可能會將它們移除。
- 需要 MP4 輸出。影片剪輯工具永遠輸出 WebM 格式。如果您的下游工具、平台或裝置需要 MP4 容器，請在桌面剪輯軟體中重新編碼剪輯後的 WebM。
- 來源影片過長。任何解碼後時長超過五分鐘的影片，都超出了本工具可接受的範圍。請分段剪輯，或改用桌面工作流程。
- 受 DRM 保護的媒體。本工具不會繞過 DRM、擷取遠端媒體，或移除浮水印。請僅使用您擁有或有權編輯的影片。
對於上述清單以外的所有用途——例如分享一段短片、從會議錄影中剪掉某個段落、抓取一段訊息用的片段、或是擷取一段供快速檢視的摘錄——邊界的偏移幅度小到可以忽略。此時，本機處理的便利性與隱私性，以及瀏覽器內剪輯的速度，會比失去影格精準對齊的能力更為重要。請將「要求時長」視為目標，將「編碼時長」視為近似值，並將 WebM 視為一個新近重新編碼的預覽版本，而非影格完美的剪輯成品。
如果您正在權衡各種方案，擷取影片影格時可能出錯的地方 一文對此有詳細說明。
如果您正在權衡各種方案，剪輯影片前新手必知的事項 一文對此有詳細說明。