繼上次的結果，我們知道用x264可以達到我們想要的檔案大小，但是，讓剪素材軟體吃進去好不好用這個還不知道。因此，我們就先用上次做出來的例子4丟給Avidemux吃，一丟進去，Avidemux就會跳出警示說有b-frame會造成Crash，但是我們的檔案裡並沒有b-frame，所以不用擔心，按下確定開始編輯吧。
實際上截了幾個片段會發現，為什麼好用的場景切換沒有用呢? 沒有這個的話，裁起來好麻煩啊，會不會是檔案的問題呢? 回去查x264的ultrafast preset的設定後，會發現他有幾個跟場景切換息息相關的參數被改掉了，主要是keyint和secencut這2個參數，因此，我們要在套用了ultrafast之後，再把這兩個參數改回我們要的數值，而這數值該設多少咧? 只要用平常的的預設值就好了，keyint設為250，而scenecut設為40，也就是說，我們的指令會是以下這樣:
ffmpeg -i 00.mp4 -c:v libx264 -qp 0 -preset ultrafast -x264opts keyint=250:scenecut=40 07.mp4
把輸出的檔案再丟進Avidemux/VirtualDub試試看，就會發現場景切換又能用囉!
Reference: Encode/H.264
Written with StackEdit.
因為總是想要剪出來的片畫質能夠好，所以不外乎有幾個要注意的地方:
- 素材檔的好壞
- 剪好的片在Render出來時的設定
本篇就是以第一點為主，做了個小小的測試。不過在開始前，先來說說本篇的動機，現今網路上的RAW檔，為了方便傳輸，有很多都用h.264作為影片的編碼，關於h.264的好處我就不在這裡提了，但是，h.264做為剪片的素材來源，除非利用avisynth把他掛入VirtualDub之類的影片裁切軟體內，不然h.264是相當不利於線性編輯的，除了處理速度慢之外，還有可能會造成軟體Crash，所以，對於有些不能用avisynth的人(ex. 我自己)來說，必定要用其他方式來預先處理(轉檔)，才能繼續接下來的作業。以下就以幾種不同的設定來轉檔，看看哪一個才符合我們的需求。
首先，來源檔為[Leopard-Raws] Hibike! Euphonium - 01 RAW (KBS 1280x720 x264 AAC).mp4，在此將它改名為00.mp4方便輸入，再來會在命令提示字元中調用ffmepg來對00.mp4進行轉檔，出來的檔案結果如下圖所示:
可以看到畫面中的00.mp4原始大小大約為364MB，第1個檔案是用xvid預設轉好玩的，輸入的指令為:
ffmpeg -i 00.mp4 -c:v libxvid -an 01_xvid.avi
打開來看了一下，雖然轉檔速度挺快的，可是這畫質真是慘不忍睹，所以不會是我們要的編碼。再來，第2個檔案是無損壓縮avi，指令為:
ffmpeg -i 00.mp4 -c:v huffyuv -an 02_huffyuv.avi
可以看到檔案大小為20GB，大約是原檔的70倍大，轉檔速度普通，畫質當然是沒問題，可是這實在是有點太大了，我硬碟hold不住啊。再來，下一個檔案是用h.264來壓的。在這裡我要解說一下了，為什麼我要從h.264轉檔為h.264呢? 有差嗎? 答案是有的，差別在於壓縮的設定，通常看到那種明明是720p或是1080p，但是大小卻只有幾百MB的mp4檔肯定是不適合線性剪輯的，但是如果是壓縮率相對小多了的設定呢? 這或許是個選擇，所以輸入以下的指令來轉轉看:
ffmpeg -i 00.mp4 -c:v libx264 -qp 0 -an 03_x264.mp4
轉出來的檔案相對無損壓縮avi小多了，只有2.5GB，轉檔時間快了許多，而且畫質還不錯，這似乎是個好選擇，但是其實x264有更快的preset，所以我們可以在第4個檔案來試試:
ffmpeg -i 00.mp4 -c:v libx264 -qp 0 -preset ultrafast 04_x264_ultrafast.mp4
出來的檔案，很明顯比上一個大上了一圈，但是速度卻快得跟飛一樣，不愧是ultrafast。在x264中用-qp 0這方式轉出來的檔案，看來是不會有b-frame，所以應該能讓影片剪裁軟體處理得順暢得多。接下來我試了一下完全無壓縮的avi檔，指令為:
ffmpeg -i 00.mp4 -c:v rawvideo -an 05_rawvideo.avi
可以看到這檔案比第2個例子足足大上了兩陪之多，居然有46GB，轉檔時間爆炸久，但是CPU使用率卻低到不行，說明這個例子的速度瓶頸並不是在CPU效能上，而是RAM或是硬碟之類的地方。這麼大的檔案，光是要讀進剪輯軟體就是個問題了，所以也不實用。下一個例子是我純屬好奇，用這個超級大檔加上第4個例子的指令轉出來的，可以發現檔案大小居然和第4個例子一模一樣，這也可以說明在第4 個例子中，00.mp4解碼後的視訊流，如果直接存出來不壓成h.264，就會是第5個例子的rawvideo。
結論: 經過了以上的比較，可以得知，在不能使用avisynth的情況下，使用x264的-qp 0 -preset ultrafast應該是比較符合時間和空間上的效益的。至於實際上能否讓軟體順利吃進去，這個就等我有空再試一下吧。
reference: How to create an uncompressed AVI from a series of 1000’s of PNG images using FFMPEG