一種傳輸數(shù)據的方法和設備的制造方法
【專利摘要】本發(fā)明涉及通訊領域，尤其涉及一種傳輸數(shù)據的方法和設備。用以解決現(xiàn)有技術中Android系統(tǒng)現(xiàn)有的用于傳輸音頻流和視頻流文件的方法傳輸速度較慢，延時較大的問題。本發(fā)明發(fā)送設備在應用層通過第一接口，向框架層發(fā)送針對需要發(fā)送的數(shù)據的傳輸信息；發(fā)送設備在框架層接收所述傳輸信息；發(fā)送設備在框架層通過第二接口，將接收到的支持應用層的傳輸信息轉換為支持框架層的傳輸信息；發(fā)送設備根據轉換后的傳輸信息，通過RTP發(fā)送對應的數(shù)據。本發(fā)明實施例中的發(fā)送設備可以將用于RTP的傳輸信息從應用層發(fā)送到接口層，因而可以在框架層通過RTP發(fā)送數(shù)據，相對于現(xiàn)有的在應用層通過RTP發(fā)送數(shù)據的傳輸數(shù)據方法，傳送數(shù)據的速度更快。
【專利說明】
一種傳輸數(shù)據的方法和設備
技術領域
[0001 ]本發(fā)明涉及通訊領域，尤其涉及一種傳輸數(shù)據的方法和設備。
【背景技術】
[0002]Android(安卓)系統(tǒng)是一種開放源代碼的操作系統(tǒng)，主要應用于移動設備，如智能手機和平板電腦。經過多年發(fā)展，Android系統(tǒng)現(xiàn)在已經成為手機上最主流的操作系統(tǒng)，占據市場份額高達78.1% Android系統(tǒng)上的應用軟件種類豐富，包括通訊、視頻、音頻和游戲等多類型軟件。
[0003]近年來，隨著網絡速度的提高和技術的發(fā)展，Android系統(tǒng)中的應用不再是簡單的信息瀏覽，電子郵件等。出現(xiàn)了各種通過網絡實時傳輸協(xié)議傳輸視頻、音頻等各種流媒體的軟件，使得實現(xiàn)遠程視屏會議、IPdnternet Protocol互聯(lián)網協(xié)議)可視電話、遠程教育、遠程醫(yī)療診斷等成為可能。這些軟件都是基于傳輸視頻流和音頻流的協(xié)議。
[0004]Android系統(tǒng)現(xiàn)有利用實施傳輸協(xié)議傳輸音頻流和視頻流文件的方法傳輸速度較慢，延時較大。

【發(fā)明內容】

