用于提供AMR-WBDTX同步的系统和方法转让专利
申请号 : CN200880104750.6
文献号 : CN101790754A
文献日 : 2010-07-28
发明人 : P·奥雅拉 , A·拉卡涅米
申请人 : 诺基亚公司
摘要 :
一种用于提供改进的自适应多速率宽带(AMR-WB)非连续传输(DTX)同步的系统和方法。根据各种实施方式，在DTX时段将开始(即，接收到SID_FIRST帧)之前的预定数量的帧处，关于不活跃语音时段的开始的指示经由语音活动检测(VAD)标志被信号传送到解码器。在VAD标志指示活跃语音时，或者在少于之前预定数量的帧时该VAD标志被设置为0的情况下，接收的NO_DATA帧可以以较高的可靠度被分类为活跃语音，即，被视为发射机、网络或终端发起的信令，并且可以由SPEECH_LOST来替换。在8个帧之前或更早之前时VAD标志被设置为0的情况下，将NO_DATA帧分类为DTX。
权利要求 :
1.一种对音频内容进行解码的方法，包括：
从比特流接收音频内容的多个帧，所述多个帧的每一个包括各自帧是否代表活跃音频的指示；
接收音频内容的附加帧，所述附加帧包括没有数据包含于其中的指示；以及如果在所述附加帧之前的预定数量的帧内的多个帧都不包括所述各自帧代表活跃音频的指示，则将所述附加帧分类作为非连续传输。
2.根据权利要求1所述的方法，进一步包括：如果在所述附加帧之前的预定数量的帧内的所述多个帧的至少一个包括所述各自帧代表活跃音频的指示，则将所述附加帧分类为代表活跃音频。
3.根据权利要求2所述的方法，进一步包括：如果在所述附加帧之前的预定数量的帧内的所述多个帧的至少一个包括所述各自帧代表活跃音频的指示，则用指定音频已经丢失的帧来替换所述附加帧。
4.根据权利要求1所述的方法，其中所述音频内容包括语音内容。
5.根据权利要求1所述的方法，其中所述预定数量的帧包括8个帧。
6.根据权利要求1所述的方法，其中所述比特流包括自适应多速率宽带比特流。
7.一种计算机程序产品，包含在计算机可读介质中，包括配置为执行权利要求1的过程的计算机代码。
8.一种装置，包括：
处理器；以及
存储器单元，其可通信地连接至所述处理器，并且包括：用于对来自比特流的音频内容的已接收的多个帧进行处理的计算机代码，所述多个帧的每一个包括各自帧是否代表活跃音频的指示；
用于对音频内容的已接收的附加帧进行处理的计算机代码，所述附加帧包括没有数据包含于其中的指示；以及用于如果在所述附加帧之前的预定数量的帧内的多个帧都不包括所述各自帧代表活跃音频的指示，则将所述附加帧分类作为非连续传输的计算机代码。
9.根据权利要求8所述的装置，其中所述存储器单元进一步包括：用于如果在所述附加帧之前的预定数量的帧内的所述多个帧的至少一个包括所述各自帧代表活跃音频的指示，则将所述附加帧分类为代表活跃音频的计算机代码。
10.根据权利要求8所述的装置，进一步包括：如果在所述附加帧之前的预定数量的帧内的所述多个帧的至少一个包括所述各自帧代表活跃音频的指示，则用指定音频已经丢失的帧来替换所述附加帧。
11.根据权利要求8所述的装置，其中所述音频内容包括语音内容。
12.根据权利要求8所述的装置，其中所述预定数量的帧包括8个帧。
13.根据权利要求8所述的装置，其中所述比特流包括自适应多速率宽带比特流。
14.一种设备，包括：
用于从比特流接收音频内容的多个帧的装置，所述多个帧的每一个包括各自帧是否代表活跃音频的指示；
用于接收音频内容的附加帧的装置，所述附加帧包括没有数据包含于其中的指示；以及用于如果在所述附加帧之前的预定数量的帧内的多个帧都不包括所述各自帧代表活跃音频的指示，则将所述附加帧分类作为非连续传输的装置。
15.根据权利要求14所述的设备，进一步包括：用于如果在所述附加帧之前的预定数量的帧内的所述多个帧的至少一个包括所述各自帧代表活跃音频的指示，则将所述附加帧分类为代表活跃音频的装置。
16.根据权利要求15所述的设备，进一步包括：用于如果在所述附加帧之前的预定数量的帧内的所述多个帧的至少一个包括所述各自帧代表活跃音频的指示，则用指定音频已经丢失的帧来替换所述附加帧的装置。
说明书 :
技术领域
本发明总体上涉及语音编码。更具体地，本发明涉及语音编码、容错以及在电路交换网络(诸如无汇接操作(TFO)网络、无声码器操作(TrFO)网络)和分组交换网络(诸如IP语音(VoIP)网络)上的语音传输。
背景技术
本部分旨在对权利要求书中细述的本发明提供背景或上下文。此处的描述可以包括能够被探究的概念，却不必须是之前已经想到或者探究的那些概念。因此，除了在此明确指出之外，本部分提及的内容对于本申请的说明书和权利要求书而言不是现有技术，并且并不因为包括在本部分中就承认其为现有技术。
第三代合作伙伴计划(3GPP)核心网中的TFO和TrFO以及服务(诸如VoIP服务)中的接收机逻辑可以利用传输码RX_NO_DATA将传递至语音编码器的空帧或空分组注入自适应多速率宽带(AMR-WB)比特流中。换言之，活跃的语音比特流偶尔可以包含空帧或空分组。这些空帧或空分组通常用于其他目的。例如，这种帧或分组通常被诸如TFO/TrFO信令或其他系统级信令之类的紧急信令数据所替换。为了避免解码器将这种“非语音”数据帧/分组作为语音帧/分组处理，将其标记为RX_NO_DATA。在接收RX_NO_DATA帧的另一示例中，沿传输路径丢失或损坏的帧可以例如由某个中间实体替换为RX_NO_DATA帧。
在启用非连续传输(DTX)操作的情况下，当AMR-WB解码器接收活跃语音的片段中的RX_NO_DATA帧时，根据TS 26.173 v7.0.0(定点实现)和TS 26.204 v7.0.0(浮点实现)的AMR-WB解码器实现可以静默(mute)或衰减语音合成的输出，有时可以长达100ms的时段。此输出的静默或衰减引起与显著的语音质量下降有关的问题。
根据TS 26.193 v7.0.0(即“Source controlled rate operation”)的既定AMR-WB解码器功能注意到：在解码器处于SPEECH(语音)模式中时，从DTX处理器的角度来看，接收的NO_DATA帧应当作为SPEECH_LOST(语音丢失)帧来处理。具体而言，TS 26.193 v7.0.0记载有“如果RX DTX处理器处于模式SPEECH，则应当按照3GPP TS26.191中定义的那样来替代或静默被分类为SPEECH_DEGRADED(语音下降)、SPEECH_BAD(不良语音)、SPEECH_LOST(语音丢失)或NO_DATA(无数据)的帧。分类为NO_DATA的帧应当与不具有有效语音信息的SPEECH_LOST帧相类似地进行处理。”
可能期待AMR-WB解码器变得更具鲁棒性，以便其能够处理可以由网络创建的或可以由终端/网关中的实现创建的任何帧类型输入组合。然而，在DTX同步的情况中出现了某些问题。AMR-WB编码器具有检测不活跃语音的语音活动性检测(VAD)功能，并且为了指示包含不活跃语音的帧，AMR-WB编码器相应地将VAD标志设置为0。在8个帧的DTX拖尾(hangover)时段之后，调用非连续传输(DTX)功能，在该DTX拖尾时段期间，确定舒适噪音参数。针对此DTX拖尾，解码器需要与编码器同步。如果解码器没有与编码器完全同步，则在解码器中的舒适噪音计算将不能与编码器对准。
传统上，所接收的NO_DATA帧被简单地分类为属于DTX时段的帧，即，指示不存在传输。然而，在这种情况下会产生问题，因为，尽管发射机或网络正在发射信令帧，而DTX同步逻辑却没有对准。在接收到包含舒适噪音参数的第一静音描述符(SID)之后，该同步被恢复。另一方面，当NO_DATA帧被分类为活跃语音比特流的一部分并且由SPEECH_LOST帧类型(并由此由解码器中的错误隐藏操作)替换时，针对DTX处理会产生问题。例如，如果接收机已经丢失了SID_FIRST帧(DTX时段的第一帧)，则该NO_DATA帧被错误地分类为丢失语音帧。在接收到下一个SID_UPDATE之后，该同步被再次恢复。
在定点AMR-WB参考实现(3GPP TS 26.173)中，此DTX同步的处理以C代码实现，如以下的示例1所示(源文件“dtx.c”中的函数“rx_dtx_handler”)。
示例1
1 if((sub(frame_type，RX_SID_FIRST)＝＝0)||
2 (sub(frame_type，RX_SID_UPDATE)＝＝0)||
3 (sub(frame_type，RX_SID_BAD)＝＝0)||
4 (sub(frame_type，RX_NO_DATA)＝＝0))
5 {
6 encState＝DTX； move16()；
7 }else
8 {
9 encState＝SPEECH； move16()；
10 }
在上述第1-3行，该算法检查该帧是SID_FIRST帧、SID_UPDATE帧还是受损的SID帧。在第4行，该算法确定此帧是否是NO_DATA帧。如果这些条件中的一个或多个为真，则解码器切换至(或停留在)DTX状态。基于此源代码片段，可见，如果在活跃语音的片段中间插入NO_DATA帧(替代丢弃语音帧)来为信令数据腾出空间，则即使校正动作应该停留在语音状态中，解码器也将错误地切换至DTX模式。
一种用于处理上述状况的现有技术提议在以下的示例2中进行了描述。
示例2
1 if((sub(frame_type，RX_SID_FIRST)＝＝0)||
2 (sub(frame_type，RX_SID_UPDATE)＝＝0)||
3 (sub(frame_type，RX_SID_BAD)＝＝0)||
4 ((sub(frame_type，RX_NO_DATA)＝＝0)&&
4b (sub(st-＞dtxGlobalState，SPEECH)！＝0)))
5 {
6 encState＝DTX； move16()；
7 }else
8 {
9 encState＝SPEECH； move16()；
10 }
尽管在上述4b行中的文本确保了可能插入在活跃语音的片段中间的NO_DATA并不导致错误地切换至DTX状态，但是这仍然没有完全解决会对插入的NO_DATA帧进行错误处理这一问题。
第三代合作伙伴计划(3GPP)核心网中的TFO和TrFO以及服务(诸如VoIP服务)中的接收机逻辑可以利用传输码RX_NO_DATA将传递至语音编码器的空帧或空分组注入自适应多速率宽带(AMR-WB)比特流中。换言之，活跃的语音比特流偶尔可以包含空帧或空分组。这些空帧或空分组通常用于其他目的。例如，这种帧或分组通常被诸如TFO/TrFO信令或其他系统级信令之类的紧急信令数据所替换。为了避免解码器将这种“非语音”数据帧/分组作为语音帧/分组处理，将其标记为RX_NO_DATA。在接收RX_NO_DATA帧的另一示例中，沿传输路径丢失或损坏的帧可以例如由某个中间实体替换为RX_NO_DATA帧。
在启用非连续传输(DTX)操作的情况下，当AMR-WB解码器接收活跃语音的片段中的RX_NO_DATA帧时，根据TS 26.173 v7.0.0(定点实现)和TS 26.204 v7.0.0(浮点实现)的AMR-WB解码器实现可以静默(mute)或衰减语音合成的输出，有时可以长达100ms的时段。此输出的静默或衰减引起与显著的语音质量下降有关的问题。
根据TS 26.193 v7.0.0(即“Source controlled rate operation”)的既定AMR-WB解码器功能注意到：在解码器处于SPEECH(语音)模式中时，从DTX处理器的角度来看，接收的NO_DATA帧应当作为SPEECH_LOST(语音丢失)帧来处理。具体而言，TS 26.193 v7.0.0记载有“如果RX DTX处理器处于模式SPEECH，则应当按照3GPP TS26.191中定义的那样来替代或静默被分类为SPEECH_DEGRADED(语音下降)、SPEECH_BAD(不良语音)、SPEECH_LOST(语音丢失)或NO_DATA(无数据)的帧。分类为NO_DATA的帧应当与不具有有效语音信息的SPEECH_LOST帧相类似地进行处理。”
可能期待AMR-WB解码器变得更具鲁棒性，以便其能够处理可以由网络创建的或可以由终端/网关中的实现创建的任何帧类型输入组合。然而，在DTX同步的情况中出现了某些问题。AMR-WB编码器具有检测不活跃语音的语音活动性检测(VAD)功能，并且为了指示包含不活跃语音的帧，AMR-WB编码器相应地将VAD标志设置为0。在8个帧的DTX拖尾(hangover)时段之后，调用非连续传输(DTX)功能，在该DTX拖尾时段期间，确定舒适噪音参数。针对此DTX拖尾，解码器需要与编码器同步。如果解码器没有与编码器完全同步，则在解码器中的舒适噪音计算将不能与编码器对准。
传统上，所接收的NO_DATA帧被简单地分类为属于DTX时段的帧，即，指示不存在传输。然而，在这种情况下会产生问题，因为，尽管发射机或网络正在发射信令帧，而DTX同步逻辑却没有对准。在接收到包含舒适噪音参数的第一静音描述符(SID)之后，该同步被恢复。另一方面，当NO_DATA帧被分类为活跃语音比特流的一部分并且由SPEECH_LOST帧类型(并由此由解码器中的错误隐藏操作)替换时，针对DTX处理会产生问题。例如，如果接收机已经丢失了SID_FIRST帧(DTX时段的第一帧)，则该NO_DATA帧被错误地分类为丢失语音帧。在接收到下一个SID_UPDATE之后，该同步被再次恢复。
在定点AMR-WB参考实现(3GPP TS 26.173)中，此DTX同步的处理以C代码实现，如以下的示例1所示(源文件“dtx.c”中的函数“rx_dtx_handler”)。
示例1
1 if((sub(frame_type，RX_SID_FIRST)＝＝0)||
2 (sub(frame_type，RX_SID_UPDATE)＝＝0)||
3 (sub(frame_type，RX_SID_BAD)＝＝0)||
4 (sub(frame_type，RX_NO_DATA)＝＝0))
5 {
6 encState＝DTX； move16()；
7 }else
8 {
9 encState＝SPEECH； move16()；
10 }
在上述第1-3行，该算法检查该帧是SID_FIRST帧、SID_UPDATE帧还是受损的SID帧。在第4行，该算法确定此帧是否是NO_DATA帧。如果这些条件中的一个或多个为真，则解码器切换至(或停留在)DTX状态。基于此源代码片段，可见，如果在活跃语音的片段中间插入NO_DATA帧(替代丢弃语音帧)来为信令数据腾出空间，则即使校正动作应该停留在语音状态中，解码器也将错误地切换至DTX模式。
一种用于处理上述状况的现有技术提议在以下的示例2中进行了描述。
示例2
1 if((sub(frame_type，RX_SID_FIRST)＝＝0)||
2 (sub(frame_type，RX_SID_UPDATE)＝＝0)||
3 (sub(frame_type，RX_SID_BAD)＝＝0)||
4 ((sub(frame_type，RX_NO_DATA)＝＝0)&&
4b (sub(st-＞dtxGlobalState，SPEECH)！＝0)))
5 {
6 encState＝DTX； move16()；
7 }else
8 {
9 encState＝SPEECH； move16()；
10 }
尽管在上述4b行中的文本确保了可能插入在活跃语音的片段中间的NO_DATA并不导致错误地切换至DTX状态，但是这仍然没有完全解决会对插入的NO_DATA帧进行错误处理这一问题。
发明内容
本发明的各种实施方式提供了一种用于提供改进的AMR-WBDTX同步的系统和方法。根据各种实施方式，讨论中的AMR-WB比特流包含用于每个所发射帧的VAD标志信息。换言之，在DTX时段将开始(即，接收到SID_FIRST帧)之前的8个帧处，向解码器信号传送关于不活跃语音时段的开始的指示。因此，在VAD标志指示在少于之前的8个帧时活跃语音或该标志被设置为0的情况下，接收的NO_DATA帧可以以高的可靠度被分类为活跃语音，即，被视为发射机、网络或终端发起的信令，并且可以由SPEECH_LOST来替换。在8个帧之前或更早之前时VAD标志被设置为0的情况下，将NO_DATA帧分类为DTX。利用本发明的各种实施方式，AMR-WB接收机针对NO_DATA帧处理更具鲁棒性。本发明的各种实施方式适用于在AMR-WB解码器中使用，并且尤其适用于在DTX舒适噪音生成和同步中使用。
通过下述结合附图的具体描述，本发明的这些和其他优点与特征，连同其组织和操作方式都将变得明显，其中贯穿下述若干附图，相同附图标记表示相同元素。
通过下述结合附图的具体描述，本发明的这些和其他优点与特征，连同其组织和操作方式都将变得明显，其中贯穿下述若干附图，相同附图标记表示相同元素。
附图说明
图1是本发明的各种实施方式可以在其中实现的系统的概括图；
图2是示出了可以实现本发明的各种实施方式的过程的流程图；
图3是可以与本发明的各种实施方式的实现结合使用的电子设备的透视图；以及
图4是可以包括在图3的电子设备中的电路的示意性表示。
图2是示出了可以实现本发明的各种实施方式的过程的流程图；
图3是可以与本发明的各种实施方式的实现结合使用的电子设备的透视图；以及
图4是可以包括在图3的电子设备中的电路的示意性表示。
具体实施方式
本发明的各种实施方式提供了一种用于提供改进的AMR-WBDTX同步的系统和方法。根据各种实施方式，讨论中的AMR-WB比特流包含用于每个所发射帧的VAD标志信息。换言之，在DTX时段将开始(即，接收到SID_FIRST帧)之前的8个帧处，向解码器信号传送关于不活跃语音时段的开始的指示。因此，在VAD标志指示在少于之前的8个帧时活跃语音或该标志被设置为0的情况下，接收的NO_DATA帧可以以高的可靠度被分类为活跃语音，即，被视为发射机、网络或终端发起的信令，并且可以由SPEECH_LOST来替换。在8个帧之前或更早之前时VAD标志被设置为0的情况下，将NO_DATA帧分类为DTX。
图1是本发明的各种实施方式可以在其中实现的通用多媒体通信系统的图形化表示。如图1所示，数据源100以模拟、未压缩数字式、或压缩数字格式或这些格式的任意组合提供源信号。编码器110将源信号编码成已编码媒体比特流。应当注意，待解码的比特流可以直接或间接从虚拟地位于任何类型的网络中的远程设备接收。另外，该比特流可以从本地硬件或软件接收。编码器110能够对多于一个的媒体类型进行编码，或者可能需要多于一个的编码器110以对源信号的不同媒体类型进行编码。编码器110还可以得到合成产生的输入，诸如图形和文本，或者其能够产生合成媒体的已编码比特流。在下文中，仅考虑对一个媒体类型的一个已编码媒体比特流进行处理，以便简化描述。然而，应当注意的是，通常实时广播服务包括若干流(通常，至少一个音频、视频和文本字幕流)。还应当注意的是，系统可以包括很多编码器，但是在图1中，不失一般性地，仅表示一个编码器110，以简化描述。还应当进一步理解，尽管在此包含的文本和示例可能具体描述了编码过程，但是本领域技术人员能够理解，相同的概念和原理也可以应用于相应的解码过程，反之亦然。
已编码媒体比特流式传输至存储设备120。存储设备120可以包括任何类型的海量存储器，以存储已编码的媒体比特流。存储设备120中已编码媒体比特流的格式可以是基本自给的(elementaryself-contained)比特流格式，或者一个或多个已编码比特流可以封装至容器文件中。某些系统“现场”操作，即，省略存储设备，而直接将已编码媒体比特流从编码器110传输至发送器130。已编码媒体比特流随后传输至发送器130，根据需要，也称为服务器。在传输中使用的格式可以是基本自给的比特流格式、分组流格式，或者一个或多个已编码媒体比特流可以封装至容器文件中。编码器110、存储设备120和发送器130可以驻留于同一物理设备中，或者它们可以包括在分离的设备中。编码器110和发送器130可以利用直播实时内容进行操作，在该情况下，已编码媒体比特流通常不会永久存储，而是在内容编码器110和/或发送器130中缓冲一小段时间，以平滑处理延迟、传输延迟和已编码媒体比特速率的变化。
发送器130使用通信协议栈来发送已编码媒体比特流。栈可以包括但不限于实时传输协议(RTP)、用户数据报协议(UDP)和互联网协议(IP)，不过还应当注意，3GPP电路交换电话也可以在本发明各种实施方式的上下文中使用。当通信协议是面向分组的时候，发送器130将已编码媒体流封装至分组中。例如，当使用RTP时，发送器130根据RTP净荷格式将已编码媒体比特流封装至RTP分组中。通常，每个媒体类型具有专用RTP净荷格式。再次需要注意，系统可以包含多于一个的发送器130，但是为了简化，以下描述仅考虑一个发送器130。
发送器130可以或可以不通过通信网络连接至网关140。网关140可以执行不同类型的功能，诸如将根据一个通信协议栈的分组流转译成另一通信协议栈，合并以及分流数据流，以及根据下行链路和/或接收机的能力操纵数据流，诸如控制根据流行的下行链路网络条件控制转发的比特流的比特速率。网关140的示例包括MCU、电路交换和分组交换视频电话之间的网关、一键通话(PoC)服务器、手持数字视频广播(DVB-H)系统的IP封装器，或者将本地广播传输转发到家庭无线网络的机顶盒。当使用RTP时，网关140被称为RTP混合器或RTP转译器，并且典型地充当RTP连接的端点。
系统包括一个或者多个接收机150，其通常能够接收、解调已传输的信号，以及将其解封装为已编码的媒体比特流。已编码媒体比特流被传输至记录存储155。记录存储155可以包括用于存储已编码媒体比特流的任何类型海量存储器。备选地或者附加地，记录存储155可以包括计算存储器，诸如随机访问存储器。记录存储155中的已编码媒体比特流的格式可以是基本自给的比特流格式，或者一个或多个已编码媒体比特流可以封装至容器文件。如果存在彼此相关联的多个已编码媒体比特流，则通常使用容器文件，并且接收机150包括或者附接至根据输入流产生容器文件的容器文件生成器。某些系统“现场”操作，即，省略记录存储155，而直接从接收机150将已编码媒体比特流传输至解码器160。在某些系统中，仅在记录存储155中维护已记录流的最新部分(例如，已记录流的最近10分钟摘录)，而从记录存储155中丢弃任何先前记录的数据。
已编码媒体比特流从记录存储155向解码器160传输。如果存在彼此相关联并且封装至容器文件的多个已编码媒体比特流，则文件解析器(附图中未示出)用于从该容器文件解封装每个已编码媒体比特流。记录存储155或解码器160可以包括文件解析器，或者文件解析器附接至记录存储155或解码器160。
已编码媒体比特流通常进一步由解码器160处理，其输出是一个或者多个未压缩的媒体流。最后，呈现器170可以例如通过扬声器重现未压缩的媒体流。接收机150、记录存储155、解码器160和呈现器170可以驻留于同一物理设备中，或者它们可以被包含在分离的设备中。
根据各种实施方式，当AMR-WB解码器接收NO_DATA帧/分组时，该解码器检查VAD标志的状态和相应的DTX拖尾状态。AMR-WB具有8帧的DTX拖尾。因此，在VAD标志被设置为0时，该解码器期望接收作为第8个帧的SID_FIRST。由于解码器已经记录了VAD标志历史，即，具有不活跃语音的连续帧数量，则解码器可以估计那个应当包含SID_FIRST和NO_DATA帧的帧。此过程的表示如下：
如果vad_hist＜8
NO_DATA帧被视为SPEECH_LOST
信令包括在比特流中
不需要DTX拖尾信息更新
否则
NO_DATA帧被视为DTX
需要更新DTX拖尾信息
为了将上述功能包括在定点3GPP AMR-WB参考实现(3GPP TS26.173)中，可以使用对之前讨论的示例2的源代码的片段的进一步修改，该修改在以下示例3中描述。
示例3
1 if((sub(frame_type，RX_SID_FIRST)＝＝0)||
2 (sub(frame_type，RX_SID_UPDATE)＝＝0)||
3 (sub(frame_type，RX_SID_BAD)＝＝0)||
4 ((sub(frame_type，RX_NO_DATA)＝＝0)&&
4b ((sub(st-＞dtxGlobalState，SPEECH)！＝0)||
4c (sub(vad_hist，DTX_HANG_CONST)＞＝0))))
5 {
6 encState＝DTX； move16()；
7 }else
8 {
9 encState＝SPEECH； move16()；
10 }
行4b和4c的源代码用于确保：只有在AMR-WB比特流中接收的VAD标志指示拖尾时段结束，即，如果当前帧是接收的VAD指示从活跃语音改变到不活跃语音之后的第8个帧的时候，NO_DATA帧才会触发从语音状态到DTX状态的切换。此外，可变的vad_hist指示接收的(连续)语音帧的数量，这些语音帧的VAD标志被设置为0。此值的取值可以例如在函数“decoder”(在文件“dec_main.c”中)中计算，并作为附加参数传递给函数“rx_dtx_handler”，或者在函数“rx_dtx_handler”(假设用于计算此值所需的信息可用)内部计算，以便支持对示例3的行4c的“if”声明的估计。
图2是示出了可以实现本发明的各种实施方式的过程的流程图。在图2的200处，音频内容的各个帧被编码为比特流。这多个帧的每一个例如通过使用VAD标志来包括关于每个相应帧是代表活跃语音还是代表其他音频的指示。在210处，解码器接收多个帧。在220处，接收具有无数据包含于其中的指示的指示的帧，即，该帧是NO_DATA帧。在230处，确定在前的预定数量(在图2中由X表示)的帧的至少一个是否包括各自帧代表活跃音频或语音的指示。如以上所讨论的，此预定数量的帧在一个实施方式中共包括8个帧。如果在前的预定数量的帧的至少一个包括各自帧代表活跃音频的指示，则在240处，将附加帧分类为代表活跃音频。在这种情况下，在250处，NO_DATA帧可以用SPEECH_LOST帧替换。另一方面，如果在前的预定数量的帧都不包括各自帧代表活跃音频的指示，则在260处，将NO_DATA帧分类为DTX，指示非连续传输。
图3和图4示出了本发明可以在其中实现的一个代表性移动设备12。然而，应当理解的是，本发明不旨在限于一种特定类型的电子设备。图3和图4的移动设备12包括外壳30、液晶显示器形式的显示器32、小键盘34、麦克风36、耳机38、电池40、红外端口42、天线44、根据本发明一个实施例的UICC形式的智能卡46、读卡器48、无线接口电路52、编解码器电路54、控制器56以及存储器58。单独的电路和元件可以是本领域公知的所有类型，例如Nokia范围内的移动电话系列。
在方法步骤或过程的通常背景下对本发明的各种实施方式进行了描述，在一个实施例中，这些方法步骤或过程可以通过包含在计算机可读介质中的计算机程序产品来实现，该计算机程序产品包括在网络环境中由计算机执行的计算机可执行指令，诸如程序代码。通常，程序模块可以包括例程、程序、对象、组件、数据结构等，用于执行特定任务或者实现特定的抽象数据类型。计算机可执行指令、相关联的数据结构和程序模块代表了用于执行此处公开的方法的步骤的程序代码的示例。这种可执行指令或者相关联的数据结构的特定序列代表了用于实现在这种步骤或过程中描述的功能的对应动作的示例。
本发明各种实施方式的软件和web实现能够利用标准编程技术来完成，利用基于规则的逻辑或者其他逻辑来实现各种数据库搜索步骤或过程、相关步骤或过程、比较步骤或过程和决策步骤或过程。还应当注意的是，此处以及下述权利要求书中使用的词语“组件”和“模块”意在包括使用一行或者更多行软件代码的实现和/或硬件实现和/或用于接收手动输入的设备。
出于示例和描述的目的，已经给出了本发明实施方式的前述说明。前述说明并非是穷举性的也并非要将本发明的实施方式限制到所公开的确切形式，根据上述教导还可能存在修改和变形，或者是可能从本发明各种实施方式的实践中得到修改和变形。在这里选择和描述实施方式是为了说明本发明各种实施方式的原理和本质及其实际应用，以使得本领域的技术人员能够以适合于构思的特定用途来以各种实施方式和各种修改而利用本发明。
图1是本发明的各种实施方式可以在其中实现的通用多媒体通信系统的图形化表示。如图1所示，数据源100以模拟、未压缩数字式、或压缩数字格式或这些格式的任意组合提供源信号。编码器110将源信号编码成已编码媒体比特流。应当注意，待解码的比特流可以直接或间接从虚拟地位于任何类型的网络中的远程设备接收。另外，该比特流可以从本地硬件或软件接收。编码器110能够对多于一个的媒体类型进行编码，或者可能需要多于一个的编码器110以对源信号的不同媒体类型进行编码。编码器110还可以得到合成产生的输入，诸如图形和文本，或者其能够产生合成媒体的已编码比特流。在下文中，仅考虑对一个媒体类型的一个已编码媒体比特流进行处理，以便简化描述。然而，应当注意的是，通常实时广播服务包括若干流(通常，至少一个音频、视频和文本字幕流)。还应当注意的是，系统可以包括很多编码器，但是在图1中，不失一般性地，仅表示一个编码器110，以简化描述。还应当进一步理解，尽管在此包含的文本和示例可能具体描述了编码过程，但是本领域技术人员能够理解，相同的概念和原理也可以应用于相应的解码过程，反之亦然。
已编码媒体比特流式传输至存储设备120。存储设备120可以包括任何类型的海量存储器，以存储已编码的媒体比特流。存储设备120中已编码媒体比特流的格式可以是基本自给的(elementaryself-contained)比特流格式，或者一个或多个已编码比特流可以封装至容器文件中。某些系统“现场”操作，即，省略存储设备，而直接将已编码媒体比特流从编码器110传输至发送器130。已编码媒体比特流随后传输至发送器130，根据需要，也称为服务器。在传输中使用的格式可以是基本自给的比特流格式、分组流格式，或者一个或多个已编码媒体比特流可以封装至容器文件中。编码器110、存储设备120和发送器130可以驻留于同一物理设备中，或者它们可以包括在分离的设备中。编码器110和发送器130可以利用直播实时内容进行操作，在该情况下，已编码媒体比特流通常不会永久存储，而是在内容编码器110和/或发送器130中缓冲一小段时间，以平滑处理延迟、传输延迟和已编码媒体比特速率的变化。
发送器130使用通信协议栈来发送已编码媒体比特流。栈可以包括但不限于实时传输协议(RTP)、用户数据报协议(UDP)和互联网协议(IP)，不过还应当注意，3GPP电路交换电话也可以在本发明各种实施方式的上下文中使用。当通信协议是面向分组的时候，发送器130将已编码媒体流封装至分组中。例如，当使用RTP时，发送器130根据RTP净荷格式将已编码媒体比特流封装至RTP分组中。通常，每个媒体类型具有专用RTP净荷格式。再次需要注意，系统可以包含多于一个的发送器130，但是为了简化，以下描述仅考虑一个发送器130。
发送器130可以或可以不通过通信网络连接至网关140。网关140可以执行不同类型的功能，诸如将根据一个通信协议栈的分组流转译成另一通信协议栈，合并以及分流数据流，以及根据下行链路和/或接收机的能力操纵数据流，诸如控制根据流行的下行链路网络条件控制转发的比特流的比特速率。网关140的示例包括MCU、电路交换和分组交换视频电话之间的网关、一键通话(PoC)服务器、手持数字视频广播(DVB-H)系统的IP封装器，或者将本地广播传输转发到家庭无线网络的机顶盒。当使用RTP时，网关140被称为RTP混合器或RTP转译器，并且典型地充当RTP连接的端点。
系统包括一个或者多个接收机150，其通常能够接收、解调已传输的信号，以及将其解封装为已编码的媒体比特流。已编码媒体比特流被传输至记录存储155。记录存储155可以包括用于存储已编码媒体比特流的任何类型海量存储器。备选地或者附加地，记录存储155可以包括计算存储器，诸如随机访问存储器。记录存储155中的已编码媒体比特流的格式可以是基本自给的比特流格式，或者一个或多个已编码媒体比特流可以封装至容器文件。如果存在彼此相关联的多个已编码媒体比特流，则通常使用容器文件，并且接收机150包括或者附接至根据输入流产生容器文件的容器文件生成器。某些系统“现场”操作，即，省略记录存储155，而直接从接收机150将已编码媒体比特流传输至解码器160。在某些系统中，仅在记录存储155中维护已记录流的最新部分(例如，已记录流的最近10分钟摘录)，而从记录存储155中丢弃任何先前记录的数据。
已编码媒体比特流从记录存储155向解码器160传输。如果存在彼此相关联并且封装至容器文件的多个已编码媒体比特流，则文件解析器(附图中未示出)用于从该容器文件解封装每个已编码媒体比特流。记录存储155或解码器160可以包括文件解析器，或者文件解析器附接至记录存储155或解码器160。
已编码媒体比特流通常进一步由解码器160处理，其输出是一个或者多个未压缩的媒体流。最后，呈现器170可以例如通过扬声器重现未压缩的媒体流。接收机150、记录存储155、解码器160和呈现器170可以驻留于同一物理设备中，或者它们可以被包含在分离的设备中。
根据各种实施方式，当AMR-WB解码器接收NO_DATA帧/分组时，该解码器检查VAD标志的状态和相应的DTX拖尾状态。AMR-WB具有8帧的DTX拖尾。因此，在VAD标志被设置为0时，该解码器期望接收作为第8个帧的SID_FIRST。由于解码器已经记录了VAD标志历史，即，具有不活跃语音的连续帧数量，则解码器可以估计那个应当包含SID_FIRST和NO_DATA帧的帧。此过程的表示如下：
如果vad_hist＜8
NO_DATA帧被视为SPEECH_LOST
信令包括在比特流中
不需要DTX拖尾信息更新
否则
NO_DATA帧被视为DTX
需要更新DTX拖尾信息
为了将上述功能包括在定点3GPP AMR-WB参考实现(3GPP TS26.173)中，可以使用对之前讨论的示例2的源代码的片段的进一步修改，该修改在以下示例3中描述。
示例3
1 if((sub(frame_type，RX_SID_FIRST)＝＝0)||
2 (sub(frame_type，RX_SID_UPDATE)＝＝0)||
3 (sub(frame_type，RX_SID_BAD)＝＝0)||
4 ((sub(frame_type，RX_NO_DATA)＝＝0)&&
4b ((sub(st-＞dtxGlobalState，SPEECH)！＝0)||
4c (sub(vad_hist，DTX_HANG_CONST)＞＝0))))
5 {
6 encState＝DTX； move16()；
7 }else
8 {
9 encState＝SPEECH； move16()；
10 }
行4b和4c的源代码用于确保：只有在AMR-WB比特流中接收的VAD标志指示拖尾时段结束，即，如果当前帧是接收的VAD指示从活跃语音改变到不活跃语音之后的第8个帧的时候，NO_DATA帧才会触发从语音状态到DTX状态的切换。此外，可变的vad_hist指示接收的(连续)语音帧的数量，这些语音帧的VAD标志被设置为0。此值的取值可以例如在函数“decoder”(在文件“dec_main.c”中)中计算，并作为附加参数传递给函数“rx_dtx_handler”，或者在函数“rx_dtx_handler”(假设用于计算此值所需的信息可用)内部计算，以便支持对示例3的行4c的“if”声明的估计。
图2是示出了可以实现本发明的各种实施方式的过程的流程图。在图2的200处，音频内容的各个帧被编码为比特流。这多个帧的每一个例如通过使用VAD标志来包括关于每个相应帧是代表活跃语音还是代表其他音频的指示。在210处，解码器接收多个帧。在220处，接收具有无数据包含于其中的指示的指示的帧，即，该帧是NO_DATA帧。在230处，确定在前的预定数量(在图2中由X表示)的帧的至少一个是否包括各自帧代表活跃音频或语音的指示。如以上所讨论的，此预定数量的帧在一个实施方式中共包括8个帧。如果在前的预定数量的帧的至少一个包括各自帧代表活跃音频的指示，则在240处，将附加帧分类为代表活跃音频。在这种情况下，在250处，NO_DATA帧可以用SPEECH_LOST帧替换。另一方面，如果在前的预定数量的帧都不包括各自帧代表活跃音频的指示，则在260处，将NO_DATA帧分类为DTX，指示非连续传输。
图3和图4示出了本发明可以在其中实现的一个代表性移动设备12。然而，应当理解的是，本发明不旨在限于一种特定类型的电子设备。图3和图4的移动设备12包括外壳30、液晶显示器形式的显示器32、小键盘34、麦克风36、耳机38、电池40、红外端口42、天线44、根据本发明一个实施例的UICC形式的智能卡46、读卡器48、无线接口电路52、编解码器电路54、控制器56以及存储器58。单独的电路和元件可以是本领域公知的所有类型，例如Nokia范围内的移动电话系列。
在方法步骤或过程的通常背景下对本发明的各种实施方式进行了描述，在一个实施例中，这些方法步骤或过程可以通过包含在计算机可读介质中的计算机程序产品来实现，该计算机程序产品包括在网络环境中由计算机执行的计算机可执行指令，诸如程序代码。通常，程序模块可以包括例程、程序、对象、组件、数据结构等，用于执行特定任务或者实现特定的抽象数据类型。计算机可执行指令、相关联的数据结构和程序模块代表了用于执行此处公开的方法的步骤的程序代码的示例。这种可执行指令或者相关联的数据结构的特定序列代表了用于实现在这种步骤或过程中描述的功能的对应动作的示例。
本发明各种实施方式的软件和web实现能够利用标准编程技术来完成，利用基于规则的逻辑或者其他逻辑来实现各种数据库搜索步骤或过程、相关步骤或过程、比较步骤或过程和决策步骤或过程。还应当注意的是，此处以及下述权利要求书中使用的词语“组件”和“模块”意在包括使用一行或者更多行软件代码的实现和/或硬件实现和/或用于接收手动输入的设备。
出于示例和描述的目的，已经给出了本发明实施方式的前述说明。前述说明并非是穷举性的也并非要将本发明的实施方式限制到所公开的确切形式，根据上述教导还可能存在修改和变形，或者是可能从本发明各种实施方式的实践中得到修改和变形。在这里选择和描述实施方式是为了说明本发明各种实施方式的原理和本质及其实际应用，以使得本领域的技术人员能够以适合于构思的特定用途来以各种实施方式和各种修改而利用本发明。