專利名稱：無線流媒體關(guān)鍵參數(shù)統(tǒng)計及其傳遞的改進(jìn)方法
技術(shù)領(lǐng)域：
本發(fā)明涉及移動通信技術(shù)領(lǐng)域，尤其涉及無線流媒體關(guān)鍵參數(shù)統(tǒng)計及其傳遞的改進(jìn)方法。
背景技術(shù)：
無線流媒體，是目前國內(nèi)比較看好的3 G的殺手級業(yè)務(wù)之一，在未來的帶寬下，將目前 廣受歡迎的有線的V0D點播問題推廣到無線的移動環(huán)境下，可以滿足用戶移動終端音頻、視 頻需求。
目前，常規(guī)的無線流媒體的傳輸技術(shù)普遍采用基于TCP (傳輸控制協(xié)議)之上的RTSP實 時流協(xié)議)，基于UDP (用戶數(shù)據(jù)協(xié)議)之上的RTCP (實時傳輸控制協(xié)議)、RTP (實時傳輸協(xié) 議)協(xié)議。這個協(xié)議棧中，RTSP負(fù)責(zé)移動終端與流媒體服務(wù)器之間的會話鏈路的建立，RTP 負(fù)責(zé)會話過程的數(shù)據(jù)包的傳遞，RTCP負(fù)責(zé)終端信息的反饋信息。
對于一個商用的系統(tǒng)而言，流媒體服務(wù)器的整套解決方案不僅需要用戶點播的請求在IP 域通過"盡力而為"原則傳送，在無線域通過"前向糾錯"的原則傳送，最終保證用戶有一 個比較好的視頻體驗；除此之外，也需要流媒體服務(wù)器對用戶點播(直播)過程中的情況進(jìn) 行了解。由于RTP協(xié)議本身采用數(shù)據(jù)報文的形式，因此流媒體服務(wù)器本身在傳遞過程中，終 端的接收質(zhì)量如何無從可知。為了改善此種情況，RTCP協(xié)議要求終端在傳輸過程中，每隔一 定的時間(目前協(xié)議定義為5秒)向服務(wù)器通知一次丟失數(shù)據(jù)包的情況，服務(wù)器根據(jù)此反饋 消息進(jìn)行相應(yīng)的調(diào)整，得到終端用戶服務(wù)的大致情況。
但是，由于UDP協(xié)議本身是不可靠的協(xié)議，終端向服務(wù)器反饋的參數(shù)可靠性也就弱化， 這些對于服務(wù)器及時根據(jù)網(wǎng)絡(luò)情況，進(jìn)行相應(yīng)的服務(wù)質(zhì)量的調(diào)整是不利的。同時，RTCP協(xié)議 的報文長度的有限性，也使得服務(wù)器不可能接收到非常多的統(tǒng)計參數(shù)。
為了解中斷服務(wù)質(zhì)量的高低，作為服務(wù)器而言，希望得到越來越多的統(tǒng)計數(shù)值，基于終 端反饋的參數(shù)，調(diào)整碼率，適應(yīng)用戶的要求。
為了詳細(xì)說明服務(wù)器需要反饋的參數(shù)問題，我們將反饋的參數(shù)分為兩類:
第一類參數(shù)是常規(guī)性參數(shù)，這類參數(shù)的特定是每個RTCP的定時器時間會將參數(shù)，通過 RTCP協(xié)議發(fā)送到流媒體服務(wù)器的平臺。無論發(fā)送最終是否被服務(wù)器接收，這個報文一個周期 內(nèi)只發(fā)送一次。這類參數(shù)主要包括丟失率，累計丟失的數(shù)據(jù)包的個數(shù)，延遲抖動等協(xié)議要求的參數(shù)。
第二類參數(shù)是一次性統(tǒng)計參數(shù)。這類參數(shù)的特點是等到用戶消息結(jié)束后，發(fā)送的用戶在 點播(直播)過程的特性參數(shù)。包括用戶的緩沖次數(shù)，用戶的延遲總時間，用戶接收的總的字 節(jié)數(shù)，用戶接收的總的數(shù)據(jù)包個數(shù)，用戶終端的平均丟包率，用戶的平均服務(wù)質(zhì)量等等參數(shù)。 此類參數(shù)沒有明確的統(tǒng)一的反饋方法，本發(fā)明包括但也不限定上述提到的參數(shù)。
目前，對于無線流媒體而言，運營上提出的計費依據(jù)主要是按次，按時間、按長度、按 流量、包月等方式。但實際的測試中，我們明顯感覺到基于服務(wù)質(zhì)量的計費是一種更加適合 流媒體業(yè)務(wù)的計費方式。對于同樣的節(jié)目，終端顯示質(zhì)量高、感受好的用戶與體驗低、感受 一般的用戶，不應(yīng)該采取同樣的計費策略。所以，對未來采用基于服務(wù)質(zhì)量的計費模式，如 何更加準(zhǔn)確的計量到第二類參數(shù)就更為重要。
另外，對于一個商用的流媒體系統(tǒng)而言，第二類參數(shù)是對服務(wù)過程中服務(wù)質(zhì)量的總體了 解，比第一類參數(shù)的過程性了解更加全面，這些參數(shù)掌握得越多，服務(wù)器中的自我學(xué)習(xí)就越 強(qiáng)，能夠比較能動得適應(yīng)終端用戶的要求，從這個角度而言，這類統(tǒng)計參數(shù)的獲取與傳遞也 就顯得更為重要。
目前，第一類統(tǒng)計參數(shù)的傳遞有明確的RTCP協(xié)議作保證，但是對于第二類統(tǒng)計參數(shù)而言， 一些服務(wù)器本身并沒有提供。即使提供第二類統(tǒng)計參數(shù)的商用系統(tǒng)，也普遍是將統(tǒng)計參數(shù)放 到客戶端一側(cè)，這類參數(shù)再通過一個自定義的協(xié)議包發(fā)送到服務(wù)器，適應(yīng)性不強(qiáng)。

