一種數據傳輸的方法、系統及裝置的製作方法

2023-05-01 01:52:31

專利名稱：一種數據傳輸的方法、系統及裝置的製作方法
技術領域：
本發明涉及多媒體廣播及通信技術領域，具體涉及數據傳輸的方法、 系統及裝置。
背景技術：
隨著流媒體、無線寬帶、移動通信技術以及網際網路技術融合發展，移 動(手機)電視等新應用逐步形成熱點，移動(手機)電視作為一場新媒 介融合的變革，將帶來巨大的商業機會和發展前景。
流媒體中有一種重要的業務，即直播業務LiveTV，需要一臺或多臺 編碼器(Encoder)對流媒體數據進行實時壓縮、編碼得到直播數據，PSS 從編碼器接收直播數據，並實時將直播流推送到客戶端。
鑑於直播數據的實時性要求，用戶隨時接入觀看同一個頻道時，所看 到的節目應是一樣的，也就是要求各個客戶端幾乎同時接收到同樣的媒體 數據。為了滿足上述特性要求，現有技術中，PSS每接收到編碼器的RTP 包就給每個客戶端拷貝 一份發出去，這樣PSS就相當於一個流量倍增器， 有多少個並發用戶幾乎就要發送相應倍數的直播媒體數據，由於編碼器輸 出的直播數據流是間斷髮送， 一般每幾十毫秒發送一幀數據(每幀數據可 能有多個RTP數據包)，這樣就會產生流量突變，對核心網設備如交換 機/路由器/GGSN等的承載能力要求非常高，同時有其它數據業務存在的 時候，造成數據丟包的概率非常大，因此，要求從PSS輸出的數據流量能 夠平滑。
現有技術中的一種實現流量平滑的技術方案，具體如下 每個直播頻道採用預定的碼率來壓縮數據，此碼率通常是該頻道的平 均碼率，碼率信息保存在SDP描述文件中，在編碼器中每創建一個頻道都 會產生一個SDP文件。現有技術釆用漏桶技術來實現數據流量平滑，即每 次採用平均碼率發送，其餘的數據先緩存起來，即將"波峰"數據削減一部 分，和"波谷"數據一起發送出去，但實際應用中，常常出現碼率突變的情 況，並會持續一段時間，另外，隨著並發用戶數增加，也會導致數據流量不穩定。

發明內容
有鑑於此，本發明提供一種數據傳輸的方法、系統及裝置，可實現數 據流量平滑傳輸。
本發明實施例提供的一種數據傳輸的方法，包括 流媒體伺服器接收來自編碼器的數據包並緩存； 獲取所述編碼器預告的傳輸數據流量信息；
根據所接收到的數據包大小、所述編碼器的傳輸數據流量信息、輸出 信道的實時碼率確定所述數據包的發送時間或/和調整數據發送速率。 該方法還包4舌
根據所確定的發送時間或/和發送速率發送數據。 本發明實施例提供的一種實現數據傳輸的系統，包括流^ 某體伺服器、 編碼器；
所述流媒體伺服器接收來自所述編碼器的數據包並緩存； 獲取所述編碼器預告的傳輸數據流量信息；
根據所接收到的數據包大小、輸出信道的實時碼率確定所述數據包的 發送時間；
所述流媒體伺服器按照所確定的發送時間將數據包發送給所述客戶端。
本發明實施例還提供一種實現數據傳輸的裝置，包括
接收單元，用於接收來自編碼器的數據包及流量信息；
緩存單元，用於緩存所述接收單元接收的數據包；
數據流量控制單元,根據所接收到的數據包大小或/和輸出信道的實時 碼率或/和流量信息控制所述數據包的發送時間或/和速率；
發送單元，在所述數據流量控制單元將所述緩存單元緩存的數據包發 送給客戶端。
存儲單元，用於存儲待編碼的音、視頻數據；
編碼單元，用於對所述音、視頻數據進行編碼；
數據流量上報單元，根據所述存儲單元保存的音、視頻數據實時發送數據流量信息，所述數據流量信息包括所述存儲單元中所存儲待編碼的 音、視頻數據量，以及所述發送單元輸出數據的速率； 發送單元，用於輸出編碼後的數據流。
本發明實施例提供的技術方案中，接收來自編碼器的數據包並緩存； 獲取所述編碼器預告的傳輸數據流量信息；根據所接收到的數據包大小、 所述編碼器的未來流量信息、輸出信道的實時碼率確定所述^t據包的發送 時間。根據本發明，可實現數據傳輸流量平滑，滿足直播業務對實時數據 傳輸的要求，達到良好的直播效果。


