H.264實時流如何實際壓縮和傳輸？

Question

這是一個概念性問題，而不是技術問題。我對H.264的理解是，它依靠過去和未來的幀來壓縮視頻數據。對於採用完全壓縮的H.264視頻文件並通過RTP或您選擇的任何其他協議進行流式處理，這很簡單，但是，這對於實時視頻將如何工作？在實時視頻中，您只能訪問過去和當前幀，並且不知道視頻的全部長度，那麼H.264編解碼器如何實際壓縮視頻並將其準備爲RTP負載？它是否簡單地將視頻緩衝並分塊爲一個任意大小的視頻並壓縮它？我能想到這個工作的唯一方法是將視頻分割成1秒的塊，將它們壓縮成單獨的視頻，並將它們作爲RTP負載。這是如何完成的，還是比我懷疑的更多的「魔術」發生？

Answer 1

首先，有三種類型的框架。

I（幀內）幀或關鍵幀。這些幀不參考任何其他幀。它們是獨立的，可以在沒有任何其他幀數據的情況下被解碼。像JPEG一樣。

P（預定義）幀。可以參考過去的幀。

B（雙向）可以參考來自過去或未來的幀。

選項1.僅使用I和P幀。這會導致文件大約10-15％（或相同文件大小的質量下降10-15％）。這用於視頻會議和屏幕共享等交互式系統，延遲非常明顯。

選項2，等待未來發生。在每秒30幀的情況下，未來將在33毫秒內完成。

h.264具體只能引用多達16個相鄰幀。然而大多數人把它限制在4左右。所以等待4幀只有大約133毫秒的延遲。