專利名稱：：一種流媒體回放方法、裝置及系統(tǒng)的制作方法
技術領域：
：本發(fā)明涉及網(wǎng)絡數(shù)據(jù)傳輸領域，特別是涉及一種流媒體數(shù)據(jù)的錄制、回放方法、裝置和系統(tǒng)。
背景技術：
：流媒體是在網(wǎng)絡中使用流技術傳輸?shù)倪B續(xù)時基媒體，其特點是在播放前不需要下載整個文件，而是采用邊下載邊播放的方式，它是視頻會議、IP電話等應用場合的技術基礎。目前，實時傳輸協(xié)議(RTP，Real-TimeProtocol)是進行實時流媒體傳輸?shù)臉藴蕝f(xié)議和關鍵技術。在分組交換網(wǎng)絡中，基于RTP對流媒體數(shù)據(jù)進行錄制和回放是一種較為常見的應用，通常會涉及三種角色實體，如圖l所示，包括發(fā)送端、錄制端和接收端。其中，發(fā)送端用于提供或產(chǎn)生原始的流媒體數(shù)據(jù)；接收端用于接收或消費最終的流媒體數(shù)據(jù)；錄制端錄制發(fā)送端提供的流媒體數(shù)據(jù)，在需要時向接收端回放。由于不同的發(fā)送端和接收端可能使用不同格式的解碼器對數(shù)據(jù)進行編碼/解碼，為了便于在回放時將數(shù)據(jù)編碼為與接收端具有相應格式的數(shù)據(jù)報文，現(xiàn)有技術中錄制端使用一種便于轉換的中間格式來存儲錄制的數(shù)據(jù)。例如錄制端將收到的以G.729算法編碼的語音錄制為PCM文件，并在需要時乂人該PCM文件提取語音數(shù)據(jù)編碼到G.723進行播放。其具體過程如下首先，發(fā)送端與錄制端通過協(xié)商確定本次傳輸中數(shù)據(jù)報負載(每一個數(shù)據(jù)報由頭部和負載兩部分組成)的編碼格式為G.729,然后發(fā)送端按G729對應的算法對要傳輸?shù)奈募蛟磾?shù)據(jù)進行提取、編碼、封包為多個RTP數(shù)據(jù)報并將這多個RTP數(shù)據(jù)報以RTP流的形式發(fā)送至錄制端；錄制端提取收到的RTP數(shù)據(jù)報的負載，按G729對應的編碼算法對負載內(nèi)容進行解碼并將解碼后生成的PCM數(shù)據(jù)記入存儲介質(zhì)中；回放時，錄制端與接收端協(xié)商確定數(shù)據(jù)報負載的編碼格式為G.723,然后按G.723格式對存儲的PCM數(shù)據(jù)提取、編碼、封包為相應的RTP數(shù)據(jù)包發(fā)送至接收端。但是，上述錄制、回放過程需要至少兩次編碼轉換錄制時對流媒體數(shù)據(jù)進行解碼，轉換成中間文件保存；回放時從中間文件中提取數(shù)據(jù)重新編碼后發(fā)送。由于流媒體數(shù)據(jù)的傳輸和存儲往往使用有損壓縮算法，反復的解碼、編碼過程會導致信號的衰減、失真；而且這些編解碼算法大多需要復雜的計算處理，增加了系統(tǒng)負荷，限制了系統(tǒng)的處理能力。
發(fā)明內(nèi)容本發(fā)明的目的在于提供一種流媒體數(shù)據(jù)的回放方法、裝置和系統(tǒng)，以解決現(xiàn)有技術中在回放流媒體數(shù)據(jù)時需要對流媒體數(shù)據(jù)進行多次編解碼轉換導致的信號質(zhì)量下降、系統(tǒng)處理能力受限的問題。為解決上述問題，本發(fā)明公開了一種流媒體數(shù)據(jù)的回放方法，該方法包括錄制步驟將數(shù)據(jù)"t艮文記入存儲介質(zhì)；回放步驟從存儲介質(zhì)中獲取所述數(shù)據(jù)報文；將所述數(shù)據(jù)報文發(fā)送至接收端。優(yōu)選的，所述用于記入存儲介質(zhì)的數(shù)據(jù)報文根據(jù)源數(shù)據(jù)直接生成。優(yōu)選的，所述用于記入存儲介質(zhì)的數(shù)據(jù)報文來自發(fā)送端。優(yōu)選的，所述錄制步驟還包括與發(fā)送端協(xié)商確定數(shù)據(jù)報文負載的編碼格式；將與該編碼格式相應的參數(shù)記入存儲介質(zhì)；所述回放步驟還包括通知接收端回放時數(shù)據(jù)報文負載使用的編碼格式和/或相應的參數(shù)。優(yōu)選的，所述數(shù)據(jù)報文中包括該數(shù)據(jù)報文的序號，所述將數(shù)據(jù)報文記入存儲介質(zhì)包括以下步驟將多個數(shù)據(jù)報文放入預置長度的緩沖區(qū)中重新排序；將排序后的數(shù)據(jù)報文按順序記入存儲介質(zhì)；所述將數(shù)據(jù)報文發(fā)送至接收端是從存儲介質(zhì)中按順序獲取所述數(shù)據(jù)報文并發(fā)送至接收端。優(yōu)選的，所述數(shù)據(jù)報文中還包括該數(shù)據(jù)報文的時戳；所述回放步驟還包括對所述多個數(shù)據(jù)報文按順序重新設置序號和時戳。優(yōu)選的，所述方法還包括根據(jù)相鄰數(shù)據(jù)報文的時戳差值確定發(fā)送數(shù)據(jù)報文的時間間隔；按照所述時間間隔將數(shù)據(jù)報文發(fā)送至接收端。為解決上述問題，本發(fā)明公開了一種流媒體數(shù)據(jù)的回放裝置，包括數(shù)據(jù)報文記入單元，用于將數(shù)據(jù)報文記入存儲單元；存儲單元，用于存儲數(shù)據(jù)報文；回放單元，用于從存儲單元中獲取并發(fā)送數(shù)據(jù)報文。優(yōu)選的，所述數(shù)據(jù)報文根據(jù)源數(shù)據(jù)直接生成。優(yōu)選的，所述裝置還包括接口單元，用于接收數(shù)據(jù)報文；所述數(shù)據(jù)報文記入單元從所述接口單元中獲得數(shù)據(jù)報文，并將該數(shù)據(jù)報文記入存儲單元。優(yōu)選的，所述裝置還包括協(xié)商單元，用于確定所述數(shù)據(jù)^^文負載的編碼格式；參數(shù)記入單元，用于將協(xié)商單元確定的數(shù)據(jù)報文負載編碼格式的參數(shù)記入存儲單元；通知單元，用于從存儲單元中獲得的數(shù)據(jù)報文負載編碼格式的參數(shù)并發(fā)送該編碼格式和/或相應的參數(shù)。優(yōu)選的，所述裝置還包括緩沖區(qū)，用于對多個數(shù)據(jù)報文按報文的序號重新排序；所述數(shù)據(jù)報文記入單元按照緩沖區(qū)排序后的順序將數(shù)據(jù)報文記入存儲單元，所述回放單元按照記入的順序回放數(shù)據(jù)報文。優(yōu)選的，所述回放單元包括重置單元，用于對從存儲單元中獲取的數(shù)據(jù)報文重新設置序號和時戳。發(fā)送單元，用于發(fā)送由重置單元重新設置了序號和時戳的數(shù)據(jù)報文。優(yōu)選的，所述回放單元還包括發(fā)送控制單元，用于控制發(fā)送單元按照相鄰數(shù)據(jù)報文時戳差值的時間間隔發(fā)送數(shù)據(jù)報文。為解決上述問題，本發(fā)明還公開了一種流々某體數(shù)據(jù)的錄制、回放系統(tǒng)，包括發(fā)送端、錄制端和接收端，其中，發(fā)送端，用于發(fā)送數(shù)據(jù)報文；所述錄制端包括接口單元，用于接收數(shù)據(jù)報文；數(shù)據(jù)報文記入單元，用于將數(shù)據(jù)l艮文記入存儲單元；存儲單元，用于存儲數(shù)據(jù)報文；回放單元，用于從存儲單元中獲取并發(fā)送數(shù)據(jù)報文；所述接收端，用于接收回放單元發(fā)送的數(shù)據(jù)報文。根據(jù)本發(fā)明的一個具體實施例，本發(fā)明能夠取得以下效果本發(fā)明在錄制流媒體數(shù)據(jù)時不必對流媒體數(shù)據(jù)進行解碼，而是按照數(shù)據(jù)報文負載原有的編碼格式存儲收到的數(shù)據(jù)報文；在回放流媒體數(shù)據(jù)時也無需對流媒體數(shù)據(jù)重新編碼，而是以數(shù)據(jù)報文原有的編碼格式發(fā)送該數(shù)據(jù)報文。由于避免了現(xiàn)有技術在錄制和回放流媒體數(shù)據(jù)時的解碼和重新編碼的過程，因此，有效保證了流媒體數(shù)據(jù)傳輸?shù)馁|(zhì)量，提高了系統(tǒng)錄制、回放流媒體數(shù)據(jù)的容量和處理能力。進一步的，本發(fā)明在錄制流媒體數(shù)據(jù)時將收到的數(shù)據(jù)報文放入預置長度的緩沖區(qū)，按報文序號或時戳進行排序后存儲，回放流媒體數(shù)據(jù)時，按照所述存儲順序回放數(shù)據(jù)報文，避免了數(shù)據(jù)報文在傳輸過程中的時延和亂序的問題，提高了流^某體數(shù)據(jù)的傳輸質(zhì)量。另外，當數(shù)據(jù)報文的來源不同時，本發(fā)明對收到的多個數(shù)據(jù)報文重新設置報文序號和時戳，回放時，按照重新設置后的序號和時戳播放報文，實現(xiàn)了對不同流媒體數(shù)據(jù)的合并錄制、回放，擴展了對流媒體數(shù)據(jù)的處理能力。圖1是流媒體數(shù)據(jù)的錄制、回放系統(tǒng)的實體關系圖2a是本發(fā)明所述流媒體數(shù)據(jù)回放方法的實施例1中錄制、存儲流媒體數(shù)據(jù)的步驟流程圖2b是本發(fā)明所述流媒體數(shù)據(jù)回放方法的實施例1中回放流媒體數(shù)據(jù)的步驟流程圖3是本發(fā)明所述流媒體數(shù)據(jù)回放方法的實施例4的步驟流程圖；圖4是本發(fā)明所述流媒體數(shù)據(jù)回放裝置一實施例的結構框圖；圖5是本發(fā)明所述流媒體數(shù)據(jù)錄制、回放系統(tǒng)一實施例的實體關系圖。具體實施例方式現(xiàn)有技術在對流媒體數(shù)據(jù)錄制、回放時，錄制端將收到的RTP報文進行解碼并生成一種便于轉換的中間格式數(shù)據(jù)存儲在介質(zhì)中，當回放時，再將該中間格式數(shù)據(jù)重新編碼后發(fā)送。由于整個過程需要對RTP報文進行多次編解碼轉換，并且使用的編解碼算法都使用了有矢量量化等有損變換手段，因此降低了信號的質(zhì)量，也限制了系統(tǒng)的處理能力。本發(fā)明在錄制時將收到的RTP報文按該報文的編碼格式直接存儲在存儲介質(zhì)中，在回放時，從存儲介質(zhì)中提取所述RTP報文，并且仍按照該報文的編碼格式將其發(fā)送至接收端，由于避免了中間的多次編解碼轉換，因此有效地解決了上述問題。需要說明的是，雖然現(xiàn)有技術對流^某體數(shù)據(jù)的傳輸基于RTP協(xié)議，但本發(fā)明所述的對流媒體數(shù)據(jù)的錄制、回放并不局限于RTP協(xié)議，隨著技術發(fā)展以及新標準的出現(xiàn)，不排除使用其他協(xié)議的可能性。為了更好的理解本發(fā)明，在下文的描述中，仍以RTP協(xié)議為例進行說明。在介紹本發(fā)明的具體實施方式之前，首先對本發(fā)明涉及的一些名詞和相關概念作一簡單介紹IETF,是一個由為互聯(lián)網(wǎng)技術工程及發(fā)展做出貢獻的專家參與和管理的技術機構，成立于1985年底，主要任務是負責互聯(lián)網(wǎng)相關技術標準的研發(fā)和制定，目前已成為全球互聯(lián)網(wǎng)界最具權威的大型技術標準組織。IETF發(fā)布的標準一般都是以RFC文檔面世，并得到全球互聯(lián)網(wǎng)行業(yè)、軟件行業(yè)及系統(tǒng)集成行業(yè)的采用，成為全3求通用的標準。ITU,ITU就是國際電信耳關盟(InternationalTelecommunicationUnion,簡稱ITU),是電信界最權威的標準制訂機構，成立于1865年5月17日，1947年10月15日成為聯(lián)合國的一個專門機構，總部設在瑞士日內(nèi)瓦。RFC,RequestforComments首字母的縮寫，它是IETF(互聯(lián)網(wǎng)工程任務推進組織)的一個無限制分發(fā)文檔。RFC被編號并且用編號來標識。一些RFC描述了標準化協(xié)議。RTP,實時傳輸協(xié)議，RFC3550。UDP,用戶才艮文協(xié)議，RFC768。PCM,脈沖編碼調(diào)制(PulseCodeModulation),數(shù)字通信的編碼方式之一。主要過程是將話音、圖像等模擬信號每隔一定時間進行取樣，使其離散化，同時將抽樣值按分層單位四舍五人取整量化，同時將抽樣值按一組二進制碼來表示抽樣脈沖的幅值。G.729，是ITU制定通過的8kbps的語音編碼標準，它采用共軛結構的算術碼激勵線性預測(CS-ACELP:Conjugate-StructureAlgebraicCodeExcitedLinearPrediction)算法。H.245多媒體通信控制協(xié)議，是H.323多媒體通信體系中的控制信令協(xié)議，其主要用于處于通信中的H.323終點或終端間的端到端H.245信息交換。H.245所傳送的信息包含終端交換能力的信息以及開通和關閉邏輯信道等信息。通過呼叫信令程序建立連接之后，H.245呼叫控制協(xié)議就會在呼叫建立之前被用來解決呼叫媒介類型問題和建立媒介流，同時在呼叫建立之后對呼叫進行管理。R323是ITU多媒體通信系列標準H.32x的一部份，該系列標準使得在現(xiàn)有通信網(wǎng)絡上進行視頻會議成為可能。H.323為現(xiàn)有的包交換網(wǎng)絡(如IP網(wǎng)絡)提供多媒體通信標準。SDP會話描述協(xié)議，RFC2327、RFC3266。SDP(SessionDescriptionProtocol)為會話通知、會話邀請和其它形式的多媒體會話初始化等目的提供了多媒體會話描述。SDP完全是一種會話描述格式，它不屬于傳輸協(xié)議它只使用不同的適當?shù)膫鬏攨f(xié)議，包括會話通知協(xié)議(SAP)、會話初始協(xié)議(SIP)、實時流協(xié)議(RTSP)、MIME擴展協(xié)議的電子郵件以及超文本傳輸協(xié)議(HTTP)等。SIP會話初始化協(xié)議，RFC326LSIP(SessionInitiationProtocol)是一種應用層控制協(xié)議，它可用來創(chuàng)建、修改或終止多媒體會話，如因特網(wǎng)電話呼叫。SIP能夠邀請參與者加入已存在的會話，如組播會議?，F(xiàn)有的會話中可以添加或刪除々某體。SIP支持名稱映射和重定向服務，即支持用戶移動性不管用戶網(wǎng)絡位置在哪，用戶只需維持單一外部可視標識符。本發(fā)明對流媒體數(shù)據(jù)的回放基于分組交換實現(xiàn)。所謂分組交換也稱包交換，它是將需要傳送的原始數(shù)據(jù)分割為若干個較短的部分，每個部分叫做一個分組。在每個分組的前面加上一個分組頭部，用以指明該分組發(fā)往目的地址，然后把這些分組逐個發(fā)送出去，在各路由點(即負責選擇路徑的分組交換機)根據(jù)各分組中的目的地址獨立尋找路徑。不同的分組可能沿著不同的路徑到達目的地。最后，接收端將收到的分組去掉分組頭部，按順序組合成完整的原始數(shù)據(jù)。使用RTP協(xié)議傳輸流媒體數(shù)據(jù)時，RTP協(xié)議負責對流媒體數(shù)據(jù)進行封包并實現(xiàn)流媒體的實時傳輸，其中，將流媒體數(shù)據(jù)劃分成的多個數(shù)據(jù)分組稱為RTP數(shù)據(jù)報，每一個RTP數(shù)據(jù)報都由頭部(Header)和負載(Payload)兩個部分組成，其中頭部前12個字節(jié)的含義是固定的，而負載則可以是音頻或者視頻數(shù)據(jù)。RTP數(shù)據(jù)報的頭部格式如下<table>tableseeoriginaldocumentpage11</column></row><table>同步源標識符(SSRC)貢獻源標識符(CSRC)列表其中比較重要的幾個域及其意義如下CSRC記數(shù)(CC):表示CSRC標識的數(shù)目。CSRC標識緊跟在RTP固定頭部之后，用來表示RTP數(shù)據(jù)報的來源，RTP協(xié)議允許在同一個會話中存在多個數(shù)據(jù)源，它們可以通過RTP混合器合并為一個數(shù)據(jù)源。例如，可以產(chǎn)生一個CSRC列表來表示一個電話會議，該會議通過一個RTP混合器將所有講話者的語音數(shù)據(jù)組合為一個RTP數(shù)據(jù)源。負載類型(PT,PayloadType):記錄負載類型編碼，用于識別RTP有效載荷的格式，并通過應用程序決定其解釋。剖分(Profile)文件規(guī)定了從負載類型編碼到負載格式的缺省靜態(tài)映射，包括所采用的編碼算法、采樣頻率、承載通道等。例如，類型2表明該RTP數(shù)據(jù)包中承載的是用ITUG.721算法編碼的語音數(shù)據(jù)，采樣頻率為8000Hz，并且采用單聲道。另外的負載類型編碼還可通過非RTP方法實現(xiàn)動態(tài)定義。序號用來為接收方提供探測數(shù)據(jù)丟失的方法，但如何處理丟失的數(shù)據(jù)則是接收方自己的事情，RTP協(xié)議本身并不負責數(shù)據(jù)的重傳。時戳記錄了負載中第一個字節(jié)的釆樣時間，接收方能夠利用時戳確定數(shù)據(jù)的到達是否受到了延遲抖動的影響，但具體如何來S卜償延遲抖動則由接收方自行決定。從RTP數(shù)據(jù)報的格式不難看出，它包含了傳輸媒體的類型、格式、包序號、時戳以及是否有附加數(shù)據(jù)等信息，這些都為實時的流媒體傳輸提供了相應的基礎。RTP協(xié)議的目的是提供實時數(shù)據(jù)(如交互式的音頻和視頻)的端到端傳輸服務，因此在RTP中沒有連接的概念，它可以建立在底層的面向連接或面向非連接的傳輸協(xié)議之上；RTP也不依賴于特別的網(wǎng)絡地址格式，而僅僅只需要底層傳輸協(xié)議支持組幀(Framing)和分段(Segmentation)就足夠了；另外RTP本身還不提供任何可靠性機制，這些要由傳輸協(xié)議或者應用程序自己來保證。需要指出，對于本發(fā)明所述的錄制和回放過程中涉及的三種角色實體，同一物理設備在邏輯上可以同時充當不同角色。如一個實時視頻會議終端即是發(fā)送端又是接收端；錄制端在錄制時是接收端、在回放時是發(fā)送端。發(fā)送端和接收端可以是任何IP電話、語音網(wǎng)關、視頻終端、會議服務器等產(chǎn)生/消費流媒體數(shù)據(jù)的標準設備。發(fā)送端流媒體數(shù)據(jù)可能直接來自音/視頻捕捉設備如話筒、攝像頭，也可能來源于事先記錄的流媒體文件如mp3音樂，還可能是直接由計算機合成的如TTS(文本語音轉換)。還可能是其他來源。本發(fā)明對發(fā)送端流媒體數(shù)據(jù)的來源不做限制。本發(fā)明所述的流i某體數(shù)據(jù)的回放方法的實施例1中，錄制端將收到的數(shù)據(jù)報文按照該報文的編碼格式記入存儲介質(zhì)，回放時從存儲介質(zhì)中獲取數(shù)據(jù)報文并將其發(fā)送至接收端。如圖2a所示，是實施例1中錄制、存儲流i某體it據(jù)的步驟流程圖。步驟S211:發(fā)送端與錄制端協(xié)商確定傳輸?shù)腞TP數(shù)據(jù)報文所采用的編碼格式。RTP數(shù)據(jù)報文所采用的編碼格式就是指該報文負載部分的格式，該編碼格式?jīng)Q定了如何對該RTP數(shù)據(jù)報文進行解碼等相關操作，例如使用何種編解碼算法等。對于一個RTP報文，其編碼格式通過該RTP報文負載的剖分參數(shù)決定。RTP報文中的負載類型是一個0-255的單字節(jié)整數(shù)，每個數(shù)值都對應一種特定的編解碼算法和應用該算法所使用的特定參數(shù)。RFC3551(RTPProfileforAudioandVideoConferenceswithMinimalControl,最小4空制的音頻和^見頻會i義的RTP剖分)標準(以及其他輔助IETF標準)失見定了這些數(shù)值和相應編解碼算法之間的映射關系，并規(guī)定了部分編解碼算法所使用的參數(shù)。這一映射關系及其參數(shù)被統(tǒng)稱為rtp負載的剖分參數(shù)。錄制端必須掌握從RTP報文的負載類型到相應編解碼算法及其參數(shù)的映射才能正確解碼。由于RFC3551僅規(guī)定了部分參數(shù)(最小控制部分)的取值，部分參數(shù)僅指定了可以由應用覆蓋的缺省值，僅依靠RFC3551是不能獲取所需的全部剖分參數(shù)的。因此錄制端在錄制過程中必須通過其他方式得到RTP報文負載編碼格式相應的參數(shù)。發(fā)送端向錄制端向提供負載參數(shù)的方式很多，具體可根據(jù)雙方采用的協(xié)議來決定，譬如SIP信令控制協(xié)議要求使用SDP會話描述協(xié)議來完成協(xié)商，H.323協(xié)議則要求使用H.245多媒體通信控制協(xié)議。協(xié)商的過程一般是由協(xié)商發(fā)起方(可以是發(fā)送端，也可以是錄制端)提供一組發(fā)起方可接受的媒體描述供對方選擇。協(xié)商過程通常包括以下步驟步驟a:發(fā)送端向錄制端發(fā)起一次協(xié)商請求，該請求中包含了發(fā)送端能夠使用的編碼格式。例如，可提供幾種編碼格式供錄制端選擇。步驟b:錄制端將選擇的結果返回給發(fā)送端。下面以SDP協(xié)議為例描述發(fā)送端與接收端協(xié)商的具體過程SDP協(xié)議標準由RFC2327定義。簡介如下SDP會話描述由若干行〈type〉二〈value〉格式的文本組成，其中，〈type〉是大小寫敏感的單個字符，'y'兩邊不能緊接空格。SDP會話描述由一個會話層描述段和可選的若干媒體層描述段組成，會話層描述段以"v二〈value"行開始，媒體層描述段以"n^〈value〉"開始。標準會話描述格式如下所示(省略較多內(nèi)容)，"*"標示行為可選行，各行之間的順序固定不可變。會話描述格式v=(協(xié)議版本號)0=<用戶名><會話號><此描述的版本號><網(wǎng)絡類型><地址類型><地址>s二(會話名稱)c=*<網(wǎng)全各類型>〈i也址類型〉<連^妄;也址>a=*<屬性>(<屬性:值>)一到多個時間描述零到多個媒體描述時間描述格式t二〈開始時間x結束時間〉注0表明無限制r=*(零到多個重復時間)媒體描述格式!11=<媒體類型><端口><傳輸協(xié)議><格式列表〉0=*(連接信息-若會話描述中已包含連接信息則是可選的)a=*(零到多個屬性描述)<々某體類型>可以是audio/video/application/data/control(音頻/禎L頻/應用[如白板信息]/數(shù)據(jù)[不要向用戶顯示]/控制)。<端口>值的確定取決于對應的"c="域中指定的網(wǎng)絡和在第三個子項中定義的<傳輸協(xié)議>,UDP端口只能在1024-65535之間，RTP端口可以是任意有效的范圍，RTCP端口定義為大于對應RTP端口的奇數(shù)，當分級的多個媒體流編碼通過單一的地址發(fā)送時，須指定多個端口用于傳輸。<傳輸協(xié)議>的值依賴于"0="域中的網(wǎng)絡類型，對于IP4(即互聯(lián)網(wǎng)協(xié)議IPv4)，常用的取值是RTP/AVP(RTPAudio/VideoProfile:RTP音頻/視頻剖分步見范)和udp(UserDatagramProtocol:用戶凄史據(jù)才艮協(xié)i義)。<格式列表>指出了媒體數(shù)據(jù)的傳輸格式列表，對于RTP/AVP,這就是相應RTP報文的〈負載類型〉值的列表，當列表中指定多個負載類型時，表明這些負載類型都被支持，但默認使用第一個。SDP標準定義的屬性描述有(有刪節(jié))a=recvonlya=sendrecva=sendoiily發(fā)送模式，是會話層屬性。a=ptime:<packettime>ptime:該參數(shù)提供一個以毫秒為單位的打包長度。a=framerate:<framerate〉該參數(shù)描述視頻的最大幀數(shù)(frames/sec),允許(整數(shù).小數(shù))格式。a=quality:<quality>該參數(shù)用0-10的整數(shù)值描述建議的編碼質(zhì)量，對視頻來說為了在幀速率和持續(xù)圖像質(zhì)量間指定一個非默認的平衡值。a=fmtp:<負載類型><媒體相關的參數(shù)>fmtp屬性用于指定SDP不了解的，由特定負載類型對應的媒體使用的附力口參數(shù)。a=rtpmap:<》載類型><編碼名稱>/<采樣頻率>[/<編碼參數(shù)>]rtpmap屬性用于對"m一'描述的4式列表〉中的負載類型進行詳細說明。從上述SDP描述格式可知，從連接描述"c^'行的相應域中可以獲取對方的連接地址和網(wǎng)絡類型，從媒體描述"111="行的相應域中可獲取對方提供的媒體類型、傳輸協(xié)議、RTP報文的負載類型等信息，還可以從"a二ptime"和"a二framerate:"等行中獲得關于封包、分幀的指示。對于特定負載類型，還可以從相應的"a二rtpmap:"和"a二fmtp:"行中獲取跟該負載類型相關的編解碼器描述和附加參數(shù)。這些和媒體相關的、解碼所需的參數(shù)就是錄制時需要從發(fā)送端提供的SDP報文中提取，回放時需要放入SDP報文與接收端協(xié)商的負載剖分參數(shù)。以下為針對語音通信的錄制和回放過程中的媒體協(xié)商示例。其媒體協(xié)商使用SDP媒體描述協(xié)議，RTP媒體負載使用G,729a編碼方式。相應信令控制協(xié)議略。發(fā)送端IP地址為192.168.0.1、錄制/回放設備IP地址為192.168.0.2。錄制過程中的媒體協(xié)商過程步驟(1):發(fā)送端發(fā)起一次SDP協(xié)商，SDP報文如下。提供G,729a、G711a、&71111三種編碼方式(建議&7293),發(fā)送端RTP端口18990。v=0o=Sender179380INIP4192.168.0.1s=-t=00m=audio18990RTP/AVP1808c=INIP4192.168.90.1a=rtpmap:18G729/8000a=fmtp:18annexb=noa=rtpmap:0PCMU/8000a=rtpmap:8PCMA/80003=s6ndrscv步驟(2):錄制端同意該SDP協(xié)商，向發(fā)送端返回SDP報文。選擇G729a編碼方式，錄制端RTP端口26536。v=0o=Recorder109400INIP4192.168.0.2s=-t=00m=audio26536RTP/AVP18c=INIP4192.168.0.2a=rtpmap:18G729/8000a=fmtp:18annexb=no3=scndr6cv步驟(3):錄制端將與RTP報文負載編碼格式相應的參數(shù)信息記入存儲介質(zhì)。將協(xié)商結果中的RTP負載剖分參數(shù)部分(G729a及其參數(shù))作為相應RTP流的媒體描述記入存儲介質(zhì)供回放時使用。地址、端口、會話號等其他僅在本次錄制過程中使用的參數(shù)不必長期存儲。步驟212:發(fā)送端使用協(xié)商確定的編碼格式對源數(shù)據(jù)進行編碼，并封包為RTP才艮文。例如若協(xié)商確定使用G729a作為RTP報文的編碼格式，則發(fā)送端對源數(shù)據(jù)進行提取，并使用&729編碼器對該數(shù)據(jù)編碼，然后加上報文頭封包為RTP報文。步驟213:發(fā)送端將RTP報文發(fā)送至錄制端。一個數(shù)據(jù)源通常會被封包為多個RTP報文，因此發(fā)送給錄制端的實際上包含了多個RTP報文的RTP流。步驟214:錄制端接收RTP報文。步驟215:錄制端將接收到的多個報文放入緩存，并對其重新排序。在分組交換網(wǎng)絡上，報文到達時間是不可預料的；由于不同報文可以選擇不同網(wǎng)絡路由，報文可能被丟棄或者重復、到達順序也可能顛倒。在RTP報文頭部，如果沒有包丟失或者亂序，屬于同一RTP流的報文的包序號應按步進<直1逐包改變。在本發(fā)明中，錄制端可使用較長的包序號滑動窗口，對進入窗口的RTP報文按照序號重排。這可以有效地補償網(wǎng)絡傳輸問題,在沒有丟包的情況下把信號質(zhì)量恢復到發(fā)送端記錄的水平。所述包序號滑動窗口是以當前已接受報文的包序號為起點，按指定窗口長度接收報文并向前滑動，以緩解亂序和時延抖動的報文緩沖區(qū)。如當前已接受的包序號為10、滑動窗口長度為3，則包序號為11、12、13的報文將進入該窗口進行重排，當ll號報文被接受后，包序號為12、13、14的報文將進入該窗口進行重排。由于RTP報文可能以不同的順序和時間間隔到達接收端，在實時播放的情況下，接收端往往使用一定長度的包接收窗口來緩沖時延抖動。然而人耳對語音時延有一定要求，單向延遲若超過200毫秒，其語音質(zhì)量就無法接受了。G729a作為低時延編碼器，每幀仍包括5毫秒前視延遲、10毫秒編碼時延、10毫秒處理延遲。每個RTP凈艮文承載兩個G729a幀，其發(fā)送延遲不低于35毫秒延遲。這限制接收端的緩沖窗口長度不超過4個RTP報文，落在窗口外的報文只能被丟棄。本發(fā)明在錄制端使用較大長度的包接收窗口接收所有在錄制期間到達的RTP報文并按其包序號對其重排，徹底的消除了亂序和時延對語音質(zhì)量的影響。至于選擇何種長度的包接收窗口重排報文，本發(fā)明對此不做限制，可由本領域技術人員在實施本發(fā)明時自行決定，例如可根據(jù)錄制設備機器性能、緩存容量等因素綜合考慮。下面用一個具體的例子說明報文重排過程RTP報文到達順序RTP包序號1RTP包序號RTP包序號4RTP包序號4RTP包序號RTP包序號2RTP報文重排7R丁P包序號1RTP包序號2RTP包序號3RTP包序號4RTP包序號5RTP報文存儲順序此例屮，重排了亂序的2~5號報文，并丟棄了一個重復的4號報文。步驟216:錄制端將重排后RTP報文的按報文順序記入存儲介質(zhì)。優(yōu)選的，將重排后的RTP報文(去除CSRC標識等在回放時會重新生成的內(nèi)容)順序存放在一個文件內(nèi)，其相應的負載剖分參數(shù)存儲在該文件的頭部。另外，負載剖分參數(shù)也可以存儲在獨立的文件中，只要在回放時能找到負載剖分參數(shù)和相應的RTP報文就可以了。本發(fā)明對錄制設備存儲流媒體數(shù)據(jù)的方式?jīng)]有要求，可以是抽象的計算機文件(使用文件系統(tǒng)時)，也可以是》茲盤或閃存上的某些區(qū)域(直接操作存儲設備時)，還可以直接保存在內(nèi)存中。以上描述了錄制端接收、存儲RTP報文的過程，下面參見圖2b對回放RTP報文的過程進行描述步驟221:從存儲介質(zhì)中獲取RTP報文負載編碼格式相應的參數(shù)，將該參數(shù)通知4妄收端。接收端只有在了解RTP報文所使用的具體編解碼格式和相應的參數(shù)后才能正確展現(xiàn)該RTP報文及相應的流媒體數(shù)據(jù)。錄制端向接收端提供負載剖分參數(shù)的方式4艮多，例如使用SDP會話描述協(xié)議來完成協(xié)商。協(xié)商和通知沒有本質(zhì)區(qū)別，兩者的目的都是要讓錄制端和接收端對于媒體流的格式和參數(shù)達成一致。仍以SDP協(xié)議為例，若錄制端的IP地址為192.168.0.2,接收端的IP地址為192.168.0.3。步驟(l):錄制端發(fā)起一次SDP協(xié)商，SDP報文根據(jù)錄制時記錄的RTP流+某體的負載剖分參數(shù)生成如下。提供G.729a編碼方式，回放端RTP端口37122。v=0o=Player882390INIP4192.168.0.2s=-t=00m=audio37122RTP/AVP18c=INIP4192.168.0.2a=rtpmap:18G729/8000a=fmtp:18annexb=no3=ssndrecv步驟(2):接收端同意該SDP協(xié)商，SDP報文如下。接受G/729a編碼方式，接收端RTP端口43893。v=0o=Recorder579260INIP4192.168.0.3s=-t=00m=audio43893RTP/AVP18c=INIP4192.168.0.3a=rtpmap:18G729/8000a=fmtp:18annexb=noa=s6ndr6cv上述過程中，若接收端拒絕或無法使用錄制端提供的編碼方式，則錄制端中斷回力文過程。目前，隨著技術的不斷發(fā)展，發(fā)送端與接收端具有相同格式編碼器的可能性越來越大，若發(fā)送端發(fā)送的RTP報文采用一種編碼方式，則作為消費流媒體數(shù)據(jù)的接收端多數(shù)情況下也會具有相應的編碼器完成對RTP報文的解碼。在這種情況下，本發(fā)明在錄制時按照該RTP報文負載的編碼格式存儲該報文，在回放時，直接從存儲介質(zhì)中獲得該報文并發(fā)送至接收端，由于避免了多次編解碼轉換，因此有效保證了流媒體數(shù)據(jù)的傳輸質(zhì)量。步驟222:從存儲介質(zhì)中按順序讀取RTP報文。步驟223:根據(jù)相鄰RTP報文的時戳差值確定發(fā)送RTP報文的時間間隔；按照該時間間隔將RTP報文發(fā)送至接收端。需要根據(jù)RTP報文負載的時戳記錄和對應的剖分規(guī)范來控制RTP報文的回放速度，從而保證流媒體數(shù)據(jù)以指定幀速率到達接收端，保障接收端的媒體展現(xiàn)質(zhì)量。時戳字段是RTP報文頭部中說明數(shù)據(jù)包時間的同步信息，是數(shù)據(jù)能以正確的時間順序恢復的關鍵。時戳的值給出了報文中數(shù)據(jù)的第一個字節(jié)的采樣時間，要求發(fā)送方時戳的時鐘是連續(xù)、單調(diào)增長的，即使在沒有數(shù)據(jù)輸入或發(fā)送數(shù)據(jù)時也是如此。即使在靜默時，發(fā)送方不必發(fā)送數(shù)據(jù)，但依然保持時戳的增長。下面以G,729a為例說明如何控制RTP報文的回放速度RFC3551指定的G.729剖分規(guī)范參數(shù)為8000Hz采樣頻率、同時指定了其時戳使用采樣時鐘分辨率。由此可推算出一個承載G,729a負載的RTP報文的時戮單位為1秒/8000次=0.000125秒。當回放下述示例中RTP報文時，需要計算相鄰兩個報文之間的時戳差值，用該值乘上時戳單位，就得到兩個報文回;故的時間間隔，具體如下從存儲介質(zhì)中讀取的RTP報文樣本:負載類型==G.729,包序號=53768，時戳=:19143056負載類型==G.729,包序號=53769,時戳==19143216負載類型:=G.729，包序號=53770，時戳==19143376負載類型:=G.729,包序號=53771,時戳=:19143536負載類型:=G.729,包序號=53772，時戳二:19143696從RFC3551中可知G.729負載的時戳單位為0.000125秒，上述兩個相鄰報文間時戳差值為160,由此可知兩個相鄰報文的回放間隔為160x0.000125秒=0.02秒即20毫秒。步驟224:判斷回放是否結束，若沒有，重復執(zhí)行步驟222。至此，回放過程結束。在錄制端回放RTP報文的同時，接收端使用錄制端通知或協(xié)商確定的RTP凈艮文負載編碼格式所對應的編碼器對收到的RTP報文進行解碼，并最終完成對流^某體數(shù)據(jù)的應用，例如直接用于展現(xiàn)如音/視頻播放，也可能記錄成流媒體文件如保存為mp3音樂，還可能直接由計算機處理如ASR(自動語音識別)。以上描述了本發(fā)明實施例1中對流媒體數(shù)據(jù)進行錄制、回》文的全部過程。在本發(fā)明的實施例2中，用于錄制和回放的數(shù)據(jù)報文中包含了該報文負載編碼格式全部的參數(shù)信息，當然，也可以只包含負載編碼格式相應的標識信息。在錄制時，錄制端直接存儲該數(shù)據(jù)報文；回放時，錄制端讀取該數(shù)據(jù)報文并將其發(fā)送至接收端；接收端從收到的數(shù)據(jù)報文中獲取所需的參數(shù)信息，或者通過所述標識信息獲得該報文負載編碼格式相應的參數(shù)信息，從而完成對該數(shù)據(jù)報文的解碼。另外，在實施例2中，發(fā)送端、錄制端以及接收端還可以預先約定數(shù)據(jù)報文負載的編碼格式以及要使用的參數(shù)，例如編碼器算法等，這樣數(shù)據(jù)報文中只需包含負載及一些必要的信息即可，提高了報文的有效容量。與實施例l相比，由于省略了通過協(xié)商、通知等手段確定報文負載編碼格式及相關參數(shù)的過程，因此進一步提高了流媒體數(shù)據(jù)錄制、回放的速度。實施例2的其他內(nèi)容請參見實施例l,這里不再贅述。本發(fā)明的實施例3與上述實施例相比，錄制端中存儲的用于回放的數(shù)據(jù)報文并非來自發(fā)送端。例如，錄制端直接對源數(shù)據(jù)進行提取、編碼、封包為數(shù)據(jù)報記入存儲介質(zhì)。對于回放單個RTP流媒體文件時，RTP報文的包序號和時戳一般都是連續(xù)的，但是若將編碼格式相同的多個RTP流媒體文件合并為一個流順序播放時，譬如把朗誦單個數(shù)字的語音動態(tài)組合成播報多位數(shù)字的語音。這就需要按照其先后關系調(diào)整各個回放的RTP報文中的包序號和時戳，使其保持連續(xù)。實施例四就是對這種情況進行描述實施例4中流媒體數(shù)據(jù)的回放流程如圖3所示。步驟301:將記錄的RTP負載剖分參數(shù)告知接收端。步驟302:從存儲介質(zhì)中讀出記錄的RTP報文。步驟303:根據(jù)當前報文和前一報文的時戳差值延時，按當前發(fā)送狀態(tài)校正時戳。以下是將兩個RTP流合并成一個時的包序號和時戳調(diào)整的示例-降回方t的RTP流1:負載類型-G.729，包序號=53768,時戳=19143056負載類型二G.729,包序號=53769,時戳=19143216負載類型=&729,包序號=53770，時戳=191433764寺回》丈的RTP流2:負載類型二G729,包序號=74533,時戳=24872334負載類型二G.729,包序號=74534,時戳=24872494負載類型二G.729,包序號=74535,時戳=24872654合并后回》文的RTP流負載類型二G.729，包序號=53768,時戳=19143056負載類型=&729，包序號=53769,時戳=19143216負載類型=&729，包序號=53770,時戳=19143376負載類型二G.729，包序號=53771，時戳=19143536負載類型-G.729，包序號=53772,時戳=19143696負載類型二G.729,包序號=53772,時戳=19143856步驟304:將重編包序號、時戳校正后的RTP報文發(fā)送給接收端。步驟305:回到步驟302重復執(zhí)行，直到停止回放。實施例四的其他內(nèi)容請參見上述實施例，這里不再贅述。下面以一個具體的文件為例說明所述回》文方法的詳細過程。在該例中，發(fā)送端需要發(fā)送一個格式為MP3的文件到錄制端，并且發(fā)送端發(fā)送的RTP報文使用G.729編碼才各式。發(fā)送端與錄制端協(xié)商以G,729作為RTP報文的編碼格式。發(fā)送端對所述MP3文件進件解碼生成PCM數(shù)據(jù)流。使用G.729編碼器對所述PCM數(shù)據(jù)流進行編碼生成G.729數(shù)據(jù)。對所述G.729數(shù)據(jù)進行封包生成RTP流，該RTP流包含多個RTP報文。錄制端接收所述RTP流，并將相應的多個RTP報文放入緩存(滑動窗口)重新排序。按順序將重排后的RTP報文記入存儲介質(zhì)。以下為回》文的過程錄制端通知接收端報文負載的編碼格式為G.729。從存儲介質(zhì)中按順序讀取RTPl艮文并發(fā)送至接收端。接收端收到RTP報文后提取該報文的負載部分，使用G729解碼器對其進行解碼生成PCM數(shù)據(jù)流，最后實現(xiàn)播放。以上結合具體的實施例描述了本發(fā)明所述的流媒體數(shù)據(jù)的回放方法，參照以上有關本發(fā)明的介紹，如圖4所示，是本發(fā)明所述的一種流i某體數(shù)據(jù)回放裝置，所述裝置包括數(shù)據(jù)報文記入單元410,用于將數(shù)據(jù)報文記入存儲單元；存儲單元420,用于存儲數(shù)據(jù)報文；回放單元430，用于從存儲單元中獲取并發(fā)送數(shù)據(jù)才艮文。優(yōu)選的，所述數(shù)據(jù)報文根據(jù)源數(shù)據(jù)直接生成。優(yōu)選的，所述裝置還包括接口單元440,用于接收數(shù)據(jù)報文；所述數(shù)據(jù)報文記入單元從所述接口單元中獲得數(shù)據(jù)報文，并將該數(shù)據(jù)報文記入存儲單元。優(yōu)選的，所述裝置還包括協(xié)商單元450,用于確定所述數(shù)據(jù)報文負載的編碼格式；參數(shù)記入單元460,用于將協(xié)商單元確定的數(shù)據(jù)報文負載編碼格式的參數(shù)記入存儲單元；通知單元470,用于從存儲單元中獲得的數(shù)據(jù)報文負載編碼格式的參數(shù)并發(fā)送該編碼格式和/或相應的參數(shù)。優(yōu)選的，所述裝置還包括緩沖區(qū)480，用于對多個數(shù)據(jù)報文按報文的序號重新排序；所述數(shù)據(jù)報文記入單元按照緩沖區(qū)排序后的順序將數(shù)據(jù)報文記入存儲單元，所述回放單元按照記入的順序回放數(shù)據(jù)報文。優(yōu)選的，所述裝置的回放單元包括重置單元431,用于對從存儲單元中獲取的數(shù)據(jù)報文重新設置序號和時戳；發(fā)送單元432，用于發(fā)送由重置單元重新設置了序號和時戳的數(shù)據(jù)報文。優(yōu)選的，所述裝置的回放單元還包括發(fā)送控制單元433,用于控制發(fā)送單元按照相鄰數(shù)據(jù)報文時戳差值的時間間隔發(fā)送數(shù)據(jù)報文。在錄制流媒體數(shù)據(jù)時，首先，協(xié)商單元確定即將接收的數(shù)據(jù)報文負載的編碼格式，并由參數(shù)記入單元將該負載編碼格式的參數(shù)記入存儲單元；數(shù)據(jù)報文記入單元將從接口單元獲得的數(shù)據(jù)報文放入緩沖區(qū)按序號排序，并按照排序后的順序將該數(shù)據(jù)報文記入存儲單元；在需要回放流媒體數(shù)據(jù)時，首先，通知單元從存儲單元中獲得的數(shù)據(jù)報文負載編碼格式的參數(shù)并發(fā)送該編碼格式和/或相應的參數(shù)；然后，重置單元對從存儲單元中獲取的數(shù)據(jù)報文重新設置序號和時戳，由發(fā)送單元發(fā)送該數(shù)據(jù)報文；進一步的，發(fā)送控制單元控制發(fā)送單元按照相鄰數(shù)據(jù)報文時戳差值的時間間隔發(fā)送數(shù)據(jù)報文。圖5示出了本發(fā)明的一種流媒體數(shù)據(jù)的錄制、回放系統(tǒng)，其特征在于，包括發(fā)送端510、錄制端520和接收端530，其中，發(fā)送端，用于發(fā)送數(shù)據(jù)報文；所述錄制端包括接口單元521，用于接收數(shù)據(jù)報文；數(shù)據(jù)報文記入單元522，用于將數(shù)據(jù)報文記入存儲單元；存儲單元523,用于存儲數(shù)據(jù)報文；回放單元524,用于從存儲單元中獲取并發(fā)送數(shù)據(jù)報文；所述接收端，用于接收回放單元發(fā)送的數(shù)據(jù)報文。以上對本發(fā)明所提供的一種流媒體數(shù)據(jù)的回放方法、裝置以及一種流媒體數(shù)據(jù)的錄制、回放系統(tǒng)，進行了詳細介紹，本文中應用了具體個例對本發(fā)明的原理及實施方式進行了闡述，以上實施例的說明只是用于幫助理解本發(fā)明的方法及其核心思想；同時，對于本領域的一般技術人員，依據(jù)本發(fā)明的思想，在具體實施方式及應用范圍上均會有改變之處，綜上所述，本說明書內(nèi)容不應理解為對本發(fā)明的限制。權利要求1、一種流媒體數(shù)據(jù)的回放方法，其特征在于，該方法包括錄制步驟將數(shù)據(jù)報文記入存儲介質(zhì)；回放步驟從存儲介質(zhì)中獲取所述數(shù)據(jù)報文；將所述數(shù)據(jù)報文發(fā)送至接收端。2、根據(jù)權利要求1所述的方法，其特征在于，所述用于記入存儲介質(zhì)的數(shù)據(jù)報文根據(jù)源數(shù)據(jù)直接生成。3、根據(jù)權利要求1所述的方法，其特征在于，所述用于記入存儲介質(zhì)的數(shù)據(jù)報文來自發(fā)送端。4、根據(jù)權利要求3所述的方法，其特征在于，所述錄制步驟還包括與發(fā)送端協(xié)商確定數(shù)據(jù)報文負載的編碼格式；將與該編碼格式相應的參數(shù)記入存儲介質(zhì)；所述回放步驟還包括通知接收端回放時數(shù)據(jù)報文負載使用的編碼格式和/或相應的參數(shù)。5、根據(jù)權利要求4所述的方法，其特征在于，所述數(shù)據(jù)報文中包括該數(shù)據(jù)報文的序號，所述將數(shù)據(jù)報文記入存儲介質(zhì)包括以下步驟將多個數(shù)據(jù)報文放入預置長度的緩沖區(qū)中重新排序；將排序后的數(shù)據(jù)報文按順序記入存儲介質(zhì)；所述將數(shù)據(jù)報文發(fā)送至接收端是從存儲介質(zhì)中按順序獲取所述數(shù)據(jù)報文并發(fā)送至接收端。6、根據(jù)權利要求5所述的方法，其特征在于，所述數(shù)據(jù)報文中還包括該數(shù)據(jù)報文的時戳；所述回放步驟還包括對所述多個數(shù)據(jù)報文按順序重新設置序號和時戳。7、根據(jù)權利要求6所述的方法，其特征在于，還包括根據(jù)相鄰數(shù)據(jù)報文的時戳差值確定發(fā)送數(shù)據(jù)報文的時間間隔；按照所述時間間隔將數(shù)據(jù)報文發(fā)送至接收端。8、一種流媒體數(shù)據(jù)的回放裝置，其特征在于，包括數(shù)據(jù)報文記入單元，用于將數(shù)據(jù)報文記入存儲單元；存儲單元，用于存儲數(shù)據(jù)報文；回放單元，用于從存儲單元中獲取并發(fā)送數(shù)據(jù)報文。9、根據(jù)權利要求8所述的裝置，其特征在于，所述數(shù)據(jù)報文根據(jù)源數(shù)據(jù)直接生成。10、根據(jù)權利要求8所述的裝置，其特征在于，還包括接口單元，用于接收數(shù)據(jù)報文；所述數(shù)據(jù)報文記入單元從所述接口單元中獲得數(shù)據(jù)報文，并將該數(shù)據(jù)報文記入存儲單元。11、根據(jù)權利要求IO所述的裝置，其特征在于，還包括協(xié)商單元，用于確定所述數(shù)據(jù)報文負載的編碼格式；參數(shù)記入單元，用于將協(xié)商單元確定的數(shù)據(jù)報文負載編碼格式的參數(shù)記入存儲單元；通知單元，用于從存儲單元中獲得的數(shù)據(jù)報文負載編碼格式的參數(shù)并發(fā)送該編碼一各式和/或相應的參凄t。12、根據(jù)權利要求11所述的裝置，其特征在于，還包括緩沖區(qū)，用于對多個數(shù)據(jù)報文按報文的序號重新排序；所述數(shù)據(jù)報文記入單元按照緩沖區(qū)排序后的順序將數(shù)據(jù)報文記入存儲單元，所述回放單元按照記入的順序回放數(shù)據(jù)報文。13、根據(jù)權利要求12所述的裝置，其特征在于，所述回放單元包括重置單元，用于對從存儲單元中獲取的數(shù)據(jù)報文重新設置序號和時戳。發(fā)送單元，用于發(fā)送由重置單元重新設置了序號和時戳的數(shù)據(jù)報文。14、根據(jù)權利要求13所述的裝置，其特征在于，所述回放單元還包括發(fā)送控制單元，用于控制發(fā)送單元按照相鄰數(shù)據(jù)報文時戳差值的時間間隔發(fā)送數(shù)據(jù)報文。15、一種流媒體數(shù)據(jù)的錄制、回放系統(tǒng)，其特征在于，包括發(fā)送端、錄制端和接收端，其中，發(fā)送端，用于發(fā)送數(shù)據(jù)報文；所述錄制端包括接口單元，用于接收數(shù)據(jù)報文；數(shù)據(jù)報文記入單元，用于將數(shù)據(jù)報文記入存儲單元；存儲單元，用于存儲數(shù)據(jù)報文；回放單元，用于從存儲單元中獲取并發(fā)送數(shù)據(jù)報文;所述接收端，用于接收回放單元發(fā)送的數(shù)據(jù)報文。全文摘要本發(fā)明公開了一種流媒體數(shù)據(jù)回放方法、裝置和系統(tǒng)，所述方法包括錄制步驟將數(shù)據(jù)報文記入存儲介質(zhì)；回放步驟從存儲介質(zhì)中獲取所述數(shù)據(jù)報文；將所述數(shù)據(jù)報文發(fā)送至接收端。由于避免了現(xiàn)有技術中在錄制和回放過程中對流媒體數(shù)據(jù)的編解碼轉換，因此有效保證了流媒體數(shù)據(jù)的傳輸質(zhì)量，提高了系統(tǒng)的處理能力。文檔編號H04L29/06GK101115011SQ20071012752公開日2008年1月30日申請日期2007年6月28日優(yōu)先權日2007年6月28日發(fā)明者旭李,王則江申請人:恒生電子股份有限公司