1 回答

TA貢獻1836條經(jīng)驗 獲得超5個贊
故障是因為您可能沒有指定時間戳的關(guān)鍵幀。因為非關(guān)鍵幀編碼與最近關(guān)鍵幀的差異,它們只顯示與前一個關(guān)鍵幀的差異,這就是為什么它們非常有效的內(nèi)存,但不一致。類似的理論也適用于音頻,并且取決于編解碼器/格式!
在核心 moviePY 也使用 ffmpeg 工具,這里是 API 參考的官方頁面,以及底層細節(jié), https://zulko.github.io/moviepy/_modules/moviepy/video/io/ffmpeg_tools.html
使用 mp4 容器可以在非關(guān)鍵幀處剪切而無需使用編輯列表重新編碼(關(guān)于編輯列表的問題)。換句話說,如果 3 秒之前最接近的關(guān)鍵幀在 0 秒,那么它將從 0 秒開始復制視頻,并使用編輯列表告訴播放器不是在 3 秒而是在 0 秒開始播放,因為它最近的關(guān)鍵幀休息幀被丟棄. 這就是有時音頻播放和視頻圖像掛起但時間線繼續(xù)運行的原因。
你做了什么,它不會重新編碼原始的東西!它只是在最近的關(guān)鍵幀處拆分到您指定的開始/結(jié)束時間,并且它們的間隔不相等,因此最終結(jié)果的長度不等。
不要這樣做: 盡管這是最快和最好的 ffmpeg 方式,但我已經(jīng)弄明白了,這就是我假設你的方法正在做的事情:
ffmpeg -ss 00:01:00 -i input.mp4 -to 00:02:00 -c copy output.mp4
但下面的東西會剪切并重新編碼:
ffmpeg -i movie.mp4 -ss 00:00:03 -t 00:00:08 -async 1 cut.mp4
重新編碼時,您可能還希望包含其他編解碼器選項,然后使用此 ::
ffmpeg -ss 00:03:00 -t 00:00:05 -i test.wmv -acodec libmp3lame -vcodec libx264 1.mp4
但是斯瓦米有什么區(qū)別呢?
我們沒有使用 -c 復制參數(shù)。因此不只是轉(zhuǎn)儲原始 I/O 流。但再次重新編碼,需要更多的 CPU 工作!
此外,-t 選項指定持續(xù)時間,而不是結(jié)束時間。上面的命令(第二個代碼片段)將從 3 秒開始對 8 秒的視頻進行編碼。要從 3 秒開始到 8 秒結(jié)束,請使用 -t 5(第三個代碼片段)。
注意:如果您使用的是當前版本的 ffmpeg(我猜是 2015 年以上),您還可以在上面的命令中將 -t 替換為 -to 以在指定時間結(jié)束。
添加回答
舉報