本發(fā)明涉及通信領(lǐng)域，尤其涉及一種互動桌面同步方法。

背景技術(shù)：

目前基于Miracast等協(xié)議的桌面同步，只能在同一網(wǎng)段的局域網(wǎng)內(nèi)使用，由于采用基于UDP的RTP協(xié)議（Real-time Transport Protocol 實時傳輸協(xié)議）傳輸，在WiFi環(huán)境下，丟包會造成畫面缺失不完整，且造成主投端和被投終端（接收端）媒體數(shù)據(jù)播放不同步。即在接收端收到媒體包后,進行解碼、放入緩沖等待被播放，理想情況下，收到包后立刻解碼播放，即緩沖區(qū)應(yīng)該始終為空，所以，緩沖區(qū)里的緩沖媒體數(shù)據(jù)有多少就是延時多少，要降低延時, 就要控制這個緩沖的大小，延時可以接受的范圍為300ms-500ms，即緩沖區(qū)要控制在這個范圍內(nèi)。

技術(shù)實現(xiàn)要素：

針對現(xiàn)有技術(shù)中存在的缺陷或不足，本發(fā)明所要解決的技術(shù)問題是：提供一種互動桌面同步方法，解決現(xiàn)有技術(shù)播放延時的技術(shù)問題。

為了達上述目的，本發(fā)明采取的技術(shù)方案為提供一種互動桌面同步方法，包括如下步驟：

A）通過服務(wù)器獲取同步系統(tǒng)終端的信息，并在所述同步系統(tǒng)終端中選出主投端或被投終端；通過多網(wǎng)段自動發(fā)現(xiàn)技術(shù)獲取同一網(wǎng)絡(luò)下所有終端的信息，以便于新加入的終端獲取整個網(wǎng)絡(luò)下終端的信息；

B）主投端與被投終端之間建立連接；

C）主投端采集桌面數(shù)據(jù)放入緩沖區(qū)中，并對所述數(shù)據(jù)進行編碼和封裝，將封裝成的媒體包發(fā)送到被投終端；

D）被投終端的解碼播放端將接收到的媒體包存入緩沖區(qū)進行解碼播放，若緩沖區(qū)的長度超過設(shè)定的閾值，則進入追趕模式加速媒體數(shù)據(jù)播放速度；及時降低了延時，使主投端與被投終端之間的畫面更加同步，保證了互動的及時性和流暢性。

作為本發(fā)明的進一步改進，步驟A包括：

A1：服務(wù)器向所述同步系統(tǒng)終端所在網(wǎng)段發(fā)送廣播包，所述同步系統(tǒng)終端收到所述廣播包將自身的信息回報給服務(wù)器，服務(wù)器對所述信息進行存儲；

A2：服務(wù)器向其它網(wǎng)段的所有終端的主機地址發(fā)送UDP消息；

A3：所述同步系統(tǒng)終端設(shè)有TCP監(jiān)聽服務(wù)監(jiān)聽所述同步系統(tǒng)終端上的端口，當(dāng)所述端口收到廣播包時給服務(wù)器返回響應(yīng)消息。

A4：設(shè)定的時間，返回執(zhí)行步驟A1-A3，服務(wù)器根據(jù)同步系統(tǒng)終端的響應(yīng)消息判斷是否有異常下線的同步系統(tǒng)終端。

作為本發(fā)明的進一步改進，所述主投端通過TCP協(xié)議或RTP協(xié)議將媒體包傳輸?shù)奖煌督K端，當(dāng)不注重畫質(zhì)以及丟包的情況下,選擇RTP傳輸，注重畫質(zhì)的質(zhì)量時,選擇穩(wěn)定的TCP協(xié)議。

作為本發(fā)明的進一步改進，步驟B）中所述連接為媒體連接。

作為本發(fā)明的進一步改進，所述主投端為每個媒體連接建立幀緩沖，發(fā)送媒體包時，若存入幀緩沖的媒體包數(shù)量超過2M字節(jié)，便主動清理不發(fā)送。

作為本發(fā)明的進一步改進，步驟C）中所述封裝為TLV封裝，TLV是指由數(shù)據(jù)的類型Tag，數(shù)據(jù)的長度Length，數(shù)據(jù)的值Value組成的結(jié)構(gòu)體，幾乎可以描任意數(shù)據(jù)類型，TLV的Value也可以是一個TLV結(jié)構(gòu)，正因為這種嵌套的特性，可用于包裝協(xié)議的實現(xiàn)。

作為本發(fā)明的進一步改進，步驟C）還包括：

