我曾經從一次採訪中刪除了 40 秒的答案，把它扔進了甲板上，然後看著演講者在我想要的那一點之前七秒鐘開始。 我已經仔細設定了開始。 修剪機不理我，或者看起來是這樣。 它沒有：它做了快速切割唯一能做的事，這是在我要求的點之前從最近的關鍵影格開始。 一旦你知道這一點，行為就不再是錯誤，成為兩個選項的選擇，選擇正確的一個需要一秒鐘。
TL;DR: 快速修剪複製現有的視訊串流而不是重新編碼，而副本只能從關鍵影格開始。 要求從 0:07 開始，在關鍵影格相距十秒、切割從 0:00 開始的檔案上，因為這是解碼器可以從最後一個點開始。 你問的末端地；只有開始漂移，它向後漂移。 當您需要確切的框架時，修復程序是重新編碼，這更慢，而且成本略有。 那個 視訊修剪器 提供和預設為快速。
為什麼削減比你問的更早開始？
因為影片中幾乎沒有框架是完整的畫面。
視訊壓縮透過儲存一個完整的畫面，然後描述這些變化來運作。 一個關鍵影格，正確地是一個 IDR 框架 H.264，擁有一個完整的形象，什麼都不依賴。 保持差異後的畫面：這個區塊向左移動四個像素，這個區域沒有變化，這些像素變得稍微暗。 順序中途的框架本身就沒有意義，如果沒有它所應用的文件，差異是毫無意義的。
因此，當您要求從 0:07 開始並且工具複製流而不解碼時，在 0:07 沒有任何東西可以複製。 有一個描述 0:07 與之前的內容有何不同。 玩家唯一可以開始的地方是關鍵影格，唯一安全的地方是起點或之前的最後一個關鍵影格。
另一種方法是將影片解碼到 0:07，扔掉之前的內容，然後將剩餘的內容壓縮到以新的關鍵影格開頭的新檔案。 這是準確的，它是慢路的，因為它在每個幀上都做真正的工作，而不是複製位元組。
關鍵影格相距多遠，真的嗎？
比大多數人想像的更遠，而差距決定了快速切割的錯誤。
我測量它而不是猜測。 以預設為 X264 的 30 秒測試鏡頭編碼，然後列出關鍵影格：
ffmpeg -f lavfi -i "testsrc=duration=30:size=640x360:rate=25" -c:v libx264 clip.mp4
ffprobe -select_streams v -show_entries packet=pts_time,flags -of csv=p=0 clip.mp4 \
| awk -F, '$2 ~ /K/ {print $1}'
# 0.000000
# 10.000000
# 20.000000
每十秒一個關鍵影格。 這是 X264 的預設值，在關鍵影格之間有 250 幀，每秒 25 幀。 在使用這些預設值編碼的檔案上，快速修剪可以在您選擇的點之前十秒開始。
您處理的大多數鏡頭都更友善，因為其中大部分是為串流媒體製作的，玩家需要頻繁的入口來切換品質。 這是值得了解的範圍：
| 來源 | 典型的關鍵影格間隙 | 最壞的情況漂移 |
|---|---|---|
| 電話錄音 | 1 到 2 秒 | 幾乎不明顯 |
| 串流影片、HLS 或 Dash | 2 到 6 秒 | 在短片上很明顯 |
| x264 或 ffmpeg 預設值 | 25 fps 10 秒 | 破壞捷徑 |
| 螢幕錄影機，低動作 | 10 秒或更長 | 破壞捷徑 |
模式：為播放器編碼的任何內容都有關閉的關鍵影格，而編碼一次用於儲存的任何內容都沒有。
漂移對文件有什麼作用？
它移動開始並留下一端，這值得精確，因為很容易假設整個視窗滑動。
要 0:07 到 0:15 要相同的剪輯，8 秒的視窗，帶有流副本：
| 要 | 來源中的關鍵影格 | 結果 | 發生了什麼事？ |
|---|---|---|---|
| 7s 到 15s | 0、10、20 | 0 到 15.08s | 開始回到關鍵影格 0 |
| 12 到 20 多歲 | 0、10、20 | 10s 到 20.08s | 10點開始回到關鍵影格 |
| 7s 到 15s | 每 2s | 6s 到 15.08s | 開始後退一個關鍵影格 |
三人都正確。 我透過對幀進行雜湊而不是信任持續時間來檢查：輸出的最後一幀與原始碼的 15.04 秒是同一格，這是我要求的框架和正確的停止位置。 改變的是它開始的地方。
這就是文件比您選擇的視窗更長的原因。 你認為八秒鐘的剪輯是十五秒，不是因為任何事情都超過，而是因為七秒的引導出現了。 在關鍵影格相距兩秒鐘的剪輯上，相同的切口以九秒的速度到達，沒有人注意到。
您應該何時重新編碼？
三種情況，在它們之外，快速路徑是更好的工具。
你需要一個特定的框架。 在球擊球的那一刻，一句話，一個手勢。 關鍵影格準確性不夠好，對滑桿的任何關注都無濟於事，因為限制在文件中而不是在介面中。
剪輯很短。 在 30 秒的剪輯中進行 7 秒的引導是一件令人討厭的事情。 在四秒鐘的切割中，這就是整個事情。
您正在切除具有稀疏關鍵影格的檔案。 如上圖所示，螢幕錄製和一次匯出的任何檔案都是為了存檔。
成本是真實的，但比人們擔心的要小。 重新編碼視窗中的每個畫面並再次壓縮它，因此它需要與切割長度成正比的時間而不是檔案的大小，並且會失去一代人的品質。 在 23 的恆定速率係數下，這是修剪器在其準確模式中使用的，該損失在一次通過時接近不可見。 這是已經壓縮過一次的第二次通過鏡頭，這是一樣的 控制壓縮的生成損失 一般。
如何在自己的檔案中找到關鍵影格？
一個命令，它會提前告訴你快速路徑是否會起作用。
# the first ten keyframe timestamps, in seconds
ffprobe -select_streams v -show_entries packet=pts_time,flags -of csv=p=0 input.mp4 \
| awk -F, '$2 ~ /K/ {print $1}' | head -10
如果間隙是一兩秒，請快速修剪並停止思考。 如果它們是十，而您的切割很重要，請重新編碼。
這有第二個用途。 如果您正在製作其他人將剪輯的鏡頭，那麼以較短的鍵框間隔進行編碼會使他們的生活更輕鬆，而文件大小的成本很小。 關鍵影格是全貌，因此其中更多意味著更多位元組，這正是編碼器在沒有人要求其他任何東西時將它們分開的原因。
修剪會失去品質嗎？
嚴格意義上的快路沒有。 沒有任何東西被解碼，所以沒有重新壓縮：輸出中的幀與輸入中與輸入中相同的壓縮幀，位元組，在新容器中。 以這種方式修剪一個檔案十次，第十個的品質與第一個相同。
準確的路徑可以，一次。 視窗再次被解碼和壓縮，因此它會產生一代損失。 在合理品質目標上編碼精良的來源上，這很難看到，而明智的規則是從原始的一鍵中完成您需要的切割，而不是修剪裝飾。
兩條路都沒有高檔、磨礪或改善任何東西。 修剪器會刪除時間，這就是整個工作。
為什麼我的修剪剪輯不能立即開始播放？
因為索引落地，壓縮時重要的是同一個標誌。
MP4 包含一個表格，描述每個幀的起點。 以明顯的順序編寫，該表最終在文件的末尾，因為編碼器只有在完成後才知道它的內容。 從磁碟播放，很好。 透過 HTTP 服務，玩家在整個檔案到達之前無法啟動。
修剪器通過 -movflags +faststart，它快速地第二次通過並將該桌子移到前面。 然後，剪輯在下載時開始播放，這是您想要的，當檔案進入聊天應用程式、CMS 或從 URL 中提取的投影片時。
音訊怎麼了？
音訊是根據自己的框架邊界剪切的，它們比視訊關鍵影格間隔短得多，因此音訊可以比圖片更接近您的標記。
這種不匹配是另一個經典修剪故障的來源：一個聲音略高於圖片的剪輯，或以單字的片段開頭。 修復在參數而不是編輯中，修剪器傳遞它： -avoid_negative_ts make_zero 重新基於兩個流的時間戳記，以便輸出從零開始，流仍然相對於彼此對齊。 沒有它，流副本可以為關鍵影格和你的剪輯點之間的框架發出負面的時間戳記，玩家不同意如何處理這些。 有的跳過，有的停，有的很早就播放音訊。
如果你只想要聲音，先剪掉影片，然後再剪 提取音訊 是錯誤的順序。 先提取並剪斷音訊，因為音訊切割既精確又便宜。
在手機的照片應用程式中修剪會更好嗎？
對於一個快速的個人剪輯，它很好，它就在那裡。 對於您將發布的任何內容，不，原因並不明顯。
電話編輯器通常會重新編碼匯出，他們使用選擇的設定來選擇速度和可預測的檔案大小而不是保真度。 你在每次修剪時都會付出一代的損失。 更糟的是，其中一些非破壞性地修剪，將您的進出點儲存為原始資料，這在手機上看起來像一個修剪，一旦文件離開，它根本不是修剪：收件者獲得完整的剪輯，或他們的播放器忽略的編輯清單。
複製模式修剪可以避免這兩個問題。 您獲得的檔案是每個人獲得的檔案，其中的幀從未被解碼。
影片會離開我的機器嗎？
不 。 切口貫穿 ffmpeg 編譯為 webassembly 在瀏覽器標籤內：檔案從磁碟讀取到頁面記憶體，在那裡修剪，然後作為下載傳回。 DevTools 中的網路面板在發生這種情況時保持空白。
對於鏡頭，這比大多數文件類型更重要。 剪輯通常是任何人編輯的最大和最個人的事情，免費線上修剪器的正常安排是您將您的鏡頭上傳給陌生人，並相信您未閱讀的頁面上的保留政策。 這裡不存在要保留的副本。
限制是標籤而不是計劃：單切割的上限為 30 分鐘，整個來源必須適合瀏覽器記憶體。 除此之外，桌面工具既更快又更可靠，這樣說比在九分鐘時給你一個記憶體用完的標籤要好。
什麼時候桌面編輯器是正確的工具？
當你做的不僅僅是消除時間。 加入幾個剪輯，添加標題、顏色、音樂或切割您需要在樣本層級上看到的波形。 這是一個編輯時間表，而不是修剪器，正確的答案是真正的編輯器。
在瀏覽器中，分界線幾乎一樣乾淨。 從一個夾子中移除一個伸展是一個修剪。 將碎片結合在一起的是 影片編輯器。 使結果更小 壓縮機，更改容器或編解碼器是 轉換器，這是一個 與壓縮不同的操作 儘管兩人經常感到困惑。
為什麼預覽和匯出的文件不同意？
因為修剪介面從三個不同意數字是什麼的地方收集相同的數字，而將它們放在一個值上是修剪器中的大部分工作。
文字欄位可以為您提供任何輸入的人，這可能是 7, 0:07, 00:00:07 或者 7.25。 滑塊比任何人都想要的更精確。 視訊元素 currentTime 給出另一個浮點數，這根本不一定是幀的時間戳記：瀏覽器可以報告幀之間的位置，而且它們確實如此。
如果這三個在稍微不同的秒鐘上著陸，預覽顯示一件事，而導出產生另一件事，這是使修剪器即使在正確下也感到損壞的特定錯誤。 這裡的解析器接受所有三個時間碼形狀，以正確對齊的方式解析它們，因此最後一部分總是秒，無論長度如何，並將單一值交給預覽和導出。 一個半鍵式的欄位不傳回任何內容，而不是拋出，因此輸入時輸入不會在每次擊鍵上爆炸 0:0.
實用建議：在確切的第二個問題時輸入時間碼而不是拖曳。 滑桿是用來找當刻的，一個用於命名它的字段。
如何從中間切出一段？
兩個切割和一個連接，沒有修剪器可以一步一步地做到這一點，這經常讓人們感到驚訝。
移除夾子的中間意味著將零件保留在您選擇之前和之後的部分，即兩個獨立的視窗，然後將它們重新組合在一起。 這裡的修剪器每次運行產生一個視窗，所以順序是：從壞部分的開始到開頭修剪，從壞部分的結尾修剪到結束，然後將兩個連接到 影片編輯器.
當你這樣做時要注意兩件事。 當兩件作品共享編解碼器、解析度和幀速率時，連接可以乾淨地工作，如果兩者都來自同一個來源檔案，則透過複製模式修剪。 接縫落在兩側的關鍵影格邊界上，因此第二部分的開始比您標記的要早一些，完全如上所述。 如果切點很重要，請對第二部分使用準確模式。
另一個選擇是在開始之前停下來：如果您想要的是高光而不是編輯，那麼兩個單獨的剪輯通常比一個夾縫更有用的夾子更有用。
