CN101313536B

CN101313536B - 视频电话的视频包成形

Info

Publication number: CN101313536B
Application number: CN2006800437110A
Authority: CN
Inventors: 李彦辑
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2005-09-29
Filing date: 2006-09-29
Publication date: 2013-06-05
Anticipated expiration: 2026-09-29
Also published as: US8102878B2; KR20080066002A; US20070071030A1; CN101313536A; WO2007041319A2; WO2007041319A3; EP1929720B1; JP2012170120A; JP2009510942A; EP1929720A2; JP5661678B2; KR100982155B1

Abstract

本发明涉及用于视频电话(VT)的视频包成形技术。所述技术可用来将音频包列入优先，以便减少音频延迟。信道条件、过多的视频内容或两者均可导致音频传输中的延迟。当减少反向链路(RL)处理量时，视频包大小可占满所述RL并增加音频延迟。所述视频包可消耗过多数目的MAC RLP包，从而导致连续音频包之间的延迟。对每个视频包的大小进行调整，以便将音频包列入优先以无实质延迟地进行传输。可基于信道条件来控制所述视频包大小。可无实质延迟地传送音频，即使视频可能因信道条件而遭受延迟。虽然视频可能会受信道条件损害，但视频包成形确保VT方能够流畅地进行口头会话。

Description

视频电话的视频包成形

技术领域

本发明涉及视频电话(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可具有挑战性。无线信道上的数据速率受到限制且随着时间而变动。举例来说，在CDMA2000 1x EV-DO 0版网络中，数据速率可能会因无线覆盖区域内的条件或多个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所示，系统10包含编码器系统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基于信道条件执行视频包成形，以便将音频包传输列入优先并进而避免过多的音频延迟。

系统10可经由传输信道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的内容产生MAC RLP包。PHY层模块30将MAC RLP包转换成PHY层包以以用于在信道16上传输。

解码系统14的PHY层模块34和MAC层模块36以相反方式操作。PHY层模块34将从信道16接收的PHY层包转换成MAC RLP包。MAC层模块36将MAC RLP包放置到RLP队列38中。RTP/UDP/IP/PPP转换模块40从RLP队列38中的数据中剥离标头信息，并重新组装视频和音频数据以供分别传递到视频解码器42和音频解码器44。

系统10可经设计以支持一种或一种以上无线通信技术，例如码分多址(CDMA)、频分多址(FDMA)、时分多址(TDMA)或正交频分多路复用(OFDM)或另一合适的无线技术。以上无线通信技术可根据多种无线电接入技术中的任一者来传递。举例来说，可根据cdma2000或宽带CDMA(WCDMA)标准来传递CDMA。可根据全球移动通信系统(GSM)标准来传递TDMA。通用移动电信系统(UMTS)标准准许GSM或WCDMA操作。通常对于VT应用来说，系统10将经设计以支持例如cdma2000 1x EV-DO 0版本等高数据速率(HDR)技术。

视频编码器20根据例如MPEG-4等视频压缩方法来产生编码的视频数据。可使用其它视频压缩方法，例如国际电信联盟(ITU)H.263、ITU H.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)来配置，且可称为MAC RLP包。PHY层模块32可包含将MAC RLP音频-视频包转换成PHY层包以供经由信道16传输。

信道16将PHY层包载运到解码器系统14。信道16可为编码器系统12与解码器系统14之间的任何物理连接。举例来说，信道16可以是有线连接，例如局域或广域有线网络。或者，如本文中描述，信道16可以是无线连接，例如蜂窝式、卫星或光学连接。信道条件可能是有线和无线信道的关注因素，而且对于经由无线信道16执行的移动VT应用尤其成问题。

根据本发明，视频包化器24控制提供到RTP/UDP/IP/PPP转换模块26的每个视频包的大小，以便将音频的传输列入优先。确切地说，将视频包的大小确定为使得每个包均可由下一可用的MAC层包容纳。对视频包的大小进行控制防止了因信道条件、较大的视频包或两者导致的音频延迟。当有音频包可用时，将其放置在RLP队列中以包含在MAC层模块30所产生的下一可用MAC RLP包中。音频包可与大小已经过确定而准许将音频包放置在MAC RLP包内的空间的视频包组合。

视频包化器24经配置以在其能够基于信道条件来调整视频包大小的意义上成为信道自适应的。以此方式，编码器系统12可将音频包的传输列入优先，以避免在信道条件较差时发生音频延迟。同时，视频包化器24可确保将音频列入优先不会导致视频包被包化不足。换句话说，视频包化器24将视频包的大小确定得足够小而准许将一个或一个以上音频包包含在下一可用MAC RLP包中，但并未小到使MAC RLP包中的多余空间浪费。因此，视频包化器24可既支持将音频包列入优先，又支持对视频包的有效传输。

解码器系统14的PHY层模块34从PHY层包中识别出MAC层包，并将内容重新组装到MAC RLP包中。MAC层模块36接着对MAC RLP包的内容重新组装，以便提供视频和音频包以供插入在RLP队列38内。RTP/UDP/EP/PPP模块40剥离伴随的标头信息，并将视频包提供到视频解码器42，且将音频包提供到音频解码器44。视频解码器42解码视频数据帧，以产生视频数据的流以用于驱动显示装置。音频解码器44解码音频数据，以产生音频信息以例如经由音频扬声器呈现给用户。

