持續每秒下載24張1920X1080的圖片幀，在線電影是怎麼做到的？

01-04

因為我想要是作為圖片格式，或者是壓縮包吧，持續每秒下載25張1920X1080的圖片，目前還沒看到這個速度。

流媒體有關的我不懂就不多說了。談一下光視頻來說最基礎的東西。

一方面是，視頻幀內與圖片不同，包括單幀的清晰度以及幀內的相關性，圖像單幀的一般壓縮率和圖片常用編碼方式的壓縮率已經不同了。

另一方面，視頻的相鄰幀一般是有相關性的，因此可以只對關鍵幀進行完整的傳輸，兩個關鍵幀之間的幀通過幀間預測等方式得到和關鍵幀的差值然後計算出來，從而在圖像質量接近的前提下大大提高過渡幀的壓縮率。

當然以上只是最基礎的部分，實際的編碼方式會有不少差異，比如h.264是IPB三種幀之類的。

你的問題前提就已經錯了……………………因為它實際上既不是傳輸24張圖片，也不是傳輸壓縮包，它傳輸的是經過視頻編碼的一段碼流………………然後再在你的瀏覽器上合成渲染出來的………………

那24幀里大部分像素都是一樣的，只要傳輸不同的部分就行了。這就是視頻格式的演算法了。網頁視頻傳輸的是視頻格式，不是簡單的每秒24幅圖片

所以才會有紅線追白線這回事，也就是緩衝，當你的上網速度快到一定境界，比如8M光纖啥的你就會發覺其實不存在這種瓶頸，況且每張1920*1080的圖像包含的信息量是不一樣的，高光死白暗部死黑其實都沒啥圖像信息…

實際上採用i7 處理器固態硬碟多網線連接就可以到達400MB/s的下載速度，折算帶寬為3Gb。商用網路有10Gb以上的帶寬的，的確能實現圖片以24幀傳輸的視頻

首先是損失信息更多的有損壓縮，其次是用傳差量而不是完整圖像的方式傳輸（所以那種嚴重損壞的視頻會突然某一幀開始花屏，看直播的時候複雜畫面會特別模糊），最後壓縮包只是一種打包收據的方式，實際的流媒體當然是用「流」傳輸。

視頻是靠演算法補足的，不是你說的24全幀圖片。

rmvb之所以日落西山，就是因為演算法不好，導致圖像質量有極限，性價比也很低。

靠圖像壓縮與視頻壓縮，它們一般都是有損壓縮，這跟常見的RAR,ZIP文件壓縮的原理不同，壓縮率更大，利用了圖像、視頻的一些特定規律。

視頻兩幀之間的差別一般來說不大，視頻編碼器在一段時間內選一幀或者多幀作為參考幀，其他幀只保存與它的殘差，殘差可以被很輕易的壓縮到很小的大小，因為只要參考幀選擇得當，相減出來會有大片大片的0。怎麼選擇參考幀是各個編碼器具體實現的事情。參考幀一般則用類似jpeg一樣的圖像有損壓縮方法壓縮，有時1-2s才會有1幀。圖像有損壓縮利用的是人對亮度敏感對色度不敏感、對大的區域敏感小細節不敏感來進行壓縮（聽上去跟廢話一樣……:-D）

為了應對畫面中有物體運動的情況（上一個畫面在這裡，下一個畫面就跑到別的地方去，原位相減並不對），當前被壓縮的幀可能會被分割成若干個塊，然後以這個塊的對應位置為中心劃一個搜索範圍，在參考幀上尋找最匹配的區域（也就是相減之後剩下最少東西的區域）

所以這就解釋了為什麼看在線電影的時候數據丟失會導致畫面花了一部分，而且是一塊一塊的，但有一部分還在動並且不是馬上恢復，慢慢的正常畫面塊越來越多，最後duang的一下恢復了（因為收到了一個參考幀）。

這都是一些最基本的方法，除此之外，各個視頻編碼標準還絞盡腦汁想了各種方法盡量利用視頻畫面之間的這種相關性增大壓縮率。

上面只是一個粗略的描述，我也有段時間沒有從事視頻解碼的開發工作了，有寫錯的地方歡迎指正

補充：

關於提高壓縮率方面，「每秒下載24張」這個前提都可能是錯的。例如電影最後結尾的演員表場景，故事轉場的全黑場景，壓根就不需要一秒24張。有的視頻壓縮標準與編碼器支持可變幀率的壓縮方法，有些片段是每秒24張播放，放著放著突然變成每秒15張了，過一會兒又回復每秒24張。這種碼流常常讓做解碼器、播放器的開發人員苦不堪言對應mp3音頻壓縮也有類似的技術叫VBR。

更喪心病狂的是還有這樣的場景，想像一下一個類似超級瑪麗的場景，人物在一個背景上動，背景長時間都會是不動的或者只是簡單平移。新聞演播室也是這樣的場景，針對這樣的場景，可以告訴編碼器我這畫面就是兩個「圖層」，後面那層都一樣，前面就一小塊東西在動而已。傳一張背景，剩下時候就傳那幾個在動的小東西就行了。聽起來匪夷所思，但確實是有的視頻編碼標準考慮支持的。所幸真實環境下遇到的不多。

首先將原始圖壓縮為264或者265等，然後採用專用的視頻或者複合流進行封包發送例如ps流，rtp流等。一般一張200w的圖，在壓縮為P幀後只需要100k到200k就能保持比較高的清晰度，I幀多佔一部分流量。但是一般I幀間隔都可以提到25或者50，甚至200。所以需要的帶寬並不大