視頻電話的視頻包成形的製作方法

2023-09-23 19:13:30 6

專利名稱：：視頻電話的視頻包成形的製作方法一見頻電話的^見頻包成形枯犬凝i^-T，'z、-—、本發明涉及視頻電話(VT),且更確切地說，涉及在VT系統中組裝音頻和視頻包以供傳輸的技術。
背景技術：
：視頻電話(VT)涉及對載運音頻和視頻數據的包進行實時傳送。每個VT裝置包含視頻編碼器，其從例如攝像機或視頻檔案等視頻捕獲裝置獲得視頻，並產生視頻包。類似地，每個VT裝置中的音頻編碼器從例如麥克風或語音合成器等音頻捕獲裝置獲得音頻，並產生音頻包。將所述視頻包和音頻包放置在無線電鏈路協議(RLP)隊列中。媒體接入控制(MAC)層模塊從RLP隊列的內容產生媒體接入控制(MAC)層包。將MAC層包轉換成物理(PHY)層包，以供經由通信信道傳輸到另一VT裝置。在移動VT應用中，VT裝置經由從基站到無線終端的無線前向鏈路(FL)(或"下行鏈路")接收物理層包。VT裝置經由從無線終端到基站的無線反向鏈路(RL)(或"上行鏈路")傳輸PHY層包。每個VT裝置包含PHY和MAC層，以便轉換接收到的PHY和MAC層包，並將所述包有效負載重新組裝成音頻包和視頻包。VT裝置內的視頻解碼器對視頻數據進行解碼，以便經由顯示裝置呈現給用戶。VT裝置內的音頻解碼器對音頻數據進行解碼，以便經由音頻揚聲器呈現。無線環境下的移動VT可具有挑戰性。無線信道上的數據速率受到限制且隨著時間而變動。舉例來說，在CDMA2000lxEV-DO0版網絡中，數據速率可能會因無線覆蓋區域內的條件或多個VT用戶間的業務擁塞而變動。此外，當數據速率下降到零時，例如當沒有數據要發送時，恢復成合理數據速率可能需要時間。結果，移動VT可易於遭受不合意的視頻和音頻延遲，這會削弱實時地執行流暢的視頻會議的能力。
發明內容一般來說，本發明針對VT應用的視頻包成形技術。所述視頻包成形技術可用來將音頻包列入優先，以便減少音頻延遲。信道條件、過多的視頻內容或兩者可導致音頻包傳輸的顯著延遲。當反向鏈路(RL)處理量減少時，視頻包大小可佔滿RL且增加音頻延遲。確切地說，視頻包可填充RLP隊列並消耗過多數目的MAC層包，從而導致載運音頻包的MAC層包的連續傳輸之間出現延遲。根據所揭示的技術，對每個視頻包的大小進行調整，以便將音頻包列入優先以用於無實質延遲地傳輸。確切地說，對提交給RLP隊列的每個視頻包的大小進行控制，以確保及時地傳輸音頻。舉例來說，可將視頻包的大小確定為使得每個音頻包可與從RLP隊列取出的下一可用MAC層包一起發送。以此方式，可在應用層處為音頻包提供服務質量(QoS)。可基於例如無線信道等信道的估計處理量來控制視頻包大小。可基於信道條件來估計處理量，所述信道條件由當前的無線信道傳輸速率、無線基站活動性或傳輸功率限制來表示。可無實質延遲地傳送VT會議的音頻部分，即使視頻部分可能會因信道條件遭受延遲。雖然視頻可能會受信道條件損害，但視頻包成形確保VT會議各方仍然能夠流暢地執行口頭會話。此外，在有些實施例中，視頻包成形技術可進一步包含基於視頻緩衝佔用率的自適應源速率控制。在此情況下，如果信道條件不支持視頻編碼速率，則考慮到列入優先的音頻包化的需要，可降低源視頻編碼速率。舉例來說，可基於駐存在視頻緩衝器中的未包化視頻幀數據的量來調整視頻編碼速率。在一個實施例中，本發明提供一種方法，其包括產生音頻包、估計無線信道的處理量，以及產生具有基於估計的處理量而確定的視頻包大小的視頻包。在另一實施例中，本發明提供一種系統，其包括音頻編碼器，其產生音頻數據；音頻緩衝器，其接收音頻數據並輸出音頻包；視頻編碼器，其產生視頻數據；包化器，其估計無線信道的處理量，從視頻數據產生具有基於估計的處理量而確定的視頻包大小的視頻包。在額外的實施例中，本發明提供一種計算機可讀媒體，其包括致使處理器執行以下操作的指令產生音頻包、估計無線信道的處理量，並產生具有基於估計的處理量而確定的視頻包大小的視頻包。在有些實施例中，基於估計的處理量、音頻包的大小和在將視頻包放置在輸出隊列中之前含有所述音頻包的輸出隊列中的經緩衝數據的大小，來確定視頻包大小。可將視頻包的大小確定為使得可將音頻包放置在從輸出隊列的內容產生的下一可用MAC層包中。在附圖和以下描述中闡述一個或一個以上實施例的細節。從描述和圖式中且從權利要求書中將容易明白其它特徵、目的和優點。圖1是說明用於VT應用的視頻/音頻編碼和解碼系統的方框圖。圖2是說明由於過多視頻內容、較差的信道條件或兩者而導致的音頻延遲的方框圖。圖3是說明用於固定長度的視頻包成形的技術的方框圖。圖4是說明用於信道自適應視頻包成形的技術的方框圖。圖5是說明實施信道自適應視頻包成形技術的視頻/音頻編碼系統的方框圖。圖6是說明在一定範圍信道條件下的信道自適應視頻包成形的方框圖。圖7是更詳細地說明在一定範圍信道條件下的信道自適應視頻包成形的方框圖。圖8是說明信道自適應視頻包成形的技術的流程圖。具體實施例方式圖1是說明視頻編碼和解碼系統10的方框圖。如圖1所示，系統IO包含編碼器系統12和解碼器系統14，其由傳輸信道16連接。編碼器系統12與第一視頻通信裝置相關聯，且包含視頻編碼器20、音頻編碼器22、視頻包化器24、實時傳輸協議(PTR)/用戶數據報協議(UDP)/網際網路協議(IP)/點對點協議(PPP)轉換模塊26、無線電鏈路協議(RLP)隊列28、MAC層模塊30和PHY層模塊32。解碼器系統14與另一視頻通信裝置相關聯，且包含PHY層模塊34、MAC層模塊36、RLP隊列38、RTP/UDP/IP/PPP轉換模塊40、視頻解碼器42和音頻解碼器44。如將描述，包化器24基於信道條件執行視頻包成形，以便將音頻包傳輸列入優先並進而避免過多的音頻延遲。系統IO可經由傳輸信道16(例如)為視頻電話提供雙向視頻和音頻傳輸。相應地，可在信道16的相反端提供一般相反的編碼、解碼和轉換模塊。在有些實施例中，編碼器系統12和解碼器系統14可包含在視頻通信裝置內，例如裝備用於視頻串流傳輸、視頻電話或兩者的無線移動終端。移動終端可根據例如RTP、LDP、IP或PPP等包交換標準支持VT。RTP/UDP/IP/PPP轉換模塊向從音頻編碼器22和視頻包化器24接收的音頻和視頻數據添加適當的RTP/UDP/IP/PPP標頭數據，且將所述數據放置在RLP隊列28中。RTP在UDP上運行，而UDP在IP上運行，且IP在PPP上運行。MAC層模塊30從RLP隊列28的內容產生MACRLP包。PHY層模塊30將MACRLP包轉換成PHY層包以以用於在信道16上傳輸。解碼系統M的PHY層模塊34和MAC層模塊36以相反方式操作。PHY層模塊34將從信道16接收的PHY層包轉換成MACRLP包。MAC層模塊36將MACRLP包放置到RLP隊列38中。RTP/UDP/IP/PPP轉換模塊40從RLP隊列38中的數據中剝離標頭信9息，並重新組裝視頻和音頻數據以供分別傳遞到視頻解碼器42和音頻解碼器44。系統10可經設計以支持一種或一種以上無線通信技術，例如碼分多址(CDMA)、頻分多址(FDMA)、時分多址(TDMA)或正交頻分多路復用(OFDM)或另一合適的無線技術。以上無線通信技術可根據多種無線電接入技術中的任一者來傳遞。舉例來說，可根據cdma2000或寬帶CDMA(WCDMA)標準來傳遞CDMA。可根據全球移動通信系統(GSM)標準來傳遞TDMA。通用移動電信系統(UMTS)標準準許GSM或WCDMA操作。通常對於VT應用來說，系統10將經設計以支持例如cdma2000lxEV-DO0版本等高數據速率(HDR)技術。視頻編碼器20根據例如MPEG-4等視頻壓縮方法來產生編碼的視頻數據。可使用其它視頻壓縮方法，例如國際電信聯盟(ITU)H.263、ITUH.264或MPEG-2方法。音頻編碼器22編碼將伴隨視頻數據的音頻數據。可從例如攝像機或視頻檔案等視頻捕獲裝置獲得視頻。可根據例如自適應多速率窄帶(AMR-NB)或其它技術等音頻壓縮方法來編碼音頻數據。可從例如麥克風或語音合成器裝置等音頻捕獲裝置獲得音頻。對於VT應用，視頻將準許一方觀看VT會議，且音頻將準許聽到所述方的講話聲音。在操作中，RTP/UDP/IP/PPP轉換模塊26從視頻編碼器20和音頻編碼器22獲得視頻和音頻數據包。RTP/UDP/IP/PPP轉換模塊26向音頻包添加適當的標頭信息，並將所得數據插入在RLP隊列28內。同樣，RTP/UDP/IP/PPP轉換模塊26向視頻包添加適當的標頭信息，並將所得數據插入在RLP隊列28內。MAC層模塊30從RLP隊列28中檢索數據，並形成MAC層包。每個MAC層包載運RTP/UDP/IP/PPP標頭信息和RLP隊列28內含有的音頻或視頻包數據。獨立於視頻包將音頻包插入在RLP隊列28中。然而，包化器24控制添加到RLP隊列28的視頻包的大小，使得每個音頻包均可由下一可用MAC層包載運。在有些情況下，從RLP隊列28的內容產生的MAC層包將只載運標頭信息和視頻包數據。在其它情況下，MAC層包將只載運標頭信息和音頻包數據。在許多情況下，MAC層包將載運標頭信息、音頻包數據和視頻包數據，這取決於RLP隊列28的內容。MAC層包可根據無線電鏈路協議(RLP)來配置，且可稱為MACRLP包。PHY層模塊32可包含將MACRLP音頻-視頻包轉換成PHY層包以供經由信道16傳輸。信道16將PHY層包載運到解碼器系統14。信道16可為編碼器系統12與解碼器系統14之間的任何物理連接。舉例來說，信道16可以是有線連接，例如局域或廣域有線網絡。或者，如本文中描述，信道16可以是無線連接，例如蜂窩式、衛星或光學連接。信道條件可能是有線和無線信道的關注因素，而且對於經由無線信道16執行的移動VT應用尤其成問題。根據本發明，視頻包化器24控制提供到RTP/UDP/IP/PPP轉換模塊26的每個視頻包的大小，以便將音頻的傳輸列入優先。確切地說，將視頻包的大小確定為使得每個包均可由下一可用的MAC層包容納。對視頻包的大小進行控制防止了因信道條件、較大的視頻包或兩者導致的音頻延遲。當有音頻包可用時，將其放置在RLP隊列中以包含在MAC層模塊30所產生的下一可用MACRLP包中。音頻包可與大小已經過確定而準許將音頻包放置在MACRLP包內的空間的視頻包組合。視頻包化器24經配置以在其能夠基於信道條件來調整視頻包大小的意義上成為信道自適應的。以此方式，編碼器系統12可將音頻包的傳輸列入優先，以避免在信道條件較差時發生音頻延遲。同時，視頻包化器24可確保將音頻列入優先不會導致視頻包被包化不足。換句話說，視頻包化器24將視頻包的大小確定得足夠小而準許將一個或一個以上音頻包包含在下一可用MACRLP包中，但並未小到使MACRLP包中的多餘空間浪費。因此，視頻包化器24可既支持將音頻包列入優先，又支持對視頻包的有效傳輸。解碼器系統14的PHY層模塊34從PHY層包中識別出MAC層包，並將內容重新組裝到MACRLP包中。MAC層模塊36接著對MACRLP包的內容重新組裝，以便提供視頻和音頻包以供插入在RLP隊列38內。RTP/UDP/EP/PPP模塊40剝離伴隨的標頭信息，並將視頻包提供到視頻解碼器42，且將音頻包提供到音頻解碼器44。視頻解碼器42解碼視頻數據幀，以產生視頻數據的流以用於驅動顯示裝置。音頻解碼器44解碼音頻數據，以產生音頻信息以例如經由音頻揚聲器呈現給用戶。如上所述，提供視頻包化器24，用其來控制提交給RTP/UDP/IP/PPP轉換模塊26的視頻包的大小。視頻包化器24控制視頻包的大小，以便將MACRLP包中的音頻包的傳輸列入優先，並防止視頻包佔滿RLP隊列28。以此方式，可無實質延遲地傳送VT會議的音頻部分，即使視頻部分可能因信道條件遭受延遲。雖然視頻可能會受信道條件損害，但視頻包化器24確保參加VT會議的各方仍然能夠流暢地執行口頭會話。由視頻包化器24應用的包成形技術可應用一個或一個以上原則，以便確保將音頻包的傳輸列入優先。根據一個原則，舉例來說，應當在從RLP隊列28的內容產生的緊接的下一個可用的MACRLP包中發送音頻包。音頻編碼器22以第一周期性間隔產生音頻幀。MAC層模塊30以第二周期性間隔產生MACRLP包。應當將以給定間隔產生的音頻幀放置在由MAC層模塊30產生的下一可用MACRLP包中。在有些實施例中，作為一個選項，RLP隊列28的總輸出隊列大小連同音頻包大小應當能夠在一個MACRLP包中載運。可相對於VT序列的每個包應用各種原則。雖然有些視頻包的大小可固有地用確保音頻和視頻可在單個MACRLP包中載運的方式確定，但其它視頻包可能較大且需要減小大小，以便確保音頻和視頻可在MACRLP包中載運，特別是在信道條件惡化的時候。通過相對於VT序列的每個包應用所述技術，即使視頻的內容龐大或信道帶寬大致有限也可確保令人滿意的語音通信。對包化器24提交給RTP/UDP/IP/PPP轉換模塊26以供插入在RLP隊列28中的每個視頻包的大小進行控制。以上原則確保不會因龐大的視頻內容消耗了連續的MACRLP包而導致音頻包延遲。而是，當音頻可用時，將來自視頻編碼器20的視頻劃分成具有經選擇以準許每個MACRLP包載運音頻和視頻的大小的包。每個音頻幀可用作提供到RLP隊列28的音頻包。或者，在有些實施例中，音頻包可綑紮以連續間隔提供的多個音頻幀。在有些實施例中，視頻包化器24可基於在連續音頻幀之間產生的MAC層包的估計的信道處理量來為每個MAC層包確定視頻包大小。可基於信道條件來估計處理量，所述信道條件由當前無線信道傳輸速率、無線基站活動性和傳輸功率限制中的一者或一者以上來表示。舉例來說，可基於當前MAC層數據速率、反向活動(RA)位和功率放大器(PA)限制來確定信道條件。此外，在有些實施例中，視頻編碼器20可進一步包含基於視頻緩衝器佔用率的自適應源速率控制。在此情況下，如果信道條件不支持視頻編碼速率，則考慮到列入優先的音頻包化的需要，可由視頻編碼器20降低源視頻編碼速率。圖2是說明因過多視頻內容或較差的信道條件導致的音頻延遲的圖。如圖2所示，音頻編碼器22產生音頻幀46A、46B、46C(統稱為幀46)，且視頻編碼器20產生視頻幀48A、48B、48C(統稱為幀48)。一系列連續的MACRLP包50A-50F(統稱為MACRLP包50)可用來載運從幀46和48導出的音頻包和視頻包，將所述包在RLP隊列28中緩衝。在音頻編碼器22產生了第一音頻幀46A之後，MAC層模塊30產生的下一可用MACRLP包是包50B。如果必要的話，包50C也可用來載運第一音頻幀46A。然而，如果視頻包佔滿RLP隊列28的內容，則可能長時期內不傳遞音頻幀46A。每個MACRLP包50具有從RL信道條件信息導出的相關聯數據速率。在良好的RL條件下，每個MACRLP包50載運每秒76.8千比特(76.8Kbps)的數據速率。然而，在較差的RL信道條件下，數據速率發生波動且通常較低，例如19.2Kbps或38.4Kbps。過多的視頻內容、較差的信道條件或兩者均可導致音頻包的傳輸出現顯著延遲。過大的視頻包大小可佔滿RL並增加音頻延遲，特別是在RL處理量因數據速率較低而減少的時候。視頻包如果不受控制，則可能會消耗過多量的MACRLP包空間，從而導致音頻包的連續傳輸之間出現延遲。在有些情況下，視頻可能會消耗若千個連續的MACRLP包50，從而使音頻無法迅速傳輸。每個MACRLP包50提供大約26.67ms的空間以供併入音頻和視頻包信息。在圖2的實例中，大致與音頻幀46A同時產生較大的視頻幀48A。在此情形下，連續視頻幀48A、48B彼此以133ms的時間間隔產生。然而，音頻幀46B、46C彼此以僅60ms的時間間隔產生。即使在良好的RL條件下，也可能沒有足夠的空間以併入音頻幀46A以及音頻幀46B和46C的音頻包。而是，與視頻幀48A相關聯的視頻包可能會消耗大部分MACRLP包50B-50F，從而導致顯著的音頻延遲。在信道條件惡化時(如圖2所示的較差的RL條件的情況下)，這個問題特別具有挑戰性。為了在各種信道條件下緩解音頻延遲，圖l的系統10併入有視頻包化器24，其控制從視頻幀36導出的視頻包的大小。通過相對於VT序列的每個包應用視頻限制，視頻包化器24可確保與VT序列相關聯的音頻不受損害。圖3是說明固定長度的視頻包成形技術的圖。固定長度的視頻包成形提供了對音頻延遲問題的部分解決方案。然而，固定長度的視頻包成形並未考慮到信道條件。因此，視頻可仍然在RL處理量減少時佔滿信道。此外，固定長度的包成形並未考慮到連續兩個音頻包之間的處理量，從而導致視頻數據包化過度或包化不足。在圖3的實例中，通過每60ms將視頻幀分段成固定大小的300位元組包52A、52B、52C(統稱為視頻包52)來控制視頻包的大小。將音頻幀每60ms分段成固定大小的93位元組包54A、54B、54C(統稱為音頻包54)。緊接在MACRLP包56內的音頻數據包54之後傳輸視頻包52。在正常操作條件下，固定長度的視頻包化會促進及時地傳輸MACRLP包56內的音頻包54。圖3中說明的方法確保在良好的RL條件下無延遲地傳輸音頻包。然而，如果RL條件惡化，則固定的300位元組視頻包52可佔滿RL，從而導致連續音頻包54之間出現延遲。由於視頻包52的長度固定，所以不能對RL條件的變化作出反應。在有些例子中，在良好的RL條件下，視頻數據可能會包化不足，從而導致對每個MACRLP包56提供的空間利用不足，並導致一般的帶寬低效。在較差的RL條件下，固定大小的視頻包52可能對於RL來說過大而難以處理，從而導致音頻延遲。出於此原因，本發明提出可調整長度的視頻包，其大小可響應於視頻內容或帶寬而自適應，以便為整個VT序列提供高質量的音頻。圖4是說明信道自適應視頻包成形技術的圖。在圖4的實例中，基於信道條件來調整視頻包大小，以便可無實質延遲地傳輸音頻包。視頻包的大小不是固定的，而是每個視頻包的大小基於音頻包大小和信道條件來動態調整。在良好的RL條件下，可增加視頻包大小，但不會大到使視頻包會佔滿RL和引入音頻延遲的程度。在較差的RL條件下，減小視頻包的大小以便提供將音頻幀包化並將其放置在下一可用的MACRLP包中的空間。如圖4所示，當音頻幀58A、58B、58C(統稱為音頻幀58)可用時，將視頻幀60A、60B、60C(統稱為視頻幀48)的大小確定為可將相應音頻幀放置在下一可用MACRLP包62A、62B、62C(統稱為MACRLP包62)中。如圖4中的箭頭所指示，將每個音頻幀58包化並接著放置在RLP隊列28中以供包含在MAC層模塊30所產生的下一可用MACRLP包中，從而消除了音頻包傳輸之間的過多延遲。參考數字64A、64B、64C(統稱為64)表示放置在相應MACRLP包62內的音頻包，連同視頻包數據。參考數字66A-66F(統稱為66)表示放置在相應MACRLP包62內的視頻包，帶有或不帶有音頻包。如圖4所示，每個MACRLP包62可只載運音頻、只載運視頻、或載運音頻與視頻兩者，這取決於RLP隊列28的內容。然而，在每個音頻包間隔處，將視頻包62的大小確定為準許將音頻包64併入在下一可用的MACRLP包62中。值得注意的是，當可用的RL速率(例如)因信道條件而降低時，音頻包58的大小相對於MACRLP包62的大小而增加。換句話說，隨著RL速率降低，每個音頻包58消耗MACRLP包62的較大部分，因為視頻包的大小減小。相反，對每個視頻包60的大小進行動態調整，使其隨著RL速率的降低而消耗MACRLP包62的較比例。以此方式，將視頻包60的大小確定為準許將每個音頻包58放置在下一可用的MACRLP包62內。結果是，給予音頻高於視頻的優先級，以便減少音頻延遲。圖5是說明實施根據本發明一實施例的信道自適應視頻包成形技術的視頻/音頻編碼系統12的方框圖。如圖5所示，編碼系統12包含視頻編碼器20、音頻編碼器22、視頻緩衝器68、音頻緩衝器70、視頻包化器24，包含有效負載大小估計器72和帶寬有效包化器74、RTP/UDP/IP/PPP轉換模塊26、RLP隊列28和反向業務信道(RTC)MAC單元76。RTCMAC單元76實施RTCMAC協議314,以便提供通信裝置在RL上傳輸所遵循的程序。為了方便起見，在圖5中未展示MAC層模塊30和PHY層模塊32。如將描述，有效負載大小估計器72基於一個或一個以上輸入來控制每個視頻包的大小。所述輸入可能關於信道條件、RLP隊列特徵和音頻包大小及狀態。帶寬有效包化器74基於有效負載大小估計器72所規定的估計的有效負載大小來產生視頻包，其受到最小視頻包大小的限制。視頻緩衝器68緩衝從視頻編碼器20接收的視頻信息，並將所述視頻信息傳遞到視頻包化器24。音頻緩衝器70緩衝從音頻編碼器22接收到的音頻幀信息，並將所述信息傳遞到RTP/UDP/IP/PPP轉換模塊26。將音頻和視頻包彼此獨立地插入在RLP隊列29中。由視頻包化器24產生的視頻包的大小確保MAC層模塊30(圖5中未展示)所產生的下一可用MACRLP包中將有充分的空間供音頻包使用。確切地說，視頻包未佔滿RLP隊列28，從而確保RLP隊列中的音頻包可與下一MACRLP包一起發送。在圖5的實例中，有效負載大小估計器72接收若干輸入，其中包含音頻包定時器、音頻優先級值MACPredNumberPlus、RLP隊列大小和信道信息。音頻包定時器指示音頻緩衝器70中目前是否有音頻信息可用，且如果有的話，則是否有用於傳遞每個音頻幀的時序。舉例來說，如果以每20ms的間隔傳遞音頻幀，則當音頻幀可用時音頻包定時器將被設定成20ms。在有些實施例中，音頻緩衝器70可經配置以綑紮連續的音頻幀以供併入在單個IP包中。在此情況下，音頻包定時器可對應於綑紮到音頻包中的幀數為多個。換句話說，音頻包定時器可具有與綑紮的幀數成比例或以其它方式相關的值。舉例來說，如果綑紮了三個音頻幀，則可將音頻定時器設定成60ms。因此，音頻包定時器也指示由音頻緩衝器70產生以供經由RTP/UDP/IP/PPP模塊26插入在RLP隊列28中的音頻包的大小。音頻優先級值MACPredNumberPlus定義音頻和視頻的相對優先級，且因此會影響與音頻和視頻相關聯的延遲。舉例來說，將MACPredNumberPlus確立為使得優先級值越小，音頻延遲就越低。相應地，隨著MACPredNumberPlus增加，音頻延遲增加且視頻延遲減小。相反，隨著MACPredNumberPlus減小，音頻延遲減小且視頻延遲增加。因此音頻延遲遵循音頻優先級值MACPredNumberPlus。有效負載大小估計器72使用MACPredNumberPlus值來控制每個視頻包的大小，從而導致規定的音頻包延遲，如同下文將更詳細描述。由有效負載大小估計器72接收到的RLP隊列大小表示在RLP隊列28中緩衝的當前數據的大小。有效負載大小估計器72使用RLP隊列大小來控制視頻包的大小。如果RLP隊列28相對較滿，則有效負載大小估計器72可調小視頻包的大小，以避免佔滿RL和導致過多的音頻延遲。如果RLP隊列28較不滿，則有效負載大小估計器72可增加視頻包的大小，同時仍然提供充分的空間以供音頻包使用。通過RLP隊列大小，有效負載大小估計器72能夠作為RLP隊列28的充滿度的函數來動態地調整視頻包的大小。隊列充滿度可能指示視頻內容過多、信道條件惡化或兩者。使用RLP隊列大小是有效負載大小估計器72可對視頻內容過載或信道條件變化作出反應的方式之一。有效負載大小估計器72也可通過監視RTCMAC單元76所提供的信道信息來更加直接地對信道條件的變化作出反應。RTCMAC單元76產生關於信道特徵的信息，所述信道特徵例如是當前MACRL速率、組合RA位和淨空限制。MACRL速率指示RL上可用的當前傳輸速率。RA位是反向活動位，其指示相關無線基站是否繁忙。淨空限制可指示基於當前傳輸功率而允許在傳輸時使用的最大速率。RA位指示RL何時因基站不活動而擁塞或不可用。PA限制表示傳輸功率淨空，且指示何時信道條件已惡化。有效負載大小估計器72基於各種輸入來產生有效負載大小估計。如果MACPredNumberPlus優先級值指示應給予音頻高優先級，則將有效負載大小估計選擇為準許將音頻包包含在下一可用MACRLP包中。帶寬有效包化器74從視頻緩衝器68接收視頻，且基於有效負載大小估計器72所規定的有效負載大小估計和最小視頻包大小來將視頻包化。最小視頻包大小表示將要由包化器24產生的視頻包的最小大小。實際上，最小視頻包大小控制視頻包大小的粒度和帶寬效率。對於較小的最小視頻包大小值，視頻包成形在容納音頻方面更加有效，且進而避免音頻延遲，但帶寬效率較低。對於較大的最小視頻包大小值，視頻包成形在避免音頻延遲方面效果較差，但提供較大的帶寬效率。如圖5中進一步展示，視頻編碼器20可經配置以響應於來自視頻緩衝器68的視頻緩衝器佔用率值。確切地說，在有些實施例中，視頻編碼器20基於視頻緩衝器佔用率而提供自適應的源速率控制特徵。當視頻緩衝器68相對較滿時，視頻編碼器20通過減小視頻編碼速率來作出響應。當視頻緩衝器68較不滿時，視頻編碼器20提高源視頻編碼速率。以此方式，如果信道條件無法支持當前的視頻編碼速率，則減小視頻編碼速率。此自適應的源速率控制特徵是可選的，但在有些應用中可能是合意的。為了說明目的將描述額外的實施細節。這些細節應被視為是示範性的，而不限制本發明中廣泛實施和描述的技術。對於cdma2000lxEV-DO0版本實施方案，可基於信道條件來估計RL處理量。3GPP2規範C.S0024-A(也稱為TIAIS-856-A)、第11-143頁、表11.9.6.1規定了在以Kbps計的傳輸速率方面表達的不同信道條件下對於MACRLP包的以字節計的最小和最大有效負載大小。將表11.9.6.1再現如下表tableseeoriginaldocumentpage17如果將上表中的每個傳輸級別表達為指數值，那麼每個MACRLP包的最大有效負載大小(包含音頻和視頻兩者)如下最大有效負載大小=2，+4—3。對於以上表達式，分別向9.6、19.2、38.4、76.8和153.6Kbps的傳輸速率級別指派指數值1、2、3、4和5。圖6是說明在一定範圍信道條件下的信道自適應視頻包成形的圖。如圖6所示，音頻幀58A、58B、58C(統稱為音頻幀58)和視頻幀60A、60B、60C(統稱為視頻幀60)、MACRLP包62A-62F(統稱為MACRLP包62)每一者具有相關聯的RL傳輸速率，且能夠載運對應於那些傳輸速率的不同最大有效負載大小。舉例來說，MACRLP包62A、62C和62D具有38.4Kbps的RL傳輸速率，且每一者能夠載運125位元組的最大有效負載大小。MACRLP包62B具有76.8Kbps的RL傳輸速率，且能夠載運253位元組的最大有效負載大小。MACRLP包62E和62F具有19.2Kbps的RL傳輸速率，且每一者能夠載運61位元組的最大有效負載大小。在示範性實施例中，可將有效負載大小估計器72的操作用偽碼錶達為算法。所述算法依賴於以下輸入RA位、PA限制、RL速率、RLPQueueSize、AudioPacketSize和MACPredNumberPlus。圖5中也展示了這些輸入。可從應用於有效負載大小估計器72的音頻包定時器導出AudioPacketSize。如先前所提到，組合的RA位是指示基站活動狀態的反向活動位，PA限制表示功率要求所強加的傳輸功率淨空限制，且指示何時信道條件己經惡化，RL速率是RL的傳輸速率，RLPQueueSize指示RLP隊列28的充滿度，且AudioPacketSize指示當前音頻包(即，將要添加到下一可用MACRLP包的音頻包)的大小。MACPredNumberPlus指示相對於視頻包而應給予音頻包的相對優先級。算法的輸出是VideoPayloadSize。為了初始化算法，將MACPredNumberPlus值設定如下MACPredNumber=floor((AudioFramesBundled承AudioFramelnterva1)/26.67)+1+MACPredNumberPlus。MACPredNumber表示載運含有單個音頻幀或一組綑紮的音頻幀的MACRLP包所必需的MACRLP包的數目。AudioFramelnterval表示音頻幀之間的時間間隔。值26.67是為每個MACRLP包分配的時間。因此，如果綑紮三個音頻幀且音頻幀間隔是20ms，且MACPredNumberPlus是零(這指示髙音頻優先級)，那麼MACPredNumber是3。這意味著針對其將估計視頻有效負載大小的MACRLP包的預測數目是3。對於每個綑紮的音頻包，在發送綑紮的音頻包之後，有效負載大小估計器72進行MAC音頻處理量確定。MAC處理量確定可如以下偽碼指示的那樣進行-MACThroughput=0;MACRatelacreasc1-RABit;MACPiedRate=CurRnte;to0=0;j<MACFtodNtmAiar;i++)《在以上MAC處理量確定中，MACThroughput是音頻傳輸所需的處理量值，MACRateIncrease指示是否將基於反向活動來提高MACRL速率，CurRate是當前的MACRL速率，MACPredRate是MACRL速率的表達為指數值的提高量。如上文所指示，MACThroughput是可用於三個預測的MACRLP包中的每一者的最大有效負載大小。假定有每個MACRLP包的最大有效負載大小MACThroughput,視頻有效負載大小估計器72如下估計最大視頻有效負載大小(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轉換模塊26引入的標頭信息的RTP/UDP/IP/PPP額外開銷的以字節計的固定數目。此固定額外開銷數目的18值可能在其它實施方案中是不同的。圖7是更詳細說明在一定範圍信道條件下的信道自適應視頻包成形的圖。有效負載大小估計器72適應於變化的信道條件(部分由RL傳輸速率來表示)，以便調整經呈現以併入在MAC層模塊30從RLP隊列28的內容產生的MACRLP包中的視頻包有效負載的大小。在圖7的實例中，以60ms的間隔產生音頻幀。在此情況下，每60ms作出關於接下來的三個MACRLP包中的可用有效負載大小的決策。如圖7所示，在第一決策點78，在3處索引當前MACRL速率以表示38.4Kbps，將RA位設定為零，PA限制等於4且RLP隊列含有X1個字節。在此情況下，根據以上公式，將接下來的三個MACRLP包中的每一者的處理量估計為253個字節。相應地，接下來的三個MACRLP包上的總處理量是253+253+253個字節減去已放置在RLP隊列28中的內容XI。因此，第一決策點50處的MACThroughput值是253+253+253—XI個字節。在第二決策點80處、在60ms之後，再次在3處索引當前RL速率且PA限制是4，但將RA位設定成1而不是0。在此情況下，RA位指示基站繁忙且導致預測接下來的三個MACRLP包上的處理量減少。確切地說，所估計的處理量MACThroughput是125+125+125—X2個字節，其中X2表示在第二決策點80之時RLP隊列28的內容。在第三決策點82處、在第二決策點78之後60ms，RA位是0，但RL速率已下降到2的指數值(19.2Kbps)且PA限制已下降到2的指數值。因此，在接下來的三個MACRLP包上的總處理量MACThroughput減少到61+61+61—X3個字節，其中X3表示在第三決策點82時RLP隊列28的內容。在MACThroughput減小時，可用於視頻包的空間也因為將音頻包列入優先而減小。在此情況下，有效負載大小估計器72減小視頻有效負載的估計大小以供包化。然而，當MACThroughput增加時，有效負載大小估計器72通過增加估計的視頻有效負載大小來作出響應。以此方式，視頻包化器24不但將音頻包列入優先，而且支持帶寬有效的視頻包化。在圖7的實例中，每次針對三個MACRLP包作出決策。然而，在其它實施例中，可應用更加積極的決策過程。舉例來說，可每20ms作出對MACThroughput的估計決策。在第一20ms間隔中，可針對三個MACRLP包作出決策。接著，在第二20ms間隔中，可針對一組三個連續MACRLP包中的剩餘兩個MACRLP包作出決策。最終，在接下來的20ms間隔期間針對三個包的組中的最後一個MACRLP包作出決策。在此情況下，在60ms間隔的過程中作出決策，且每20ms進行更新以便獲得可能已經在信道條件或RLP隊列充滿度方面發生的任何變化。在60ms之後，所述過程在接下來的60ms期間針對接下來的三個MACRLP包重複，且以迭代的方式繼續。一旦估計了MACThroughput，視頻有效負載大小估計器72便考慮到MACThroughput值來估計可容納的視頻有效負載大小，如上文所解釋。接著，帶寬有效包化器74使用估計的視頻有效負載大小和最小視頻包大小值來產生視頻包以供提交給RTP/UDP/TP/PPP轉換模塊26。現在將更詳細地描述帶寬有效包化器74的操作。一般來說，如果使用MPEG4視頻編碼，則視頻包化應符合網絡工作組請求註解(RFC)3016(日期為2000年11月)，而如果使用ITUH.263視頻編碼，則視頻包化應符合RFC2190(日期為1997年9月)或RFC2429(日期為1998年10月)。RFC3016概括了MPEGE4流的RTP有效負載格式。RFC2429概括了ITUH.263流的1998版本的RTP有效負載格式，且RFC2190概括了ITUH.263流的原始版本的RTP格式。RFC3016規定視頻包(a)必須用視頻對象平面(VOP)標頭或視頻包(VP)標頭開頭，如果其中任一者存在的話；(b)如果滿足了先前原則，則可含有一個以上VP標頭；(c)可只含有視頻數據而其中沒有任何VOP和VP標頭；以及(d)不能含有跨越兩個視頻幀的數據。RFC2190規定視頻包(a)必須用圖片開始碼(PSC)或區塊組(GOB)開頭；(b)無須具有GOB標頭或完整的GOB;以及(c)GOB的字節無須對準。RFC2429規定視頻包(a)可用字節對準的PSC、GOB標頭、條標頭和條結尾(EOS)標記開頭，且(b)可以是後續的包，其並不用任何同步碼開頭，但允許在視頻包的中間有同步碼。考慮到以上要求，視頻編碼器20可經配置以將視頻數據以VOP禾I]VP(對於MPEG4)或PSC、GOB禾口SSC(對於H.263)插入在視頻緩衝器68中。與MPEG4兼容的編碼器以VOP或VP為單位產生數據。H.263編碼器以PSC、GOB或SSC為單位產生數據，其中GOB的字節是對準的。當使用RFC2190時，模式A是默認的。在示範性實施例中，可將帶寬有效包化器60的操作表達成利用以下輸入的算法VideoDataInBuffer、EstimatedVideoPayloadSize,minVPSize。VideoDatalnBuffer表示年見頻緩衝器68中的視頻的大小。EstimatedVideoPayloadSize表示由有效負載大小估計器72確定的估計的視頻有效負載大小。minVPsize值是將要由包化器60產生的最小視頻包大小，且用以控制粒度和帶寬效率。帶寬有效包化算法的輸出是供提交給RTP/UDP/IP/PPP轉換模塊26的一個或一個以上視頻包。在一示範性實施例中，帶寬有效包化器74的操作由以下偽碼來表達ViifedPayloadDstaQ:瓶咖y;for(;;)ifCReniainingMdeoPa^EoadSke<minVFSize/2)elseif(RemainingVideoFayloadSizeSize>=RemajiringVi(teoPayloadSi坊+minVPSize)if(RFC3016關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基於由有效負載大小估計器72和minVPSize所提供的EstimatedVideoPayloadSize而產生視頻包。RemainingVideoPayloadSize表示在產生視頻包期間的任何點處仍然可用的有效負載的量。起初，RemainingVideoPayloadSize等於視頻有效負載大小估計器74所提供的整個EstimatedVideoPayloadSize。VideoPayloadSize表示包中的視頻有效負載的實際大小，且起初設定成零。VideoPayloadData[]識別視頻緩衝器68中的視頻數據段的陣列。包化器74首先確定RemainingVideoPayloadSize是否小於最小VP大小/2。如果是的話，將RemainingVideoPayloadSize設定成零。或者，如果RemainingVideoPayloadSize小於minVPSize，那麼將RemainingVideoPayloadSize的值設定成等於minVPSize。接著，如果RemainingVideoPayloadSize等於零或VideoDatalnBuffer為空，則所述過程重設，因為下一可用MACRLP包中沒有剩餘空間，或視頻緩衝器68中沒有剩餘視頻。如果VideoInBuffer的大小大於或等於RemainingVideoPayloadSize加上minVPSize，則包化器74接下來確定剩餘的VideoPayloadSize是否大於或等於minVPSize/2。如果是的話，包化器74便確定RFC3016或RFC2429是否可適用。如果RFC3016或RFC2429均不適用，那麼包化器74確定RFC2190是否可適用，即ITUH.263的初始版本的RTP有效負載格式是否適用。如果RFC3016或RFC2429適用，那麼包化器74將視頻從視頻緩衝器68(由開始地址VideoPayloadData禾口偏移VideoPayloadSize來確定)複製(memcpy)至U由VideoDatalnBuffer識別的輸入緩衝器。起初，將VideoPayloadSize設定成零。從視頻緩衝器68複製的視頻的量等於RemainingVideoPayloadSize，其起初被設定成估計的VideoPayloadSize。包化器74接著將VideoPayloadSize調整成等於RemainingVideoPayloadSize。接下來，包化器74將視頻數據從輸入緩衝器複製到偏移剩餘VideoPayloadSize所識別的地址，複製的量由RemainingVideoPayloadSize來確定。接著將VideoDatalnBuffer的內容分段以供包化。如果RFC2190適用，那麼包化器74將視頻從視頻緩衝器68(由開始地址VideoPayloadData和偏移VideoPayloadSize來確定)復串U(memcpy)到由VideoDatalnBuffer識別的輸入緩衝器。同樣，起初將VideoPayloadSize設定成零。從視頻緩衝器68複製的視頻的量等於VideoDatalnBuffer的大小。接著，使VideoPayloadSize等於VideoDatalnBuffer的大小。一旦退出RFC3016/RFC2429操作或RFC21卯操作，包化器74接下來便從VideoPayloadData中產生VideoPacket，所述VideoPacket的有效負載大小等於VideoPayloadSize的當前值。接著，將RemainingVideoPayloadSize的值設定成零。在此點處，已由包化器74產生視頻包以供提交給RTP/UDP/IP/PPP轉換模塊26。如果RemainingVideoPayloadSize不小於minVPSize，貝ijRemainingVideoPayloadSize不等於零,VideoDatalnBuffer不為空，且VideoDatalnBuffer的大小不大於或等於RemainingVideoPayloadSize+minVPSize，那麼包化器74使用地址VideoPayloadData加上VideoPayloadSize的偏移將數據從緩衝器68複製到VideoDatalnBuffer。在此情況下，所複製的數據的量等於VideoPayloadSize。接著，包化器74將VideoPayloadSize設定成等於VideoDatalnBuffer的大小。包化器74接下來將RemainingVideoPayloadSize設定成等於RemainingVideoPayloadSize的最大值減去視頻緩衝器大小和零。VideoBufferSize表示視頻緩衝器68的大小。如果在視頻緩衝器68中不再有數據，或者當前時戳(TS)不等於下一TS，或RemainingVideoPayloadSize等於零，或VideoDatalnBuffer經過分段，則包化器74從VideoPayloadData中產生一個有效負載大小為VideoPayloadSize的VideoPacket,並將VideoPayloadSize設定成零。否則，包化器74設定VideoDatalnBuffer，23以獲得視頻緩衝器68中的下一幀、GOB或條單位(如果存在的話)，或者如果視頻緩衝器中不再有數據的話，則將其設定為空。圖8是說明根據本發明一實施例的信道自適應視頻包成形技術的流程圖。如圖8所示，音頻緩衝器70產生音頻包(84)。RTP/UDP/IP/PPP模塊26將音頻包添加到RLP隊列28(86)。有效負載大小估計器72確定RLP隊列大小(88)，音頻-視頻優先級值(90)和信道條件(92)。基於那些確定，有效負載大小估計器72估計將要產生的下一視頻包的有效負載大小(94)。帶寬有效包化器74產生視頻包(96)，並基於估計的有效負載大小和最小視頻包大小來確定視頻包的大小(98)。帶寬有效包化器74將視頻包添加到RLP隊列28(100)。MAC層模塊30從RLP隊列28的內容產生MACRLP包(102)。本發明中所描述的信道自適應視頻包成形支持較高的音頻數據優先級。如果沒有信道自適應視頻包成形，則音頻通常會延遲較大的視頻包。根據本發明所描述的包成形技術的視頻幀分段在下一可用MACRLP包中為將要傳輸的音頻包提供空間。雖然將視頻包大小確定為固定長度在許多例子中可減少音頻延遲，但此方法並不適於信道條件，且可在帶寬消耗方面較低效。信道自適應視頻包成形提供將音頻和視頻數據列入優先的靈活性。可規定音頻-視頻優先級值(MACPREDNUMBERPLUS)與最小視頻包大小(minVPSize)的不同值以實現音頻與視頻優先級之間的所需折衷。此外，信道自適應包成形可提供幾乎恆定的音頻延遲性能，從而即使在較差的信道條件下也能產生流暢的音頻會話。在有些情況下，音頻延遲性能可與沒有視頻的性能相當。視頻處理量可適於音頻處理量和信道條件。確切地說，可根據可用帶寬自適應地改變視頻處理量，且當音頻處理量減少時可增加視頻處理量。有利的是，信道自適應視頻包成形可易於低複雜度地實施，從而在有些實施例中只需要若干行代碼，正如本發明中所闡述。此外，在大多實施例中，不需要修改解碼系統14。本發明所描述的技術可在通用微處理器、數位訊號處理器(DSP)、專用集成電路(ASIC)、場可編程門陣列(FPGA)或其它等效的邏輯裝置內實施。舉例來說，視頻編碼器系統12及其組件和模塊可實施為在數位訊號處理器(DSP)或其它處理裝置上運行的編碼過程或編碼/解碼(CODEC)過程的部分。相應地，描述成模塊的組件可形成此過程的可編程特徵或形成單獨過程。視頻編碼器系統12可具有用於存儲指令和數據的專用存儲器，以及專用的硬體、軟體、固件或其組合。如果是用軟體實施的，則所述技術可實施成計算機可讀媒體上的指令，所述媒體例如是隨機存取存儲器(RAM)、只讀存儲器(ROM)、非易失性隨機存取存儲器(NVRAM)、電可擦除可編程只讀存儲器(EEPROM)、快閃記憶體或類似裝置。所述指令致使一個或一個以上處理器執行本發明描述的功能性的特定方面。已經描述了各種實施例。這些和其它實施例處於所附權利要求書的範圍內。權利要求1.一種方法，其包括產生音頻包；估計無線信道的處理量；以及產生視頻包，其具有基於所述估計的處理量而確定的視頻包大小。2.根據權利要求l所述的方法，其中基於所述估計的處理量和所述音頻包的大小而確定所述視頻包大小。3.根據權利要求1所述的方法，其進一步包括將所述音頻包和所述視頻包放置在輸出隊列中，其中基於所述估計的處理量、所述音頻包的大小和在將所述視頻包放置在所述輸出隊列中之前所述輸出隊列中經緩衝數據的大小來確定所述視頻包大小。4.根據權利要求1所述的方法，其進一步包括將所述音頻包和所述視頻包放置在輸出隊列中，以及基於所述輸出隊列的內容中的至少一些內容來產生媒體存取控制(MAC)層包。5.根據權利要求l所述的方法，其進一步包括以第一周期性間隔接收音頻幀，以及以第二周期性間隔產生媒體存取控制(MAC)層包，其中產生音頻包包含產生綑紮所述音頻幀中的至少兩者的音頻包，並將所述音頻包添加到下一可用MAC層包。6.根據權利要求1所述的方法，其進一步包括將所述音頻包和所述視頻包放置在輸出隊列中，以及基於所述輸出隊列的內容中的至少一些內容來產生媒體存取控制(MAC)層包，其中所述視頻包大小是基於所述音頻包的所述大小、所述估計的處理量和在將所述視頻包放置在所述輸出隊列中之前所述輸出隊列中經緩衝數據的大小。7.根據權利要求l所述的方法，其進一步包括基於當前無線信道傳輸速率、無線基站活動性和傳輸功率限制中的一者或一者以上來估計所述處理量。8.根據權利要求1所述的方法，其中所述視頻包大小充分地小，以避免在經由所述無線信道傳輸所述音頻包的過程中發生實質性延遲。9.根據權利要求l所述的方法，其進一步包括接收多個視頻幀，以及基於未包化視頻幀數據的量來調整視頻編碼速率。10.根據權利要求l所述的方法，其中至少部分基於向所述音頻包指派優於所述視頻包的優先級的優先級值來確定所述視頻包大小，且其中針對給定的估計的處理量的所述視頻包大小隨著所述優先級值的減小而增加。11.根據權利要求1所述的方法，其中所述視頻包大小大於或等於最小視頻包大小。12.根據權利要求1所述的方法，其進一步包括基於所述音頻包和所述視頻包來產生物理層包，並將所述物理層包傳輸到遠程裝置以支持移動無線視頻電話會議。13.根據權利要求12所述的方法，其中所述物理層包大致符合cdma2000lxEV-DO版本0標準。14.一種系統，其包括音頻編碼器，其產生音頻數據；音頻緩衝器，其接收所述音頻數據並輸出音頻包；視頻編碼器，其產生視頻數據；包化器，其估計無線信道的處理量，並從所述視頻數據中產生視頻包，所述視頻包具有基於所述估計的處理量而確定的視頻包大小。15.根據權利要求14所述的系統，其中所述視頻包大小是基於所述估計的處理量和所述音頻包的大小而確定。16.根據權利要求14所述的系統，其進一步包括輸出隊列，所述輸出隊列接收所述音頻包和所述視頻包，其中所述視頻包大小是基於所述估計的處理量、所述音頻包的大小和在將所述視頻包放置在所述輸出隊列中之前所述輸出隊列中經緩衝數據的大小而確定。17.根據權利要求14所述的系統，其進一步包括輸出隊列，其接收所述音頻包和所述視頻包；以及媒體存取控制(MAC)層模塊，其基於所述輸出隊列的內容中的至少一些內容來產生MAC層包。18.根據權利要求14所述的系統，其中所述音頻緩衝器以第一周期性間隔接收音頻幀，並針對所述音頻幀中的每一者產生音頻包，且所述MAC層模塊以第二周期性間隔產生媒體存取控制(MAC)層包，將所述音頻包添加到下一可用MAC層包。19.根據權利要求14所述的系統，其中所述音頻緩衝器以第一周期性間隔接收音頻幀，並綑紮所述音頻幀中的至少兩者以形成所述音頻包，且所述MAC層模塊以第二周期性間隔產生媒體存取控制(MAC)層包，並將所述音頻包添加到下一可用的MAC層包。20.根據權利要求14所述的系統，其中所述包化器基於當前無線信道傳輸速率、無線基站活動性和傳輸功率限制中的一者或一者以上來估計所述處理量。21.根據權利要求14所述的系統，其中所述視頻包大小充分地小，以避免在經由所述無線信道傳輸所述音頻包的過程中發生實質性延遲。22.根據權利要求14所述的系統，其中所述視頻編碼器產生多個視頻幀，並基於未包化視頻幀數據的量來調整視頻編碼速率。23.根據權利要求14所述的系統，其中所述包化器至少部分基於向所述音頻包指派優於所述視頻包的優先級的優先級值來確定所述視頻包大小，其中針對給定的估計的處理量的所述視頻包大小隨著所述優先級值的減小而增加。24.根據權利要求14所述的系統，其中所述視頻包大小大於或等於最小視頻包大小。25.根據權利要求l所述的系統，其進一步包括物理層模塊，所述物理層模塊基於所述音頻包和所述視頻包而產生物理層包，並將所述物理層包傳輸到遠程裝置以支持移動無線視頻電話會議。26.根據權利要求25所述的系統，其中所述物理層包大致符合cdma2000lxEV-DO版本0標準。27.—種計算機可讀媒體，其包括致使處理器執行以下操作的指令-產生音頻包；估計無線信道的處理量；以及產生視頻包，其具有基於所述估計的處理量而確定的視頻包大小。28.根據權利要求27所述的計算機可讀媒體，其進一步包括致使處理器基於所述估計的處理量和所述音頻包的大小來確定所述視頻包大小的指令。29.根據權利要求27所述的計算機可讀媒體，其進一步包括致使處理器將所述音頻包和所述視頻包放置在輸出隊列中的指令，其中所述視頻包大小是基於所述估計的處理量、所述音頻包的大小和在將所述視頻包放置在所述輸出隊列中之前所述輸出隊列中經緩衝數據的大小而確定。30.根據權利要求27所述的計算機可讀媒體，其進一步包括致使處理器將所述音頻包和所述視頻包放置在輸出隊列中並基於所述輸出隊列的內容中的至少一些內容來產生媒體存取控制(MAC)層包的指令。31.根據權利要求27所述的計算機可讀媒體，其進一步包括致使處理器以第一周期性間隔接收接收的音頻幀並以第二周期性間隔產生媒體存取控制(MAC)層包的指令，其中產生音頻包包含針對所述音頻幀中的每一者產生音頻包，並將所述音頻包添加到下一可用MAC層包。32.根據權利要求27所述的計算機可讀媒體，其進一步包括致使處理器以第一周期性間隔接收音頻幀並以第二周期性間隔產生媒體存取控制(MAC)層包的指令，其中產生音頻包包含產生綑紮所述音頻幀中的至少兩者的音頻包，並將所述音頻包添加到下一可用MAC層包。33.根據權利要求27所述的計算機可讀媒體，其進一步包括致使所述處理器基於當前無線信道傳輸速率、無線基站活動性和傳輸功率限制中的一者或一者以上來估計所述處理量的指令。34.根據權利要求27所述的計算機可讀媒體，其中所述視頻包大小充分地小，以避免在經由所述無線信道傳輸所述音頻包的過程中發生實質性延遲。35.根據權利要求27所述的計算機可讀媒體，其進一步包括致使所述處理器接收多個視頻幀並基於未包化視頻幀數據的量來調整視頻編碼速率的指令。36.根據權利要求27所述的計算機可讀媒體，其中所述視頻包大小至少部分是基於向所述音頻包指派優於所述視頻包的優先級的優先級值而確定，且其中針對給定的估計的處理量的所述視頻包大小隨著所述優先級值的減小而增加。37.根據權利要求27所述的計算機可讀媒體，其中所述視頻包大小大於或等於最小視頻包大小。38.根據權利要求27所述的計算機可讀媒體，其進一步包括致使處理器基於所述音頻包和所述視頻包來產生物理層包並將所述物理層包傳輸到遠程裝置以支持移動無線視頻電話會議的指令。39.根據權利要求38所述的計算機可讀媒體，其中所述物理層包大致符合cdma2000lxEV-DO版本O標準。40.—種系統，其包括用於產生音頻包的裝置；用於估計無線信道的處理量的裝置；以及用於產生視頻包的裝置，所述視頻包具有基於所述估計的處理量而確定的視頻包大小。41.根據權利要求40所述的系統，其中所述視頻包的大小是基於所述估計的處理量和所述音頻包的大小而確定。42.根據權利要求40所述的系統，其進一步包括將所述音頻包和所述視頻包放置在輸出隊列中的裝置，其中所述視頻包大小是基於所述估計的處理量、所述音頻包的大小和在將所述視頻包放置在所述輸出隊列中之前所述輸出隊列中經緩衝數據的大小而確定。43.根據權利要求40所述的系統，其進一步包括將所述音頻包和所述視頻包放置在輸出隊列中並基於所述輸出隊列的內容中的至少一些內容來產生媒體存取控制(MAC)層包。全文摘要本發明涉及用於視頻電話(VT)的視頻包成形技術。所述技術可用來將音頻包列入優先，以便減少音頻延遲。信道條件、過多的視頻內容或兩者均可導致音頻傳輸中的延遲。當減少反向鏈路(RL)處理量時，視頻包大小可佔滿所述RL並增加音頻延遲。所述視頻包可消耗過多數目的MACRLP包，從而導致連續音頻包之間的延遲。對每個視頻包的大小進行調整，以便將音頻包列入優先以無實質延遲地進行傳輸。可基於信道條件來控制所述視頻包大小。可無實質延遲地傳送音頻，即使視頻可能因信道條件而遭受延遲。雖然視頻可能會受信道條件損害，但視頻包成形確保VT方能夠流暢地進行口頭會話。文檔編號H04L12/56GK101313536SQ200680043711公開日2008年11月26日申請日期2006年9月29日優先權日2005年9月29日發明者李彥輯申請人:高通股份有限公司