如上所述，提供视频包化器24，用其来控制提交给RTP/UDP/IP/PPP转换模块26的视频包的大小。视频包化器24控制视频包的大小，以便将MAC RLP包中的音频包的传输列入优先，并防止视频包占满RLP队列28。以此方式，可无实质延迟地传送VT会议的音频部分，即使视频部分可能因信道条件遭受延迟。虽然视频可能会受信道条件损害，但视频包化器24确保参加VT会议的各方仍然能够流畅地执行口头会话。

由视频包化器24应用的包成形技术可应用一个或一个以上原则，以便确保将音频包的传输列入优先。根据一个原则，举例来说，应当在从RLP队列28的内容产生的紧接的下一个可用的MAC RLP包中发送音频包。音频编码器22以第一周期性间隔产生音频帧。MAC层模块30以第二周期性间隔产生MAC RLP包。应当将以给定间隔产生的音频帧放置在由MAC层模块30产生的下一可用MAC RLP包中。在有些实施例中，作为一个选项，RLP队列28的总输出队列大小连同音频包大小应当能够在一个MAC RLP包中载运。

可相对于VT序列的每个包应用各种原则。虽然有些视频包的大小可固有地用确保音频和视频可在单个MAC RLP包中载运的方式确定，但其它视频包可能较大且需要减小大小，以便确保音频和视频可在MAC RLP包中载运，特别是在信道条件恶化的时候。通过相对于VT序列的每个包应用所述技术，即使视频的内容庞大或信道带宽大致有限也可确保令人满意的语音通信。

对包化器24提交给RTP/UDP/IP/PPP转换模块26以供插入在RLP队列28中的每个视频包的大小进行控制。以上原则确保不会因庞大的视频内容消耗了连续的MAC RLP包而导致音频包延迟。而是，当音频可用时，将来自视频编码器20的视频划分成具有经选择以准许每个MAC RLP包载运音频和视频的大小的包。每个音频帧可用作提供到RLP队列28的音频包。或者，在有些实施例中，音频包可捆扎以连续间隔提供的多个音频帧。

在有些实施例中，视频包化器24可基于在连续音频帧之间产生的MAC层包的估计的信道处理量来为每个MAC层包确定视频包大小。可基于信道条件来估计处理量，所述信道条件由当前无线信道传输速率、无线基站活动性和传输功率限制中的一者或一者以上来表示。举例来说，可基于当前MAC层数据速率、反向活动(RA)位和功率放大器(PA)限制来确定信道条件。此外，在有些实施例中，视频编码器20可进一步包含基于视频缓冲器占用率的自适应源速率控制。在此情况下，如果信道条件不支持视频编码速率，则考虑到列入优先的音频包化的需要，可由视频编码器20降低源视频编码速率。

图2是说明因过多视频内容或较差的信道条件导致的音频延迟的图。如图2所示，音频编码器22产生音频帧46A、46B、46C(统称为帧46)，且视频编码器20产生视频帧48A、48B、48C(统称为帧48)。一系列连续的MAC RLP包50A-50F(统称为MAC RLP包50)可用来载运从帧46和48导出的音频包和视频包，将所述包在RLP队列28中缓冲。在音频编码器22产生了第一音频帧46A之后，MAC层模块30产生的下一可用MACRLP包是包50B。如果必要的话，包50C也可用来载运第一音频帧46A。然而，如果视频包占满RLP队列28的内容，则可能长时期内不传递音频帧46A。

每个MAC RLP包50具有从RL信道条件信息导出的相关联数据速率。在良好的RL条件下，每个MAC RLP包50载运每秒76.8千比特(76.8Kbps)的数据速率。然而，在较差的RL信道条件下，数据速率发生波动且通常较低，例如19.2Kbps或38.4Kbps。过多的视频内容、较差的信道条件或两者均可导致音频包的传输出现显著延迟。过大的视频包大小可占满RL并增加音频延迟，特别是在RL处理量因数据速率较低而减少的时候。

视频包如果不受控制，则可能会消耗过多量的MAC RLP包空间，从而导致音频包的连续传输之间出现延迟。在有些情况下，视频可能会消耗若干个连续的MAC RLP包50，从而使音频无法迅速传输。每个MAC RLP包50提供大约26.67ms的空间以供并入音频和视频包信息。在图2的实例中，大致与音频帧46A同时产生较大的视频帧48A。在此情形下，连续视频帧48A、48B彼此以133ms的时间间隔产生。然而，音频帧46B、46C彼此以仅60ms的时间间隔产生。

即使在良好的RL条件下，也可能没有足够的空间以并入音频帧46A以及音频帧46B和46C的音频包。而是，与视频帧48A相关联的视频包可能会消耗大部分MAC RLP包50B-50F，从而导致显著的音频延迟。在信道条件恶化时(如图2所示的较差的RL条件的情况下)，这个问题特别具有挑战性。为了在各种信道条件下缓解音频延迟，图1的系统10并入有视频包化器24，其控制从视频帧36导出的视频包的大小。通过相对于VT序列的每个包应用视频限制，视频包化器24可确保与VT序列相关联的音频不受损害。