C1：采集桌面數(shù)據(jù)時，控制輸入到緩沖區(qū)中桌面數(shù)據(jù)的長度；

C2：判斷所述桌面數(shù)據(jù)的長度是否超過閾值；

C3：若超過閾值，則拋棄先接收的幀；提高了媒體傳輸?shù)募皶r性，降低了時間延遲。

作為本發(fā)明的進一步改進，所述媒體數(shù)據(jù)包括視頻數(shù)據(jù)與音頻數(shù)據(jù)，通過調(diào)高輸出采樣率加速音頻數(shù)據(jù)的播放，步驟D）中所述閾值在300ms-500ms之內(nèi)。

本發(fā)明的有益效果是：本發(fā)明降低了傳輸延遲，保證了不同情形下主投端與被投終端之間信息的實時性。

附圖說明

圖1是本發(fā)明提供的互動桌面同步方法流程圖。

具體實施方式

下面結(jié)合附圖說明及具體實施方式對本發(fā)明進一步說明。

如圖1所示，本發(fā)明為互動桌面同步方法的流程圖，包括以下步驟：

步驟A）通過服務(wù)器獲取同步系統(tǒng)終端的信息，并在所述同步系統(tǒng)終端中選出主投端或被投終端；通過多網(wǎng)段自動發(fā)現(xiàn)技術(shù)獲取同一網(wǎng)絡(luò)下所有終端的信息，以便于新加入的終端獲取整個網(wǎng)絡(luò)下終端的信息。

服務(wù)器向整個同一網(wǎng)段的主機發(fā)送廣播包，端口號為5550，所述廣播包可以被路由，可以經(jīng)由路由器到達本網(wǎng)段內(nèi)所有的主機，所述主機可以是同步客戶端也可以是其他服務(wù)器終端，所述終端設(shè)有TCP監(jiān)聽服務(wù)，用于監(jiān)聽所述5550端口，當(dāng)5550端口接收到廣播包后及時給服務(wù)器返回響應(yīng)消息，并將自身的地址信息、身份信息以及分組等信息回報給所述服務(wù)器，服務(wù)器將這些信息存儲起來；服務(wù)器還向其他網(wǎng)段的終端發(fā)送UDP消息，端口5550，這樣新加入本網(wǎng)絡(luò)中的終端就可以獲取到整個網(wǎng)絡(luò)下的同步客戶端或者服務(wù)器等終端，且這種發(fā)現(xiàn)掃描會定期執(zhí)行，其周期是1至3分鐘，用于防止應(yīng)用崩潰而沒有正常退出等異常情況。

步驟B） 主投端與被投終端之間建立連接，所述主投端為每一個連接建立幀緩沖；這樣的設(shè)置使得ＣＰＵ過高時自動降低采集頻率，而不至于緩沖過多而導(dǎo)致延遲。

