技术领域

本发明实施例涉及媒体播放技术领域， 更具体地说， 涉及一种媒体 文件播放系统及方法。 发明背景

目前， 在 Window 平台上， 对各种媒体文件的播放通常采用 DirectShow技术框架，其使用一种叫 Filter Graph的模型来管理整个多媒 体数据流的处理过程， 参与数据处理的各功能模块称为 Filter (滤镜）。 各 Filter在 Filter Graph中按一定的顺序连接成一条 "流水线"协同工作， 这条 "流水线" 通常称之为渲染线。 按功能来分， Filter大致分为三类： 源滤镜 （Source Filter ) , 转换滤镜 （Transform Filter ) 和渲染滤镜 ( Rendering Filter )„ 源滤镜主要负责获取数据， 并将数据向下一个滤镜 传输； 转换滤镜主要负责数据的格式转换， 例如数据流分离 /合成、 解码 /编码等， 并将数据继续向下一个滤镜传输； 渲染滤镜主要负责数据的最 终去向， 将数据传送给显卡、 声卡进行多媒体的演示。

Filter含有被称为 Pin的结构， 一种是输出 Pin, —种是输入 Pin。一 个 Filter—般由一个或多个 Pin组成， Filter之间通过 Pin相互连接。 当 上一个 Filter要和下一个 Filter连接时， 上一个 Filter的输出 Pin要和下 一个 Filter的输入 Pin协商， 若输出 Pin的媒体流格式能被下一个 Filter 的输入 Pin支持， 则两者可以成功建立连接。

播放器在播放媒体文件之前， 会获取所有已知的 Filter并按一定顺 序连接出一条渲染线， 从而达到播放媒体的目的。 该过程称之为建立渲 染线。 每一个 Filter都有一个称为优先级的属性， DirectShow建立渲染 线的时候默认会把优先级高的 Filter连入渲染线。然而，优先级高的 Filter 不一定能连入成功， 因为该 Filter的输入 Pin可能不支持已连入渲染线 中的上一个 Filter的输出 Pin输出的媒体流格式。 因此， 达到播放媒体 的目的， 需建立合适的渲染线。

目前在各种播放器中， 一般采用以下两种方式建立渲染线播放媒 体。

( 1 )直接调用 DirectShow提供的接口方法 RenderFile( strFilePath )。 该接口方法依赖于 DirectShow技术框架内置的建立渲染线的默认逻� �， 为以 strFilePath为全路径的媒体建立渲染线。 这种方式是最筒单的渲染 策略， 在该方式中， 播放器可以完全不考虑渲染线中各 Filter是什么及 各 Filter的顺序。 该方法对于 DirectShow内置的建立渲染线的默认逻辑 能处理的媒体有效。 然而， 很多媒体由于压制的方法、 工具不同及传输 时造成的局部错误， 导致 DirectShow无法通过 RenderFile ( strFilePath ) 智能地为媒体建立适当的渲染线进行播放， 从而导致播放效果可能很 差。

例如， 播放视频流为 H264的媒体文件时， 系统中有解码器 CL264 Decoder8和 MPCHC, 两者都可支持对 H264视频流的解码（即两者都 可以连入渲染线 ), 且根据 DirectShow技术框架内置的建立渲染线的默 认逻辑，前者比后者的优先级高。则 CL264 Decoder8解码器优先连入了 渲染线， 而 MPCHC解码器没有机会连入渲染线。 事实上， 在用显卡对 媒体文件的播放进行高清加速时， 由于该文件自身的某些特性（例如媒 体文件分辨率、容器格式等），使用 CL264 Decoder8来解码效果很不好， 会花屏，更严重的由 CL264 Decoder8解码出的视频流可能根本无法显示 到屏幕上， 而出现黑屏等现象； 而用 MPCHC解码的效果反而更好。 然 而 DirectShow内置的建立渲染线的默认逻辑没有给 MPCHC机会，因此 采用 DirectShow内置的建立渲染线的默认逻辑，未考� �到媒体文件自身 特点， 不能为各种媒体建立适当的渲染线， 从而导致媒体文件的播放效 果差。