图3是说明固定长度的视频包成形技术的图。固定长度的视频包成形提供了对音频延迟问题的部分解决方案。然而，固定长度的视频包成形并未考虑到信道条件。因此，视频可仍然在RL处理量减少时占满信道。此外，固定长度的包成形并未考虑到连续两个音频包之间的处理量，从而导致视频数据包化过度或包化不足。

在图3的实例中，通过每60ms将视频帧分段成固定大小的300字节包52A、52B、52C(统称为视频包52)来控制视频包的大小。将音频帧每60ms分段成固定大小的93字节包54A、54B、54C(统称为音频包54)。紧接在MAC RLP包56内的音频数据包54之后传输视频包52。在正常操作条件下，固定长度的视频包化会促进及时地传输MACRLP包56内的音频包54。

图3中说明的方法确保在良好的RL条件下无延迟地传输音频包。然而，如果RL条件恶化，则固定的300字节视频包52可占满RL，从而导致连续音频包54之间出现延迟。由于视频包52的长度固定，所以不能对RL条件的变化作出反应。在有些例子中，在良好的RL条件下，视频数据可能会包化不足，从而导致对每个MAC RLP包56提供的空间利用不足，并导致一般的带宽低效。在较差的RL条件下，固定大小的视频包52可能对于RL来说过大而难以处理，从而导致音频延迟。出于此原因，本发明提出可调整长度的视频包，其大小可响应于视频内容或带宽而自适应，以便为整个VT序列提供高质量的音频。

图4是说明信道自适应视频包成形技术的图。在图4的实例中，基于信道条件来调整视频包大小，以便可无实质延迟地传输音频包。视频包的大小不是固定的，而是每个视频包的大小基于音频包大小和信道条件来动态调整。在良好的RL条件下，可增加视频包大小，但不会大到使视频包会占满RL和引入音频延迟的程度。在较差的RL条件下，减小视频包的大小以便提供将音频帧包化并将其放置在下一可用的MAC RLP包中的空间。

如图4所示，当音频帧58A、58B、58C(统称为音频帧58)可用时，将视频帧60A、60B、60C(统称为视频帧48)的大小确定为可将相应音频帧放置在下一可用MAC RLP包62A、62B、62C(统称为MAC RLP包62)中。如图4中的箭头所指示，将每个音频帧58包化并接着放置在RLP队列28中以供包含在MAC层模块30所产生的下一可用MAC RLP包中，从而消除了音频包传输之间的过多延迟。参考数字64A、64B、64C(统称为64)表示放置在相应MAC RLP包62内的音频包，连同视频包数据。参考数字66A-66F(统称为66)表示放置在相应MAC RLP包62内的视频包，带有或不带有音频包。如图4所示，每个MAC RLP包62可只载运音频、只载运视频、或载运音频与视频两者，这取决于RLP队列28的内容。然而，在每个音频包间隔处，将视频包62的大小确定为准许将音频包64并入在下一可用的MAC RLP包62中。

值得注意的是，当可用的RL速率(例如)因信道条件而降低时，音频包58的大小相对于MAC RLP包62的大小而增加。换句话说，随着RL速率降低，每个音频包58消耗MAC RLP包62的较大部分，因为视频包的大小减小。相反，对每个视频包60的大小进行动态调整，使其随着RL速率的降低而消耗MAC RLP包62的较比例。以此方式，将视频包60的大小确定为准许将每个音频包58放置在下一可用的MAC RLP包62内。结果是，给予音频高于视频的优先级，以便减少音频延迟。

图5是说明实施根据本发明一实施例的信道自适应视频包成形技术的视频/音频编码系统12的方框图。如图5所示，编码系统12包含视频编码器20、音频编码器22、视频缓冲器68、音频缓冲器70、视频包化器24，包含有效负载大小估计器72和带宽有效包化器74、RTP/UDP/IP/PPP转换模块26、RLP队列28和反向业务信道(RTC)MAC单元76。RTC MAC单元76实施RTC MAC协议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中未展示)所产生的下一可用MAC RLP包中将有充分的空间供音频包使用。确切地说，视频包未占满RLP队列28，从而确保RLP队列中的音频包可与下一MAC RLP包一起发送。

在图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也可通过监视RTC MAC单元76所提供的信道信息来更加直接地对信道条件的变化作出反应。RTC MAC单元76产生关于信道特征的信息，所述信道特征例如是当前MAC RL速率、组合RA位和净空限制。MAC RL速率指示RL上可用的当前传输速率。RA位是反向活动位，其指示相关无线基站是否繁忙。净空限制可指示基于当前传输功率而允许在传输时使用的最大速率。RA位指示RL何时因基站不活动而拥塞或不可用。PA限制表示传输功率净空，且指示何时信道条件已恶化。