[0005]本發(fā)明實施例提供了一種傳輸數(shù)據的方法和設備，用以解決現(xiàn)有技術中Android系統(tǒng)現(xiàn)有的用于傳輸音頻流和視頻流文件的方法傳輸速度較慢，延時較大的問題。
[0006]本發(fā)明實施例提供一種傳輸數(shù)據的方法，包括:
[0007]發(fā)送設備在應用層通過第一接口，向框架層發(fā)送針對需要發(fā)送的數(shù)據的傳輸信息;
[0008]所述發(fā)送設備在框架層接收所述傳輸信息；
[0009]所述發(fā)送設備在框架層通過第二接口，將接收到的支持應用層的所述傳輸信息轉換為支持框架層的傳輸信息；
[0010]所述發(fā)送設備根據轉換后的傳輸信息，通過實時傳播協(xié)議RTP發(fā)送對應的數(shù)據。
[0011]由于本發(fā)明實施例中的發(fā)送設備可以將用于RTP的傳輸信息從應用層發(fā)送到接口層，因而可以在框架層通過RTP發(fā)送數(shù)據，從而節(jié)省了將要傳輸?shù)臄?shù)據從框架層發(fā)送到應用層的時間，相對于現(xiàn)有的在應用層通過RTP發(fā)送數(shù)據的傳輸數(shù)據方法，傳送數(shù)據的速度更快。
[0012]可選的，所述第一接口為JAVA接口；和/或
[0013]所述第二接口為面向服務的體系結構SOA接口。
[0014]由于本發(fā)明實施例的第一接口為JAVA接口，因而可以使基于JAVA語言的應用程序更方便的調用本接口；由于本發(fā)明實施例中的第二接口為SOA接口，因而可以方便的將傳輸信息由一種應用層的編程語言轉換成框架層的編程語言，使框架層的用于實現(xiàn)RTP傳輸數(shù)據的模塊更方便的使用傳輸信息。
[0015]可選的，所述傳輸信息包括IP地址和/或端口號；
[0016]所述需要發(fā)送的數(shù)據包括音頻數(shù)據和/或視頻數(shù)據。
[0017]由于本發(fā)明實施例向框架層發(fā)送的傳輸信息包括但不限于IP地址和/或端口號，完成RTP傳輸數(shù)據需要傳輸數(shù)據的目的設備的IP地址和端口號，因此本發(fā)明實施例的發(fā)送設備可以實現(xiàn)在框架層通過RTP通訊協(xié)議傳輸數(shù)據；由于本發(fā)明實施例可以實現(xiàn)在框架層通過RTP傳輸音頻數(shù)據和視頻數(shù)據，因此可以用于減少直播視頻或音頻軟件的延遲。
[0018]可選的，所述第一接口位于所述應用層；
[0019 ]所述第二接口位于所述框架層。
[0020]由于本發(fā)明實施例的第一接口位于應用層上，因而可以使位于應用層上的應用程序方便的調用第一接口；由于本發(fā)明實施例的第二接口位于框架層上，因此使框架層上的用于完成RTP通訊協(xié)議功能的模塊方便的調用第二接口。
[0021 ]可選的，所述發(fā)送設備根據轉換后的傳輸信息，通過RTP發(fā)送對應的數(shù)據，還包括:
[0022]所述發(fā)送設備在所述框架層根據數(shù)據分發(fā)質量反饋信息，生成實時傳播控制協(xié)議RTCP 包；
[0023]所述發(fā)送設備將所述RTCP包發(fā)送到所述應用層。
[0024]由于本發(fā)明實施例的發(fā)送設備可以向應用層提供包含數(shù)據分發(fā)質量反饋信息的實時傳播控制協(xié)議RTCP包，因而位于應用層的軟件可以根據數(shù)據分發(fā)質量反饋信息使傳輸效率最佳化。
[0025]本發(fā)明實施例提供一種傳輸數(shù)據的設備，包括:
[0026]第一發(fā)送模塊，用于在應用層通過第一接口，向框架層發(fā)送針對需要發(fā)送的數(shù)據的傳輸信息；
[0027]接收模塊，用于在框架層接收所述傳輸信息；
[0028]轉換模塊，用于在框架層通過第二接口，將接收到的支持應用層的所述傳輸信息轉換為支持框架層的傳輸信息；
[0029]第二發(fā)送模塊，用于根據轉換后的傳輸信息，通過RTP發(fā)送對應的數(shù)據。
[0030]可選的，所述第一接口為JAVA接口；和/或[0031 ]所述第二接口為SOA接口。
[0032]可選的，所述傳輸信息包括IP地址和/或端口號；
[0033]所述需要發(fā)送的數(shù)據包括音頻數(shù)據和/或視頻數(shù)據。
[0034]可選的，所述第一接口位于所述應用層；
[0035]所述第二接口位于所述框架層。
[0036]可選的，所述第二發(fā)送模塊，還用于:
[0037]在所述框架層根據數(shù)據分發(fā)質量反饋信息，生成實時傳播控制協(xié)議RTCP包；
[0038]將所述RTCP包發(fā)送到所述應用層。
【附圖說明】
[0039]為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術中的技術方案，下面將對實施例或現(xiàn)有技術描述中所需要使用的附圖作一簡單地介紹，顯而易見地，下面描述中的附圖是本發(fā)明的一些實施例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據這些附圖獲得其他的附圖。
[0040]圖1為本發(fā)明實施例傳輸數(shù)據的框架示意圖；
[0041 ]圖2為本發(fā)明實施例傳輸數(shù)據的方法示意圖；
[0042]圖3為本發(fā)明實施例RTP包的報頭示意圖；
[0043]圖4為本發(fā)明傳輸數(shù)據的方法的整體流程示意圖；
[0044]圖5為本發(fā)明傳輸數(shù)據的設備結構示意圖。
【具體實施方式】
[0045]為使本發(fā)明實施例的目的、技術方案和優(yōu)點更加清楚，下面將結合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領域普通技術人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。
[0046]本發(fā)明實施例的方法應用于流媒體傳輸?shù)膽脠鼍啊Ｔ诰W上傳輸視頻、音頻等多媒體信息目前主要有兩種傳輸方式:下載和流式傳輸。采用下載方式，用戶需要下載整個媒體文件，然后才能進行播放。由于網絡帶寬的限制，下載需要較長時間，造成延時較大。
[0047]目前，流媒體傳輸采用的主流技術是流式傳輸。進行傳輸之前，首先對多媒體數(shù)據進行預處理(可利用音頻編碼器和視頻編碼器實現(xiàn)，作用是降低音視頻數(shù)據的質量并進行壓縮)，然后使用緩存系統(tǒng)來保證數(shù)據連續(xù)正確的傳輸。使用流式傳輸方式，使用流式傳輸方式，用戶不必像采用下載方式那樣要等到整個文件全部下載完畢，而是只需經過幾秒到幾十秒的啟動延時即可在客戶端進行播放和觀看。此時媒體文件的剩余部分將在后臺繼續(xù)下載。
[°°48] 流式傳輸?shù)闹髁鱾鬏攨f(xié)議是RTP(RealTime Transport Protocol，實時傳播協(xié)議)，用于流失傳輸?shù)腞TP建立在UDP(User Datagram Protocol，用戶數(shù)據報協(xié)議)傳輸協(xié)議之上，UDP傳輸協(xié)議的可靠性不如TCP(Transmiss1n Control Protocol，傳輸控制協(xié)議)傳輸協(xié)議，并且無法保證實時業(yè)務的服務質量，需要RTCP(RealTime Transport ControlProtocol，實時傳播控制協(xié)議)實時監(jiān)控數(shù)據傳輸和服務質量。
[0049]本發(fā)明實施例實現(xiàn)RTP基于的操作系統(tǒng)為Andrο i d操作系統(tǒng)。
[0050]Android操作系統(tǒng)主要分為四個層次，從高到低分別是:
[0051 ]應用層、框架層、系統(tǒng)運行庫和Linux(—種操作系統(tǒng))內核。
[0052]1、應用層
[0053]在應用層上有用戶可以直接使用的應用軟件。應用層上的應用軟件分為兩類:系統(tǒng)提供的核心應用軟件和其他應用開發(fā)者開發(fā)的軟件。例如，應用層上可以有核心應用軟件:E-mail(電子郵件)客戶端，SMS(Short message service短信息服務)程序，日歷、地圖；應用層上也可以由其他應用開發(fā)者開發(fā)的軟件:游戲應用軟件，系統(tǒng)維護軟件，即時通訊軟件。應用層上的軟件都基于JAVA(—種編程語言)語言。
[0054]2、框架層
[0〇55] 框架層(B卩Applicat1n Framework(應用框架層))是編寫Google(谷歌)發(fā)布的核心應用時所使用的API (Applicat1n Programming Interface，應用程序接口)框架，開發(fā)人員同樣可以使用這些框架來開發(fā)自己的應用，這樣便簡化了程序開發(fā)的架構設計。開發(fā)人員可以利用系統(tǒng)運行庫中的函數(shù)開發(fā)用于框架層的完成特定功能的功能塊。功能塊必須遵循框架的安全性設計，可以被應用層不同的軟件多次使用?？蚣軐邮褂肅/C++語言。
[0056]3、系統(tǒng)運行庫
[0057]Android操作系統(tǒng)包含一些C/C++庫，這些庫包含各種函數(shù)，可以被Android操作系統(tǒng)中不同的組件(功能塊)使用，它們通過框架層為開發(fā)者提供服務。
[0058]4、Linux 內核
[0059]Linux內核作為軟件和硬件之間的抽象層，Android操作系統(tǒng)的核心服務也基于Linux內核。
[0060]本發(fā)明實施例的傳輸數(shù)據的方法中，發(fā)送設備在應用層通過第一接口，向框架層發(fā)送針對需要發(fā)送的數(shù)據的傳輸信息;所述發(fā)送設備在框架層接收所述傳輸信息;所述發(fā)送設備在框架層通過第二接口，將接收到的支持應用層的所述傳輸信息轉換為支持框架層的傳輸信息;所述發(fā)送設備根據轉換后的傳輸信息，通過RTP發(fā)送對應的數(shù)據。由于本發(fā)明實施例中的發(fā)送設備可以根據傳輸信息在框架層通過RTP發(fā)送數(shù)據，因而相對于現(xiàn)有的在應用層通過RTP發(fā)送數(shù)據的傳輸數(shù)據方法，傳送數(shù)據的速度更快。
[0061]如圖1所示，本發(fā)明實施例與現(xiàn)有技術的主要區(qū)別在于:現(xiàn)有技術在應用層實現(xiàn)RTP傳輸數(shù)據。而本發(fā)明實施例在提供從應用層向框架層傳輸用于RTP傳輸數(shù)據的第一接口(BPRecorder App，記錄器應用軟件)。應用層和框架層RTP傳輸模塊采用不同的編程語言(分別是JAVA和C++)，本發(fā)明實施例還提供了將從應用層傳來的信息發(fā)送給RTP傳輸模塊的第二接口(即MediaRecorder，該模塊存儲路徑為/ java/android/media/MediaRecorder)。并在系統(tǒng)運行庫中提供了供接口模塊調用的函數(shù)(MediaRecorder.cpp，該函數(shù)存儲的路徑為/framework/av/media/libmedia)。第二接口還可以接受來自來自Aud1Fl inger(音頻管理器)的音頻文件和來自Camera Service(照相機服務)的視頻文件并發(fā)送給RTP傳輸模塊。
[0062]如圖2所示，本發(fā)明實施例提供一種傳輸數(shù)據的方法，包括:
[0063]步驟201，發(fā)送設備在應用層通過第一接口，向框架層發(fā)送針對需要發(fā)送的數(shù)據的傳輸信息；
[0064]步驟202，所述發(fā)送設備在框架層接收所述傳輸信息；
[0065]步驟203，所述發(fā)送設備在框架層通過第二接口，將接收到的支持應用層的所述傳輸信息轉換為支持框架層的傳輸信息；
[0066]步驟204，所述發(fā)送設備根據轉換后的傳輸信息，通過實時傳播協(xié)議RTP發(fā)送對應的數(shù)據。
[0067]本發(fā)明實施例的應用場景用于對視頻數(shù)據或音頻數(shù)據的實時性要求比較高的場景。例如，網絡視頻直播，視頻電話會議，遠程語音通訊等。上述應用場景可由具有錄音和/或錄像設備的發(fā)送設備配合安裝在發(fā)送設備上的應用軟件實現(xiàn)。
[0068]本發(fā)明實施例中的發(fā)送設備包括但不限于下列設備:
[0069]基于Android操作系統(tǒng)的手機、平板電腦，智能電視，電腦。由于本發(fā)明實施例中的傳輸數(shù)據的方法多用于傳輸直播的音頻或視頻文件。因此，發(fā)送設備可具有音頻錄制或/和視頻錄制功能。
[0070]本發(fā)明實施例中的應用軟件可以是視頻或音頻直播軟件。
[0071 ] 具體的，應用軟件可以是基于VoIP(Voice over Internet Protocol網絡語音協(xié)議)的應用軟件。其中，Vo IP可以將模擬信號(聲音)數(shù)字化，以Data Packe t (數(shù)據封包)的形式在網絡上做實時傳遞。VoIP可以在IP網絡上完成傳送語音、傳真、視頻、和數(shù)據等業(yè)務，如統(tǒng)一消息業(yè)務、虛擬電話、虛擬語音/傳真郵箱、查號業(yè)務、Internet呼叫中心、Internet呼叫管理、電話視頻會議、電子商務、傳真存儲轉發(fā)和各種信息的存儲轉發(fā)等。
[0072]應用軟件也可以是基于RTSP(Real Time Streaming Protocol，實時流傳輸協(xié)議)的軟件。其中，RTSP是TCP/IP協(xié)議體系中的一個應用層協(xié)議，該協(xié)議定義了一對多應用程序如何有效地通過IP網絡傳送多媒體數(shù)據。基于RTSP協(xié)議的軟件多為目前較為流行的視頻直播軟件。
[0073]本發(fā)明實施例通過RTP通訊協(xié)議發(fā)送的數(shù)據可以包括但不限于下列數(shù)據類型:
[0074]—、音頻數(shù)據
[0075]音頻數(shù)據可以是通過發(fā)送設備的麥克風現(xiàn)場錄制的音頻文件，或者現(xiàn)場錄制后經過音頻編碼器編碼的形成的文件，也可以是已有的音頻文件。例如，音頻數(shù)據可以是現(xiàn)場錄制的wave文件，也可以是經過錄制后經過音頻編碼器編碼得到的MP3文件，也可以是存儲在存儲介質中的MP3文件。
[0076]二、視頻數(shù)據
[0077]視頻數(shù)據可以是通過發(fā)送設備的攝像頭錄制后視頻編碼器編碼形成的數(shù)據，也可以是已有的視頻文件，也可以是已有的視頻文件。例如，視頻文件可以是現(xiàn)場錄制的AVI(Aud1 Video Interfaced，音頻視頻交錯格式)文件，也可以是經過視頻編碼器編碼的RM文件，也可以是已有的RM文件。
[0078]三、音視頻數(shù)據
[0079]音視頻數(shù)據為音頻數(shù)據和視頻數(shù)據打包在一起形成的數(shù)據。例如，傳輸?shù)臄?shù)據的格式可以是RM(Real Media，Real公司開發(fā)的一種視頻格式)，ASF(Advanced StreamingFormat，高級串流格式)或其他類似類型。
[0080]發(fā)送設備中不同的應用程序在傳輸數(shù)據前對數(shù)據做不同的處理。應用程序可以同時錄制音頻文件和視頻文件時，可以將音頻數(shù)據和視頻數(shù)據打包在一起，然后再進行傳輸，也可以將音頻文件和視頻文件分別進行傳輸。
[0081]本發(fā)明實施例用RTP傳輸數(shù)據需要向用于傳輸數(shù)據的RTP傳輸模塊提供傳輸信息。傳輸信息由應用層的應用軟件確定，傳輸信息與傳輸數(shù)據的目的設備相對應。傳輸信息可以包括但不限于下面的信息:
[0082]IP地址和/或端口號。
[0083]本發(fā)明實施例可以實現(xiàn)在框架層(S卩framework層)通過RTP通訊協(xié)議進行數(shù)據傳輸，為位于應用層應用軟件提供了接口(即第一接口)，用于從應用層向框架層發(fā)送傳輸信息。第一接口可以為JAVA語言編寫的接口。
[0084]具體的，第一接口的定義方式可以是:
[0085]Java\android\media\MediaRecoder.java: void setOutputAddress(Stringaddress,String port,String type)
[0086]其中，括號中的內容為傳輸信息，address為IP地址；
[0087]port 為端口號；
[0088]type為要傳輸?shù)臄?shù)據的數(shù)據類型，可以是音頻數(shù)據或者視頻數(shù)據。
[0089]本發(fā)明實施例的發(fā)送設備通過第一接口將傳輸數(shù)據發(fā)送到框架層后，再通過位于框架層的第二接口將傳輸數(shù)據進行轉換再發(fā)送給位于框架層的RTP傳輸模塊。第二接口可以是SOA(Service-Oriented Architecture，面向服務的體系結構)接口。由于現(xiàn)有的可用于框架層的RTP傳輸模塊是用C++語言編程的，而第一接口位于應用層是用JAVA語言編程的，因而為了使框架層由第一接口收到的JAVA語言的傳輸信息傳遞給C++語言的RTP傳輸模塊可以識別的傳輸信息，本發(fā)明實施例提供了第二接口用于轉換來自第一接口的傳輸信息。
[0090]本發(fā)明實施例中RTP傳輸模塊可以將來自編碼器的數(shù)據(若編碼器為音頻編碼器，則數(shù)據為音頻數(shù)據;若編碼器為視頻編碼器，則數(shù)據為視頻數(shù)據)，并將數(shù)據發(fā)送到傳輸信息所對應的位置(可以是IP地址和端口號)。當RTP傳輸模塊同時用于傳輸音頻數(shù)據和視頻數(shù)據時，音頻數(shù)據的傳輸信息可以與視頻數(shù)據的傳輸信息不同。
[0091 ] RTP傳輸模塊在發(fā)送RTP數(shù)據前，需先將音頻數(shù)據或視頻數(shù)據封裝成RTP包。
[0092]RTP包中包含兩部分內容:報頭和有效載荷。
[0093]報頭的內容是RTP中與傳輸?shù)臄?shù)據相關的信息，包含的內容如圖3所示。
[0094]版本號(V):2比特，用來標志使用的RTP版本。
[0095]填充位(P):1比特，如果該位為I，則該RTP包的尾部就包含附加的填充字節(jié)。
[0096]擴展位(X):1比特，如果該位為I的話，RTP固定頭部后面就跟有一個擴展頭部。
[0097]CSRC(Contributing SouRCe，作用源)計數(shù)器(CC):4比特，含有固定頭部后面跟著的CSRC的數(shù)目。
[0098]標記位(M):1比特，不同的有效載荷有不同的含義，對于視頻，標記一幀的結束;對于音頻，標記會話的開始;該位的解釋由配置文檔(Profile)來承擔.
[0099]載荷類型(PT):7比特，標識了RTP載荷的類型。如GSM音頻、JPEM圖像等。
[0100]序列號(SN):16比特，發(fā)送設備在每發(fā)送完一個RTP包后就將該域的值增加I，接收設備可以由該域檢測包的丟失及恢復包序列。序列號的初始值是隨機的。
[0101]時間戳:32比特，記錄了該包中數(shù)據的第一個字節(jié)的采樣時刻。在一次數(shù)據傳輸開始時，時間戳初始化成一個初始值。即使在沒有數(shù)據傳輸時，時間戳的數(shù)值也要隨時間而不斷地增加。時間戳用于去除抖動和實現(xiàn)同步。
[0102]同步源標識符(SSRC):32比特，同步源就是指RTP包流的來源。在同一個RTP會話中不能有兩個相同的SSRC值。該標識符是隨機選取的RFC1889推薦了 MD5隨機算法。
[0103]貢獻源列表(CSRC List):0?15項，每項32比特，用來標志對一個RTP混合器產生的新包有貢獻的所有RTP包的源。由混合器將這些有貢獻的SSRC標識符插入表中。SSRC標識符都被列出來，以便接收端能正確指出交談雙方的身份。
[0104]有效載荷的內容是傳輸?shù)木幋a器的編碼音頻數(shù)據或視頻數(shù)據。RTP傳輸模塊將有效載荷放在報頭后形成RTP包。
[0105]可選的，所述發(fā)送設備在所述框架層根據數(shù)據分發(fā)質量反饋信息，生成實時傳播控制協(xié)議RTCP包；
[0106]所述發(fā)送設備將所述RTCP包發(fā)送到所述應用層，以使所述發(fā)送設備控制RTP發(fā)送對應的數(shù)據的傳輸速率。
[0107]本發(fā)明實施例中RTP本身只保證實時數(shù)據的傳輸，并不能為按順序傳送數(shù)據包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP包提供這些服務。RTCP包中可以包括數(shù)據分發(fā)質量反饋信息。數(shù)據分發(fā)質量反饋信息中含有已發(fā)送的數(shù)據包的數(shù)量、丟失的數(shù)據包的數(shù)量等統(tǒng)計資料。
[0108]實際應用中，通過RTP傳輸數(shù)據時，數(shù)據的發(fā)送設備和數(shù)據的接受設備周期性地相互傳送RTCP包，控制傳輸速率的網絡側設備(例如應用軟件的服務器)可以利用這些信息動態(tài)地改變傳輸速率，甚至改變有效載荷類型，從而能以有效的反饋和最小的開銷使傳輸效率最佳化。
[0109]現(xiàn)有技術中，RTP傳輸模塊可以周期性自動生成包含數(shù)據分發(fā)質量反饋信息的RTCP 包。
[0110]如圖4所示，本發(fā)明實施例提供一種傳輸數(shù)據的整體流程，包括:
[0111]步驟401，發(fā)送設備將傳輸數(shù)據的傳輸信息從第一接口發(fā)送到框架層；
[0112]步驟402，發(fā)送設備在框架層接收所述傳輸信息；
[0113]步驟403，發(fā)送設備通過第二接口將傳輸信息轉換成支持框架層的傳輸信息；
[0114]步驟404，發(fā)送設備將支持框架層的傳輸信息發(fā)送給框架層的RTP傳輸模塊；
[0115]步驟405，框架層的RTP傳輸模塊將從音頻解碼器接收到的經過編碼的音頻文件打包成RTP包，并發(fā)送到傳輸信息對應的接收設備。
[0116]步驟406，傳輸信息對應的接收設備接收RTP包。
[0117]基于同一發(fā)明構思，本發(fā)明實施例中還提供了傳輸數(shù)據的設備，由于該設備對應的方法是本發(fā)明實施例中的方法，并且設備解決問題的原理與本發(fā)明實施例的方法相似，因此該設備的實施可以參見方法的實施，重復之處不再贅述。
[0118]如圖5所示，本發(fā)明實施例提供一種傳輸數(shù)據的設備，包括:
[0119]第一發(fā)送模塊501，用于在應用層通過第一接口，向框架層發(fā)送針對需要發(fā)送的數(shù)據的傳輸信息；
[0120]接收模塊502，用于在框架層接收所述傳輸信息；
[0121]轉換模塊503，用于在框架層通過第二接口，將接收到的支持應用層的所述傳輸信息轉換為支持框架層的傳輸信息；
[0122]第二發(fā)送模塊504，用于根據轉換后的傳輸信息，通過RTP發(fā)送對應的數(shù)據。
[0123]可選的，所述第一接口為JAVA接口；和/或
[0124]所述第二接口為SOA接口。
[0125]可選的，所述傳輸信息包括IP地址和/或端口號；
[0126]所述需要發(fā)送的數(shù)據包括音頻數(shù)據和/或視頻數(shù)據。
[0127]可選的，所述第一接口位于所述應用層；
[0128]所述第二接口位于所述框架層。
[0129]可選的，所述第二發(fā)送模塊504，還用于:
[0130]根據數(shù)據分發(fā)質量反饋信息，生成實時傳播控制協(xié)議RTCP包；
[0131]將所述RTCP包發(fā)送到所述應用層，以使所述發(fā)送設備控制RTP發(fā)送對應的數(shù)據的傳輸速率。
[0132]從上述內容可以看出:本發(fā)明實施例的傳輸數(shù)據的方法中，發(fā)送設備在應用層通過第一接口，向框架層發(fā)送針對需要發(fā)送的數(shù)據的傳輸信息;所述發(fā)送設備在框架層接收所述傳輸信息;所述發(fā)送設備在框架層通過第二接口，將接收到的支持應用層的所述傳輸信息轉換為支持框架層的傳輸信息;所述發(fā)送設備根據轉換后的傳輸信息，通過RTP發(fā)送對應的數(shù)據。由于本發(fā)明實施例中的發(fā)送設備可以將用于RTP的傳輸信息從應用層發(fā)送到接口層，因而可以在框架層通過RTP發(fā)送數(shù)據，相對于現(xiàn)有的在應用層通過RTP發(fā)送數(shù)據的傳輸數(shù)據方法，傳送數(shù)據的速度更快。
[0133]以上所描述的裝置實施例僅僅是示意性的，其中所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位于一個地方，或者也可以分布到多個網絡單元上?？梢愿鶕嶋H的需要選擇其中的部分或者全部模塊來實現(xiàn)本實施例方案的目的。本領域普通技術人員在不付出創(chuàng)造性的勞動的情況下，即可以理解并實施。
[0134]通過以上的實施方式的描述，本領域的技術人員可以清楚地了解到各實施方式可借助軟件加必需的通用硬件平臺的方式來實現(xiàn)，當然也可以通過硬件?；谶@樣的理解，上述技術方案本質上或者說對現(xiàn)有技術做出貢獻的部分可以以軟件產品的形式體現(xiàn)出來，該計算機軟件產品可以存儲在計算機可讀存儲介質中，如R0M/RAM、磁碟、光盤等，包括若干指令用以使得一臺計算機設備(可以是個人計算機，服務器，或者網絡設備等)執(zhí)行各個實施例或者實施例的某些部分所述的方法。
[0135]最后應說明的是:以上實施例僅用以說明本發(fā)明的技術方案，而非對其限制;盡管參照前述實施例對本發(fā)明進行了詳細的說明，本領域的普通技術人員應當理解:其依然可以對前述各實施例所記載的技術方案進行修改，或者對其中部分技術特征進行等同替換；而這些修改或者替換，并不使相應技術方案的本質脫離本發(fā)明各實施例技術方案的精神和范圍。
【主權項】
1.一種傳輸數(shù)據的方法，其特征在于，包括: 發(fā)送設備在應用層通過第一接口，向框架層發(fā)送針對需要發(fā)送的數(shù)據的傳輸信息； 所述發(fā)送設備在框架層接收所述傳輸信息； 所述發(fā)送設備在框架層通過第二接口，將接收到的支持應用層的所述傳輸信息轉換為支持框架層的傳輸信息； 所述發(fā)送設備根據轉換后的傳輸信息，通過實時傳播協(xié)議RTP發(fā)送對應的數(shù)據。2.如權利要求1所述的方法，其特征在于，所述第一接口為JAVA接口；和/或 所述第二接口為面向服務的體系結構SOA接口。3.如權利要求1所述的方法，其特征在于，所述傳輸信息包括IP地址和/或端口號； 所述需要發(fā)送的數(shù)據包括音頻數(shù)據和/或視頻數(shù)據。4.如權利要求1所述的方法，其特征在于， 所述第一接口位于所述應用層； 所述第二接口位于所述框架層。5.如權利要求1?4任一所述的方法，其特征在于，所述發(fā)送設備根據轉換后的傳輸信息，通過RTP發(fā)送對應的數(shù)據，還包括:所述發(fā)送設備在所述框架層根據數(shù)據分發(fā)質量反饋信息，生成實時傳播控制協(xié)議RTCP包； 所述發(fā)送設備將所述RTCP包發(fā)送到所述應用層。6.一種傳輸數(shù)據的設備，其特征在于，包括: 第一發(fā)送模塊，用于在應用層通過第一接口，向框架層發(fā)送針對需要發(fā)送的數(shù)據的傳輸信息； 接收模塊，用于在框架層接收所述傳輸信息； 轉換模塊，用于在框架層通過第二接口，將接收到的支持應用層的所述傳輸信息轉換為支持框架層的傳輸信息； 第二發(fā)送模塊，用于根據轉換后的傳輸信息，通過RTP發(fā)送對應的數(shù)據。7.如權利要求6所述的設備，其特征在于，所述第一接口為JAVA接口；和/或 所述第二接口為SOA接口。8.如權利要求6所述的設備，其特征在于，所述傳輸信息包括IP地址和/或端口號； 所述需要發(fā)送的數(shù)據包括音頻數(shù)據和/或視頻數(shù)據。9.如權利要求6所述的設備，其特征在于， 所述第一接口位于所述應用層； 所述第二接口位于所述框架層。10.如權利要求6?9任一所述的設備，其特征在于，所述第二發(fā)送模塊，還用于: 根據數(shù)據分發(fā)質量反饋信息，生成實時傳播控制協(xié)議RTCP包； 將所述RTCP包發(fā)送到所述應用層。
【文檔編號】H04L29/08GK105897687SQ201511020792
【公開日】2016年8月24日
【申請日】2015年12月30日
【發(fā)明人】蔡煒
【申請人】樂視致新電子科技（天津）有限公司