数字电视传输系统中标引数据的方法 本发明涉及一种在数字电视传输系统中标引数据，尤其是服务信息的方法。本发明用于这种传输系统的接收机中。
某些数字电视系统，例如DVB(直接视频广播)，为所谓的服务信息(‘SI’数据)的传输作好了准备，该服务信息包括例如与接收的数字数据流或其他数字数据流的分级结构有关的信息。这种分级结构可包括几个传输网络，每个网络包括几个信道，而每个信道包括几个服务，等…。
数字电视接收机和译码器必须了解这种分级结构，以便恰当地存取传输数据。但是，这种分级结构的管理的内在问题一方面出现在其展开特性上，另一方面则出现在正常限制上，该正常限制也许不总是与消费电子产品的限制相协调。例如，分级结构中的每个组件(网络、信道、服务等)是由其标准长度相对较大的标识符来识别的，这就产生了存储和处理的问题。为了例如以独有的方式来识别服务，理论上必需8个字节。这8个字节必须在每次参考该服务时使用，并因此由接收机的应用而必须大量次数地进行存储。
本发明地目的是提供一种用于在数字电视传输系统中标引数据的方法，所述系统至少包括一接收机，所述方法的特征在于，在接收机上包括如下步骤：
从传输的数字数据流中提取同类型的网络、信道、服务、事件或描述符的分级结构列表；
为每个提取的列表创建包括所述提取列表的每个组件的地址指针的数组，每个所述地址指针指向其中存储有与每个部件相关的附加信息的接收机的存储区；
采用逻辑密钥来查阅列表中的指定部件，该逻辑密钥包括所属数组中所述指定部件索引和所述分级结构中所述指定部件以上的各部件索引的交叉重叠。
接收机构建表示其已存取的数据分级结构的至少一部分的图像。网络列表、信道列表、服务列表、事件列表、或其他部件的成分列表(服务问候语等)由接收机存储和标引。这种标引大大降低了存储标识符所必需的存储量。
数据的分级结构特性允许仅通过对数组索引进行交叉重叠来为保持在接收机中的数据库的部件创建‘逻辑密钥’。例如，由接收机使用的网络中服务的‘逻辑密钥’是通过该服务所属的网络和信道的数组索引以及服务自身的数组索引来形成的。部件的操纵是通过其‘逻辑密钥’由接收机进行的。一旦建立了索引和部件之间的关系，则接收机将内部使用该索引(而不是部件的标识符)来查阅该部件。该逻辑密钥承载待检索数据的路径，保证了快速存取。
根据变化的实施例，在一系列相同尺寸的几个数组上分布了一部件列表，所述系列中的每个数组包括指向所述系列中下一数组的地址指针。
根据变化的实施例，每个数组包括多个基数为2的部件地址指针。
通过适当地掩蔽部件的逻辑密钥中足够多个比特，基数2的使用可容易地注意到包含指定部件的数组。
通过参照构成本发明不可分割的一部分的附图示出的非限定性的特定示意性实施例的描述，可看出本发明的其他特征和优点：
图1是实现本发明示意性实施例的电视接收机的框图；
图2a至2c是根据本示例，在数据管理模块和数据源之间发生的交换的时序图；
图3a和3b分别是表示单次(one-off)和永久请求操作的状态图；
图4是根据本示意性实施例的一应用下、即电子节目向导的屏幕的示意图；
图5是由管理模块保持的数据库的图表。
可看出，对于有关服务数据的格式和内容、MPEG和DVB表格及单元的更完整信息，可具体参照如下3个文件：
(a)ETS 300 468-数字视频广播(DVB)系统中的服务信息(SI)规范，1996年1月23日；
(b)ISO/IEC 13818-1(1994)运动图象和相关音频的一般编码-推荐本H.220，亦称“MPEGⅡ系统”；以及
(c)ETR 211-用于电视的数字广播系统：使用MPEG-2系统的实施指南；服务信息的实施和使用指南。
图1是DVB(数字视频广播)型数字电视集成译码器/接收机的框图。
很明显，本发明并不局限于该自然环境，也可用于其他类型的服务数据传输环境中。
图1的译码器连接到天线1，天线1与译码器的调谐器2相连。由该调谐器提供的信号由解调器3解调。校正器电路4校正解调的数据，并将其传输到多路分解器5。
后者与汤姆森多媒体公司(THOMSON multimedia)与1995年12月29日申请的法国专利申请95 15767中描述的多路分解器相类似。多路分解器5包括由微处理器23基于由译码器所支持的各种应用块而编程的一些滤波器。为了使该图清楚，仅示出微处理器23中最重要的连接关系。
由于这些应用块的缘故，由该多路分解器滤波的音频或视频分组或单元存储在缓冲存储器6的预定区域中。如果必要，在将信息存储在这个缓冲存储器6之前，首先由脱密电路7根据用户的权利来对该信息进行脱密。
根据本示例，应用块有5个：音频译码器16、视频译码器17、可视数据译码器18、存取控制组件(包括脱密器7、校验器微处理器8、和用于使微处理器卡9以正常操作模式与微处理器卡10相连的接口)、以及服务数据管理模块。
该译码器还包括用于遥控的红外接口24，所述接口又连接到微处理器23。后者与存储器12相连，存储器12中包括操作系统以及用于运行应用块的驻留或下载程序。
与电话交换网(STN)14相连的调制解调器13也由微处理器控制。
字符发生器15产生与译码器参数或特定应用相关的命令或图形菜单。由该字符发生器产生的视频信号采用来自视频译码器17或可视数据译码器8的各视频信号之一来多路复用至连接到电视22的第一TV外围插口(SCART插口)或连接到视频译码器21的第二TV外围插口。多路复用电路20由微处理器23管理。
本发明更具体地涉及服务数据管理模块的操作。在这种情况下，该模块以与音频或视频译码器相同的方式，采用专用电路，来实际发送由微处理器管理的节目，尽管从概念上讲该模块进行的是处理数据分组的应用。
该模块是服务数据(MPEG和DVB表格和单元)与客户应用块(节目向导、电话购物、交互式游戏等)之间的接口。它管理来自客户应用块的请求，并根据接收到的服务数据强度来保持内部数据库。
根据本示意性实施例，客户应用块是一节目向导，它也由微处理器管理。
管理模块为客户应用块赋予一些功能，这些功能用于定义与各应用块所必需的信息有关的请求。
各请求功能异步进行。对请求的响应(如果存在响应的话)由管理模块在该响应可用时向以应用块发出通知。这就要求实现请求功能识别机制。为此，对于发出的每个请求，由该应用块选择识别符，并将该识别符与该请求一同传输。该识别符与管理模块的响应通知密切相关。
图2a至2c表示在一请求下，客户应用块、服务数据管理模块和数据源，即多路分解/缓冲存储器/微处理器组件之间的3种交换的情况。
图2a表示的是内部数据库(“高速缓冲存储器”)包括由客户应用块请求的信息的情况。来自后者的请求之后是该信息可用的通知。当这种情况下的信息出现在数据库中时，响应的通知是拟即时的。在这种情况下，没有数据项向数据源发送或从数据源发送。
图2b示出的情况是所请求的信息项不出现在内部数据库中。在这种情况下，来自客户应用块的请求之后的也是由管理模块向应用块发出的通告信息项暂时不可用的通知，然后是由管理模块向数据源发出的命令。当已经在存储于缓冲存储器中的多路分解数据流中找出相应于寻求的信息项的单元或各单元时，数据源通知模块SI这些单元是可用的。在对该单元数据进行读取和重新格式化之后，管理模块接下来便通知客户应用块寻求的信息项为可用。在客户应用块发出初始请求期间，该模块将该寻求的信息项(可能仅是单元数据的一部分)写到指定的缓冲存储器。因此，这种情况下的通知到达的速度低于图2a的情况。
根据一种变型，管理模块不进行信息项不可用的通知。
图2c表示的情况是诸如图2a的初始请求规定将要发出表示寻求的信息项中的变化的信号。在这种情况下，可从数据流中提取包含该信息项的数据分组的数据源的滤波器保持前面的值，而不是处于停用状态。下面将进一步详细描述这种类型的请求，即所谓的永久请求。
根据本示意性实施例，有4种类型的请求：
(a)唯一请求
当应用块向管理模块发出这种请求时，后者将其资源(滤波器和存储器)仅保持到所请求数据传送的时刻。然后，该资源立刻释放。
(b)超前单次请求
该请求具有单次请求的特性，但其优先级较低。管理模块具有两个FIFO(先进先出)型存储器，一种用于超前请求，而另一种则用于非超前请求。所等待的超前请求总是在非超前请求之后进行处理的。
(c)永久请求
即使在对请求数据进行多路分解和传送之后，仍保持管理模块的资源。每当这些数据发生变化时，向应用块发送通知。因此，管理模块进行系统监测，直至应用块发送中断这种监测的命令为止。
(d)超前永久请求
这种请求类似于永久请求，但优先级较低。
这些请求的优先级当然不预先判断与这些请求有关的数据的实际接收级。这种优先级还取决于诸如每个数据项的周期性及相对于该周期发出请求的瞬间等诸因素。
图3a是单次请求的状态图，而图3b是永久请求的状态图。
每当应用块发出请求时，请求类型必须与其相对应。
在永久请求的情况下，从数据流检索的数据再次存储在管理模块的内部数据库中。这与单次请求时提取数据的情况不同，该情况下不保持数据的副本。当检测到与永久请求有关的表格或描述符的新版本时(即当表格的参数version id改变时)，将该表格或该描述符中的相应数据与数据库中的数据相比较。仅当这些数据项中的至少一个已经发生变化时，才发送更新的通知。不管表格中发生的变化如何，该表格或描述符的版本标识符，即使仅与应用块未请求的数据有关，实际上仍发生变化。这种机制避免了在应用块与管理模块之间传送冗余数据。
请求类型的选择是由应用块进行的。作为应用块关于请求类型的判定准则，图4示出了节目向导屏幕的示意图。该屏幕包括两部分：下部40，通过遥控器选取命令功能；和上部41，包括使用所述命令选择的事件列表。对于每个事件，节目向导均显示标题、相应服务的名称以及起始和结束时间。
上部40可仅显示事件列表的一部分。为了存取其他事件，用户可使用遥控器的滚动箭。
当节目向导应用块向管理模块发出与事件列表的信息有关的请求时，与所显示的事件相关的请求首先为非超前类型，即具有优先级。实际上，这是绝对必须显示的信息。与列表中的其他事件有关的请求为超前型，并且在非超前请求之后由管理模块进行处理。实际上不能确定应用块需要相应的信息，这是因为当用户寻找的特定事件在最初显示的事件中时，不能肯定用户将实际滚动事件栏。为了加快在请求这些数据时显示它们的速度，预先加载这些数据。当已对向应于超前请求的数据进行多路分解时，管理模块通知应用块已经发出这种情况的请求。但是，只要应用块不请求进行向缓冲器的数据传送，则应用块不进行这种传送。
服务数据管理模块的一个作用是对多路分解器的滤波器进行编程。为了实现这种功能并对寻求的数据进行快速存取，根据本示意性实施例，保持已经接入的一网络或各网络的物理结构的图象。
文件a和b定义了10个表格，这些表格给出有关一网络或各网络的结构、及传输的丛、服务和事件的信息。这些表格是由PID(分组识别数据)及表格标识符(table_id)的特定值、即由所述文件定义的值识别的。每个表格均包含版本标识符，这就可能从该表格的一次传输到另一次传输中确定该表格的内容是否发生变化。
版本标识符也可以在描述符或描述符群的级别使用，也可与表格的描述符并行使用。
我们在这里所感兴趣的表格是所谓的NIT表格(指网络信息表格)。NIT表格包括有关给定的传输网络的信息，尤其包括每个传输信道上可用服务的列表(传送流)。
数据管理模块构建网络、信道和可用服务的内部索引。当接通译码器或更新NIT表格时，为每个可用服务分配逻辑密钥。该密钥是保留在模块中的数据库中的该服务的索引，并且包括数组中一部件的索引和其分级结构较高的数组中所连接部件的索引。
在DVB系统中，可通过包括如下变量的路由来唯一地对服务进行定位：
-network_id(网络的标识符)；
-(transport_stream_id；original_network_id)对；
-service_id(特定服务的标识符)。
这3个变量是由16个比特编码的自然整数。
建立了3种类型的列表：一种列表用于网络、一种列表用于每个网络的信道、而最后一种用于每个信道的服务。
每当包括新网络的NIT表格被多路复用时，创建网络列表中的部件。为此，对其PID等于0x0010的传送分组进行过滤。这些分组实际上包含另外由变量table_id识别的NIT表格。按着相应表格的多路分解的次序，每个网络均伴随着一4比特代码。在网络列表中，该代码是包括与该网络有关的信息的结构的地址指针索引。通过扩展，也可是该列表中的网络索引。
NIT表格包括该网络信道的列表和每个信道可用服务的列表。
对于网络列表中的每个网络，创建信道列表。在这个列表中，采用5个比特来标引信道列表的每个部件。该列表包含包括每个信道的特定数据的结构的地址指针。数据库中用于识别信道的逻辑密钥包括网络的4个索引比特，随后是该网络的5比特的信道索引。
对于每个信道，创建服务列表，该列表包含在NIT表格中描述的服务的标识符。列表中的每个服务是以7个比特来标引的。因此，数据库中服务的逻辑密钥总共包括16个比特：4个网络索引比特，5个信道比特和7个服务比特。
服务的事件借助于表示该事件的16个比特(表格的变量event_id)来识别，这16个比特附带有相关服务的16个比特的逻辑密钥。因此，为了获得部件的逻辑密钥，仅交叉重叠相应于唯一定义它们的标识符的索引便可。
数据库(事件以外)的结构是按照下面的结构构成的： Database(数据库)NetworksListAddress(网络列表地址) NetworksList(网络列表) 0NetworkAddress(网络地址) 1NetworkAddress 2NetworkAddress 3NetworkAddress 4NetworkAddress 5NetworkAddress 6NetworkAddress 7NetworkAddressNetworkArrayNextAddress(网络数组下一地址) Network(网络)NetworkIdentifier(网络标识符)(“Network_id”)NetWorkName(网络名称)(“Network_name”)ChannelsListAddress(信道列表地址) ChannelsList(信道列表) 0 ChannelAddress(信道地址) 1 ChannelAddress 2 ChannelAddress 3 ChannelAddress 4 ChannelAddress 5 ChannelAddress 6 ChannelAddress 7 ChannelAddressChannelsArrayNextAddress(信道数组下一地址) Channel(信道)ChannelIdentifier(信道标识符)(“TransportStream_id”)OriginalNetworkIdentifier(初始网络标识符)(“OrigmalNetwork_id”)ServicesListAddress(服务列表地址) ServicesList(服务列表) 0 ServiceAddress(服务地址) 1 ServiceAddress 2 ServiceAddress 3 ServiceAddress 4 ServiceAddress 5 ServiceAddress 6 ServiceAddress 7 ServiceAddressServicesArrayNextAddress(服务数组下一地址) Service(服务)ServiceIdentifier(服务标识符)(“service_id”)ServiceName(服务名称)(“service_name”)Status(状态)(“running_status”)...
其名称中含有“Address(地址)”词语的变量是指向相应于数据结构开头的存储区的指针。
其他变量相应于从数据流中提取出的信息。为便于理解起见，文件(a)中，这些变量位于名称后面的括号中的引号之间。
应注意的是，每个网络、信道和服务列表均以数组形式构成，每个数组一方面由指向网络、信道或服务类型的数据结构的八个指针构成，另一方面由指向包含列表其余部分的可能数组的指针构成。当没有其他数组时，即当数字包含列表的最末部件时，后一指针为空指针。
每个数组包括8个部件，并对应2的幂。在这种情况下，这就能通过掩蔽信道索引的最后3个比特来确定包含所需信道指针的数组。
相同类型的数组(例如所有网络数组)形成相应的列表(这种情况下为网络列表)。给定类型的数组形成虚拟单数组。当分配索引时，则构建列表中的部件索引。由于虚拟单数组的每个数组具有8个部件的长度，因此索引的比特掩码确定哪个数组包括给定的部件。
Database数组包括指向包含网络列表第一部分的数组的指针。
NetworksList数组包括指向首8个网络的指针。根据本实施例，最多有包含完整的网络列表的两个NetworkList数组。
Network数组包括与给定网络有关的信息以及指向与该网络相关的信道列表的指针。
其他数组的结构与前面刚刚描述的相类似。也可更容易地扩展到事件和其他类型数据的情况。
根据一变化的实施例，与涉及网络、信道和服务结构的数据有关的请求是永久型请求，其目的在于一直保持数据库中的最新网络图象。
在与管理模块进行交换时，应用块仅使用逻辑密钥。这些逻辑密钥由该模块转移到存储器中相应于存储信息的位置的地址上。
图5表示存在网络的情况下管理模块数据库的示意图，该网络包含两个信道，每个信道自身又包含两个服务。
数组中的部件位置确定的逻辑密钥传送到应用块。当由应用块向SI管理模块发出请求时，例如当发出当前事件的请求时(参见下面有关当前事件的更详细信息)，发送到SI模块的逻辑密钥是要找出的事件的服务的逻辑密钥。例如，假定逻辑密钥为0000 00001 0000000。运相应于第一网络(索引0)、第二信道(索引1)、第一服务(索引0)。
通过对逻辑密钥中的比特进行移位，确定网络、信道和服务索引，并且在这种情况下读取3个指针(网络、信道和服务指针)。根据当前事件已经存储或未存储在内部数据库的情况，读取服务、传送流…标识符，以计算多路分解器的滤波器。
根据另一示例，逻辑密钥可以是0001 01100 0000000，表明所需服务位于第二网络和第十二信道中。如果如上所述地将信道数组尺寸限制在8个部件以内，则读取4个指针：
-指向第二网络的指针；
-指向信道列表的第二数组的指针(第一信道数组的最后指针)；
-指向服务列表的指针(第二信道数组中的第四指针)；
-指向服务的指针(适当的服务数组中的第一指针)。
指向第二信道数组的指针必须架接各数组之间的间隙，就象第一信道数组仅包含8个部件的情况一样。
在上面的两个例子中，在存取所请求数据之前仅需计算少量的指针。
应用请求的表格得出由应用块当前提出的请求的列表。根据本实例，当前的该请求是用于检索出现在网络上的服务列表的永久型请求。
管理模块请求的表格包括响应于应用请求的原请求(primitive request)。本文中，原请求是可以在多路分解器级转换成单滤波器的请求。在该情况下，假定网络中存在两个信道，必须有两个原请求来转换应用请求，一个是每个服务列表的原请求，另一个是每个信道的原请求。正是管理模块将应用请求分离成原请求。
在图中，可在管理模块请求表格的左方找到相应于每个原请求的滤波器。
假设在图5所示的例子中已经首次获得了服务列表。在应用请求具有永久特性的情况下，保持相应滤波器及与该请求相关的数据库内容。
识别链接列表和该列表中的部件的支路的数字相应于该列表中该部件的索引(逻辑密钥)。
应用块此时试图获得当前在网络中的事件的列表。每个服务中当前有一事件，这就有必要过滤相应的“EIT当前/后续”表格(“事件信息表格”)。
对于指定的服务，由应用块发出的请求包括如下参数：
-请求标识符；
-请求类型；
-所涉及服务的逻辑密钥；
-一组标志，指示在数据库中将存储哪些事件描述符数据；
-数据结构，一方面，包含事件起始时间、其持续期、关于接入控制和事件名称的信息项；另一方面，包含指向一地址的地址指针，其中，由标志识别的数据存储从该地址开始。
根据本示例，假设与当前在第一信道(TS_id=7)中的事件相关的请求是非超前请求，而与当前在第二信道(TS_id=9)中的事件相关的请求是超前请求。这样就使此时例如同时仅显示两个事件，并且首先在屏幕上显示服务1(Service_id=1)和3(Service_id=3)的事件。
为了获得关于当前事件的详细资料，应用块必须发送已经作为原请求的4个不同的请求。后文中假设这些请求不是永久请求。因此，当与各事件有关的数据已经传送到客户应用块时，它们将不存储在内部数据库中。
管理模块查看这些原请求，并将优先处理非超前请求。
由应用块传输的逻辑密钥将分别为：
0.0.0 (十进制表示)
0.0.1
0.1.0
0.1.1
其中，第一个数字代表网络，第二个数字代表(信道、原始网络)对，而第三个数字代表服务。
也可以二进制表示为：
0000 00000 0000000
0000 00000 0000001
0000 00001 0000000
0000 00001 0000001
根据由管理模块保持的列表，可将实际的标识符发送到多路分解器，并给开头的两个请求设置优先级。EIT表格的PID值(PID=0x0012)以及EIT_当前_后续表格的标识符(table_id=0x4E)是由文件(a)定义的，并可通过由请求功能标引的查询表来存取。
借助于该信息，可对多路分解器的一个滤波器进行编程。
根据变化的实施例，在存储容量不足的情况下，将删除至少一些相应于永久超前请求的存储数据。
根据变化的实施例，可改变当前请求的类型。所设想的特定实例是将非超前型永久请求改变成超前型永久请求。这种变化的特殊功能可供客户应用块使用。
根据一变型，管理模块自身产生与网络结构(尤其是网络列表和信道的相关列表)有关的某些请求，并以永久方式保持这些请求。
应注意的是，本发明并不仅仅局限在由卫星传输数据、以无线或有线方式传输数据的情况，也可用于数据流中周期性地出现数据或数据分组的其他任意系统中。对于被记录和读回的数据流而言尤其是如此。
此外，索引的长度可根据应用块的需要而修改：有些电视系统需要少量的网络和信道，有些则需要的多一些。当接收机可监测至少一些类别(网络、信道等)中的部件最大数时，甚至可以动态进行这种调节，并由此调整索引长度来优化其资源的使用。对于分级结构的相同级上的所有列表而言，索引长度，即比特分配数，理所当然地应当相同(即，不管传送流如何，所有服务将具有A个比特的索引，所有事件索引具有B个比特，等)。