( 2 )依靠播放器编写者的经验，在播放器代码中� �先设置好各 Filter 的优先级，以实现播放器能对 DirectShow内置的建立渲染线的默认逻辑 无法处理或者处理效果不好的媒体进行较好的 播放， 该方法能克服第一 种方法的缺点。这种做法表现为：对不同的媒 体格式，有区别的设置 Filter 的优先级。 比如， 对 H264的视频， 设置 MPCHC解码器的优先级高于 CL264 Decoder8解码器； 而对于 mpeg2的视频， 设置 CL264 Decoder 8 解码器的优先级高于 MPCHC的优先级。

然而， 这种方法也仅仅是部分考虑到了媒体文件自身 的特点， 仍然 具有以下缺陷： A.通用性差。 对于同一格式的媒体文件， 适用的 Fi l ter 也有不同， 按照设置好的 Fi l ter 优先级建立渲染线， 也会导致媒体的 播放效果差。 例如， 对于 H264视频， 某些媒体文件使用 CL264 Decoder8 来解码比用 MPCHC解码效果好， 而另一部 H264视频流格式的媒体文件 则使用 MPCHC解码器比使用 CL264 Decoder8解码器的效果好。 针对这 种情况， 播放器编写者必须对这些媒体文件进行测试分 析， 然后修改或 添加程序来应付播放这一部分媒体时如何设置 Fi l ter 的优先级， 并把 修改后的新版本发出去才能解决用户机器上播 放这部分媒体时播放效 果不好的问题。 B.修改频繁。 由于不同的用户机器环境不同 （比如显卡 加速能力不同）， 而播放器编写者是无法实现预知的， 因此经过测试修 改后发出去的播放器版本可能无法解决所有用 户的问题。 因不同用户机 器环境对播放器的要求， 要解决播放效果差的问题， 则需频繁修改播放 器的版本。 发明内容

本发明实施例提供一种媒体文件播放系统和方 法， 实现建立适合各 种媒体文件的渲染线， 从而得到更好的媒体播放效果。

本发明实施例提供的技术方案包括：

一种媒体文件播放系统， 包括渲染规则库与播放器单元， 渲染规则 库中存储了渲染规则， 播放器单元包括： 规则管理模块、 渲染策略环境 模块和播放模块， 其中，

所述规则管理模块用于从所述渲染规则库中获 取渲染规则， 并对获 取的渲染规则进行解析；

所述渲染策略环境模块， 用于根据所述规则管理模块解析出的渲染 规则生成渲染线；

所述播放模块， 用于利用所述渲染线播放媒体文件。

一种媒体文件播放方法， 所述方法包括以下步骤：

A, 从预先建立的渲染规则库中获取渲染规则， 并对获取的渲染规 则进行解析；

B, 根据解析出的渲染规则生成渲染线；

C, 应用所述渲染线播放媒体文件。

综上技术方案可以看出， 上述媒体文件播放系统及方法， 通过建立 渲染规则， 并将渲染规则集中存储在渲染规则库中， 当播放器播放媒体 文件时， 遍历渲染规则库中的渲染规则， 根据渲染规则中定义的逻辑因 果关系执行规则中定义的操作， 能达到调整渲染线的目的， 建立适合媒 体文件的渲染线， 从而可以得到更好的媒体播放效果。 附图简要说明 图 1是一个实施例中媒体文件播放系统的结构示� �图; 图 2是一个实施例中渲染策略环境模块的结构示� �图；

图 3是一个实施例中规则管理模块的结构示意图� �

图 4是一个实施例中媒体文件播放方法的流程图� �

图 5是一个实施例中生成渲染策略的方法流程图� �

图 6是一个实施例中解析渲染规则的方法流程图� �

图 7是一个实施例中解析条件节点的方法流程图� �

图 8是一个实施例中解析操作节点的方法流程图� �

图 9是一个实施例中条件二叉树的示意图；

图 10是一个实施例中计算条件二叉树根节点的真� ��值的方法流程 图；

图 11是一个实施例中创建原子条件类实例和原子� ��作类实例的示 意图. 实施本发明的方式 本发明实施例中， 将播放媒体时运用到的渲染线的各种建立逻辑 统 一抽象为渲染规则模型， 并以此建立出一个渲染规则库， 这样， 基于该 渲染规则库可以实现建立适合各种媒体文件的 渲染线， 以便得到更好的 媒体播放效果。

为了使本发明的目的、 技术方案和优点更加清楚， 下面结合附图和 具体实施例对本发明进行详细描述。

