本發(fā)明涉及一種多媒體系統(tǒng)中信息交互機制，更確切地說，涉及一種多媒體系統(tǒng)中信息交互機制及網(wǎng)絡(luò)傳輸方法。
背景技術(shù)：
：隨著云計算、物聯(lián)網(wǎng)、智能可穿戴設(shè)備等新一代應(yīng)用消費模式的興起，基于傳統(tǒng)的音視頻媒體的單向數(shù)據(jù)傳輸已經(jīng)不能滿足各種應(yīng)用的需求了。新一代多媒體傳輸系統(tǒng)中傳輸新型的數(shù)據(jù)傳輸格式應(yīng)該包括各種可能的數(shù)據(jù)類型，同時通信雙方需支持雙向通信來實現(xiàn)不同的業(yè)務(wù)邏輯與業(yè)務(wù)流程。實時信息交互越來越成為未來多媒體系統(tǒng)中數(shù)據(jù)交換的重要趨勢，其中用戶需要將交互數(shù)據(jù)實時上傳服務(wù)器，以便服務(wù)器能夠知道用戶當(dāng)前操作與工作狀態(tài)，另一方面服務(wù)器對獲知信息進行分析和計算，做出快速響應(yīng)，將處理結(jié)果實時傳遞給用戶。其特點是信息單次數(shù)據(jù)量小，但交互頻率很高，對上傳、下推實時性要求非常高，所以消息格式應(yīng)簡單，開銷越小越好。因此對于這種信息交互的格式設(shè)計顯得尤為重要。非實時信息交互主要為資源請求響應(yīng)交互信息，其目的是滿足用戶根據(jù)自身需要主動請求服務(wù)器端的資源數(shù)據(jù)的需求，其特點為會話式交互，非實時頻繁交互，但需要客戶端到服務(wù)器端的通信鏈路支持及服務(wù)器的有效響應(yīng)。流程為用戶接收到節(jié)目流之后得到其提供的可用資源信息，包括描述文件與媒體數(shù)據(jù)，然后向服務(wù)器端請求相應(yīng)數(shù)據(jù)，服務(wù)器接收到請求后核實請求合法性，若合法則發(fā)送確認(rèn)信息并傳輸數(shù)據(jù)，否則發(fā)送失敗信息。高效的多媒體傳輸系統(tǒng)應(yīng)滿足更輕量級的請求與響應(yīng)交互方式，同時面向多媒體的交互格式也應(yīng)該被支持。經(jīng)檢索，中國發(fā)明專利cn200310123710.5，該系統(tǒng)中涉及一種便于附帶有多媒體對象的節(jié)目內(nèi)容和節(jié)目指南數(shù)據(jù)進行通信的節(jié)目特有信息數(shù)據(jù)結(jié)構(gòu)，多媒體對象包括音頻、視頻、動畫、靜止圖像、因特網(wǎng)、電子郵件、文本和其它類型的數(shù)據(jù)。該數(shù)據(jù)結(jié)構(gòu)支持例如被動觀看的單向通信應(yīng)用和例如交互類型功能的雙向通信應(yīng)用。解碼器處理分組化節(jié)目數(shù)據(jù)和包含輔助描述信息的節(jié)目特有信息，輔助描述信息包括多媒體對象類型、位置和其它描述性指示符。這些指示符用于獲取和解碼從不同信源獲得的多媒體對象，以便在表示視頻節(jié)目內(nèi)容或節(jié)目指南的復(fù)合視頻圖像中顯現(xiàn)。利用附加的輔助位置和獲取描述信息，能夠獲取補充的節(jié)目特有信息單元和節(jié)目內(nèi)容數(shù)據(jù)。但是該專利缺乏高效雙向快速信息交互機制。技術(shù)實現(xiàn)要素：針對現(xiàn)有技術(shù)中的缺陷，本發(fā)明的目的是提供一種多媒體系統(tǒng)中信息交互機制，旨在解決現(xiàn)有媒體傳輸系統(tǒng)中缺乏高效雙向快速信息交互機制的缺陷。根據(jù)本發(fā)明的一個目的，提供一種多媒體系統(tǒng)中信息交互機制，所述機制采用采用以下交互消息主體實現(xiàn)雙向快速信息交互，所述交互消息主體包含如下字段：交互消息的消息標(biāo)識字段；消息的版本號字段；消息長度標(biāo)識字段；標(biāo)示當(dāng)前消息負載(payload)的數(shù)據(jù)段。進一步的，所述包含標(biāo)示當(dāng)前消息負載(payload)的數(shù)據(jù)段，包含如下字段：保留字段；消息內(nèi)容類別的標(biāo)識字段。更進一步的，所述包含標(biāo)示當(dāng)前消息負載(payload)的數(shù)據(jù)段，還包含如下字段：標(biāo)示了此消息的序列號的字段；標(biāo)示了此消息所關(guān)聯(lián)的消息的序列號的字段；標(biāo)示了反饋狀態(tài)的字段；標(biāo)示了此消息的內(nèi)容格式的字段；標(biāo)示了此消息的內(nèi)容數(shù)據(jù)長度的字段；標(biāo)示當(dāng)前交互信息的字節(jié)數(shù)據(jù)段。本發(fā)明中：消息為會話式交互，用戶請求與系統(tǒng)響應(yīng)格式有機統(tǒng)一，支持本機制的服務(wù)器客戶端雙方，即使沒有http協(xié)議的接口，也能實現(xiàn)面向多媒體的資源請求響應(yīng)類的輕量級交互應(yīng)用。這為媒體網(wǎng)絡(luò)傳輸，帶來了極大的便利。配合本發(fā)明所提出的靈活的消息體格式機制，可以針對各種媒體業(yè)務(wù)具體需求，設(shè)計貼切的具體消息格式?？旖莞咝У膫鬏攨f(xié)議結(jié)合靈活可定制的消息體格式，使本發(fā)明能應(yīng)用到所有媒體傳輸系統(tǒng)。根據(jù)本發(fā)明的第二目的，提供一種基于上述機制的多媒體系統(tǒng)中交互信息數(shù)據(jù)的網(wǎng)絡(luò)傳輸方法，包括：步驟a，網(wǎng)絡(luò)終端設(shè)備按消息體已預(yù)先定制的可擴展的消息格式內(nèi)具體比特負載數(shù)據(jù)段的格式或自定義的格式封裝消息體“prr_data_byte”字段。步驟b，網(wǎng)絡(luò)終端設(shè)備按交互消息主體格式封裝消息整體。步驟c，網(wǎng)絡(luò)終端設(shè)備按所選用的網(wǎng)絡(luò)通訊協(xié)議“payload”格式定義把消息封裝進協(xié)議“payload”。步驟d，網(wǎng)絡(luò)終端設(shè)備按協(xié)議格式定義生成一個或多個packet網(wǎng)絡(luò)傳送數(shù)據(jù)包。步驟e，網(wǎng)絡(luò)服務(wù)器接收一個或多個客戶端提交的packet數(shù)據(jù)包后，按數(shù)據(jù)包協(xié)議頭，解析出完整的協(xié)議級“payload”數(shù)據(jù)段。步驟f，網(wǎng)絡(luò)服務(wù)器按所選用的網(wǎng)絡(luò)協(xié)議“payload”格式定義解出完整的消息體數(shù)據(jù)段。步驟g，網(wǎng)絡(luò)服務(wù)器按消息頭定義解出消息體的比特負載數(shù)據(jù)段(即“prr_data_byte”字段所含數(shù)據(jù))。步驟h，網(wǎng)絡(luò)服務(wù)器按消息定義或自定義的格式，解析比特負載數(shù)據(jù)段(即“prr_data_byte”字段所含數(shù)據(jù))，并進行相應(yīng)處理和回應(yīng)。服務(wù)器端到網(wǎng)絡(luò)終端設(shè)備的通信，也遵照此步驟。此數(shù)據(jù)格式和應(yīng)用方法，滿足網(wǎng)絡(luò)雙向通信的要求。與現(xiàn)有技術(shù)相比，本發(fā)明具有如下的有益效果：采用本發(fā)明的技術(shù)方案，信息交互機制可以針對各種不同的交互式數(shù)據(jù)的特點，設(shè)計統(tǒng)一的交互式數(shù)據(jù)的傳輸格式，通過統(tǒng)一的交互式數(shù)據(jù)的傳輸步驟，通信雙方可以大大節(jié)省為適應(yīng)不同類型數(shù)據(jù)所帶來的開銷；進一步的，消息體內(nèi)“payload”數(shù)據(jù)段也允許自定義，結(jié)合消息頭內(nèi)的保留字段，十分便利地就可以實現(xiàn)系統(tǒng)的擴展。本發(fā)明可以有效提高媒體網(wǎng)絡(luò)的傳輸效率。附圖說明通過閱讀參照以下附圖對非限制性實施例所作的詳細描述，本發(fā)明的其它特征、目的和優(yōu)點將會變得更明顯：圖1是本發(fā)明一實施例中交互消息消息應(yīng)用示意圖。具體實施方式下面結(jié)合具體實施例對本發(fā)明進行詳細說明。以下實施例將有助于本領(lǐng)域的技術(shù)人員進一步理解本發(fā)明，但不以任何形式限制本發(fā)明。應(yīng)當(dāng)指出的是，對本領(lǐng)域的普通技術(shù)人員來說，在不脫離本發(fā)明構(gòu)思的前提下，還可以做出若干變形和改進。這些都屬于本發(fā)明的保護范圍。本發(fā)明提供了一種多媒體傳輸系統(tǒng)中信息交互機制，旨在解決現(xiàn)有媒體傳輸系統(tǒng)中，缺乏高效雙向快速信息交互機制的缺陷。所述機制設(shè)計統(tǒng)一的交互式數(shù)據(jù)的傳輸格式，通過統(tǒng)一的交互式數(shù)據(jù)的傳輸步驟，節(jié)省為適應(yīng)不同類型數(shù)據(jù)所帶來的開銷。以下對本發(fā)明實施細節(jié)進行舉例說明，在本發(fā)明部分實施例中，交互信息主體包含如下字段(如表3所示)：包含交互消息的消息標(biāo)識字段；包含消息的版本號字段；包含消息長度標(biāo)識字段；包含標(biāo)示當(dāng)前消息負載(payload)的數(shù)據(jù)段。進一步的，在本發(fā)明部分實施例中，消息負載其中包含如下字段：包含保留字段；包含消息內(nèi)容類別的標(biāo)識字段；表1–prr_type字段取值valuedescription0post上行傳輸1post下行傳輸更進一步的，對于消息內(nèi)容類別的標(biāo)識字段賦值為對應(yīng)“0”形式下：包含標(biāo)示了此消息的序列號的字段；包含標(biāo)示了此消息的內(nèi)容格式的字段；包含標(biāo)示了此消息的內(nèi)容數(shù)據(jù)長度的字段；包含標(biāo)示當(dāng)前交互信息的字節(jié)數(shù)據(jù)段；更進一步的，對于消息內(nèi)容類別的標(biāo)識字段賦值為對應(yīng)“1”形式下：包含標(biāo)示了此消息所關(guān)聯(lián)的消息的序列號的字段；包含標(biāo)示了反饋狀態(tài)的字段；表2–status_number字段取值更進一步的，對于標(biāo)示了反饋狀態(tài)的字段賦值為對應(yīng)“0x02”形式下(反饋狀態(tài)字段賦值可以參照標(biāo)準(zhǔn)hypertexttransferprotocol(http)協(xié)議的statuscodes取值，以保持良好的兼容性)：包含標(biāo)示了此消息的內(nèi)容格式的字段；包含標(biāo)示了此消息的內(nèi)容數(shù)據(jù)長度的字段；包含標(biāo)示當(dāng)前交互信息的字節(jié)數(shù)據(jù)段；整個數(shù)據(jù)格式的結(jié)構(gòu)可參見以下交互消息格式表表示：表3–交互消息格式表基于上述的多媒體傳輸系統(tǒng)中信息交互機制，本發(fā)明進一步的提供交互信息數(shù)據(jù)的網(wǎng)絡(luò)傳輸方法，作為一個實施方式，本發(fā)明所述的消息數(shù)據(jù)的網(wǎng)絡(luò)傳輸方法是應(yīng)用在網(wǎng)絡(luò)終端設(shè)備與網(wǎng)絡(luò)服務(wù)器之間。具體包括以下步驟:步驟a，網(wǎng)絡(luò)終端設(shè)備按消息體已預(yù)先定制的交互消息主體格式內(nèi)具體比特負載數(shù)據(jù)段的格式或自定義的格式封裝消息體“prr_data_byte”字段。步驟b，網(wǎng)絡(luò)終端設(shè)備按交互消息主體格式封裝消息整體。步驟c，網(wǎng)絡(luò)終端設(shè)備按所選用的網(wǎng)絡(luò)通訊協(xié)議“payload”格式定義把消息封裝進協(xié)議“payload”。步驟d，網(wǎng)絡(luò)終端設(shè)備按協(xié)議格式定義生成一個或多個packet網(wǎng)絡(luò)傳送數(shù)據(jù)包。步驟e，網(wǎng)絡(luò)服務(wù)器接收一個或多個客戶端提交的packet數(shù)據(jù)包后，按數(shù)據(jù)包協(xié)議頭，解析出完整的協(xié)議級“payload”數(shù)據(jù)段。步驟f，網(wǎng)絡(luò)服務(wù)器按所選用的網(wǎng)絡(luò)協(xié)議“payload”格式定義解出完整的消息體數(shù)據(jù)段。步驟g，網(wǎng)絡(luò)服務(wù)器按消息頭定義解出消息體的比特負載數(shù)據(jù)段(即“prr_data_byte”字段所含數(shù)據(jù))。步驟h，網(wǎng)絡(luò)服務(wù)器按消息定義或自定義的格式，解析比特負載數(shù)據(jù)段(即“prr_data_byte”字段所含數(shù)據(jù))，并進行相應(yīng)處理和回應(yīng)。服務(wù)器端到網(wǎng)絡(luò)終端設(shè)備的通信，也遵照此步驟。此數(shù)據(jù)格式和應(yīng)用方法，滿足網(wǎng)絡(luò)雙向通信的要求。作為一個實施方式，用本發(fā)明上述的消息格式傳輸用戶自定義的json格式的消息內(nèi)容為例，說明消息交互的實施步驟。本發(fā)明有著良好的擴展性和靈活性，用戶可以十分方便地使用json等格式，來傳輸自己的定制信息。以下為實際步驟描述：把信息內(nèi)容填充進json文件。例如用戶點播節(jié)目進行播放，期間拖動播放器進度條，直接跳到節(jié)目某一時間點進行觀看。需要上傳此時間點信息，從而從特定位置開始獲取數(shù)據(jù)包。則按此請求生成的json文件內(nèi)容為：{"eventtype":"request_movie_by_time","movieid":"123","time":"17:50"}對于此例，“prr_type”字段值設(shè)為“0”，“post_serial_number”字段值設(shè)為“111”，“mime_type()”字段值按mime標(biāo)準(zhǔn)設(shè)為對應(yīng)json文件類型的值。把此json文件作為bit流填充進消息體的“prr_data_byte”數(shù)據(jù)段，然后進行消息的發(fā)送即可，具體的消息傳送底層可以使用任何相適應(yīng)的協(xié)議和物理層。服務(wù)器收到此上傳消息后，進行相應(yīng)解析，并給出反饋信息。反饋信息內(nèi)容也用json格式進行組織。那么對于服務(wù)器回復(fù)的下傳消息，具體值設(shè)置如下：“prr_type”字段值設(shè)為“1”，“response_number”字段值設(shè)為“111”，”status_number字段值設(shè)為“0x02”，“mime_type()”字段值按mime標(biāo)準(zhǔn)設(shè)為對應(yīng)json文件類型的值。并把此json文件作為bit流填充進消息體的“prr_data_byte”數(shù)據(jù)段，然后進行消息的發(fā)送。此流程可以參見圖1。通過不標(biāo)準(zhǔn)的信息格式進行信息交互的方式，需要針對不同服務(wù)器客戶端不停進行重復(fù)開發(fā)。使用本發(fā)明，通過信息格式的標(biāo)準(zhǔn)化，可以有效降低構(gòu)架多媒體傳輸網(wǎng)絡(luò)的復(fù)雜度。應(yīng)當(dāng)理解的是，以上僅僅是本發(fā)明的部分實施例，本發(fā)明還可以應(yīng)用到其他的傳輸系統(tǒng)，只需通過針對具體的業(yè)務(wù)需求，提煉出需要傳輸?shù)木W(wǎng)絡(luò)交互信息數(shù)據(jù)，把信息數(shù)據(jù)填充進消息的“payload”內(nèi)“prr_data_byte”數(shù)據(jù)段，之后按照交互信息數(shù)據(jù)的網(wǎng)絡(luò)傳輸方法所描述的步驟，便可以實現(xiàn)，在本發(fā)明描述的技術(shù)方案基礎(chǔ)上，對于本領(lǐng)域技術(shù)人員來說是很容易理解的。以上對本發(fā)明的具體實施例進行了描述。需要理解的是，本發(fā)明并不局限于上述特定實施方式，本領(lǐng)域技術(shù)人員可以在權(quán)利要求的范圍內(nèi)做出各種變形或修改，這并不影響本發(fā)明的實質(zhì)內(nèi)容。當(dāng)前第1頁12