Directshow RTP对网络多媒体应用适配的支持(二)

3． DirectShow RTP 适配 DirectShow允许一个程序员编写多媒体程序时不必考虑媒体的处理细节。DirectShow RTP拓展了这种架构以采用RTP协议支持NetMM应用。为了支持适配，DirectShow需要做出几处改变。组件被用来度量和监控多媒体流的分发和显示的服务质量，测定在不利条件这些流任何出现质量下降的原因，对这些条件的初始适配，和测定是否适配针对流的分发和展现，达到了预期的改进效果。同样必要的是开发一套决定同一程序或同一主机不同应用程序不同流相对的优先级系统。 DirectShow架构支持允许一个filter graph 适配影响它加载的流不利条件这样一套机制。这种机制是基于质量消息（quality messages）的产生和解释。Quality messages指出当数据被过快生成和过慢被graph中filters吸收时的情景。Quality messages在filter graph中在与数据流相反的方向传播。这是每个filter向上传递消息以前尝试保存状态到quality messages的责任。为标识流的爆发或枯竭的严重程度，quality messages包含一个字段，用来标识一个逆流而上的filter应该改变码流的比例。除了一些默认行为quality messages的分发, 同样可能的是配置filter，分发这些消息到其它系统组件中。这允许DirectShow支持两种模式的适配。默认的模式，包含向上传递的质量消息，允许流内方式的适配。重新路由这些消息到一个变化的接收者需要一个适配控制器集中适配控制多个流。这两种quality message 分发方式导致了两种不同的在DirectShow RTP架构中添加适配支持的方法。 3．1 流内方式 （Quality Control） Video Capture Codec Packetizer RTP Render Data Flow 图4：DirectShow 流内适配 在这种方式中（如图4所示），生成质量控制消息的filter会发送消息到下一个逆向filter。Graph 中每一个filter都可能改变它的输出或不加处理向上传递这个消息。 这种方式有以下特征： 每一filter监控QoS并能够提供性能指示。 每个filter都可能含有解析质量信息并对它做出反映的功能。 适配的任务分布于组件之中并且它们之间的交互是简单的。 然而，这种方式也存在以下缺点： 每个流都单独适配而不是与其它流协作适配。 一个应用无法与其它应用协作分享可用资源。 很难执行比如“在编解码参数设置前适配采集”这种策略。 流内服务质量控制提供了一种简单的，易于执行的机制来获取一个filter graph中不利条件信息并做出反应。然而，这种质量度量方法在事实面前严重受限，它只适应于单个filter graph环境中而不是应用或广义系统的范围。 3．2适配控制途径 为一个filter指定一适配控制器（DirectShow中质量管理器），应用都为它的每个filter pin设置一个质量消息接收入口。如果接收入口已设定，fitlers分发质量消息到接收器而不是向上发送。一个适配控制器可能监控单个filter,一个filter graph中所有filters，一个程序中所有filter graphs,或者甚至是在几个不同应用环境执行的filter graphs。适配控制器采用质量消息进行适配选择。图5列举了一个适配控制器控制两个流，适配控制输入来自两个渲染filters,适配策略的执行通过修改源（采集）和编解码filters的行为得以贯彻。 Video Capture Codec SPH RTP Render Control actions or quality messages Quality control message Audio Capture Codec SPH RTP Render 图5：DirectShow中使用适配控制器适配 一个采用适配控制的架构会引入几个问题。其中一个必须说明的是确定适配控制如何与应用交互。同样必要的是检查适配控制怎样可以以灵活的方式编写，这样可以控制不同种类的组件。最后，对网络和主机不利条件适配策略必须确定。这些策略必须对单filter graph（媒体流）情况和多filter graph情形都具有可行性。应用根据与适配控制器的交互类型，可以分为3个不同种类。这些类别包括应用与适配控制器的适配策略协作，应用只与适配控制器在初始时交互，和应用与适配控制器无直接交互。 与适配控制器交互的应用以DLL的形式加载控制器。在创建filter graph后，应用调用一个适配控制器提供的API来建立可能的连接允许适配控制器适配filter graph。应用正确配置那些可以被适配的filters和被用来适配的策略。 对于那些添加与适配控制器的交互的支持是不可行的应用，可以添加以初始适配控制的形式的小限度级别的支持。这种情况下，应用只需要控制应用为每个filter graph创建的适配控制器的指针。适配控制器解析graph来获取各种接口和以对应用透明的方式与之交互。 最后，对于那些需要适配，但不能直接修改的应用，可以通过添加一个适配代理filter到应用程序的filter graph中来实现。这种技术可以同DirectShow中的以文件形式存储filter graph以备后用的能力一起使用。代理filter无需知道应用的信息就可直接添加到filter graph中。当这个filter graph被初始后，代理filter代表适配控制器贯穿整个filter graph，分发来自其它filters接口和质量消息到适配控制器。 为了做成一个最多有效的利用DirectShow RTP 架构的应用，我们的适配控制器支持所有这三种应用交互。 3．3 控制filters引起适配 这里探讨两种适配控制filter操作方式。其中之一，不直接干涉的适配控制器；相反沿着适合的filter graph逆流向上传输质量消息。适配控制器不必考虑filters和它们的各自的控制方法。然而，我们发现许多filters（像普通的DirectShow 视频采集filter和一般的codecs）不具有处理质量消息的能力。其它的filters对质量消息做出的反应也不是很好，比如MPEG解码filter，在接收到一个爆发消息后会丢弃所有的P和B帧。为DirectShow RTP创建的适配控制器可以在缺少直接利用filters的输出的方式的情况下简单的发送质量消息。然而，这种方式只是在缺少好的控制方式时最后一个办法，因为适配控制器无法知晓质量消息的反馈。 许多filters提供允许适配控制器直接控制它们输出的接口。为了利用这种能力，适配控制利用filters上某些接口来实现适配行为。直接控制每个允许适配的filter的输出，可以选择哪个filter想用来适配，还有适配的程度。这种方式允许适配控制器以比前一种更优美和精确的控制方式适配，那种适配依靠逆流发送一条质量信息，希望某个filter如所期望的那样做出反应。 创建的适配控制引擎提供对两种适配类型的支持。这一引擎为处于一个单独组件一个进程中所有多媒体流集中适配决策。这样产生比默认DirectShow行为更有效的适配能力，那只是为每个filter graph流在不协调时做出适配决策。在下一章节我们讨论两种适配机制，基于源的适配控制和通过分层广播的接收驱动的控制。这篇论文讲述了这些适配机制是如何在我们的基于组件的架构执行，还有这些机制是如何被用来获得网络和主机的适配。 4． 源适配控制 在适配源码流控制（ASRC）中，发送者根据网络资源的变化改变filter的采集帧率和压缩设置等参数来响应。在我们的实践中，我们拓展了ASRC，让也可以适配检测到的本地可用资源的变化。因为DirectShow提供的许多组件缺乏对适配的较好支持，创建新的满足我们需求的组件是必要的。而且，创建一个能够操控每个组件接口，乃至执行ASRC的适配控制器是必要的。 4．1 视频采集filter控制 为了支持适配，视频采集filter必须允许诸如采集帧率等参数和分辨率在不工作时可调。视频采集filter也必须生成含有足够精确可被渲染filter用来生成质量消息的时间戳的media samples。最后，它需要应答来自下游filters的质量消息。 如当前所执行的，改变采集filter中视频采集的帧率或分辨率，需要停止采集，改变采集参数，重新启动采集。当改变采集分辨率时，重启filter时会有一个可觉察的停顿，在一个高速CPU比如P2-200 Pro处理器上视频流中帧率的变化很难被觉察。这一在视频采集过程中的特性告诉我们当需要适配时，通过改变帧率而不是分辨率来调整适配策略。改变采集频率对DirectShow的时间戳影响显著。DirectShow media sample的时间戳是基于采集驱动设置的视频帧中消逝时间值。 Sample start time = Graph start time + Elapsed frame time in video frame 渲染filters根据sample时间戳来确定media samples是否准时到达。当视频采集重启，视频帧中的时间戳值复位为0。合成的DirectShow 时间戳看来比渲染filter还要老。 据观察，几分钟后，视频渲染filters显示samples已延迟，尽管系统负载很低。会有这种问题出现是因为视频采集驱动产生的时间戳逐渐的落后wall时钟时间。视频采集filter从每个视频帧头生成这些时间戳，它们是基于采集设备的时钟源进行赋值的。这种时钟源采用不合适的分辨率和不精确特征引起了和用于视频渲染比较的时钟之间潜在的不一致，导致sample 缓慢这种错误迹象。 为解决这些问题，我们已经修改采集filter，让它使用DirectShow 参考时钟（它是基于更精确的wall时钟源）来生成时间戳，而不是根据视频帧头找到的值。这样排除了重启和延迟问题，等同于下面的sample的起始时间戳赋值： Sample start time = Graph start time + Elapsed wall clock time 除了需要高精确度的时钟用于时间戳生成，还发现采集filter的缓冲管理策略对质量管理至关重要。一旦这个filter用完缓冲，它会抛弃最老的缓冲并把新的视频帧放置于缓存链表头。这意味着渲染filter将获取最新的视频帧而不是那些旧的，无效的缓冲。这使渲染者认为所有的samples都被准时发送，意味着低CPU负载，没必要适配或发送质量消息。一种解决方法是当采集filter用光缓冲后直接采取正确行动而不是依赖于来自下游的质量消息指令来采取行动。如果据此决定丢弃新帧，允许渲染器检测接收到的sample将为时已晚。 为允许视频采集filter在视频控制器缺位的前提下适配，我们修改了采集filter的质量消息提醒功能让它处理这些消息而不是忽略它们。一个下游filter（比如视频渲染）通过质量消息调用这一功能，表示改变sample的发送率是必须的。回应质量消息视频采集的改变是在一个独立线程中实现的，避免在呼叫线程环境做过多处理工作。这样操作是必要的，避免因渲染错误检测进一步引起的延迟，那样有可能会发生渲染者线程被迫代表源filter做过多处理。 4．2 编解码对适配的支持 Filter graph 中的编解码是处理器资源的主要消耗者，因此它成为适配的首选。我们采用的视频的编解码提供了一个控制输出码流和视频质量的接口。适配控制器采用这个接口来影响CPU和网络带宽的占用。我们发现这些接口对我们创建适配控制器的意图非常有用，它能够直接与单个filter交互。 4．3 RTP源和渲染filter适配 允许根据网络和主机条件适配，需要RTP渲染filter的改变，它的任务是网络传输RTP流和监控RTCP报告。这个filter必须生成能够反应它通过RTCP接收器接收渲染流主机的报告的回馈的消息。 一个完成这项任务的方法是允许RTP渲染filter 解析RTCP接收器报告。这种解析将包含反映DirectShow 质量消息部分值的丢失比例的RTCP包的变化。这种方法的缺点是这样限制了改变RTCP包解析和执行各种适配算法的能力。因而，为了添加对基于源网络适配的支持，发送RTCP包到网络适配器同样也是必要的。一个适配控制器能够通过RTP渲染filter支持的一个普通接口截取原始RTCP消息。 为允许发送方主机适配，RTP渲染filter需要生成能够反映本地资源状态，比如CPU这样的质量消息。这一任务可通过RTP render filter继承DirectShow 视频渲染基础类轻松实现。这个基础类支持音视频流质量消息的生成。 4．4 网络适配控制 基于网络的发送适配，对当呼叫发送时可用网络带宽未明时的点对点会议最为有益。多播会议也可以使用发送适配方式，但这是假定主机应用很高的网络带宽。因而当采用多播，ASRC的最佳使用是在可用网络能力比较同质的局域网络会议。在这种环境下，根据发送问题减少发送带宽这种轻量形式的适配方式，比接收驱动层多播方式（RLM）更会产生预期的效果。 网络适配控制采用的算法与Busse et al描述的类似。适配控制器允许应用设定丢失阈值和最低，最高带宽。我们扩展了ASRC概念，添加了设置单个应用中视频流之间的优先级的能力。典型的，这包含为希望减少高优先级流的可见丢失，适配低优先级流。 在我们基于数据源网络适配的执行中，由以下三步组成。就是RTCP分析，网络状态预测和带宽调整。 一旦接收到某个发送方的一条新的RTCP报告，这份新报告被用来校正最初发送RTCP报告接收者丢失的数据包。我们在低通filter中使用a（RTCP最近丢失报告的权重）=0.3 来计算平滑包丢失。每个接收者都在它们展现的参与过程中得以维护。RTCP Bye消息被用来从活动接受者列表中删除接收者。因为这个消息的丢失将导致用来调整决策的不准确。我们计划给每个接收者添加时间戳，来记录和当RTCP包在一个合理的时间内没有到达时驱逐接收者。 基于每个接收者平滑包的丢失，可分为堵塞，加载和卸载几个状态。每个状态维护几个接收者，当每个接收者从一个状态变迁到另一状态，当前一状态的接收者减少，新状态的接受者相应增加。平滑包丢失率超过4％的被视为堵塞（congested），低于2%的视为卸载（unloaded），介于二者之间的被视为加载（loaded）。 根据每个状态接受者的数目，来决定降低、提高或保持目前的比特流。如果超过10%的接收者都处于堵塞状态，我们降低当前网络的比特流使用目标。如果没出现这种情况不过超过10％的接收者处于加载状态（loaded）,我们持续维持目前的比特流。最后，如果不处于这两个条件，我们提高网络的比特流预期。 发送者使用加法提高和乘法降低的算法来调整它们发送数据的比特流。调整码流有两步任务，就如我们发现编解码时偶尔会偏离目标比特流，如果帧运动会引起编解码器剧烈超出设定码流。在这个情况下我们提高采集帧率来达到预期的码流。我们计划加强网络源适配控制来允许用户获取码流和帧率调整的折中。 4．5 主机适配控制 主机适配通过graph中的filter提供的控制接口来初始适配，响应CPU负载变化。这一部分讨论了主机适配控制器如何为发送数据的NetMM应用提供适配。 图2中，我们展示了一个典型的传输视频流的filter graph，包含一个视频采集fiter,一个视频编解码filter，一个RTP SPH，和一个RTP渲染filter。为了为这个filter graph添加适配功能，主机适配控制器配置RTP 渲染filter来分发质量消息至适配控制器而不是逆流发送。分发的质量消息中的比例字段值指定了码流需要改变的程度。这些质量消息被转换为媒体参数可被用来操控视频采集和编解码。这些参数包括编解码流，数据采集比特率，和数据采集方案。改变采集率和方案对CPU和网络带宽耗用有显著影响，但改变编解码比特率对CPU消耗影响甚微。综合这些提供的参数，用于适配过程中用户参数估计。比如，我们执行的一条政策包含特殊改变的路径，描述如下： 如果编解码率超出最低值，减少到最低值。 如果解码率已处于最低值，帧率超出最低值，降低帧率。 如果帧率早已被降到最低值，降低帧品质。 Graph 运行期间改变帧率和比特率非常容易。然而，改变品质是复杂的，因为它改变了用于协商filter连接的DirectShow中的media type。Media types在filters连接组成filter graph时会被协商，然后就确定下来。当DirectShow 不允许media types在运行状态中被改变，许多filter很难能够很快满足这些变化。对于这些filters，有必要采用其它方法来动态改变media type。 H.263和H.261编解码filters属于这类不允许动态改变的filter。除了这些filters，标准视频渲染filters不自动根据media type的改变调整显示大小。为解决网络视频源初始方法的变化，有必要编写一个视频分割器连接一对解码器和视频渲染。分割器根据它们的方法路由media samples，这样这些分发数据流方案的改变对编解码器和渲染器是不可见的。 当media type发生改变，应用必须被通知，这样它可以采用合适的视频渲染filter显示输出。因而，对于某些形式的适配（特别是那些导致用户接口改变的），一个应用能够感知适配是很必要的。 5． 采用层多播的接收驱动适配 我们执行的接收控制依赖于接收驱动层多播（RLM）来取得适配。这种适配类型的机制需要每个压缩层发送到不同的多播IP地址（或单播地址和端口）。在RLM中，根据网络条件比如可用带宽和检测到的损失，添加或丢弃层。我们接收适配也采用RLM来适配主机CPU负载，被处理的各层对处理器负载和总线带宽等系统资源有直接的影响。 为支持RLM，有必要创建新的组件，修改现存的DirectShow组件。我们使用c++类结构机制创建一套支持采用RLM实现网络和主机适配的适配控制器。在这一章节，我们引入该版本的适配控制器和DirectShow需要的其它改变，添加基于组件架构对RLM接收适配的支持。 DirectShow RTP 收发负载调度器需要具有单个流的接收压缩数据，处理后用于回放或网络传输的能力。为支持层压缩，我们需要把包含各层的单个流分成多个独立流，每个包含一个用来通过独立网络连接传输的独立层。同样必要的是能够把多层合成为一个单一的视频流，分发给解码器。为了提供这种功能，我们添加了一个叫层负载调度器（LPH）的新类型的filter到DirectShow RTP。 LPH 是为每个支持层次压缩负载类型特地编写的。LPH filters有两个，Send LPH filters和Receive LPH filters。 SLPH filters执行当使用层多播时把每个视频帧赋值到对应的流中的策略。这些filters接收来自codec的输入，它生成一个包括来自流中所有层的帧的流。这些SLPH filter生成的流包含一些视频帧然后在RTP SPH filters中打包。无需改变RTP SPH filters来实现，因为每层只包含需求流的特定负载类型的合法帧。这些包会被RTP Render filter通过独立的多播流传输。 在层多播中每个流的接收由RTP Source filter来完成，它无需改变就可支持此项功能。一旦接收，每个流都通过 RTP Demux filter分发到RTP RPH filter。每个RPH filter把一个流的包汇编为合适media type 的帧。这些帧随后分发到RLPH filter，它负责重新排序组合这些来自每层的帧到一个合理media type的统一流中，然后分发到codec中解码和渲染。 5．1 Poorman Codec 当我们开始工作，我们对分级codecs诸如 H。263+或Indeo 5.0接触不多。因而，我们决定实现一个简单的SLPH（poorman 编码）和RLPH（poorman 解码）允许采用标准codec临时的视频缩放。Poorman压缩器通过输出Pins多路输出视频帧，poorman 解压器把这些帧整合为一个流。Poorman 压缩器采用了（weighted round-robin interleaving algorithm）分配帧到各个pin。这种简单的算法通过避免帧间依赖成为可能，我们可以通过强迫视频codec只生成关键帧来实现。明确的但不是优化的针对层视频的解决办法，我们发现这是很有效的进行多级适配研究和在缺少真正分级编码条件下证明非常有用的工具。图7和8显示了采用poorman 编码的RLM在filter graph中的实现。 H26x Decoder Video Render RTP Source RTP Demux Depacketizer H26x Splitter H26x Decoder Video Render 图6： 在采用（weighted round-robin ）多播流算法的多路输出视频帧过程中，保持时间戳信息是非常重要的。确保接收者重组这些流为按时间序列的单个视频流，这个信息是必要的。 在我们执行中，RTP SPH filter确保相关各层RTP时间戳之间正确性，基于这样的事实，它们继承RTP时间戳，每个来自DirectShow被打包的帧有关的时间戳。在接收方，RPH filter 把RTP时间戳放置于DirectShow samples，允许在poorman解码前同步和排列帧。一旦帧被poorman 解码器排序和同步，有必要为每个帧打上时间戳。这些信息对视频渲染filter根据需要适配的主机或网络条件正确生成质量消息来说是必要的。我们决定时间戳需根据如下公式赋值： time offset = FIRST_RTP_TIME – STAT_STREAM_TIME sample_start_time = CURRENT_RTP_TIME +Time_offset Interval_time = PREVIOUS_RTP_TIME – CURRENT_RTP_TIME 考虑到 FIRST_RTP_TIME 是通过根据时间戳排列第一组到达的包获取最小的结果值。必须在排序以前（因而获取FIRST_RTP_TIME）接收到包的数目是可编程控制的。这种机制对于消除出现在网络和发送接收主机操作系统到达包的抖动和重排的影响，是必要的。 5．2 H263+/Indeo 层负载操作者 分层负载操作者在初始设计过程集中设计了二个等级视频压缩，Indeo和H.263+。这两个视频压缩器有不同的分层结构，致使被每个LPH执行的功能有点不同。Indeo 是基于波段的, 多波段视频出现在每个压缩视频片段中。每个波段能都在一个单独的流中传输和所有波段能够通过一个流发送。为区分一个流中的波段，使用了一种叫波段抽取的工具。在我们的实现中，SLPH起到了一个波段抽取的角色，接收来自压缩器的复合帧，分割成波段数据，传递到RTP SPH filters打包，通过RTP流传输。波段被RLPH重新组合为一个单独的视频帧，提供给解码器。Indeo需要一个基层，可以被单独接收，如果其它层需要处理也必须接收。其它层以连续的方式互相依赖，就是说，层1依赖于层0（基础层），层2依赖于层1，等等。 H．263的分层结构比Indeo更为复杂，有三个不同基本类型的层，或可以说是被引入的收缩性【18】。这三个可量测的类型包括时间的，空间的和SNR（噪音率信号）。时间可量测性，包含B（双向预测）帧，提供一个较大的帧率。空间可量测性是指图片大小的变化，比如从QCIF（176×144）到CIF（352×288）。SNR可量测性是为了校正在压缩过程中编码错误对数据封装，相较原始的未压缩版本改进图片。这三种可伸缩类型可以被结合在一起提供许多不同层的视频。然而，每个视频帧都是隔离的，只属于一个层。两个或更多的这些帧可以被编码器组合来创建一个可用来显示的图片。不像Indeo, H.263+的分层没有以一个有序的方式排列。当这儿需要一个基础层，其它加强层可能依靠其它任何分层结构中在它下面的层。分层负载处理器被配置来知晓各层的依赖并根据这些信息决定丢弃还是添加层。 除了H.263+支持的复杂的层关系，重组层时需要特定序列的帧。这种序列，在H.263 ITU 介绍中有详尽描述，需要提供B帧给解码器，在基于它的双向预测帧以后。比如，在连续的3帧中，帧2是来自帧1和帧3的双向预测，顺序将为1，3，2。 这也是编码器生成帧的序列，这致使RLPH接收到的帧以不同于原始采样或采集顺序。因为RTP的说明中需要RTP时间戳基于即时的取样，负载操作者必须为帧重建一个即时取样，在传输数据时生成RTP时间戳。同样的，当接收方重排帧后，RTP时间戳不能被用来排列它们，分发给解码器。重建时间戳不是一个难题，尽管它导致一个对即时取样值的估算。然而，没有RTP时间戳的协助来为解码器排列帧是一个非常难以解决的问题，两个参考帧之间的B帧数目可以是变化的。我们通过与其它帧分开单独排列B帧，把参考帧作为用来预测B帧，来确定原始编码序列的分割符来解决这个问题。因为在任何“预测窗口”中预期的B帧数目是变化的，我们添加了一个可配置的缓冲超时时段。在此段时间，接收分层负载控制器将会在那个窗口的B帧提供给解码器以前等待所有进入的B帧。我们也可以基于在超时后接收的B帧数目，动态适配这一超时时段。 适配管理器使用LPH filter 来动态的添加和撤销发送或接收方的层。通过执行大部分很复杂的SLPH 和RLPH filter 特定的 RLM 和重用这些filters，能够比较容易添加 RLM对我们适配引擎的支持。在这种单架构而不是像DirectShow这样的基于组件的架构构建这种功能将会显著增加明显的复杂度。 5．3 RLM在网络适配控制中的执行 我们的网络适配控制组件实现了对RLM适配机制的支持。为了简化实现，RLM适配控制器提供一个有关适配策略的可变参数，可以在应用中设置。参数包括丢失阈值（在离开一个层前丢失的总量）和 离/合TTL消息（用来限制发送离/合消息到网络子网）。除了这些参数，所有RLM的相关定时器可被应用使用。 RLM算法以包丢失作为确定增添或去除层的依据。因为这一信息目前保存在RTP SPH filter中，我们需要一个广播到网络适配控制器的方法。为了这么做，我们修改了RTP RPH filter，添加了一个用来分发丢包信息到适配控制器的回调接口。网络适配控制器接收到来自每个RTP RPH丢包信息，跨层集合到一起。 我们的网络适配控制的方式可依两种操作模式实现。第一种，直接对不利网络条件进行补偿。这种行动可能包含命令RTP 源filter 添加/加入一个多播层和指示作为结果行为的RLPH，让他知道是否需要等待来自一个特定层的数据。在另一种方式中，适配控制可在应用中使用。应用基于网络适配控制器提供的信息执行适配决策（比如，操作RTP源filter 和RLPH）。 5．4 使用主机适配控制的主机接收适配 主机适配控制允许视频流的接收者来选择最适合主机可用源的一组层。主机适配控制的初始要么通过应用执行（在适配感知应用中），要么通过适配代理filter调用。主机适配控制器把自己设为发送自视频渲染filter的DirectShow 质量消息的接收器。当消息显示为一个洪流，控制器丢弃用于多播组RTP源filter提供的离合接口，当接收到饥渴消息时添加层。这些操作在一个单独线程中实现，为了避免与数据流冲突。 6． 体验应用和测试 为了测试我们的软件架构，我们创建了一系列的适配应用。这些应用包含一个允许在HTML网页显示RTP流的ActiveX控件和一个普通的叫xNetMM的测试应用，它提供了类似VIC和VAT的功能。ActiveX控件的属性可以通过各种语言在HTML页中设置。 使用DirectShow RTP和软件编码/解码，我们可以接收和解码三个同步的H.263CIF视频流，每个流20帧/秒，和一个音频流，总共带宽可超过3Mbits/s，在一个P2-266处理器的主机上。使用一个特定允许filters 直接写视频硬件存储的DirectShow 视频渲染filter，我们能够提供在50%的CPU占用率下，全屏高质量的Indeo视频和音频（MPEG2 SDTV 5Mbps质量）。 我们使用这些应用，如图11所示测试平台，来测试各种情景。Modem 的存在允许我们在广阔的可用主机带宽范围中测试ASRC和RLM功能。处理使用modem来创造广阔范围的客户带宽，我们已经为框架编写了用于模拟网络丢失的抛弃RTP包的组件。这些组件的行为全可以通过参数配置，所以我们能够详细控制报丢失的分布。最后，在我们测试环境的主机的处理器能力跨度较大，从p90到p2-300。 为了证明多流应用中的主机适配，我们使用activeX控件的多实例在Web页中的创建了一个视频会议应用。会议中的视频流使用允许接收者适配的层视频。会议的参与者可以听和看到对方，观看视频窗口的视频剪辑。电影以帧率20Fps和44.1HZ indeo 音频 播放。随着参与者的增加，各视频和音频流的品质下降。视频会跳动，音频会出现噪音。当接收流和本地输出流适配后，接收流会降为很低的视频层（2FPS），发送流会降到 5FPS。适配后，音视频的质量会回到可接收的水平。这一情景包含明显的用户交互。在下一章节，我们着重说明如何最小化这些用户输入。 7． 未来工作 我们计划拓展我们的适配架构，包含对多源和应用适配的支持。我们也趋向于改进我们的设计来允许用户驱动的策略和优先级设置。扩展适配到广阔的系统而不是对每个不利条件做出反映的应用，将超出目前的执行进一步加强用户的体验。通过考虑用户在如此系统级的适配，其它的对适配控制器不可用的信息也可能被使用。我们相信这样结合系统级的适配和使用用户的选择将允许我们到达一个最佳的适配水平。 7．1跨越多资源适配 用来监控性能的度量，适配的算法，和控制适配的机制是资源明确的。然而，我们相信用于为特定资源的适配控制交互的接口可以被生成。提供一套标准的接口，应用可以实例化并与特定的适配控制器交互，而不需要获取一个很高水品的有关适配的应用知识。 为允许应用跨资源适配，我们计划使用一套分级适配控制组织来扩展我们的体系。在这种安排类型中，应用与一个单根的适配控制器交互，它反过来代表应用管理其它的适配控制器。例如，为适配主机和网络资源，应用可以实例一个复合的适配控制器，它使用一个主机适配控制器和一个网络适配控制器。当适配控制器是这个结构树的一片叶子，它将不直接控制。而是咨询他的父母，当条件允许时是否需要适配。 树根将根据它所有孩子的当前状态采取行动。我们相信这种分级方式将提供一套评估当前显示质量和能够操纵更广范围应用可用资源的方法，可以显著提高用户体验的品质。 7．2 用户特定的适配策略 进一步工作的一个重要领域就是允许用户设定参数，比如相关流和应用的优先级。用户也应该能够设置适配策略，也许根据应用和适配控制器的暗示。允许用户遵照哪个流时最重要的输入对达到最可能好的用户体验是关键的，如这些信息（用户对体育频道还是财经频道趋向于更高优先级）是通过其它方式难以获取的。用户的喜好对于怎样去适配同样是非常重要的，如一个用户喜欢高的帧率，而同时另一个也许喜欢高的品质。最终，适配控制器提供给用户的线索，什么形式的适配对用户来说更趋向于成功执行，将对帮助用户确定适配策略有用。 为了说明这些问题，我们计划创建两个实体，一个策略工具和一个策略控制器。策略工具提供一个图形用户接口，允许用户选择应用和指定策略。这些策略可以对单个应用或系统范围都有效。我们想象一个策略工具，这个允许这些指定策略优先于应用运行，可以在运行期间修改。最后，这个策略工具将包含一系列默认的用于没有用户输入的情况的策略。 一旦一组策略已被设定（只要策略被动态改变），策略工具将加载它们到系统策略控制器。策略控制器负责与每个适配控制器和每个应用交互，来执行策略工具指定的策略。策略控制器还需要负责监控每个策略控制器的状态，发送反馈到策略工具，它也许会同用户交互，以至于更新策略规范。 8． 总结 以DirectShow为基础，我们已为RTP流开发了一套叫做DirectShow RTP的框架。通过充分利用DirectShow的灵活性，和内在的可扩展性设计DirectShow RTP框架，我们实现了几种网络适配方法，并探究了新的主机适配方向。拓展流功能以自动适配网络和主机条件，使多媒体展现质量最大化，而依旧使用标准的编解码和协议变得可能。基于组件的DirectShow RTP 框架让适配领域的工作变的简单，因为这一框架提高了以前创建组件的重用和可维护性。 DirectShow RTP框架扩充的适配能力被采用已在系统存在的原有质量监控机制实现。这样适配能够很容易的使用这套框架就可添加到NetMM应用中去，无需改变或做很小改变。这些对像DirectShow RTP基于组件框架附加的能力，导致了NetMM使用该框架后有了戏剧性的和直接的改进。这证明了适配能力的价值，和允许简单快速的利用框架的价值。 致谢 谢谢微软公司的Don Ryan 和Mike Clark, Don Newll， Dele Scotto，和许多其它的Intel架构实验室成员，为本项目做出贡献。 DirectShow，Windows NT，ActiveX是微软公司的注册商标。 Pentium 和Pentium II是Intel公司的注册商标。