絕多數情況下，我們使用這項技術的主要目的是進行檔案格式的轉換與編碼的調整。這些操作通常是為了使影音檔案能夠符合各種不同工具和平台的技術規範與要求。透過適當的轉檔與編碼設定，我們可以確保檔案在不同系統和應用程式中都能夠正常播放和使用，同時也能維持理想的影音品質。
素材取用
影片：雲端下載 ＜影片來源 – Bad Apple by あにら | ニコニコ ＞
實作過程
轉檔
最為常用的使用方式，莫過於檔案格式間的轉換，如果有詳細看過上回的參考 [3]，各位肯定會發現編碼與檔案格式間也有相互依賴性，但基本上 FFmpeg 都會幫我們處理這塊。
ffmpeg -i test.mp4 test_converted.mkv
pause我們可以在 Terminal 直接執行第一行的指令，此時畫面應該會跳出一堆的文字，並且最末端有數字不斷地跳動。而上方的就是輸入的資訊，下方則是處理進度。
透過這串指令，我們就能將目錄內原始的 .mp4 直接變成 .mkv 規格。完成工作後，則會顯示出輸出過程的資料，此時如過透過 -i 查詢輸出的結果，可以發現與原始的資料可能有些差異，這是因為不同的包裝格式 (Container) 通常有不同的資料儲存方式，因此可能會有 Metadata 遺失的問題。
關於這個工具，筆者自己的第一次使用則是研究 Python 的 YouTube 下載器，將原始的 .mp4 轉換成純音檔的 .mp3，畢竟音樂這類東西基本就是用聽的。
轉編碼
我們上次提到，不同的編碼模式有不同的處理範圍，還有壓縮功率。所以我們這邊就用我們檔案的 h.264 與 h.265 來做個比對。
ffmpeg -i test.mp4 -c:v libx265 -c:a copy -b:v 134k test_transcoded.mp4
pause這邊突然多了許多的參數，簡單的介紹一下。 -c 指的是 codec。針對影片 (v)，後面 libx265 則是呼叫 h.265 的 Encoder。針對音訊 (a)，後面的 copy 代表維持原樣。然後 -b 則是位元速率，我們用動態平均的方式維持原始的 134 kbps 的資訊量。
由於這項工作同樣需要 Decode 與 Encode，時間也會稍長一些。當完成後，我們能看到提示說編譯了多少的內容，而不像先前轉檔那樣涉及許多的變化。
這個時候我們可能會發現 h.265 的沒有封面圖，因為預設情況沒有 HEVC 的解譯器，但我覺得比起安裝一堆來路不明的工具，不如我們後續再靠 FFmpeg 生成封面，未來再裁切圖片之後會再銜接介紹。
接著我們看到檔案大小，約從原始的 7.08 MB 變成 7.04 MB，實際是有縮小的，而按照理論的話則是可以達到 50% 的壓縮效率。
後話
在處理影音檔案的過程中，如果我們仔細觀察，會發現系統提供了畫格數量 (Frames) 的資訊。這些資訊不僅反映了影片的基本特性，還能幫助我們更好地理解影片的結構和組成。透過對這些數據的分析，我們可以更準確地掌握影片的時間軸和內容分布。在下一個章節中，我們將深入探討畫格與切割之間的密切關係，並且說明如何運用這些知識來實現更精確的影片處理。
參考
[1] Transcoding — FFmpeg
https://ffmpeg.org/ffmpeg.html#Trancoding
[2] Transcoding Guide — Nvidia
https://developer.nvidia.com/blog/nvidia-ffmpeg-transcoding-guide/