有效负载大小估计器72基于各种输入来产生有效负载大小估计。如果MACPredNumberPlus优先级值指示应给予音频高优先级，则将有效负载大小估计选择为准许将音频包包含在下一可用MAC RLP包中。带宽有效包化器74从视频缓冲器68接收视频，且基于有效负载大小估计器72所规定的有效负载大小估计和最小视频包大小来将视频包化。最小视频包大小表示将要由包化器24产生的视频包的最小大小。实际上，最小视频包大小控制视频包大小的粒度和带宽效率。对于较小的最小视频包大小值，视频包成形在容纳音频方面更加有效，且进而避免音频延迟，但带宽效率较低。对于较大的最小视频包大小值，视频包成形在避免音频延迟方面效果较差，但提供较大的带宽效率。

如图5中进一步展示，视频编码器20可经配置以响应于来自视频缓冲器68的视频缓冲器占用率值。确切地说，在有些实施例中，视频编码器20基于视频缓冲器占用率而提供自适应的源速率控制特征。当视频缓冲器68相对较满时，视频编码器20通过减小视频编码速率来作出响应。当视频缓冲器68较不满时，视频编码器20提高源视频编码速率。以此方式，如果信道条件无法支持当前的视频编码速率，则减小视频编码速率。此自适应的源速率控制特征是可选的，但在有些应用中可能是合意的。

为了说明目的将描述额外的实施细节。这些细节应被视为是示范性的，而不限制本发明中广泛实施和描述的技术。对于cdma2000 1x EV-DO 0版本实施方案，可基于信道条件来估计RL处理量。3GPP2规范C.S0024-A(也称为TIAIS-856-A)、第11-143页、表11.9.6.1规定了在以Kbps计的传输速率方面表达的不同信道条件下对于MAC RLP包的以字节计的最小和最大有效负载大小。将表11.9.6.1再现如下：

表

传输速率(Kbps)	最小有效负载大小(字节)	最大有效负载大小(字节)
			9.6Kbps	1	29
19.2Kbps	30	61
			38.4Kbps	62	125
76.8Kbps	126	253
			153.6Kbps	254	509

如果将上表中的每个传输级别表达为指数值，那么每个MAC RLP包的最大有效负载大小(包含音频和视频两者)如下：

最大有效负载大小＝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)、MAC RLP包62A-62F(统称为MAC RLP包62)每一者具有相关联的RL传输速率，且能够载运对应于那些传输速率的不同最大有效负载大小。举例来说，MAC RLP包62A、62C和62D具有38.4Kbps的RL传输速率，且每一者能够载运125字节的最大有效负载大小。MAC RLP包62B具有76.8Kbps的RL传输速率，且能够载运253字节的最大有效负载大小。MAC RLP包62E和62F具有19.2Kbps的RL传输速率，且每一者能够载运61字节的最大有效负载大小。

在示范性实施例中，可将有效负载大小估计器72的操作用伪码表达为算法。所述算法依赖于以下输入：RA位、PA限制、RL速率、RLPQueueSize、AudioPacketSize和MACPredNumberPlus。图5中也展示了这些输入。可从应用于有效负载大小估计器72的音频包定时器导出AudioPacketSize。如先前所提到，组合的RA位是指示基站活动状态的反向活动位，PA限制表示功率要求所强加的传输功率净空限制，且指示何时信道条件已经恶化，RL速率是RL的传输速率，RLPQueueSize指示RLP队列28的充满度，且AudioPacketSize指示当前音频包(即，将要添加到下一可用MAC RLP包的音频包)的大小。MACPredNumberPlus指示相对于视频包而应给予音频包的相对优先级。算法的输出是VideoPayloadSize。

为了初始化算法，将MACPredNumberPlus值设定如下：MACPredNumber＝floor((AudioFramesBundled*AudioFrameInterval)/26.67)+1+MACPredNumberPlus。

MACPredNumber表示载运含有单个音频帧或一组捆扎的音频帧的MAC RLP包所必需的MAC RLP包的数目。Audio Framelnterval表示音频帧之间的时间间隔。值26.67是为每个MAC RLP包分配的时间。因此，如果捆扎三个音频帧且音频帧间隔是20 ms，且MACPredNumberPlus是零(这指示高音频优先级)，那么MACPredNumber是3。这意味着针对其将估计视频有效负载大小的MAC RLP包的预测数目是3。

对于每个捆扎的音频包，在发送捆扎的音频包之后，有效负载大小估计器72进行MAC音频处理量确定。MAC处理量确定可如以下伪码指示的那样进行：

MACThroughput＝0；

MACRateIncrease＝1-RABit；

MACPredRate＝CurRate；

for(i＝0；i＜MACPredNumber，i++)

{

MACPredRate＝MIN(MACPredRate+

MACRateIncrease，4)， PALimit)；

MACTbroughput+＝(2^{MACPradRase+4}-3)；

}

在以上MAC处理量确定中，MACThroughput是音频传输所需的处理量值，MACRateIncrease指示是否将基于反向活动来提高MAC RL速率，CurRate是当前的MACRL速率，MACPredRate是MAC RL速率的表达为指数值的提高量。如上文所指示，MACThroughput是可用于三个预测的MAC RLP包中的每一者的最大有效负载大小。

