分配执行具有可配置复杂度的多媒体数据处理组件的处理器的资源的制作方法
【专利说明】分配执行具有可配置复杂度的多媒体数据处理组件的处理器 的资源
【背景技术】
[0001] 现代音频和视频处理组件(诸如编码器、解码器、回波抵消器、降噪器、抗混叠滤波 器等)通常能够通过采用更复杂的音频/视频算法处理操作来实现更高的输出音频/视频质 量。这些操作典型地由计算系统的处理器(例如，CPU)执行的一个或多个软件应用来实现。 应用可以包括多个代码组件(例如，单独的音频和视频处理组件），其中每个代码组件均实 现单独的处理算法。本上下文中的处理器资源管理涉及使得这些算法的复杂度适应这种处 理器的处理能力。如本文所使用的、用于实现算法的代码组件的"复杂度"是指基础算法 (underlying algorithm)的时间算法复杂度。如本领域公知的，算法的时间复杂度是该算 法的固有特性，其确定该算法处理任何给定输入所需的多个基本操作，其中，相比于不太错 综复杂的算法，更复杂的算法要求要求每输入的更多的基本处理操作。因此，该提高的质量 以更复杂的、更高质量的算法为代价，该更复杂的、更高质量的算法要求更多的时间来处理 每个输入，或者这些算法要求更多的处理器资源，并且如果它们要以相当于不太复杂的、较 低质量的处理算法的速率处理输入数据，则从而导致更高的CHJ负荷。
[0002] 对于"实时"数据处理，诸如在由通信客户端应用的实时音频/视频代码构件实现 的音频/视频会议的上下文中对音频/视频数据的处理，输出的质量不是唯一考虑:这些算 法操作"实时"地结束也是严格必需的。如本文所使用的，一般而言，"实时"数据处理是指以 至少与接收输入数据的输入速率一样快的速率对输入数据流的处理（即，使得如果在一毫 秒内接收到N个比特，则对这N个比特的处理所花费的时间必须不多于一毫秒"实时操作" 是指满足该标准的处理操作。因此，允许更复杂的算法具有更多的处理时间不是一个选项， 这是因为算法仅具有在其中要处理流的N个比特的有限窗口，该窗口从接收到该N个比特的 时间和接收到该流中下N个比特的时间而运行一一如果要保持实时操作，则处理N个比特所 需的算法操作都必需在该窗口内执行且不能推迟。因此，如果要保持实时操作，随着代码组 件复杂度增加，代码组件要求更多的处理器资源。此外，如果CPU负荷增加至超过某个 点一一例如，由于运行过于复杂的音频/视频处理算法一一则实时操作将是不可能的，这是 因为音频和/或视频组件将为了实时操作而需要比实际上可供使用的处理器资源更多的处 理器资源。因此，在一方面最大化输出质量与另一方面保留实时操作之间存在折中。
[0003] 具体地在音频/视频处理的上下文中，原始音频和视频数据按部分地进行处理，然 后被打包传输。每个音频数据部分可以是(例如）音频的20ms的音频帧;每个视频数据部分 可以是（例如)包括图像序列中的单个捕获的图像的视频帧。为了保持实时操作，对音频帧 的处理应当在完成对下一音频诊断的捕获之前结束;否则，后续的音频帧将被缓存，并且在 计算系统中引入了增加的延迟。同样，基于相同的原因，对视频帧的处理应当在捕获下一视 频帧之前结束。对于过于复杂的音频/视频算法，处理器可能不具有足够对其进行实现的资 源。
【发明内容】
[0004] 提供该概述以便以简化的形式引入对构思的选择，以下在详细描述中将对其进一 步描述。该概述不旨在标识出权利要求主题的关键特征或主要特征，也不旨在用于限制权 利要求主题的范围。
[0005] 根据第一方面，本公开内容涉及一种分配处理器资源的方法，该处理器执行用于 处理第一序列的数据部分的第一实时代码组件和用于处理第二序列的数据部分的第二代 码组件。至少该第二代码组件具有可配置复杂度。该方法包括:估计针对该第一代码组件的 第一实时性能度量，以及基于所估计的第一实时性能度量来配置该第二代码组件的复杂 度。
[0006] 通过如此配置所述复杂度，处理器的处理资源有效地以对于第一组件的实时性能 要求敏感的方式分配给第二代码组件。在实施例中，第二实时组件也可以是实时组件，但是 这不是必需的。
[0007] 第一数据序列和第二数据序列可以是不同类型的数据。例如，第一序列可以是音 频数据帧序列，第二序列可以是视频数据帧序列，第一代码组件是实现音频编码算法的音 频代码组件，而第二代码组件是实现视频编码算法的视频组件(或者反之亦然）。
【附图说明】
[0008] 为了更好地理解所描述的实施例以及示出如何实现所描述的实施例，将通过示例 的方式参照以下附图，在以下附图中：
[0009]图1示出了通信系统的示意图；
[0010] 图2是用户设备的示意性框图；
[0011] 图3A是音频和视频处理的示意性框图；
[0012]图3B是在图3A之后的时间的、首频和视频处理的不意性框图；
[0013] 图4是示出了处理器资源管理的示意性框图。
【具体实施方式】
[0014] 为辅助理解，考虑以下示例是有用的：假设未处理的音频帧包括N个样本，每个具 有Μ比特。第一最基本的下采样算法可能仅起到通过在每隔一个样本进行'跳过'来简单地 将多个样本取半的作用。另一方面，第二略微更复杂的下采样算法可以执行对音频帧的低 通滤波(例如，使用适合的正弦滤波器）以在每隔一个滤波后样本进行'跳过'之前适当地减 小信号带宽。第二算法比第一算法更复杂，因为一般而言，对于每个样本来说需要相同数量 的基本操作来执行'跳过'步骤，而执行第二方法的额外滤波步骤需要额外的基本操作。因 此，当处理音频数据流时，第二算法将需要比第一算法更多的处理器资源来保持实时操作， 但是如本领域公知的，根据奈奎斯特(Nyquist)采样定理，一般预期第二算法将实现比第一 算法高的输出质量。尽管如此，但是如果该增加的质量是以折衷的实时操作为代价的(这是 由于没有可用于实时地处置第二算法的额外操作的充足资源而导致的），则在实时上下文 中，期望的是通过使用第一算法使得质量降级而不是利用第二算法来遭遇累积的延迟。当 然，将意识到的是，这是仅出于示例的目的的极度简化的示例(实际上，现代的CPU足够快而 使得LP滤波不是实际存在的问题）。
[0015] -种控制系统负荷的方式是在实际应用调用之前运行基准测试，并且关于与实时 代码组件相关的复杂度来配置应用的实时代码组件(诸如实时音频和视频处理代码组件）， BP，将复杂度设定在最大化质量而在运行时(run-time)之前不折衷实时操作的水平。然而， 该方法不能适应变化的条件，诸如由于过热导致的CHJ时钟频率降低，或者其它应用启动或 停止，从而减少或释放出可用的系统资源。
[0016] 这可以通过监测由操作系统(0S)报告的系统CPU负荷，以及调节算法复杂度以保 持系统负荷低于某预规定目标(例如95% )来防止。然而，保持系统负荷低于某预规定目标 很难，这是因为不可能选择这样的预规定目标:其确保跨越不同系统的实时操作、其不会在 至少一些系统上导致不必要地折衷的质量。这是因为，在某些系统上，在 CPU负荷低至（例 如)60 %时实时操作可能折衷，而其它系统可能负载至(例如)99 %而没有任何问题。因此， 目标需要预设为(例如)60%以确保跨大多数系统的实时操作，这意味着那些在不折衷实时 操作的情况下能够负载至高于60 %并从而实现更高的质量的系统是利用不足的 (underutilized)，从而使得质量不必要地降级。而且，额外的难题是，某些计算设备甚至不 能够首先报告系统负荷。
[0017] 另一选项将基于以下技术来"动态"调节计算复杂度:通过该技术，（例如）音频编 码复杂度是基于监视相对于目标来说对每个音频帧进行编码所花费的时间(这指示处理器 资源使用情况)来调节的。
[0018] 也就是说，可以通过以下各项来管理资源:监控代码组件，以确定是否该代码组件 正使用处理器资源达到了折衷其自身实时操作的程度（即，确定实时操作将需要更多可用 的资源），或者确定正在欠使用处理器资源（即，确定组件可以占用更多的资源，并从而实现 更高的输出质量，而不折衷其自身的实时操作），以及根据所确定的处理器资源使用情况来 重新配置该代码组件的复杂度。
[0019] 然而，发明人已经认识到，这种技术由于以下原因而有缺陷。由于同时执行的、实 现不同功能(诸如音频编码、视频编码等）的实时代码组件共享相同的处理器资源，因此当 第一组件（例如，音频)经历实时问题时，可能实际上更为适当的是降低另一第二组件（例 如，视频）的复杂度从而减少第二组件所需的资源量并且因此释放出资源以供第一组件使 用，而不是降低第一组件自身的复杂度。例如，在视频电话场景中（其中音频和视频必需被 捕获且被实时处理以通过网络传输），重要的可能是保持高质量音频，甚至以降低视频质量 为代价（以以下情况为基础:对电话参与者来说，相比于清楚地看到彼此，清楚地听到彼此 更为重要）。也就是说，将视频质量降级至有利于保持音频质量的程度是可接受的。
[0020] 而且，如果多个组件要同时实现该技术，则将是多个组件彼此'战斗'（即，多个组 件均'盲目地'试图将它们的个体负荷推高至例如0.95)。这将导致最进取的组件趋于赢得 全部的系统资源，或者，如果所有组件是同等进取的，则可能导致如下振荡：自由的系统