CAST-深刻理解并減少視頻壓縮系統(tǒng)的延遲

在視頻的世界，延時是一幀被捕獲的時刻和該幀顯示時刻之間的時間間隔。對于任何其中有與視頻內(nèi)容的實時交互的系統(tǒng)，如視頻會議或無人駕駛試點, 低延遲都是其一個重要的設(shè)計目標。

但“低延遲”的含義有所不同，實現(xiàn)低延時的方法并不總是顯而易見的。

在這里，我們將定義和解釋視頻延遲的基本知識，并重點討論視頻編碼方式的選擇對延時的重要影響。

視頻系統(tǒng)延遲特性

要使得照相機捕獲的像素在視頻顯示器上可視，需要有幾個階段的處理。這些處理步驟每個都會引起延遲，以及用于發(fā)送壓縮視頻流所需要的時間，一起產(chǎn)生了總延遲，有時也被稱為端至端的延遲。

延時在口頭上常用時間單位來表達，例如，秒或毫秒（ms） 。

但是，視頻延遲最大的貢獻者是需要暫時緩存的數(shù)據(jù)，。正因為如此，視頻系統(tǒng)工程師往往用緩沖的視頻數(shù)據(jù)來計量延遲，例如，兩幀或8個水平線的延遲。

把幀轉(zhuǎn)換成時間取決于該視頻的幀速率。例如，一個30幀每秒（fps）的視頻一幀的延遲等于三十分之一秒（ 33.3ms ）的延遲。

圖1：代表1080p30視頻流的延遲

將視頻線轉(zhuǎn)換成時間需要幀速率和幀大小或分辨率。 720p的高清視頻幀有720行水平線，所以延遲一行30fps的是1 /（30 * 720 ）= 0.046ms的延遲。 而1080@ 30fps的，同樣的一行延時需要一個非常短的0.030ms 。

關(guān)于何為低延時,沒有一個絕對值。相反，被認為是可以接受的低延遲會因應(yīng)用不同而變化。

當人類進行實時視頻會議或玩游戲時，延遲低于100ms的被認為是低，因為大多數(shù)人察覺不到這么小的延遲。但在一臺機器與視頻交互的應(yīng)用中,常見于許多汽車,工業(yè)和醫(yī)療系統(tǒng)，然后延遲要求要低得多： 30毫秒， 10毫秒，即使是在一毫秒，這取決于系統(tǒng)的要求。

您還將看到這個詞適用于視頻處理功能和IP內(nèi)核的超低延遲。這是一個營銷的描述不是一個技術(shù)性的定義，是的，它只是意味著對于給定應(yīng)用“真的，真的低延遲” 。

因為在今天的互聯(lián)而可視的世界，這是司空見慣的。讓我們來看看從相機（或服務(wù)器）的視頻流通過網(wǎng)絡(luò)到達顯示的系統(tǒng)中的延遲。

正如大多數(shù)系統(tǒng)的設(shè)計目標，實現(xiàn)適當?shù)牡脱舆t的流媒體系統(tǒng)設(shè)計需要權(quán)衡硬件，處理速度，傳輸速度和視頻質(zhì)量的最佳平衡。正如前面所提到的，任何視頻數(shù)據(jù)（未壓縮或壓縮的）的臨時存儲增加了延遲，因此降低緩沖是一個很好的首要目標。

緩沖視頻的大小取決于處理所需要的最少數(shù)據(jù)。需要緩沖的數(shù)據(jù)的量可以從幾像素到幾條視頻線，或者甚至整個幀。理解系統(tǒng)設(shè)計最大可容忍的延遲，我們可以很容易地計算出系統(tǒng)中所需緩存的大小，從而在做預(yù)算及優(yōu)化延遲時推算出像素，線，或幀的水準。

例如，對于使用1080p30的視頻流媒體系統(tǒng)，我們?nèi)祟惸恳暱山邮艿淖畲笱舆t為100ms，我們從而可以計算通過處理管道的最大允許緩沖如下：

100毫秒/每幀33.3ms = 3幀，或

1080行，每3幀幀x = 3240行，或

每行1920像素× 3240線=620萬像素

在這個場景中，我們可以看到，對硬件JPEG編碼器的延遲的擔(dān)心（通常只有幾千像素）是無關(guān)緊要的，因為它太小無法對終端到終端的延遲產(chǎn)生任何重大的影響。相反，人們應(yīng)該專注于需要整個幀或大量視頻線緩沖的系統(tǒng)節(jié)點。