發(fā)明內(nèi)容
為了克服現(xiàn)有技術(shù)中的缺陷和不足，本發(fā)明的目的在于提供一種無線流媒體關(guān)鍵參數(shù)統(tǒng) 計及其傳遞的改進(jìn)方法，以減輕客戶端在流媒體播放過程中的計算能力，并保證無線流媒體 統(tǒng)計參數(shù)的可靠傳輸。
為了達(dá)到上述發(fā)明目的，本發(fā)明采用以下技術(shù)方案
無線流媒體關(guān)鍵參數(shù)統(tǒng)計及其傳遞的改進(jìn)方法，包括
(1) 定義實時流協(xié)議的自定義擴(kuò)展特性，確定統(tǒng)計參數(shù)的放置位置，并由服務(wù)器計算出 往返時間值；
(2) 服務(wù)器與客戶端進(jìn)行傳遞參數(shù)的協(xié)商，通過客戶端對RTCPSR協(xié)議的處理，設(shè)置數(shù) 據(jù)包字段的格式，并由客戶端提交網(wǎng)絡(luò)時間協(xié)議的值；
(3) 計算得到吞吐量，并通過調(diào)整吞吐量的值，使得當(dāng)前的實際碼流值大于節(jié)目需要的 最低碼流值；
(4) 服務(wù)器建立會話流，并向客戶端發(fā)送實時傳輸協(xié)議數(shù)據(jù)包；
(5) 在服務(wù)器與客戶端經(jīng)實時流協(xié)議協(xié)商確定的時間間隔后，客戶端向服務(wù)器發(fā)送實時 傳輸控制協(xié)議包或?qū)崟r流協(xié)議包，由服務(wù)器統(tǒng)計數(shù)據(jù)包的丟失情況；
(6) 會話流斷開后，服務(wù)器統(tǒng)計一次性參數(shù)，由服務(wù)器計算客戶端的相關(guān)參數(shù)。 其中，所述步驟(5)和步驟(6)之間還包括
(51)通過對實時傳輸控制地址解析協(xié)議的擴(kuò)展，服務(wù)器進(jìn)行緩沖時間的統(tǒng)計，以保證 客戶端的突然斷開，不造成服務(wù)器統(tǒng)計資源的錯誤。
其中，所述步驟(3)吞吐量的計算公式為<formula>see original document page 6</formula>
其中，S為平均數(shù)據(jù)報文大小；RTT為平均的時間周期；p為丟包率；T為吞吐量。
其中，所述平均的時間周期的計算方法為服務(wù)器根據(jù)客戶端提交的網(wǎng)絡(luò)時間協(xié)議的值， 計算得到當(dāng)前的往返時間值，并將當(dāng)前往返時間值與步驟(1)中得到的往返時間值進(jìn)行加權(quán) 平均，得到平均的時間周期。
其中，步驟(3)中所述的吞吐量的調(diào)整方法為將得到的吞吐量與客戶端請求的節(jié)目內(nèi) 容的碼流進(jìn)行比較，使得當(dāng)前的實際碼流值大于節(jié)目需要的最低碼流值。
其中，所述步驟(4)中服務(wù)器建立會話流包括端口的協(xié)商、音頻與視頻的負(fù)載格式、 音頻與視頻流的建立。
其中，所述步驟(5)具體為若客戶端向服務(wù)器發(fā)送一個實時傳輸控制協(xié)議包，則客戶 端填充丟包率、總的丟失數(shù)據(jù)包的個數(shù)，其他字段值置零；若客戶端向服務(wù)器發(fā)送實時^t協(xié) 議包，則由服務(wù)器在接收到此數(shù)據(jù)包后進(jìn)行統(tǒng)計，得到數(shù)據(jù)包的丟失情況。
其中，所述步驟(6)中的客戶端相關(guān)參數(shù)包括客戶的丟失包率、丟包數(shù)、接收的數(shù)據(jù) 包、緩沖次數(shù)。
與現(xiàn)有技術(shù)相比，采用本方法后，由于在參數(shù)統(tǒng)計過程中，大部分在服務(wù)器側(cè)完成，因 此減小了移動終端的計算量，也有利于會話結(jié)束后一個RTT (平均的時間周期)時間內(nèi)，曰志工作的完成；在參數(shù)的傳遞過程中，使用RTSP與RTCP協(xié)議的擴(kuò)展，顯示了比較好的靈活性，終端的支持比較容易實現(xiàn)。通過對于統(tǒng)計參數(shù)的統(tǒng)計參數(shù)統(tǒng)計位置的轉(zhuǎn)變，提高了統(tǒng)計參數(shù)傳遞的可用性、可靠性，提高了曰志寫入的速度，減輕了移動終端在流媒體播放過程中的計算能力，延長了終端節(jié)目的播放時間。同時，解決了服務(wù)器對于客戶端整體節(jié)目播放的服務(wù)質(zhì)量的了解與學(xué)習(xí)的問題。


