視訊編碼與封包化
經由IP網路來傳遞即時視訊，因封包遺失為其常態，故應用層(application-layer)的錯誤控制方法常經由聯合來源端與通道編碼方法(joint source-channel coding，JSCC)來加以搭配使用。其中來源端編碼(source coding)與前導錯誤修正(forward error correction，FEC)更是常被加入錯誤控制的設計裡面，用以緩和因封包遺失所帶來的衝擊。不過要在IP網路上保證即時視訊品質有其一定的難度，在處理這些視訊QoS的問題上面，一個通常的作法是應用錯誤控制策略來因應。
不同的錯誤控制策略，其使用的方法(元件)亦可能在不同的網路層級上加以實作，並且可能被放在傳送端或接收端來處理。在傳送端，其可能應用的有錯誤修復(error resilience)來源編碼策略、應用層重傳機制或是混合式的FEC方法；在接收端，其可能應用的策略主要有錯誤隱藏(error concealment)方法。不管是在接收端或傳送端，每一種不同的錯誤控制方法都被用來處理封包遺失的問題。例如：在錯誤回復來源端編碼策略裡面，其執行錯誤控制的方法，是利用在來源端編碼層級裡面加入一些冗餘封包來防止錯誤的擴散，並限制封包遺失所可能導致的失真情形。
常見的錯誤回復技術
在封包交換式的網路裡面，要做到錯誤回復一般有兩種常見技術可供使用。一種是利用封包本身的不同編碼機制來做到錯誤回復的功能，另一種是利用現有的錯誤修正方法來達成錯誤回復功能。在前者，其其錯誤回復的效能與每個封包的編碼模式(encode node)選擇息息相關，例如使用可變視訊編碼或多描述編碼(multiple description coding)方式，也可以達到一部份錯誤回復的效果；除了封包本身的編碼模式選擇來達到錯誤回復功能之外，另一種處理封包遺失的方法，便是在應用層傳送層使用錯誤修正技術(error correction)。
目前這種錯誤修正技術有兩種常見基本型態存在，一種是前導錯誤修正(forward error correction，FEC)方法；另一種是自動重複要求(automatic repeat request，ARQ)方法。兩種方法在其錯誤強固性與網路流量負載(traffic load)上均有其優、缺點。在許多觀念裡，因為這種錯誤回復機制常被放在解碼端使用，所以錯誤回復技術也就常被認為是一種須藉助解碼器所使用之後處理技術，其利用視訊片段在空間與時序上的關聯性，用以掌握封包的遺失狀況。不過在即時串流的應用上面，ARQ比FEC較少被使用，換言的FEC-based的技術在此領域頗受青睞。甚至J. Rosenberg及H. Schulzrinne更是強力主導FEC方法成為IETF錯誤回復的標準規範。然而因FEC本身區塊大小(block size)的限制，其不能完全避開封包遺失的問題。另外，FEC的使用即使在無封包遺失的情況下，亦須付出固定的使用代價，且FEC的適當使用層級必須依據通道行為的精準評估才行。此點相較於ARQ，FEC方法的確有不及之處（因ARQ可以自動適應通道的遺失特徵，並只傳送所遺失的封包及數量），因此在端點對端點的延遲限制無太大要求時，ARQ的方法反而會是不錯的選擇。一個封包式即時視訊傳送系統，以及不同層級所可以使用的錯誤控制元件如圖1。
圖1、一個封包式即時視訊傳送系統，以及不同層級所可以使用的錯誤控制元件。
視訊編碼技術運作
視訊的編碼對於頻寬的節省有重大貢獻，但是其必須倚靠解碼器的高度複雜性運作。以一個輸入的視訊來說，其對移動評估(otion estimation，ME)算法而言是一種主觀性的資料，其必須經過一些處理之後，輸出移動向量(motion vectors，MV)移動補償(otion compensation，MC)時序(temporal)分析才能提供客觀品質建立的實質幫助。如果站在訊號處理的角度來看，移動補償的時序分析區塊的輸出，可視為一種時序上低頻與高頻次頻帶(ubband)集合。以一個由8畫面組成的GOP結構以及畫面的移動向量關係而言。
圖2中，我們顯示了一個由8畫面組成的GOP結構以及畫面的移動向量關係。圖示中最上層所表示的是一全訊框率的視訊畫面，其鄰近的訊框(frames)被分解後產生高頻與低頻頻帶(前者以虛線表示，後者以實線表示)，而圖中的箭頭部分為移動向量(MV)。由圖2可以看見，在經分解鄰近畫面後所產生的頻帶，其中時序低頻對於移動向量得取得是很有幫助的。通常他們的發生速率為視訊訊框率的一半而已，且此過程會不斷重複，直到我們取得GOP內八個畫面的移動向量為止。在上述例子裡面，整個視訊資料有四個時序延伸層(temporal scalability levels)，即是圖2中標示的(1)～(4)。這些不同層級對視訊重建有不同的貢獻，舉例來說，視訊訊框率只有全訊框率的1/8時，那只需第一層視訊資料(level (1))即可重建視訊。相對的如果訊框率達全訊框率的1/4，那視訊的重建就會需要第一層及第二層協力完成。同理，如果視訊訊框率達到全訊框率1/2，那所需要的視訊資料就要更多(即是需第一層、第二層及第三層時序資料)才能重建視訊。
對於已壓縮的視訊位元串流而言，可以依據GOP-based的方式加以封包化。而對一個給定GOP的位元串流而言，其在封包化之前首先會先被重新排列，使得GOP的移動向量可以被排放在位元串流的起始之處，緊接在移動向量之後者，乃已編碼的次頻帶樣本(subband samples)。經過適當排列之後的位元串流，接下來才會被封包化成512-byte左右大小的切割封包。此切割封包中除了含有GOP樣本之外，還涵蓋了4-byte的應用層標頭(application-layer header)，用以表示GOP號碼與GOP內封包序號。在標題後面的負載區(payload)則被用以存放已壓縮的視訊資料，其可存放的空間為508 bytes。換句話說，視訊的頻寬實際可負載率約為99.22%左右(即508/512*100％)。在GOP的運算裡面，其傳送能力等級(即是power level)的決定乃在於其速率失真(rate-distortion)特徵。因為在IP通訊的過程中封包遺失的情形無法完全避免，對即時串流而言，封包的遺失影響程度不一，而對這些封包遺失的修補作法一般有兩種常見的技術可供使用，一種為重新傳送技術(retransmission)，另一種為錯誤回復(error concealment)技術，這些技術我們稍後再做說明。
為了使接收端的封包遺失不致影響服務品質，通常其會採用一些封包錯誤隱藏機制。一個簡單而有效的錯誤隱藏策略，可參考Gallant及Kossentini所提議的方法。在許多現存的錯誤隱藏策略裡面，其使用的是一種空間因果性(causal)方法。解碼器只利用先前收到的封包所提供訊息來隱藏(插補)遺失的封包，例如巨集區塊(MB)的移動向量(MV)的猜測，可由該區塊周邊三個MV來加以評估(即是左上、下及右上)。這種因果性的錯誤隱藏技術亦被廣泛用在數位影像處理領域，例如：例如Bayer RGB模版(Bayer RGB pattern)的色彩資訊遺失，往往也都藉由該遺失像素的空間上周邊像素色彩資訊來加以補償而得。
但除了空間的因果性錯誤隱藏方法之外，亦有另種「時序取代」的錯誤隱藏方式被提出(參見F. Zhai、Y. Zisenberg等人的研究)，這種時序方式的錯誤隱藏方法乃利用前後畫面之間的參考差異，作為遺失補償的依據。在即時視訊上面，單靠空間因果性的錯誤隱藏方法未必能達有效的補償錯誤作用，通常與視訊壓縮效率問題一樣，我們也可能必須往時序方向去考量。一言以蔽之，對即時視訊而言，視訊資料除具有空間關聯性之外，時序方面的高度相似性往往也可能成為非常有潛力的錯誤隱藏方法。另外要注意的是，來源端的封包遺失機率與傳送時的封包遺失機率，此二者之間的關連性乃依據所選用特異性傳送封包化策略而定，二者並非全無關係存在。
一些錯誤回復技術
在一個基於因果性的錯誤控制策略裡，要評估目前的遺失資料，乃必須依據的前的傳送資料而定(即現在遺失資料的插補與的前接收的資料有因果關係)。假設系統嘗試依據PSNR(peak signal-to-noise ratio)去維持一定程度的視訊品質(簡單的客觀視訊品質維持)。在一般情況下，為達此品質目的，我們所需要的參考資料也要有足夠高的品質(在影像處理上，即需要一定大小的迴旋核心存在)。因此為了修復現在遺失的資料，以維持品質不致降低，我們需要先前傳送的資料本身擁有足夠高的品質可供參考。不過，通常我們對於這一點往往無法確認其傳送品質，也無法評估所遺失的資訊對未來視訊品質的影響程度會有多大。因此，這讓此類錯誤控制方式變得沒有效率。
一個直覺式的取代方法，便是我們可以用量的方式取代質的要求。換句話說，我們總是要傳送高品質的資料出去(不管這些資料有沒有在未來被使用到)，一旦有發生傳送的視訊封包遺失的情形，那就有足夠高的品質參考可供修復遺失訊息。但這種作法的缺點，在於整體系統資源的浪費嚴重。這種基於因果錯誤隱藏方式的錯誤控制策略，明顯和那些基於前導錯誤修正(forward error correction，FEC)的策略有著同樣的問題。從另一角度來看，如果應用非因果性的錯誤隱藏方法，那其效果又如何？在此至少和因果錯誤隱藏方式有一個明顯區別，那就是我們不須為了封包遺失的問題，預採某些先行措施來防備。此即是在傳送過程中如果發生封包遺失，其在有必要的下才會改變資料的傳送品質。
由於這種方式不需要預先傳送大量可能不被使用到的高品質封包資料，因此不會加重系統負擔，且在系統資源的使用上面會非常比較有效率。ARQ(Automatic Repeat reQuest)的運作也是基於此概念，它只會在目前傳送資料有發生遺失的情況，才會在將來傳送時把遺失的部分予以重傳。目前為此，這種依時重傳策略目前也是大家公認還蠻有效率的一種方法。只不過，對視訊串流而言，非因果錯誤控制(NCEC)方式有時在能量的使用上，會比ARQ要更有效率(事實上在即時串流應用上，ARQ的使用並不廣，因為它並未考慮到這些應用型態的延遲需求)。一個無線視訊傳送系統概要，如圖3。
在圖3中，一個視訊擷取裝置在擷取視訊完畢之後，這些原始資訊(raw data)會先被影像處理核心處理，然後再經過壓縮後儲存或是傳送。為了方便網路傳送，通常這些已被壓縮後的視訊位元串流(video bitstream)會被存在一個通話區段(session)起始前的一個伺服器中，並且在這些位元串流被傳送前。其會先經過封包化(packetized)處理過程然後才傳送出去。當使用者端收到這些封包化訊息之後，先會經過去封包化過程將這些封包組合起來，並可能具備通知伺服器，其所遺失封包訊息的功能。伺服器便可依據這些訊息回饋資料，以及相關未來視訊資料速率失真(rate distortion)情形，作為其傳送能量(能力)管理(power management)或是建構錯誤控制模組(error control module，EC module)的依據，以及決定其未來這封包所應具備的適當傳送能力。
封包傳送策略
封包傳送策略的選擇與傳送能力的管理，主要目的的一乃在於維持一定的服務品質，而伺服端為達更精確的品質控制，往往需要接收端回饋一些封包接受的訊息，或者需要在接收端建立一些緩衝區(buffer)以儲存一些視訊資料，用以提供未來視訊的顯示或解碼的用。在一般視訊串流得應用裡面，利用接收端緩衝區來預存未來幾秒視訊資料的作法，是司空見慣的一種現象。為了簡化說明起見，我們假設接收端的緩衝區大小為2個GOPs容量(即可存GOPi-1與GOPi資料)。此意味著，在傳送GOPi的情況下，我們只會關心GOPi-1的正確性。對一個有8個畫面的GOP大小，其訊框率為每秒30格(30 fps)的視訊而言，接收端(有兩個GOP大小的buffers)所需要的緩衝區空間配置約為0.53秒的視訊資料(此緩衝區大小可自由假設)。假設GOPi-1已經傳送給接收端，而用以報告GOPi-1封包遺失的回饋封包負載區，乃由Mi-1個位元所組成，其中有個位元n為旗標位元，主要用以表示所接受GOPi-1封包中的第n個封包。此值不是0便是1，0表示GOPi-1中的第n個封包並沒被接收，接收端沒有對此封包解碼；如果為1，則表示該封包以被接收並可順利解碼。傳送者可根據此旗標位元的狀態來得知某個封包的遺失情形，並採取適當的補救措施。這種回饋封包會在每個GOP傳送時間順序區隔(time slot)結束後，由接收端傳回給伺服端作為下次品質改進或傳送能量調整依據(例如：在無線傳輸情況)。因此傳送者在下一波GOP開始傳送的前，依據回饋模式的選擇，可能在收到接收端的回饋訊息之後，才會傳送下一波GOP資料，但以可能在接收回饋訊息的前已先傳送所需的一些GOP封包出去。
當GOPi-1的封包全部傳送完畢之後，接收端會產生一個回饋訊息傳送者(伺服端)，在該回饋訊息中將涵蓋剛剛傳送GOPi-1時，其封包遺失情況。依據系統設計差異，該回饋訊息可以設定在下一個GOPi傳出的前取得或是在傳送下一波GOP的中取得。
經由IP網路來傳遞即時視訊，因封包遺失為其常態，故應用層(application-layer)的錯誤控制方法常經由聯合來源端與通道編碼方法(joint source-channel coding，JSCC)來加以搭配使用。其中來源端編碼(source coding)與前導錯誤修正(forward error correction，FEC)更是常被加入錯誤控制的設計裡面，用以緩和因封包遺失所帶來的衝擊。不過要在IP網路上保證即時視訊品質有其一定的難度，在處理這些視訊QoS的問題上面，一個通常的作法是應用錯誤控制策略來因應。
不同的錯誤控制策略，其使用的方法(元件)亦可能在不同的網路層級上加以實作，並且可能被放在傳送端或接收端來處理。在傳送端，其可能應用的有錯誤修復(error resilience)來源編碼策略、應用層重傳機制或是混合式的FEC方法；在接收端，其可能應用的策略主要有錯誤隱藏(error concealment)方法。不管是在接收端或傳送端，每一種不同的錯誤控制方法都被用來處理封包遺失的問題。例如：在錯誤回復來源端編碼策略裡面，其執行錯誤控制的方法，是利用在來源端編碼層級裡面加入一些冗餘封包來防止錯誤的擴散，並限制封包遺失所可能導致的失真情形。
常見的錯誤回復技術
在封包交換式的網路裡面，要做到錯誤回復一般有兩種常見技術可供使用。一種是利用封包本身的不同編碼機制來做到錯誤回復的功能，另一種是利用現有的錯誤修正方法來達成錯誤回復功能。在前者，其其錯誤回復的效能與每個封包的編碼模式(encode node)選擇息息相關，例如使用可變視訊編碼或多描述編碼(multiple description coding)方式，也可以達到一部份錯誤回復的效果；除了封包本身的編碼模式選擇來達到錯誤回復功能之外，另一種處理封包遺失的方法，便是在應用層傳送層使用錯誤修正技術(error correction)。
目前這種錯誤修正技術有兩種常見基本型態存在，一種是前導錯誤修正(forward error correction，FEC)方法；另一種是自動重複要求(automatic repeat request，ARQ)方法。兩種方法在其錯誤強固性與網路流量負載(traffic load)上均有其優、缺點。在許多觀念裡，因為這種錯誤回復機制常被放在解碼端使用，所以錯誤回復技術也就常被認為是一種須藉助解碼器所使用之後處理技術，其利用視訊片段在空間與時序上的關聯性，用以掌握封包的遺失狀況。不過在即時串流的應用上面，ARQ比FEC較少被使用，換言的FEC-based的技術在此領域頗受青睞。甚至J. Rosenberg及H. Schulzrinne更是強力主導FEC方法成為IETF錯誤回復的標準規範。然而因FEC本身區塊大小(block size)的限制，其不能完全避開封包遺失的問題。另外，FEC的使用即使在無封包遺失的情況下，亦須付出固定的使用代價，且FEC的適當使用層級必須依據通道行為的精準評估才行。此點相較於ARQ，FEC方法的確有不及之處（因ARQ可以自動適應通道的遺失特徵，並只傳送所遺失的封包及數量），因此在端點對端點的延遲限制無太大要求時，ARQ的方法反而會是不錯的選擇。一個封包式即時視訊傳送系統，以及不同層級所可以使用的錯誤控制元件如圖1。
圖1、一個封包式即時視訊傳送系統，以及不同層級所可以使用的錯誤控制元件。
視訊編碼技術運作
視訊的編碼對於頻寬的節省有重大貢獻，但是其必須倚靠解碼器的高度複雜性運作。以一個輸入的視訊來說，其對移動評估(otion estimation，ME)算法而言是一種主觀性的資料，其必須經過一些處理之後，輸出移動向量(motion vectors，MV)移動補償(otion compensation，MC)時序(temporal)分析才能提供客觀品質建立的實質幫助。如果站在訊號處理的角度來看，移動補償的時序分析區塊的輸出，可視為一種時序上低頻與高頻次頻帶(ubband)集合。以一個由8畫面組成的GOP結構以及畫面的移動向量關係而言。
圖2中，我們顯示了一個由8畫面組成的GOP結構以及畫面的移動向量關係。圖示中最上層所表示的是一全訊框率的視訊畫面，其鄰近的訊框(frames)被分解後產生高頻與低頻頻帶(前者以虛線表示，後者以實線表示)，而圖中的箭頭部分為移動向量(MV)。由圖2可以看見，在經分解鄰近畫面後所產生的頻帶，其中時序低頻對於移動向量得取得是很有幫助的。通常他們的發生速率為視訊訊框率的一半而已，且此過程會不斷重複，直到我們取得GOP內八個畫面的移動向量為止。在上述例子裡面，整個視訊資料有四個時序延伸層(temporal scalability levels)，即是圖2中標示的(1)～(4)。這些不同層級對視訊重建有不同的貢獻，舉例來說，視訊訊框率只有全訊框率的1/8時，那只需第一層視訊資料(level (1))即可重建視訊。相對的如果訊框率達全訊框率的1/4，那視訊的重建就會需要第一層及第二層協力完成。同理，如果視訊訊框率達到全訊框率1/2，那所需要的視訊資料就要更多(即是需第一層、第二層及第三層時序資料)才能重建視訊。
對於已壓縮的視訊位元串流而言，可以依據GOP-based的方式加以封包化。而對一個給定GOP的位元串流而言，其在封包化之前首先會先被重新排列，使得GOP的移動向量可以被排放在位元串流的起始之處，緊接在移動向量之後者，乃已編碼的次頻帶樣本(subband samples)。經過適當排列之後的位元串流，接下來才會被封包化成512-byte左右大小的切割封包。此切割封包中除了含有GOP樣本之外，還涵蓋了4-byte的應用層標頭(application-layer header)，用以表示GOP號碼與GOP內封包序號。在標題後面的負載區(payload)則被用以存放已壓縮的視訊資料，其可存放的空間為508 bytes。換句話說，視訊的頻寬實際可負載率約為99.22%左右(即508/512*100％)。在GOP的運算裡面，其傳送能力等級(即是power level)的決定乃在於其速率失真(rate-distortion)特徵。因為在IP通訊的過程中封包遺失的情形無法完全避免，對即時串流而言，封包的遺失影響程度不一，而對這些封包遺失的修補作法一般有兩種常見的技術可供使用，一種為重新傳送技術(retransmission)，另一種為錯誤回復(error concealment)技術，這些技術我們稍後再做說明。
為了使接收端的封包遺失不致影響服務品質，通常其會採用一些封包錯誤隱藏機制。一個簡單而有效的錯誤隱藏策略，可參考Gallant及Kossentini所提議的方法。在許多現存的錯誤隱藏策略裡面，其使用的是一種空間因果性(causal)方法。解碼器只利用先前收到的封包所提供訊息來隱藏(插補)遺失的封包，例如巨集區塊(MB)的移動向量(MV)的猜測，可由該區塊周邊三個MV來加以評估(即是左上、下及右上)。這種因果性的錯誤隱藏技術亦被廣泛用在數位影像處理領域，例如：例如Bayer RGB模版(Bayer RGB pattern)的色彩資訊遺失，往往也都藉由該遺失像素的空間上周邊像素色彩資訊來加以補償而得。
但除了空間的因果性錯誤隱藏方法之外，亦有另種「時序取代」的錯誤隱藏方式被提出(參見F. Zhai、Y. Zisenberg等人的研究)，這種時序方式的錯誤隱藏方法乃利用前後畫面之間的參考差異，作為遺失補償的依據。在即時視訊上面，單靠空間因果性的錯誤隱藏方法未必能達有效的補償錯誤作用，通常與視訊壓縮效率問題一樣，我們也可能必須往時序方向去考量。一言以蔽之，對即時視訊而言，視訊資料除具有空間關聯性之外，時序方面的高度相似性往往也可能成為非常有潛力的錯誤隱藏方法。另外要注意的是，來源端的封包遺失機率與傳送時的封包遺失機率，此二者之間的關連性乃依據所選用特異性傳送封包化策略而定，二者並非全無關係存在。
一些錯誤回復技術
在一個基於因果性的錯誤控制策略裡，要評估目前的遺失資料，乃必須依據的前的傳送資料而定(即現在遺失資料的插補與的前接收的資料有因果關係)。假設系統嘗試依據PSNR(peak signal-to-noise ratio)去維持一定程度的視訊品質(簡單的客觀視訊品質維持)。在一般情況下，為達此品質目的，我們所需要的參考資料也要有足夠高的品質(在影像處理上，即需要一定大小的迴旋核心存在)。因此為了修復現在遺失的資料，以維持品質不致降低，我們需要先前傳送的資料本身擁有足夠高的品質可供參考。不過，通常我們對於這一點往往無法確認其傳送品質，也無法評估所遺失的資訊對未來視訊品質的影響程度會有多大。因此，這讓此類錯誤控制方式變得沒有效率。
一個直覺式的取代方法，便是我們可以用量的方式取代質的要求。換句話說，我們總是要傳送高品質的資料出去(不管這些資料有沒有在未來被使用到)，一旦有發生傳送的視訊封包遺失的情形，那就有足夠高的品質參考可供修復遺失訊息。但這種作法的缺點，在於整體系統資源的浪費嚴重。這種基於因果錯誤隱藏方式的錯誤控制策略，明顯和那些基於前導錯誤修正(forward error correction，FEC)的策略有著同樣的問題。從另一角度來看，如果應用非因果性的錯誤隱藏方法，那其效果又如何？在此至少和因果錯誤隱藏方式有一個明顯區別，那就是我們不須為了封包遺失的問題，預採某些先行措施來防備。此即是在傳送過程中如果發生封包遺失，其在有必要的下才會改變資料的傳送品質。
由於這種方式不需要預先傳送大量可能不被使用到的高品質封包資料，因此不會加重系統負擔，且在系統資源的使用上面會非常比較有效率。ARQ(Automatic Repeat reQuest)的運作也是基於此概念，它只會在目前傳送資料有發生遺失的情況，才會在將來傳送時把遺失的部分予以重傳。目前為此，這種依時重傳策略目前也是大家公認還蠻有效率的一種方法。只不過，對視訊串流而言，非因果錯誤控制(NCEC)方式有時在能量的使用上，會比ARQ要更有效率(事實上在即時串流應用上，ARQ的使用並不廣，因為它並未考慮到這些應用型態的延遲需求)。一個無線視訊傳送系統概要，如圖3。
在圖3中，一個視訊擷取裝置在擷取視訊完畢之後，這些原始資訊(raw data)會先被影像處理核心處理，然後再經過壓縮後儲存或是傳送。為了方便網路傳送，通常這些已被壓縮後的視訊位元串流(video bitstream)會被存在一個通話區段(session)起始前的一個伺服器中，並且在這些位元串流被傳送前。其會先經過封包化(packetized)處理過程然後才傳送出去。當使用者端收到這些封包化訊息之後，先會經過去封包化過程將這些封包組合起來，並可能具備通知伺服器，其所遺失封包訊息的功能。伺服器便可依據這些訊息回饋資料，以及相關未來視訊資料速率失真(rate distortion)情形，作為其傳送能量(能力)管理(power management)或是建構錯誤控制模組(error control module，EC module)的依據，以及決定其未來這封包所應具備的適當傳送能力。
封包傳送策略
封包傳送策略的選擇與傳送能力的管理，主要目的的一乃在於維持一定的服務品質，而伺服端為達更精確的品質控制，往往需要接收端回饋一些封包接受的訊息，或者需要在接收端建立一些緩衝區(buffer)以儲存一些視訊資料，用以提供未來視訊的顯示或解碼的用。在一般視訊串流得應用裡面，利用接收端緩衝區來預存未來幾秒視訊資料的作法，是司空見慣的一種現象。為了簡化說明起見，我們假設接收端的緩衝區大小為2個GOPs容量(即可存GOPi-1與GOPi資料)。此意味著，在傳送GOPi的情況下，我們只會關心GOPi-1的正確性。對一個有8個畫面的GOP大小，其訊框率為每秒30格(30 fps)的視訊而言，接收端(有兩個GOP大小的buffers)所需要的緩衝區空間配置約為0.53秒的視訊資料(此緩衝區大小可自由假設)。假設GOPi-1已經傳送給接收端，而用以報告GOPi-1封包遺失的回饋封包負載區，乃由Mi-1個位元所組成，其中有個位元n為旗標位元，主要用以表示所接受GOPi-1封包中的第n個封包。此值不是0便是1，0表示GOPi-1中的第n個封包並沒被接收，接收端沒有對此封包解碼；如果為1，則表示該封包以被接收並可順利解碼。傳送者可根據此旗標位元的狀態來得知某個封包的遺失情形，並採取適當的補救措施。這種回饋封包會在每個GOP傳送時間順序區隔(time slot)結束後，由接收端傳回給伺服端作為下次品質改進或傳送能量調整依據(例如：在無線傳輸情況)。因此傳送者在下一波GOP開始傳送的前，依據回饋模式的選擇，可能在收到接收端的回饋訊息之後，才會傳送下一波GOP資料，但以可能在接收回饋訊息的前已先傳送所需的一些GOP封包出去。
當GOPi-1的封包全部傳送完畢之後，接收端會產生一個回饋訊息傳送者(伺服端)，在該回饋訊息中將涵蓋剛剛傳送GOPi-1時，其封包遺失情況。依據系統設計差異，該回饋訊息可以設定在下一個GOPi傳出的前取得或是在傳送下一波GOP的中取得。
