基于mpeg-4和rtp的網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)研究(編輯修改稿)
2025-07-19 06:25 本頁面
【文章內(nèi)容簡介】 8[3]所定義的負(fù)載格式傳輸冗余數(shù)據(jù)。這樣，RTP頭后將是一或多個(gè)冗余數(shù)據(jù)塊頭，個(gè)數(shù)與從攜帶的冗余T140塊數(shù)相同，最后是此包的新T140塊。每個(gè)RTP包開始于一個(gè)固定的RTP頭。段。負(fù)載類型（PT）：RTP負(fù)載類型的分配是使用該負(fù)載格式的RTP框架特定的。對(duì)于利用動(dòng)態(tài)負(fù)載類型號(hào)的協(xié)議子集，這種負(fù)載格式被命名為T140（參照第六節(jié)）。如果按照RFC2198使用冗余數(shù)據(jù)，負(fù)載類型中必須指定負(fù)載格式（RED）。順序號(hào)：順序號(hào)必須嚴(yán)格按照每個(gè)新傳送包以一遞增。它用于包丟失和亂序檢測，同時(shí)也可以用于獲取冗余文本，重組文本和標(biāo)記丟失文本。時(shí)間戳：RTP時(shí)間戳記錄了包中主文本塊采樣時(shí)間的近似值。必須使用1000赫茲的時(shí)鐘頻率。連續(xù)包不能使用相同的時(shí)間戳。由于包不按固定間隔發(fā)送，所以時(shí)間戳不能直接被用于指示包丟失。本負(fù)載格式?jīng)]有定義專門的附加頭。當(dāng)要按RFC2198傳輸冗余數(shù)據(jù)時(shí)，RTP頭后緊跟者一個(gè)或多個(gè)冗余數(shù)據(jù)塊頭，每個(gè)冗余數(shù)據(jù)塊都要有一個(gè)對(duì)應(yīng)的冗余數(shù)據(jù)塊頭。這些頭部均提供了時(shí)間戳位移和相應(yīng)的數(shù)據(jù)塊長度，以及指示了這種負(fù)載格式(T140)的負(fù)載類型號(hào)。，沒有額外組幀。當(dāng)用該格式傳輸冗余數(shù)據(jù)時(shí)，發(fā)送者會(huì)選擇每個(gè)包中要傳輸?shù)腡140block數(shù)。數(shù)越高則將丟包保護(hù)性越好，但同時(shí)也會(huì)增加數(shù)據(jù)傳輸率。由于數(shù)據(jù)包并非按一定的時(shí)間間隔產(chǎn)生，如果不提供附加信息，時(shí)間戳在包丟失時(shí)就無法標(biāo)識(shí)出該包。冗余數(shù)據(jù)頭并沒有提供順序號(hào)，所以必須遵循附加規(guī)則才能將丟失主數(shù)據(jù)所對(duì)應(yīng)的冗余數(shù)據(jù)正確的插入T140blocks主數(shù)據(jù)流中：1. 每個(gè)冗余數(shù)據(jù)塊必須與先前傳輸原始數(shù)據(jù)的T140塊數(shù)據(jù)相同，并標(biāo)識(shí)為相同的時(shí)間戳位移。2. 冗余數(shù)據(jù)必須按照時(shí)間順序放置，最近的冗余T140塊位于冗余區(qū)的最后。3. 必須包括從最早的T140blocks到新數(shù)據(jù)塊前的T140blocks所有的T140塊。通過這些規(guī)則，冗余T140塊的順序號(hào)可以從當(dāng)前RTP頭的序號(hào)反向推算得到。結(jié)果就是負(fù)載中的所有文本都是連續(xù)且順序的。這部分描述了負(fù)載格式使用的推薦過程，根據(jù)接受包的信息，接收者可以：1. 把錯(cuò)亂文本重新排序。2. 標(biāo)識(shí)丟失文本。3. 用冗余數(shù)據(jù)補(bǔ)償丟失包。在接收端，將RTP順序號(hào)與最后一次正確接收包的序號(hào)相比較，如果是連續(xù)的，就從中取出T140block。為了減少包丟失時(shí)的數(shù)據(jù)丟失，可以根據(jù)RFC2198在包中使用冗余數(shù)據(jù)。如果無法得知網(wǎng)絡(luò)條件，建議每一包中只使用一個(gè)冗余T140塊。如果RTP序號(hào)出現(xiàn)空隙，且后續(xù)包中的冗余T140塊可用，則可以通過包中RTP頭的序號(hào)逆向推算出冗余T140塊的序號(hào)。如果該冗余T140塊的序號(hào)與丟失的相吻合，就用冗余T140塊來替換丟失T140塊。無論是否使用冗余數(shù)據(jù)，都應(yīng)該在T140塊的接收流中插入一個(gè)丟失文本標(biāo)記來標(biāo)志丟失的數(shù)據(jù)。對(duì)于亂序包的檢測，接收端應(yīng)該采取下屬程序。如果接收包序號(hào)有空隙，但沒有可用的冗余數(shù)據(jù)來填充那個(gè)空隙，則接收包將被存儲(chǔ)在緩存中來等待丟失包的到達(dá)。建議等待時(shí)間。如果使用了冗余，則等待時(shí)間應(yīng)延長到該乘積。如果空隙數(shù)據(jù)包在限制時(shí)間內(nèi)到達(dá)，則將它被插入到空隙中，這樣從空隙前沿開始的T140塊就恢復(fù)連續(xù)了。任何沒有在限制時(shí)間內(nèi)到達(dá)的T140塊將被視為丟失?！办o音期”傳輸，最后傳輸?shù)囊粋€(gè)T140塊有可能在作冗余數(shù)據(jù)傳送之前就失效。這樣就不能對(duì)文本輸入序列的末尾提供有效的丟包保護(hù)。為了要避免這種情況，應(yīng)該傳送一個(gè)0長度的攜帶冗余數(shù)據(jù)的原始T140塊。，為了能正確推算冗余T140塊的序號(hào)，任何被當(dāng)作原始數(shù)據(jù)為0長度的T140塊必須如同正常文本塊一樣在接下來的包中當(dāng)作冗余傳輸。最后一個(gè)T140塊的冗余不應(yīng)該由重復(fù)傳送同一個(gè)包（相同序號(hào)）來解決，因?yàn)檫@樣會(huì)造成RTCP報(bào)告的包丟失數(shù)量減少。這是一個(gè)沒有冗余的T140RTP包的例子012301234567890123456789012345678901+++++++++++++++++++++++++++++++++|V=2|P|X|CC=0|M|T140PT|順序號(hào)|+++++++++++++++++++++++++++++++++|時(shí)間戳(1000Hz)|+++++++++++++++++++++++++++++++++|同步源(SSRC)標(biāo)識(shí)符|+++++++++++++++++++++++++++++++++++||+++||+++++++++++++++++++++++++這是一個(gè)攜帶冗余數(shù)據(jù)的RTP包的例子012301234567890123456789012345678901+++++++++++++++++++++++++++++++++|V=2|P|X|CC=0|M|REDPT|主序號(hào)|+++++++++++++++++++++++++++++++++|原始數(shù)據(jù)時(shí)間戳|+++++++++++++++++++++++++++++++++|同步源(SSRC)標(biāo)識(shí)符|+++++++++++++++++++++++++++++++++|1|T140PT|R時(shí)間戳位移|R塊長度|+++++++++++++++++++++++++++++++++|0|T140PT||++++++++++||+R+||+++|||++++++++++++++++++++++++++|P|+++++||+++++++++++++++++++++++++附圖：RTP文本包的例子5．安全性考慮既然本負(fù)載格式的目的是在文本交談中攜帶文本，加密的安全性度量就變得十分重要。文本傳輸?shù)臄?shù)量很少，行加密。如果數(shù)據(jù)包中包含了冗余數(shù)據(jù)，要使用同RFC2198一樣的安全性考慮。本文檔描述了一種新的RTP負(fù)載名稱和相應(yīng)的MIME類型，T140(text/t140).MIMEmediatypename:textMIMEsubtypename:t140必需參數(shù):無可選參數(shù):無編碼考慮:按RFC2793規(guī)定傳輸T140文本。安全性考慮：無互操作考慮:無已發(fā)行規(guī)范:，RFC2793.使用該媒體類型的應(yīng)用:文本通信終端和文本會(huì)議工具。附加信息:無Magiumber(s):無文件擴(kuò)展:無Macintosh文件類型碼:無聯(lián)系辦法:GunnarHellstrom@預(yù)期使用:COMMONAuthor/Changecontroller:GunnarHellstrom|IETFavtWG@|c/oSteveCasnercasner@鳴謝感謝StephenCasner和ColinPerkins在本文寫作時(shí)給予的細(xì)查和建議。感謝Ericsson公司的MickeyNasiri提供的實(shí)驗(yàn)環(huán)境。感謝MicheleMizarro驗(yàn)證了負(fù)載格式的可用性。作者地址GunnarHellstromOmnitorABAlsnogatan7,4trSE11641StockholmSwedenPhone:+46708204288/+46855600203Fax:+46855600206EMail:@參考[1](1998)Textconversationprotocolformultimediaapplication,withamendment1,(2000).[2]Schulzrinne,H.,Casner,S.,Frederick,RTP:ATransportProtocolforRealTimeApplications,RFC1889,January1996.[3]Perkins,C.,Kouvelas,I.,Hardman,V.,Handley,.Bolot,RTPPayloadforRedundantAudioData,RFC2198,September1997.
環(huán)評(píng)公示相關(guān)推薦
鄂ICP備17016276號(hào)-1