在瀏覽器式影片幀擷取工具中，所要求的幀時間是一個媒體時間軸位置，並非來源幀精度的保證，兩者不應混淆。當你輸入 12.375 秒這類數值時，HTMLMediaElement 會跳到該位置，瀏覽器則繪製最接近的已解碼幀，並將該幀編碼為 PNG。已解碼幀是由瀏覽器的媒體管線所決定，該管線取決於關鍵幀、編解碼器行為、時間戳記捨入、編輯清單以及變動幀率。下載的 PNG 會以原生尺寸保留已解碼幀，不會進行縮放、裁剪、銳化或任何濾鏡處理。對於你擁有或已獲授權處理的媒體，若用途是縮圖、參考資料、簡報或快速取得靜態畫面，這通常符合大多數人真正想要的結果。但若是需要幀級精度的編輯工作、精確的編號幀、HDR 或色彩管理輸出、含 Alpha 通道的工作流程，或橫跨長片進行的批次擷取，正確的解決方案是能檢查封包時間戳記的專用桌面工具，而非瀏覽器管線。理解這項差異，是取得你真正所需靜態畫面的第一步。
「精度」在從影片擷取幀時代表什麼
當人們搜尋「extract frames from video accuracy」時，他們其實在問兩個相關但不同的問題。第一個是：儲存的靜態畫面是否對應到輸入的時間？第二個是：輸入的時間是否對應到特定的編號來源幀？像 Video Frame Extractor 這類瀏覽器式擷取工具，對第一個問題是精確的，對第二個問題則有所限制。時間欄位接受從零到所顯示時長之間的含小數秒數，因此像 1.25 或 30.5 這類數值會完整保留輸入的形式——這部分是真實的，且輸出檔名會包含所選時間，以便記錄請求內容。然而，瀏覽器回傳的是最接近該時間軸位置的已解碼幀，且所顯示的時間記錄的是請求位置，而非實際已解碼幀的來源幀編號。輸出 PNG 同樣以原生像素尺寸保留已解碼幀，因此結果與解碼器產出的尺寸相同——並未套用縮放、銳化或平滑化來「修飾」影像。這讓靜態畫面保持真實：若你輸入的時間落點偏差一幀，PNG 會如實呈現瀏覽器解碼的結果，而不是你所輸入時間的平滑近似值。
為何瀏覽器解碼會落在鄰近幀
要求時間與來源幀之間的落差，源自壓縮影片實際的儲存方式。多數現代編解碼器僅在特定間隔（稱為關鍵幀或 I 幀）儲存完整畫面，其餘畫面則以最近關鍵幀為基準的正向或反向差量方式編碼。當你跳到某個非關鍵幀的位置時，瀏覽器通常會解碼最近的關鍵幀，再向前播放直到抵達所要求的時間戳記。這個向前播放的過程可能會捨入到最接近的已解碼幀邊界，這代表你儲存的靜態畫面可能與輸入的時間戳記相差一或兩幀。除此之外，還有其他幾種行為可能使結果偏移：
- 變動幀率（VFR）素材中，幀與幀之間的間隔並不固定，這會使任何時間對幀的計算都只能是近似值。
- 在不重新編碼底層串流的情況下修剪容器時間軸的編輯清單，可能會改變解碼器認定為時間「零」的位置。
- 容器內部的時間戳記捨入，可能會將請求對齊到最近的容器時間戳記。
- 不同編解碼器的跳轉行為各異，H.264、HEVC、VP9 與 AV1 之間都有差異，且某些跳轉策略較快但精度較低。
根據 MDN 的 HTMLMediaElement 參考資料，currentTime 屬性代表媒體時間軸上的某個位置，並不保證與來源幀編號對齊；結果取決於底層解碼器如何滿足跳轉需求。同樣的注意事項也適用於將已解碼幀透過 drawImage 交給 canvas 的情況——渲染器取得的是解碼器手上既有的幀，而非你可能想要的那個封包時間戳記所對應的幀。
檔案、編解碼器與輸出限制
精度並非唯一會阻擋幀擷取的因素。在進行任何跳轉之前，瀏覽器必須解碼容器、將已解碼幀繪製到 canvas，然後將結果編碼為 PNG——每一步都有其上限。Video Frame Extractor 對所有輸入套用統一的安全政策，使操作保持在有限、可預期且失敗時可回報的範圍內。檔案必須落在文件所規範的範圍內，而輸出則受 canvas 能編碼的內容所約束。下表的限制在工具內不可協商；它們的存在，是為了確保解碼器、canvas 與 PNG 編碼器隨時有餘裕執行工作，而不會逾時或產生損毀檔案。
| 限制 | 數值 |
|---|---|
| 最大檔案大小 | 500 MiB |
| 最大時長 | 5 分鐘 |
| 每邊最大像素數 | 4096 px |
| 最大輸出解析度 | 3840 × 2160 |
| 支援的容器 | MP4、WebM、MOV、M4V、Ogg |
| 輸出格式 | PNG |
| 輸出尺寸 | 已解碼幀原生大小 |
| 縮放、裁剪、銳化 | 未套用 |
支援的副檔名並不保證容器內的編解碼器一定可用。同一個 MP4 檔案可能在某個瀏覽器中能開啟，在另一個瀏覽器中卻無法載入，因為瀏覽器只會內建它所搭載的解碼器。WebM、MOV、M4V 與 Ogg 也是如此：在某台機器上可正常運作的檔案，在另一台機器上若編解碼器組合不同便可能失敗。若解碼、canvas 繪製或 PNG 編碼在任何一步失敗，工具會回報失敗，而不會產出空白或損毀的下載檔——這也是精度的一部分：明顯錯誤的結果，勝過靜默錯誤的結果。當輸入變更或元件卸載時，過期的工作與物件 URL 會失效，因此前一個檔案半完成的擷取不會洩漏到下一個作業中。
如何使用 Video Frame Extractor 擷取幀
以下為工作流程的簡要說明。工具會在當前的分頁中本地處理檔案——不會上傳任何內容——而 PNG 是由瀏覽器在所要求時間所暴露的已解碼幀所產生。
- 選擇一個符合 500 MiB 與 5 分鐘政策、且為支援格式（MP4、WebM、MOV、M4V 或 Ogg）的本地影片，然後等待時長與預覽載入完成。若檔案無法載入，最可能的原因是容器內的編解碼器在你的瀏覽器中不可用——請嘗試其他檔案或不同的編碼。
- 在零到所顯示時長之間輸入一個以秒為單位的幀時間，需要毫秒級定位時可使用如 1.25 或 30.5 的小數。欄位接受含小數的秒數，而你輸入的數值會完整保留於輸出檔名中。
- 選擇「Extract PNG frame」，確認預覽中的靜態畫面，然後下載本地的 PNG。檔名會包含所選時間，方便日後追蹤所擷取的時間點。若靜態畫面差了一點，可微調時間並重新擷取——這是工具所支援、可用來精準對齊所需瞬間的方式。
更接近目標幀的實用技巧
由於瀏覽器跳轉受限於關鍵幀距離，以下幾個習慣能讓結果更可預期：
- 了解你的來源幀率。在 30 fps 下，每幀間隔約 0.0333 秒；在 60 fps 下約為 0.0167 秒。選擇落在幀區間內部、而非邊界上的時間，能讓跨次執行結果穩定。
- 盡量靠近關鍵幀。多數編碼器每隔 1 到 5 秒放置一個關鍵幀；時間越接近關鍵幀，解碼器造成的漂移通常越小。若你能取得編碼報告或會顯示關鍵幀標記的播放器，請善加利用該資訊。
- 使用小數而非幀編號。欄位接受含小數的秒數；即使解碼幀偏差了一個區間，輸入像 12.375 這類數值仍能明確記錄你所請求的內容。「第 4827 幀」這類請求無法直接輸入——只能輸入該幀大致對應的時間。
- 下載前先驗證。靜態畫面預覽就是實際的已解碼影像。若幀位置差了一點，可微調一小段時間並重新擷取，直到預覽符合你所想要的瞬間。
- 若需精確的編號幀或批次作業，請改用其他工具。任何需要封包層級精度的工作——例如 20 分鐘檔案中精確的第 4827 幀、10 分鐘片段的每一幀、HDR 或色彩管理輸出——都應交由專用桌面影片工具處理，而非瀏覽器管線。若想更深入了解時間與幀率之間的數學計算，可參考從幀率與時間取得影片幀指南，其中對相同計算有更詳細的說明。
PNG 能保留透明度嗎？只有當瀏覽器的已解碼影片幀確實提供 Alpha 通道時才能保留。多數編碼後的影片並未提供 Alpha 通道，因此即使你預期會有透明，PNG 仍會是不透明的——canvas 保留的是解碼器交給它的內容，而非來源格式可能暗示的內容。
當瀏覽器的精度不足以應付時
Video Frame Extractor 的設計目的，是針對你擁有或已獲授權處理的短片，單次擷取一幀。它不支援批次處理、不會內插解碼器未暴露的幀，也無法保證所要求的時間等同於特定的來源幀編號。HDR 色彩管理、含 Alpha 通道的工作流程、極長的素材、解碼器無法辨識的容器／編解碼器組合，以及每個幀編號都必須對應到 EDL 的編輯工作，皆超出其適用範圍。決策規則很簡單：若你需要確認儲存的是哪一個精確編號的幀，瀏覽器管線就是錯誤的工作層級，因為已解碼影像是由媒體引擎選擇，而非透過封包時間戳記運算得出。針對這類情況，正確的做法是使用桌面 NLE，或具備封包層級時間戳記存取權的命令列工具——通常的答案是搭配幀率感知跳轉篩選器的 FFmpeg，而逐幀的本地擷取工作流程則適用於需要精確時間戳記的情境。若只是要快速取得參考用的靜態畫面、簡報用的縮圖、文件中的暫停瞬間，或單張用於簡報的 PNG，瀏覽器管線已綽綽有餘。對於更嚴格的需求，請規劃一個下探至 canvas 層以下、進入解多工器的步驟。
若想進一步了解，請參閱擷取影片幀：瀏覽器解碼如何運作。