在正式使用 FFmpeg 工具前，我認為有必要先建立穩固的基礎概念，這樣能夠確保我們在後續操作時更加得心應手。為了達到這個目標，我們將從影音內容的主要資訊著手，仔細探討這些基本要素。通過系統性的了解，掌握這些資訊之間的相互關係和連動性，同時注意每個環節可能存在的特殊情況和需要特別留意的事項。
影視
1. 長寬 Height n’ Width
影片的長寬，通常跟解析度 (Resolution) 牽涉在一塊兒。控制畫面比例 (Ratio) 之外，也代表這個畫布上能用多少的像素點來呈現資料，越大也代表能做更精細。
2. 幀數 Frame Rate
幀數代表在一秒內有多少影格，最易懂的單位是 Frame Per Second (FPS)，但也能使用 Hz 來表示。等時間內影格越多，代表之間的差異越短，肉眼就會覺得越流暢。所以認識玩遊戲的朋友，尤其玩 First Person Shooter (也簡稱 FPS) 可能都會聽到要 240 Hz 螢幕，來增加自己的遊玩優勢。
但單純的撥放影片，我們需要如此高的幀率嗎？研究的普遍說法認為，60 FPS 以上其實人類就感受不到太多的差異，甚至為了專注一些細節而忽略不重要的部分。所以常見到的錄影 FPS 為 30 跟 60，雖然理論上影格越多，貌似代表圖片檔案越多，但完全不會改變檔案大小。
3. 位元速率 Bit Rate
真正的檔案大小來自於 Bit Rate x Duration，常見單位是 kbps，但隨著畫質的進展，也開始不少 Mbps 的出現。而先前的寬高跟幀數都不影響檔案大小，卻是計算位元速率的指標。可以想像成在一秒內需要多少的資料來呈現畫面，如果太少你的畫面可能出現粉刺，太多反而可能產生晃動。那這個又該如何設置才是最好的呢？這邊建議看過就好，不如上網找個固定數值就好。
為什麼說網路上查詢就好，或者根據自己的習慣 (像我是用串流的低標準)，因為這部分跟影片的編碼格式也有很大的關聯。在理論上的開端我們需要如此計算。
Bitrate = (Width × Height) × Colour Depth × FPS
我們事先計算畫布大小，若 4K 影片以 3840 x 2160 來計算有 8,294,400 的空位，採用 8bit 色彩深度還有 RGB 的 x3 個圖層，換算一下我們拿到 23.7 Mb，此時再乘上 30 FPS 我們的數字就爆表為 5.97 Gbps。但是根據 Adobe 的 [2] 這篇文章，我們看到 Low Frame Rate 其實只要大概 44 ~ 56 Mbps。這是因為如 H.265 編碼的壓縮過程，由於畫布很大，我們可能用 64×64 來切塊處理，然後再偷偷地減少關鍵幀，偷工減料之下就省很多。
所以說，不要記。但我還是特別拉出底層概念，來闡述目前三個屬性的相互關係。
4. 編碼 Codec
剛剛我們有介紹到比較新的 H.265 (.mp4)，但在其之前還有 H.264 (.mp4) 跟 H.263 (.3gp)。再來還有由 Google 維護的 VP8 與 VP9 (.webm)，開始支援極大的影片面積。作為後繼者的 AV1 橫空而出，除了面積之外還強調更細節的顏色深度。
音訊
1. 聲道 Channel
從發明留聲機開始，衍生出越來越多的錄音方式，都持續維持著單聲道 (Mono) 到 1931，但直到 1960 技術成熟後，模擬左右雙耳的立體聲 (Stereo) 才開始普及。後面我們總覺得不夠立體，所以增加一堆喇叭分散方向，組成四聲道 (Quadraphonic) 還有 5.1, 6.1, 7.1, 22.2 環繞音效。
但當然，普遍居家使用為立體聲道，尤其各式各樣的耳機。現在很多親民的藍芽耳機可能都強調環繞音效，但其實是透過數位轉換的方式，去打亂原始音效用以模擬空間感。
2. 位元速率 Bit Rate
同理於影片的傳輸，但有兩組數字可以記一下，包括 256 與 320 kbps，這兩個是 AAC 編碼最上層的兩筆數值。而如果你有買過 Hi-Res 音樂就會發現資訊量普遍高於這個數值，如 FLAC 從 1000 – 5000 kbps 都有可能，而 DSD 則跨躍到約 2.8 Mbps。這個時候問題又來了，資訊量越高代表音質越好？在相同編碼的情況下確實如此，但也無法超出編碼的規格上限。
3. 編碼 Codec
音訊的編碼可以簡便利用 Analog 與 Digital 分別代表 無損 與 有損，而只要有混和到 Analog 就也算是無損，包含如 FLAC 與 DSD 這兩個常見的 Hi-Res 格式。
＃有損
- AAC
這是最為廣泛接受的技術之一，其作為 MP3 的後繼者，支援 48 個最高至 96 kHz 的全頻寬聲道，加上 16 個 120 Hz 的低頻聲道。主要副檔名為 .aac / .mp4 / .m4a。
＃無損
- PCM
將類比轉換為數位的方式，依照訊號強度間距分段，還有進階形成 LPCM 即 .wav 所使用的規格。雖然學理上或多或少還是有些誤差，但在演算法的加持下誤差很小而被認作無損。這就像是許多的電子零件牽涉到 ADC 與 DAC 交換器的轉變。
- FLAC
FLAC 編碼由 PCM 做為底層來源，並經過壓縮，但是由於疊加的關係其 Bit Rate 維持較高，也有自己的對應容器 .flac 來封裝。
- DSD
其錄製與聆聽條件相對苛刻許多，因此實際上並不普及。其用 1 bit 來表達所有的音訊，因此一般認為比 PCM 好，但其位元速率通常高達 2.8 Mbps 之高。
後話
這些設定幾乎都有所謂的大眾口味，但每個人的觀感並非相同。比如筆者本人就喜歡 30 FPS 用來減少 Bit Rate 需求來縮減大小，畢竟早期 Windows XP 時代玩遊戲 15 FPS 可是家常便飯，但同時也展現出科技的不斷更迭。
接者在了解以上主要資訊的基礎上，我們將透過 FFmpeg 的操作來深入探討這些話題。歡迎各位按照自己感興趣的議題選讀，我們下次再會啦！
參考
[1] 人眼的更新頻率 — National Institutes of Health
https://pmc.ncbi.nlm.nih.gov/articles/PMC4314649/
[2] What is Bitrate — Adobe
https://www.adobe.com/creativecloud/video/discover/bit-rate.html#
[3] Video Codecs — MDN Web Docs
https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Video_codecs#common_codecs
[4] Audio Codecs — MDN Web Docs
https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Audio_codecs#common_codecs
額外閱讀
[1] Per-Title Encode Optimization — Netflex TechBlog
https://netflixtechblog.com/per-title-encode-optimization-7e99442b62a2
[2] What is Per-Title Encoding — IO River
https://www.ioriver.io/terms/per-title-encoding