目前，基于TCP/IP的數據傳輸網絡在本質上是盡力而為的網絡，是為傳統數據業務提供傳輸服務的網絡，其傳輸帶寬的波動是不可避免的，傳輸延時也是隨機的。因此，如何在IP網絡上提供流媒體服務并實時傳輸視頻，在這里也需要詳細解讀一下。
一、實時視頻網絡傳輸系統的組成及原理
一個完整的實時視頻網絡傳輸系統由視頻采集、視頻編碼、傳輸控制協議處理、1P通信網絡、視頻解碼等組成。
整個視頻流的處理、傳輸流程是：在視頻發送端，對模擬視頻進行采樣，獲得數字視頻并進行視頻編碼，生成適應于網絡傳輸的面向網絡通信的視頻碼流；根據反饋信息，估計網絡的可用傳輸帶寬，自適應地調整編碼器的編碼輸出速率（包括信源碼率的調整與信道碼率的調整），使得視頻碼流能夠滿足當前網絡傳輸可用帶寬的限制；在接收端，對接收的視頻流進行解碼、重構視頻信號、計算當前網絡傳輸參數（如傳輸中的丟包率等）并發送反饋控制信息。
視頻采集部分主要由視頻A/D、視頻D/A、同步邏輯控制、視頻處理、數據存儲器構成。A/D部分是將各種標準的模擬視頻信號轉換成數字視頻信號，作為視頻處理子單元的輸入數據；邏輯產生單元通常選用FPGA或CPLD來完成各種同步邏輯控制，保證采集的實時性；對視頻數據進行分析和處理，所需運算量常常較大，為了保證視頻處理的實時性，常采用視頻處理專用芯片、高速DSP、FPGA和DSP等來完成視頻處理。
視頻編碼部分將數字視頻信號壓縮為滿足一定視覺質量要求并且符合一定標準的數據流。在視頻流的網絡通信應用中，特別強調編碼器所生成的視頻流應該對網絡傳輸帶寬的隨機波動具有自適應性。目前常采用可伸縮的視頻編碼器對視頻信號進行編碼，可伸縮的視頻編碼可以在時域、空域或正交變換域進行，其基本思想是將碼流分成基本層和增強層。其中基本層碼流是必須傳輸的，包括提供質量等級保證的視頻碼率和視頻序列的運動矢量：增加層是可選擇傳輸的，并且可以根據網絡的傳輸條件進行任意截斷。
傳輸控制部分根據網絡的反饋信息，調整編碼器的編碼速率（信源碼率調整）和信道差錯控制（信道碼率調整），并使信源碼率與信道碼率達到分配。為了降低信道突發誤碼對視頻碼流的影響，常對視頻數據包進行交織處理，以降低臨近數據包同時發生誤碼的概率，便于接收端的錯誤隱藏和恢復。
在視頻流的網絡傳輸中，丟包是不可避免的（特別是在無線網絡傳輸環境中）。為了保證完全正確的數據包傳輸，可以采用重傳的策略，但對于視頻流應用，因為對時延的敏感更勝于對丟包的敏感，所以在接收端，不需要強調完全正確的數據包傳在正確接收的數據包基礎上如何提供滿意程度的視頻質量則為接收端解碼模塊的中心問題。該問題等價于如何利用接收數據包的冗余信息，提供更為滿意的解碼視頻流輸出。解決的辦法就是在接收端的錯誤隱藏和誤差恢復。錯誤隱藏的方法有：
（1）基于空間相關性的錯誤隱藏。利用錯誤塊在同一幀內相鄰塊的正確數據進行內插來重構錯誤塊的數據，以此來達到錯誤隱藏的目的。這樣才能夠對相似或者很多細節的區域進行很有效的恢復。
（2）基于時間相關性的錯誤隱藏。這種方法是利用時間上相鄰的幀具有很強的相關性來進行錯誤隱藏。錯誤隱藏的一個新的發展是采用自適應的方法進行改進，即根據圖像的特點和誤碼的類型來選擇相應的恢復方法或者是這幾種方法的結合。自適應的一種準則是恢復圖像的峰值信噪比（PSNR）化，結合的方式有線性加權合并、信噪比合并等。
二、TCP/IP協議不適合網絡實時傳輸視音頻數據
視頻流傳輸與傳統的TCP/IP網絡的數據傳輸有明顯的區別，主要表現在：傳統的數據傳輸對傳輸延時和傳輸抖動沒有嚴格的要求，但是有嚴格的差錯控制和錯誤重傳機制。而視頻流要求傳輸具有實時性，對同步要求較高，并且對傳輸延時和抖動非常敏感，但在一定的情況下可以允許分組丟失，即可以接受一定程度的傳輸誤碼，并且流媒體服務具有根據網絡的實時用傳輸帶寬自適應地調整視頻的傳輸質量的能力。
IP網已被廣泛使用在各種場合，其中TCP/IP協議是各種網絡操作系統互連和通信的工業標準。TCP/IP協議初是為提供非實時數據業務而設計的，IP協議負責主機之間的數據傳輸，不進行檢錯和糾錯，因此經常發生數據丟失或失序現象。為保證數據的可靠傳輸，人們將TCP協議用于IP數據的傳輸，以提高接收端的檢錯和糾錯能力。當檢測到數據包丟失或錯誤時，就會要求發送端重新發送，這樣一來就不可避免地引起了傳輸延時和耗用網絡的帶寬，因此傳統的TCP/IP協議傳輸實時音頻、視頻數據的能力較差。當然在傳輸用于回放的視頻和音頻數據時，TCP協議也是一種選擇。如果有足夠大的緩沖區、充足的網絡帶寬，在TCP協議上，接近實時的視/音頻傳輸也是可能的。然而，如果在丟包率較高、網絡狀況不好的情況下，利用TCP協議進行視/音頻通信幾乎是不可能的。TCP和其他傳輸層協議如XTP不適合實時視音頻傳輸的原因主要有：
（1）TCP的重傳機制不宜。在TCP/IP協議中，當發送方發現數據丟失時，它將要求重傳丟失的數據包。然而這將需要一個甚至更多的周期（TCP/IP的快速重傳機制，將需要3個額外的幀延遲），這對于實時性要求較高的視/音頻數據通信幾乎是災難性的，因為接收方不得不等待重傳數據的到來，從而造成了延遲和斷點（音頻的不連續或視頻的凝固等）。
（2）TCP的擁塞控制機制不宜。它在探測到有數據包丟失時，就會減小它的擁塞窗口。而視/音頻在特定的編碼方式下，產生的編碼數量（即碼率）是不可能突然改變的。正確的擁塞控制應該是變換視/音頻信息的編碼方式，調節視頻信息的幀頻或圖像幅面的大小等。
（3）TCP的報文頭較大。TCP的報文頭比UDP的報文頭大，TCP的報文頭為40B，而UDP的報文頭僅為12B，并且這些可靠的傳輸層協議不能提供時間戳（TimeStamp）和編/解碼信息，而這些信息恰恰是接收方（即客戶端）的應用程序所需要的。
（4）啟動速度慢。因為即便是在網絡運行狀態良好、沒有丟包的情況下，由于TCP的啟動需要建立連接，因而在初始化的過程中，需要較長的時間。顯然，在一個實時視/音頻傳輸應用中，盡量少的延遲是我們所期望的。
因此，TCP不適合于視/音頻信息的實時傳輸。雖然，TCP/IP協議可拓寬其應用范圍。但單純的TCP/IP協議已經很難適應視/音頻通信，特別是連續的媒體流（如視頻流）通信的要求。TCP協議是面向連接的協議，被用于各種網絡上提供有序可靠數據傳輸的虛電路服務，它的重傳機制和擁塞控制機制（Congestion Control Mechanism）都是不適合用來傳輸實時視/音頻數據的。
三、RTP/RTCP協議適合實時傳輸視音頻
若要在Internet上面提供流媒體數據服務，則需要使用RTP/RTCP（Real-time Transport Protocol/Real-time Transport Control Protocol）協議。RTP協議在一對一或者一對多的傳輸情況下工作，提供數據包傳輸過程中的時間信息和實現流數據同步；RTCP協議與RTP協議…起工作，提供網絡傳輸中的流量控制和擁塞控制。RTP/RTCP是一種應用型的傳輸層協議，它并不提供任何傳輸可靠性的保證和流量的擁塞控制機制，它是由IETF（Internet Engineering Task Force）為視/音頻的實時傳輸而設計的傳輸協議。RTP協議位于UDP協議之上，在功能上獨立于下面的傳輸層（UDP）和網絡層，但不能單獨作為一個層次存在，通常是利用低層的UDP協議對實時視/音頻數據進行組播（Multicast）或單播（Unicast），從而實現多點或單點視/音頻數據的傳輸。
UDP是一種無連接的數據報投遞服務，雖然沒有TCP那么可靠，并且無法保證實時視/音頻傳輸業務的服務質量（QoS），需要RTCP實時監控數據傳輸和服務質量。但是，由于UDP的傳輸延時低于TCP，能與視/音頻流很好地匹配。因此，在實際應用中，RTP/RTCP/UDP用于視/音頻媒體，而TCP用于數據和控制信令的傳輸。
RTP協議沒有連接的概念，它既可以建立在面向連接的底層協議上，也可以建立在面向無連接的底層協議上，因此RTP協議對傳輸層是獨立的。RTP協議一般由兩個部分組成：數據報文部分（RTP報文）和控制報文部分（RTCP）。RTCP是RTP的控制協議，它用于監視服務質量和正在進行的與會者會話上傳遞信息，單獨運行在底層協議上。根據協議規定，RTP和RTCP選用不同的網絡端口號，RTP選擇一個偶數位的端口號，而RTCP則選用下一個奇數位的端口號。RTCP是由接收方向發送的報文，它負責監視網絡的服務質量、通信帶寬，以及網上傳送的信息，并將這些信息發送給發送端。RTCP包周期性地向同一個組播網內的所有成員發送。
RTCP的基本做法是周期性地向會話的所有參加者進行通信，采用和數據包分配傳送的相同機制來發送控制包。和RTP協議相同，RTCP協議也要求下層協議提供復用手段（如要UDP提供不同的端口號來實現復用）。RTCP的主要功能如下。
（1）數據傳輸的質量提供反饋，并提供QoS的檢測。所有的接收方把它近的接收情況報告給所有發送者，這些信息包括所接收到數據包的順序號、丟失的包數、亂序包的數量，以及用于估計傳輸時延的時間戳的信息。而這些信息反映了當前的網絡狀況，發送方在接收到這些信息后自動地調整它們的發送速率。
（2）提供不同媒體間的同步。在視/音頻傳輸服務中，RTP源可能會有幾種媒體（如視/音頻）需要傳輸，這些不同的媒體之間的同步需要依靠RTCP中包含的時鐘信息和相關的RTP時間戳信息來進行同步。
（3）在會話的用戶界面上顯示會話參與者的標識。RTP報文中提供了SSRC字段來進行源標識，然而，進一步的會話參與者的描述是需要的。RTCP報文中的源描述（SEDS）提供了會話參與者的詳盡描述，包括姓名、住址、E-mail等，主要是為會議電視提供更體貼的支持。當然，對于多視頻服務器的組播模式也提供了很好的解決方案。
視頻流和音頻流在時間軸上的連續性，要求網絡的實時傳輸及高帶寬，同時又允許傳輸中存在一定的數據錯誤率及數據丟失率。由于RTP本身并不具有一種獨立傳輸能力，它必須與低層網絡協議結合才能完成數據的傳輸服務。又由于視/音頻在時間軸上的相關性不強，而數據的實時性要高于其可靠性，所以在UDP之上利用RTP/RTCP協議對媒體（視頻和音頻）流進行封裝、打包和同步，可以使數字視/音頻信號的網絡傳輸延時達到小。
由上分析可知，與TCP協議相比較，RTP協議提供了一種更適合于實時視/音頻信息的傳輸機制。