假定有每个MAC RLP包的最大有效负载大小MACThroughput，视频有效负载大小估计器72如下估计最大视频有效负载大小(VideoPayloadSize)：

VideoPayloadSize＝MAX(MACThroughput-RLPQueneSize，0)

VideoPayloadSize＝MAX(VideoPayloadSize-2*AudioPacketSize-45，0)，

其中RLPQueueSize指示RLP队列28的充满度，且AudioPacketSize表示将要添加到下一MACRLP包的音频包的大小。值45是考虑到RTP/UDP/IP/PPP转换模块26引入的标头信息的RTP/UDP/IP/PPP额外开销的以字节计的固定数目。此固定额外开销数目的值可能在其它实施方案中是不同的。

图7是更详细说明在一定范围信道条件下的信道自适应视频包成形的图。有效负载大小估计器72适应于变化的信道条件(部分由RL传输速率来表示)，以便调整经呈现以并入在MAC层模块30从RLP队列28的内容产生的MAC RLP包中的视频包有效负载的大小。在图7的实例中，以60ms的间隔产生音频帧。在此情况下，每60ms作出关于接下来的三个MAC RLP包中的可用有效负载大小的决策。

如图7所示，在第一决策点78，在3处索引当前MAC RL速率以表示38.4Kbps，将RA位设定为零，PA限制等于4且RLP队列含有X1个字节。在此情况下，根据以上公式，将接下来的三个MAC RLP包中的每一者的处理量估计为253个字节。相应地，接下来的三个MAC RLP包上的总处理量是253+253+253个字节减去已放置在RLP队列28中的内容X1。因此，第一决策点50处的MACThroughput值是253+253+253-X1个字节。

在第二决策点80处、在60ms之后，再次在3处索引当前RL速率且PA限制是4，但将RA位设定成1而不是0。在此情况下，RA位指示基站繁忙且导致预测接下来的三个MAC RLP包上的处理量减少。确切地说，所估计的处理量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的实例中，每次针对三个MAC RLP包作出决策。然而，在其它实施例中，可应用更加积极的决策过程。举例来说，可每20ms作出对MACThroughput的估计决策。在第一20ms间隔中，可针对三个MAC RLP包作出决策。接着，在第二20ms间隔中，可针对一组三个连续MAC RLP包中的剩余两个MAC RLP包作出决策。最终，在接下来的20ms间隔期间针对三个包的组中的最后一个MAC RLP包作出决策。在此情况下，在 60ms间隔的过程中作出决策，且每20ms进行更新以便获得可能已经在信道条件或RLP队列充满度方面发生的任何变化。在60ms之后，所述过程在接下来的60ms期间针对接下来的三个MAC RLP包重复，且以迭代的方式继续。

一旦估计了MACThroughput，视频有效负载大小估计器72便考虑到MACThroughput值来估计可容纳的视频有效负载大小，如上文所解释。接着，带宽有效包化器74使用估计的视频有效负载大小和最小视频包大小值来产生视频包以供提交给RTP/UDP/TP/PPP转换模块26。现在将更详细地描述带宽有效包化器74的操作。

一般来说，如果使用MPEG4视频编码，则视频包化应符合网络工作组请求注解(RFC)3016(日期为2000年11月)，而如果使用ITU H.263视频编码，则视频包化应符合RFC 2190(日期为1997年9月)或RFC 2429(日期为1998年10月)。RFC 3016概括了MPEGE4流的RTP有效负载格式。RFC 2429概括了ITU H.263流的1998版本的RTP有效负载格式，且RFC 2190概括了ITU H.263流的原始版本的RTP格式。

RFC 3016规定视频包：(a)必须用视频对象平面(VOP)标头或视频包(VP)标头开头，如果其中任一者存在的话；(b)如果满足了先前原则，则可含有一个以上VP标头；(c)可只含有视频数据而其中没有任何VOP和VP标头；以及(d)不能含有跨越两个视频帧的数据。RFC 2190规定视频包：(a)必须用图片开始码(PSC)或区块组(GOB)开头；(b)无须具有GOB标头或完整的GOB；以及(c)GOB的字节无须对准。RFC 2429规定视频包：(a)可用字节对准的PSC、GOB标头、条标头和条结尾(EOS)标记开头，且(b)可以是后续的包，其并不用任何同步码开头，但允许在视频包的中间有同步码。

考虑到以上要求，视频编码器20可经配置以将视频数据以VOP和VP(对于MPEG4)或PSC、GOB和SSC(对于H.263)插入在视频缓冲器68中。与MPEG4兼容的编码器以VOP或VP为单位产生数据。H.263编码器以PSC、GOB或SSC为单位产生数据，其中GOB的字节是对准的。当使用RFC 2190时，模式A是默认的。

在示范性实施例中，可将带宽有效包化器60的操作表达成利用以下输入的算法：VideoDataInBuffer、EstimatedVideoPayloadSize、minVPSize。VideoDataInBuffer表示视频缓冲器68中的视频的大小。EstimatedVideoPayloadSize表示由有效负载大小估计器72确定的估计的视频有效负载大小。minVPsize值是将要由包化器60产生的最小视频包大小，且用以控制粒度和带宽效率。带宽有效包化算法的输出是供提交给RTP/UDP/IP/PPP转换模块26的一个或一个以上视频包。在一示范性实施例中，带宽有效包化器74的操作由以下伪码来表达：

