我想大家都能看到明顯的「方塊化」了……

為了解決這個問題，一般會在解碼器里設計一個「環路濾波」的過程，靠這個過程把塊與塊之間的邊緣「軟化」掉…從而得到一個看起來還說得過去的圖像。

另一方面，比如「奔跑的人」、比如「疾馳的列車」…其中的很多部分是可以用其它部分來表示的…

為了這個，人們還提出了所謂「運動估計」的方式。把圖像分割成一個又一個小「塊」，之後用一個塊去表示另一個相近的塊。然後，只要用很小的代價去表示它們之間的差值就可以啦！

為了方便，畢竟我們一般只考慮附近的塊嘛，所以直接把附近的有可能被「引用」的塊排一下順序，記下來用第幾個就好了…

啊，說了這麼多廢話，到現在，我們的所謂「視頻文件」還是一大攤圖表（指DCT結果）以及箭頭（指運動向量）。

那麼，我們還要想一個辦法，把它展開成一長串的01流。

只是展開當然是容易的——從左到右、從上到下、每個塊開頭說一下運動向量——問題是，人力有窮，為了能夠更快地敲完這個視頻，我們還需要進行更進一步的壓縮。

比如說，基於算術編碼的壓縮方案——或者如果說點更廣為人知的東西來類比的話——Huffman編碼，這玩意現在已經普及到在推理遊戲里出現了（逃

雖然我不太清楚人腦計算算術編碼（以及維護上下文）的可行性，但是姑且認為「大神」自然是有這個能力的。

那麼，該如何把一個DCT塊展開成一個位元組流呢？又如何把若干個DCT塊組成的圖像展開呢？又如何把若干個圖像組成的序列展開？最後，如何讓它成為一個可以播放的視頻呢？

對於DCT塊，為了讓壓縮更加有效，我們往往希望其中的值分布的不那麼「均勻」。

換句話說，我們希望高頻部分（較小）和低頻部分可以被區分開。因此，我們往往採用一種類似Z形的順序依次編碼這些值。

而每一幀，本質上也是按照約定好的格式和順序，編碼一些基本信息和算術編碼需要的東西…剩下的就是還原這些DCT塊需要用到的內容了…（具體的Block格式什麼的就要看用的是什麼編碼方案了倒是…實際上我這裡說的幀格式也並不怎麼普適……

然後把這些幀按順序連起來，在開頭（以及，有的時候，結尾）添加上一些視頻的「容器」所需要的信息。

這些信息往往是整個視頻的一些關鍵信息…比如視頻的元信息、比如需要使用的解碼器之類的…

「老師，我知道怎麼把視頻轉換成位元組流了！」我高高地舉起手，向老師示意。

「那個內容剛才就已經講完了啊」老師看了看我，「不是告訴你們用ffmpeg了嗎…」

這是個數字信息科學的問題。

我們常說的數字化是因應人的識別能力有限，以及呈現設備能力等原因。把無限的信息，通過採樣、量化等手段壓縮起來，變成有限信息。

譬如說，自然界有千變萬化的顏色，但是，反正你都辨別不了 ，數字化過程中，就可以只取2^24種，成為真色彩（當然有很多種色彩模型，不展開了），因此我們需要一個24位的空間（就是24個0或者1）來存放顏色，這是編碼過程。最後為了能正確呈現，我們就要有一個約定，哪個數字代表哪種顏色，需要跟編碼一致，這就是解碼過程。

同樣的一個數字，既可以代表一個顏色，也可以代表一個字元，也可以代表一個音頻採樣。怎麼來解讀一串數字，關鍵就是靠約定 。