交互通信中客户机-服务器交互方法和系统 【发明领域】
本发明涉及在通信系统中实现客户机-服务器交互的技术，特别涉及基于MPEG-4标准的通信系统。
背景技术
交互性是MPEG-4国际标准(ISO/IEC 14496 Parts 1-6,Committee Draft,October 31,1997,Fribourg,Switzerland)发展中突出关注的课题。反向信道专门用于交互消息支持。但是通过信道载带的消息的语法和语义仍然未加定义，对于触发这种消息发送的机制也是如此。现有诸如DSM-CC(ISO/IEC国际标准13818-6)和RTSP(RFC 2326)之类的标准支持传统的VCR型交互，在回放期间重新配置介质流，但是对于交互控制要求更为复杂的MPEG-4应用，这是不合适的。
交互消息可以由某个用户动作或系统事件生成。随后它被送至服务器，可由服务器通过增加和去除对象或切换至完全新的场景修改其正在传送的流。用户动作可以包括点击一个对象、输入文本流等。系统事件包括定时器、条件测试等。
交互性是针对应用的，并且无法借助用户事件完全定义交互行为。为了支持针对应用的交互性，应该采用类似CGI的方式。特定的用户事件使得针对应用的命令数据送回服务器。服务器可以随后一般通过发送场景描述更新命令作出响应。这使得可以完全自由地支持应用所需的全交互性。
MPEG-4基本上采用两种交互性模式：本地的和远端的。本地交互性可以利用MPEG-4 BIFS(场景地二进制格式，它基于VRML 2.0 ROUTEs设计(参见www.veml.org和“The VRML Handbook”，J.Hartman和J.Wernecke，Addison-Wesley，1996)并且在MPEG-4说明书(系统)部分1中描述)特有的事件架构充分地实现本地交互性。如果在另一应用中以MPEG-4接收方为主，则需要由应用将其传送至MPEG-4接收方的事件可以翻译为MPEG-4部分1定义的BIFS更新命令。
远端交互性目前由URLs组成。如MPEG-4系统委员会草案所定义的，这些只能用来获得对内容的访问。因此它们无法用于触发命令。
MPEG-4系统已经包含借助事件源/转换器路由(它们是场景描述(BIFS)部分)支持本地交互的事实要求服务器交互处理与本地交互性模型完全集成在一起。
【发明内容】
本发明的目标是提供一种技术，用于在两个诸如“客户机”和“服务器”之类的实体之间，利用MPEG-4国际标准传送消息。
本发明的第二个目标是提供一种技术，用于使系统或用户可以生成MPEG-4播放机或客户拟含义下的这类消息。
第三个目标是提供一种技术，用于生成与MPEG-4中定义的本地交互性模型兼容的这类消息，它基于VRML2.0规定。
进一步的目标是提供一种技术，用于编码MPEG-4比特流内的这类消息并将编码的消息链接至场景描述。
进一步的目标是提供一种技术，用于以一种在某种程序上使服务器能够在发送给客户机供使用之前方便地进行修改的编码这类消息。对于交互应用这是重要的。一个实例是“小甜饼”管理，服务器必须能够用存储特定站点用户活动的状态信息的码字迅速更新命令的内容。
为了满足借助以下揭示将进一步明显的这些和其他目标，本发明广义地提供一种技术，用于将服务器命令并入MPEG-4客户机。技术涉及命令描述符的使用，即与场景描述信息一起发送并且包含在相关事件触发之后返回服务器的命令的描述符的具体形式。场景描述中所需的事件源与这些命令描述符相关。
在一个实施例中，利用服务器路由完成了关联化。这些同样对传统的MPEG-4 BIFS路由进行操作，但是用源域与转换器命令描述符链接代替了将源域与转换器域链接。服务器路由需要MPEG-4 BIFS ROUTE语法的扩展。
在另一实施例中，利用命令节点实现了关联化。这种节点包含转换器域，并且与命令描述符关联。这种技术涉及一个以上节点类型加入MPEG-4 BIFS节点组。
在两种情况下，对于本地交互性(即生成并在本地客户机上处理的事件)和服务器交互性(即送回服务器的客户机生成命令生成的事件)可以采用MPEG-4定义的普通交互模型。在与命令描述符相关的事件触发之后，经服务器路由或常规路由至命令节点，客户机获取存储在命令描述符内的命令信息，将其分组入命令消息，比较好的是利用较佳实施例中提供的语法，并且利用合适的返回信道将其送回服务器。
生成命令载带的返回服务器的数据包含在命令描述符内。由于命令描述符是MPEG-4整个描述符框架的部分，所以它们可以利用时间戳记对象描述符更新进行动态更新。这在定制命令例如以实现“小甜饼”管理中提供了相当的灵活性。
为了进一步在处理生成命令中辅助服务器，在客户机信息中还包含了附加信息，例如时间事件生成源节点等。
附图简述
图1为示出了MPEG-4客户机或终端总体结构的示意图。
图2示出了MPEG-4系统译码器模型。
图3示出了MPEG-4中所用的方法，用于借助对象描述符和基本流描述符使听觉视觉对象与其它流中的编码数据关联。
图4示出了客户机/服务器的基于MPEG-4的通信系统的一般配置。
图5示出了利用(a)服务器路由和(b)命令路由节点使场景描述符节点(特别是传感器节点)与命令描述符相关的方法。
图6示出了较佳实施例中描述的命令描述符的二进制语法。
图7示出了较佳实施例中描述的命令描述符去除命令的二进制语法。
图8示出了服务器路由结构的二进制语法和如何加入主MPEG-4 BIFS场景语法。
图9示出了命令路由结构的节点语法和语义。
图10示出了预定义命令IDs以及相关解释的指示列表。
图11示出了包含在较佳实施例命令描述符中的命令的二进制语法。
图12为表示当采用服务器路由时触发MPEG-4客户机中服务器命令的过程的流程图。
图13为表示当采用服务器路由时组合放置在返回服务器的命令内数据的过程的流程图。
图14为表示当采用命令路由节点时触发MPEG-4客户机中服务器命令的过程的流程图。
图15为表示当采用命令路由节点时组合放置在返回服务器的命令内数据的过程的流程图。
实施发明的较佳方式
以下借助附图详述本发明的较佳实施例。
MPEG-4是在国际标准化组织(ISO)支持下提出的国际标准。其正式名称为ISO/IEC 14496。其与以前的ISO或ITU标准(例如MPEG-1、MPEG-2、H.261或H.263)的基本差别是它寻址视听对象的表现形式。因此首先利用规定部分2(视觉)和3(音频)中定义的技术分别编码包含音频施加场景的不同单元。这些对象被发送至接收方或者连同场景描述信息一起从海量存储装置读取，场景描述信息描述了如何将这些对象放置在空间和时间上以提供给用户。
每个视听对象以及场景描述信息的编码数据以自己的“信道”或基本流发送。如下所述，为了使接收方能够正确地使场景内提及的视听对象与包含在编码数据内的基本流相关联，还发送了附加控制信息。
为了完整描述MPEG-4的结构，参见图1。在图的下方示出了各种可能的发送系统，包括(但不局限于)在通信链路上或经海量存储装置的ATM、IP、MPEG-2传输流(TS)、DVB。与MPEG-2相反，为了能够在各种通信环境下发送，MPEG-4未定义自己的传输层功能。对于可能缺少合适的多路复用能力(例如GSM无线数据信道)或者要求少延迟的发送系统，定义了称为FlexMux的简单多路复用工具。
该底层结构用来向客户机发送一组基本流。流包含了场景描述信息、视听对象数据(例如诸如MPEG-2或MPEG-4视频流之类的编码视频)或控制信息(即对象描述符)中的任何一种。每个基本流可以只包含一种类型的数据。
包含基本流的数据按照MPEG-4 Sync Leyer(SL)分组，Sync Layer分组下层介质的访问单元(例如视频或音频帧或场景描述命令)并且加入时序信息(时钟基准和时间戳记)、序列号等。图1的中间部分示出了SL。
单独的视听对象数据的编码按照MPEG-4规定的部分2和3进行。进一步还允许利用其他的编码，例如MPEG-1或MPEG-2。场景描述和控制信息(对象描述符)按照MPEG-4部分1的定义编码。
接收方处理场景描述信息和解码的视听对象数据并且完成合成(即将对象组合到一个单元内)和表现(即在用户监视器上显示结果或在音频情况下在用户扬声器内回放的过程)。这示于图1上方。
根据场景描述中包含的信息，用户可以有机会与场景交互。此外，场景描述可以包含使动态行为有效的信息。换句话说，场景本身无需用户干预可生成事件。
与MPEG-2和或其他系统相比，MPEG-4基于对象的结构需要定义更多的通用系统译码器模型。特别是如图2所示，考虑为接收方配备一组译码器，每个对象用一个。每个译码器具有译码缓冲器和合成缓冲器。译码缓冲器由发送方利用与MPEG-2类似的技术管理，即利用时钟恢复的时钟基准和用于从译码缓冲器去除数据的译码时间戳记(理论上译码紧随其后)。放置在合成缓冲器内的数据可被合成器使用并且覆盖先前放置的数据。译码缓冲器由封装在DMIF(数字介质集成框架，MPEG-4部分6)应用接口内的多路复用器填充。这是概念性的接口，无需进一步的描述。
MPEG-4场景描述
MPEG-4中场景描述信息是VRML 2.0(虚拟实体建模语言)说明书的扩展。VRML采用树形结构方法定义场景。场景内的每个节点完成合成和/或分组操作，树结构端结点包含实际的视觉或音频信息。而且节点包含影响行为的域。例如变换节点包含旋转域来定义旋转角度。
由于VRML是纯粹的3-D场景描述语言，所以MPEG-4定义了寻址2-D成分的一些附加节点。这寻址满足了低成本系统应用的需求。与VRML相反，MPEG-4未采用基于文本的场景描述而是定义了称为BIFS(场景的二进制格式)的高效带宽压缩表现形式。
BIFS编码紧随VRML场景的文本定义。特别是，与基于文本的VRML文件类似，节点编码以深度为先的方式完成。如同在VRML中一样，每种节点类型的域被假定为缺省值。因此只有非缺省值的域才需要在每个节点内定义。节点内的域编码利用简单的基于索引的方法完成，其后是编码域值。节点类型编码更为复杂。为了进一步提高带宽效率，考虑了父域(如果有的话)的前后关系。每个接受子节点的域与特定的节点数据类型关联。随后以已知方式，利用针对该节点数据类型的索引编码节点。
每个编码节点也可以分配一个节点标识符(一般为整数)。这可以使该节点在场景的其他位置再次使用。这与VRML的USE/DEF机制类似。但是更为重要的是这使得可以在交互过程中参与。
MPEG-4所用的交互模型与VRML中的一致。特别是，节点域可以担当事件源、事件转换器或者同时二者的作用。事件源与特定的用户动作或系统事件关联。用户事件的实例是可以检测到鼠标点击的传感器节点。系统事件的实例是按照系统时间触发的定时器(事件传感器节点)。
动态场景行为和交互性通过将事件源域与事件转换器域链接实现。利用ROUTEs的机制完成了实际的链接。在场景节点描述之后立即给出了MPEG-4路由定义(如果有的话)。它们的编码基于源和转换器节点的节点标识符和源和转换器域的域标识。
VRML与MPEG-4之间的重要区别是在后者中，可以利用时间戳记命令动态更新场景描述。相反，VRML在静态“世界”上操作。在加载完全之后，没有修改的机制。在MPEG-4中，对象可以增加或删除，并且部分场景(或整个场景)可以替代。
对象描述符
为了具有非常灵活的结构(便于编辑等)，视听对象的实际内容未包含在场景描述本身之内。换句话说，BIFS只提供场景结构信息和纯粹合成的对象，例如利用BIFS/VRML节点构造的红色矩形。需要编码信息的视听对象在场景内用指向URL或对象描述符的叶节点表示。
对象描述符为分层结构信息，描述了包含单个视听对象的编码表现形式的基本流。可能需要不止一个流，例如用于立体声或多语言音频或分层编码视频。最上面的描述符被称为对象描述符，并且是外壳，用来使对象描述符识别符(OD-ID)与一组基本流描述符关联。后者包含ES-ID和包含在与特定ES-ID相关的基本流内的数据类型的信息。该信息告知接收方例如流在主层面的MailProfile之后包含了MPEG-2视频数据。
利用流映射表完成了ES-ID至实际基本流的映射。例如它可以使ES-ID10与支持号1025关联。在建立会话期间该表可为接收方所用。间接的多层次使用便于MPEG-4内容的操作。例如，重新多路复用将只需不同的流映射表。在MPEG-4内容中无需其他信息修改。
对象描述符在自己的基本流内发送，并且按照Sync Layer语法分组入命令。这使得对象描述符可以被更新、增加或去除。
图3示出了对象描述符和基本流用来使场景描述中的视听对象与其基本流相关联的的过程。首先利用特定的初始对象描述符，通过指向对象描述符流和与选定内容相关的场景描述符流启动MPEG-4接收方。这种描述符在建立对话期间送至接收方。
该实例内的场景描述包含音频源节点，它指向其中一个对象描述符。描述符包含未相关的流提供ES-ID的基本流描述符。利用流映射表将ES-ID分解未实际的传输信道。场景还具有影视纹理节点，在这种情况下该节点采用两个流下可伸缩的视频。因此包含了两个基本流描述符，每个指向合适的流(基本和增强层)。
MPEG-4客户机/服务器交互
从上述描述中可见并且考虑MPEG-4/VRML场景描述框架，显而易见的是，虽然提供了丰富的本地交互框架，但是没有实现基于服务器交互的工具。特别是，没有描述返回服务器或触发这种消息生成的机制。
图4示出了示例性的客户机/服务器环境。在图的左侧是MPEG-4服务器，包括完成作为SL分组流读取的数据的定时发送的抽吸和DMIF服务提供者的实例，在这种情况下利用了MPEG-4 FlexMux多路复用工具。
FlexMux的使用是可选的。如本领域内公知的，可以采用其他服务器结构。例如数据源可以是MPEG-4文件代替SL分组流。
服务器处生成的信息被经过网络(例如IP或ATM)送至接收方。在接受侧，我们具有类似的DMIF服务提供商实例，它向播放机发送去多路复用的基本流。DMIF-to-DMIF传信是一种实现会话建立的方法，并且在MPEG-4的部分6内有所描述。正如本领域公知的那样，其他方法也是可行的，包括基于因特网的协议，例如SIP、SDP、RTSP等。
本发明的一个主要目标是一种过程，首先描述服务器命令并从服务器发送至客户机，随后在客户机处以合适的时间触发，最后送回服务器以启动进一步的动作。
命令描述符
命令描述符框架提供了使命令与场景图节点内的事件源关联的手段。当用户与场景交互时，触发相关的事件并且随后处理命令并发送回服务器。
实际交互本身由内容创建者定义并且可以是鼠标点击或鼠标越过或其他形式的交互(例如系统事件)。
命令描述符框架由三个单元组成，命令描述、服务器路由或命令路由节点和命令。
命令描述符包含ID(整数识别符)和最终发送回服务器(如果并且当触发相关事件时)的实际命令。
ID被用来表示来自场景描述信息的命令描述符。通过从场景本身中分离出命令描述符和命令，我们可以使不止一个事件使用同一命令。这还允许在不以任何方式改变场景描述的情况下修改命令。
命令描述符到事件源域节点的关联可以不同方式完成。
首先服务器路由可以加入BIFS的常规路由工具中。与传统路由的差别是路由目标不是另一个域，而是命令描述符。图5(a)示出了这种结构。在该实例中，我们在场景树内具有两个节点使事件域化至两个命令描述符。传感器节点使事件触发至事件源的另一节点、事件出或事件元/转换器、MPEG-4术语中的外露域(它经服务器路由至命令描述符1)。对于命令描述符2，从节点至描述符有直接的服务器路由。
第二种方法包括将新的命令路由节点类型加入MPEG-4支持的节点列表。该节点具有“执行”事件转换器域和包含命令描述符ID的域。无论何时利用常规的MPEG-4/VRML路由“执行”域接收到事件，与该ID相关的命令描述符被用来向服务器回送命令。这种结构示于图5(b)中。与图5(a)相比，服务器路由用命令路由节点替代。两种情况下的操作基本上是相同的。
图6示出了命令描述符的语法。我们采用Flavor介质表现形式语言来描述比特流语法，它也用于MPEG-4规定的部分1(参见www.ee.columbia.edu/flavor或MPEG-4的部分1)。命令描述符开始于特殊的标记，将其识别为这种特定类型的描述符。我们随后有描述符ID，其后是命令ID。后者用来传信预定义的服务器命令，例如“开始”、“暂停”或“停止”。接着，我们在描述符中包含以字节计的其余数据的长度指示。随后提供ES-IDs数的计数用来向服务器返回消息。在需要实现一对多通信的情况下(即单个命令被送至多个服务器)给出的不止一个。其后是一系列所需的ES-IDs。最后，包含了一组针对应用的参数。当触发命令时这些将被送回服务器。根据命令ID的数值，可以预定义这些参数的语义。
命令描述符面向字节的结构使服务器可以容易地生成描述符。对于涉及“小甜饼”管理的应用来说这是重要的特征，在那里命令参数需要服务器在处理每个用户事件之后由服务器连续更新。
为了更新命令描述符，服务器或内容创建者只需发送ID相同的新描述符。
为了去除命令描述符，提供了特定的命令。图7示出了语法。命令以将该描述符识别未命令描述符去除命令的标记开始。随后是被去除的命令描述符的ID。
命令描述符和命令描述符去除结构可以在对象描述符流内执行。由于对象描述符框架的结构，利用识别描述符的标记，这些描述符可以散布在其他描述符中。
如上所述，有两种方式将命令描述符链接至场景。第一种依赖于服务器路由。如图8所示，这些要求扩展MPEG-4场景描述的比特流语法。特别是，主BIFS场景结构经过扩展包含了服务器路由结构。常规路由与服务器路由之间仅有的差异是代替目标节点/域，定义了目标命令描述符的ID。对于本领域内的技术人员来说，如何修改其他路由命令(插入、删除等)以容纳服务器路由是公知的。在所有情况下，需要改变目标节点/域对以指示目标命令描述符。
利用命令路由节点方法，需要定义新的节点类型。在图9中，利用MPEG-4说明书部分1所用的标准节点定义表提供了节点定义。节点只包含两个域，即用作事件转换器的“执行”域和包含指向命令描述符的URL或与该命令路由节点相关的命令描述符的ID的“命令描述符”域。在所有SFUrl域下，利用一个比特的标志完成ID与URL之间的选择(SFUrl域编码在MPEG-4部分1中定义)。
利用命令路由节点方法，改变事件与命令描述符的关联可以利用标准MPEG-4 BIFS命令实现以改变其中的节点和域。
可以利用命令描述符更新来更新命令描述符，使得节点能够根据命令描述符中的命令支持不同时间上的不同交互行为。利用DMIF支持的DAI用户命令元将命令发送至服务器。
也可以扩展命令描述符以包含用来发送命令的协议。例如可以采用不同的标记来指示利用HTTP POST/GET的发送而不是标准的MPEG-4工具。
即使命令描述符框架是通用的并且支持针对应用的用户交互，为了在应用和服务器上支持相容的应用行为，也需要几个标准的命令。对于诸如流控制之类的共用命令特别如此。因此我们定义了一组共用控制命令。为了处理，服务器应该意识到任何针对应用的命令。标准命令组可以与任何服务器配合。图10示出了一组命令连同该实施例的命令ID。对于本领域内技术人员显而易见的是，其他指定也是可行的。
图11示出了从客户机发送至服务器时命令的语法。它基本上是命令描述符减去描述符ID的副本。特别是它包含了命令ID、该命令发送至的ES-ID组以及命令描述符定义的参数组。这些命令在SL分组流中发送，并且因此服务器可以利用完整的时间和序列信息。
发送服务器命令的处理事件
我们现在详细讨论根据用户或系统事件生成命令的过程，它以利用服务器路由开始。
参见图12，在生成用户或系统事件之后，接收方将事件经路由和服务器路由的网络传送。对于事件的传送，路由类型是无关紧要的，从而可以采用相同的算法。如果事件经服务器路由传播，则系统检查事件是否对应与逻辑真值相关的条件。如果否，则服务器命名处理终止；如果是，则执行发送过程。
图13示出了服务器路由下的这种过程。过程包含了来自服务器路由的命令描述符ID。它随后使其与场景内可用命令描述符上的信息相关。如果未找到匹配，则是错误的并且不采取进一步的动作。如果找到匹配，则系统检查命令ID以查看是否对应已知的语义(预定义命令ID)。如果对应已知的语义，则系统可以按照所需的语义处理命令参数。如果不对应已知的语义，则系统跳过该状态，并且直接分组指示的命令并发送至服务器。
对于命令路由节点，参见图14，在生成用户或系统事件之后，接收方经路由网络传送事件。如果事件到达命令路由节点的“执行”域，则系统检查事件是否对应与逻辑真值关联的条件。如果否，则终止服务器处理；如果是，则执行发送过程。
图15示出了命令路由节点情况下的这个过程。步骤基本上与图13的相同，差别在于命令描述符ID的基准现在是在命令路由节点内而不是在服务器路由内。