專利名稱：：視頻電話的視頻包成形的制作方法一見頻電話的^見頻包成形枯犬凝i^-T，'z、-—、本發(fā)明涉及視頻電話(VT),且更確切地說，涉及在VT系統(tǒng)中組裝音頻和視頻包以供傳輸?shù)募夹g(shù)。
背景技術(shù)：
：視頻電話(VT)涉及對載運音頻和視頻數(shù)據(jù)的包進行實時傳送。每個VT裝置包含視頻編碼器，其從例如攝像機或視頻檔案等視頻捕獲裝置獲得視頻，并產(chǎn)生視頻包。類似地，每個VT裝置中的音頻編碼器從例如麥克風(fēng)或語音合成器等音頻捕獲裝置獲得音頻，并產(chǎn)生音頻包。將所述視頻包和音頻包放置在無線電鏈路協(xié)議(RLP)隊列中。媒體接入控制(MAC)層模塊從RLP隊列的內(nèi)容產(chǎn)生媒體接入控制(MAC)層包。將MAC層包轉(zhuǎn)換成物理(PHY)層包，以供經(jīng)由通信信道傳輸?shù)搅硪籚T裝置。在移動VT應(yīng)用中，VT裝置經(jīng)由從基站到無線終端的無線前向鏈路(FL)(或"下行鏈路")接收物理層包。VT裝置經(jīng)由從無線終端到基站的無線反向鏈路(RL)(或"上行鏈路")傳輸PHY層包。每個VT裝置包含PHY和MAC層，以便轉(zhuǎn)換接收到的PHY和MAC層包，并將所述包有效負(fù)載重新組裝成音頻包和視頻包。VT裝置內(nèi)的視頻解碼器對視頻數(shù)據(jù)進行解碼，以便經(jīng)由顯示裝置呈現(xiàn)給用戶。VT裝置內(nèi)的音頻解碼器對音頻數(shù)據(jù)進行解碼，以便經(jīng)由音頻揚聲器呈現(xiàn)。無線環(huán)境下的移動VT可具有挑戰(zhàn)性。無線信道上的數(shù)據(jù)速率受到限制且隨著時間而變動。舉例來說，在CDMA2000lxEV-DO0版網(wǎng)絡(luò)中，數(shù)據(jù)速率可能會因無線覆蓋區(qū)域內(nèi)的條件或多個VT用戶間的業(yè)務(wù)擁塞而變動。此外，當(dāng)數(shù)據(jù)速率下降到零時，例如當(dāng)沒有數(shù)據(jù)要發(fā)送時，恢復(fù)成合理數(shù)據(jù)速率可能需要時間。結(jié)果，移動VT可易于遭受不合意的視頻和音頻延遲，這會削弱實時地執(zhí)行流暢的視頻會議的能力。
發(fā)明內(nèi)容一般來說，本發(fā)明針對VT應(yīng)用的視頻包成形技術(shù)。所述視頻包成形技術(shù)可用來將音頻包列入優(yōu)先，以便減少音頻延遲。信道條件、過多的視頻內(nèi)容或兩者可導(dǎo)致音頻包傳輸?shù)娘@著延遲。當(dāng)反向鏈路(RL)處理量減少時，視頻包大小可占滿RL且增加音頻延遲。確切地說，視頻包可填充RLP隊列并消耗過多數(shù)目的MAC層包，從而導(dǎo)致載運音頻包的MAC層包的連續(xù)傳輸之間出現(xiàn)延遲。根據(jù)所揭示的技術(shù)，對每個視頻包的大小進行調(diào)整，以便將音頻包列入優(yōu)先以用于無實質(zhì)延遲地傳輸。確切地說，對提交給RLP隊列的每個視頻包的大小進行控制，以確保及時地傳輸音頻。舉例來說，可將視頻包的大小確定為使得每個音頻包可與從RLP隊列取出的下一可用MAC層包一起發(fā)送。以此方式，可在應(yīng)用層處為音頻包提供服務(wù)質(zhì)量(QoS)?？苫诶鐭o線信道等信道的估計處理量來控制視頻包大小?？苫谛诺罈l件來估計處理量，所述信道條件由當(dāng)前的無線信道傳輸速率、無線基站活動性或傳輸功率限制來表示?？蔁o實質(zhì)延遲地傳送VT會議的音頻部分，即使視頻部分可能會因信道條件遭受延遲。雖然視頻可能會受信道條件損害，但視頻包成形確保VT會議各方仍然能夠流暢地執(zhí)行口頭會話。此外，在有些實施例中，視頻包成形技術(shù)可進一步包含基于視頻緩沖占用率的自適應(yīng)源速率控制。在此情況下，如果信道條件不支持視頻編碼速率，則考慮到列入優(yōu)先的音頻包化的需要，可降低源視頻編碼速率。舉例來說，可基于駐存在視頻緩沖器中的未包化視頻幀數(shù)據(jù)的量來調(diào)整視頻編碼速率。在一個實施例中，本發(fā)明提供一種方法，其包括產(chǎn)生音頻包、估計無線信道的處理量，以及產(chǎn)生具有基于估計的處理量而確定的視頻包大小的視頻包。在另一實施例中，本發(fā)明提供一種系統(tǒng)，其包括音頻編碼器，其產(chǎn)生音頻數(shù)據(jù)；音頻緩沖器，其接收音頻數(shù)據(jù)并輸出音頻包；視頻編碼器，其產(chǎn)生視頻數(shù)據(jù)；包化器，其估計無線信道的處理量，從視頻數(shù)據(jù)產(chǎn)生具有基于估計的處理量而確定的視頻包大小的視頻包。在額外的實施例中，本發(fā)明提供一種計算機可讀媒體，其包括致使處理器執(zhí)行以下操作的指令產(chǎn)生音頻包、估計無線信道的處理量，并產(chǎn)生具有基于估計的處理量而確定的視頻包大小的視頻包。在有些實施例中，基于估計的處理量、音頻包的大小和在將視頻包放置在輸出隊列中之前含有所述音頻包的輸出隊列中的經(jīng)緩沖數(shù)據(jù)的大小，來確定視頻包大小?？蓪⒁曨l包的大小確定為使得可將音頻包放置在從輸出隊列的內(nèi)容產(chǎn)生的下一可用MAC層包中。在附圖和以下描述中闡述一個或一個以上實施例的細(xì)節(jié)。從描述和圖式中且從權(quán)利要求書中將容易明白其它特征、目的和優(yōu)點。圖1是說明用于VT應(yīng)用的視頻/音頻編碼和解碼系統(tǒng)的方框圖。圖2是說明由于過多視頻內(nèi)容、較差的信道條件或兩者而導(dǎo)致的音頻延遲的方框圖。圖3是說明用于固定長度的視頻包成形的技術(shù)的方框圖。圖4是說明用于信道自適應(yīng)視頻包成形的技術(shù)的方框圖。圖5是說明實施信道自適應(yīng)視頻包成形技術(shù)的視頻/音頻編碼系統(tǒng)的方框圖。圖6是說明在一定范圍信道條件下的信道自適應(yīng)視頻包成形的方框圖。圖7是更詳細(xì)地說明在一定范圍信道條件下的信道自適應(yīng)視頻包成形的方框圖。圖8是說明信道自適應(yīng)視頻包成形的技術(shù)的流程圖。具體實施例方式圖1是說明視頻編碼和解碼系統(tǒng)10的方框圖。如圖1所示，系統(tǒng)IO包含編碼器系統(tǒng)12和解碼器系統(tǒng)14，其由傳輸信道16連接。編碼器系統(tǒng)12與第一視頻通信裝置相關(guān)聯(lián)，且包含視頻編碼器20、音頻編碼器22、視頻包化器24、實時傳輸協(xié)議(PTR)/用戶數(shù)據(jù)報協(xié)議(UDP)/因特網(wǎng)協(xié)議(IP)/點對點協(xié)議(PPP)轉(zhuǎn)換模塊26、無線電鏈路協(xié)議(RLP)隊列28、MAC層模塊30和PHY層模塊32。解碼器系統(tǒng)14與另一視頻通信裝置相關(guān)聯(lián)，且包含PHY層模塊34、MAC層模塊36、RLP隊列38、RTP/UDP/IP/PPP轉(zhuǎn)換模塊40、視頻解碼器42和音頻解碼器44。如將描述，包化器24基于信道條件執(zhí)行視頻包成形，以便將音頻包傳輸列入優(yōu)先并進而避免過多的音頻延遲。系統(tǒng)IO可經(jīng)由傳輸信道16(例如)為視頻電話提供雙向視頻和音頻傳輸。相應(yīng)地，可在信道16的相反端提供一般相反的編碼、解碼和轉(zhuǎn)換模塊。在有些實施例中，編碼器系統(tǒng)12和解碼器系統(tǒng)14可包含在視頻通信裝置內(nèi)，例如裝備用于視頻串流傳輸、視頻電話或兩者的無線移動終端。移動終端可根據(jù)例如RTP、LDP、IP或PPP等包交換標(biāo)準(zhǔn)支持VT。RTP/UDP/IP/PPP轉(zhuǎn)換模塊向從音頻編碼器22和視頻包化器24接收的音頻和視頻數(shù)據(jù)添加適當(dāng)?shù)腞TP/UDP/IP/PPP標(biāo)頭數(shù)據(jù)，且將所述數(shù)據(jù)放置在RLP隊列28中。RTP在UDP上運行，而UDP在IP上運行，且IP在PPP上運行。MAC層模塊30從RLP隊列28的內(nèi)容產(chǎn)生MACRLP包。PHY層模塊30將MACRLP包轉(zhuǎn)換成PHY層包以以用于在信道16上傳輸。解碼系統(tǒng)M的PHY層模塊34和MAC層模塊36以相反方式操作。PHY層模塊34將從信道16接收的PHY層包轉(zhuǎn)換成MACRLP包。MAC層模塊36將MACRLP包放置到RLP隊列38中。RTP/UDP/IP/PPP轉(zhuǎn)換模塊40從RLP隊列38中的數(shù)據(jù)中剝離標(biāo)頭信9息，并重新組裝視頻和音頻數(shù)據(jù)以供分別傳遞到視頻解碼器42和音頻解碼器44。系統(tǒng)10可經(jīng)設(shè)計以支持一種或一種以上無線通信技術(shù)，例如碼分多址(CDMA)、頻分多址(FDMA)、時分多址(TDMA)或正交頻分多路復(fù)用(OFDM)或另一合適的無線技術(shù)。以上無線通信技術(shù)可根據(jù)多種無線電接入技術(shù)中的任一者來傳遞。舉例來說，可根據(jù)cdma2000或?qū)拵DMA(WCDMA)標(biāo)準(zhǔn)來傳遞CDMA。可根據(jù)全球移動通信系統(tǒng)(GSM)標(biāo)準(zhǔn)來傳遞TDMA。通用移動電信系統(tǒng)(UMTS)標(biāo)準(zhǔn)準(zhǔn)許GSM或WCDMA操作。通常對于VT應(yīng)用來說，系統(tǒng)10將經(jīng)設(shè)計以支持例如cdma2000lxEV-DO0版本等高數(shù)據(jù)速率(HDR)技術(shù)。視頻編碼器20根據(jù)例如MPEG-4等視頻壓縮方法來產(chǎn)生編碼的視頻數(shù)據(jù)?？墒褂闷渌曨l壓縮方法，例如國際電信聯(lián)盟(ITU)H.263、ITUH.264或MPEG-2方法。音頻編碼器22編碼將伴隨視頻數(shù)據(jù)的音頻數(shù)據(jù)?？蓮睦鐢z像機或視頻檔案等視頻捕獲裝置獲得視頻?？筛鶕?jù)例如自適應(yīng)多速率窄帶(AMR-NB)或其它技術(shù)等音頻壓縮方法來編碼音頻數(shù)據(jù)?？蓮睦琨溈孙L(fēng)或語音合成器裝置等音頻捕獲裝置獲得音頻。對于VT應(yīng)用，視頻將準(zhǔn)許一方觀看VT會議，且音頻將準(zhǔn)許聽到所述方的講話聲音。在操作中，RTP/UDP/IP/PPP轉(zhuǎn)換模塊26從視頻編碼器20和音頻編碼器22獲得視頻和音頻數(shù)據(jù)包。RTP/UDP/IP/PPP轉(zhuǎn)換模塊26向音頻包添加適當(dāng)?shù)臉?biāo)頭信息，并將所得數(shù)據(jù)插入在RLP隊列28內(nèi)。同樣，RTP/UDP/IP/PPP轉(zhuǎn)換模塊26向視頻包添加適當(dāng)?shù)臉?biāo)頭信息，并將所得數(shù)據(jù)插入在RLP隊列28內(nèi)。MAC層模塊30從RLP隊列28中檢索數(shù)據(jù)，并形成MAC層包。每個MAC層包載運RTP/UDP/IP/PPP標(biāo)頭信息和RLP隊列28內(nèi)含有的音頻或視頻包數(shù)據(jù)。獨立于視頻包將音頻包插入在RLP隊列28中。然而，包化器24控制添加到RLP隊列28的視頻包的大小，使得每個音頻包均可由下一可用MAC層包載運。在有些情況下，從RLP隊列28的內(nèi)容產(chǎn)生的MAC層包將只載運標(biāo)頭信息和視頻包數(shù)據(jù)。在其它情況下，MAC層包將只載運標(biāo)頭信息和音頻包數(shù)據(jù)。在許多情況下，MAC層包將載運標(biāo)頭信息、音頻包數(shù)據(jù)和視頻包數(shù)據(jù)，這取決于RLP隊列28的內(nèi)容。MAC層包可根據(jù)無線電鏈路協(xié)議(RLP)來配置，且可稱為MACRLP包。PHY層模塊32可包含將MACRLP音頻-視頻包轉(zhuǎn)換成PHY層包以供經(jīng)由信道16傳輸。信道16將PHY層包載運到解碼器系統(tǒng)14。信道16可為編碼器系統(tǒng)12與解碼器系統(tǒng)14之間的任何物理連接。舉例來說，信道16可以是有線連接，例如局域或廣域有線網(wǎng)絡(luò)?；蛘撸绫疚闹忻枋?，信道16可以是無線連接，例如蜂窩式、衛(wèi)星或光學(xué)連接。信道條件可能是有線和無線信道的關(guān)注因素，而且對于經(jīng)由無線信道16執(zhí)行的移動VT應(yīng)用尤其成問題。根據(jù)本發(fā)明，視頻包化器24控制提供到RTP/UDP/IP/PPP轉(zhuǎn)換模塊26的每個視頻包的大小，以便將音頻的傳輸列入優(yōu)先。確切地說，將視頻包的大小確定為使得每個包均可由下一可用的MAC層包容納。對視頻包的大小進行控制防止了因信道條件、較大的視頻包或兩者導(dǎo)致的音頻延遲。當(dāng)有音頻包可用時，將其放置在RLP隊列中以包含在MAC層模塊30所產(chǎn)生的下一可用MACRLP包中。音頻包可與大小已經(jīng)過確定而準(zhǔn)許將音頻包放置在MACRLP包內(nèi)的空間的視頻包組合。視頻包化器24經(jīng)配置以在其能夠基于信道條件來調(diào)整視頻包大小的意義上成為信道自適應(yīng)的。以此方式，編碼器系統(tǒng)12可將音頻包的傳輸列入優(yōu)先，以避免在信道條件較差時發(fā)生音頻延遲。同時，視頻包化器24可確保將音頻列入優(yōu)先不會導(dǎo)致視頻包被包化不足。換句話說，視頻包化器24將視頻包的大小確定得足夠小而準(zhǔn)許將一個或一個以上音頻包包含在下一可用MACRLP包中，但并未小到使MACRLP包中的多余空間浪費。因此，視頻包化器24可既支持將音頻包列入優(yōu)先，又支持對視頻包的有效傳輸。解碼器系統(tǒng)14的PHY層模塊34從PHY層包中識別出MAC層包，并將內(nèi)容重新組裝到MACRLP包中。MAC層模塊36接著對MACRLP包的內(nèi)容重新組裝，以便提供視頻和音頻包以供插入在RLP隊列38內(nèi)。RTP/UDP/EP/PPP模塊40剝離伴隨的標(biāo)頭信息，并將視頻包提供到視頻解碼器42，且將音頻包提供到音頻解碼器44。視頻解碼器42解碼視頻數(shù)據(jù)幀，以產(chǎn)生視頻數(shù)據(jù)的流以用于驅(qū)動顯示裝置。音頻解碼器44解碼音頻數(shù)據(jù)，以產(chǎn)生音頻信息以例如經(jīng)由音頻揚聲器呈現(xiàn)給用戶。如上所述，提供視頻包化器24，用其來控制提交給RTP/UDP/IP/PPP轉(zhuǎn)換模塊26的視頻包的大小。視頻包化器24控制視頻包的大小，以便將MACRLP包中的音頻包的傳輸列入優(yōu)先，并防止視頻包占滿RLP隊列28。以此方式，可無實質(zhì)延遲地傳送VT會議的音頻部分，即使視頻部分可能因信道條件遭受延遲。雖然視頻可能會受信道條件損害，但視頻包化器24確保參加VT會議的各方仍然能夠流暢地執(zhí)行口頭會話。由視頻包化器24應(yīng)用的包成形技術(shù)可應(yīng)用一個或一個以上原則，以便確保將音頻包的傳輸列入優(yōu)先。根據(jù)一個原則，舉例來說，應(yīng)當(dāng)在從RLP隊列28的內(nèi)容產(chǎn)生的緊接的下一個可用的MACRLP包中發(fā)送音頻包。音頻編碼器22以第一周期性間隔產(chǎn)生音頻幀。MAC層模塊30以第二周期性間隔產(chǎn)生MACRLP包。應(yīng)當(dāng)將以給定間隔產(chǎn)生的音頻幀放置在由MAC層模塊30產(chǎn)生的下一可用MACRLP包中。在有些實施例中，作為一個選項，RLP隊列28的總輸出隊列大小連同音頻包大小應(yīng)當(dāng)能夠在一個MACRLP包中載運?？上鄬τ赩T序列的每個包應(yīng)用各種原則。雖然有些視頻包的大小可固有地用確保音頻和視頻可在單個MACRLP包中載運的方式確定，但其它視頻包可能較大且需要減小大小，以便確保音頻和視頻可在MACRLP包中載運，特別是在信道條件惡化的時候。通過相對于VT序列的每個包應(yīng)用所述技術(shù)，即使視頻的內(nèi)容龐大或信道帶寬大致有限也可確保令人滿意的語音通信。對包化器24提交給RTP/UDP/IP/PPP轉(zhuǎn)換模塊26以供插入在RLP隊列28中的每個視頻包的大小進行控制。以上原則確保不會因龐大的視頻內(nèi)容消耗了連續(xù)的MACRLP包而導(dǎo)致音頻包延遲。而是，當(dāng)音頻可用時，將來自視頻編碼器20的視頻劃分成具有經(jīng)選擇以準(zhǔn)許每個MACRLP包載運音頻和視頻的大小的包。每個音頻幀可用作提供到RLP隊列28的音頻包?；蛘?，在有些實施例中，音頻包可捆扎以連續(xù)間隔提供的多個音頻幀。在有些實施例中，視頻包化器24可基于在連續(xù)音頻幀之間產(chǎn)生的MAC層包的估計的信道處理量來為每個MAC層包確定視頻包大小?？苫谛诺罈l件來估計處理量，所述信道條件由當(dāng)前無線信道傳輸速率、無線基站活動性和傳輸功率限制中的一者或一者以上來表示。舉例來說，可基于當(dāng)前MAC層數(shù)據(jù)速率、反向活動(RA)位和功率放大器(PA)限制來確定信道條件。此外，在有些實施例中，視頻編碼器20可進一步包含基于視頻緩沖器占用率的自適應(yīng)源速率控制。在此情況下，如果信道條件不支持視頻編碼速率，則考慮到列入優(yōu)先的音頻包化的需要，可由視頻編碼器20降低源視頻編碼速率。圖2是說明因過多視頻內(nèi)容或較差的信道條件導(dǎo)致的音頻延遲的圖。如圖2所示，音頻編碼器22產(chǎn)生音頻幀46A、46B、46C(統(tǒng)稱為幀46)，且視頻編碼器20產(chǎn)生視頻幀48A、48B、48C(統(tǒng)稱為幀48)。一系列連續(xù)的MACRLP包50A-50F(統(tǒng)稱為MACRLP包50)可用來載運從幀46和48導(dǎo)出的音頻包和視頻包，將所述包在RLP隊列28中緩沖。在音頻編碼器22產(chǎn)生了第一音頻幀46A之后，MAC層模塊30產(chǎn)生的下一可用MACRLP包是包50B。如果必要的話，包50C也可用來載運第一音頻幀46A。然而，如果視頻包占滿RLP隊列28的內(nèi)容，則可能長時期內(nèi)不傳遞音頻幀46A。每個MACRLP包50具有從RL信道條件信息導(dǎo)出的相關(guān)聯(lián)數(shù)據(jù)速率。在良好的RL條件下，每個MACRLP包50載運每秒76.8千比特(76.8Kbps)的數(shù)據(jù)速率。然而，在較差的RL信道條件下，數(shù)據(jù)速率發(fā)生波動且通常較低，例如19.2Kbps或38.4Kbps。過多的視頻內(nèi)容、較差的信道條件或兩者均可導(dǎo)致音頻包的傳輸出現(xiàn)顯著延遲。過大的視頻包大小可占滿RL并增加音頻延遲，特別是在RL處理量因數(shù)據(jù)速率較低而減少的時候。視頻包如果不受控制，則可能會消耗過多量的MACRLP包空間，從而導(dǎo)致音頻包的連續(xù)傳輸之間出現(xiàn)延遲。在有些情況下，視頻可能會消耗若千個連續(xù)的MACRLP包50，從而使音頻無法迅速傳輸。每個MACRLP包50提供大約26.67ms的空間以供并入音頻和視頻包信息。在圖2的實例中，大致與音頻幀46A同時產(chǎn)生較大的視頻幀48A。在此情形下，連續(xù)視頻幀48A、48B彼此以133ms的時間間隔產(chǎn)生。然而，音頻幀46B、46C彼此以僅60ms的時間間隔產(chǎn)生。即使在良好的RL條件下，也可能沒有足夠的空間以并入音頻幀46A以及音頻幀46B和46C的音頻包。而是，與視頻幀48A相關(guān)聯(lián)的視頻包可能會消耗大部分MACRLP包50B-50F，從而導(dǎo)致顯著的音頻延遲。在信道條件惡化時(如圖2所示的較差的RL條件的情況下)，這個問題特別具有挑戰(zhàn)性。為了在各種信道條件下緩解音頻延遲，圖l的系統(tǒng)10并入有視頻包化器24，其控制從視頻幀36導(dǎo)出的視頻包的大小。通過相對于VT序列的每個包應(yīng)用視頻限制，視頻包化器24可確保與VT序列相關(guān)聯(lián)的音頻不受損害。圖3是說明固定長度的視頻包成形技術(shù)的圖。固定長度的視頻包成形提供了對音頻延遲問題的部分解決方案。然而，固定長度的視頻包成形并未考慮到信道條件。因此，視頻可仍然在RL處理量減少時占滿信道。此外，固定長度的包成形并未考慮到連續(xù)兩個音頻包之間的處理量，從而導(dǎo)致視頻數(shù)據(jù)包化過度或包化不足。在圖3的實例中，通過每60ms將視頻幀分段成固定大小的300字節(jié)包52A、52B、52C(統(tǒng)稱為視頻包52)來控制視頻包的大小。將音頻幀每60ms分段成固定大小的93字節(jié)包54A、54B、54C(統(tǒng)稱為音頻包54)。緊接在MACRLP包56內(nèi)的音頻數(shù)據(jù)包54之后傳輸視頻包52。在正常操作條件下，固定長度的視頻包化會促進及時地傳輸MACRLP包56內(nèi)的音頻包54。圖3中說明的方法確保在良好的RL條件下無延遲地傳輸音頻包。然而，如果RL條件惡化，則固定的300字節(jié)視頻包52可占滿RL，從而導(dǎo)致連續(xù)音頻包54之間出現(xiàn)延遲。由于視頻包52的長度固定，所以不能對RL條件的變化作出反應(yīng)。在有些例子中，在良好的RL條件下，視頻數(shù)據(jù)可能會包化不足，從而導(dǎo)致對每個MACRLP包56提供的空間利用不足，并導(dǎo)致一般的帶寬低效。在較差的RL條件下，固定大小的視頻包52可能對于RL來說過大而難以處理，從而導(dǎo)致音頻延遲。出于此原因，本發(fā)明提出可調(diào)整長度的視頻包，其大小可響應(yīng)于視頻內(nèi)容或帶寬而自適應(yīng)，以便為整個VT序列提供高質(zhì)量的音頻。圖4是說明信道自適應(yīng)視頻包成形技術(shù)的圖。在圖4的實例中，基于信道條件來調(diào)整視頻包大小，以便可無實質(zhì)延遲地傳輸音頻包。視頻包的大小不是固定的，而是每個視頻包的大小基于音頻包大小和信道條件來動態(tài)調(diào)整。在良好的RL條件下，可增加視頻包大小，但不會大到使視頻包會占滿RL和引入音頻延遲的程度。在較差的RL條件下，減小視頻包的大小以便提供將音頻幀包化并將其放置在下一可用的MACRLP包中的空間。如圖4所示，當(dāng)音頻幀58A、58B、58C(統(tǒng)稱為音頻幀58)可用時，將視頻幀60A、60B、60C(統(tǒng)稱為視頻幀48)的大小確定為可將相應(yīng)音頻幀放置在下一可用MACRLP包62A、62B、62C(統(tǒng)稱為MACRLP包62)中。如圖4中的箭頭所指示，將每個音頻幀58包化并接著放置在RLP隊列28中以供包含在MAC層模塊30所產(chǎn)生的下一可用MACRLP包中，從而消除了音頻包傳輸之間的過多延遲。參考數(shù)字64A、64B、64C(統(tǒng)稱為64)表示放置在相應(yīng)MACRLP包62內(nèi)的音頻包，連同視頻包數(shù)據(jù)。參考數(shù)字66A-66F(統(tǒng)稱為66)表示放置在相應(yīng)MACRLP包62內(nèi)的視頻包，帶有或不帶有音頻包。如圖4所示，每個MACRLP包62可只載運音頻、只載運視頻、或載運音頻與視頻兩者，這取決于RLP隊列28的內(nèi)容。然而，在每個音頻包間隔處，將視頻包62的大小確定為準(zhǔn)許將音頻包64并入在下一可用的MACRLP包62中。值得注意的是，當(dāng)可用的RL速率(例如)因信道條件而降低時，音頻包58的大小相對于MACRLP包62的大小而增加。換句話說，隨著RL速率降低，每個音頻包58消耗MACRLP包62的較大部分，因為視頻包的大小減小。相反，對每個視頻包60的大小進行動態(tài)調(diào)整，使其隨著RL速率的降低而消耗MACRLP包62的較比例。以此方式，將視頻包60的大小確定為準(zhǔn)許將每個音頻包58放置在下一可用的MACRLP包62內(nèi)。結(jié)果是，給予音頻高于視頻的優(yōu)先級，以便減少音頻延遲。圖5是說明實施根據(jù)本發(fā)明一實施例的信道自適應(yīng)視頻包成形技術(shù)的視頻/音頻編碼系統(tǒng)12的方框圖。如圖5所示，編碼系統(tǒng)12包含視頻編碼器20、音頻編碼器22、視頻緩沖器68、音頻緩沖器70、視頻包化器24，包含有效負(fù)載大小估計器72和帶寬有效包化器74、RTP/UDP/IP/PPP轉(zhuǎn)換模塊26、RLP隊列28和反向業(yè)務(wù)信道(RTC)MAC單元76。RTCMAC單元76實施RTCMAC協(xié)議314,以便提供通信裝置在RL上傳輸所遵循的程序。為了方便起見，在圖5中未展示MAC層模塊30和PHY層模塊32。如將描述，有效負(fù)載大小估計器72基于一個或一個以上輸入來控制每個視頻包的大小。所述輸入可能關(guān)于信道條件、RLP隊列特征和音頻包大小及狀態(tài)。帶寬有效包化器74基于有效負(fù)載大小估計器72所規(guī)定的估計的有效負(fù)載大小來產(chǎn)生視頻包，其受到最小視頻包大小的限制。視頻緩沖器68緩沖從視頻編碼器20接收的視頻信息，并將所述視頻信息傳遞到視頻包化器24。音頻緩沖器70緩沖從音頻編碼器22接收到的音頻幀信息，并將所述信息傳遞到RTP/UDP/IP/PPP轉(zhuǎn)換模塊26。將音頻和視頻包彼此獨立地插入在RLP隊列29中。由視頻包化器24產(chǎn)生的視頻包的大小確保MAC層模塊30(圖5中未展示)所產(chǎn)生的下一可用MACRLP包中將有充分的空間供音頻包使用。確切地說，視頻包未占滿RLP隊列28，從而確保RLP隊列中的音頻包可與下一MACRLP包一起發(fā)送。在圖5的實例中，有效負(fù)載大小估計器72接收若干輸入，其中包含音頻包定時器、音頻優(yōu)先級值MACPredNumberPlus、RLP隊列大小和信道信息。音頻包定時器指示音頻緩沖器70中目前是否有音頻信息可用，且如果有的話，則是否有用于傳遞每個音頻幀的時序。舉例來說，如果以每20ms的間隔傳遞音頻幀，則當(dāng)音頻幀可用時音頻包定時器將被設(shè)定成20ms。在有些實施例中，音頻緩沖器70可經(jīng)配置以捆扎連續(xù)的音頻幀以供并入在單個IP包中。在此情況下，音頻包定時器可對應(yīng)于捆扎到音頻包中的幀數(shù)為多個。換句話說，音頻包定時器可具有與捆扎的幀數(shù)成比例或以其它方式相關(guān)的值。舉例來說，如果捆扎了三個音頻幀，則可將音頻定時器設(shè)定成60ms。因此，音頻包定時器也指示由音頻緩沖器70產(chǎn)生以供經(jīng)由RTP/UDP/IP/PPP模塊26插入在RLP隊列28中的音頻包的大小。音頻優(yōu)先級值MACPredNumberPlus定義音頻和視頻的相對優(yōu)先級，且因此會影響與音頻和視頻相關(guān)聯(lián)的延遲。舉例來說，將MACPredNumberPlus確立為使得優(yōu)先級值越小，音頻延遲就越低。相應(yīng)地，隨著MACPredNumberPlus增加，音頻延遲增加且視頻延遲減小。相反，隨著MACPredNumberPlus減小，音頻延遲減小且視頻延遲增加。因此音頻延遲遵循音頻優(yōu)先級值MACPredNumberPlus。有效負(fù)載大小估計器72使用MACPredNumberPlus值來控制每個視頻包的大小，從而導(dǎo)致規(guī)定的音頻包延遲，如同下文將更詳細(xì)描述。由有效負(fù)載大小估計器72接收到的RLP隊列大小表示在RLP隊列28中緩沖的當(dāng)前數(shù)據(jù)的大小。有效負(fù)載大小估計器72使用RLP隊列大小來控制視頻包的大小。如果RLP隊列28相對較滿，則有效負(fù)載大小估計器72可調(diào)小視頻包的大小，以避免占滿RL和導(dǎo)致過多的音頻延遲。如果RLP隊列28較不滿，則有效負(fù)載大小估計器72可增加視頻包的大小，同時仍然提供充分的空間以供音頻包使用。通過RLP隊列大小，有效負(fù)載大小估計器72能夠作為RLP隊列28的充滿度的函數(shù)來動態(tài)地調(diào)整視頻包的大小。隊列充滿度可能指示視頻內(nèi)容過多、信道條件惡化或兩者。使用RLP隊列大小是有效負(fù)載大小估計器72可對視頻內(nèi)容過載或信道條件變化作出反應(yīng)的方式之一。有效負(fù)載大小估計器72也可通過監(jiān)視RTCMAC單元76所提供的信道信息來更加直接地對信道條件的變化作出反應(yīng)。RTCMAC單元76產(chǎn)生關(guān)于信道特征的信息，所述信道特征例如是當(dāng)前MACRL速率、組合RA位和凈空限制。MACRL速率指示RL上可用的當(dāng)前傳輸速率。RA位是反向活動位，其指示相關(guān)無線基站是否繁忙。凈空限制可指示基于當(dāng)前傳輸功率而允許在傳輸時使用的最大速率。RA位指示RL何時因基站不活動而擁塞或不可用。PA限制表示傳輸功率凈空，且指示何時信道條件已惡化。有效負(fù)載大小估計器72基于各種輸入來產(chǎn)生有效負(fù)載大小估計。如果MACPredNumberPlus優(yōu)先級值指示應(yīng)給予音頻高優(yōu)先級，則將有效負(fù)載大小估計選擇為準(zhǔn)許將音頻包包含在下一可用MACRLP包中。帶寬有效包化器74從視頻緩沖器68接收視頻，且基于有效負(fù)載大小估計器72所規(guī)定的有效負(fù)載大小估計和最小視頻包大小來將視頻包化。最小視頻包大小表示將要由包化器24產(chǎn)生的視頻包的最小大小。實際上，最小視頻包大小控制視頻包大小的粒度和帶寬效率。對于較小的最小視頻包大小值，視頻包成形在容納音頻方面更加有效，且進而避免音頻延遲，但帶寬效率較低。對于較大的最小視頻包大小值，視頻包成形在避免音頻延遲方面效果較差，但提供較大的帶寬效率。如圖5中進一步展示，視頻編碼器20可經(jīng)配置以響應(yīng)于來自視頻緩沖器68的視頻緩沖器占用率值。確切地說，在有些實施例中，視頻編碼器20基于視頻緩沖器占用率而提供自適應(yīng)的源速率控制特征。當(dāng)視頻緩沖器68相對較滿時，視頻編碼器20通過減小視頻編碼速率來作出響應(yīng)。當(dāng)視頻緩沖器68較不滿時，視頻編碼器20提高源視頻編碼速率。以此方式，如果信道條件無法支持當(dāng)前的視頻編碼速率，則減小視頻編碼速率。此自適應(yīng)的源速率控制特征是可選的，但在有些應(yīng)用中可能是合意的。為了說明目的將描述額外的實施細(xì)節(jié)。這些細(xì)節(jié)應(yīng)被視為是示范性的，而不限制本發(fā)明中廣泛實施和描述的技術(shù)。對于cdma2000lxEV-DO0版本實施方案，可基于信道條件來估計RL處理量。3GPP2規(guī)范C.S0024-A(也稱為TIAIS-856-A)、第11-143頁、表11.9.6.1規(guī)定了在以Kbps計的傳輸速率方面表達的不同信道條件下對于MACRLP包的以字節(jié)計的最小和最大有效負(fù)載大小。將表11.9.6.1再現(xiàn)如下表<table>tableseeoriginaldocumentpage17</column></row><table>如果將上表中的每個傳輸級別表達為指數(shù)值，那么每個MACRLP包的最大有效負(fù)載大小(包含音頻和視頻兩者)如下最大有效負(fù)載大小=2，+4—3。對于以上表達式，分別向9.6、19.2、38.4、76.8和153.6Kbps的傳輸速率級別指派指數(shù)值1、2、3、4和5。圖6是說明在一定范圍信道條件下的信道自適應(yīng)視頻包成形的圖。如圖6所示，音頻幀58A、58B、58C(統(tǒng)稱為音頻幀58)和視頻幀60A、60B、60C(統(tǒng)稱為視頻幀60)、MACRLP包62A-62F(統(tǒng)稱為MACRLP包62)每一者具有相關(guān)聯(lián)的RL傳輸速率，且能夠載運對應(yīng)于那些傳輸速率的不同最大有效負(fù)載大小。舉例來說，MACRLP包62A、62C和62D具有38.4Kbps的RL傳輸速率，且每一者能夠載運125字節(jié)的最大有效負(fù)載大小。MACRLP包62B具有76.8Kbps的RL傳輸速率，且能夠載運253字節(jié)的最大有效負(fù)載大小。MACRLP包62E和62F具有19.2Kbps的RL傳輸速率，且每一者能夠載運61字節(jié)的最大有效負(fù)載大小。在示范性實施例中，可將有效負(fù)載大小估計器72的操作用偽碼表達為算法。所述算法依賴于以下輸入RA位、PA限制、RL速率、RLPQueueSize、AudioPacketSize和MACPredNumberPlus。圖5中也展示了這些輸入?？蓮膽?yīng)用于有效負(fù)載大小估計器72的音頻包定時器導(dǎo)出AudioPacketSize。如先前所提到，組合的RA位是指示基站活動狀態(tài)的反向活動位，PA限制表示功率要求所強加的傳輸功率凈空限制，且指示何時信道條件己經(jīng)惡化，RL速率是RL的傳輸速率，RLPQueueSize指示RLP隊列28的充滿度，且AudioPacketSize指示當(dāng)前音頻包(即，將要添加到下一可用MACRLP包的音頻包)的大小。MACPredNumberPlus指示相對于視頻包而應(yīng)給予音頻包的相對優(yōu)先級。算法的輸出是VideoPayloadSize。為了初始化算法，將MACPredNumberPlus值設(shè)定如下MACPredNumber=floor((AudioFramesBundled承AudioFramelnterva1)/26.67)+1+MACPredNumberPlus。MACPredNumber表示載運含有單個音頻幀或一組捆扎的音頻幀的MACRLP包所必需的MACRLP包的數(shù)目。AudioFramelnterval表示音頻幀之間的時間間隔。值26.67是為每個MACRLP包分配的時間。因此，如果捆扎三個音頻幀且音頻幀間隔是20ms，且MACPredNumberPlus是零(這指示髙音頻優(yōu)先級)，那么MACPredNumber是3。這意味著針對其將估計視頻有效負(fù)載大小的MACRLP包的預(yù)測數(shù)目是3。對于每個捆扎的音頻包，在發(fā)送捆扎的音頻包之后，有效負(fù)載大小估計器72進行MAC音頻處理量確定。MAC處理量確定可如以下偽碼指示的那樣進行-MACThroughput=0;MACRatelacreasc1-RABit;MACPiedRate=CurRnte;to0=0;j<MACFtodNtmAiar;i++)《在以上MAC處理量確定中，MACThroughput是音頻傳輸所需的處理量值，MACRateIncrease指示是否將基于反向活動來提高MACRL速率，CurRate是當(dāng)前的MACRL速率，MACPredRate是MACRL速率的表達為指數(shù)值的提高量。如上文所指示，MACThroughput是可用于三個預(yù)測的MACRLP包中的每一者的最大有效負(fù)載大小。假定有每個MACRLP包的最大有效負(fù)載大小MACThroughput,視頻有效負(fù)載大小估計器72如下估計最大視頻有效負(fù)載大小(VideoPayloadSize):^deoPayloadSize豕MAX(^iACThrou^put-RLFQQeoeSi2e,0)WdeoPayloadSize-MAXC^dec^Ioad^ze-2攀AucHoPacfcc^ize-45,0),其中RLPQueueSize指示RLP隊列28的充滿度，且AudioPacketSize表示將要添加到下一MACRLP包的音頻包的大小。值45是考慮到RTP/UDP/IP/PPP轉(zhuǎn)換模塊26引入的標(biāo)頭信息的RTP/UDP/IP/PPP額外開銷的以字節(jié)計的固定數(shù)目。此固定額外開銷數(shù)目的18值可能在其它實施方案中是不同的。圖7是更詳細(xì)說明在一定范圍信道條件下的信道自適應(yīng)視頻包成形的圖。有效負(fù)載大小估計器72適應(yīng)于變化的信道條件(部分由RL傳輸速率來表示)，以便調(diào)整經(jīng)呈現(xiàn)以并入在MAC層模塊30從RLP隊列28的內(nèi)容產(chǎn)生的MACRLP包中的視頻包有效負(fù)載的大小。在圖7的實例中，以60ms的間隔產(chǎn)生音頻幀。在此情況下，每60ms作出關(guān)于接下來的三個MACRLP包中的可用有效負(fù)載大小的決策。如圖7所示，在第一決策點78，在3處索引當(dāng)前MACRL速率以表示38.4Kbps，將RA位設(shè)定為零，PA限制等于4且RLP隊列含有X1個字節(jié)。在此情況下，根據(jù)以上公式，將接下來的三個MACRLP包中的每一者的處理量估計為253個字節(jié)。相應(yīng)地，接下來的三個MACRLP包上的總處理量是253+253+253個字節(jié)減去已放置在RLP隊列28中的內(nèi)容XI。因此，第一決策點50處的MACThroughput值是253+253+253—XI個字節(jié)。在第二決策點80處、在60ms之后，再次在3處索引當(dāng)前RL速率且PA限制是4，但將RA位設(shè)定成1而不是0。在此情況下，RA位指示基站繁忙且導(dǎo)致預(yù)測接下來的三個MACRLP包上的處理量減少。確切地說，所估計的處理量MACThroughput是125+125+125—X2個字節(jié)，其中X2表示在第二決策點80之時RLP隊列28的內(nèi)容。在第三決策點82處、在第二決策點78之后60ms，RA位是0，但RL速率已下降到2的指數(shù)值(19.2Kbps)且PA限制已下降到2的指數(shù)值。因此，在接下來的三個MACRLP包上的總處理量MACThroughput減少到61+61+61—X3個字節(jié)，其中X3表示在第三決策點82時RLP隊列28的內(nèi)容。在MACThroughput減小時，可用于視頻包的空間也因為將音頻包列入優(yōu)先而減小。在此情況下，有效負(fù)載大小估計器72減小視頻有效負(fù)載的估計大小以供包化。然而，當(dāng)MACThroughput增加時，有效負(fù)載大小估計器72通過增加估計的視頻有效負(fù)載大小來作出響應(yīng)。以此方式，視頻包化器24不但將音頻包列入優(yōu)先，而且支持帶寬有效的視頻包化。在圖7的實例中，每次針對三個MACRLP包作出決策。然而，在其它實施例中，可應(yīng)用更加積極的決策過程。舉例來說，可每20ms作出對MACThroughput的估計決策。在第一20ms間隔中，可針對三個MACRLP包作出決策。接著，在第二20ms間隔中，可針對一組三個連續(xù)MACRLP包中的剩余兩個MACRLP包作出決策。最終，在接下來的20ms間隔期間針對三個包的組中的最后一個MACRLP包作出決策。在此情況下，在60ms間隔的過程中作出決策，且每20ms進行更新以便獲得可能已經(jīng)在信道條件或RLP隊列充滿度方面發(fā)生的任何變化。在60ms之后，所述過程在接下來的60ms期間針對接下來的三個MACRLP包重復(fù)，且以迭代的方式繼續(xù)。一旦估計了MACThroughput，視頻有效負(fù)載大小估計器72便考慮到MACThroughput值來估計可容納的視頻有效負(fù)載大小，如上文所解釋。接著，帶寬有效包化器74使用估計的視頻有效負(fù)載大小和最小視頻包大小值來產(chǎn)生視頻包以供提交給RTP/UDP/TP/PPP轉(zhuǎn)換模塊26?，F(xiàn)在將更詳細(xì)地描述帶寬有效包化器74的操作。一般來說，如果使用MPEG4視頻編碼，則視頻包化應(yīng)符合網(wǎng)絡(luò)工作組請求注解(RFC)3016(日期為2000年11月)，而如果使用ITUH.263視頻編碼，則視頻包化應(yīng)符合RFC2190(日期為1997年9月)或RFC2429(日期為1998年10月)。RFC3016概括了MPEGE4流的RTP有效負(fù)載格式。RFC2429概括了ITUH.263流的1998版本的RTP有效負(fù)載格式，且RFC2190概括了ITUH.263流的原始版本的RTP格式。RFC3016規(guī)定視頻包(a)必須用視頻對象平面(VOP)標(biāo)頭或視頻包(VP)標(biāo)頭開頭，如果其中任一者存在的話；(b)如果滿足了先前原則，則可含有一個以上VP標(biāo)頭；(c)可只含有視頻數(shù)據(jù)而其中沒有任何VOP和VP標(biāo)頭；以及(d)不能含有跨越兩個視頻幀的數(shù)據(jù)。RFC2190規(guī)定視頻包(a)必須用圖片開始碼(PSC)或區(qū)塊組(GOB)開頭；(b)無須具有GOB標(biāo)頭或完整的GOB;以及(c)GOB的字節(jié)無須對準(zhǔn)。RFC2429規(guī)定視頻包(a)可用字節(jié)對準(zhǔn)的PSC、GOB標(biāo)頭、條標(biāo)頭和條結(jié)尾(EOS)標(biāo)記開頭，且(b)可以是后續(xù)的包，其并不用任何同步碼開頭，但允許在視頻包的中間有同步碼?？紤]到以上要求，視頻編碼器20可經(jīng)配置以將視頻數(shù)據(jù)以VOP禾I]VP(對于MPEG4)或PSC、GOB禾口SSC(對于H.263)插入在視頻緩沖器68中。與MPEG4兼容的編碼器以VOP或VP為單位產(chǎn)生數(shù)據(jù)。H.263編碼器以PSC、GOB或SSC為單位產(chǎn)生數(shù)據(jù)，其中GOB的字節(jié)是對準(zhǔn)的。當(dāng)使用RFC2190時，模式A是默認(rèn)的。在示范性實施例中，可將帶寬有效包化器60的操作表達成利用以下輸入的算法VideoDataInBuffer、EstimatedVideoPayloadSize,minVPSize。VideoDatalnBuffer表示年見頻緩沖器68中的視頻的大小。EstimatedVideoPayloadSize表示由有效負(fù)載大小估計器72確定的估計的視頻有效負(fù)載大小。minVPsize值是將要由包化器60產(chǎn)生的最小視頻包大小，且用以控制粒度和帶寬效率。帶寬有效包化算法的輸出是供提交給RTP/UDP/IP/PPP轉(zhuǎn)換模塊26的一個或一個以上視頻包。在一示范性實施例中，帶寬有效包化器74的操作由以下偽碼來表達ViifedPayloadDstaQ:瓶咖y;for(;;)ifCReniainingMdeoPa^EoadSke<minVFSize/2)elseif(RemainingVideoFayloadSize<mJnVPSize)Remaiiting\^deoPayoadSize:minVFSize;If((Remataing^i(teoPayloadSize=0)||(Vi(feoDataInBuffer=NULL))teeik;If(\^feoDataInBuffw-:>Size>=RemajiringVi(teoPayloadSi坊+minVPSize)if(RFC3016關(guān)KFC2429)VidecJ>ataIiStt￡ra->Siee—EiemainingVide6PayloadSize,VkteoDatafiiBirffr->Size-=RemainingVideoftiyloadSize);VidcoDsto&Biiffer-;^ragffiraated=1;el坊if(KFC21鄰)memcpy(VideoPayk)adData+VideoPayioadSize^VidedDatalnBafifer->Data>V!deoDataInBuffer->Size);MdeoPayloadSize—VideoDataIiiBu￡feT-:>Size;}K&In加oVidodPacketfrom\%tooPaykdDataOwittipayloaddzeofMdedPayloadSize;{nwmcpy(VideoPayloadData+VWeoPayloadSi取Vided)atelnBijff妙Dauu\^deo￡)ataBiBuffer->Size);WdeoPayioadSize+eVMeoDtafoBaflfer->Size;RemainingWdeoPayloadSizie-MAXCRemainiQgMdK^loailSize-VideoBofifeiSize>>Sjze-45,0);汰(No邁oicidatainlmff汰10cocrentTS!-flwnextTS||MakeraieVideoiPackBt￡nnVideoPayloadDataOwiftpa^oadsizeof-VideoPayloadSize;;VideoPayloadSi坊-0;VideoDataInBuff汰-the加xtframe/GOB/必ce.unitinthevideobofTo:,ifany,orNUIJUifnomoredata如以上偽碼所表示，帶寬有效包化器74基于由有效負(fù)載大小估計器72和minVPSize所提供的EstimatedVideoPayloadSize而產(chǎn)生視頻包。RemainingVideoPayloadSize表示在產(chǎn)生視頻包期間的任何點處仍然可用的有效負(fù)載的量。起初，RemainingVideoPayloadSize等于視頻有效負(fù)載大小估計器74所提供的整個EstimatedVideoPayloadSize。VideoPayloadSize表示包中的視頻有效負(fù)載的實際大小，且起初設(shè)定成零。VideoPayloadData[]識別視頻緩沖器68中的視頻數(shù)據(jù)段的陣列。包化器74首先確定RemainingVideoPayloadSize是否小于最小VP大小/2。如果是的話，將RemainingVideoPayloadSize設(shè)定成零?；蛘撸绻鸕emainingVideoPayloadSize小于minVPSize，那么將RemainingVideoPayloadSize的值設(shè)定成等于minVPSize。接著，如果RemainingVideoPayloadSize等于零或VideoDatalnBuffer為空，則所述過程重設(shè)，因為下一可用MACRLP包中沒有剩余空間，或視頻緩沖器68中沒有剩余視頻。如果VideoInBuffer的大小大于或等于RemainingVideoPayloadSize加上minVPSize，則包化器74接下來確定剩余的VideoPayloadSize是否大于或等于minVPSize/2。如果是的話，包化器74便確定RFC3016或RFC2429是否可適用。如果RFC3016或RFC2429均不適用，那么包化器74確定RFC2190是否可適用，即ITUH.263的初始版本的RTP有效負(fù)載格式是否適用。如果RFC3016或RFC2429適用，那么包化器74將視頻從視頻緩沖器68(由開始地址VideoPayloadData禾口偏移VideoPayloadSize來確定)復(fù)制(memcpy)至U由VideoDatalnBuffer識別的輸入緩沖器。起初，將VideoPayloadSize設(shè)定成零。從視頻緩沖器68復(fù)制的視頻的量等于RemainingVideoPayloadSize，其起初被設(shè)定成估計的VideoPayloadSize。包化器74接著將VideoPayloadSize調(diào)整成等于RemainingVideoPayloadSize。接下來，包化器74將視頻數(shù)據(jù)從輸入緩沖器復(fù)制到偏移剩余VideoPayloadSize所識別的地址，復(fù)制的量由RemainingVideoPayloadSize來確定。接著將VideoDatalnBuffer的內(nèi)容分段以供包化。如果RFC2190適用，那么包化器74將視頻從視頻緩沖器68(由開始地址VideoPayloadData和偏移VideoPayloadSize來確定)復(fù)串U(memcpy)到由VideoDatalnBuffer識別的輸入緩沖器。同樣，起初將VideoPayloadSize設(shè)定成零。從視頻緩沖器68復(fù)制的視頻的量等于VideoDatalnBuffer的大小。接著，使VideoPayloadSize等于VideoDatalnBuffer的大小。一旦退出RFC3016/RFC2429操作或RFC21卯操作，包化器74接下來便從VideoPayloadData中產(chǎn)生VideoPacket，所述VideoPacket的有效負(fù)載大小等于VideoPayloadSize的當(dāng)前值。接著，將RemainingVideoPayloadSize的值設(shè)定成零。在此點處，已由包化器74產(chǎn)生視頻包以供提交給RTP/UDP/IP/PPP轉(zhuǎn)換模塊26。如果RemainingVideoPayloadSize不小于minVPSize，貝ijRemainingVideoPayloadSize不等于零,VideoDatalnBuffer不為空，且VideoDatalnBuffer的大小不大于或等于RemainingVideoPayloadSize+minVPSize，那么包化器74使用地址VideoPayloadData加上VideoPayloadSize的偏移將數(shù)據(jù)從緩沖器68復(fù)制到VideoDatalnBuffer。在此情況下，所復(fù)制的數(shù)據(jù)的量等于VideoPayloadSize。接著，包化器74將VideoPayloadSize設(shè)定成等于VideoDatalnBuffer的大小。包化器74接下來將RemainingVideoPayloadSize設(shè)定成等于RemainingVideoPayloadSize的最大值減去視頻緩沖器大小和零。VideoBufferSize表示視頻緩沖器68的大小。如果在視頻緩沖器68中不再有數(shù)據(jù)，或者當(dāng)前時戳(TS)不等于下一TS，或RemainingVideoPayloadSize等于零，或VideoDatalnBuffer經(jīng)過分段，則包化器74從VideoPayloadData中產(chǎn)生一個有效負(fù)載大小為VideoPayloadSize的VideoPacket,并將VideoPayloadSize設(shè)定成零。否則，包化器74設(shè)定VideoDatalnBuffer，23以獲得視頻緩沖器68中的下一幀、GOB或條單位(如果存在的話)，或者如果視頻緩沖器中不再有數(shù)據(jù)的話，則將其設(shè)定為空。圖8是說明根據(jù)本發(fā)明一實施例的信道自適應(yīng)視頻包成形技術(shù)的流程圖。如圖8所示，音頻緩沖器70產(chǎn)生音頻包(84)。RTP/UDP/IP/PPP模塊26將音頻包添加到RLP隊列28(86)。有效負(fù)載大小估計器72確定RLP隊列大小(88)，音頻-視頻優(yōu)先級值(90)和信道條件(92)。基于那些確定，有效負(fù)載大小估計器72估計將要產(chǎn)生的下一視頻包的有效負(fù)載大小(94)。帶寬有效包化器74產(chǎn)生視頻包(96)，并基于估計的有效負(fù)載大小和最小視頻包大小來確定視頻包的大小(98)。帶寬有效包化器74將視頻包添加到RLP隊列28(100)。MAC層模塊30從RLP隊列28的內(nèi)容產(chǎn)生MACRLP包(102)。本發(fā)明中所描述的信道自適應(yīng)視頻包成形支持較高的音頻數(shù)據(jù)優(yōu)先級。如果沒有信道自適應(yīng)視頻包成形，則音頻通常會延遲較大的視頻包。根據(jù)本發(fā)明所描述的包成形技術(shù)的視頻幀分段在下一可用MACRLP包中為將要傳輸?shù)囊纛l包提供空間。雖然將視頻包大小確定為固定長度在許多例子中可減少音頻延遲，但此方法并不適于信道條件，且可在帶寬消耗方面較低效。信道自適應(yīng)視頻包成形提供將音頻和視頻數(shù)據(jù)列入優(yōu)先的靈活性?？梢?guī)定音頻-視頻優(yōu)先級值(MACPREDNUMBERPLUS)與最小視頻包大小(minVPSize)的不同值以實現(xiàn)音頻與視頻優(yōu)先級之間的所需折衷。此外，信道自適應(yīng)包成形可提供幾乎恒定的音頻延遲性能，從而即使在較差的信道條件下也能產(chǎn)生流暢的音頻會話。在有些情況下，音頻延遲性能可與沒有視頻的性能相當(dāng)。視頻處理量可適于音頻處理量和信道條件。確切地說，可根據(jù)可用帶寬自適應(yīng)地改變視頻處理量，且當(dāng)音頻處理量減少時可增加視頻處理量。有利的是，信道自適應(yīng)視頻包成形可易于低復(fù)雜度地實施，從而在有些實施例中只需要若干行代碼，正如本發(fā)明中所闡述。此外，在大多實施例中，不需要修改解碼系統(tǒng)14。本發(fā)明所描述的技術(shù)可在通用微處理器、數(shù)字信號處理器(DSP)、專用集成電路(ASIC)、場可編程門陣列(FPGA)或其它等效的邏輯裝置內(nèi)實施。舉例來說，視頻編碼器系統(tǒng)12及其組件和模塊可實施為在數(shù)字信號處理器(DSP)或其它處理裝置上運行的編碼過程或編碼/解碼(CODEC)過程的部分。相應(yīng)地，描述成模塊的組件可形成此過程的可編程特征或形成單獨過程。視頻編碼器系統(tǒng)12可具有用于存儲指令和數(shù)據(jù)的專用存儲器，以及專用的硬件、軟件、固件或其組合。如果是用軟件實施的，則所述技術(shù)可實施成計算機可讀媒體上的指令，所述媒體例如是隨機存取存儲器(RAM)、只讀存儲器(ROM)、非易失性隨機存取存儲器(NVRAM)、電可擦除可編程只讀存儲器(EEPROM)、快閃存儲器或類似裝置。所述指令致使一個或一個以上處理器執(zhí)行本發(fā)明描述的功能性的特定方面。已經(jīng)描述了各種實施例。這些和其它實施例處于所附權(quán)利要求書的范圍內(nèi)。權(quán)利要求1.一種方法，其包括產(chǎn)生音頻包；估計無線信道的處理量；以及產(chǎn)生視頻包，其具有基于所述估計的處理量而確定的視頻包大小。2.根據(jù)權(quán)利要求l所述的方法，其中基于所述估計的處理量和所述音頻包的大小而確定所述視頻包大小。3.根據(jù)權(quán)利要求1所述的方法，其進一步包括將所述音頻包和所述視頻包放置在輸出隊列中，其中基于所述估計的處理量、所述音頻包的大小和在將所述視頻包放置在所述輸出隊列中之前所述輸出隊列中經(jīng)緩沖數(shù)據(jù)的大小來確定所述視頻包大小。4.根據(jù)權(quán)利要求1所述的方法，其進一步包括將所述音頻包和所述視頻包放置在輸出隊列中，以及基于所述輸出隊列的內(nèi)容中的至少一些內(nèi)容來產(chǎn)生媒體存取控制(MAC)層包。5.根據(jù)權(quán)利要求l所述的方法，其進一步包括以第一周期性間隔接收音頻幀，以及以第二周期性間隔產(chǎn)生媒體存取控制(MAC)層包，其中產(chǎn)生音頻包包含產(chǎn)生捆扎所述音頻幀中的至少兩者的音頻包，并將所述音頻包添加到下一可用MAC層包。6.根據(jù)權(quán)利要求1所述的方法，其進一步包括將所述音頻包和所述視頻包放置在輸出隊列中，以及基于所述輸出隊列的內(nèi)容中的至少一些內(nèi)容來產(chǎn)生媒體存取控制(MAC)層包，其中所述視頻包大小是基于所述音頻包的所述大小、所述估計的處理量和在將所述視頻包放置在所述輸出隊列中之前所述輸出隊列中經(jīng)緩沖數(shù)據(jù)的大小。7.根據(jù)權(quán)利要求l所述的方法，其進一步包括基于當(dāng)前無線信道傳輸速率、無線基站活動性和傳輸功率限制中的一者或一者以上來估計所述處理量。8.根據(jù)權(quán)利要求1所述的方法，其中所述視頻包大小充分地小，以避免在經(jīng)由所述無線信道傳輸所述音頻包的過程中發(fā)生實質(zhì)性延遲。9.根據(jù)權(quán)利要求l所述的方法，其進一步包括接收多個視頻幀，以及基于未包化視頻幀數(shù)據(jù)的量來調(diào)整視頻編碼速率。10.根據(jù)權(quán)利要求l所述的方法，其中至少部分基于向所述音頻包指派優(yōu)于所述視頻包的優(yōu)先級的優(yōu)先級值來確定所述視頻包大小，且其中針對給定的估計的處理量的所述視頻包大小隨著所述優(yōu)先級值的減小而增加。11.根據(jù)權(quán)利要求1所述的方法，其中所述視頻包大小大于或等于最小視頻包大小。12.根據(jù)權(quán)利要求1所述的方法，其進一步包括基于所述音頻包和所述視頻包來產(chǎn)生物理層包，并將所述物理層包傳輸?shù)竭h程裝置以支持移動無線視頻電話會議。13.根據(jù)權(quán)利要求12所述的方法，其中所述物理層包大致符合cdma2000lxEV-DO版本0標(biāo)準(zhǔn)。14.一種系統(tǒng)，其包括音頻編碼器，其產(chǎn)生音頻數(shù)據(jù)；音頻緩沖器，其接收所述音頻數(shù)據(jù)并輸出音頻包；視頻編碼器，其產(chǎn)生視頻數(shù)據(jù)；包化器，其估計無線信道的處理量，并從所述視頻數(shù)據(jù)中產(chǎn)生視頻包，所述視頻包具有基于所述估計的處理量而確定的視頻包大小。15.根據(jù)權(quán)利要求14所述的系統(tǒng)，其中所述視頻包大小是基于所述估計的處理量和所述音頻包的大小而確定。16.根據(jù)權(quán)利要求14所述的系統(tǒng)，其進一步包括輸出隊列，所述輸出隊列接收所述音頻包和所述視頻包，其中所述視頻包大小是基于所述估計的處理量、所述音頻包的大小和在將所述視頻包放置在所述輸出隊列中之前所述輸出隊列中經(jīng)緩沖數(shù)據(jù)的大小而確定。17.根據(jù)權(quán)利要求14所述的系統(tǒng)，其進一步包括輸出隊列，其接收所述音頻包和所述視頻包；以及媒體存取控制(MAC)層模塊，其基于所述輸出隊列的內(nèi)容中的至少一些內(nèi)容來產(chǎn)生MAC層包。18.根據(jù)權(quán)利要求14所述的系統(tǒng)，其中所述音頻緩沖器以第一周期性間隔接收音頻幀，并針對所述音頻幀中的每一者產(chǎn)生音頻包，且所述MAC層模塊以第二周期性間隔產(chǎn)生媒體存取控制(MAC)層包，將所述音頻包添加到下一可用MAC層包。19.根據(jù)權(quán)利要求14所述的系統(tǒng)，其中所述音頻緩沖器以第一周期性間隔接收音頻幀，并捆扎所述音頻幀中的至少兩者以形成所述音頻包，且所述MAC層模塊以第二周期性間隔產(chǎn)生媒體存取控制(MAC)層包，并將所述音頻包添加到下一可用的MAC層包。20.根據(jù)權(quán)利要求14所述的系統(tǒng)，其中所述包化器基于當(dāng)前無線信道傳輸速率、無線基站活動性和傳輸功率限制中的一者或一者以上來估計所述處理量。21.根據(jù)權(quán)利要求14所述的系統(tǒng)，其中所述視頻包大小充分地小，以避免在經(jīng)由所述無線信道傳輸所述音頻包的過程中發(fā)生實質(zhì)性延遲。22.根據(jù)權(quán)利要求14所述的系統(tǒng)，其中所述視頻編碼器產(chǎn)生多個視頻幀，并基于未包化視頻幀數(shù)據(jù)的量來調(diào)整視頻編碼速率。23.根據(jù)權(quán)利要求14所述的系統(tǒng)，其中所述包化器至少部分基于向所述音頻包指派優(yōu)于所述視頻包的優(yōu)先級的優(yōu)先級值來確定所述視頻包大小，其中針對給定的估計的處理量的所述視頻包大小隨著所述優(yōu)先級值的減小而增加。24.根據(jù)權(quán)利要求14所述的系統(tǒng)，其中所述視頻包大小大于或等于最小視頻包大小。25.根據(jù)權(quán)利要求l所述的系統(tǒng)，其進一步包括物理層模塊，所述物理層模塊基于所述音頻包和所述視頻包而產(chǎn)生物理層包，并將所述物理層包傳輸?shù)竭h程裝置以支持移動無線視頻電話會議。26.根據(jù)權(quán)利要求25所述的系統(tǒng)，其中所述物理層包大致符合cdma2000lxEV-DO版本0標(biāo)準(zhǔn)。27.—種計算機可讀媒體，其包括致使處理器執(zhí)行以下操作的指令-產(chǎn)生音頻包；估計無線信道的處理量；以及產(chǎn)生視頻包，其具有基于所述估計的處理量而確定的視頻包大小。28.根據(jù)權(quán)利要求27所述的計算機可讀媒體，其進一步包括致使處理器基于所述估計的處理量和所述音頻包的大小來確定所述視頻包大小的指令。29.根據(jù)權(quán)利要求27所述的計算機可讀媒體，其進一步包括致使處理器將所述音頻包和所述視頻包放置在輸出隊列中的指令，其中所述視頻包大小是基于所述估計的處理量、所述音頻包的大小和在將所述視頻包放置在所述輸出隊列中之前所述輸出隊列中經(jīng)緩沖數(shù)據(jù)的大小而確定。30.根據(jù)權(quán)利要求27所述的計算機可讀媒體，其進一步包括致使處理器將所述音頻包和所述視頻包放置在輸出隊列中并基于所述輸出隊列的內(nèi)容中的至少一些內(nèi)容來產(chǎn)生媒體存取控制(MAC)層包的指令。31.根據(jù)權(quán)利要求27所述的計算機可讀媒體，其進一步包括致使處理器以第一周期性間隔接收接收的音頻幀并以第二周期性間隔產(chǎn)生媒體存取控制(MAC)層包的指令，其中產(chǎn)生音頻包包含針對所述音頻幀中的每一者產(chǎn)生音頻包，并將所述音頻包添加到下一可用MAC層包。32.根據(jù)權(quán)利要求27所述的計算機可讀媒體，其進一步包括致使處理器以第一周期性間隔接收音頻幀并以第二周期性間隔產(chǎn)生媒體存取控制(MAC)層包的指令，其中產(chǎn)生音頻包包含產(chǎn)生捆扎所述音頻幀中的至少兩者的音頻包，并將所述音頻包添加到下一可用MAC層包。33.根據(jù)權(quán)利要求27所述的計算機可讀媒體，其進一步包括致使所述處理器基于當(dāng)前無線信道傳輸速率、無線基站活動性和傳輸功率限制中的一者或一者以上來估計所述處理量的指令。34.根據(jù)權(quán)利要求27所述的計算機可讀媒體，其中所述視頻包大小充分地小，以避免在經(jīng)由所述無線信道傳輸所述音頻包的過程中發(fā)生實質(zhì)性延遲。35.根據(jù)權(quán)利要求27所述的計算機可讀媒體，其進一步包括致使所述處理器接收多個視頻幀并基于未包化視頻幀數(shù)據(jù)的量來調(diào)整視頻編碼速率的指令。36.根據(jù)權(quán)利要求27所述的計算機可讀媒體，其中所述視頻包大小至少部分是基于向所述音頻包指派優(yōu)于所述視頻包的優(yōu)先級的優(yōu)先級值而確定，且其中針對給定的估計的處理量的所述視頻包大小隨著所述優(yōu)先級值的減小而增加。37.根據(jù)權(quán)利要求27所述的計算機可讀媒體，其中所述視頻包大小大于或等于最小視頻包大小。38.根據(jù)權(quán)利要求27所述的計算機可讀媒體，其進一步包括致使處理器基于所述音頻包和所述視頻包來產(chǎn)生物理層包并將所述物理層包傳輸?shù)竭h程裝置以支持移動無線視頻電話會議的指令。39.根據(jù)權(quán)利要求38所述的計算機可讀媒體，其中所述物理層包大致符合cdma2000lxEV-DO版本O標(biāo)準(zhǔn)。40.—種系統(tǒng)，其包括用于產(chǎn)生音頻包的裝置；用于估計無線信道的處理量的裝置；以及用于產(chǎn)生視頻包的裝置，所述視頻包具有基于所述估計的處理量而確定的視頻包大小。41.根據(jù)權(quán)利要求40所述的系統(tǒng)，其中所述視頻包的大小是基于所述估計的處理量和所述音頻包的大小而確定。42.根據(jù)權(quán)利要求40所述的系統(tǒng)，其進一步包括將所述音頻包和所述視頻包放置在輸出隊列中的裝置，其中所述視頻包大小是基于所述估計的處理量、所述音頻包的大小和在將所述視頻包放置在所述輸出隊列中之前所述輸出隊列中經(jīng)緩沖數(shù)據(jù)的大小而確定。43.根據(jù)權(quán)利要求40所述的系統(tǒng)，其進一步包括將所述音頻包和所述視頻包放置在輸出隊列中并基于所述輸出隊列的內(nèi)容中的至少一些內(nèi)容來產(chǎn)生媒體存取控制(MAC)層包。全文摘要本發(fā)明涉及用于視頻電話(VT)的視頻包成形技術(shù)。所述技術(shù)可用來將音頻包列入優(yōu)先，以便減少音頻延遲。信道條件、過多的視頻內(nèi)容或兩者均可導(dǎo)致音頻傳輸中的延遲。當(dāng)減少反向鏈路(RL)處理量時，視頻包大小可占滿所述RL并增加音頻延遲。所述視頻包可消耗過多數(shù)目的MACRLP包，從而導(dǎo)致連續(xù)音頻包之間的延遲。對每個視頻包的大小進行調(diào)整，以便將音頻包列入優(yōu)先以無實質(zhì)延遲地進行傳輸。可基于信道條件來控制所述視頻包大小。可無實質(zhì)延遲地傳送音頻，即使視頻可能因信道條件而遭受延遲。雖然視頻可能會受信道條件損害，但視頻包成形確保VT方能夠流暢地進行口頭會話。文檔編號H04L12/56GK101313536SQ200680043711公開日2008年11月26日申請日期2006年9月29日優(yōu)先權(quán)日2005年9月29日發(fā)明者李彥輯申請人:高通股份有限公司