参见图 1 , 图 1示出了一个实施例中的媒体文件播放系统， 该系统 包括渲染规则库 10和播放器单元 20, 其中：

渲染规则库 10 中预先存储了渲染规则。 渲染规则中定义了在何种 条件下执行何种操作。 所谓条件即影响播放效果的某些因素， 包括以下 内容： （1 )媒体文件本身的因素， 例如媒体的分辨率、媒体的容器格式、 视频流格式、音频流格式等； （2 ) Filter本身的局限性，例如 Filter在 Pin 的连接协商中声明支持某种视频或音频流格式 ， 但实际支持的效果并不 好； （3 )操作系统软环境， 如操作系统等。 例如， 在 Windows XP系统 下高清加速的时候， 渲染滤镜一般采用 VMR9就可以支持， 但在 Vista 或 Win7系统下， 则必须用 EVR渲染滤镜； （4 )机器硬件能力， 如显卡 等， 主要表现显卡能不能支持高清加速， 支持高清加速的时候， 显卡最 多緩存多少参考帧等； （5 )播放模式， 即用户想让播放器以什么样的方 式去播放媒体文件。 例如用户播放时是否考虑占中央处理器资源， 若用 户在播放媒体文件时还想做其他事情， 则播放器播放媒体时采用尽量少 占中央处理器资源的智能加速方式等。 条件可以是上述各种因素中的至 少一个或者任意组合， 本发明并不对此做限制。 而相应地， 操作包括设 置高清加速和调整 Filter的优先级等中的至少一个或者任意组合， 其与 条件对应。 可以看出， 渲染规则实质上描述了条件和操作的对应关系 。

在一个实施方式中， 渲染规则库 10 中描述渲染规则的数据是静态 数据， 其可存在播放器程序代码的一组硬编码的数据 结构中， 也可采用 脚本文件存于播放器的安装目录下， 或位于网络上的某个集中的数据库 中， 本发明实施例并不限定， 但较佳地， 需要保证该静态数据和具体程 序逻辑分离， 这样易于修改且管理。

播放器单元 20包括规则管理模块 200、渲染策略环境模块 202和播 放模块 204。

其中， 规则管理模块 200用于获取并解析渲染规则， 这里， 规则管 理模块 200可从渲染规则库中获取渲染规则； 至于规则管理模块 200解 析渲染规则， 其具体为： 获取渲染规则中的逻辑因果关系， 并将该获取 的逻辑因果关系的格式转换为符合格式比如计 算机识别的格式。

渲染策略环境模块 202根据规则管理模块 200解析的渲染规则生成 渲染线。 播放模块 204用于利用所述渲染线播放媒体文件。

这里， 规则管理模块 200仅能通过解析渲染规则获取该渲染规则中 的逻辑因果关系， 该逻辑因果关系实质上为条件和操作的对应关 系， 其 中， 该逻辑因果关系中的条件包含各种条件， 比如原子条件 ( ServiceAtomCondition )和子条件 (子 Condition Group ), 其中, 原子 条件为只有业务环境能够识别的关键字且其代 表的是一个条件， 其不可 再细分； 而子条件还可以进一步细分， 比如细分为原子条件等，基于此， 可将该逻辑因果关系中的条件筒称为条件节点 ， 相应地， 将该逻辑因果 关系中的操作筒称为操作节点； 这里， 操作节点由一些原子操作 ( Service AtomAction )构成， 其中， 原子操作是指只有业务环境能够识 别的关键字并且代表的是一种操作， 其不可再细分。 但是， 规则管理模 块 200并不能识别该条件节点中原子条件和该操作 节点中原子操作的具 体含义， 在一个实施方式中， 规则管理模块 200通过调用渲染策略环境 模块 202预先提供的应用程序接口将获取的条件节点 中的原子条件和操 作节点中的原子操作传送给渲染策略环境模块 202进行识别。

基于此， 图 2示出了一个实施例中的渲染策略环境模块 202的一个 结构。 如图 2所示， 渲染策略环境模块 202包括条件生成模块 2020、 条 件判断模块 2022、 操作生成模块 2026和操作执行模块 2028。

其中， 条件生成模块 2020获取条件节点中原子条件的描述， 对获 取的原子条件的描述进行解析并创建原子条件 类实例， 以及将该原子条 件类实例返回给规则管理模块 200。