每個設(shè)計關(guān)注點所獲得的代表性結(jié)果如表1所示，這從一個精心設(shè)計的“低延遲”視頻流媒體系統(tǒng)的各個階段提供了該延遲的分布。這里所有不必要的幀級緩沖已被忽略，整個過程使用硬件編解碼器（因為通常軟件編解碼具有更高的延遲，由于涉及到從OS來的內(nèi)存傳輸和任務(wù)級別的管理）。

Processing Stage

Buffering

Latency

(1080p30)

CapturePost-Processing

(e.g., Bayer filter, chroma resampling)

A few lines (e.g.8)

< 0.50ms

Video Compression

(e.g. Motion-JPEG,MPEG-1/2/4 or H.264 with single-pass bitrate regulation)

8 lines forconversion from raster scan

A few thousandpixels on the encoder pipeline

0.25ms

<< 0.10ms

Network Processing

(e.g. RTP/UDP/IP encapsulation)

A few Kbytes

< 0.01ms

Decoder StreamBuffer

From a number offrames (e.g. more than 30) to

sub-frame (e.g. 1/2 frame)

from 16ms

to 1sec

Video Decompression

(JPEG, MPEG-1/2/4, or H.264)

8 lines forconversion from raster scan

A few thousand ofpixels on the decoder pipeline

0.25ms

<< 0.10ms

DisplayPre-Processing

(e.g. Scaling, Chroma Resampling)

A few lines (e.g.8)

< 0.50ms

表1, 一個低延遲1080p30的視頻流系統(tǒng)的延遲分布。

由于大多數(shù)視頻流應(yīng)用中，占主導(dǎo)地位的剩余延遲貢獻者是解碼器流緩沖區(qū)（DSB）。接下來我們將看看這是什么，為什么我們需要，我們?nèi)绾尾拍茏顑?yōu)地減少它引入的延遲。

在表1的例子中，我們看到DSB可能增加從16ms到1秒的延遲。這種范圍依賴于視頻流的比特率屬性。我們可以控制什么樣的屬性，以保持此范圍的低端DSB延遲？

視頻流系統(tǒng)的帶寬限制，通常需要調(diào)節(jié)傳輸比特率。 720p30視頻流例如，可能需要以不超過每秒10兆比特（Mbps）速率被壓縮以通過一個速率限制在10Mbps的傳輸通道。[!--empirenews.page--]

可以合理地假設(shè)通過比特率調(diào)控后， 產(chǎn)生在每一個時間點是恒定的傳輸比特率，例如，每幀都是同樣的10Mbps的速率。但是，這是不正確的，這就是為什么我們需要流的解碼器的緩沖。讓我們來看看視頻壓縮比特率調(diào)控如何運作。

視頻壓縮減少了視頻數(shù)據(jù)的大小，通過使用較少的位來表示相同的視頻內(nèi)容。然而，并非所有類型的視頻內(nèi)容是同樣容易接受壓縮。在一個給定的幀，例如，平坦的背景部分的圖像可以有較少的比特比需要的更詳細的前景部分表示。以類似的方式，高速運動的序列比那些與中度或沒有運動需要更多的比特。

其結(jié)果是，壓縮天然會產(chǎn)生可變比特率（VBR）的數(shù)據(jù)流。隨著比特率調(diào)節(jié)（或比特率控制） ，我們強制壓縮產(chǎn)生相同數(shù)量的數(shù)據(jù)流在相等的時間內(nèi)（例如，每10幀，或每3秒的間隔） 。我們稱這種恒定比特率（CBR）視頻。它以犧牲視頻質(zhì)量為代價，因為我們實際上是要求壓縮引擎分配比特基于時間而不是基于圖像本身。

用于定義恒定比特率的平均周期也有著重大的影響，對視頻質(zhì)量。例如， “ 10Mbps” ，可以對應(yīng)CBR流一個大小為10Mbits每秒，或5Mbits每半秒，或100Mbits的每10秒。進一步重要的是要注意，在該平均周期之內(nèi)的位速率波動。舉例來說，我們可能會平均50Mbps的每5秒，但是，這可能意味著40Mbps的在前兩秒和10Mbps 在其余3秒。

正如限定比特率會影響質(zhì)量，限制平均周期長度也會影響質(zhì)量，相對越小的平均周期對應(yīng)越低的傳輸視頻質(zhì)量。