一種提升低速網絡中rtp視頻流處理效率的方法
【專利摘要】本發明公開了一種提升低速網絡中RTP視頻流處理效率的方法，視頻采集端負責視頻數據的實時獲取；視頻編碼打包模塊首先對視頻數據進行壓縮編碼，形成標準的H.264格式的視頻，再對壓縮后的視頻進行RTP封裝打包，將打包后的數據送往網絡緩存區；網絡發送端獲取共享的網絡緩存區中的RTP包數據，生成RTP幀數據，通過基礎網絡將多對TCP套接字對上傳到網絡發送端上；網絡接收端作為視頻服務器，通過與網絡發送端建立多對TCP套接字來傳送RTP數據。實現了多對套接字共同傳輸實時RTP流，合理地合并多個小RTP包一次傳輸，提高了帶寬利用率和網絡傳輸效率，有效解決視頻流實時傳輸導致的丟幀、卡頓及花屏等問題。
【專利說明】一種提升低速網絡中RTP視頻流處理效率的方法
【技術領域】
[0001]本發明涉及一種網絡傳輸方法，尤其涉及的是一種提升低速網絡中RTP視頻流處理效率的方法。
【背景技術】
[0002]隨著3G網絡的普及和LTE時代的到來，人們希望能隨時獲取到音視頻等多媒體信息。RTP協議就是為支持多媒體通信而設計的網絡傳輸協議，從而使流媒體播放器在各種網絡終端上得到普遍應用。
[0003]RTP封裝的數據包易于在網絡上傳輸，其序列號字段和時間戳字段保證接收端能實現丟包檢測和包順序的恢復。在RTP/RTSP協議中，RTP數據包和RTCP數據包都采用UDP協議傳輸，RTCP數據包用于實時監控數據傳輸質量和擁塞控制。UDP是基于消息的方式傳送數據包，傳送速度快，但不提供消息的確認與重傳機制，不提供流量的擁塞控制，因此在低速網絡中容易導致丟包和亂序到達，影響實時音視頻傳輸的用戶體驗。
[0004]低速網絡傳輸通常是基于無線廣域網。由于低速網絡的帶寬限制，數據包傳送速率慢，且容易因網絡狀況不穩定而產生波動。傳輸通道更有可能受信號覆蓋、自然環境、用戶稠密度、業務時間段等影響。因此低速網絡的流媒體傳輸需要將多媒體的編解碼和傳輸技術很好地結合在一起，才能確保用戶在復雜的網絡環境下也能得到穩定的音視頻播放質量。
【發明內容】
[0005]本發明的目的在于克服現有技術的不足，提供了一種提升低速網絡中RTP視頻流處理效率的方法，解決基于RTP/RTCP傳輸技術容易產生的丟包、卡頓問題，提升了數據傳輸的穩定性和帶寬利用效率。
[0006]本發明是通過以下技術方案實現的，本發明包括以下步驟:
[0007](I)視頻采集端負責視頻數據的實時獲取；
[0008](2)視頻編碼打包模塊首先對視頻數據進行壓縮編碼，形成標準的H.264格式的視頻，再對壓縮后的視頻進行RTP封裝打包，形成適合網絡傳輸的RTP視頻流，將打包后的數據送往網絡緩存區；
[0009](3)網絡緩存區是編碼打包模塊與網絡發送端之間共享的環形緩存存儲區域，網絡發送端獲取共享的網絡緩存區中的RTP包數據，生成RTP幀數據，通過基礎網絡的多對TCP套接字對將RTP數據幀上傳到網絡接收端上；
[0010](4)網絡接收端作為視頻服務器，通過與網絡發送端建立多對TCP套接字來接收RTP數據幀并完成幀的分解、RTP包解析和H.264視頻的播放。
[0011 ] 所述網絡發送端與網絡接收端之間采用基于連接的TCP傳輸層協議傳輸RTP數據幀，通信雙方通過TCP報文協商來確定雙方采用的傳輸線程數目、每個線程的TCP傳輸連接數目以及每個傳輸連接雙方所采用的TCP端口。[0012]在低速網絡中，如果采用UDP傳輸，發送方有數據則直接發送且無需確認接收方是否能正確接收數據，從而導致數據包丟包和亂序到達的現象比較嚴重，影響視頻播放的質量。如果采用TCP的傳輸方式，依靠TCP的重傳、確認和流量控制機制，實現數據的可靠傳輸，從而減少數據包的丟失，減少低速網絡中多種網絡環境因素可能對視頻傳輸產生的干擾。與UDP相比，TCP傳輸方式對可靠性的保障會影響傳輸的效率，特別是在低速網絡中，很容易因為速率不夠導致實時視頻播放的卡頓，因此必須有效地提高帶寬的利用率。本發明的網絡發送端與網絡接收端采用多線程多連接，一方面提高網絡帶寬的利用效率，另一方面也提高通信雙方操作系統分配的CPU處理時間。
[0013]所述TCP報文協商的具體過程為:處于廣域網的一端首先創建TCP套接字sockl并進入監聽狀態，處于局域網的一端向sockl發起連接，通過此連接傳輸協商參數，即協商連接；用戶在網絡發送端獲取用戶設置的線程數，每個線程連接數以及每個連接雙方所采用的端口組裝成報文I后發送，通過協商連接發送給網絡接收端，網絡接收端接收到報文I并解析到協商參數后，先后建立對應數目的接收線程數，在每個線程中使用協商的端口進行TCP監聽，如果所有協商參數生效成功則通過協商連接返回設置成功，如果出現協商端口被占用，則自動遞增獲取一個可用端口并進行監聽，并將生效的端口信息通過協商連接返回給發送端，從而建立好數據傳輸通道。
[0014]H.264流中常會連續出現多幀長度較小的P圖像幀，對應的RTP流中就會出現長度較小的RTP數據包以及長度較小的音頻信息和私有封裝子信息。為提升連續出現的小RTP包的傳輸效率，并在接收端與發送端之間形成足夠的視頻數據的緩沖，在本發明中通過合并小RTP包實現并包傳輸，以減少傳輸層發送幀、確認幀的數目，從而進一步提高傳輸的效率。
[0015]所述視頻數據的傳輸通過合并緩存區已有的、連續的、長度較小的RTP包實現并包傳輸，以RTP包為最小單元，RTP包前添加N字節RTP長度信息，按時間順序依次將一個或多個RTP包拼接起來，在首部封裝頭部信息，形成RTP數據幀，以RTP數據幀的形式實現數據的發送與接收；對網絡緩存區已有的RTP數據進行封包并立即發送，若網絡緩存區已沒有新數據，即使已有數據幀總長度很小，也不必等待網絡緩存區的下一包數據；所述RTP數據幀的幀頭信息包含幀序列號、幀長度信息和RTP數據幀所包含的RTP數據包個數。
[0016]所述RTP數據幀的總長度根據網絡最大傳輸路徑單元MSS的長度來確定，單個RTP包的最大長度與幀頭長度之和或小于等于數據幀的最大長度限定值；拼接起來的若干RTP數據包的長度與幀頭長度之和小于或等于RTP數據幀的最大長度限定值，數據幀的最大長度限定值不超過底層MSS的N倍，I < N < 5。從而減少IP層分片傳輸的次數以及發送和接收端網絡緩存區上下文切換的次數。以太網中典型的MSS值為1460字節。
[0017]所述RTP長度的判斷方法如下:
[0018]循環檢測并讀取緩存區中等待傳輸的RTP數據包并對RTP長度進行判斷；若僅有一包等待傳輸，則僅將此包封裝成RTP數據幀并發送；若有N個RTP包等待傳輸且長度之和小于RTP數據幀的限定值，則將此N個RTP合并封裝成RTP數據幀并發送；若有N個RTP包等待傳輸且長度之和超過RTP數據幀的限定值，則僅將部分RTP包合并封裝成RTP數據幀并發送，將超過限定值的部分RTP包與下一次讀取到的RTP數據合并后再重新判斷封包。
[0019]與UDP基于消息的傳輸方式不同,TCP是基于字節流的傳輸協議,有時會出現發送端的若干包數據到接收端時粘在一起形成一個數據包。本發明由于最大限度的提高網絡帶寬利用效率，故TCP的流量控制會頻繁地將數據幀粘起來發送。為解決此問題，所述網絡接收端對網絡數據流進行分解接收工作和RTP數據包的解封裝工作:對每一個RTP幀分兩次讀取，首先讀取RTP數據幀的首部信息，確定RTP數據幀的序號、數據幀的長度以及此數據幀包含多少個RTP包信息，再根據數據幀的長度去讀取剩余的數據幀。
[0020]在低速網絡中，數據包到達網絡接收端是一個明顯的過程，從數據包的首部移入網絡接收端的網絡緩存區到數據包的最后一個字節到達網絡接收端的網絡緩存區是一個可以明顯感知到的過程。所述網絡接收端在讀取網絡緩存區的時候要等待數據均到達網絡緩存區后再去讀取，具體步驟如下:
[0021]設RTP數據幀的首部長度為N字節，網絡接收端在網絡緩存區發現有網絡數據到達后，先判斷網絡緩存區是否有超過N個字節可讀，如果超過N個字節可讀，讀取N字節并分解獲得幀首部信息；如果不夠N字節則延時一毫秒后繼續判斷緩存區可讀的數據長度，循環等待直到有超過N字節可讀為止；獲得幀長度信息后，判斷緩存區剩余可讀數據的長度，如果達到幀的長度，讀取此幀，如果緩存區剩余可讀數據的長度沒有達到幀的長度，延時一毫秒后繼續判斷緩存區可讀數據長度，循環等待直到有超過N字節可讀為止，至此一幀數據讀取完成。
[0022]網絡接收端與發送端建立了多對套接字連接，數據幀在廣域網傳輸過程中可能會出現接收亂序現象，原因在于，一方面數據包在廣域網中傳輸會出現不同程度的延時，后發送的數據可能會先到達；另一方面如果有若干幀數據均已到達接收端,而接收端在接收數據時無法判斷先接收哪一幀數據，可能會出現先到達接收端的數據卻后被處理的情況。為解決此問題，所述網絡接收端與發送端建立了多對套接字連接，通過select端口模型監控套接字數據的到達情況，對獲取到的數據進行順序重建，具體步驟如下:
[0023]a、通過鏈表管理接收到的RTP幀，根據Frame N0.字段遞增依次將連續的鏈表節點送入播放器；
[0024]b、播放器緩存區是一個先進先出的FIFO結構，對送進來的每一個RTP幀分解成一個或多個RTP包，再對RTP包解析成H.264格式可播放的NALU裸流數據，最后將完整的NALU幀送入播放庫進行顯示；
[0025]C、將每個從網絡緩存區接收到的一幀數據，建立一個鏈表節點，并根據FrameN0.值插入到鏈表中，如果有Frame N0.重復的巾貞則丟棄,如果Frame N0.小于已送入播放器的巾貞的Frame N0.則丟棄；
[0026]d、根據select監控套接字到達，如果僅有一個套接字可讀，則讀取此套接字的一幀數據后，建立一個鏈表節點并插入鏈表，如果多個套接字可讀，則依次讀取每一個套接字的幀數據，對每個RTP幀建立鏈表節點，并插入鏈表。
[0027]本發明相比現有技術具有以下優點:本發明實現了多對套接字共同傳輸實時RTP流，合理地合并多個小RTP包一次傳輸，接收端通過亂序重組、分解得到視頻流數據，提高了帶寬利用率和網絡傳輸效率，有效解決視頻流實時傳輸導致的丟幀、卡頓及花屏等問題。
【專利附圖】
【附圖說明】
[0028]圖1是本發明的結構示意圖；[0029]圖2是對RTP包數據合并成RTP幀數據的示意圖。
【具體實施方式】
[0030]下面對本發明的實施例作詳細說明，本實施例在以本發明技術方案為前提下進行實施，給出了詳細的實施方式和具體的操作過程，但本發明的保護范圍不限于下述的實施例。
[0031]如圖1和圖2所示，本實施例包括視頻采集端1、視頻編碼打包模塊2、網絡發送端
3、網絡接收端4和基礎網絡5，
[0032](I)視頻采集端I負責視頻數據的實時獲取；
[0033](2)視頻編碼打包模塊2首先對視頻數據進行壓縮編碼，形成標準的H.264格式的視頻，再對壓縮后的視頻進行RTP封裝打包，形成適合網絡傳輸的RTP視頻流，將打包后的數據送往網絡緩存區；
[0034](3)網絡緩存區是編碼打包模塊與網絡發送端3之間共享的環形緩存存儲區域，網絡發送端3獲取共享的網絡緩存區中的RTP包數據，生成RTP幀數據，通過基礎網絡5的多對TCP套接字對將RTP數據幀上傳到網絡接收端4上；
[0035](4)網絡接收端4作為視頻服務器，通過與網絡發送端3建立多對TCP套接字來接收RTP數據幀并完成幀的分解、RTP包解析和H.264視頻的播放。
[0036]所述網絡發送端3與網絡接收端4之間采用基于連接的TCP傳輸層協議傳輸RTP數據幀，通信雙方通過TCP報文協商來確定雙方采用的傳輸線程數目、每個線程的TCP傳輸連接數目以及每個傳輸連接雙方所采用的TCP端口。
[0037]所述TCP報文協商的具體過程為:處于廣域網的一端首先創建TCP套接字sockl并進入監聽狀態，處于局域網的一端向sockl發起連接，通過此連接傳輸協商參數，即協商連接；用戶在網絡發送端3獲取用戶設置的線程數，每個線程連接數以及每個連接雙方所采用的端口組裝成報文I后發送，通過協商連接發送給網絡接收端4，網絡接收端4接收到報文I并解析到協商參數后，先后建立對應數目的接收線程數，在每個線程中使用協商的端口進行TCP監聽，如果所有協商參數生效成功則通過協商連接返回設置成功，如果出現協商端口被占用，則自動遞增獲取一個可用端口并進行監聽，并將生效的端口信息通過協商連接返回給發送端，從而建立好數據傳輸通道。
[0038]所述視頻數據的傳輸通過合并緩存區已有的、連續的、長度較小的RTP包實現并包傳輸，以RTP包為最小單元，RTP包前添加N字節RTP長度信息，按時間順序依次將一個或多個RTP包拼接起來，在首部封裝頭部信息，形成RTP數據幀，以RTP數據幀的形式實現數據的發送與接收；對網絡緩存區已有的RTP數據進行封包并立即發送，若網絡緩存區已沒有新數據，即使已有數據幀總長度很小，也不必等待網絡緩存區的下一包數據；所述RTP數據幀的幀頭信息包含幀序列號、幀長度信息和RTP數據幀所包含的RTP數據包個數。具體合并過程如圖2所示，RTP包數據包括RTP Header和RTP Data,需要將總長度添加到RTPLength字段形成RTP Group,控制若干RTP Group的總長度。生成Frame Header需要添加Frame N0.幀標識字段，表示RTP Frame的先后順序，以便在網絡接收端4進行亂序的重組，從而避免視頻播放的花屏。
[0039]所述RTP數據幀的總長度根據網絡最大傳輸路徑單元MSS的長度來確定，單個RTP包的最大長度與幀頭長度之和或小于等于數據幀的最大長度限定值；拼接起來的若干RTP數據包的長度與幀頭長度之和小于或等于RTP數據幀的最大長度限定值，數據幀的最大長度限定值不超過底層MSS的N倍，I < N < 5，N通常取I或2，從而減少IP層分片傳輸的次數以及發送和接收端網絡緩存區上下文切換的次數。
[0040]所述RTP長度的判斷方法如下:
[0041]循環檢測并讀取緩存區中等待傳輸的RTP數據包并對RTP長度進行判斷；若僅有一包等待傳輸，則僅將此包封裝成RTP數據幀并發送；若有N個RTP包等待傳輸且長度之和小于RTP數據幀的限定值，則將此N個RTP合并封裝成RTP數據幀并發送；若有N個RTP包等待傳輸且長度之和超過RTP數據幀的限定值，則僅將部分RTP包合并封裝成RTP數據幀并發送，將超過限定值的部分RTP包與下一次讀取到的RTP數據合并后再重新判斷封包。
[0042]所述網絡接收端4對網絡數據流進行分解接收工作和RTP數據包的解封裝工作:對每一個RTP幀分兩次讀取，首先讀取RTP數據幀的首部信息，確定RTP數據幀的序號、數據幀的長度以及此數據幀包含多少個RTP包信息，再根據數據幀的長度去讀取剩余的數據幀。
[0043]所述網絡接收端4在讀取網絡緩存區的時候要等待數據均到達網絡緩存區后再去讀取，具體步驟如下:
[0044]設RTP數據幀的首部長度為N字節，網絡接收端4在網絡緩存區發現有網絡數據到達后，先判斷網絡緩存區是否有超過N個字節可讀，如果超過N個字節可讀，讀取N字節并分解獲得幀首部信息；如果不夠N字節則延時一毫秒后繼續判斷緩存區可讀的數據長度，循環等待直到有超過N字節可讀為止；獲得幀長度信息后，判斷緩存區剩余可讀數據的長度，如果達到幀的長度，讀取此幀，如果緩存區剩余可讀數據的長度沒有達到幀的長度，延時一毫秒后繼續判斷緩存區可讀數據長度，循環等待直到有超過N字節可讀為止，至此一幀數據讀取完成。
[0045]所述網絡接收端4與發送端建立了多對套接字連接，通過select端口模型監控套接字數據的到達情況，對獲取到的數據進行順序重建，具體步驟如下:
[0046]a、通過鏈表管理接收到的RTP幀，根據Frame N0.字段遞增依次將連續的鏈表節點送入播放器；
[0047]b、播放器緩存區是一個先進先出的FIFO結構，對送進來的每一個RTP幀分解成一個或多個RTP包，再對RTP包解析成H.264格式可播放的NALU裸流數據，最后將完整的NALU幀送入播放庫進行顯示；
[0048]C、將每個從網絡緩存區接收到的一幀數據，建立一個鏈表節點，并根據FrameN0.值插入到鏈表中，如果有Frame N0.重復的巾貞則丟棄,如果Frame N0.小于已送入播放器的巾貞的Frame N0.則丟棄；
[0049]d、根據select監控套接字到達，如果僅有一個套接字可讀，則讀取此套接字的一幀數據后，建立一個鏈表節點并插入鏈表，如果多個套接字可讀，則依次讀取每一個套接字的幀數據，對每個RTP幀建立鏈表節點，并插入鏈表。
[0050]本實施例的網絡接收端4是DVR。基礎網絡5是局域網或寬帶接入網絡，包括FTTx, XDSL、IEEE802.11.x 或者無線通信網絡的 TD-LTE、FDD-LTE, CDMA-EVDO、CDMA2000、TD-CDMA。
【權利要求】
1.一種提升低速網絡中RTP視頻流處理效率的方法，其特征在于，包括以下步驟: (1)視頻采集端負責視頻數據的實時獲取； (2)視頻編碼打包模塊首先對視頻數據進行壓縮編碼，形成標準的H.264格式的視頻，再對壓縮后的視頻進行RTP封裝打包，形成適合網絡傳輸的RTP視頻流，將打包后的數據送往網絡緩存區； (3)網絡緩存區是編碼打包模塊與網絡發送端之間共享的環形緩存存儲區域，網絡發送端獲取共享的網絡緩存區中的RTP包數據，生成RTP幀數據，通過基礎網絡的多對TCP套接字對將RTP數據幀上傳到網絡接收端上； (4)網絡接收端作為視頻服務器，通過與網絡發送端建立多對TCP套接字來接收RTP數據幀并完成幀的分解、RTP包解析和H.264視頻的播放。
2.根據權利要求1所述的一種提升低速網絡中RTP視頻流處理效率的方法，其特征在于，所述網絡發送端與網絡接收端之間采用基于連接的TCP傳輸層協議傳輸RTP數據幀，通信雙方通過TCP報文協商來確定雙方采用的傳輸線程數目、每個線程的TCP傳輸連接數目以及每個傳輸連接雙方所采用的TCP端口。
3.根據權利要求2所述的一種提升低速網絡中RTP視頻流處理效率的方法，其特征在于，所述TCP報文協商的具體過程為:處于廣域網的一端首先創建TCP套接字SOCkl并進入監聽狀態，處于局域網的一端向sockl發起連接，通過此連接傳輸協商參數，即協商連接；用戶在網絡發送端獲取用戶設置的線程數，每個線程連接數以及每個連接雙方所采用的端口組裝成報文I后發送，通過協商連接發送給網絡接收端，網絡接收端接收到報文I并解析到協商參數后，先后建立對應數目的接收線程數，在每個線程中使用協商的端口進行TCP監聽，如果所有協商參數生效成功則通過協商連接返回設置成功，如果出現協商端口被占用，則自動遞增獲取一個可用端口并進行監聽，并將生效的端口信息通過協商連接返回給發送端，從而建立好數據傳輸通道。
4.根據權利要求1所述的一種提升低速網絡中RTP視頻流處理效率的方法，其特征在于，所述視頻數據的傳輸通過合并緩存區已有的、連續的、長度較小的RTP包實現并包傳輸，以RTP包為最小單元，RTP包前添加N字節RTP長度信息，按時間順序依次將一個或多個RTP包拼接起來，在首部封裝頭部信息，形成RTP數據幀，以RTP數據幀的形式實現數據的發送與接收；對網絡緩存區已有的RTP數據進行封包并立即發送，若網絡緩存區已沒有新數據，即使已有數據幀總長度很小，也不必等待網絡緩存區的下一包數據；所述RTP數據幀的幀頭信息包含幀序列號、幀長度信息和RTP數據幀所包含的RTP數據包個數。
5.根據權利要求4所述的一種提升低速網絡中RTP視頻流處理效率的方法，其特征在于，所述RTP數據幀的總長度根據網絡最大傳輸路徑單元MSS的長度來確定，單個RTP包的最大長度與幀頭長度之和或小于等于數據幀的最大長度限定值；拼接起來的若干RTP數據包的長度與幀頭長度之和小于或等于RTP數據幀的最大長度限定值，數據幀的最大長度限定值不超過底層MSS的N倍，I≤N≤5。
6.根據權利要求5所述的一種提升低速網絡中RTP視頻流處理效率的方法，其特征在于，所述RTP長度的判斷方法如下: 循環檢測并讀取緩存區中等待傳輸的RTP數據包并對RTP長度進行判斷；若僅有一包等待傳輸，則僅將此包封裝成RTP數據幀并發送；若有N個RTP包等待傳輸且長度之和小于RTP數據幀的限定值，則將此N個RTP合并封裝成RTP數據幀并發送；若有N個RTP包等待傳輸且長度之和超過RTP數據幀的限定值，則僅將部分RTP包合并封裝成RTP數據幀并發送，將超過限定值的部分RTP包與下一次讀取到的RTP數據合并后再重新判斷封包。
7.根據權利要求1所述的一種提升低速網絡中RTP視頻流處理效率的方法，其特征在于，所述網絡接收端對網絡數據流進行分解接收工作和RTP數據包的解封裝工作:對每一個RTP幀分兩次讀取，首先讀取RTP數據幀的首部信息，確定RTP數據幀的序號、數據幀的長度以及此數據幀包含多少個RTP包信息，再根據數據幀的長度去讀取剩余的數據幀。
8.根據權利要求7所述的一種提升低速網絡中RTP視頻流處理效率的方法，其特征在于，所述網絡接收端在讀取網絡緩存區的時候要等待數據均到達網絡緩存區后再去讀取，具體步驟如下: 設RTP數據幀的首部長度為N字節，網絡接收端在網絡緩存區發現有網絡數據到達后，先判斷網絡緩存區是否有超過N個字節可讀，如果超過N個字節可讀，讀取N字節并分解獲得幀首部信息；如果不夠N字節則延時一毫秒后繼續判斷緩存區可讀的數據長度，循環等待直到有超過N字節可讀為止；獲得幀長度信息后，判斷緩存區剩余可讀數據的長度，如果達到幀的長度，讀取此幀，如果緩存區剩余可讀數據的長度沒有達到幀的長度，延時一毫秒后繼續判斷緩存區可讀數據長度，循環等待直到有超過N字節可讀為止，至此一幀數據讀取完成。
9.根據權利要求7所述的一種提升低速網絡中RTP視頻流處理效率的方法，其特征在于，所述網絡接收端與發送端建立了多對套接字連接，通過select端口模型監控套接字數據的到達情況，對獲取到的數據進行順序重建，具體步驟如下: a、通過鏈表管理接收到的RTP幀，根據FrameN0.字段遞增依次將連續的鏈表節點送入播放器； b、播放器緩存區是一個先進先出的FIFO結構，對送進來的每一個RTP幀分解成一個或多個RTP包，再對RTP包解析成H.264格式可播放的NALU裸流數據，最后將完整的NALU幀送入播放庫進行顯示； C、將每個從網絡緩存區接收到的一幀數據，建立一個鏈表節點，并根據Frame N0.值插入到鏈表中，如果有Frame N0.重復的幀則丟棄，如果Frame N0.小于已送入播放器的幀的Frame N0.則丟棄； d、根據select監控套接字到達，如果僅有一個套接字可讀，則讀取此套接字的一幀數據后，建立一個鏈表節點并插入鏈表，如果多個套接字可讀，則依次讀取每一個套接字的幀數據，對每個RTP幀建立鏈表節點，并插入鏈表。
【文檔編號】H04N21/6437GK103929681SQ201410140850
【公開日】2014年7月16日 申請日期:2014年4月9日 優先權日:2014年4月9日
【發明者】李陽, 張乾坤, 王孝貴, 邱換春, 汪俊鋒 申請人:安徽超遠信息技術有限公司