条件判断模块 2022获取媒体文件信息， 根据媒体文件信息判断原 子条件的真假值， 并将原子条件的真假值返回至规则管理模块 200。 例 如： 原子条件是 "当前媒体文件的视频流格式是 H264" , 根据媒体文件 信息可知当前媒体文件的视频流格式是 H264, 基于此， 可以看出条件 判断模块 2022判断原子条件的真假值为 "真"。

操作生成模块 2024获取操作节点中的原子操作的描述， 对原子操 作的描述进行解析并创建原子操作类实例， 以及将原子操作类实例返回 至规则管理模块 200。

操作执行模块 2026在接收到规则管理模块 200发送的渲染规则中 条件节点成立的通知时， 执行所述渲染规则中条件成立时对应的操作。

由于渲染线表示了条件和执行操作的对应关系 ， 当操作执行模块 2026执行操作时， 很显然得到条件和执行操作的对应关系， 即可生成对 应的渲染线。 相应地， 当操作执行模块 2026 不执行操作时， 即该条件 和操作的不对应， 也可生成对应的渲染线。

基于图 2所示的渲染策略环境模块 202的结构， 本发明实施例还提 供了规则管理模块 200的结构， 具体如图 3所示。 在图 3中， 规则管理 模块 200包括条件二叉树生成模块 2000和条件二叉树计算模块 2002。

其中， 条件二叉树生成模块 2000根据渲染规则中的条件节点生成 条件二叉树。

由于渲染规则中的一个条件节点可能包含多个 原子条件， 其可由其 所包含的原子条件进行逻辑组合而成。 条件二叉树则形象的表示出了每 条件二叉树计算模块 2002根据条件判断模块 2022返回的原子条件 的真假值递归计算条件二叉树的根节点的真假 值。 这里， 条件二叉树的 根节点的真假值决定了所述渲染规则中条件节 点是否成立， 当条件二叉 树计算模块 2002计算出条件二叉树的根节点的真假值为真� �， 发送渲 染规则中条件节点成立的通知给上述操作执行 模块 2026,以便操作执行 模块 2026执行相应地操作。

以上对本发明实施例提供的系统进行了描述， 下面结合附图和实施 例对本发明提供的方法进行描述。

图 4示出了一个实施例中媒体文件播放方法的流� �，具体过程如下： 在步骤 S10中， 获取渲染规则。

这里， 步骤 S10可从渲染规则库中获取渲染规则。 如上所述， 该获 取的渲染规则中定义了在何种条件下执行何种 操作， 这里所述的条件为 影响播放效果的因素。

在步骤 S20中， 解析所述渲染规则。

具体地， 步骤 S20为： 通过解析所述渲染规则获取渲染规则中的逻 辑因果关系， 并将该获取的逻辑因果关系的格式转换为符合 格式比如计 算机识别的格式。

在步骤 S30中， 根据解析出的渲染规则生成渲染线。

在步骤 S40中， 应用所述渲染线播放媒体文件。

其中， 上述步骤 S30具体操作可参见图 5所示的流程。

图 5示出了一个实施例中生成渲染线的方法流程� � 具体过程如下： 在步骤 S200 中， 获取所述渲染规则中所有条件节点下原子条件 的 描述， 调用渲染策略环境模块 202解析原子条件的描述并创建原子条件 类实例。

在一个渲染规则中， 一个条件节点可能包含多个原子条件， 对于每 个原子条件， 需调用渲染策略环境模块 202解析原子条件的描述， 并创 建原子条件类实例， 以及将原子条件类实例返回至规则管理模块 200。

在步骤 S202 中， 获取媒体文件信息和机器参数， 根据媒体文件信 息和机器参数判断原子条件的真假值。

在一个实施方式中， 调用渲染策略环境模块 202提供的应用程序接 口计算原子条件的真假值， 这里， 当解析的原子条件与媒体文件信息或 机器参数符合时， 则确定原子条件的真假值为 "真"， 不符合时确定原 子条件的真假值为 "假"， 将确定出的原子条件的真假值返回规则管理 模块 200。

需要说明的是， 上述媒体文件信息包括媒体文件本身的特性（ 例如 媒体文件格式、 分辨率等）， 机器参数包括用户机器的操作系统软环境 和硬件参数等。

在步骤 S204中， 根据渲染规则中的条件节点生成条件二叉树。 如上所述， 条件二叉树中表示了一个条件节点下的所有原 子条件以 及各原子条件之间的逻辑关系。