步驟C）主投端采集桌面數(shù)據(jù)放入緩沖區(qū)中，并對所述數(shù)據(jù)進行編碼和封裝，將封裝成的媒體包發(fā)送到被投終端；采集桌面數(shù)據(jù)時，控制輸入到緩沖區(qū)中桌面數(shù)據(jù)的長度，判斷所述桌面數(shù)據(jù)的長度是否超過閾值，若超過閾值，則拋棄較老的幀；即在CUP使用較高時，自動降低采集頻率，并拋棄先采集的幀，而不至于緩沖過多而導(dǎo)致延時，提高了媒體傳輸?shù)募皶r性，降低了時間延遲。所述桌面數(shù)據(jù)包括桌面畫面、聲音，即正在運行的可視可聽的媒體數(shù)據(jù)以及打開視頻播放軟件正在播放的視頻和聲音等，并對所述桌面數(shù)據(jù)進行編碼和封裝，啟動主投端與被投終端之間的連接，所述連接包括信令連接、IO連接以及媒體連接，所述主投端為每個媒體連接建立幀緩沖，將封裝成的媒體包發(fā)送到被投終端，所述封裝方法為TLV；TLV是指由數(shù)據(jù)的類型Tag，數(shù)據(jù)的長度Length，數(shù)據(jù)的值Value組成的結(jié)構(gòu)體，幾乎可以描任意數(shù)據(jù)類型，TLV的Value也可以是一個TLV結(jié)構(gòu)，正因為這種嵌套的特性，可以讓我們用來包裝協(xié)議的實現(xiàn)，TLV是由數(shù)據(jù)的類型Tag，數(shù)據(jù)的長度Length以及數(shù)據(jù)的值Value組成的結(jié)構(gòu)體，length是value域的長度，Value是數(shù)據(jù)本身，Length域的編碼比較簡單,最多有四個字節(jié)，所以使用TLV方式封裝采集到的數(shù)據(jù)，使得編碼和解碼機制簡單易實現(xiàn)，且數(shù)據(jù)編解速度快，占用空間?。环庋b完成后發(fā)送到被投終端，所述主投端通過TCP協(xié)議或RTP協(xié)議將桌面數(shù)據(jù)傳輸?shù)奖煌督K端，當(dāng)不注重畫質(zhì)以及丟包的情況下,選擇RTP傳輸，注重畫質(zhì)的質(zhì)量時,選擇穩(wěn)定的TCP協(xié)議，兩個傳輸協(xié)議之間可自動切換；RTP，用于實時傳輸數(shù)據(jù)，RTP傳輸協(xié)議是一種基于UDP的傳輸協(xié)議，RTP本身并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務(wù)；這樣，對于那些丟失的數(shù)據(jù)包，不存在由于超時檢測而帶來的延時，同時，對于那些丟棄的包，也可以由上層根據(jù)其重要性來選擇性的重傳，比如，對于I幀、P幀、B幀數(shù)據(jù)，由于其重要性依次降低，故在網(wǎng)絡(luò)狀況不好的情況下，可以考慮在B幀丟失甚至P幀丟失的情況下不進行重傳，這樣，在被投終端，雖然可能會有短暫的不清晰畫面，但卻保證了實時性的體驗和要求；而TCP傳輸協(xié)議為了實現(xiàn)網(wǎng)絡(luò)通信的可靠性，使用了復(fù)雜的擁塞控制算法，建立了繁瑣的握手過程以及重傳策略，是以在網(wǎng)絡(luò)允許的情況下使用TCP傳輸協(xié)議，在網(wǎng)絡(luò)較差的情況下使用傳輸效果稍次但是傳輸速度強于TCP協(xié)議的RTP傳輸協(xié)議，這樣可以在不同的場景下滿足不同的用戶的需求；但在發(fā)送過程中，所述幀緩沖中的媒體包的大小超過2M字節(jié)時，則主動將這此包丟棄不發(fā)送，以保證主投端與被投終端之間的信息的同步性。

步驟D) 被投終端的解碼播放端將接收到的媒體包存入緩沖區(qū)進行解碼播放，若緩沖區(qū)的長度超過設(shè)定的閾值，則進入追趕模式加速媒體數(shù)據(jù)播放速度；解碼播放端將通過TLV封裝成的媒體包存儲到被投終端上的緩沖區(qū)內(nèi)，并解碼為播放器可播放的格式，即媒體數(shù)據(jù)，然后對其進行播放，在理想情況下，被投終端接收到媒體包后應(yīng)立刻對其進行解碼并播放，即被投終端緩沖區(qū)里的媒體數(shù)據(jù)始終是空的，所以, 緩沖區(qū)內(nèi)的媒體數(shù)據(jù)的大小是多少就是延時多少，若要降低延時，就要控制所述緩沖區(qū)長度；即當(dāng)緩沖區(qū)長度超過閾值則進入追趕模式，加速媒體數(shù)據(jù)播放，而對媒體數(shù)據(jù)中的音頻數(shù)據(jù)進行加速播放時，具體方法是調(diào)高輸出采樣率加速播放，即對緩沖區(qū)內(nèi)的音頻數(shù)據(jù)進行重采樣，常用的重采樣方法有最鄰近內(nèi)插法、雙線性內(nèi)插法和三次卷積法內(nèi)插，其中，最鄰近內(nèi)插法最為簡單，計算速度快，但是視覺效應(yīng)差；雙線性插值會使圖像輪廓模糊；三次卷積法產(chǎn)生的圖像較平滑，有好的視覺效果，但計算量大，較費時；若緩沖區(qū)長度超過閾值，則將音頻采樣率變換成新的采樣率以適應(yīng)不同采樣率的要求，并加快音頻數(shù)據(jù)的播放速度，直到緩沖區(qū)內(nèi)緩沖區(qū)長度在閾值之內(nèi)，才恢復(fù)正常播放速度，所述閾值的范圍在300ms-500ms之間。

以上內(nèi)容是結(jié)合具體的優(yōu)選實施方式對本發(fā)明所作的進一步詳細說明，不能認定本發(fā)明的具體實施只局限于這些說明。對于本發(fā)明所屬技術(shù)領(lǐng)域的普通技術(shù)人員來說，在不脫離本發(fā)明構(gòu)思的前提下，還可以做出若干簡單推演或替換，都應(yīng)當(dāng)視為屬于本發(fā)明的保護范圍。