圖1為現有技術中的移動流々某體端對端組網示意圖2為現有技術中的RTP固定頭欄位構成示意圖3為現有技術中的RTP固定頭擴展欄位的構成示意圖4為本發明實施例中實現悽t據流平滑的原理示意圖5為本發明實施例中編碼器輸入到流媒體伺服器的數據流量突變情
況下的翁:據流量平滑處理示意圖6為本發明實施例中編碼器輸入到流媒體伺服器的流量信息有偏差
的情況下數據流量平滑處理示意圖。
具體實施例方式
參照圖1,在移動(手機)電視電視系統中，移動(手機)電視用戶 終端(UE)通過GGSN接入IP網絡，機頂盒(STB)與PC通過各種接 入手段，如ADSL直接接入到IP網中，分組域流媒體伺服器(PSS， Packet
-switched Streaming Server) —般處於核心網，為各種客戶端提供流媒 體業務。目前，流媒體一般使用RTSP/RTP/RTCP協議簇來控制、傳輸流媒 體數據。RTSP( RFC 2326 )用於建立和控制連續媒體的時間同步流，RTSP 是標準的流媒體協議，並通常利用獨立傳輸協議(如RTP)來傳輸媒體數 據。RTP (RFC 1889、 RFC 1890、 RFC 3550 )提供時間信息和實現A/V流 同步。RTP不處理資源預定，並且不能保證實時服務的服務質量，而RTCP (RFC 3550)的主要功能是為數據的傳送情況提供反饋。流媒體中有一種重要的業務，即直播業務LiveTV,需要一臺或多臺編碼器(Encoder)對 流媒體數據進行實時壓縮、編碼得到直播數據，PSS從編碼器接收直播數 據，並實時將直播流推送到客戶端。鑑於直播數據的實時性要求，用戶隨 時接入觀看同一個頻道時，所看到的節目應是一樣的，也就是要求各個客 戶端幾乎同時接收到同樣的媒體數據。本發明提供一種數據傳輸的方法、 系統及裝置，可實現數據流量平滑傳輸。
為使本發明的原理、特性和優點更加清楚，下面對本發明進行詳細描述。
流媒體直播Live TV業務系統中包括處於核心網為各種客戶端提供流 々某體業務的流媒體伺服器以及一臺或多臺編碼器(Encoder),所述編碼 器實時對釆集的直播數據進行壓縮、編碼，然後發送給流媒體伺服器，流 媒體伺服器從編碼器接收直播數據並實時將直播數據流推送到客戶端，從 而實現直播服務。
由於編碼器需要對動態音視頻數據進行壓縮、碼率控制、以及重新編 碼等處理，因此，通常要緩沖一小段時間的數據，換而言之，編碼器預先 知道在未來一小段時間內將要輸出的數據量。編碼器通過將上述未來數據 流量信息告知流媒體伺服器，流媒體伺服器就可較準確地知道編碼器輸出 直播流的實時碼率，每次發送數據時就可較準確計算出發送的數據的時間 點和數據量。
流媒體伺服器每接收到一個RTP數據包時，先將RTP數據緩存起來， 然後根據此RTP數據包在內存中的指針，針對每個並發用戶生成一條發包 記錄，放進發包緩衝區，每條發包記錄的結構如下RTP指針、希望發包 時間點、用戶信息、頻道信息。計算出每條發包記錄的希望發包時間點。 採用高精度的定時器，定時啟動發送數據的任務，根據預定規則從發包緩 衝區取出滿足條件的數據發送出去。接收來自編碼器的數據包並緩存；獲 取所述編碼器預告的傳輸數據流量信息；根據所接收到的數據包大小、輸 出信道的實時碼率確定所述數據包的發送時間。當所述編碼器的輸出數據 的速率變化時，根據所述編碼器中緩存的數據量實時調整所述數據包的發 送時間。所有時間點都採用當前作業系統的系統時鐘作為基準，以保證時間同步。
本發明實施例提供的技術方案中，流媒體伺服器每次發送適當數量的 數據，其餘數據先緩存起來，等待後續波谷期間發送出去，本發明在實現 流量平滑的同時，解決了由於各種誤差累加導致的丟包、音視頻不同步等 問題。
本發明實施例提供的一種數據傳輸的方法，包括如下步驟 S01 ，流媒體伺服器接收來自編碼器的數據包並緩存； 編碼器實時對採集的直播數據進行壓縮、編碼，然後採用實時傳輸協
議RTP將數據發送給流媒體伺服器。流媒體伺服器每接收到 一個RTP數據 包時，先把RTP數據緩存起來，然後根據此RTP數據包在內存中的指針， 針對每個並發用戶生成一條發包記錄，放進發包緩衝區，每條發包記錄包 括RTP指針、希望發包時間點、用戶信息、頻道信息。
S02，獲取所述編碼器預告的傳輸數據流量信息；
本實施例中，編碼器採用實時傳輸協議RTP傳輸數據給流媒體服務 器，RTP協議是支持頭擴展的，見圖2的RTP協議頭所示，把X位設置 為1,頭擴展的格式見圖3。預告傳輸數據流量信息放在header extension 欄位中，前32位表示未來的時間段，單位為微秒，後24位表示未來時間 段內的流量，單位為bit,最後8位表示對應的數據包的數量。
需要說明的是，編碼器預告未來一段時間內的流量信息不一定釆用 RTP數據包的頭擴展來傳輸，也可以採用RTCP數據包或者是RTSP協議 來傳輸，或者特定的私有協議來傳輸，只是實時性以及實用性沒有採用 RTP頭擴展好。
流媒體伺服器收到RTP數據包後，解析RTP的頭擴展欄位，獲取所述 編碼器的未來流量信息，可得知編碼器未來多長時間內(FT, Future Time ) 將發送多少的數據量(FF, Future Flux)到流媒體伺服器。
S03,根據所接收到的數據包大小、輸出信道的實時碼率確定所述數據 包的發送時間。
流i某體伺服器每次發完該發的數據後，記錄最後一次發包的時間點，以此時間點作為開始時間點(ST， Start Time),供後續發送數據包時參照。
流媒體伺服器收到的RTP數據包大小為RtpSize,並發用戶數為CUC (Current User Count),發包周期為SC ( Send Cycle )，上述所有時間點 都折算為系統時鐘的精度。
直^番頻道的實時碼率(Real Rate)為RR = FF/FT 每包RTP數據的理想的發送時長RtpT = RtpSize/RR
RtpT = (RtpSize x FT) / FF 每RTP數據包最好在RtpT內發送給所有的並發用戶。 需要考慮的情況是，編碼器只告知PSS在FT時間內發送大小為FF的數 據量，計算實時碼率時取的是平均值，考慮到實際應用中，FF的數據量可 能不是均勻地在FT時間段內發送出來，可能集中在某個時間點內發送出 來，流媒體伺服器需要自適應此種變化，即需要把緩沖區未發送的數據也 考慮進來。當所述編碼器的輸出數據的速率變化時，需要讀取發包緩存區 的緩存信息，包括未發送的數據量(NSF)、未發送數據的最大希望發 送時間點(NMaxT),根據所緩存信息實時調整所述數據包的發送速率和 /或時間。
通常，客戶端分別設置一個視頻緩存區與音頻緩存區， 一般情況下， 音頻數據碼率一般比較穩定，音頻的緩存區要求比較小，假設客戶端最少 的緩衝時間為MinBT (Min Buffer Time),但考慮特殊情況，MinBT不特 指音頻的最小緩衝時間，而是取視頻緩衝與音頻緩衝時間中較小的。為了 實現音視頻同步以及音視頻流都能正常播放，所緩存數據包必須要求在最 'J、緩衝時間MinBT內發送給客戶端。
每個RTP數據包都要轉發給CUC個並發用戶，某RTPi數據包給第n個 用戶的希望發送時間點(EST， Expect Send Time )的計算方法如下
情況I:在編碼器以恆定速率發送數據的前提下，如果計算的發送時 長小於客戶端的最小緩衝時間，即RtpT <= MinBT ,並且之前收到RTP 包計算出來的希望發送時間點比當前包計算出來的希望發送最大時間點 還要靠後，即(NMaxT —ST) NSF/(NMaxT —ST)，那 麼NMaxT時間點之前需要新增加發送數據量為ESR( NMaxT - ST) - NSF, 折算為RTP數據包數為
M = ( ESR1 (麗axT - ST) - NSF ) / RtpSize 即n <= M時，EST計算公式如下
ESTn =ST + nx (麗axT-ST) /M 由上述兩式得到
ESTn = ST + (nxRtpSize)/ (ESR1- NSF/ (NMaxT-ST)) n〉m時，即所計算得到的時間點都是在NMaxT之後，剩下的數據都 是以ESR發送的，剩下的數據量為(n-M) xRtpSize，因此，EST計算公式 :i口下
ES丁n = NMaxT + (n — M) xRtpSize/ESR (2 )如果之前計算的發送碼率偏高，即ESRl > NSF/( NMaxT — ST)， 考慮性能以及穩定性，進入發送緩衝區就不再作調整速率和發送時間，即 新數據在NMaxT到(ST + RtpT)之間發送完畢，因此，EST的計算公式如 下
ESTn = NMaxT + n x(ST + RtpT-畫axT)/CUC 情況(II ):當計算得到所接收數據包發送時長RtpT不小於客戶端的 最小緩衝時間MinBT，即RtpT =RtpT,則在RtpT內實際要發送的數據量 RSF (Real Send Flux)為
RSF = CUC xRtpSize + (NSF xRtpT )/NMaxT - ST 期望的發送碼率為RSF/RtpT，因此，EST的計算公式如下
ESTn = ST + nxRtpSizexRtpT / RSF 情況(III):當計算得到所接收數據包發送時長RtpT大於客戶端的最 小緩衝時間MinBT，即RtpT >MinBT,且所述流々某體伺服器之前收到翁: 據包計算確定的發送時間點在當前數據包計算確定的發送最大時間點之後，即(NMaxT-ST) <RtpT，則需要對所述流媒體伺服器發送數據的 速率進行調整，此時計算計算期望的發送碼率ESR以及希望發送時間點 EST的方式與情況(I )類同，用MinBT替換RtpT來計算即可，期望的 數據發送速率為
ESR = (RtpSizexCUC + NSF) /MinBT
RtpSize為所述流々某體伺服器每次收到的數據包大小，CUC為並發用戶 數，NSF為所述流媒體伺服器中緩存數據量。
情況(IV ):當計算得到所接收數據包發送時長RtpT大於客戶端的最 小緩衝時間MinBT,即RtpT >MinBT,且所述流媒體伺服器之前數據包 計算確定的發送最大時間點在當前收到數據包計算確定的發送時間點之 後，即(畫axT-ST) >=RtpT,則此時計算計算期望的發送碼率ESR以 及希望發送時間點EST的方式與情況(II )類同，用MinBT替換RtpT來計 算即可，在RtpT內要發送的數據量RSF為
RSF = CUCxRtpSize + (NSFxMinBT)/麗axT —ST。
編碼器輸入數據到PSS的速率不恆定的異常情況
如圖5所示，圖5的上曲線圖中每隔一條虛豎線表示編碼器的緩衝時 間，即上述FT值，每條豎實線表示發送的數據包，每條豎實線等高表示 數據包大小相等，這是為了描述方便，實際應用中，發送的數據包大小不 一樣的，但可以理解為分解成幾個數據包同時發送，如上曲線圖中前4條 豎實線。圖5的下曲線圖的每條虛橫線的間隔表示發送周期，圖中的發送 周期為50個單位時間，灰色框內的數字表示每單位時間的流量。
PSS接收到第1個數據包時，由於編碼器此時只知1000單位時間內有 5000個單位流量的數據量要發送，因此編碼器把這一信息傳給PSS。從圖 中可知，前4個數據包發送時間間隔很密，表示有流量突變，按理說，此 時刻的碼率很多，但PSS也只能計算了一個平均值作為實時的碼率，即 5000/1000 = 5,即每單位時間發送5單位流量的數據量。本段文字就是要 說明PSS如何自適應的應付此變化。
PSS接收到第2個數據包時，這做了一種較壞情況的假設，即已經發送 有誤差的碼率發送了n個周期，為了方便說明，圖中只假設按有誤差的碼率發送了l個周期，編碼器此時因為沒有新數據流入，因此傳給PSS的信息
是未來1000單位時間內發送4000單位流量的數據，因此，PSS根據新老數 據，計算出來的實時碼率為7，計算方式如下
RtpT =緩存周期x數據包大小/未來時間段內總流量
=(1000/4000) xl000 = 250 已發送數據=發送周期x上次實時碼率=50x5 =250 剩餘數據量=新接收到+未發送出去的
=1000 + 1000-250 = 1750 當前的實時碼率為=1750/250 = 7
後面如此類推，從圖中可知，儘管由於輸入的流量突變引起PSS輸出 流量波動，但PSS實時自適應的做了調整，誤差不會不斷積累，同時也使
得波峰平滑了。
編碼器計算的流量信息有偏差的情況
圖6為本發明實施例中編碼器輸入到流媒體伺服器的流量信息有偏差 的情況下數據流量平滑處理示意圖。
假設編碼器由於異常原因沒有統計到某個數據包，如第4數據包，見 圖6中虛豎線。
參照圖6， PSS接收到第1個數據包時，編碼器輸入的流量信息是未來 IOOO單位時間內有4000個單位流量的數據量要發送，PSS的第一個發送周 期的實時碼率就為4，如此類推，收到2個數據包的實時碼率為3，收到第3 個數據包的實時碼率為2。
收到第4個數據包，編碼器得到更正，給PSS輸入的流量信息為未來 1000單位時間內有2000個單位流量的數據量要發送，此時PSS及時進行 自適應調整，因此，也不會累積誤差。
本發明實施例還提供一種數據傳輸的系統，包括流媒體伺服器、編 碼器；
編碼器，包括存儲單元，用於存儲待編碼的音、視頻數據；編碼單 元，用於對所述音、視頻數據進行編碼；數據流量上報單元，根據所述存 儲單元保存的音、視頻數據實時發送數據流量信息，所述數據流量信息包括所述存儲單元中所存儲待編碼的音、視頻數據量，以及所述發送單元
輸出數據的速率；發送單元，用於輸出編碼後的數據流。 所述流媒體伺服器接收來自所述編碼器的數據包並緩存； 具體包括每接收到一個數據包時，將所述數據包緩存，然後根據每
個並發用戶生成一條發包記錄，存入發包緩衝區，每條發包記錄包括RTP
指針、希望發包時間點、用戶信息、頻道信息。 獲取所述編碼器預告的傳輸數據流量信息；
根據所接收到的數據包大小、輸出信道的實時碼率確定所述數據包的 發送時間；
當所述編碼器輸出數據給所述流媒體伺服器的速率變化時，根據所述 編碼器中緩存的數據量實時調整所述數據包的發送時間；
所述流媒體伺服器按照所確定的發送時間將數據包發送給所述客戶端。
所述編碼器通過擴展所述數據包頭攜帶傳輸數據流量信息以發送給 所述流媒體伺服器。
所述流媒體伺服器根據計算得到所接收數據包發送時長RtpT、客戶 端的最小緩衝時間MinBT，數據包計算確定的發送時間點，實時對發送數 據的速率進行調整。
本發明實施例還提供一種編碼裝置，包括
存儲單元，用於存儲待編碼的音、視頻數據；
編碼單元，用於對所述音、視頻數據進行編碼；
數據流量上報單元，根據所述存儲單元保存的音、視頻數據實時發送 數據流量信息，所述數據流量信息包括所述存儲單元中所存儲待編碼的 音、視頻數據量，以及所述發送單元輸出數據的速率；
發送單元，用於輸出編碼後的數據流。
本發明實施例還提供一種實現數據傳輸的裝置，包括
接收單元，用於接收來自編碼器的數據包及後續流量信息；
緩存單元，用於緩存所述接收單元接收的數據包；
數據流量控制單元，根據所接收到的數據包大小、輸出信道的實時碼率以及後續流量信息控制所述數據包的發送時間；
發送單元，按照所確定的發送時間將所述緩存單元緩存的數據包發送 給客戶端。
發送單元啟用一個精確的定時器來定時觸發發包任務， 一般而言，精 度(即最小周期)設置得越小對流量平滑的效果越好，因此，需要設置一
個適當值(如，2毫秒)，並可以根據實際平滑規格作調整。
所述裝置還包括控制單元，用於控制所述發送單元的發包線程，在 希望發包時間之前，啟動發包線程，確保當前啟動時間點先於發包記錄的 希望發包時間點。
發包線程啟動後，從發包緩衝區中讀出要發送的數據包發送出去，因 為發包記錄已經包含要發送客戶端的網絡信息，按發包記錄的信息直接發 送。更適宜地，採用過濾條件當前喚醒啟動時間點先於發包記錄的希望 發包時間點，這樣就可以消除了定時器的誤差積累，每次定時誤差都實時 處理掉了，而不會等到一定積累後再處理。發包線程實際上就是一個高精 度的定時器，定時被喚醒，執行一次發送任務後就sleep，等待下一次被喚 醒。當前喚醒啟動時間點是指發包線程被喚起的時刻，由於放到發送緩衝 區的數據是超前預測的，或者說期望的發送時間可能比發包線程的當前喚 醒啟動時間還要靠後，考慮定時器可能也會有誤差，採用上述過濾條件， 可以實時消除誤差積累。
綜上所述，本發明實施例提供的技術方案中，接收來自編碼器的數據 包並緩存；獲取所述編碼器預告的傳輸數據流量信息；根據所接收到的數 據包大小、所述編碼器的未來流量信息、輸出信道的實時碼率確定所述數 據包的發送時間。當所述編碼器的輸出數據的速率變化時，根據所述編碼 器中緩存的數據量實時調整所述數據包的發送時間。根據本發明，可在實 現數據流量平滑的同時，解決了由於各種誤差累加導致的丟包、音視頻不 同步等問題，滿足直播業務對實時數據傳輸的要求，達到良好的直播效果。
顯然，本領域的技術人員應該明白，上述的本發明的各模塊或各步驟 可以用通用的計算裝置來實現，它們可以集中在單個的計算裝置上，或者 分布在多個計算裝置所組成的網絡上，可選地，它們可以用計算裝置可執行的程序代碼來實現，從而，可以將它們存儲在存儲裝置中由計算裝置來 執行，或者將它們分別製作成各個集成電路模塊，或者將它們中的多個模 塊或步驟製作成單個集成電路模塊來實現。這樣，本發明不限制於任何特 定的硬體和軟體結合。
以上所述僅為本發明的較佳實施例而已，並非用於限定本發明的保護 範圍。凡在本發明的精神和原則之內所作的任何修改、等同替換、改進等， 均包含在本發明的保護範圍內。
權利要求
1. 一種數據傳輸的方法，其特徵在於，包括接收來自編碼器的數據包並緩存；獲取所述編碼器預告的傳輸數據流量信息；根據所接收到的數據包大小、所述編碼器的傳輸數據流量信息、輸出信道的實時碼率確定所述數據包的發送時間或/和調整數據發送速率。
2. 如權利要求l所述的方法，其特徵在於，還包括 根據所確定的發送時間或/和發送速率發送數據。
3. 如權利要求l所述的方法，其特徵在於，還包括 當所述編碼器的輸出數據的速率變化時，根據所緩存的數據量實時調整所述數據包的發送速率和/或時間。
4. 如權利要求1所述的方法，其特徵在於，所述獲取傳輸數據流量信 息是通過下述方式實現的通過所述數據包頭攜帶所述傳輸數據流量信息發送給所述流媒體服務 器；或，根據編碼器中緩存數據包的數據量實時發送所述傳輸數據流量信息給 所述流媒體伺服器。
5. 如權利要求l所述的方法，其特徵在於，還包括 當計算得到所接收數據包發送時長RtpT小於客戶端的最小緩衝時間MinBT,且所述流媒體伺服器之前收到數據包計算確定的發送時間點在當前 數據包計算確定的發送最大時間點之後，則根據所述流媒體伺服器每次收到 的數據包大小、並發用戶數、所述流媒體伺服器中緩存數據量以及所述流媒 體伺服器發送各數據包的理想時長對所述流^(某體伺服器發送數據的速率進 行調整。
6. 如權利要求5所述的方法，其特徵在於，還包括 若調整後的數據發送速率ESR大於之前計算確定的數據發送速率，則在所 述流媒體伺服器中緩存數據希望發送時間點之前需要增加發送數據量。
7. 如權利要求5所述的方法，其特徵在於，還包括 若調整後的數據發送速率ESR小於之前計算確定的數據發送速率，則根據 所述流媒體伺服器發送各數據包的理想時長、並發用戶數、所述流媒體伺服器中緩存數據希望發送時間點調整所述流媒體伺服器中數據希望發送時間 點。
8、 如權利要求l所述的方法，其特徵在於，還包括 當計算得到所接收數據包發送時長RtpT大於客戶端的最小緩衝時間MinBT，且所述流媒體伺服器之前收到數據包計算確定的發送時間點在當前 數據包計算確定的發送最大時間點之後，則根據所述流媒體伺服器每次收到 的數據包大小、並發用戶數、所述流媒體伺服器中緩存數據量以及最小緩衝 時間對所述流媒體伺服器發送數據的速率進行調整。
9、 如權利要求8所述的方法，其特徵在於，還包括 若調整後的數據發送速率ESR大於之前計算確定的數據發送速率NSF/( NMaxT - ST),則在所述流媒體伺服器中緩存數據的希望發送時間點 NMaxT之前至少增加發送lt據量ESRx (NMaxT-ST) - NSF 其中，ST為上一次發送數據包的時間點。
10、 如權利要求8所述的方法，其特徵在於，還包括 若調整後的數據發送速率ESR小於之前計算確定的數據發送速率NSF/( NMaxT- ST),則調整所述流媒體伺服器中數據的希望發送時間點。
11、 如權利要求l所述的方法，其特徵在於，還包括當計算得到所接收數據包發送時長RtpT不小於客戶端的最小緩衝時間 MinBT,且所述流媒體伺服器當前數據包計算確定的發送最大時間點在之前 收到數據包計算確定的發送時間點之後，則在RtpT內至少要發送的數據量 RSF為RSF = CUCxRtpSize + (NSFxRtpT )/麗axT-ST。
12、 如權利要求10所述的方法，其特徵在於，期望的發送碼率為RSF / RtpT,按照下式計算確定所述流^某體伺服器中數據希望發送時間點ESTn = ST + nxRtpSizexRtpT / RSF 。
13、 如權利要求11所述的方法，其特徵在於，還包括當計算得到所接收數據包發送時長RtpT大於客戶端的最小緩衝時間 MinBT,且所述流^某體伺服器之前數據包計算確定的發送最大時間點在當前收到數據包計算確定的發送時間點之後，則在RtpT內要發送的數據量RSF 為RSF = CUCxRtpSize + (NSFxMinBT)/麗axT-ST 。
14、 如權利要求13所述的方法，其特徵在於，期望的發送碼率為RSF / RtpT，按照下式計算確定所述流媒體伺服器中數據的希望發送時間點ESTn = ST + nxRtpSizexMinBT / RSF 。
15、 一種數據傳輸系統，包括流i某體伺服器其特徵在於， 所述流媒體伺服器接收來自編碼器的數據包並緩存； 獲取編碼器預告的傳輸數據流量信息；根據所接收到的數據包大小、輸出信道的實時傳輸速率確定所述數據包 的發送時間；所述流媒體伺服器按照所確定的發送時間將數據包發送給所述客戶端。
16、 如權利要求15所述的系統，其特徵在於，還包括 所述編碼器，用於進行數據編碼，並將編碼後得到的數據包及傳輸數據流量信息提供給所述流媒體伺服器；所述編碼器通過擴展所述數據包頭攜帶傳輸數據流量信息發送給所述 流媒體伺服器；或，所述編碼器根據所緩存數據包的數據量實時發送所述傳輸數據流量信 息給所述流媒體伺服器。
17、 如權利要求15所述的系統，其特徵在於，所述流媒體伺服器接收來 自所述編碼器的數據包並緩存，具體包括每接收到一個數據包時，將所述數據包緩存，然後根據每個並發用戶生 成一條發包記錄，存入發包緩衝區，每條發包記錄包括RTP指針、用戶信 息、頻道信息。
18、 如權利要求15所述的系統，其特徵在於，所述流媒體伺服器根據計算得到所接收數據包發送時長RtpT、客戶端 的最小緩衝時間MinBT,數據包計算確定的發送時間點，實時對發送數據 的速率進行調整。
19、 一種實現數據傳輸的裝置，其特徵在於，包括接收單元，用於接收來自編碼器的數據包及後續數據流量信息；緩存單元，用於緩存所述接收單元接收的數據包；數據流量控制單元，根據所接收到的數據包大小或/和輸出信道的實時 碼率或/和後續流量信息控制所述數據包的發送時間或/和速率；發送單元，在所述數據流量控制單元將所述緩存單元緩存的數據包發送 給客戶端。
20、 如權利要求19所述的裝置，其特徵在於，還包括控制單元，用於控制所述發送單元的發包線程，在希望發包時間之前， 啟動發包線程。
21、 一種編碼裝置，其特徵在於，包括 存儲單元，用於存儲待編碼的音、視頻數據； 編碼單元，用於對所述音、視頻數據進行編碼； 數據流量上報單元，根據所述存儲單元保存的音、視頻數據實時發送數據流量信息；發送單元，用於輸出編碼後的數據流。
22、 如權利要求21所述的編碼裝置，其特徵在於，所述數據流量信息 包括所述存儲單元中所存儲待編碼的音、視頻數據量，以及所述發送單元輸 出數據的速率。
全文摘要
本發明公開了一種數據傳輸的方法、系統及裝置。該方法包括流媒體伺服器接收來自編碼器的數據包並緩存；獲取所述編碼器預告的傳輸數據流量信息；根據所接收到的數據包大小、所述編碼器的傳輸數據流量信息、輸出信道的實時碼率確定所述數據包的發送時間或/和調整數據發送速率，根據所確定的發送時間或/和發送速率發送數據。本發明還公開了相應的系統和裝置。根據本發明，可實現數據傳輸流量平滑，滿足直播業務對實時數據傳輸的要求，達到良好的直播效果。
文檔編號H04L12/56GK101296184SQ20081011032
公開日2008年10月29日 申請日期2008年5月30日 優先權日2008年5月30日
發明者剛 仇, 劉啟銘, 羅澤文 申請人:華為技術有限公司