在步骤 S206 中， 根据计算得到的原子条件的真 支值， 递归计算所 述条件二叉树的根节点的真假值。

在一个实施方式中， 规则管理模块 200调用渲染策略环境模块 202 提供的应用程序接口计算原子条件的真假值， 根据原子条件的真假值， 对条件二叉树上的节点进行递归计算， 从而得到根节点的真假值。

在步骤 S208 中， 获取渲染规则中操作节点的原子操作的描述， 调 用渲染策略环境模块 202解析原子操作的描述并创建原子操作类实例 。

在渲染规则中， 一个操作节点可能包含多个原子操作， 原子操作依 赖于业务环境，因此需调用渲染策略环境模块 202解析原子操作的描述， 创建的原子操作类实例返回至规则管理模块 200。

在步骤 S210 中， 根据所述条件二叉树的根节点的真假值的计算 结 果， 执行条件成立时对应的操作。

在一个实施方式中， 计算得到条件二叉树的根节点的真假值为 "真"， 表示该渲染规则中的条件节点成立， 则渲染策略环境模块 202 执行该条件节点下的操作， 即步骤 S208对应的操作， 例如设置高清加 速、 调整 Filter的优先级等。

可以看出， 本实施例中， 条件二叉树根节点的真假值决定了渲染规 则中条件是否能成立。 由于渲染规则中定义了各种条件下所执行的操 作， 在符合渲染规则的情况下， 操作执行模块 2026 则执行渲染规则中 定义的操作， 从而建立适合媒体的渲染线， 以便播放单元 20播放时得 到更好的媒体播放效果。

至此， 通过图 5所示的步骤实现了渲染线的生成。 为使本申请提供 的图 4和图 5所示的技术方案更加清楚， 下面以一个具体实施例进行详 细描述。

该实施例中， 采用可扩展标记语言 （ Extensible Markup Language, 筒称 "XML" )描述渲染规则， 生成脚本文件。 该脚本文件的结构形式 :¾口下：

<Root>

<Rule ID="ID1" >

<ConditionGroup Operator="OPl">

<ServiceAtomConditionl/>

<ServiceAtomCondition2/>

<ServiceAtomCondition3/>

<ConditionGroup Operator="OP2">

</ConditionGroup>

</ ConditionGroup>

<Action>

<ServiceAtomActionl/>

<ServiceAtomAction2/>

</Action>

</Rule> <Rule ID="IDn">

</Rule>

</Root>

上述脚本文件的结构形式中， Root包含各种渲染规则， 是该脚本文 件的根节点； Rule节点表示一个渲染规则， 即在何种条件下做何种操作 的描述； ID是渲染规则唯一的标识号； ConditionGroup节点表示渲染规 则中的条件， 一个渲染规则中必定包含一个 ConditionGroup节点。 而一 个 GonditionGroup节点中可能包含子条件（ GonditionGroup ) 以及各种 原 子 条 件 （ 如 上 述 结 构 中 的 Service AtomConditionl 、 ServiceAtonConditon2等）， 这些原子条件具有渲染策略环境模块 202能 识别的关键字。 例如， ServiceAtomConditionl可以是一个用来判断当前 影片的视频流格式是否是 H264的条件， 形式如下：

<HDVideoFormat Operato="Eq" Value="H2647>

该原子条件必须依赖渲染策略环境模块 202才能识别， 若根据渲染 策略环境模块 202得到当前媒体的视频流是 H264时， 则条件判断模块 2022判断出该原子条件为真。

需要说明的是， ConditionGroup节点中的 Operator属性值可由规则 管理模块 200进行定义，该属性值可以是一些逻辑关系， 例如，与（ and )、 或 ( or ) 关系等。 当 Operator属性值为 "与" 时, 表示 ConditionGroup 节点下的各子节点所代表的条件是与的关系， 即 ConditionGroup节点下 所有子节点所表示的条件都为真时， ConditionGroup节点为真， 否则为 假； 当 Operator属性值为 "或" 时， 表示 ConditionGroup节点下的各子 节点所代表的条件是或的关系， 即 ConditionGroup节点下所有子节点所 表示的条件有一个为真时， 则 ConditionGroup节点为真， 否则为假。 还需要说明的是， ConditionGroup节点下的子节点的 Operator属性 值不应与该 ConditionGroup节点（称为父节点）的 Operator属性值相同， 否则， 可以把子节点化筒到父节点中。 这可通过以下代码体现：