RimainingVidePayloadSize＝EstimatedVideoPayloadSize＝0；

VideoPayloadD[]：an array；

for(；；)

{

if(RemainingVideoPayloadSize＜minVPSize/2)

RemainingVideoPayloadSize＝0；

else if(RimainingVideoPayloadSize＜minVPSize)

RemainingVideoPayloadSize＝minVPSize；

If((RemainingVideoPayloadSize＝0)||(VideoDataInBuffer＝＝NULL))bread； If(VideoDataInBuffer-＞＝RemainingVideoPayloadSize+minVPSize)

{

if(RemainingVideoPayloadSize-＞＝(minVPSize/2))

{

if(RFC3016||RFC2429)

memcpy(VideoPayloadData+VideoPayloadSize，VideoDataInBuffer-

＞Data， RemainingVideoPayloadSize)；

VideoPayloadSize+＝RemainingVideoPayloadSize；

memcpy(VideoDataInBuffer-＞Data，

VidepDataInBuffer-＞Data+RemainingVideoPayloadSize，

VideoDataInBuffer-＞Size-RemainingVideoPayloadSize，

VideoDataInBuffer-＞Size-＝RemainingVideoPayloadSize)；

VideoDataInBuffer-＞Fragmented＝1；

else if(RFC2190)

memcpy(VideoPayloadData+VideoPayloadSize，VideoDataInBuffer-

＞Data， VideoDataInBuffer-＞Size)；

VideoPayloadSize+＝VideoDataInBuffer-＞Size；

}

Make one VideoPacket from VideoPayloadData[] with payload size of

VideoPayloadSize；

Remaining VideoPayloadSize＝0；

}

else

{

memcpy(VideoPayloadData+VideoPayloadSize，VideoDataInBuffer-＞Data，

VideoDataInBuffer-＞Size)；

VideoPayloadSize+＝VideoDataInBuffer-＞Size；

Remaining VideoPayloadSize＝MAX(Remaining VideoPayloadSize-

VideoBufferSize-＞Size-45，0)；

if(No more data in buffer||the current TS！＝the next TS||

RemainingVideoPayloadSize＝0||VideoDataInBuffer-＞

Fragmented＝＝1)

Make one VideoPacket from VideoPayloadData[]with payload size of

VideoPayloadSize；

VideoPayloadSize＝0；

VideoDataInBuffer＝the next frame/GOB/slice unit in the video buffer if any，

or NULL，if no more data

}

如以上伪码所表示，带宽有效包化器74基于由有效负载大小估计器72和minVPSize所提供的EstimatedVideoPayloadSize而产生视频包。RemainingVideoPayloadSize表示在产生视频包期间的任何点处仍然可用的有效负载的量。起初，RemainingVideoPayloadSize等于视频有效负载大小估计器74所提供的整个EstimatedVideoPayloadSize。VideoPayloadSize表示包中的视频有效负载的实际大小，且起初设定成零。VideoPayloadData[]识别视频缓冲器68中的视频数据段的阵列。

包化器74首先确定RemainingVideoPayloadSize是否小于最小VP大小/2。如果是的话，将RemainingVideoPayloadSize设定成零。或者，如果RemainingVideoPayloadSize小于minVPSize，那么将RemainingVideoPayloadSize的值设定成等于minVPSize。接着，如果RemainingVideoPayloadSize等于零或VideoDataInBuffer为空，则所述过程重设，因为下一可用MAC RLP包中没有剩余空间，或视频缓冲器68中没有剩余视频。

如果VideoInBuffer的大小大于或等于RemainingVideoPayloadSize加上minVPSize，则包化器74接下来确定剩余的VideoPayloadSize是否大于或等于minVPSize/2。如果是的话，包化器74便确定RFC3016或RFC2429是否可适用。如果RFC3016或RFC2429均不适用，那么包化器74确定RFC2190是否可适用，即ITU H.263的初始版本的RTP 有效负载格式是否适用。

如果RFC3016或RFC2429适用，那么包化器74将视频从视频缓冲器68(由开始地址VideoPayloadData和偏移VideoPayloadSize来确定)复制(memcpy)到由VideoDataInBuffer识别的输入缓冲器。起初，将VideoPayloadSize设定成零。从视频缓冲器68复制的视频的量等于RemainingVideoPayloadSize，其起初被设定成估计的VideoPayloadSize。包化器74接着将VideoPayloadSize调整成等于RemainingVideoPayloadSize。接下来，包化器74将视频数据从输入缓冲器复制到偏移剩余VideoPayloadSize所识别的地址，复制的量由RemainingVideoPayloadSize来确定。接着将VideoDataInBuffer的内容分段以供包化。

如果RFC2190适用，那么包化器74将视频从视频缓冲器68(由开始地址VideoPayloadData和偏移VideoPayloadSize来确定)复制(memcpy)到由VideoDataInBuffer识别的输入缓冲器。同样，起初将VideoPayloadSize设定成零。从视频缓冲器68复制的视频的量等于VideoDataInBuffer的大小。接着，使VideoPayloadSize等于VideoDataInBuffer的大小。

一旦退出RFC3016/RFC2429操作或RFC2190操作，包化器74接下来便从VideoPayloadData中产生VideoPacket，所述VideoPacket的有效负载大小等于VideoPayloadSize的当前值。接着，将RemainingVideoPayloadSize的值设定成零。在此点处，已由包化器74产生视频包以供提交给RTP/UDP/IP/PPP转换模块26。如果RemainingVideoPayloadSize不小于minVPSize，则RemainingVideoPayloadSize不等于零，VideoDataInBuffer不为空，且VideoDataInBuffer的大小不大于或等于RemainingVideoPayloadSize+minVPSize，那么包化器74使用地址VideoPayloadData加上VideoPayloadSize的偏移将数据从缓冲器68复制到VideoDataInBuffer。在此情况下，所复制的数据的量等于VideoPayloadSize。接着，包化器74将VideoPayloadSize设定成等于VideoDataInBuffer的大小。

包化器74接下来将RemainingVideoPayloadSize设定成等于RemainingVideoPayloadSize的最大值减去视频缓冲器大小和零。VideoBufferSize表示视频缓冲器68的大小。如果在视频缓冲器68中不再有数据，或者当前时戳(TS)不等于下一TS，或RemainingVideoPayloadSize等于零，或VideoDataInBuffer经过分段，则包化器74从VideoPayloadData中产生一个有效负载大小为VideoPayloadSize的VideoPacket，并将VideoPayloadSize设定成零。否则，包化器74设定VideoDataInBuffer，以获得视频缓冲器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的内容产生MAC RLP包(102)。

本发明中所描述的信道自适应视频包成形支持较高的音频数据优先级。如果没有信道自适应视频包成形，则音频通常会延迟较大的视频包。根据本发明所描述的包成形技术的视频帧分段在下一可用MAC RLP包中为将要传输的音频包提供空间。虽然将视频包大小确定为固定长度在许多例子中可减少音频延迟，但此方法并不适于信道条件，且可在带宽消耗方面较低效。信道自适应视频包成形提供将音频和视频数据列入优先的灵活性。可规定音频-视频优先级值(MACPREDNUMBERPLUS)与最小视频包大小(minVPSize)的不同值以实现音频与视频优先级之间的所需折衷。

此外，信道自适应包成形可提供几乎恒定的音频延迟性能，从而即使在较差的信道条件下也能产生流畅的音频会话。在有些情况下，音频延迟性能可与没有视频的性能相当。视频处理量可适于音频处理量和信道条件。确切地说，可根据可用带宽自适应地改变视频处理量，且当音频处理量减少时可增加视频处理量。有利的是，信道自适应视频包成形可易于低复杂度地实施，从而在有些实施例中只需要若干行代码，正如本发明中所阐述。此外，在大多实施例中，不需要修改解码系统14。

本发明所描述的技术可在通用微处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、场可编程门阵列(FPGA)或其它等效的逻辑装置内实施。举例来说，视频编码器系统12及其组件和模块可实施为在数字信号处理器(DSP)或其它处理装置上运行的编码过程或编码/解码(CODEC)过程的部分。相应地，描述成模块的组件可形成此过程的可编程特征或形成单独过程。视频编码器系统12可具有用于存储指令和数据的专用存储器，以及专用的硬件、软件、固件或其组合。如果是用软件实施的，则所述技术可实施成计算机可读媒体上的指令，所述媒体例如是随机存取存储器(RAM)、只读存储器(ROM)、非易失性随机存取存储器(NVRAM)、电可擦除可编程只读存储器(EEPROM)、快闪存储器或类似装置。所述指令致使一个或一个以上处理器执行本发明描述的功能性的特定方面。

已经描述了各种实施例。这些和其它实施例处于所附权利要求书的范围内。

Claims

1.一种视频包成形方法，其包括：

产生音频包；

估计无线信道的处理量；以及

产生视频包，其具有基于所述估计的处理量和所述音频包的大小而确定的视频包大小。

2.根据权利要求1所述的方法，其中对每个视频包的大小进行调整，以便将音频包优先传输而无实质延迟。

3.根据权利要求1所述的方法，其进一步包括将所述音频包和所述视频包放置在输出队列中，其中基于所述估计的处理量、所述音频包的大小和在将所述视频包放置在所述输出队列中之前所述输出队列中经缓冲数据的大小来确定所述视频包大小。

4.根据权利要求1所述的方法，其进一步包括将所述音频包和所述视频包放置在输出队列中，以及基于所述输出队列的内容中的至少一些内容来产生媒体存取控制MAC层包。

5.根据权利要求1所述的方法，其进一步包括以第一周期性间隔接收音频帧，以及以第二周期性间隔产生媒体存取控制MAC层包，其中产生音频包包含针对所述音频帧中的每一者产生音频包，以及将所述音频包添加到下一可用MAC层包。

6.根据权利要求1所述的方法，其进一步包括以第一周期性间隔接收音频帧，以及以第二周期性间隔产生媒体存取控制MAC层包，其中产生音频包包含产生捆扎所述音频帧中的至少两者的音频包，并将所述音频包添加到下一可用MAC层包。

7.根据权利要求1所述的方法，其进一步包括将所述音频包和所述视频包放置在输出队列中，以及基于所述输出队列的内容中的至少一些内容来产生媒体存取控制MAC层包，其中所述视频包大小是基于所述音频包的所述大小、所述估计的处理量和在将所述视频包放置在所述输出队列中之前所述输出队列中经缓冲数据的大小。

8.根据权利要求1所述的方法，其进一步包括基于当前无线信道传输速率、无线基站活动性和传输功率限制中的一者或一者以上来估计所述处理量。

9.根据权利要求1所述的方法，其中所述视频包大小充分地小，以避免在经由所述无线信道传输所述音频包的过程中发生实质性延迟。

10.根据权利要求1所述的方法，其进一步包括接收多个视频帧，以及基于未包化视频帧数据的量来调整视频编码速率。

11.根据权利要求1所述的方法，其中至少部分基于向所述音频包指派优于所述视频包的优先级的优先级值来确定所述视频包大小，且其中针对给定的估计的处理量的所述视频包大小随着所述优先级值的减小而增加。

12.根据权利要求1所述的方法，其中所述视频包大小大于或等于最小视频包大小。

13.根据权利要求1所述的方法，其进一步包括基于所述音频包和所述视频包来产生物理层包，并将所述物理层包传输到远程装置，以支持移动无线视频电话会议。

14.根据权利要求13所述的方法，其中所述物理层包大致符合cdma20001x EV-DO版本0标准。

15.一种视频包成形系统，其包括：

音频编码器，其产生音频数据；

音频缓冲器，其接收所述音频数据并输出音频包；

视频编码器，其产生视频数据；

包化器，其估计无线信道的处理量，并从所述视频数据中产生视频包，所述视频包具有基于所述估计的处理量和所述音频包的大小而确定的视频包大小。

16.根据权利要求15所述的系统，其进一步包括输出队列，所述输出队列接收所述音频包和所述视频包，其中所述视频包大小是基于所述估计的处理量、所述音频包的大小和在将所述视频包放置在所述输出队列中之前所述输出队列中经缓冲数据的大小而确定。

17.根据权利要求15所述的系统，其进一步包括：输出队列，其接收所述音频包和所述视频包；以及媒体存取控制MAC层模块，其基于所述输出队列的内容中的至少一些内容来产生MAC层包。

18.根据权利要求17所述的系统，其中所述音频缓冲器以第一周期性间隔接收音频帧，并针对所述音频帧中的每一者产生音频包，且所述MAC层模块以第二周期性间隔产生媒体存取控制MAC层包，将所述音频包添加到下一可用MAC层包。

19.根据权利要求17所述的系统，其中所述音频缓冲器以第一周期性间隔接收音频帧，并捆扎所述音频帧中的至少两者以形成所述音频包，且所述MAC层模块以第二周期性间隔产生媒体存取控制MAC层包，并将所述音频包添加到下一可用的MAC层包。

20.根据权利要求15所述的系统，其中所述包化器基于当前无线信道传输速率、无线基站活动性和传输功率限制中的一者或一者以上来估计所述处理量。

21.根据权利要求15所述的系统，其中所述视频包大小充分地小，以避免在经由所述无线信道传输所述音频包的过程中发生实质性延迟。

22.根据权利要求15所述的系统，其中所述视频编码器产生多个视频帧，并基于未包化视频帧数据的量来调整视频编码速率。

23.根据权利要求15所述的系统，其中所述包化器至少部分基于向所述音频包指派优于所述视频包的优先级的优先级值来确定所述视频包大小，其中针对给定的估计的处理量的所述视频包大小随着所述优先级值的减小而增加。

24.根据权利要求15所述的系统，其中所述视频包大小大于或等于最小视频包大小。

25.根据权利要求15所述的系统，其进一步包括物理层模块，所述物理层模块基于所述音频包和所述视频包而产生物理层包，并将所述物理层包传输到远程装置，以支持移动无线视频电话会议。

26.根据权利要求25所述的系统，其中所述物理层包大致符合cdma20001x EV-DO版本0标准。

27.一种视频包成形系统，其包括：

用于产生音频包的装置；

用于估计无线信道的处理量的装置；以及

用于产生视频包的装置，所述视频包具有基于所述估计的处理量和所述音频包的大小而确定的视频包大小。

28.根据权利要求27所述的系统，其进一步包括将所述音频包和所述视频包放置在输出队列中的装置，其中所述视频包大小是基于所述估计的处理量、所述音频包的大小和在将所述视频包放置在所述输出队列中之前所述输出队列中经缓冲数据的大小而确定。

29.根据权利要求27所述的系统，其进一步包括将所述音频包和所述视频包放置在输出队列中并基于所述输出队列的内容中的至少一些内容来产生媒体存取控制MAC层包。