圖1是本發(fā)明無線流媒體關(guān)鍵參數(shù)統(tǒng)計及其傳遞的改進(jìn)方法的流程圖。
具體實施例方式
本發(fā)明的設(shè)計思想如下對于無線流媒體的統(tǒng)計參數(shù)，本發(fā)明提出一種新的統(tǒng)計數(shù)值的放置位置與傳遞方法?？紤]到移動設(shè)備的電力有限性，計算能力也比較弱的特點，將統(tǒng)計的計算量全部放到服務(wù)器側(cè)來完成。同時，將終端需要為服務(wù)器傳遞的參數(shù)減小，對RTCP協(xié)議 普遍的擴(kuò)展參數(shù)的方式進(jìn)行改造，同時啟用了RTCPAPP的數(shù)據(jù)包。這種方式的改造，對于終 端的要求很低，改變了當(dāng)前各種流媒體服務(wù)器對于終端具有定制的要求，更大程度的推廣了無線流媒體這項業(yè)務(wù)。同時，本發(fā)明也利用了TFRC的一些功能，在終端與流服務(wù)器之間拓展 了TFRC的性能，更加容易適應(yīng)碼率的調(diào)整，更好的適應(yīng)終端上無線信道不穩(wěn)定的特點。
本發(fā)明無線流媒體關(guān)鍵參數(shù)統(tǒng)計及其傳遞的改進(jìn)方法主要包括
利用RTSP協(xié)議的拓展特性，進(jìn)行一些自定義的擴(kuò)展，對于這些擴(kuò)展，沒有過多的增加終端的識別能力。如果終端不支持此種能力，給出了一定的替換辦法。
參考了 TFRC協(xié)議的特性，修改了TFRC協(xié)議中丟失率計算的方法，更加準(zhǔn)確的得出客戶端接收數(shù)據(jù)包的個數(shù)、丟失率等參數(shù)。
調(diào)整了RTCPSR (實時流控制協(xié)議準(zhǔn)備發(fā)送)協(xié)議的要求，對服務(wù)器做出了最簡單的簡化處理，終端對于此類協(xié)議能夠動態(tài)的進(jìn)行丟失與接收。
拓展了 RTCP APP協(xié)議，對高端移動設(shè)備，如果有能力支持可靠的數(shù)據(jù)包協(xié)議，則通過APP協(xié)議，加以自定義的改造。
對于服務(wù)器，能夠依據(jù)終端設(shè)備的情況，更加動態(tài)的進(jìn)行參數(shù)的統(tǒng)計。
本發(fā)明的具體過程如下
(1)定義了RTSP協(xié)議的自定義的擴(kuò)展特性，Location關(guān)鍵描述符，表示終端與服務(wù)器協(xié)商統(tǒng)計參數(shù)的放置位置，如果答復(fù)是Server,表示統(tǒng)計功能放置到服務(wù)器，否則放置到客
戶端。如果服務(wù)器或者終端對此屬性沒有200系列的正?；貜?fù)，表示雙方中有一方不支持， 統(tǒng)計的參數(shù)依然放置到服務(wù)器側(cè)進(jìn)行，對于客戶端傳回的統(tǒng)計參數(shù)，服務(wù)器可以作相應(yīng)處理，但不在本發(fā)明之列。服務(wù)器同時計算出RTT1。
(2) 服務(wù)器與客戶端進(jìn)行傳遞參數(shù)的協(xié)商。如果支持?jǐn)U展頭，則要求客戶端對于RTCPRR 協(xié)議進(jìn)行簡單處理，可以選擇填充丟失率和累計丟失數(shù)據(jù)包數(shù)，其余字段置零的方式；由于丟失率的計算，是一個比較復(fù)雜的浮點運算過程，因此也可以直接置零；此外，也可以選用 RTSP提交a=ssrc的一個結(jié)構(gòu)體數(shù)值。在這個數(shù)據(jù)包的協(xié)商過程中，客戶端需要提交NTP(網(wǎng)絡(luò)時間協(xié)議)的數(shù)值。
(3) 服務(wù)器根據(jù)NTP的數(shù)值，消除掉服務(wù)器處理時間，雙方時鐘的時間差異，計算出 RTT2。服務(wù)器將步驟(1)中得到的RTT值和RTT2的值采用一定的加權(quán)平均，得出當(dāng)前的RTT 值，采用TFRC的吞吐量計算公式計算出發(fā)送的碼率。公式如下<formula>see original document page 8</formula>
公式中各個字段的含義如下
其中，S為平均數(shù)據(jù)報文大??；RTT為平均的時間周期；p為丟包率；T為吞吐量。
同時將此T值(字節(jié)/秒)存儲到服務(wù)器的服務(wù)質(zhì)量的字段部分。這個字段采用但不限定堆棧的方式。
(4) 服務(wù)器將吞吐量值與客戶端請求的節(jié)目內(nèi)容的碼流進(jìn)行相應(yīng)的對比，如果請求的節(jié)目碼率為Rclient，節(jié)目需要的最低碼流為Rmedia，當(dāng)前的實際碼流是Rreal。為了說明服務(wù)器的判斷標(biāo)準(zhǔn)，考慮實際的情況，應(yīng)該滿足Rreal＞Rmedia。
在下面的情況采用特殊的方法處理
if Rreal＞Rclient＞Rmeidia
Rreal= (1+a) Rclient a＞0;
這種方式在服務(wù)器與終端之間可以協(xié)商，能夠加快媒體節(jié)目的快速啟動，減少終端的延遲時間。
(5) 服務(wù)器進(jìn)行會話流的建立。主要包括端口的協(xié)商、音頻與視頻的負(fù)載格式，音頻與視頻流的建立等。這些過程完成后，服務(wù)器開始發(fā)送RTP的包，終端播放內(nèi)容。
(6) 到達(dá)一定的時間(服務(wù)器與終端在會話建立過程中通過RTSP協(xié)商)，客戶端向服 務(wù)器發(fā)送一個RTCP包，也可以發(fā)送一個自定義的RTSP包。如果發(fā)送的是RTCP包，客戶端可 以將相應(yīng)字段的值置零，只需要填充丟包率、總的丟失的數(shù)據(jù)包的個數(shù)兩個字段的值。對于 丟失率的計算終端設(shè)備只要通過SR包中高質(zhì)的發(fā)送最大的數(shù)據(jù)包的包號，簡單計算即可。總 的丟失的數(shù)據(jù)包的個數(shù)是一個累計值，終端只需要在會話過程中維持一個變量的值即可，因 此，如此使得客戶端得計算量大大減輕，也減少了終端設(shè)備的內(nèi)容使用量。如果客戶端使用 的是RTSP的自定義方式，則根據(jù)會話建立過程中的SSRC個數(shù)，組成一個簡單的結(jié)構(gòu)體，結(jié) 構(gòu)如下
SSRC—1: lost_packetl
SSRC—n: lost—packetn
服務(wù)器接收到此數(shù)據(jù)包后，進(jìn)行統(tǒng)計，即可得到數(shù)據(jù)包的丟失情況。并且，根據(jù)當(dāng)前數(shù) 據(jù)包的發(fā)送情況，計算出從客戶端到達(dá)服務(wù)器的時間，按照上述第3步的公式，計算出新的 TFRC對應(yīng)的碼流Tnew。服務(wù)器根據(jù)相應(yīng)新的碼流值，在已有的服務(wù)器的碼流隊列的基礎(chǔ)上， 采用一定的加權(quán)算法，計算出新的碼率值。服務(wù)器采用新的碼率值進(jìn)行數(shù)據(jù)包的發(fā)送。
(7) 為了保證客戶端的突然斷開，不造成服務(wù)器統(tǒng)計資源的錯誤，改造空余的RTCPAPP 協(xié)議。服務(wù)器對這個協(xié)議實行定時詢問制度，也可以采用客戶端主動發(fā)送方式。采用的方式 不屬于本發(fā)明涉及的范疇，但是采用的方式在RTSP中會話開始前已經(jīng)完成協(xié)商。
這個協(xié)議中的拓展字段，主要進(jìn)行緩沖時間的統(tǒng)計。 一旦流播放器的內(nèi)容下溢，則定時 器開始工作，計算出流服務(wù)器的緩沖時間。如果客戶端采用主動上報的方式，則不需要進(jìn)行 任何額外累計，終端的計算量非常小，但是在網(wǎng)絡(luò)情況不是很好，客戶端經(jīng)常緩沖時候，RTCP 的APP包會占用比較大的帶寬，更加不利于下溢時的帶寬使用。如果采用定時査詢的方式， 終端需要一個內(nèi)存變量來維護(hù)，但只是簡單的累加計算，因此不會給終端設(shè)備造成比較大的 負(fù)擔(dān)。
除此之外的參數(shù)，客戶端或者服務(wù)器需要的，也可以通過RTCP的APP協(xié)議自定義進(jìn)行擴(kuò) 展，完成相應(yīng)的參數(shù)傳遞。
(8) 持續(xù)上述的步驟一直到服務(wù)器發(fā)送節(jié)目源的結(jié)束，或者用戶點播放棄、網(wǎng)絡(luò)遺矢等 情況為止，此時，會話流已經(jīng)斷開。
(9) 一旦會話斷開，流媒體服務(wù)器需要開始統(tǒng)計一次性參數(shù)。這些參數(shù)中，從簡便的角
度，客戶的丟失包率，丟包數(shù)，接收的數(shù)據(jù)包，緩沖次數(shù)等，都可以在終端進(jìn)行完成。但是
由于終端計算這些參數(shù)，需要在RTCP的BYE數(shù)據(jù)包前進(jìn)行完成，加重了客戶端的計算壓力， 因此改變到服務(wù)器端完成比較合理。
對于丟包率，由于每個定時周期的時間內(nèi)，已經(jīng)有了相應(yīng)的參數(shù)，服務(wù)器通過堆棧已經(jīng) 建立起了相應(yīng)的數(shù)值，進(jìn)行簡單的處理即可；對于緩沖次數(shù)，服務(wù)器可以通過在每次緩沖時， 客戶端發(fā)送的RTSP協(xié)議的請求進(jìn)行累計；對于體現(xiàn)網(wǎng)絡(luò)服務(wù)質(zhì)量的RTT或者X值，由于定時 周期內(nèi)，保存了每個周期內(nèi)的平均RTT，所以很容易得到最大的RTT，最小的RTT，并且計算 出平均RTT數(shù)值。對于本發(fā)明中，沒有提及的參數(shù)，也可以采用類似的方法來實現(xiàn)。
實施例一
(1) 終端發(fā)起會話請求 ＃C-〉S:
DESCRIBE rtsp:〃10. 24. 2.100/sample—100. 3GP RTSP/1. 0 CSeq: l\r\n
Accept: application/sdp\r\n Bandwidth: 2147483647\r\n Accept-Language: en-US\r\n User-Agent: Paraml Retquire : Location
(2) 服務(wù)器獲取到終端的請求，取出相應(yīng)的字段，特別關(guān)注User-Agent字段，這個字 段提供了終端的服務(wù)能力。如果這個字段服務(wù)器的能力識別數(shù)據(jù)庫中存在，則發(fā)出類似于如 下的答復(fù)(內(nèi)容的描述字段部分省略)。
#S-〉C:
RTSP/1.0 200 0K\r\n Cseq: l\r\n
Last-Modified: Wed， 12 Nov 2003 09:03:00 GMT\r\n Cache-Control: must-revalidate\r\n Content-length: 368\r\nDate: Thu， 27 May 2004 01:35:35 GMT\r\n
Expires: Thu， 27 May 2004 01:35:35 GMT\r\n
Content-Type: application/sdp\r\n
x-Accept-Retransmit: our-retransmit\r\n
x-Accept-Dynamic-Rate: l\r\n
Content-Base: rtsp//10. 24. 2. 100/sample_100. 3GP \r\n
\r\n
v=0\r\n
o=ABC 3294610534 1068627780000 IN IP4 10.24. 2. 100\r\n
s=\sample_100. 3GP\r\n
u=http:///\r\n
e=admin@\r\n
c=IN IP4 0.0.0.0\r\n
b=AS:94\r\n
t=0 0\r\n
a=control:*\r\n
a=range:npt=0- 66.47000\r\n
m=audio 0 RTP/AVP 96\r\n
b=AS:84\r\n
a=rtpmap:97 X-SV3V-ES/90000\r\n
a=control:trackID=4\r\n a=Location: Server
回復(fù)，表示服務(wù)器識別此功能，雙方的統(tǒng)計功能參數(shù)傳遞在服務(wù)器側(cè)進(jìn)行。如果服務(wù)器沒有找到關(guān)于Location的請求，發(fā)出如下的請求回復(fù) #S->C:
RTSP/L 0 200 0K\r\n Cseq: l\r\n Retquire : Location
在此情況下，如果終端設(shè)備作出如下答復(fù) RTSP/1.0 200 0K\r\n Cseq: 2\r\n
則表示終端設(shè)備支持統(tǒng)計功能的服務(wù)器位置，否則終端設(shè)備表示不明確Location參數(shù)的 含義，服務(wù)器默認(rèn)為終端設(shè)備不支持。
(3) 客戶端開始進(jìn)行參數(shù)的協(xié)商參數(shù)的協(xié)商包括了下面幾個，但不限于下面的這些。 可以進(jìn)行擴(kuò)展。
#C-〉S:
SETUP rtsp:〃10.24.2. 100/sample—100. 3GP /trackID=3 RTSP/1. 0\r\n CSeq: 2\r\n
Transport: RTP/AVP;unicast;c1ient_port=6974-6975\r\n x_retransmit: our-retranstnit\r\n x-dynamic-rate: l\r\n
x-transport-options: late-tolerance=5. 884000\r\n x_buffer-time: 4 \r\n x-rtt: 20 \r\n
(4) 服務(wù)器根據(jù)終端的響應(yīng)情況，其中，application部分表示相關(guān)的參數(shù)傳遞通過RTCP 的APP協(xié)議進(jìn)行。發(fā)出如下的請求(其余部分略)
#S->C: OPTIONS * RTSP/1. 0\r\n
Content-Type: application/x-random-data\r\n Content-Type: applica/tion/x-buffer-time \r\n Content-Length: 1400\r\n
(5) 服務(wù)器進(jìn)行自建立參數(shù)的設(shè)會話如下
#S->C:
SET—PARAMETER rt印〃10. 24. 2. 100/sample—100. 3GP /r/n
CSeq: 4 \r\n
Content-Type: Text/parameters
SSRC一l
SSRC—2
SSRC—3
說明，這個會話請求建立時，服務(wù)器已經(jīng)知道SSRC的貢獻(xiàn)源的個數(shù)，因此會話建立的個 數(shù)可以指定，由于普遍會話建立過程中，只涉及到音頻和視頻，因此貢獻(xiàn)源的個數(shù)不會很多。
客戶端對此會話參數(shù)建立的答復(fù)如下 #C->S:
RTSP/1.0 200 OK\r\n
CSeq: 4 \r\n
(6) 如果首次協(xié)商時，Location字段表示在服務(wù)器，則客戶端發(fā)送的數(shù)據(jù)包可以簡化 為下述形式。客戶端在RTP數(shù)據(jù)包傳送過程中，發(fā)送相應(yīng)數(shù)據(jù)包的格式如下
80 C9 00 06 ** ** ** ** $$ $$ $$ $$ 0# ## ## ##00 00…..00
** ** ** **字段，表示SSRC，在RTP包中可以取得。
$$ $$ $$ $$字段，也可以從RTP包中直接取得。
移動終端只需要計算#號字段的累積的丟包數(shù)，計算量完全減輕，其余字段用0填充。
(7) 客戶端在RTP的交互過程中，如果發(fā)送相應(yīng)的緩沖時間字段，可以如下形式
80 CC 00 04 ** ** ** ** && && && &&
*符號字段，表示SSRC，在RTP包中可以直接取得。
&符號字段，表示緩沖時間的名字，協(xié)商時已經(jīng)完成。
符號字段，表示緩沖時間對應(yīng)的數(shù)值。
(8) 為了更可靠的傳輸終端的狀態(tài)值，服務(wù)器通過RTSP協(xié)議獲取SSRC的丟包數(shù)值。形式如下
服務(wù)器向客戶端發(fā)送如下 #S-〉C:
GET—PARAMETER rtsp:〃10. 24. 2.100/sample—lOO. 3GP /r/n CSeq: 10 \r\n
Content-Type: Text/parameters SSRC—1 SSRC—2 SSRC—3
客戶端響應(yīng)服務(wù)器的請求如下
#C->S:
RTSP/1. 0 200 OK\r\n CSeq: 10 \r\n Content-Type: Text/parameters SSRC—1 30 SSRC一2 50 SSRC—3 60
當(dāng)然，本發(fā)明還可有其他多種實施例，在不背離本發(fā)明精神及其實質(zhì)的情況下，本領(lǐng)域 技術(shù)人員當(dāng)可根據(jù)本發(fā)明做出各種相應(yīng)的改變和變形，但這些相應(yīng)的改變和變形都應(yīng)屬于本 發(fā)明所附的權(quán)利要求的保護(hù)范圍。
權(quán)利要求
1. 無線流媒體關(guān)鍵參數(shù)統(tǒng)計及其傳遞的改進(jìn)方法，其特征在于，包括(1)定義實時流協(xié)議的自定義擴(kuò)展特性，確定統(tǒng)計參數(shù)的放置位置，并由服務(wù)器計算出往返時間值；(2)服務(wù)器與客戶端進(jìn)行傳遞參數(shù)的協(xié)商，通過客戶端對RTCP SR協(xié)議的處理，設(shè)置數(shù)據(jù)包字段的格式，并由客戶端提交網(wǎng)絡(luò)時間協(xié)議的值；(3)計算得到吞吐量，并通過調(diào)整吞吐量的值，使得當(dāng)前的實際碼流值大于節(jié)目需要的最低碼流值；(4)服務(wù)器建立會話流，并向客戶端發(fā)送實時傳輸協(xié)議數(shù)據(jù)包；(5)在服務(wù)器與客戶端經(jīng)實時流協(xié)議協(xié)商確定的時間間隔后，客戶端向服務(wù)器發(fā)送實時傳輸控制協(xié)議包或?qū)崟r流協(xié)議包，由服務(wù)器統(tǒng)計數(shù)據(jù)包的丟失情況；(6)會話流斷開后，服務(wù)器統(tǒng)計一次性參數(shù)，由服務(wù)器計算客戶端的相關(guān)參數(shù)。
2、 根據(jù)權(quán)利要求1所述的無線流媒體關(guān)鍵參數(shù)統(tǒng)計及其傳遞的改進(jìn)方法，其特征在于， 所述步驟(5)和步驟(6)之間還包括-(51)通過對實時傳輸控制地址解析協(xié)議的擴(kuò)展，服務(wù)器進(jìn)行緩沖時間的統(tǒng)計。
3、 根據(jù)權(quán)利要求1所述的無線流媒體關(guān)鍵參數(shù)統(tǒng)計及其傳遞的改進(jìn)方法，其特征在于， 所述步驟(3)吞吐量的計算公式為其中，S為平均數(shù)據(jù)報文大?。籖TT為平均的時間周期；p為丟包率；T為吞吐量。
4、 根據(jù)權(quán)利要求3所述的無線流媒體關(guān)鍵參數(shù)統(tǒng)計及其傳遞的改進(jìn)方法，其特征在于 所述平均的時間周期的計算方法為服務(wù)器根據(jù)客戶端提交的網(wǎng)絡(luò)時間協(xié)議的值，計算得到當(dāng)前的往返時間值，并將當(dāng)前往返時間值與步驟(1)中得到的往返時間值進(jìn)行加權(quán)平均，得 到平均的時間周期。
5、 根據(jù)權(quán)利要求1所述的無線流媒體關(guān)鍵參數(shù)統(tǒng)計及其傳遞的改進(jìn)方法，其特征在于 步驟(3)中所述的吞吐量的調(diào)整方法為將得到的吞吐量與客戶端請求的節(jié)目內(nèi)容的碼流進(jìn)行比較，使得當(dāng)前的實際碼流值大于節(jié)目需要的最低碼流值。
6、 根據(jù)權(quán)利要求1所述的無線流媒體關(guān)鍵參數(shù)統(tǒng)計及其傳遞的改進(jìn)方法，其特征在于所述步驟(4)中服務(wù)器建立會話流包括端口的協(xié)商、音頻與視頻的負(fù)載格式、音頻與視頻 流的建立。
7、 根據(jù)權(quán)利要求1所述的無線流媒體關(guān)鍵參數(shù)統(tǒng)計及其傳遞的改進(jìn)方法，其特征在于 所述步驟(5)具體為若客戶端向服務(wù)器發(fā)送一個實時傳輸控制協(xié)議包，則客戶端填充丟包 率、總的丟失數(shù)據(jù)包的個數(shù)，其他字段值置零；若客戶端向服務(wù)器發(fā)送實時流協(xié)議包，則由 服務(wù)器在接收到此數(shù)據(jù)包后進(jìn)行統(tǒng)計，得到數(shù)據(jù)包的丟失情況。
8、 根據(jù)權(quán)利要求1所述的無線流媒體關(guān)鍵參數(shù)統(tǒng)計及其傳遞的改進(jìn)方法，其特征在于 所述步驟(6)中的相關(guān)參數(shù)包括客戶的丟失包率、丟包數(shù)、接收的數(shù)據(jù)包、緩沖次數(shù)。
全文摘要
本發(fā)明公開了無線流媒體關(guān)鍵參數(shù)統(tǒng)計及其傳遞的改進(jìn)方法，為減輕客戶端在流媒體播放過程中的計算能力，實現(xiàn)無線流媒體統(tǒng)計參數(shù)的可靠傳輸而發(fā)明。包括(1)確定統(tǒng)計參數(shù)的放置位置，并由服務(wù)器計算出往返時間值；(2)服務(wù)器與客戶端進(jìn)行傳遞參數(shù)的協(xié)商，并由客戶端提交網(wǎng)絡(luò)時間協(xié)議的值；(3)計算得到吞吐量；(4)服務(wù)器建立會話流，并向客戶端發(fā)送實時傳輸協(xié)議數(shù)據(jù)包；(5)客戶端向服務(wù)器發(fā)送實時傳輸控制協(xié)議包或?qū)崟r流協(xié)議包，由服務(wù)器統(tǒng)計數(shù)據(jù)包的丟失情況；(6)會話流斷開后，服務(wù)器統(tǒng)計一次性參數(shù)，由服務(wù)器計算客戶端的相關(guān)參數(shù)。本發(fā)明轉(zhuǎn)變了統(tǒng)計參數(shù)的統(tǒng)計位置，提高了統(tǒng)計參數(shù)傳遞的可用性、可靠性。
文檔編號H04L12/24GK101207506SQ20061016578
公開日2008年6月25日 申請日期2006年12月18日 優(yōu)先權(quán)日2006年12月18日
發(fā)明者劉繼興, 云 葉, 孫瑞囡, 王淑棉, 崗 隆, 魯照華 申請人:中興通訊股份有限公司