<ConditionGroup Operator =" And" >

<HDVideoFormat Operator="Eq" Value="H264"/>

<ConditionGroup Operator^" And" >

<HDAudioFormat Operator="Eq" Value="EAC3"/> <System Operator="Eq" Value="WinVista"/>

</ ConditionGroup>

</ConditionGroup>

表示的是

if ( ( HDVideoFormat == H264 )

&& ( (HDAudioFormat == EAC3) && (System ==

Win Vista) )

)

在上述代码中可以看出， 子节点的 Operator 属性值与父节点的 Operator属性值相同， 都为" And" , 基于此， 上述代码可以化筒为：

If( ( HDVideoFormat == H264 ) && ( HDAudioFormat == EAC3 ) && ( System == WinVista )

)

用脚本可表示为

<ConditionGroup Operator="And">

<HDVideoFormat Operator="Eq" Value="H2647>视频流格 式是 H264

<HDAudioFormat Operator="Eq" ¥311½=' 。37>音频流格 式是 EAC3

<System Operator="Eq" Value="WinVista"/> 系 统 是 Win Vista系统

</ConditionGroup>。

Action 节点 （操作节点 ） 表示的是渲染规则中最顶层的

ConditionGroup节点中条件的返回值是 "真" 时， 需要执行的操作， 该 Action节点也可由一些原子操作 (如上述结构中的 ServiveAtomActionl、 ServiceAtomAction2 )进行逻辑组合构成。 原子操作也具有渲染策略环 境模块 202能识别的关键字， 例如 ServiveAtomActionl表现形式如下： <SetTransformFilterPriority Name="WMVideo Decoder DMO"

Priority="PRIORITY_PREFERRED7>

该描述可由渲染策略环境模块 202 识别出， 该操作是要将名为 "WMVideo Decoder DMO" 的解码器的优先级调为最高。

图 6示出了该实施例中解析渲染规则的方法流程� � 具体过程如下： 在步骤 S60中， 获取渲染规则脚本中当前规则节点 （ Rule节点）。 这里， 渲染规则脚本包含多个规则节点 （即上述脚本文件的结构中 含有多个 Rule节点 ), 因此需遍历脚本文件中的所有规则节点。

在步骤 S62中， 判断渲染规则脚本中是否还有当前规则节点的 下一 个规则节点， 若是， 则进入步骤 S64, 否则结束。

在步骤 S64中， 定位到当前规则节点的根 CondionGroup节点。 在步骤 S66中， 解析当前 ConditonGroup节点， 生成原子条件类实 例并插入现有的条件二叉树中。

在步骤 S68中， 解析规则节点下的操作节点， 将所述当前规则节点 的下一个规则节点作为当前规则节点， 返回至步骤 S60。

具体地， 步骤 S66可通过图 7所示。 图 7示出了一个实施例中解析 条件节点的方法流程， 具体过程如下：

在步骤 S660中， 从该条件节点即 ConditionGroup节点中确定当前 子条件节点。

这里， 一般将条件节点即 ConditionGroup节点中的第一个子条件节 点作为当前子条件节点。

在步骤 S662 中， 判断所述当前子条件节点是否为 ConditionGroup 节点， 若是， 则进入步骤 S668, 否则进入步骤 S664。

这里， ConditionGroup节点为复合节点， 其可进一步细分为原子节 点。

在步骤 S664 中， 将该当前子条件节点传给渲染策略环境模块 202 进行解析， 生成原子条件类实例。

该实施例中， 当子条件节点不是 ConditionGroup节点时， 说明该子 条件节点下不再会有原子条件节点， 则可将该子条件节点的描述传给渲 染策略业务环境 202进行解析。

在步骤 S666中， 将该原子条件类实例插入到条件二叉树中， 之后， 执行步骤 S669。

在步骤 S668 中， 递归解析当前子条件节点， 生成原子条件类实例 并插入到现有的条件二叉树中， 之后， 执行步骤 S669。

在一个实施例中， 当前的子条件节点是 ConditionGroup节点时， 也 就说明该 ConditonGroup节点下可能还含有原子条件节点， 因此需递归 解析该当前的 ConditionGroup节点， 直至最终得到原子条件节点为止。

