將兩個影片檔案端到端放置聽起來像是世界上最便宜的操作，大約五分鐘我相信。 然後我使用最快的方法將 1280x720 剪輯以 30fps 的速度加入 640x480 的剪輯，使用最快的方法，複製流並不重寫。 它產生了一個文件。 當兩個剪輯加起來十一時，該文件聲稱是十一點九九六秒長，容器說 1280x720，而流的後半部分是 640x480，而 muxer 則印製了關於第二個剪輯的每個框架的重寫時間戳記的警告。 關於加入影片的一切都取決於為什麼會發生這種情況。
TL;DR: 便宜的加入只有在兩個檔案都已經在編解碼器、解析度、幀速率和時基上達成一致時才有效，而兩個裝置的鏡頭從未如此。 誠實的路線同時解碼並編碼一個新檔案，該檔案速度較慢，並且會產生播放的內容。 這裡測量：複製方法在 11 秒的鏡頭中報告了 11.996 秒，並宣布了錯誤的解析度；重新編碼在 0.63 秒內以單一一致的 1280x720 產生 11.000 秒。 必須先將不同尺寸的夾子安裝到一幀中，否則連接將被直接拒絕。 那個 影片編輯器 在瀏覽器中完成所有操作，最多八個剪輯和三十分鐘。
為什麼兩個剪輯不能只是黏在一起？
因為影片檔案不是帶有標題的圖片流。 它是一個容器，其中包含編碼的流，編碼是承載狀態。
H.264 透過將大多數幀描述為與其他幀的差異來壓縮。 關鍵影格獨立存在；它之後的一切都與先前的內容相對應，直到下一個關鍵影格。 解碼器還需要 Stream 的參數集，它描述解析度、顏色格式和設定檔，它包含一個將每個資料包上的數字轉換為秒的時基。
兩個設備製作的兩個文件都同意這些。 不同的分辨率意味著不同的參數集。 不同的幀速率通常意味著不同的時基。 即使是相隔一年錄製的同一款手機的兩個剪輯，也可能有所不同，因為相機應用程式更改了其編碼器設定。
連接位元組會給你一個流，它的解碼器在標題中被告知一件事，並在中途交出另一件事。 有時玩家會應付。 通常它顯示第一個剪輯並停止，或將第二個剪輯播放為彩色噪音。
快速方法會產生什麼？
一個文件，一堆警告和一個錯誤的持續時間。
ffmpeg&#s 濃縮器 與串流複製是每個“只需加入他們”的方法在線推薦，當輸入匹配時，它確實是正確的工具。 指著它成功退出的兩個不匹配的剪輯，這是它回饋的：
| 測量 | 預期 | 生 |
|---|---|---|
| 長短 | 11.000 秒 | 11.996 秒 |
| 宣判 | 一個值，正確 | 1280x720 用於 640x480 的流 |
| 時間戳警告 | 沒有 | 第二個剪輯的每幀一個 |
警告都說了同樣的話：
Non-monotonic DTS; previous: 90981, current: 76133; changing to 90982.
This may result in incorrect timestamps in the output file.
第二個剪輯的時間戳記從零重新開始，因為它們應該在自己的檔案中，而 muxer 不會寫出時間戳倒退的流。 所以它發明一個新的，一次一個框架，真實時間和發明的時間之間的累積差異是額外的秒的來源。
FFMPEG 之後仍然可以解碼兩半，因為 FFMPEG 的耐受性異常。 瀏覽器不是。 這是在您的機器上播放良好的檔案，並為檢視器顯示黑色矩形。
透過過濾圖加入的成本是多少，它買了什麼？
它花費完整的解碼和編碼。 它購買了一個正確的文件。
每個輸入都不是複製流，而是將每個輸入解碼為幀，而是在過濾器圖中修剪和連接，並從結果中編碼一個新流。 每個畫面都經過一個解碼器和一個編碼器，這是真正的工作。
它購買的是輸出有一個編解碼器、一個解析度、一個幀速率和一組連續的時間戳，因為它都是從頭開始編碼的。 在相同的兩個剪輯上：
| 測量 | 複製方法 | 濾圖 |
|---|---|---|
| 長短 | 11.996 秒 | 11.000 秒 |
| 決議 | 宣告 1280x720，變成 640x480 | 1280x720 整個 |
| 框框 | 305 | 305 |
| 輸出時間 | 瞬間 | 0.63 秒 |
| 尺寸 | 較小的 | 2.1 兆位元組 |
11 秒輸出的 0.63 秒工作，在本機運行 ffmpeg 的桌面上。 在透過 WebAssembly 的瀏覽器標籤中，它慢了好幾倍，這是誠實的交易，也是剪輯計數被封頂的原因。
為什麼每個剪輯都需要重新基於其時間戳？
因為濾波圖中的連接連接流，而流的時間戳是絕對的。
每個剪輯的畫面都從自己的文件開始時測量。 從夾子中間修剪一個部分，這些畫面仍然說“這發生在 42 秒”。 將他們加入到以 6 秒結束的剪輯，您將擁有一條從 6 秒跳到 42 的流，中間沒有 36 秒。
setpts=PTS-STARTPTS 從每一幀中減去每個剪輯自己的開始，因此每個剪輯在連接之前從零開始。 音頻等價物是 asetpts。 沒有它們，輸出播放第一個剪輯，然後是長凍結，然後是第二個。 這是手寫的 ffmpeg join 指令中最常見的錯誤，它是無聲的：檔案有效，持續時間不對。
當夾子大小不同時會發生什麼？
加入被拒絕，直到最近，拒絕才是這裡的全部。
的 連擊過濾器 如果視訊尺寸或樣本縱橫比不同意，則比較其輸入，並且不會運行：
Input link in0:v0 parameters (size 640x480, SAR 1:1) do not match the
corresponding output link in0:v0 parameters (1280x720, SAR 1:1)
Failed to configure output pad on Parsed_concat_8
那是一個中止，而不是警告：沒有產生檔案。 兩部手機，或一個電話剪輯和一個螢幕錄音，正是觸發它的情況，這也是有人加入剪輯的普通原因。
音訊不需要這樣的幫助，這值得知道，因為它是違反直覺的。 同一張圖表將 44.1 kHz 單聲道軌道連接到 48 kHz 立體聲無怨無怨的音軌，並產生確切的 11.000 秒檔案。 只有視訊端是嚴格的。
解決方法是在整個時間軸上確定一個框架，並在加入之前將每個剪輯放入其中。 高度來自您選擇的輸出解析度，或從您保持來源解析度時選擇的第一個剪輯，寬度遵循該剪輯的縱橫比，因此肖像畫面的時間線保持肖像。 然後每個夾子都被縮放以適應該框架並填充以填充它：
scale=1280:720:force_original_aspect_ratio=decrease,
pad=1280:720:(ow-iw)/2:(oh-ih)/2,setsar=1
合身而不是填充意味著不同形狀的夾子是信箱而不是拉伸，當 4:3 夾子遇到 16:9 的時間線時，這是兩個惡中較小的一個。 setsar=1 不是裝飾：濾鏡比較樣品縱橫比和像素尺寸，因此兩個夾子可以是相同的尺寸，但仍然被拒絕。
這兩個維度都四捨五入到偶數，因為 H.264 以 4:2:0 的比例在每個方向上以半分辨率儲存顏色，並且無法對奇數寬度或高度進行編碼。
為什麼只有八個剪輯和三十分鐘？
因為每個剪輯在瀏覽器標籤內花費一個解碼通道，並且該選項卡具有固定的記憶體量。
八個輸入意味著在同一個濾鏡圖上運行的八個解碼器，加上編碼器，加上記憶體中保存的每個原始檔，因為沒有磁碟可供串流。 三十分鐘的輸出是編碼需要足夠長的時間，以至於人們認為頁面已掛起的點。
這兩個限制都不是格式的規律。 兩者都是瀏覽器建立的線路，不再令人愉快，並且在匯出 40 分鐘後發現選項卡時，它們是預先說明的，而不是在選項卡中發現的。 短於十分之一秒的剪輯也被拒絕，因為它在下面沒有提供幀和 FFMPEG 錯誤而不是警告。
對於任何更大的工具，這是錯誤的工具，桌面編輯器是正確的。
這裡的修剪與修剪器有何不同？
在連接內進行修剪是準確的，而且不需要任何額外的費用。
專注 視訊修剪器 提供複製流的快速模式，並且只能在關鍵影格上切割，這就是為什麼修剪的開始有時會提前十秒。 它的指南 詳細介紹原因。
這種貿易在這裡不存在，因為無論如何出口都在重新編碼一切。 修剪發生在濾鏡圖內，在解碼的框架上，因此在 4.3 秒時切割是在 4.3 秒時切割。 您獲得的框架準確性是免費的，這是您已經支付的成本的副作用。
因此，如果您想要修剪一個夾子而不是其他任何東西，那麼修剪器的快速模式要快得多。 如果您要加入任何內容，請在此處修剪。
速度變化對音訊有什麼影響？
它必須單獨處理，並且算術與視訊不同。
視訊速度是時間戳記操作： setpts=PTS/2 將每個畫面的演示時間減半，框架本身不受影響。 音訊不能那樣工作，因為播放樣本的速度會以兩倍的速度提高音高。 那個 atempo 過濾器重新取樣，保持音高並改變持續時間。
atempo 在其大部分時間中，一次僅接受 0.5 到 2.0，因此 4x 更改是建立為兩次 2x 通過，而 0.25 倍的變化是兩個 0.5 倍的通過。 目前的版本提高了上限，FFMPEG 8.1 報告的範圍為 0.5 到 100。 在一個剪輯上測量，一個 atempo=4 和被鎖鏈 atempo=2,atempo=2 相距 11 毫秒。
鏈條仍然是建構的，因為 WebAssembly 核心是在運行時取得而不是固定到版本的，並且在曾經運送過濾器的每個構建上乘坐傳遞都是正確的。 提供的速度範圍，0.25 倍到 4 倍，結果仍然是編輯而不是新奇。
mp4還是webm？
MP4 除非你有具體的理由，而且原因幾乎總是許可而不是品質論證。
| mp4 | 網路 | |
|---|---|---|
| 視訊編碼 | H.264 | vp9 |
| 音訊編解碼器 | 阿克 | 作品 |
| 玩 | 一切 | 瀏覽器、大多數現代玩家 |
| 在選項卡中編碼速度 | 更快 | 慢得多 |
| 大小相似的尺寸 | 更大的 | 較小的 |
VP9 以相同的感知品質產生較小的檔案，並且它是免版稅的，這對某些專案很重要，但對其他專案則不重要。 ffmpeg 自己的 VP9編碼指南 對速度成本很直率。 它不是很快。 這裡的 WebM 路徑在更高的 CRF 上運行，並具有即時截止日期，並且 cpu-used 5， 桌面編碼會認為粗心的設定，因為沒有它們，標籤中的 VP9 編碼需要足夠長的時間才能感覺壞掉。
MP4 路徑使用 -preset veryfast 在 CRF 23 與 yuv420p, 加 -movflags +faststart，它將索引移到文件的前面，以便在下載時播放，而不僅僅是之後。
出口將有多大，需要多長時間？
從解析度可以預測大小。 時間是無法預測的。
因為匯出總是重新編碼，所以原始檔案的大小告訴你結果很少。 顯示的估計來自輸出高度：1080p 時約為 5 Mbps，720p 為 2.5，低於該值 1.2，WebM 降落約 MP4 數字的 70%，音訊增加了 128 kbps，除非靜音。
這是一個估計，並被標記為一個，因為內容比任何公式都重要。 靜態面試和手持平底鍋以相同的分辨率和相同的 CRF 相差數倍，因為 CRF 的目標是品質水平並花費任何需要的比率。
時間取決於您的機器、解析度、剪輯數量以及標籤是否有其他事情要做。 原生 FFMPEG 在 0.63 秒內運行超過 11 秒的輸出；預計瀏覽器會慢幾倍，並預期 WebM 會再次變慢。
這不做什麼?
它連接、修剪、重新排序、縮放、更改速度和刪除音訊。 這是整個功能集，它與視訊編輯器之間的差距值得清楚。
沒有過渡，沒有標題，沒有音樂曲目，沒有色彩校正，沒有裁剪，沒有每個剪輯的音量，沒有關鍵框架的任何東西，沒有完成的時間線的預覽。 每個剪輯都被修剪和放置，一組輸出設定適用於所有這些設定，並對結果進行編碼。
這涵蓋了一個真實且常見的工作：需要成為一個文件的幾個錄音，以正確的順序修剪到有用的部分，以某種大小的東西將接受。 對於任何涉及創意決定的事情，請使用編輯。
剪輯的順序是什麼，你能改變嗎？
您添加它們的順序，是的，每個剪輯上都有向上和向下的按鈕。
重新排序是清單操作而不是視訊操作：移動剪輯會更改它在過濾器圖中佔用的輸入索引，並且在匯出運行之前沒有重新讀取或重新編碼。 因此，無論檔案有多大，一個動作都是即時的，您可以免費重新排列時間線多次。
按鈕而不是拖放是最多八項清單的深思熟慮的選擇。 每個都帶有一個標籤，命名它移動的剪輯，因此該順序可通過鍵盤更改並可由螢幕閱讀器閱讀，而拖曳手柄在沒有大量額外工作的情況下都不會為您提供。
匯出前值得檢查的是序列的方向。 同一事件的幾個錄音通常按字母順序從檔案採摘者到達，這是相機的檔案名稱碰巧產生的順序，而不是總是製作錄音的順序。
為什麼它在瀏覽器中運行？
因為這段影片通常是你不願意上傳的那種，而且工作不需要伺服器。
這裡的每個操作都是 ffmpeg 和 ffmpeg 編譯到 WebAssembly。 檔案從您的磁碟讀取到標籤中，在那裡解碼，在那裡連接，在那裡編碼，然後作為下載傳回。 沒有上傳，沒有隊列可以容納您的鏡頭，也沒有您無法控制的機器上沒有副本。
人們加入的剪輯包括訪談、諮詢、家庭錄音、內部軟體的螢幕截圖、禁運下的草稿。 通常的替代方案將數百兆位元組上傳到免費服務，將其轉換為您一無所知的硬體，並將其保留在無人閱讀的術語下。
成本是八個夾子和三十分鐘的天花板，以及比桌上型電腦慢的編碼。 兩者都在你開始之前說明，這是值得從事的交易。