在步骤 S669 中， 判断当前子条件节点是否为条件节点即 ConditionGroup节点中的最后一个子条件节点， 如果是， 结束， 否则， 将当前子条件节点的下一个子条件节点作为当 前子条件节点， 返回执行 步骤 S660。 本实施例中， 步骤 S68所示的解析操作可通过图 8所示。 图 8示出 了一个实施例中解析操作节点的方法流程， 具体过程如下：

在步骤 S680中， 定位到当前规则节点下的操作节点 （即 Action节 点）。

在步骤 S682中， 从当前操作节点获取下一个原子操作节点。

在步骤 S684 中， 判断是否还有原子操作节点， 若是， 则进入步骤 S686, 否则结束。

在步骤 S686中， 将该原子操作节点传给渲染策略环境模块 202进 行解析， 生成原子操作类实例。

该实施例中， 对于脚本文件中 ConditionGroup下的原子条件节点， 以及 Aciton 节点下的原子操作节点， 由于其具有与业务环境联系的语 义， 而规则管理模块 200仅能处理原子条件之间的逻辑关系， 以及在条 件成立时执行何种操作的问题， 因此规则管理模块 200需将原子条件以 及原子操作的 XML节点传给渲染策略环境 202模块进行解析， 并创建 相应的原子条件类实例和原子操作类实例， 返回给规则管理模块 200。

该实施例中， 规则管理模块 200采用条件二叉树表示脚本中的规则 下的条件节点。 例如， 在一个脚本文件中， ContionGroup节点的代码如 下：

<ConditionGroup Operator="And">

<HDVideoFormat Operator="Eq" Value="H264"/>

<HDAudioFormat Operator="Eq" Value="EAC3"/>

<System Operator="Eq" Value="WinVista"/>

<ConditionGroup Operator="Or">

<HDContainerFormat Operator="Eq" Value="MKV"/>

<HDContainerFormat Operator="Eq" Value="MP4"/>

</ConditionGroup> </ConditionGroup>

将该 ConditionGroup节点表示成条件二叉树如图 9所示。 该条件二 叉树中， "&&" 表示逻辑关系与 （and ), "II" 表示逻辑关系或（or )。 该 条件二叉树从渲染规则的根 ConditionGroup节点下的第一个原子条件节 点开始遍历， 条件二叉树的根节点为根 ConditionGroup节点的 Operator 属性值（如图 9 中的根 "&&" ), 用来表示条件二叉树左右两个原子条 件节点的逻辑关系。 在条件二叉树中， 每个节点的左子节点是与业务环 境相关的原子条件节点， 当左子节点表示的原子条件节点在脚本中后续 只有一个原子条件时， 右子节点为后续的那个原子条件节点。 当左子节 点表示的原子条件在脚本中后续是一个子 ConditonGroup节点， 则右子 节点为该子 ConditonGroup节点的 Operator属性值。 当左子节点表示的 原子条件在脚本中后续有不只一个子条件节点 时， 则右子节点为当前 ConditonGroup节点的 Operator属'] "生值。

图 10 示出了一个实施例中计算条件二叉树的根节点 的真假值的方 法流程， 具体过程如下：

在步骤 S100中， 调用渲染策略环境模块 202计算左子节点所对应 的原子条件的真假值。

在步骤 S102 中， 判断右子节点是否是原子条件， 若是， 则进入步 骤 S104, 否则进入步骤 S106。

在步骤 S104中， 调用渲染策略环境模块 202计算右子节点所对应 的原子条件的真假值。

在步骤 S106 中， 递归调用后续遍历的算法计算以右子节点为根 节 点的树所表示的条件的真假值。

该实施例中， 当右子节点不是原子条件时， 则右子节点是一个为逻 辑关系的根节点， 则需递归计算以该右子节点为根节点的树所表 示的条 件的真假值。

在步骤 S108 中， 根据各节点所表示的逻辑关系， 对左右子节点的 真假值进行逻辑运算， 得到条件二叉树的根节点的真假值。

该实施例中， 当条件二叉树的根节点的真假值为 "真" 时， 表明渲 染规则中的条件成立； 若为 "假"， 则表明渲染规则中的条件不成立。

图 11 示出了一个实施例中创建原子条件类实例和原 子操作类实例 的示意图。

如图 11所示， 在规则管理模块 200解析渲染规则时， 会将表示原 子条件的 XML节点传给渲染策略环境模块 202, 要求渲染策略环境模 块 202创建对应的原子条件类实例， 渲染策略环境模块 202则返回一个 继承于 CQPAtomCondition 抽 象类 的 原 子条件类 实 例 。 CQPAtomCondition类是一个含有虚方法 BOOL Fit()的抽象类，其事先由 规则管理模块 200定义， 渲染策略环境模块 202根据脚本文件中表示原 子条件的脚本创建出对应于该脚本的以 CQPAtomCondition为基类的原 子条件类实例。 例如， 规则管理模块 202传送代码 "<Mode Operator^ "Eq" Valuer " RENDERMODE_CUSTOM " />" 至渲染策略环境模块 202, 要求渲染策略环境模块 202创建对应的原子条件类实例， 渲染策 略环境模块 202 则返回 CQPHDVideoFormat 类， 其为继承于 CQPAtomCondition抽象类的原子条件类实例。

在规则管理模块 200解析操作节点时， 会将表示原子操作 XML节 点传给渲染策略环境模块 202, 要求渲染环境模块 202创建对应的原子 操作，渲染策略环境模块 202则返回继承于 CQPAtomAction抽象类的原 子操作类实例。 CQPAtomAction类是一个含有虚方法 BOOL DoAction() 的抽象类， 其事先由规则管理模块 200定义， 渲染策略环境模块 202根 据脚本文件中表示原子操作的脚本创建出对应 于该脚本的以 CQPAtomAction为基类的各种原子条件类实例。例� �，规则管理模块 200 传送代码 "<DXVA Value= "True" />" 给渲染策略环境模块 202, 要求 渲染策略环境模块 202创建对应的原子操作类实例， 渲染策略环境模块 202则返回 CQPAtomActionDXVA类，其为继承于 CQPAtomAction抽象 类的原子条件类实例。

基于上述方法原理，规则管理模块 200持有的各种原子条件类实例、 原子操作类实例，都可以用抽象类 CQPAtomCondition和 CQPAtomAction 的类指针进行表示。 规则管理模块 200判断条件是否满足时， 仅需调用 抽象类的类指针即可。

需要说明的是， 根据上面描述， 可以知道， 由于规则脚本中含有依 赖于业务环境的原子条件， 原子操作， 因此向具有解析创建规则的规则 管理模块 200提供一个用于播放器渲染策略业务环境是必 要的。 这里， 播放器渲染策略业务环境主要的功能是：

( 1 )解析规则管理模块 200传过来的表示原子条件或者原子操作 的 XML节点， 并创建出对应于该节点的原子条件类实例或原 子操作类 实例， 返回给规则管理模块 200。

( 2 ) 向规则管理模块 200提供业务能力， 当规则管理模块 200在 做规则的条件判断时， 播放器渲染策略业务环境提供给规则管理模块 200判断原子条件真与假所需的业务 API。 当规则的条件满足时， 播放 器渲染策略业务环境向规则管理模块 200提供执行操作时所需的业务 APL

下边通过代码具体举例说明：

<Rule ID="Rule_Set_DXVA_When_RENDERMODE_CUSTOM">

<ConditionGroup Operator= " Null" >

<Mode Operator="Eq" Value="RENDERM0DE_CUST0M7> </ ConditionGroup>

<Action>

<DXVA Value="True7>

</Action>

</Rule>。

以上对本发明实施例提供的方法进行了描述。

在上述媒体文件播放系统及方法中， 可以将渲染规则库 10 置于网 络上的某些运营机器上， 在网络上更新新的渲染规则， 并同步到播放器 客户端， 则无需频繁修改播放器版本。 另外， 针对特定的用户， 还可以 根据用户的机器环境、 播放习惯及要播放的特殊媒体文件， 定做一套渲 染规则， 根据该渲染规则建立最适合媒体文件的渲染线 ， 从而得到较好 的媒体播放效果， 极大地满足了用户的体验需求。 和详细， 但并不能因此而理解为对本发明专利范围的限 制。 应当指出的 是， 对于本领域的普通技术人员来说， 在不脱离本发明构思的前提下， 还可以做出若干变形和改进， 这些都属于本发明的保护范围。 因此， 本 发明专利的保护范围应以所附权利要求为准。