发明内容
按照本发明的第一方面,提供了一种用于包括数据部分的MPEG专用表格段的数据结构,该数据结构包括尺寸说明符,它规定段或数据部分的尺寸的度量,所述数据部分包括至少一个数据块,该块或每个块包括一个另外的尺寸说明符,它规定该数据块的尺寸的度量。
具体地,本发明提供了一种组织表格的方法,所述表格包括:一头标;一数据部分,其中该数据部分包括:对应于一第一描述符循环的描述符;数据项目的可变长度循环,其中每个数据项目包括一个数据项目识别符以及一个包括特定于那个数据项目的描述符的描述符循环,其中所述表格被复用于一压缩的数字视频流中。
通过在表格段中除按照传统提供的说明符之外具有一个另外的尺寸说明符,而该另外的尺寸说明符规定特定的数据块的尺寸的度量,则可以消除为MPEG专用表格段的每次使用提供不同的结构的需要,因为能够定义通用数据结构。而且,因为传统的尺寸说明符可被保持,所以表格段可以是后向兼容的。
将会看到,上面提到的MPEG标准尺寸说明符依据在尺寸说明符之后的、段中剩余的字节数来规定该段的尺寸。然而,段或数据部分的尺寸的其他度量属于本发明的范围内。
具体地,为了实现更复杂的数据结构,数据部分优选地包括多个数据块,每个数据块包括各自的、上述的另外尺寸说明符之一。
按照本发明的另一个方面,提供了一种用于包括数据部分的MPEG专用表格段的数据结构,该数据部分包括多个数据块,每个块包括一个尺寸说明符,它规定其各自数据块的尺寸的度量。
该结构还优选地包括数据块列表。
这可以允许还更复杂的数据结构。列表可以不包含块、包含一个块或多个(或甚至多重)块。
优选地,这样的一个列表包括列表说明符,它规定列表中的数据块的总尺寸的度量。这可以允许该数据结构保持为可分析的。列表说明符例如可以规定相关的块的数目或它们整个的长度。
对于还更复杂的数据结构,则该结构优选地包括多个这样的列表。
该结构优选地还包括至少一个块,该块具有对这样的多个列表共同的数据。这可以改进该数据结构的通用性。
由于同一个原因,在上述列表中的该块或每个具有特定于它的具体列表的数据。
当然,将会看到,在这种情况下,对列表的引用包括对该列表所表示的内容的引用。
该结构优选地在这样一个列表中包括多个块。
为了提供更多的功能性到该数据结构,该结构优选地还包括识别符,它代表各个列表的内容。
为了易于分析该数据结构,尺寸说明符被放置在块的标题部分。
优选地,至少一个这样的块包括代表其内容的标志。
因此,具有所需要的数据的块可被检索或被过滤。视要求而定,该标志可以包含与块的内容有关的任何信息。
用于MPEG专用表格的数据结构的优选实施例只包括如上所述的一个结构。
用于MPEG专用表格的数据结构的另一个实施例包括如上所述的多个结构。
因此,可以定义两种通用数据结构,每种数据结构可以具有单独的总结构。这两种通用结构可以取决于环境地被使用。
该结构优选地包括一个MPEG标准标题和一个另外的标题。
优选地,该另外的标题包括一个标记,它代表数据的变换的状态。例如,该标记可以代表数据的压缩或加密的状态。
替换地,或另外地,该另外的标题可包括一个标记,它代表应用到该数据部分的变换的类型。
本发明的另一个方面提供了一种汇编MPEG专用表格的方法,包括提供数据部分和添加代表该数据部分的变换的状态或类型的标记。
上述的标记然后可被使用于以后的处理器(比如接收机/译码器),以确定变换的状态或类型。例如,该标记可被使用来区分压缩的和非压缩的表格,或区分加密的和非加密的表格。该标记的使用也允许采用几个不同的变换算法。这导致更大的灵活性,例如使得对不同种类的数据能够使用不同的算法。
优选地,使数据部分经过变换,诸如压缩或加密。优选地,该标准标题和另外的标题不被压缩和不被加密。这保证与现有的系统硬件和软件相兼容。
优选地,该另外的标题包括一个过滤器说明符、和/或用于规定分析器类型的字段、和/或用于规定优先权的字段,专用表格段将以该优先权被处理的。通常地分析器类型字段是该另外的标题的第一字段。
按照本发明的另一个方面,提供了一种用于MPEG专用表格段的数据结构,包括一个MPEG标准标题、一个另外的标题、和数据部分。
MPEG标准标题的存在可允许与现有的专用表格段的兼容性,同时该另外的标题的存在可允许将附加的功能性合并到该表格段中。
该另外的标题优选地包括代表应用到数据部分上的变换的状态或类型的标记。
该另外的标题优选地包括代表数据压缩状态的标记。因此,可以需要较小的带宽。优选地,该标准标题和另外的标题不是以压缩的形式。
该另外的标题也可包括代表数据加密状态的标记。因而,专用表格段可以只被具有加密码的那些读出。优选地,该标准标题和另外的标题不是以加密的形式。
该另外的标题优选地还包括一个过滤器说明符。因此,可提供增强的功能性来进行数据的过滤。
该另外的标题优选地包括用于规定分析器类型的字段。这可提供更大的通用性。
为了易于分析,分析器类型字段是该另外的标题的第一字段。
此外对于附加的功能性,该另外的标题包括用于规定专用表格段按其被处理的优先权的字段。例如,如果几个同一种类的表格同时被接收,则优先权可被使用来确定它们被处理的次序。
本发明的另一个方面提供了一种对MPEG专用表格执行变换的方法,所述表格包括数据部分,该方法包括压缩数据部分,以便形成变换的数据部分。
本发明的另一个方面提供了一种对MPEG专用表格执行变换的方法,所述表格包括数据部分,该方法包括解压缩数据部分,以便形成变换的数据部分。
本发明的另一个方面提供了一种对MPEG专用表格执行变换的方法,所述表格包括数据部分,该方法包括加密数据部分,以便形成变换的数据部分。
本发明的另一个方面提供了一种对MPEG专用表格执行变换的方法,所述表格包括数据部分,该方法包括解密数据部分,以便形成变换的数据部分。
该方法优选地还包括添加代表对变换的数据部分所执行的变换的状态或类型的标记。
本发明的另一个方面提供了一种对多个数据块执行变换的方法,包括汇编数据块以形成中间块,以及对中间块执行变换,以便形成变换的块。
按照本发明的这个方面,这些数据块是以中间块的形式被批量地处理,而不是单独地和分开地变换每个数据块。这可以减小处理的额外开销。典型的变换过程的例子包括压缩、解压缩、加密和解密。
优选地,变换包括把块分割成多个子块,以及可任选地把代表数据的变换的状态和/或类型的标记加到每个子块。
变换的块可被发送到接收者,和/或从发射机处被接收。
通常该方法还包括对已变换的块执行另外一个变换:通常是所述变换的逆变换。
执行该另外的变换通常包括:汇编子块以便形成另一个中间块,以及对该另一个中间块执行该另外的变换。
标准标题可被加到每个子块。
通常汇编步骤包括:把分别规定各自数据块的尺寸的尺寸说明符包括在中间块内。这使得这些数据块能够在以后的处理步骤中从中间块中被提取出。每个说明符可以处在其各自数据块的前面,或可以用某种其他的方式与其各自数据块相关联。
替换地,在变换的块中的尺寸说明符可被检查,以确定该块应当如何被分割成子块。这使得先前的数据块结构能够被创建。
变换可以是压缩、解压缩、加密和解密。
通常,所述多个数据块属于MPEG专用表格的数据部分。
变换的块通常也被使用来形成变换的MPEG专用表格的一部分。
通常,MPEG专用表格包括多个表格段,每个表格段包括标准标题和数据部分,而变换的MPEG专用表格包括多个表格段,每个表格段包括标准标题和由变换的块提供的变换的数据部分。
在变换的MPEG专用表格中的标题的至少一部分可以基本上等同于在MPEG专用表格中的标准标题的一部分。
该方法还可包括:把规定变换的类型和/或状态的数值包括在变换的MPEG专用表格中。
该方法优选地包括加上目标信息的步骤,目标信息标识作为数据的预定接收者的接收机/译码器或者接收机/译码器组。
例如通过列出所标识的接收机/译码器的智能卡号码,目标信息可以直接标识特定的接收机/译码器或者接收机/译码器组。替换地,目标信息可以用某种间接方式标识接收机/译码器,例如通过标识软件或硬件平台。
本发明的另一个方面提供了一种包括多个压缩的数据块的数据结构,其中压缩的数据块可被解压缩以提供多个解压缩的数据块,每个解压缩的数据块包括数据部分和规定该数据部分的尺寸的尺寸说明符。
通常,被解压缩的数据块的数目多于被压缩的数据块的数目。这减小了处理的额外开销。
通常该数据结构还包括与每个压缩的数据块相关联的标题。
本发明的再一个方面提供了一种包括多个加密的数据块的数据结构,其中加密的数据块可被解密以提供多个解密的数据块,每个解密的数据块包括数据部分和规定该数据部分的尺寸的尺寸说明符。
通常该数据结构还包括与每个解密的数据块相关联的标题。
通常该标题是标准MPEG标题。
本发明的再一个方面提供了一种压缩的MPEG专用表格段和/或一种压缩的MPEG专用表格。标准MPEG专用表格的压缩节省了贮存空间和带宽。
本发明的再一个方面提供了一种加密的MPEG专用表格段和/或一种加密的MPEG专用表格。
本发明的再一个方面提供了一种包括目标信息的MPEG专用表格段或MPEG专用表格,其中目标信息标识作为该MPEG专用表格段的预定接收者的接收机/译码器或接收机/译码器组。
目标信息可以直接标识特定的接收机/译码器或接收机/译码器组,例如通过列出所标识的接收机/译码器的智能卡号码而进行。替换地,目标信息可以用某种间接方式标识接收机/译码器,例如通过标识软件或硬件平台。
本发明的再一个方面提供了一种汇编MPEG专用表格段的方法,该方法包括插入目标信息,它标识作为该MPEG专用表格段的预定接收者的接收机/译码器或者接收机/译码器组。
本发明的再一个方面提供了用于汇编MPEG专用表格的设备,该设备包括用于提供已经过变换的被变换的数据部分的装置,以及用于添加代表变换类型的标记的装置。
本发明的再一个方面提供了用于对MPEG专用表格执行变换的设备,所述表格包括数据部分,该设备包括用于对数据部分进行压缩、解压缩、加密和/或解密以便形成变换的数据部分的装置。
本发明的再一个方面提供了用于对多个数据块执行变换的设备,该设备包括用于汇编数据块以形成中间块的装置,以及用于对中间块执行变换以便形成变换的块的装置。
本发明的再一个方面提供了用于汇编MPEG专用表格段的设备,该设备包括用于插入目标信息的装置,该目标信息标识作为该MPEG专用表格段的预定接收者的接收机/译码器或接收机/译码器组。
按照本发明的另一个方面,提供了一种用于分析包括数据部分的MPEG专用表格段的分析器,包括用于分析数据的装置(例如,以具有相关联的存储器的处理器的形式),所述数据是以一种包括规定段或数据部分的尺寸度量的尺寸说明符的格式,所述数据部分包括至少一个数据块,该块或每个块包括规定该数据块的尺寸度量的一个另外的尺寸说明符。
优选地,该分析器适用于分析具有如下格式的数据,在该格式中数据部分包括多个数据块,每个数据块包括各自的这种另外的尺寸说明符之一。
在本发明的另一个方面,提供了一种用于分析包括数据部分的MPEG专用表格段的分析器,所述数据部分包括多个数据块,每个块包括规定其各自的块的尺寸度量的尺寸说明符。
优选地,该分析器适用于分析具有进一步包括块列表的格式的数据。
优选地,该分析器适用于分析具有如下格式的数据,在该格式中上述列表包括列表说明符,该列表说明符规定在该列表中的块的总尺寸的度量。
优选地,该分析器适用于分析具有包括多个这样的列表的格式的数据。
优选地,该分析器适用于分析具有如下格式的数据,在该格式中数据进一步包括至少一个块具有这样的多个列表所共有的数据。
优选地,该分析器适用于分析具有如下格式的数据,在该格式中处于这样的列表中的该块或每个块具有特定于其具体列表的数据。
优选地,该分析器适用于以这样的方式来分析数据,即:这样的特定数据优先于这样的共有数据。
优选地,该分析器适用于分析具有在这样的列表中包括多个块的格式的数据。
优选地,该分析器适用于分析具有进一步包括代表各个列表内容的识别符的格式的数据。
优选地,该分析器适用于分析具如下格式的数据,在该格式中尺寸说明符被放置在块的标题部分中。
优选地,该分析器适用于分析具有如下格式的数据,在该格式中至少一个这样的块包括代表其内容的标志。
优选地,该分析器适用于分析具有只包括一个MPEG段的格式的数据。
替换地,该分析器适用于分析具有包括多个MPEG段的格式的数据。
优选地,该分析器适用于分析具有包括一个MPEG标准标题和一个另外标题的格式的数据。
按照本发明的再一个方面,提供了一种用于分析MPEG专用表格段的分析器,包括用于分析具有包括一个MPEG标准标题、一个另外的标题和数据部分的格式的数据的装置(例如,以具有相关联的存储器的处理器的形式)。
优选地,该分析器适用于分析具有如下格式的数据,在该格式中该另外的标题包括代表变换的状态或类型的标记。
优选地,该分析器适用于分析具有如下格式的数据,在该格式中该另外的标题包括代表数据的压缩的状态的标记。
优选地,该分析器适用于分析具有如下格式的数据,在该格式中该另外的标题包括代表数据的加密的状态的标记。
优选地,该分析器适用于分析具有如下格式的数据,在该格式中该另外的标题包括过滤器说明符。
优选地,该分析器适用于分析具有如下格式的数据,在该格式中该另外的标题包括用于规定分析器类型的字段。
优选地,该分析器适用于分析具有如下格式的数据,在该格式中分析器类型字段是该另外的标题的第一字段。
优选地,该分析器适用于分析具有如下格式的数据,在该格式中该另外的标题包括用于规定优先权的字段,专用表格段将以该优先权被处理。
按照本发明的再一个方面,提供了一种用于分析包括MPEG标准标题和数据部分的MPEG专用表格段的分析器,所述MPEG标准标题包括TID扩展字段,该分析器包括用于输出TID扩展字段的数值的装置(例如,以具有相关联的存储器的处理器的形式)。先前,TID扩展字段被忽略。
按照本发明的再一个方面,提供了一种用于处理数据的设备,包括这样的装置(例如,以具有相关联的存储器的处理器的形式):它用于在给定的格式和具有如在此所述的数据结构的格式的数据之间转换这种数据。
按照本发明的再一个方面,提供了用于汇编MPEG专用表格的设备,包括用于提供数据部分的装置(例如,以具有相关联的存储器的处理器的形式)和用于添加代表该数据部分的变换的状态或类型的标记的装置(例如,以具有相关联的存储器的处理器的形式)。
优选地,该数据部分是已经过变换的被变换的数据部分。
按照本发明的再一个方面,提供了用于对MPEG专用表格执行变换的设备,所述表格包括数据部分,该设备包括用于压缩、解压缩、加密或解密数据部分以便形成变换的数据部分的装置(例如,以具有相关联的存储器的处理器的形式)。
优选地,该设备还包括用于添加代表被变换的数据部分的变换状态标记的装置(例如,以具有相关联的存储器的处理器的形式)。
优选地,该设备还包括用于添加代表对数据部分执行的变换类型的标记的装置(例如,以具有相关联的存储器的处理器的形式)。
按照本发明的再一个方面,提供了用于对多个数据块执行变换的设备,包括用于汇编数据块以形成中间块的装置(例如,以具有相关联的存储器的处理器的形式)和用于对中间块执行变换以便形成变换的块的装置(例如,以具有相关联的存储器的处理器的形式)。
优选地,该执行装置包括用于把一个块分割成多个子块的装置(例如,以具有相关联的存储器的处理器的形式)。
优选地,该设备还包括用于添加代表数据变换到子块的状态的标记的装置(例如,以具有相关联的存储器的处理器的形式)。
优选地,该设备还包括用于添加代表到子块的变换类型的标记的装置(例如,以具有相关联的存储器的处理器的形式)。
优选地,该设备还包括用于把变换的块发送到接收者的装置(例如,以具有相关联的存储器的处理器的形式)。
优选地,该设备还包括用于接收该已变换的块的装置(例如,以具有相关联的存储器的处理器的形式)。
优选地,该设备还包括用于对变换的数据块执行另外一个变换的装置(例如,以具有相关联的存储器的处理器的形式)。
优选地,所述另外的变换是所述变换的逆变换。
优选地,该设备还包括用于汇编子块以便形成另一个中间块的装置(例如,以具有相关联的存储器的处理器的形式)和用于对该另一个中间块执行另外一个变换的装置(例如,以具有相关联的存储器的处理器的形式)。
优选地,该设备还包括用于把标准标题加到每个子块的装置(例如,以具有相关联的存储器的处理器的形式)。
优选地,该设备还包括用于把尺寸说明符包括在中间块内的装置(例如,以具有相关联的存储器的处理器的形式),其中每个说明符规定各自数据块的尺寸。
优选地,该设备还包括用于检查块中的尺寸说明符以确定该块应当如何被分割成子块的装置。
优选地,所述变换是压缩、解压缩、加密或解密。
优选地,所述多个数据块是MPEG专用表格的数据部分。
优选地,该设备还包括用于形成变换的MPEG专用表格的装置(例如,以具有相关联的存储器的处理器的形式),其中该变换的MPEG专用表格具有至少一个由变换的块提供的被变换的数据部分。
优选地,该设备还包括用于把规定变换类型的数值包括在变换的MPEG专用表格中的装置(例如,以具有相关联的存储器的处理器的形式)。
优选地,该设备还包括用于把规定被变换的数据部分的变换状态的数值包括在变换的MPEG专用表格中的装置(例如,以具有相关联的存储器的处理器的形式)。
优选地提供了一种包括如上所述的分析器的接收机/译码器。然而,本发明并不限于接收机/译码器,而是能够以例如PC机方式被实施。
数据可以在广播流中被发送。然后,数据可以在接收机端从广播流中被提取。
在优选实施例中,该方法在包括数字广播中心与多个接收机/译码器的系统中被使用。
数据然后可以在各种各样的任务中被使用。例如,它可包含行动通知数据,用于控制接收机/译码器的功能。替换地,数据可包含密钥数据,由接收机/译码器使用以获得对一条件接入系统的接入。
替换地,该数据可包含在视频点播系统中使用的节目信息。
优选地,数据部分或块包含关于给定类别的至少一个有用资源(asset)的节目信息,以及数据部分或块附有过滤器说明符,该过滤器说明符包含标识所述类别的类别识别符。有用资源优选地是通过视频点播系统可得到的电视节目或其他提供品,有用资源优选地按照它们的内容被归类;例如,可以有体育类别、电影类别等等。也可以有子类别。这样,可以对于类别识别符执行过滤,使得在想要的类别中的有用资源的信息更容易被检索。
替换地或另外地,数据部分或块包含关于有用资源的节目信息,以及数据部分或块附有过滤器说明符,该过滤器说明符包含标识所述有用资源的有用资源识别符。这使得特定的有用资源的信息更容易被检索。
优选地,该过滤器说明符是MPEG表格段的TID扩展字段。由于许多接收机/译码器按照包括TID扩展字段的多个标题字段来提供用于过滤MPEG表格段的设施,以及由于这样的设施常常以硬件方式被提供,所以当TID扩展字段以这样的方式被使用时,信息可以更容易和更快速地被这样的译码器检索。
该接收机/译码器优选地包括用于接收TID扩展字段的数值和用于处理这类数值的装置(例如,以具有相关联的存储器的处理器的形式)。
该接收和处理装置优选地适用于处理像给接收机/译码器的用户的通知之类的数值。
该接收和处理装置优选地适用于处理像涉及接收机/译码器接收的内容的数据之类的数值。
优选地提供了一种接收机/译码器,它适用于接收和/或译码如前所述的数据结构中的数据,或如前所述的被汇编、处理或变换的数据。
一种发射机,适用于发送如前所述的数据结构中的数据,或如前所述的被汇编、处理或变换的数据。
还提供了一种引入上述的接收机/译码器和发射机的广播系统。
该广播系统中的数据优选地是条件接入数据,该系统适用于在分开的信道上发送和接收这样的数据。
还提供了一种处理数据的方法,包括在给定的格式和具有如前所述数据结构的格式的数据之间转换这种数据。该给定格式可以是希望把该数据从如前所述的数据结构的格式转换到的任何格式或者是从其转换出的任何格式。
按照本发明的再一个方面,提供了一种发送MPEG专用表格的方法,包括通过使用在此描述的方法对MPEG专用表格执行变换,以及发送该变换的表格。
另一个方面,提供了一种接收MPEG专用表格的方法,包括接收MPEG专用表格以及通过使用在此描述的方法对所接收的表格执行变换。
优选地,数据部分或块包含行动通知数据,供接收机/译码器接收,以及用于控制接收机/译码器的功能。
优选地,数据部分或块包含在视频点播中使用的节目信息。
优选地,数据部分或块包含关于给定类别的至少一个有用资源的节目信息,以及其中数据部分或块附有过滤器说明符,该过滤器说明符包含标识所述类别的类别识别符。
优选地,数据部分或块包含关于有用资源的节目信息,以及数据部分或块附有过滤器说明符,该过滤器说明符包含标识所述有用资源的有用资源识别符。
优选地,该过滤器说明符是MPEG表格段的TID扩展字段。
优选地,数据部分或块可包含密钥数据,由接收机/译码器使用以获得对一条件接入系统的接入。
本发明的再一个方面提供了一种分析器,它包括这样的装置(例如,以具有相关联的存储器的处理器的形式):用于分析如这里描述的MPEG专用表格或表格段,或用于分析具有如这里描述的数据结构的数据,或用于分析已经由如这里描述的方法处理、汇编或变换过的数据。
本发明的再一个方面提供了一种发射机,该发射机适用于发射如这里描述的MPEG专用表格或表格段,或已经由如这里描述的方法处理、汇编或变换过的MPEG专用表格或表格段。
本发明的再一个方面提供了一种适用于执行如这里描述的方法的分析器。
本发明还提供了一种基本上如参照附图在这里描述的方法,以及基本上如参照附图在这里描述的、并在附图中图示的设备。
本发明扩展到适用于执行如前所述的方法的计算机程序产品。
本发明还扩展到体现如上所述的分析器或设备的计算机可读的媒体。
本发明更进一步扩展到有形地体现如上所述的分析器或设备的信号。
本发明还提供了用于实行这里描述的任何方法和/或用于体现这里描述的任何设备特性的计算机程序和计算机程序产品,以及其中存储有用于实行这里描述的任何方法和/或用于体现这里描述的任何设备特性的程序的计算机可读的媒体。
本发明还提供了体现用于实行这里描述的任何方法和/或用于体现这里描述的任何设备特性的计算机程序的信号、发送这样的信号的方法、以及具有如下操作系统的计算机产品,其中该操作系统支持用于实行这里描述的任何方法和/或用于体现这里描述的任何设备特性的计算机程序。
用硬件方式实施的特性通常可以用软件方式被实施,且反之亦然。这里涉及的任何软件和硬件特性应当被据此来解释。
本发明的某一个方面的任何特性能够以任何适当的组合被应用到本发明的其他方面。具体地,方法方面能够被应用到设备方面,且反之亦然。
具体实施方式
系统总貌
图1中显示数字电视系统1的总貌。本发明包括使用已知的MPEG-2压缩系统来发送压缩的数字信号的最传统的数字电视系统2。更详细地,在广播中心内的MPEG-2压缩器3接收数字信号流(通常是视频信号流)。压缩器3通过联接5被连接到复用器和扰码器4。
复用器4接收多个另外的输入信号、汇编输送流、以及把压缩的数字信号通过联接7发送到广播中心的发射机6,联接7当然可以采取各种各样的形式,包括电信链路。发射机6通过上行链路8向卫星转发器9发送电磁信号,在该处它们被电子地处理,并通过抽象的下行链路10广播到地面接收机12,后者在传统上是以由最终用户拥有的或租用的碟形天线的形式。用于数据传输的其他输送信道当然是可能的,诸如地面广播、电缆传输、组合的卫星/电缆链路、电话网等等。
由接收机12接收的信号被发送到由最终用户拥有或租用并被连接到最终用户的电视机14的集成式接收机/译码器13。接收机/译码器13把压缩的MPEG-2信号译码成用于电视机14的电视信号。虽然图1中显示分开的接收机/译码器,但接收机/译码器也可以是集成数字电视的一部分。正如这里所使用的,术语“接收机/译码器”包括诸如机顶盒那样的分开的接收机/译码器、以及在其内集成有接收机/译码器的电视机。
在多信道系统中,复用器4处理从多个并行的源接收的音频和视频信息,并与发射机6交互作用,沿相应数目的信道广播该信息。除了音频图象信息以外,消息或应用或任何其他种类的数字信号都可以与发送的数字音频和视频信息交织地被引入到这些信道中的部分或全部信道。
条件接入系统15被连接到复用器4和接收机/译码器13,该系统部分位于广播中心,部分位于接收机/译码器中。它使得最终用户能够从一个或多个广播供应商处接入数字电视广播。智能卡能够解密与商业提供品(也就是由广播供应商出售的一个或几个电视节目)有关的消息,它可被插入到接收机/译码器13中。通过使用接收机/译码器13和智能卡,最终用户可以用预订模式或按观看付费模式购买商业提供品。
如上所述,由系统发送的节目在复用器4处被加扰,加到给定传输上的条件和加密密钥由接入控制系统15确定。这样被加扰的数据的传输在付费电视系统领域中是熟知的。通常,被加扰的数据连同用于数据的解扰的控制字一起被发送,控制字本身被所谓的使用密钥加密,并以加密的形式被传输。
加扰的数据和加密的控制字然后被接收机/译码器13接收,接收机/译码器13有权接入使用密钥的等价物,以便解密被加密的控制字以及此后解扰该发送的数据,其中使用密钥的等价物被存储在插入到接收机/译码器的智能卡上。付费的订户例如将在每月广播的EMM(权利管理消息)中接收对被加密的控制字进行解密所必须的使用密钥,以便允许观看传输。
互动系统16,也被连接到复用器4和接收机/译码器13,并且也是部分位于广播中心和部分位于接收机/译码器,它使得最终用户能够通过后向信道17与各种应用互动。后向信道例如可以是公共交换电话网(PSTN)信道(例如,调制解调器后向信道)或带外(OOB)信道。后向信道也可被用于在条件接入系统15中使用的通信。
条件接入系统
参照图2,在总体上条件接入系统15包括用户授权系统(SAS)30。SAS 30通过链路34(它可以是TCP-IP链路或其他类型的链路)被连接到一个或多个用户管理系统(SMS)32,每个广播供应商使用一个SMS。替换地,一个SMS可以在两个运营商之间共享,或一个运营商可以使用两个SMS等等。
以利用“母”智能卡38的密码单元36的形式的第一加密单元通过联接40被连接到SAS。仍然以利用母智能卡44的密码单元42的形式的第二加密单元通过联接46被连接到复用器4。接收机/译码器13接收“子”智能卡48。该接收机/译码器通过通信服务器50和调制解调器后向信道17被直接连接到SAS 30。SAS按请求而尤其把预订权利发送到子智能卡。
智能卡包含来自一个或多个运营商的保密信息。“母”智能卡加密不同种类的消息,而“子”智能卡解密这些消息,如果它们具有这样做的权利的话。
参照图2,在广播中心,数字视频信号首先通过使用MPEG-2压缩器3被压缩(或减小比特率)。压缩的信号然后被发送到复用器和加扰器4,以便与其他数据(诸如其他压缩的数据)复用。
加扰器生成控制字,控制字在加扰过程中被使用以及在复用器4中被包括在MPEG-2流中。控制字被内部地生成,它使得最终用户的集成式接收机/译码器13能够对节目解扰。
表明该节目如何被商品化的接入准则也被加到MPEG-2流中。该节目可以在多个“预订”模式之一和/或多个“按观看付费”(PPV)模式或事件之一下被商品化。在预订模式下,最终用户预订一个或多个商业提供品或“花束(bouquet)”,从而得到观看在这些花束内的每个频道的权利。在按观看付费的模式下,向最终用户提供购买他希望的事件的能力。
控制字和接入准则都被使用来构建权利控制消息(ECM);这是与一个加扰的节目有关的、被发送的消息;该消息包含控制字(它供节目的解扰使用)和广播节目的接入准则。接入准则和控制字通过联接46被发送到第二加密单元42。在这个单元中,ECM被生成、被加密并被发送到复用器与加扰器4。
在数据流中由广播供应商广播的每个业务包括多个不同的组成部分;例如,电视节目包括视频组成部分、音频组成部分、子标题组成部分等等。业务的这些组成部分的每一个被单独地加扰和加密,以用于以后的广播。在业务的每个被加扰的组成部分方面,需要分开的ECM。
复用器4接收电信号,它包括来自SAS 30的加密的EMM、来自第二加密单元42的加密的ECM、和来自压缩器3的压缩的节目。复用器4对节目进行加扰,以及把加扰的节目、加密的EMM、和加密的ECM作为电信号发送到广播系统54,该广播系统可以是例如图1所示的卫星系统,或其他广播系统。接收机/译码器13对信号解复用,从而得到带有加密的EMM和加密的ECM的加扰的节目。
接收机/译码器接收广播信号并提取MPEG-2数据流。如果节目被加扰,则接收机/译码器13从MPEG-2数据流中提取相应的ECM,并把该ECM传送到最终用户的“子”智能卡48。该卡被插置在接收机/译码器13的外壳中。子智能卡48控制最终用户是否有权利解密ECM和接入到节目。如果没有权的话,把否定的状态传送到接收机/译码器13,表示节目不能被解扰。如果最终用户确实拥有该权利,则解密ECM以及提取控制字。译码器13然后可以使用该控制字对节目进行解扰。MPEG-2流被解压缩并被转变为视频信号,以用于向前传输到电视机14。
如果节目没有被加扰,则没有ECM与MPEG-2数据流一起被发送,于是接收机/译码器13解压缩数据,并把该信号改变为视频信号,以用于传输到电视机14。
用户管理系统(SMS)32包括数据库52,它主要管理所有的最终用户文件、商业提供品(诸如价格表和推销)、预订、PPV细节、和有关最终用户消费和授权的数据。SMS在物理上可以远离SAS。
SMS 32发送消息到SAS 30,这些消息暗示对要被发送到最终用户的权利管理消息(EMM)的修正或建立。SMS 32还发送消息到SAS 30,该消息暗示没有EMM的修正或建立,而是暗示仅仅最终用户的状态的改变(涉及到在订购产品时准许给最终用户的授权或涉及到最终用户将被收费的量)。SAS 30还发送消息(通常为请求信息,诸如回呼信息或计费信息)到SMS 32,这样将会看到二者之间的通信是双向的。
权利管理消息(EMM)
EMM是仅仅专用于单独的最终用户(预订用户)或一组最终用户的消息,与ECM相对比,ECM仅仅专用于一个被加扰的节目,或专用于一组被加扰的节目,如果是同一个商业提供品的一部分的话。
各种特定类型的EMM是可能的。单独的EMM是专用于单独的用户,且通常被使用于按观看付费业务的供应;这些EMM包含组识别符和用户在该组中的位置。所谓的“组”预订EMM是专用于比如256个单独的用户的组,且通常在某些预订业务的经营中被使用。观众EMM是专用于整个观众。“观众”是拥有附带同一个运营商识别号(OPI)的智能卡的用户的全体。最后,“唯一的”EMM被寻址到智能卡的唯一识别符。
现在参照图3描述在优选实施例中使用的EMM的一般形式。基本上,作为一系列数字数据比特被实施的EMM包括标题60、EMM固有部分62、和签名64。标题60本身又包括用来标识EMM的类型的类型识别符66、给出EMM的长度的长度识别符68、用于EMM的可任选的地址70、运营商识别符72、和密钥识别符74。最后,签名64也是可任选的,它提供对抗EMM中的其余数据的讹误的多个检验。标题中的类型识别符标识该消息为EMM。
用户授权系统(SAS)
由SMS 32生成的消息通过联接34被传送到用户授权系统(SAS)30,该系统又依次生成对接收到由SMS 32生成的消息进行确认的消息,并把这些确认传送到SMS 32。可被传送到SAS的消息包括:用户暂停,例如由于未付费;用户修正,例如加上或去除某些商业提供品;以及提供权利,例如用于在PPV模式下的特定事件。
SAS 30管理存储有SMS 32所宣布的所有用户的状态的数据库,。按照由SMS发送的状态和各种消息,SAS生成用于用户的智能卡的EMM。EMM被SAS密码单元36进行加密,并被发送到复用器4。为了确保EMM被用户接收,SAS周期性地发送这些消息。该周期取决于EMM的类型,但通常介于30秒到30分钟之间。
图4上显示SAS 30的典型的配置。总体地,SAS 30包括:预订链区域100,它对于预订模式给予权利并且每月自动延续该权利;按观看付费(PPV)链区域102,它对于PPV事件给予权利;以及EMM注入器104,它用于把由预订与PPV链区域创建的EMM传送到复用器与加扰器4,并因此向MPEG流馈送以EMM。如果准许其他的权利,诸如在下载计算机软件到用户个人计算机的情形下按文件付费(PPF)的权利,则也提供其他类似的区域。
SAS 30的一个功能是管理对电视节目的接入权利,其中该电视节目可作为预订模式下的商业提供品而可获得或者按照不同的商业化模式(预约模式,促销模式)作为PPV事件而被销售。SAS 30按照那些权利和从SMS 32接收的信息,生成用于用户的EMM。
预订链区域100包括:命令接口(CI)106、用户技术管理(STM)服务器108、消息生成器(MG)110、以及密码单元36。PPV链区域102包括:授权服务器(AS)112;数据库服务器114、116,它们包含用于存储最终用户的相关细节的关系数据库;定购集中式服务器(OCS)118;用于节目广播者的服务器(SPB)120;消息生成器(MG)122,它的功能基本上与用于预订链区域的MG相同;以及密码单元36。
EMM注入器104包括多个消息发送器(ME)124、126、128和130,以及软件复用器(SMUX)132和134。在优选实施例中,有两个ME 124和126用于消息生成器132,同时有另两个ME 128和130用于消息生成器134。ME 124和126被连接到SMUX 132,而ME 128和130被连接到SMUX 134。
消息生成器110和122把分别由STM 108和OCS 118发出的命令转换成EMM。MG确定EMM的持续时间和发送速率。MG还通过使用专用的密码单元加密EMM。然后它们把加密的EMM传送到周期地发送EMM的各个ME。如图4所示,多于一个的ME能够被连接到单一的MG上,适合的ME由MG按照在EMM中所涉及的运营商来确定。在给定的EMM的使用期限内,MG把其存储在它自己的数据库内。只要EMM的发送持续时间已经到期,就从数据库中删除该EMM。该数据库确保在MG与ME之间的一致性。
消息发送器124、126、128、130接收来自各自MG的EMM和几个参数,,所述参数是诸如广播开始日期、广播停止日期、和广播周期。然后,MG按照所规定的参数管理EMM的广播。
接收机/译码器
参照图5,现在按照功能块来描述接收机/译码器13的各个单元。
接收机/译码器13,例如可以是数字机顶盒(STB),它包括中央处理器220,该处理器包括相关联的存储器单元并且适合于从串行接口221、并行接口222、调制解调器223(被连接到图1的调制解调器后向信道)和在译码器的前面板上的开关触点224接收输入数据。
该接收机/译码器附加地适合于通过控制单元226从红外遥控器225接收输入,以及还处理两个智能卡读取器227、228,该读取器分别适合于读银行和预订智能卡242、240。预订智能卡读取器228与插入的预订卡240和条件接入单元229相接合,以提供必要的控制字到解复用器/解扰器230,从而使得加密的广播信号能够被解扰。该译码器还包括传统的调谐器231和解调器232,用于在单元230进行过滤和解复用之前接收和解调卫星传输。
正如本说明中使用的,应用优选地是一段计算机代码,该代码用于优选地控制接收机/译码器13的高级别功能。例如,当最终用户把遥控器225对准在电视机14的屏幕上看到的按钮目标并按下确认键时,与该按钮相关联的指令序列被运行。
互动应用在最终用户的请求下提出菜单和执行命令,以及提供与应用的目的有关的数据。应用可以是驻留的应用,也就是被存储在接收机/译码器13的ROM(或FLASH(闪存)或接收机/译码器13的其他非易失性存储器)中,或者可以被广播或下载到接收机/译码器13的RAM或FLASH存中。
应用被存储在位于接收机/译码器13的存储器中,并被表示为资源文件。该资源文件包括图形对象描述单元文件、变量块单元文件、指令序列文件、应用文件和数据文件,正如在上述的专利说明中更详细地描述的。
接收机/译码器包含存储器,它被划分成RAM组、FLASH组、和ROM组,但这种物理组织不同于逻辑组织。该存储器还可被划分成与各种接口相关联的存储器组。从某一个观点看来,该存储器可被看作是硬件的一部分;从另一个观点看来,存储器可被看作是对除了硬件以外所显示的整个系统的支持或包含。
接收机/译码器的结构
接收机/译码器包含五个软件层,它们被如此组织,使得软件可以在任何接收机/译码器中以及用任何操作系统来实施。参照图6,各个软件层是应用层250、应用编程接口(API)层252、虚拟机层254、设备层256和系统软件/硬件层258。
应用层250包括驻留在或是被下载到接收机/译码器中的应用。它们可以是由顾客使用的、用例如Java、HTML、MHEG-5或其他语言编写的互动应用,或者它们可以是由接收机/译码器使用来运行这种应用的应用。这个层是基于由虚拟机层提供的开放的应用编程接口(API)组。这个系统允许应用被动态地或按要求地被下载到接收机/译码器中的闪速或RAM存储器。可以通过使用诸如数据贮存媒体命令和控制(DSMCC)、网络文件服务器(NFS)或其他协议、以压缩的或未压缩的格式来发送应用代码。
互动应用是用户与其互动(例如得到产品和服务)的应用,诸如电子节目向导、电脑化银行应用和游戏。以下的驻留应用被使用来管理互动应用:
·引导.引导应用260是当接收机/译码器接通电源时起动的第一个应用。引导应用启动虚拟机中不同的“管理器”,其中第一个是应用管理器262。
·应用管理器.应用管理器262管理在接收机/译码器中运行的互动应用,也就是,它启动、停止、暂停、继续、操纵事件和处理在应用之间的通信。它允许多个应用立即运行,因此涉及到它们之间的资源的分配。这个应用对于用户是完全透明的。
·设立.设立应用264的用途是配置接收机/译码器,主要是在其第一次使用时。它执行诸如扫描电视频道、设置日期和时间、建立用户喜爱项等之类的行动。另一方面,设立应用可以由用户在任何时间使用,用来改变接收机/译码器的配置。
·跳过广告节目.跳过广告节目应用268被用于通过使用节目向上、节目向下和数字键来改变频道。当跳过广告节目的另一个形式例如通过大标题(banner)(导引)应用而被使用时,上述的跳过广告节目应用被停止。
·回呼.回呼应用被使用来提取被存储在接收机/译码器存储器中的各种参数的值,以及通过调制解调器后向信道17或通过其他装置把这些值返回到运营商。
API层252对于互动应用开发提供了高级别的效用。它包括组成这个高级别API的几个包。这些包提供对于运行互动应用所必须的全部功能。这些包是应用可访问的。
在优选实施例中,API适用于运行以Java编程语言编写的应用。而且,它能够解译HTML和其他格式,诸如MHEG-5。除了这些解译器以外,它还包括其他包和业务模块,它们是按要求指示可分离和可扩展的。
虚拟机层254由语言解译器和各种模块及系统组成。它包含对于接收和执行接收机/译码器中的互动应用所必须的每件事物。
设备接口层256包括设备管理器和设备。设备是软件模块,它包含管理外部事件和物理接口所必须的逻辑资源。设备层管理在驱动器与应用之间的通信信道,以及提供增强的错误异常检验。被管理的设备的某些例子是:读取器、调制解调器、网络、PCMCIA(个人计算机存储器卡国际协会)、LED显示器等等。编程器不必直接处理这个层,因为API层从上面控制这些设备。
系统软件/硬件层258由接收机/译码器的制造商提供。因为系统的模块化,以及因为由OS供应的业务(诸如事件调度和存储器管理)是虚拟机的一部分,所以更高的层不受限于特定的实时操作系统(RTOS)或特定的处理器。
MPEG系统
传统的数字电视广播系统以离散的输送流分组或输送分组的形式发送数据,每个分组具有预定的长度以及包含标题与主体。MPEG标准是当前在这个领域中受欢迎的标准,尤其是,它宣布了用于这样的分组的预定格式。
分组标题包括关于该分组的一般描述性数据,而主体则包括要在接收机/译码器处被处理的数据。分组标题至少包括一个标识该分组的分组ID或PID。分组的主体可包含音频、视频或诸如应用数据的其他数据,或特别地包含条件接入系统数据。
传统上,进入的数据流由接收机/译码器按照每个分组的PID被过滤。需要立即处理的数据,诸如音频或可视数据以传统上被称为分组化的基本流或PES的形式被传送到适当的处理器。这个连续的数据流是通过汇编输送分组的主体而形成的,它本身包括一系列分组,每个PES分组包括分组标题和主体。
不需要立即处理的其他数据也可被封装在输送分组的主体内。与被处理器立即处理以生成实时输出的PES数据不同,这类数据通常由接收机/译码器处理器以非同步方式来处理。在这种情形下,数据在单个表格或一系列表格段中被格式化,每个包括标题和主体,段或表格的标题包括表格ID或TID。
现在参照图7a、7b、和7c来描述传统的MPEG数据流的各个方面,图7a、7b、和7c也被包含在WO 98/43431中,该专利的揭示内容在此被引用,以供参考。
参照图7a,正如已知的,MPEG-2比特流包括具有为零的分组标识(“PID”)的节目接入表格(“PAT”)310。PAT包含对多个节目的节目映射表格(“PMT”)312的PID的引用。每个PMT包含对该节目的音频MPEG表格314和视频MPEG表格316的流的PID的引用。具有为零的PID的分组,也就是节目接入表格310,提供对于所有的MPEG接入的进入点。
为了为它们下载应用和数据,规定两个新的数据流类型,以及相关的PMT也包含对应用MPEG表格318(或它们的段)和数据MPEG表格320(或它们的段)的流的PID的引用。
参照图7b,为了下载应用322,把该应用划分成一些模块324,每个由一个MPEG表格形成,某些MPEG表格由单个段318形成,而其他MPEG表格由多个段318组成。通常段318具有标题326,它包括:一字节的表格标识(“TID”)328;该段在表格中的段号码330;该表格中段的总数332;以及二字节的TID扩展334。每个段还包括数据部分336和CRC 338。对于特定的模块/表格324,组成该表格324的所有的段318具有相同的TID 328和相同的扩展334。对于特定的应用322,组成该应用322的所有的表格具有相同的TID 328,但具有不同的各自的TID扩展。
对于每个应用322,有被用作目录的单个这样的MPEG表格324,它被更详细地显示在图7c中。目录表格340包括标题326、目录部分342、密钥标识344、加密的签名346和CRC 338。从以上将会看到,目录表格340在它的标题326中具有与组成应用的其他的模块/表格324相同的TID 328。然而,目录表格具有预定的为零的TID扩展334,而所有的其他模块324具有为非零的TID扩展。该标题也包括目录表格340的版本号348。对于组成应用322的每个其他的模块/表格324,目录部分342包括该模块的名称350、该模块的TID扩展334、以及该模块的签名352。对于每个其他的模块/表格324,目录部分342也可包括该模块的长度和模块的版本号。
回过来参照图7a,在运行时,PAT 310、PMT 312和应用与数据流分量318、329被周期地发送,如有必要则被更新。被发送的每个应用具有各自的预定的TID 328。为了下载应用,具有适当的TID和为零的TID扩展的MPEG表格被下载到接收机/译码器13。所以,这是用于所需应用的目录表格40。在该目录中的数据然后被接收机/译码器13处理,以确定组成所需应用项的模块表格的TID扩展334,然后具有与该目录表格相同的TID和从目录确定的TID扩展的任何需要的模块表格都可被下载。
接收机/译码器13被安排成对目录表格检验它的任何更新。这可以通过周期性地(例如每30秒或1分钟或5分钟)再次下载目录表格,以及把新下载的目录表格的版本号与先前下载的目录表格的版本号进行比较来完成。如果新下载的目录表格的版本号是更后的,则不安装与先前的目录表格相关联的模块,或者不安装那些又出现了更后的版本号的任何这样的模块,而是下载和安装该更后的模块。在替换的安排中,进入的比特流通过使用相应于TID、TID扩展和版本号的掩码被过滤,该掩码具有对于该应用的TID、为零的TID扩展和比当前下载的目录的版本号大1的版本号的数值集。因此,版本号的增加可被检测到,并且立刻如上所述地下载所检测的目录和更新该应用。上述过滤的进一步说明被包含在专利申请WO 98/43415中。如果应用要被终结,则具有下一个版本号的空的目录被发送,而无需在该目录中列出任何模块。响应于接收到这样的空的目录,接收机/译码器13被编程为不安装该应用。
在其中要限制对传输的接入的情形下,例如在付费电视系统中,条件接入数据可被包括在一个表格或段中,通过该传输在输送流中广播。该条件接入数据被译码器过滤并被传送到被插入在译码器中的便携式安全模块,诸如智能卡。然后,该数据被智能卡处理,以便生成例如由译码器以后使用来对传输进行解扰的控制字。
一个问题在于将被译码器接收和处理的数据的量、特别是最终被转发到安全模块的条件接入数据的量。具体地,安全模块处理器的处理能力和在译码器与安全模块之间的通信信道的容量可能不足以处理给定的消息的量。这个问题由于要通过多条件接入消息被发送的节目不断增加的趋势而加重,多条件接入消息使得能够通过不同的运营商接入到同一个节目(例如,足球比赛或主题电视频道)。因此,现在将研究减小或至少更好地管理信息广播的方法。
下面在附表1中显示专用MPEG表格段。这个格式被专门用来把原始数据放入MPEG段中。段的最大数目取决于section_syntax_indicator(段语法指示符)。
表1
名称 |
尺寸(比特) |
格式 |
缺省值 |
private_section(){ |
|
|
|
table_id |
8 |
uimsbf |
|
section_syntax_indicator |
1 |
bslbf |
|
private_indicator |
1 |
bslbf |
|
Reserved |
2 |
bslbf |
|
private_section_length |
12 |
uimsbf |
|
if(section_syntax_indicator==’0’){ |
|
|
|
For(i=0;i<N;I++){ |
|
|
|
Private_data_byte |
8 |
bslbf |
|
} |
|
|
|
} |
|
|
|
else{ |
|
|
|
Table_id_extension |
16 |
uimsbf |
|
Reserved |
2 |
bslbf |
|
Version_number |
5 |
uimsbf |
|
Current_next_indicator |
1 |
bslbf |
|
Section_number |
8 |
uimsbf |
|
Last_section_number |
8 |
uimsbf |
|
For(i=0;i<private_section_length-9;i++){ |
|
|
|
private_data_byte |
8 |
bslbf |
|
} |
|
|
|
CRC_32 |
32 |
rpchof |
|
} |
|
|
|
} |
|
|
|
作为用if/else语句表示的变量数据结构,附表1既代表长的表格数据结构,也代表短的表格段结构。换句话说,如果section_syntax_indicator等于0,则表格将具有短的表格数据结构,否则表格将具有长的表格数据结构。短的表格只包含单个段,而长的表格可含多个段。
在下面描述的本发明的两个实施例中,结构化信息代替长的和短的表格段数据结构的原始的数据部分,产生用于二者的新的数据格式。原始的数据部分在附表1中由private_data_byte字段的循环来表示,它也将被称为段主体。这些实施例的结构在图8中作为通用数据结构被显示。
数据结构包括传统的MPEG专用表格段标题400。传统标题400的table_id_extension(表格标识扩展)字段402在某些实施例中被使用来提供特定于应用的过滤能力。例如,它可被用作表格内容的识别符,使得能够通过使用硬件过滤来快速检索该内容。传统的CRC信息420被保持。
标准MPEG专用数据段的原始的数据部分(或主体)被另外的标题404代替,标题404包括附加标题字段,外加结构式数据部分。在另外的标题404中的附加标题字段包括有关表格的压缩和加密、优先权、分析格式以及过滤器扩展字段的信息。它们也包括规定共有属性列表408的尺寸的字段。共有属性列表408包括属性406,它对于在数据项目列表410中的所有数据项目412是共有的。结构化数据部分还包括数据项目412的可变长度列表410,每个包括通用数据项目识别符和该数据项目特定的属性416的可变长度列表414。特定的属性列表414的长度是在数据项目412中被规定的。在项目特定的属性列表414中的属性416可以优先于共有属性列表408中的相同的共有属性406。
这个结构使得所有数据项目所共有的属性能够只被包括一次。另外,某些数据项目所共有的属性可出现在共有属性列表中,对于具有不同于这些共有属性的数值的那些数据项目则包括占优的特定属性。这使得被格式化的数据所需要的空间能够被保持为最小。
属性随后按照MPEG标准术语也被称为描述符。列表同样地也将被称为循环,因为循环结构在后面给出的特定表格格式定义中被用作为在定义列表时的形式体系。所以,属性列表408和414也被称为描述符循环,或被分别称为共有的和特定的描述符循环。循环410也将被称为识别符循环。
特定的例子也可以给予任何的数据结构单元以特定的名称。
描述符本身可以是任意的数据结构,它取决于要被代表的属性。优选地,它将包含简单的标题,其中包含描述符标志和描述符尺寸,以使得能够自动分析该描述符。
通过把另外的标题以及结构化数据封装在原始数据部分或附表1的现有的表格结构的主体内,而保持现有的结构的兼容性。这也给出了与现有的MPEG表格处理硬件和软件的兼容性。
专用表格段通常将在广播中心生成,其中信息将按照上述结构被格式化。一旦数据结构被汇编在广播中心的存储器中,它们就被插入到MPEG数据流中,并被广播到接收机/译码器。接收机/译码器然后可以从MPEG数据流中检索该信息,并在它的存储器中重新产生数据结构,之后把它们传送到分析器,用于进一步处理,如将在下面讨论的。
下面通过表2中给出长的专用表格段的具体的例子。这样的表格可包含多达256个段。该表格给出字段名称、字段尺寸(以比特计)、二进制数据格式和缺省值。二进制数据格式是通过使用在MPEG标准中定义的记忆符号而给出的。
表2
最大的段数:256
每段的最大尺寸:4096
在last_section_number(最后段号码)与CRC_32之间的、但不排它的字段代替附表1的现有表格格式的原始的、未格式化的数据段。现在描述新的字段,保留的字段除外。
Private_Filter_extension(专用过滤器扩展):为了使得硬件过滤器的使用最佳化,这个16比特的字段可被使用来扩展专用的过滤,这是通过在对其执行硬件过滤的标题的部分中包括另外的准则而进行的,例如,借助于MLOAD_table,MLOAD_group或MLOAD_section调用。
Data_Parsing_Format(数据分析格式):这个8比特的字段表示表中随后的数据的数据分析格式。这有助于自动分析随后的数据的格式在将来的版本中是否改变。在需要多于256个分析格式的情形下,这个字段可被解译为等价于以256为模数的表格格式版本号。在这种情形下,另外的标题字段可被引入到新的表格格式,以用于规定分析格式。
Data_Cyphered_flag(数据密码标记):这个标记表示在数据部分或主体中的数据,也就是说,在另外标题与CRC_32字段之间(但不排它)的数据是否被加密。如果数据被加密,则藉助于Data_Cyphering_Algorithm(数据密码算法)字段选择加密算法。
Data_Compressed_flag(数据压缩标记):这个标记表示在数据部分或主体中的数据,也就是说,在另外标题与CRC_32字段之间(但不排它)的数据是否被压缩。如果数据被压缩,则藉助于Data_Compressing_Algorithm(数据压缩算法)字段选择压缩算法。
如果Data_Cyphered_Flag和Data_Compressed_Flag都被设置,则在数据压缩后执行加密。在接收侧,接收机/译码器13在解压缩之前解密。
Data_Cyphering_Algorithm:这个2比特字段允许四种不同算法之一被规定使用于加密/解密段主体中的数据。
Data_Compressing_Algorithm:这个2比特字段允许四种不同算法之一被规定使用于压缩段主体中的数据。
Priority(优先权):在这个2比特字段中可规定四个优先权级别之一,这使得优先权级别能够与专用数据相关联。数值0代表最高优先权级别,而数值3代表最低优先权级别。
Common_Descriptor_info_length(共有描述符信息长度):它规定以下的共有描述符列表的长度,尺寸以字节计(虽然单元的数目也可被使用来给出长度)。
描述符(Descriptor)列表:它是描述符单元的列表。描述符单元可以是变化的内部结构,以及表示数据单元属性。该列表在表2上用循环结构表示。
额外识别符(Extra identifier)列表:这个列表在表2上用循环结构表示。这个列表可以包含零或多个额外识别符,每个具有一个描述符列表。额外识别符的每个单元包括以下的字段:
Extra_Identifier_length(额外识别符长度):这个8比特字段规定用于viriable_length_Extra_identifier(可变长度额外识别符)字段的字节的数目(N)。
Extra_Identifier(额外识别符):这个8乘N比特字段规定描述以下的额外识别符描述符循环的识别符或识别符组。
额外识别符描述符(Extra_Identifier_descriptor)循环:它是描述符单元列表。描述符单元可以有变化的内部结构,以及表示数据单元属性。这个表在表2上用循环结构表示。
在以上的附表1中,字段private_section_length(专用段长度)规定从下一个字段直至该段末尾的专用段的剩余部分的尺寸。相同的功能由附表2中的Section_length(段长度)字段执行。在附表2中,两个描述符循环的长度(尺寸以字节计,虽然也可以使用描述符的数目)由字段Common_Descriptor_info_length(缺省值N1)和Extra_descriptor_length(缺省值N3)附加地规定。
具有短的专用表格形式的实施例在下面附表3中给出。短的专用表格只包含单个段。
表3
名称 |
尺寸(比特) |
格式 |
缺省值 |
Short_Private_C+_section(){ |
|
|
|
Table_id |
8 |
Uimsbf |
|
Section_syntax_indicator |
1 |
Bslbf |
0b |
Private_Syntax_indicator |
1 |
Bslbf |
1b |
ISO reserved |
2 |
Bslbf |
11b |
Section_length |
12 |
Uimsbf |
最大值=0xFFD |
Private_Filter_Extension |
56 |
Uimsbf |
|
Data_Parsing_Format |
8 |
Uimsbf |
见解释 |
Priority |
2 |
Bslbf |
11b |
Data_Cyphered_flag |
1 |
bslbf |
|
Data_Compressed_flag |
1 |
Bslbf |
|
Data_Cyphering_Algorithm |
2 |
Uimsbf |
见解释 |
Data_Compressing_algorithm |
2 |
Uimsbf |
见解释 |
Reserved |
4 |
Bslbf |
1111b |
Commomn_Descriptor_info_length |
12 |
Uimsbf |
N1 |
For(i=0,i<N1,i++){ |
|
|
|
Descriptor() |
|
|
|
} |
|
|
|
For(i=0,i<N2,i++){ |
|
|
|
Extra_Identifier_length |
8 |
Uimsbf |
N |
Extra_Identifier |
8*n |
Uimsbf |
|
Reserved |
4 |
bslbf |
111b |
Extra_Identifier_descriptor_length |
12 |
Uimsbf |
N3 |
for(i=0,i<N3,i++){ |
|
|
|
Descriptor |
|
|
|
} |
|
|
|
} |
|
|
|
} |
|
|
|
最大的段数:1
每段的最大尺寸:4096
在Section_length与CRC_32之间(但不排它)的字段代替现有的表格格式的原始的、未格式化的数据段或主体。现在描述新的字段,保留的字段和以上参照附表2描述的字段除外。
Private_Filter_extension:为了使得硬件过滤器的使用最佳化,这个56比特的字段可被使用来扩展专用过滤,扩展专用过滤是通过在对其执行硬件过滤的标题的部分中包括另外的准则而进行的,这例如是借助MLOAD_table、MLOAD_group或MLOAD_section调用。这个过滤器扩展字段比在短长格式中的等价的字段(见表2)更长。这是为了使两个格式的标题在尺寸上相等,这样使得表格的分析更容易。
Priority:在这个2比特字段中可规定四个优先权级别之一,这使得优先权级别能够与专用数据相关联。数值0代表最高优先权级别,而数值3代表最低优先权级别。
Common_Descriptor_info_length:它规定以下的共有描述符列表的长度,尺寸以字节计(虽然单元的数目也可被使用来给出长度)。
描述符列表:这是描述符单元的列表。描述符单元可以有变化的内部结构,以及表示数据单元属性。该列表在附表3中用循环结构表示。
额外识别符列表:这个列表在附表3上用循环结构表示。这个列表可以包含零或多个额外识别符,每个具有一个描述符列表。额外识别符的每个单元包括以下的字段:
Extra_Identifier_length:它规定用于viriable_length_Extra_identifier字段的字节的数目。
Extra_Identifier:它规定描述以下的描述符循环的识别符或识别符组。
额外识别符描述符循环:这是描述符单元的列表。描述符单元可以有变化的内部结构,以及表示数据单元。这个列表在表3上用循环结构表示。
以上的长段和短段格式的例子提供与压缩和加密有关的附加的标题字段。这些提供了加密和压缩格式化数据部分与部分的附加标题信息的能力。下面给出段主体的压缩和加密的说明。同样,提供优先权字段以使得被包含在专用表格段中的信息能够划分优先级别。
所描述的专用表格格式可被使用于许多不同的应用,例如,把指令传送到机顶盒;视频点播应用;或用在条件接入系统中。后面将更详细地描述某些上述的例子。
分析器
为了解译上述的通用表格结构,分析器作为机顶盒的操作软件的一部分被提供。给定了所定义的数据结构的上述分析器的结构可以由本领域技术人员容易地实现。所以,这里只列出某些基本要求。
图9上显示分析器的作用。包括分析器的分析器层506提供在应用层508与MPEG表格接收和过滤层504之间的提取层,它提取由广播系统500通过数据流502发送的信息。
这个提取的效果是,不同的应用不必专门适合于它们处理的不同种类数据的大量不同的表格格式。分析器处理接收的表格段以及提取相关的信息,并把它传送到应用层的应用中。
上述的通用表格格式允许不同类型的数据被组织在同一个表格结构内。被存储在表格段中作为共有和专用属性描述符的集合的单独的数据项包含应用所需要的信息。描述符格式可以变化;在以上的例子中,提供包括规定信息的类型和尺寸属性的标志的简单标题以使得分析器能够正确地提取信息并把它传送到应用中。
此外,描述符列表的尺寸以Common_Descriptor_info_length字段和Extra_Identifier_descriptor_length字段的形式被提供,以使得分析器能够正确地提取它们。分析器不需要关心单独的数据项的意义或功能;它只把该数据传送到应用中。所以,分析器不需要知道它可以接收的信息的不同类型;信息的解译由应用来执行。分析器仅仅除去被包含在标题中的有关传输的信息,以及把表格的实际数据内容以适当的通用形式传送到应用中。
因此,分析器能够处理可变长度的、不同类型的表格。分析器的设计仅通过通用表格的设计被监管,而不是通过不同应用所使用的不同类型的信息被监管。
为了允许其它的表格段格式,当前的格式提供分析格式字段(Data_Parsing_Format)。在这个字段前面的标题段在所有表格格式的尺寸上保持恒定,以使得分析器可正确地识别该字段,它使用该字段来确定专用表格段的格式,并据此选择用于分析它的适当的策略。
专用表格的压缩和加密
如上所述的表格格式还提供压缩和/或加密的专用表格。当表格被使用来输送大量信息(例如在视频点播应用中的节目目录)时,专用表格的压缩可能是有用的。数字广播系统中的带宽常常是昂贵的,所以,减小所需要的带宽会是有利的。如果被存储在表格中的信息具有保密性质,例如,条件接入信息,则表格的加密可能是有用的。
现在将描述专用表格的压缩。
如先前定义的所述另外标题(见表2)包括两个有关压缩的字段。Data_Compressed_flag标记被使用来指示在专用表格段中的数据是否被压缩。此外,在该另外标题中的Data_Compressing_Algorithm字段允许规定用于压缩的算法。所以系统可以同时使用多种不同的压缩算法。在表2所描述的实施例中,它是2比特的字段;因此可以规定4种算法。
在下面描述的优选实施例中,标准标题和注脚(footer),以及包括上面所提到的字段的另外标题不被压缩,以使得被压缩的表格可以通过使用标准的MPEG硬件和软件被处理和发送,以及以使得接收机可确定表格是否已被压缩以及是用哪个算法来压缩它的。仅仅MPEG专用表格的主体(或数据部分)被压缩。在其他的例子中,处在另外标题的有关压缩的字段和注脚之间的(但不排他的)每个项都被压缩,包括在另外标题中的某些字段。
在某些实施例中,段主体仅仅单独地被压缩。在压缩后,表格则作为整体而保持相同数目的段。
然而,在优选实施例中,所有表格段的段主体从表格段中被提取,并被汇编以形成大的数据块。为了使得原始的表格段能够在解压缩后被重新创建,在块中每个主体的前面是一个给出其长度的说明符。
这个包括所有段主体连同它们的各自长度的中间数据块然后被压缩,以给出一个新的被压缩的数据块。新的专用MPEG表格然后从这个块通过把它划分成多个分段而被创建,每个分段被放置在新的表格段的主体中。在每个新的表格段的另外标题中的压缩标记随之被设置。除了这些与段号码和尺寸有关的标记和字段以外,MPEG标准和另外标题在其它方面保持与原始表格相同。所以,压缩的表格可以用与原始的未压缩的表格相同的方式被处理。
压缩的表格通常(依赖于达到的压缩比)包含少于原始表格的段,因为要被发送的数据量已经通过压缩而被减小。
这个压缩的专用表格然后通过常规的信道被发送。当被接收时,Data_Compressed_flag指示该表格被压缩,同时Data_Compressing_Algorithm字段给出用于压缩的算法,由此向接收机/译码器指示应当使用哪个算法来解压缩。
接收机/译码器然后从每个压缩的表格段提取主体,并把它重新汇编,以形成原先被压缩的数据块。它被解压缩,然后,藉助于长度说明符,把它分解成它的组成段的主体。这些被解压缩的主体然后被使用来重新创建原始的专用表格段,并由此创建原始的专用表格。
压缩由所有段主体构建的大的数据块,而不是单独地压缩每个段主体的优点在于:可以达到更高的压缩比。另外,要被发送的段的数目可被减少。因此,对于压缩的专用表格的传输所需要的带宽和计算上的额外开销也被减小。
现在参照图11A和11B更详细地描述压缩和解压缩。
首先参照图11A,专用MPEG表格700包括N个专用表格段702到704。每个表格段包括一个标准MPEG专用表格段标题A、一个另外标题B、主体C1到Cn、和注脚D。在某些实施例中,表格段结构是如先前在表2或表3中定义的,尽管其他特定结构也是可能的。在其他的实施例中,所述另外标题包含除在表2和3中给出的字段之外的、或者不是在表2和3中给出的字段的其他的字段,或略去这样的字段。另外,在长的表格格式实施例中,注脚提供CRC检验和。在短的表格格式实施例中,注脚被略去。
为了压缩表格700,段主体C1到Cn从表格段1到N中被提取。确定每个主体的长度,以及通过汇编这些主体和在每个主体前放置规定该主体的长度的尺寸说明符从而创建数据块706。该数据块于是包括段主体C1到Cn,每个主体前面有它们各自的尺寸说明符C1_length到Cn_length。尺寸说明符的包括使得段主体在解压缩后能够被正确地提取。因为具有长的和短的表格格式的段长度字段(如分别在表2和3中描述的)是12比特字段,两个字节长度的说明符在本例中是足够的。每个二字节长度说明符的四个未使用的比特被设置为1。
数据块706然后通过使用任一适当的压缩算法被压缩。这导致压缩的块708。
然后用以下的方式从压缩的块708产生压缩的MPEG专用表格710。压缩块708被分割成多个分段C’1到C’p。每个分段然后作为段主体被放置在表格710的一个段中。压缩的表格710于是包括P个表格段712到714,其包含压缩的数据块708的分段C’1到C’p。
压缩的表格710然后可被发送或存储。压缩的表格不仅与MPEG标准专用表格相兼容,还与如上所述的通用的专用表格格式相兼容,所以,可以用相同的方式来处理。
压缩的表格710通常将(虽然不一定)具有比原始的未压缩的表格700少的段,因为被存储在压缩的表格中的数据量通过压缩被减小;且压缩的数据因而已被优选地、均匀地重新分布。所以,不单通过减小发送的总的数据量,而且通过减少发送的表格段的数目,来使表格的传输更有效地进行。另外,通过将所有段主体一起压缩,而不是单独地压缩,可以达到更高的压缩比。
现在转过来参照图11B,压缩的MPEG专用表格710用以下的方式被解压缩。段主体C’1到C’p被提取和被汇编,以给出压缩的数据块716,它然后通过使用适当的解压缩算法被解压缩。这产生原先的未压缩的数据块718,它包括原始的段主体C1到Cn,带有它们的各自的尺寸说明符。通过使用这些尺寸说明符,数据块718然后被分割成它原先的组成成分,即,段主体C1到Cn,根据这些段主体而重新构建具有表格段722到724的原先的、未压缩的专用MPEG表格720。
与以上所述用于表格压缩相同的过程被使用来加密专用表格。为此,所述另外标题提供两个字段Data_Cyphered_Flag和Data_Cyphering_Algorithm。它们类似于具有类似名称的有关压缩的字段;第一个是指示表格是否被加密的标记,而第二个可选地被用来规定所使用的加密算法和对于解密所需要的解密算法(在其他的例子中,这个字段也被使用来规定几个加密密钥之一,这些密钥此前已被输送到接收机)。任何适当的加密算法都可被使用,例如DES或RSA。和压缩一样,在某些实施例中,解密是对表格段单独地执行的,但在这里描述的优选实施例中,解密是对于包括具有尺寸说明符的所有表格段主体的数据块来执行的。这后一种技术可提供增加的安全性,因为表格结构没有被保留。用于加密表格的过程就类似于上述的压缩算法。事实上,该技术可以通过任何操作或变换被使用。具有压缩和加密形式的变换在这里已作为例子被描述。
此外,表格可被既加密又压缩。在这种情形下,如图11A所示的数据块706首先被压缩,然后被加密。在接收机处,被压缩并被加密的表格则首先被解密,然后被解压缩(在另一个例子中,表格首先被加密然后被压缩,以及在接收机处,加密的、压缩的表格首先被解压缩,然后被解密)。
在接收机/译码器处,解压缩和解密作为第一步骤由分析器模块来执行。在替换实施例中,它们被分开地执行,并且是在表格被传送到分析器之前执行。自从解压缩和解密导致用发送来的压缩的和/或加密的专用表格创建第二个专用表格开始,一旦解压缩的/解密的表格被生成,由发送来的表格所占用的存储器就被释放,因为此后不再需要压缩的/加密的表格。当接收到包括关于表格结构的信息和到表格段的指针的表格时,接收机/译码器生成一个表格描述符。表格描述符被使用来从存储器中去除压缩的/加密的表格。然后,为解压缩的/解密的表格创建一个新的表格描述符,它例如可被传送到另一个软件模块,以使得该软件模块能够接入到该解压缩的/解密的表格。
解压缩的/解密的模块通过检查Data_Compressed_flag和Data_Cyphered_flag来检测表格是否被压缩和/或加密。如果这些标记的任一个被设置,则根据Data_Compressing_Algorithm和Data_Cyphering_Algorithm字段的数值来选择适当的解压缩和/或解密算法。然后执行解压缩和/或解密,此后进行进一步的分析。
所以,表格的压缩和加密对于应用是透明的,以及如果不是全部,则在很大的程度上,对于分析器是透明的。因为MPEG标准标题在压缩的和/或加密的表格中保持不变,以及标准MPEG专用表格段结构因而是被保留的,压缩/加密对于与MPEG表格的发送、接收和过滤有关的较低级别的、遵循MPEG的模块也是透明的。在接收机/译码器处,使用标准过滤方法,例如通过对表格ID和表格ID扩展字段进行过滤,而从进入的流中检索压缩的和/或加密的表格。所以,保持了接入MPEG流中被压缩/加密的信息的便捷。
压缩/加密技术于此已在先前讨论的、并在表2和3中示例地说明的通用的MPEG专用表格结构方面被描述。然而,它也可应用于标准MPEG专用表格,这些表格可以通过使用同一个技术被压缩和加密。在某些这样的例子中,标记属性,诸如所描述的那些,只在专用表格段主体的开始时被加上。在其他的例子中,如果在发送者和接收者之间对于专用表格段主体的压缩的或加密的状态存在以前的约定,则这样的标记是不需要的。该技术也可应用于不是MPEG专用表格的、其他类似的数据结构。
应用例子
上述的实施例可以被使用于多种不同的应用。现在给出某些这样的应用的例子。
第一个例子提供用于把要由机顶盒实行的动作通知给机顶盒的装置。
应用例子:动作通知表格
动作通知表格(ANT)是基于先前所讨论的通用表格结构。它可被使用来指令机顶盒或机顶盒组,以实行特定的动作。
要由接收机/译码器实行的动作的例子包括:下载软件;自动频道扫描;接收机/译码器的重新引导;刷新节目目录(诸如视频点播的目录);和显示消息给机顶盒的用户(观众消息传送)。表格ID扩展字段在ANT中被使用以识别所要求的动作。
借助于目标描述符,可以使ANT把特定种类的机顶盒(例如,来自特定的制造商)或甚至单独的机顶盒确定为目标。这些目标描述符例如可以被放置在ANT表格的公共描述符循环中。通过处理在公共描述符循环中的目标描述符,机顶盒可以确定该动作是否要被该机顶盒实行。所述确定目标和动作信息的处理,例如可以由运行在机顶盒上的应用程序来实行。
ANT是载有描述符列表和循环的表格,其中的描述符列表和循环用来支持任意的动作类型和选择准则。对于创建新的描述符没有限制。所以,这个方法对于任何新的发展是开放的。在下面的章节中,描述ANT表格的基本结构,以及一些为基本下载目的所需要的基本描述符。
两种表格格式都是可用的,带有附加标题字段的长表格允许用于多段表格,而短版本允许用于单段表格。这些表格格式遵循如上所述的本发明的实施例。下面在表4a中显示长表格格式。
表4a
名称 |
尺寸(比特) |
格式 |
缺省值 |
Action_Notification_section(){ |
|
|
|
Table_id |
8 |
Uimsbf |
0x91 |
Section_syntax_indicator |
1 |
Bslbf |
1b |
Private_syntax_indicator |
1 |
Bslbf |
1b |
ISO reserved |
2 |
Bslbf |
11b |
section_length |
12 |
Uimsbf |
最大值=0xFFD |
Action_Identifier |
16 |
Uimsbf |
见下面解释 |
Reserved |
2 |
Bslbf |
11b |
Version_number |
5 |
uimsbf |
|
Current_next_indicator |
1 |
Bslbf |
1b |
Section_number |
8 |
uimsbf |
|
Last_section_number |
8 |
uimsbf |
|
Filter_extension |
16 |
uimsbf |
跟随action_id |
Data_Parsing_Format |
8 |
uimsbf |
见解释 |
Priority |
2 |
Bslbf |
11b |
Data_Cyphered_flag |
1 |
bslbf |
|
Data_Compressed_flag |
1 |
bslbf |
|
Data_Cyphering_Algorithm |
2 |
uimsbf |
见解释 |
Data_Compressing_Algorithm |
2 |
uimsbf |
见解释 |
Reserved |
4 |
Bslbf |
1111b |
Commomn_Descriptor_info_lengt |
12 |
uimsbf |
N1 |
h |
|
|
|
For(i=0,i<N1,i++){ |
|
|
|
Descriptor() |
|
|
|
} |
|
|
|
For(i=0,i<N2,i++){ |
|
|
|
Extra_Identifier_length |
8 |
uimsbf |
N |
Extra_Identifier |
8*N |
uimsbf |
|
Reserved |
4 |
bslbf |
1111b |
Extra_Identifier_descriptor_length |
12 |
uimsbf |
N3 |
for(i=0,i<N3,i++){ |
|
|
|
Descriptor() |
|
|
|
} |
|
|
|
} |
|
|
|
CRC_32 |
32 |
Rpchof |
|
} |
|
|
|
Action_identifier(动作识别符):表格识别符扩展字段(Tid_ext)在这里被使用于一个不同的用途,即识别动作。动作的例子和它们的编码在下面的表4b中给出。
表4b
数值 |
注解 |
0x0000 |
CDNT MediaOne及Jupiter |
0x0001 |
代码下载V2 |
0x0002 |
自动扫描 |
0x0003...0xFFFF |
RFU |
Filter_extension:这个字段的意义取决于Action_identifier字段的数值。可能的数值和意义的例子在下面的表4c中给出。
表4c
Action_identifier Filter_extension 注解
0x0000 >0x0000 Message_index(消息索引)
0x0001 0xFFFF 保留用于自动下载项目
0x0002 TBD RFU
0x0003...0xFFFF TBD RFU
短表格格式的动作通知表格可以类似地根据上述的短表格格式被构建。
下面参照表4d-4k描述基本描述符的某些例子。
Code_download_descriptor(代码下载描述符)
为可用的每个代码装载器提供一个描述符。
描述符被放置在ANT表格内的项目循环,以及定义代码下载调度。
表4d
名称 |
尺寸(比特) |
格式 |
缺省值 |
Code_Download_descriptor(){ |
|
|
|
Descriptor_tag |
8 |
Uimsbf |
Tbd |
Descriptor_length |
8 |
Uimsbf |
|
Download_flag |
1 |
Bslbf |
0:自动1:人工 |
Type |
2 |
Bslbf |
0:调度1:立即2,3:保留供将来使用 |
Periodicity |
2 |
Bslbf |
0:非周期1:每天2:每星期3:每月 |
Reserved |
3 |
Bslbf |
111b |
UTC_Date_Time_start |
40 |
Uimsbf |
|
UTC_Date_Time_estimated_stop |
40 |
Uimsbf |
|
} |
|
|
|
字段的说明
Download_flag(下载标记):
表4e
数值 |
注解 |
0 |
装载器在下一次重新导引时将不起动,但下载参量将在EEPROM中被更新。要考虑到,下载必须人工地激活,·从STB的前面板按键·从建立菜单 |
1 |
代码下载实际上将在下一次重新导引时被执行。 |
Type:这个字段定义当下载处理过程开始时的STB行为。
表4f
数值 |
注解 |
0 |
立即下载 |
1 |
调度的下载 |
2 |
保留用于将来使用 |
3 |
保留用于将来使用 |
调度的动作使得STB能够编程让自动软件周期地(例如,在一个月内一天一次在上午03:00)下载,直至该操作成功为止。
Periodicity(周期性):这个字段定义当下载处理过程对于调度的动作开始时的STB行为。该周期性只是在UTC_date_time_start与UTC_date_time_estimated_stop之间对于调度的动作是可用的。
UTC_date_time_start:这个字段表示被调度的日期和时间,在该日期和时间,STB的强制重新导引将发生。它以与TDT和TOT表格中的DVB所规定的相同的格式在UTC中被编码。
UTC_date_time_estimated_stop:这个字段指示对于代码下载的可用性的日期。
ANT extension(ANT扩展)
ANT可被使用于其他类型的事件通知。没有限制;下面的例子描述如何使用这个解决方案用于另一个用途:
Scanning_Descriptor(扫描描述符)
通过使用这个描述符,可指令机顶盒来实行扫描。这包括得到业务映射,它例如包含关于可用的信道的信息。可以即时或按照调度的原则来要求扫描。
表4g
名称 |
尺寸(比特) |
格式 |
缺省值 |
Scanning_descriptor(){ |
|
|
|
Descriptor_tag |
8 |
uimsbf |
TBD |
Descriptor_length |
8 |
uimsbf |
|
Reserved |
3 |
bslbf |
|
Service_map_version_number |
5 |
uimsbf |
n |
Original_Network_id |
16 |
Uimsbf |
|
Transport_stream_id |
16 |
Uimsbf |
|
Scanning_flag |
1 |
Bslbf |
0:自动1:人工 |
Type |
2 |
Bslbf |
0:调度1:立即2,3:保留供将来使用 |
Periodicity |
2 |
Bslbf |
0:非周期1:每天2:每星期3:每月 |
Reserved |
3 |
Bslbf |
111b |
UTC_Date_Time_start |
40 |
Uimsbf |
|
UTC_Date_Time_estimated_stop |
40 |
Uimsbf |
|
} |
|
|
|
字段的说明
Service_map_version_number(业务映射版本号):这个字段表示所使用的业务映射的版本号。
Original_network_id(原始网络标识),Transport_stream_id(输送流标识):这些DVB数值标识在扫描信息被广播的场合下的输送数据流。
Scanning_flag(扫描标记):
表4h
数值 |
注解 |
0 |
要考虑到扫描必须从建立菜单人工地激活。 |
1 |
扫描实际上将在下一次重新导引时被执行。 |
Type:这个字段定义当扫描处理过程开始时的STB行为。
表4i
数值 |
注解 |
0 |
立即扫描 |
1 |
调度的扫描 |
2 |
保留供将来使用 |
3 |
保留供将来使用 |
调度的动作使得有可能编程以便周期地(例如,在一个月内一天一次在上午03:00)自动扫描,直至该操作成功为止。
Periodicity:这个字段定义当扫描处理过程对于调度的动作开始时的STB行为。该周期性只在UTC_date_time_start与UTC_date_time_estimated_stop之间对于调度的动作是可用的。
UTC_date_time_start:这个字段表示被调度的日期和时间,在该日期和时间STB的强制重新导引将发生。它以与TDT和TOT表格中的DVB所规定的相同的格式在UTC中被编码。
UTC_date_time_estimated_stop:这个字段指示对于扫描业务映射信息的可用性的日期。
动作通知表格(ANT)例如可被使用来指令机顶盒下载信息。
下载数据需要三个机制:信令机制;下载机制;和自举机制。在以下的说明中,信令机制是基于使用在到PMT的NIT(网络信息表格)或BAT内的一个联接描述符。PMT(以上在图7a引入的)是载送对于数据下载所必需的全部信息以及识别该下载的流的位置的表格。
下载处理过程可能需要大量各种各样不同类型的信息,这取决于要使用哪个运营商、网络和机顶盒制造商。所以,需要非常公开的和灵活的表格概念。
平台通过OUI识别符在第一级别上被识别。OUI识别符表示特定的STB制造商。在第二级别上,精确的目标是未决定的,以便使用各种参数,像系列号、Mac地址、被链接到CAS_ID的智能卡号码等等。附加的硬件或软件版本和子版本是允许的。下面描述的解决方案允许任何类型的鉴别描述符被使用于过滤。
如图10所示,下载业务的信令是基于到PMT 606的NIT或BAT 602中的一个联接描述符。在SDT(业务描述表格)的service_descriptor(业务说明符)以及NIT的service_list_descriptor(业务列表说明符)中,定义了业务类型“DOWNLOAD(下载)”(为了避免下载业务在屏幕上作为节目出现)以声明这个特定的业务。
PMT 606通过定义流类型“通知(Notification)”600,而引用ANT(动作通知表格)608。OUI选择器在PMT 606中被使用,以便允许ANT表格608的第一选择被使用,因为多个ANT表格可被支持。如果接收机/译码器13找到正确的OUI和相应的ANT,它将在ANT 608中检验描述符是否与不同的选择准则相匹配,然后得到数据圆盘传送器(datacarousel)的进入点。
PMT 606载送类似于AIT表格的选择描述符,以便能够立即观察ANT 608是否正在载送下载业务或任何其他的通知描述符。
对于OUI的过滤在这个级别上被执行。OUI的保留的数值被定义,以便选择任何制造商的STB。
下面在表4j中显示OUI数据结构:
表4j
语法 |
比特数目 |
格式 |
代码 |
Action Notification List descriptor(){ |
|
|
|
Descriptor_tag |
8 |
Uimsbf |
|
Descriptor_length |
8 |
Uimsbf |
|
OUI |
32 |
Uimsbf |
0xFFFFFFFF用于所有的OUI |
For(i=0;i<N;i++){ |
|
|
|
Action_Identifier |
16 |
uimsbf |
|
Reserved_future_use |
3 |
bslbf |
|
ANT version number |
5 |
uimsbf |
|
} |
|
|
|
Action_Identifier(动作识别符)字段等于ANT的动作代码值,即,ANT的TID_Ext。
由于所有的表格都包括版本号,通过过滤PMT版本号的改变,可以看到ANT版本号是否已经改变以及变成哪一个,而无需分开地检验每个ANT。
NIT或BAT联接描述符具有表4k中显示的结构:
表4k
linkage_descriptor(){ |
长度(比特) |
descriptor_tag |
8 |
descriptor_length |
8 |
transport_stream_id |
16 |
original_network_id |
16 |
service_idlinkage_typefor(i=0;i<N;i++){private_data |
16规定的DVB“下载信令” |
} |
|
} |
|
这个联接描述符指向下载业务,其中PMT涉及到一个或几个ANT分量。
在第一步骤,目标是达到这样的业务,该业务载送可用的通知的所有描述符。在第二步骤,执行该业务的PMT的分析。为特定动作制定各自的通知表格,其包括特定的选择符以便只影响所需要的STB。这样,为了允许OUI过滤,在每个ANT PID下的Action_Notification_List_descriptor(动作通知列表描述符)的存在是强制性的。ANT PID可载送来自同一个OUI提供者的相应于不同动作通知的、多于一个的ANT子表格。每个ANT不同于它的TID_Extension字段。如果“下载”被描述为一个可能的动作,并且OUI代码与接收机相匹配,则ANT通过STB被下载。一旦被装载,ANT的分析就有助于更精确地及时描述可得到的、匹配的下载。调度是可能的,这样使得在将来引用和编程下载、而不在编程时下载在流中存在的代码是可行的。
当在下载说明和位于不同的可得到的描述代码内的STB特性之间发现匹配时,则STB可跳到由association_tag(关联标记)610所描述的下载代码进入点,或者如果代码在另一个业务中由deferred_association_tag(延期关联标记)612描述,或者如果代码是不可得到的,则开始时间和位置必须由STB记住。此后,是一直到STB提供者分析和使用由被记住的entry_point(进入点)(ON_ID,TS_ID,SV_ID和association_tag)指向的数据。下载的数据的格式可以是提供者希望的任何格式。
尽管如此,数据应该按一种方式被排序,即
·甚至对于第一过滤,在进行下载之前在STB特性与下载的代码之间进行检验=>必须给该代码定义一个清楚的身份
·在同一个数据PID中载送多个下载代码的能力-例如每个硬件版本一个代码-意味着一种方法来在现有数据的整个集合中区分用于各个版本的数据(在数据圆盘传送器中模块的选择)。
ANT和相关的机制提供传统信令方法的扩展,它向一个或几个机顶盒指示在该输送流中的或在另一个输送流中的一个位置,在该位置可以找到新的装载器版本,即它们的软件代码的新的可下载版本。
上述的表格结构在调度的下载的情形下是特别有用的。
应用例子:被作为目标的表格
正如以上对于ANT表格描述的,通过把目标描述符包括在描述符循环中,表格的确定目标是可能的。下面给出目标描述符的两个例子。第一个,Target_RSM_Descriptor(目标RSM描述符)被使用把特定的智能卡确定为目标。第二个,Target_Platform_Descriptor(目标平台描述符)被使用来把特定的硬件和/或软件平台确定为目标。
Target_RSM_Descriptor
下面在表5中描述的这个描述符,使得能够对于智能卡识别符列表实行动作,以及它被放置在ANT表格的公共描述符循环中。在该表格中可出现几个连续的描述符。
表5
名称 |
尺寸(比特) |
格式 |
缺省值 |
Target_RSM_descriptor(){ |
|
|
|
Descriptor_tag |
8 |
uimsbf |
TBD |
Descriptor_length |
8 |
uimsbf |
|
Ca_system_id |
16 |
uimsbf |
|
Number_of_tester |
8 |
uimsbf |
N |
For(i=0;i<N;i++){ |
|
|
|
RSM_serial_number |
48 |
uimsbf |
|
QEV |
8 |
uimsbf |
|
} |
|
|
|
} |
|
|
|
字段的说明:
Number_of_tester(测试器数目):这个数字表示下载所涉及到的RSM的数目。
RSM_serial_number(RSM系列号):Qui etes Vous(对于介质保护智能卡可用)
Qev:Qui etes Vous(对于介质保护智能卡可用)
Target_Platform_Descriptor
下面在表6中描述的这个描述符,使得能够对于平台识别符列表实行动作。它被放置在ANT表格的公共描述符循环中。在该表格中可出现几个连续的描述符,每个平台一个。
表6
名称 |
尺寸(比特) |
格式 |
缺省值 |
Target_Platform_descriptor(){ |
|
|
|
Descriptor_tag |
8 |
uimsbf |
TBD |
Descriptor_length |
8 |
uimsbf |
|
Hardware_version_number |
32 |
bslbf |
|
Number_of_versions_concerned |
8 |
uimsbf |
N |
For(i=0;i<N;i++){ |
|
|
|
Global_soft_id |
16 |
uimsbf |
|
} |
|
|
|
字段的说明:
Hardware_version_number(硬件版本号):这个号码表示在一个制造商内的硬件平台。
Number_of_versions_concerned(所涉及的版本的数目):这个数字表示下载所涉及到的软件平台的数目。
Global_soft_id(全球软件标识):这个字段表示代码下载所涉及到的每个硬件平台的STB软件版本。
Target_RSM_Descriptor(表5)和Target_Platform_Descriptor(表6)被用来使表格和表格段把特定的智能卡和/或平台确定为目标。这样,它们可被使用于除了上述的动作通知表格以外的应用,和下面描述的视频点播应用。通过使应用和相关信息的目标为定义的测试设备组,这个确定目标功能性对于测试新的应用是特别有用的。在下面描述的视频点播应用中,确定目标也可被使用来例如为不同的顾客提供不同的语言或不同的价格。通过使用目标描述符来提供多种语言,传输带宽可被节省,因为只需要复制节目的声音分量;图片分量不考虑语言而保持为相同的。目标描述符实际上提供对于通常的表格过滤方法的扩展。
目标描述符可被放置在公共的和特定的描述符循环中。第一个公共描述符循环的使用提供第一级别过滤,给出可应用于所有可能的过滤器的公共过滤参量。关于这个表格的其他公共信息可被包括在这个公共描述符循环中。
识别符循环则可被解译为OR(或)条件,而内部的特定的描述符循环提供AND(与)条件。例如,如果声明有三个过滤器,每个具有两个链接的条件,则识别符循环将包含三个项目,每个包含两个描述符。
应用例子:视频点播应用
在第二个应用例子中,长的和短的表格段格式被使用来发送信息到与视频点播的供应品有关的接收机/译码器。
在视频点播(VoD)应用方面,有用资源目录(有用资源是特定的VoD供应品,例如影片)由元数据组成。该元数据来自内容提供者(以XML格式),以及被放置在MPEG专用段中。被发送到STB的这些段以圆盘传送器模式被广播。
可以有大量通过VoD系统提供的有用资源。所以,必须提供可被使用于大量有用资源的数据格式,比如说,几十或几百或几千。
考虑到每个有用资源的数据尺寸,提供两个级别的信息:
第一级别:提供有用资源的标题、评定等级和类别。
第二级别:提供概要、演员表、语言和副标题信息,以及其他有关节目的信息。
在第一级别,可提供表格组以列出有用资源,例如电视节目。为了便于接入到表格,这些表格具有相同的表格ID,但有不同的表格ID扩展。这些表格ID扩展被使用来把有用资源归类。例如,一个表格可以列出影片,而另一个列出体育事件。这使得与所需有用资源类别有关的表格能够容易地通过硬件过滤从MPEG流中被提取出来。用户例如可以要求观看体育节目表。通过在表格ID扩展字段中把用于有用资源表的表格ID和用于体育节目的类别代码组合起来,正确的有用资源表可以容易地被检索。
这个表格将包含属于该类别的所有有用资源的列表,也就是说,在本例中,包含所有的体育节目。这个表然后可被显示给该用户。如果该用户要求有关这些节目之一的另外的信息,则检索包含与这个特定有用资源有关的另外的信息的第二级别表格,诸如节目的花费和内容的说明。这里,有用资源识别符被用作表格识别符扩展,以使得能够对有用资源识别符进行硬件过滤,因此能快速检索相应的有用资源信息。
可能的可用类别也在另一个MPEG专用数据表格中被发送。
可得到的有用资源的列表组成节目类别。另外的表格被提供用于类别的更新,如下面将描述的。
以下的格式是基于用于专用表格的以上的通用格式描述,以确保分析模块的可重复使用性。这些格式利用这样的事实,即在译码器中的段过滤模块是基于硬件8字节掩码(table_id+来自tid_ext字段的7字节,包括tid_ext)。
注意,以下的表格中类别和有用资源的优先权应被排序,使较低的数值具有较高的优先权,这样,当信息被存储在tid_ext字段时,最高优先权数据首先被检索。
Categories_Description_Table(类别说明表格)
Categories_Description_Table(下面在表7上显示的)是要从进入的流中被检索的第一个表格,以及提供可用类别的列表。该表格是基于先前描述的通用长表格段格式。Category_id(类别标识)是2字节字段,标识在随后的描述符列表中所提供的其它信息的类别。Category_id的数值的范围使得能够使用类别定义和子类别定义,如下面更详细地描述的。
Category_id的高字节定义类别。Category_id的低字节定义子类别。因此,例如,Category_id 0x1200定义类别0x12和子类别0x00。类似地,Category_id 0x1234定义同一个类别0x12,但定义不同的子类别0x34。
例如,在category_id 0x1200后面的category_name_descriptor(类别名描述符)可代表该类别可见的名称,以及在category_id 0x1234后面的category_name_descriptor可代表同一个类别的不同子类别的名称。
类别0x00是保留的数值,允许使用通用的sub_category定义。例如,如果在所有可能的类别中必须用subcategory_id 0x01定义通用子类别“live_event”,那么有可能定义一个0x0001数值作为category_id和一个用“live_event”作为文本内容的描述符。
表7
名称 |
尺寸(比特) |
格式 |
数值/注解 |
Categories_Description_section(){ |
|
|
|
Table_id |
8 |
Uimsbf |
0x90 |
Section_syntax_indicator |
1 |
Bslbf |
1b |
Private_syntax_indicator |
1 |
Bslbf |
1b |
ISO reserved |
2 |
Bslbf |
11b |
section_length |
12 |
Uimsbf |
最大值=0xFFD |
Tid_extension |
16 |
Uimsbf |
未使用的=0x0000,但将来可改变 |
Reserved |
2 |
Bslbf |
11b |
Version_number |
5 |
uimsbf |
|
Current_next_indicator |
1 |
Bslbf |
1b |
Section_number |
8 |
uimsbf |
|
Last_section_number |
8 |
uimsbf |
|
Reserved |
16 |
bslbf |
0xFFFF |
Data_Parsing_Format |
8 |
uimsbf |
见解释 |
Priority |
2 |
Bslbf |
11b |
Data_Cyphered_flag |
1 |
uslbf |
|
Data_Compressed_flag |
1 |
bslbf |
|
Data_Cyphering_Algorithm |
2 |
uimsbf |
见解释 |
Data_Compressing_algorithm |
2 |
uimsbf |
见解释 |
Reserved |
4 |
Bslbf |
1111b |
Commomn_category_info_length |
12 |
uimsbf |
N1=0 |
for(i=0,i<N1,i++){ |
|
|
|
Descriptor() |
|
|
|
} |
|
|
|
for(i=0,i<N2,i++){ |
|
|
|
Category_Id_length |
8 |
uimsbf |
N=2 |
Category_id |
8*N |
uimsbf |
|
Reserved |
4 |
bslbf |
1111b |
Category_descriptor_Length |
12 |
uimsbf |
N3 |
for(i=0,j<N3,j++){ |
|
|
|
Descriptor |
|
|
|
} |
|
|
|
} |
|
|
|
CRC_32 |
32 |
Rpchof |
|
} |
|
|
|
要被存储在category_descriptor_loop(类别描述符循环)中的描述符被显示在下面表8上。
category_name_descriptor
表8
名称 |
尺寸(比特) |
格式 |
数值/注解 |
Category_name_descriptor(){ |
|
|
|
Descriptor_tag |
8 |
Uimsbf |
0xC9 |
Descriptor_length |
8 |
Uimsbf |
|
Category_code |
8 |
uimsbf |
|
ISO_639:_Language_Code |
24 |
Uimsbf |
|
Category_name_length |
8 |
Uimsbf |
|
For(I=0;i<N;i++){ |
|
|
|
Category_name_char |
8 |
Uimsbf |
|
} |
|
|
|
} |
|
|
|
有用资源(ASSET)表格
第一级别的有用资源信息是基于用于专用段的长格式语法(Section_syntax_indicator=1)。
每个表格相应于由它们各自的识别符所标识的特定类别和子类别。一个表格可描述10000个以上的有用资源,因为它可由256个段构成,每个段4k字节。
类别和子类别等级评定(它代替tid_ext字段)在于硬件过滤器深度,以确保根据等级评定准则快速过滤一组有用资源。评定等级以8比特被编码,以便与例如在典型的按观看付费应用中使用的DVBparental_rating_descriptor一致。
每个表格由asset_id(有用资源标识)循环构成。第一描述符循环载送适用于所有asset_id的公共属性。
第二描述符循环载送适用于特定有用资源的特定属性。当属性在该第一和第二循环中被定义时,第二定义优先于该公共定义。
有用资源信息表格段的结构被显示于表9。
表9
名称 |
尺寸(比特) |
格式 |
数值/注解 |
Asset_Information_section(){ |
|
|
|
Table_id |
8 |
Uimsbf |
0x91 |
Section_syntax_indicator |
1 |
Bslbf |
1b |
Private_syntax_indic |
1 |
Bslbf |
1b |
ator |
|
|
|
ISO reserved |
2 |
Bslbf |
11b |
Secfion_length |
12 |
Uimsbf |
最大值=0xFFD |
Category_id |
8 |
Uimsbf |
|
Sub_category_id |
8 |
Uimsbf |
Tid_ext |
Reserved |
2 |
Bslbf |
11b |
Version_number |
5 |
uimsbf |
|
Current_next_indicator |
1 |
Bslbf |
1b |
Section_number |
8 |
uimsbf |
|
Last_section_number |
8 |
uimsbf |
|
Category_rating |
8 |
uimsbf |
|
Sub_category_rating |
8 |
uimsbf |
|
Data_Parsing_Format |
8 |
uimsbf |
见解释 |
Priority |
2 |
Bslbf |
11b |
Data_Cyphered_flag |
1 |
bslbf |
|
Data_Compressed_flag |
1 |
bslbf |
|
Data_Cyphering_Algorithm |
2 |
uimsbf |
见解释 |
Data_Compressing_algorithm |
2 |
uimsbf |
见解释 |
Reserved |
4 |
Bslbf |
1111b |
Commomn_Asset_info_length |
12 |
uimsbf |
N1 |
for(i=0,i<N1,i++){ |
|
|
|
Descriptor() |
|
|
|
} |
|
|
|
for(i=0,i<N2,i++){ |
|
|
|
Asset_id_length |
8 |
uimsbf |
N |
Asset_id |
8*N |
uimsbf |
|
Reserved |
4 |
bslbf |
1111b |
Asset_descriptor_Length |
12 |
uimsbf |
N3 |
for(j=0,j<N3,j++){ |
|
|
|
Descriptor() |
|
|
|
Asset_id_length(有用资源标识长度):被使用来定义数值字段的字节数。
Asset_id:描述随后的描述符循环的描述符或描述符组。
第二级别的有用资源信息是基于用于专用段的短格式语法(Section_syntax_indicator=0)。
由于硬件过滤器深度,有可能设置一个过滤器以接入特定的asset_id。定义了24比特的保留字段,以便与用于短的段语法的通用格式相一致。它实际上补充该硬件过滤掩码。
描述符循环被使用来编码与有用资源有关的属性。
该表格段结构在表10中被描述。
表10
名称 |
尺寸(比特) |
格式 |
数值/注解 |
Asset_more_information_section(){ |
|
|
|
Table_id |
8 |
Uimsbf |
0x92 |
Section_syntax_indicator |
1 |
Bslbf |
0b |
Private_syntax_indicator |
1 |
Bslbf |
1b |
ISO reserved |
2 |
Bslbf |
11b |
Section_length |
12 |
Uimsbf |
最大值=0xFFD |
Asset_id |
32 |
Uimsbf |
|
Reserved |
24 |
Uimsbf |
0xFFFFFF |
Data_Parsing_Format |
8 |
uimsbf |
见解释 |
Priority |
2 |
Bslbf |
11b |
Data_Cyphered_flag |
1 |
bslbf |
|
Data_Compressed_flag |
1 |
bslbf |
|
Data_Cyphering_Algorithm |
2 |
uimsbf |
见解释 |
Data_Compressing_algorithm |
2 |
uimsbf |
见解释 |
Reserved |
4 |
Bslbf |
1111b |
Commomn_Asset_info_length |
12 |
uimsbf |
N1 |
for(i=0,i<N1,i++){ |
|
|
|
Descriptor() |
|
|
|
} |
|
|
|
} |
|
|
|
现在描述在Asset_information_section(有用资源信息段)或Asset_more_information_section(有用资源更多信息段)的描述符循环中包括的、某些可能的描述符。
Asset_name_descriptor
这个描述符被放置在有用资源信息表格的有用资源循环中。它的结构在表11中被描述。
表11
名称 |
尺寸(比特) |
格式 |
数值/注解 |
Asset_name_descriptor(){ |
|
|
|
Descriptor_tag |
8 |
Uimsbf |
0xC1 |
Descriptor_length |
8 |
uimsbf |
|
Start_date |
40 |
Bslbf |
|
End_date |
40 |
Bslbf |
|
Asset_rating |
8 |
Uimsbf |
|
ISO_639:_Language_Code |
24 |
Uimsbf |
见规范 |
Title_length |
8 |
Uimsbf |
最大值0x3C |
For(I=0;i<N;i++){ |
|
|
|
Title_char |
8 |
Uimsbf |
|
} |
|
|
|
} |
|
|
|
以下的描述符通常被放置在Asset_more_information_table(有用资源更多信息表格)中。然而,其中的某些也可被用作Asset_information_table(有用资源信息表格)中的属性。
Source_descriptor(源描述符)
在下面的表12中定义的这个描述符提供有关有用资源的呈现格式方面的信息。
表12
名称 |
尺寸(比特) |
格式 |
数值/注解 |
Source_descriptor(){ |
|
|
|
Descriptor_tag |
8 |
Uimsbf |
0xC2 |
Descriptor_length |
8 |
Uimsbf |
|
Reserved |
6 |
Bslbf |
111111b |
Surround |
1 |
Bslbf |
|
Widescreen |
1 |
Bslbf |
|
Language |
24 |
Bslbf |
|
Subtitle_language |
24 |
Bslbf |
|
} |
|
|
|
Asset_more_info_descriptor(有用资源更多信息描述符)
在下面的表13中定义的这个描述符提供有关有用资源的各种信息。
表13
名称 |
尺寸(比特) |
格式 |
数值/注解 |
Asset_more_info_descriptor(){ |
|
|
|
Descriptor_tag |
8 |
Uimsbf |
0xC3 |
Descriptor_length |
8 |
uimsbf |
|
Duration |
24 |
bslbf |
|
Retail_price |
48 |
bslbf |
|
Year |
32 |
bslbf |
|
Provider_Country_Code |
24 |
Uimsbf |
|
Provider_name_length |
8 |
Uimsbf |
最大值0x10 |
For(i=0;i<N;i++){ |
|
|
|
Proyider_name_char |
8 |
uimsbf |
|
Asset_description_descriptor(有用资源说明描述符)
在下面的表14中定义的这个描述符提供有用资源的文本的说明。
表14
名称 |
尺寸(比特) |
格式 |
数值/注解 |
Asset_description_descriptor(){ |
|
|
|
Descriptor_tag |
8 |
uimsbf |
0xC5 |
Descriptor_length |
8 |
uimsbf |
|
ISO_639_Language_Code |
24 |
uimsbf |
|
For(j=0;j<N;j++){ |
|
|
|
Description_char |
8 |
uimsbf |
|
} |
8 |
|
|
} |
|
|
|
Actors_descriptor(演员描述符)
在下面的表15中定义的这个描述符提供有关在比如电影的有用资源中出现的演员的信息。
表15
名称 |
尺寸(比特) |
格式 |
数值/注解 |
Actors_descriptor(){ |
|
|
|
Descriptor_tag |
8 |
Uimsbf |
0xC6 |
Descriptor_length |
8 |
Uimsbf |
|
ISO_639_Language_Code |
24 |
Uimsbf |
|
For(j=0;j<N;j++){ |
|
|
|
Actors_char |
8 |
uimsbf |
|
} |
|
|
|
} |
|
|
|
Package_descriptor(包描述符)
在下面的表16中定义的这个描述符提供有关有用资源的包的信息。
表16
名称 |
尺寸(比特) |
格式 |
数值/注解 |
Package_descriptor(){ |
|
|
|
Descriptor_tag |
8 |
Uimsbf |
0xC7 |
Descriptor_length |
8 |
Uimsbf |
|
ISO_639_Language_Code |
24 |
uimsbf |
|
For(i=0;i<N;i++){ |
|
|
|
Package_char |
8 |
Uimsbf |
|
} |
|
|
|
} |
|
|
|
以下的描述符应用于所有的有用资源,因而它们应当位于有用资源信息表格的公共描述符循环中,或如果必须优先于特定的有用资源,则它可以在asset_loop中重复。
Checkout_Length_descriptor(检验长度描述符)
在下面的表17中定义的这个描述符提供有关检验长度的信息。它提供用于使到VoD服务器的连接超时的机制。
表17
名称 |
尺寸(比特) |
格式 |
数值/注解 |
Checkoutlength_descriptor(){ |
|
|
|
Descriptor_tag |
8 |
Uimsbf |
0xC4 |
Descriptor_length |
8 |
uimsbf |
|
CheckoutLength |
16 |
uimsbf |
|
} |
|
|
|
Stream_control_descriptor(流控制描述符)
在下面的表18中定义的这个描述符提供流控制信息。它在下面被定义为使用if-语句的变量数据结构。
表18
名称 |
尺寸(比特) |
格式 |
数值/注解 |
Stream_control_descriptor(){ |
|
|
|
Descriptor_tag |
8 |
uimsbf |
0xC8 |
Descriptor_length |
8 |
uimsbf |
|
Control_flag |
8 |
uimsbf |
见解释 |
If(Pause_Control==’1’){ |
|
|
|
PauseLimitSeconds |
16 |
uimsbf |
|
ActionOnPauseLimits |
8 |
uimsbf |
|
} |
|
|
|
If(Fast_Forward_Control==’1’){ |
|
|
|
PauseLimitSeconds |
16 |
uimsbf |
|
ActionOnPauseLimits |
8 |
uimsbf |
|
} |
|
|
|
If(Rewind_Control==’1’){ |
|
|
|
PauseLimitSeconds |
16 |
uimsbf |
|
ActionOnPauseLimits |
8 |
uimsbf |
|
} |
|
|
|
} |
|
|
|
Control_flag(控制标记)属性在下面的表19中被描述。
表19
比特 |
说明 |
注解 |
0 |
暂停控制 |
0:禁止/1:使能 |
1 |
快进控制 |
0:禁止/1:使能 |
2 |
倒带控制 |
0:禁止/1:使能 |
3-7 |
保留 |
|
类别更新
当VoD应用被起动时,有用资源信息表格被装载,以显示可用的有用资源。(为了隐藏具有未授权的电影的类别,考虑类别等级评定)。
当用户需要特定的有用资源的附加信息时,它装载相应的Asset_more_information_table。
此外,为了更新有用资源信息,以下在表20中描述的Catalog_Update_table(类别更新表格)可以被广播,它表示应当被更新的类别和子类别。
表20
名称 |
尺寸(比特) |
格式 |
数值/注解 |
Catalog_update_section(){ |
|
|
|
Table_id |
8 |
Uimsbf |
0x93 |
Section_syntax_indicator |
1 |
Bslbf |
1b |
Private_syntax_indicator |
1 |
Bslbf |
1b |
ISO reserved |
2 |
Bslbf |
11b |
Section_length |
12 |
Uimsbf |
最大值=0xFFD |
Reserved |
16 |
Uimsbf |
0xFFFF |
Reserved |
2 |
Bslbf |
11b |
Version_number |
5 |
uimsbf |
|
Current_next_indicator |
1 |
Bslbf |
1b |
Section_number |
8 |
uimsbf |
|
Last_section_number |
8 |
uimsbf |
|
Update_counter |
8 |
uimsbf |
|
Reserved |
4 |
Bslbf |
1111b |
Current_Action_flag |
4 |
bslbf |
|
Data_Parsing_Format |
8 |
uimsbf |
见解释 |
Priority |
2 |
Bslbf |
11b |
Data_Cyphered_flag |
1 |
bslbf |
|
Data_Compressed_flag |
1 |
bslbf |
|
Data_Cyphering_Algorithm |
2 |
uimsbf |
见解释 |
Data_Compressing_Algorithm |
2 |
uimsbf |
见解释 |
Reserved |
4 |
bslbf |
|
Counter_descriptor_loop_length |
12 |
uimsbf |
|
for(i=0,i<N1,i++){ |
|
|
|
Category_descriptor() |
|
|
|
} |
|
|
|
CRC32 |
32 |
Rpchof |
|
} |
|
|
|
Update_counter(更新计数器):每次类别被完全更新时这个计数器被递增1。当只有某些修正发生时,这个计数器被递增1。Update_Counter字段的第一个数值是0。当数据库提取器被复位时,该计数器可被复位到0,但Current_Action_Flags字段将被设置为0001,以指示整个数据库的完全更新。因为该字段尺寸被限制在8比特,所以该数值被STB理解为被模256地表示。更新计数器使得STB能够确定何时需要下载新的信息。
Category_counter_descriptor(类别计数器描述符):该计数器描述符标识有用资源信息表格的版本计数器。它使得STB能够确定有用资源信息何时已被更新,以使得STB可以下载最新的信息。
Current_action_flags(当前动作标记):相应于在内部循环中可用到的category_descriptors的各种标记可以同时出现。这些独特的标记在表21中被列出。
表21
比特 |
注解 |
0 |
Full_update_action(全部更新动作) |
1 |
Partial_Add_update_action(局部添加更新动作) |
2 |
Partial_Change_update_action(局部改变更新动作) |
3 |
Partial_Remove_update_action(局部删除更新动作) |
现在描述在Catalog_update_section(目录更新段)的描述符循环中可能出现的某些描述符。
Category_Counter_descriptor
这个描述符在下面的表22中定义,它提供类别/子类别更新计数器。
表22
名称 |
尺寸(比特) |
格式 |
数值/注解 |
Category_counter_descriptor(){ |
|
|
|
Descriptor_tag |
8 |
Uimsbf |
0xCB |
Descriptor_length |
8 |
Uimsbf |
|
Category_id |
8 |
Uimsbf |
|
Sub_category_id |
8 |
Uimsbf |
|
Counter(计数器):这个8比特字段对用于特定的类别和子类别的Asset_Information_Table和相关的Asset_more_information_table的更新进行计数。
Category_Action_descriptor(类别动作描述符)
这个描述符在下面的表23中定义,它提供与指定的类别和子类别组合所需要的更新种类有关的信息。
表23
名称 |
尺寸(比特) |
格式 |
数值/注解 |
Category_Action_descriptor(){ |
|
|
|
Descriptor-tag |
8 |
Uimsbf |
0xCC |
Descriptor_length |
8 |
Uimsbf |
|
Action |
8 |
Uimsbf |
|
For(i=0;i<n;i++){ |
|
|
|
Category_id |
8 |
Uimsbf |
|
Sub_category_id |
8 |
Uimsbf |
|
} |
|
|
|
} |
|
|
|
Action(动作):这个8比特字段规定在被包含于循环中的类别与子类别列表的类别更新期间要执行的动作。可能的动作在表24中给出。
表24
数值 |
动作 |
0x00 |
更新全部(不包括以后的Tidext循环) |
0x01 |
加上某些类别 |
0x02 |
改变某些类别 |
0x03 |
删除某些类别 |
Plant_Id机制
Plant_id机制被使用来建立与选定的服务器的VOD会话连接。首先,接收机/译码器13检索在下面的表25中定义的初始化文件,并扫描在表27中所示的lookup_frequency_list_descriptor(查找频率列表描述符)循环中可得到的所有频率,直到有可能调谐到所扫描的频率之一。当一个频率被找到时,则必须对该同一个描述符中描述的PID进行Plant_Id定义表格的过滤,有tidext等于Plant_id_selection(设备标识选择)字段(总是在同一个描述符中),以检索正确的Service_Group_Id(业务组标识)。并行地,应用通过使用在VOD_initialization_table(VOD初始化表格)的common_descriptor_loop(公共描述符循环)中可得到的routing_ip(路由_ip)描述符来连接到http服务器,以检索VOD服务器的IP地址。
VOD_initialization_section(VOD初始化段)的语法在下面的表25中被显示。
表25
名称 |
尺寸(比特) |
格式 |
数值/注解 |
VOD_Initialization_section(){ |
|
|
|
Table_id |
8 |
Uimsbf |
0x94 |
Section_syntax_indicator |
1 |
Bslbf |
0b |
Private_syntax_indicator |
1 |
Bslbf |
1b |
ISO_reserved |
2 |
Bslbf |
11b |
Section_length |
12 |
Uimsbf |
最大值=0xFFD |
Private_Filtering_Extension |
56 |
uimsbf |
|
Data_Parsing_Format |
8 |
uimsbf |
见解释 |
Prio_rity |
2 |
Bslbf |
11b |
Data_Cyphered_flag |
1 |
uslbf |
|
Data_Compressed_flag |
1 |
bslbf |
|
Data_Cyphering_Algorithm |
2 |
uimsbf |
见解释 |
Data_Compressing_algorithm |
2 |
uimsbf |
见解释 |
Reserved |
4 |
Bslbf |
1111b |
Common_Descriptor_into_length |
12 |
uimsbf |
|
for(i=0,i<N1,i++){ |
|
|
|
Category_descriptor() |
|
|
|
} |
|
|
|
for(i=0,i<N2,i++){ |
|
|
|
Plant_Id_length |
8 |
uimsbf |
N |
Plant_Id |
8*n |
uimsbf |
|
Reserved |
4 |
bslbf |
1111b |
Plant_Id_Descriptor_length |
12 |
uimsbf |
N3 |
for(i=0,i<N3,i++){ |
|
|
|
Descriptor() |
|
|
|
} |
|
|
|
} |
|
|
|
} |
|
|
|
Private_Filtering_Extension:为了使得硬件过滤器的使用最佳化,这个56比特字段可被使用来通过MLOAD_table(MLOAD表格)、MLOAD_group(MLOAD组)、或MLOAD_section(MLOAD段)的调用而扩展专用过滤。
Plant_id_length:被使用来定义Extra_identifier字段的字节数。
Plant_id:由随后的描述符循环所描述的一个识别符或一组识别符。
下面描述在表25的VOD_initialization_section(VOD初始化段)中使用的描述符。
Cable_deliver_system_descriptor(Cable传送系统描述符)
在下面的表26中定义的Cable_deliver_system_descriptor可以位于具有被设置为0000.0000MHz的频率字段的common_descriptor_loop中。它将有助于给出用于所有的以下频率的缺省调制参量。
表26
语法 |
比特尺寸 |
格式 |
数值/注解 |
Cable_delivery_system_descriptor(){ |
|
|
|
Descriptor_tag |
8 |
Uimsbf |
0x44 |
Descriptor_length |
8 |
Uimsbf |
|
Frequency |
32 |
bslbf |
|
Reserved_future_use |
12 |
bslbf |
|
FEC outer |
4 |
bslbf |
|
Moduration |
8 |
Bslbf |
|
Symbol_rate |
28 |
Bslbf |
|
FEC_inner |
4 |
Bslbf |
|
} |
|
|
|
在plant_id_descriptor_loop中可能的描述符如下:
Lookup_Frequency_List_descriptor
这个描述符在表27中被定义。
表27
名称 |
尺寸(比特) |
格式 |
数值/注解 |
Looup_Frequency_List_Descriptor(){ |
|
|
|
Descriptor_tag |
8 |
uimsbf |
0xCD |
Descriptor_length |
8 |
uimsbf |
|
For(i=0;i<n;I++){ |
|
|
|
Frequency |
32 |
bslbf |
|
Reserved |
3 |
bslbf |
111 |
Plant_Id_PID |
13 |
uimsbf |
|
Plant_Id_Selection |
16 |
uimsbf |
可任选的 |
} |
|
|
|
} |
|
|
|
Frequency(频率):这是一个32比特字段,给出4比特的BCD数值,规定8字符的频率值。该频率以MHz被编码,其中小数出现在第四个字符后。
Plant_Id_PID:在其中接收机/译码器13可找到Plant_Id文件的PID值。
Plant_id_Selection:这个16比特字段可以是要对PID过滤的Tid_ext 值,而TID 值是静态的以检索正确的Plant_Id_Definition_Table。这个字段是可任选的,仅仅用于将来的扩展。如果是任选的,它的数值将被设置为0xFFFF。
在另外的例子中,保留的字段和Plant_Id_PID字段可被合并,以便给出相关标志数值,这将有助于找到真正的PID值,而总是很难利用一个具有静态数据PID引用的系统。
以下的三个描述符应当在公共描述符循环中被设置为Http ODA服务器。
Connection_data_descriptor(连接数据描述符)
这个描述符在表28中被定义。
表28
语法 |
比特尺寸 |
格式 |
数值/注解 |
Connection_data_descriptor(){ |
|
|
|
Descriptor_tag |
8 |
Uimsbf |
0xE8 |
Descriptor_length |
8 |
Uimsbf |
|
Login_name_length |
8 |
Uimsbf |
|
For(i=0;i<N;i++){ |
|
|
|
Login_name |
8*n |
Uimsbf |
|
} |
|
|
|
Password_length |
8 |
Uimsbf |
|
For(i=0;i<N;i++){ |
|
|
|
Password |
8*n |
uimsbf |
|
} |
|
|
|
} |
|
|
|
Routing_Ipv4_descriptor(路由Ipv4描述符)这个描述符在表29中被定义。
表29
语法 |
比特尺寸 |
格式 |
数值/注解 |
routing_descriptor_ipv4(){ |
|
|
|
Descriptor_tag |
8 |
uimsbf |
0x06 |
Descriptor_length |
8 |
uimsbf |
|
For(i=0;i<N;i++){ |
|
|
|
component_tag |
8 |
uimsbf |
|
Address |
32 |
uimsbf |
|
port_number |
16 |
uimsbf |
|
adress_mask |
32 |
uimsbf |
|
} |
|
|
|
在这个例子中没有使用Component_tag(分量标志)字段。它的数值被设置为0。
Routing_Ipv6_descriptor(路由Ipv6描述符)
这个描述符在表30中被定义。
表30
语法 |
比特尺寸 |
格式 |
数值/注解 |
routing_descriptor_ipv6(){ |
|
|
|
Descriptor_tag |
8 |
uimsbf |
0x07 |
Descriptor_length |
8 |
uimsbf |
|
For(i=0;i<N;i++){ |
|
|
|
Component_tag |
8 |
uimsbf |
|
Address |
128 |
uimsbf |
|
port_number |
16 |
uimsbf |
|
adress_mask |
128 |
uimsbf |
|
} |
|
|
|
} |
|
|
|
在这个例子中没有使用Component_tag(分量标志)字段。它的数值被设置为0。
表31定义Plant_ID_Definition_Section的语法。
表31
名称 |
尺寸(比特) |
格式 |
数值/注解 |
Plant_Id_Definition_section(){ |
|
|
|
Table_id |
8 |
Uimsbf |
0x95 |
Section_syntax_indicator |
1 |
Bslbf |
1b |
Private_syntax_indicator |
1 |
Bslbf |
1b |
ISO_reserved |
2 |
Bslbf |
11b |
Section_length |
12 |
Uimsbf |
最大值=0xFFD |
Plant_Id_Selection |
16 |
Uimsbf |
Tid_ext |
Reserved |
2 |
Bslbf |
11b |
Version_number |
5 |
Uimsbf |
|
Current_next_indicator |
1 |
Bslbf |
1b |
Section_number |
8 |
uimsbf |
|
Last_section_number |
8 |
uimsbf |
|
Filter_extension |
16 |
uimsbf |
|
Data_Parsing_Format |
8 |
uimsbf |
见解释 |
Priority |
2 |
Bslbf |
11b |
Data_Cyphered_flag |
1 |
bslbf |
|
Data_Compressed_flag |
1 |
bslbf |
|
Data_Cyphering_Algorithm |
2 |
uimsbf |
见解释 |
Data_Compressing_Algorithm |
2 |
uimsbf |
见解释 |
Reserved |
4 |
Bslbf |
1111b |
Common_Descriptor_loop_length |
12 |
uimsbf |
N1 |
for(i=0;I<N1;i++){ |
|
|
|
Descriptor() |
|
|
|
} |
|
|
|
CRC_32 |
32 |
Rpchof |
|
} |
|
|
|
VOD_Service_Group_Descriptor
在下面表32中所描述的这个描述符在Plant_ID_definition_section内被使用。
表32
名称 |
尺寸(比特) |
格式 |
数值/注解 |
VOD_Service_Group_descriptor(){ |
|
|
|
Descriptor_tag |
8 |
uimsbf |
0xCE |
Descriptor_length |
8 |
uimsbf |
|
Service_group_Identifier |
32 |
uimsbf |
|
} |
|
|
|
VOD信令化的使用
下面这节讨论如何使用标准的和专用的C+信令化来从数据流中检索专用VOD表格。
首先必须声明VOD门户业务。这是藉助于等于专用数值0xD0(表示这个业务是VOD业务)的业务类型完成的。这种业务类型是要在CNIT的service_list_descriptor(业务列表描述符)和SNT(业务网络表格)的service_descriptor(业务描述符)中被报告的。
这个业务应当找到必要的声明,以激活VOD应用;VOD业务类型声明可以足够达到这一点。
然后,在属于这个业务的PMT的分量循环中,将找到具有stream_type(流类型)为0xC1和附着PID的专用数据基本流的循环。这个stream_type的每个流将包含appli_list_descriptor(应用列表描述符),用于规定这些数据中的哪些数据使用该PID被广播。
在下面表33中给出appli_list_descriptor的语法。
表33
语法 |
比特尺寸 |
格式 |
数值/注解 |
Appli_list_descriptor(){ |
|
|
|
Descriptor_tag |
8 |
uimsbf |
0xC2 |
Descriptor_length |
8 |
uimsbf |
|
For(i=0;i<N;i++){ |
|
|
|
Appli_name |
64 |
uimsbf |
8字符 |
} |
|
|
|
} |
|
|
|
Appli_name(应用名称)可以取以下的数值(限于8个字符):
·VOD_INIT,用于VOD_Initialization_Table
·ASSET,用于Asset_Information_Table(名称将被填入多到8个字符的空间)
·DETAILS,用于Asset_More_Information_Table
·CATEGORY,用于Category_Definition_Table
·UPDATE,用于Catalog_Update_Table(名称将被填入多到8个字符的空间)
注意,对于广播,ASSET和CATEGORY可被放置在同一个PID中,这样,两个appli_list_descriptor将在这个PID名义下存在,以使得将来的分离更容易。
DETAILS由于数据量和循环周期而应当处在与ASSET和CATEGORY不同的PID中。
VOD应用在开始时首先显示类别,以及如果用户要求,则显示在ASSET表格中存在的详细资料。一旦数据的PID被定义,就允许直接使用所分配的TID数值来进行过滤,而不是使用整个DMT机制,以便加速接入到信息。(DMT将以给出在TID与table_name之间的解决方案(与appli_list_descriptor中的相同)的任何方式被广播)
在目录的分析期间,UPDATE表格将被监视,以防在类别或有用资源中出现改变。
然后,一旦用户作出他的选择,VOD应用就使用VOD_INIT数据来扫描它的集线器频率。对于更多的细节可参阅以上的Plant_id_mechanism。
一旦当前的频率被检索到,那么调谐就是可能的,至少一个Plant_Id_Definition_Table要在输送流的第一PMT中定义的PID上被广播。所谓第一PMT是指,这是在PAT内声明的第一业务,其中PAT应当包含stream_type(流类型)为0xC1的一个基本流,该基本流具有其中包含PLANT_ID名称的appli_list_descriptor。这个PID有在用于该频率的VOD_initialization_table的lookup_frequecy_list_descriptor中也描述过的PID数值。为了遵从DVB而建立了这个机制,以及使得不具有虚幻的PID。
然后,在这个PID上,plant_Id_definition_Table被广播,TIDExt数值等于在用于当前调谐的频率的VOD_initialization_table的lookup_frequecy_list_descriptor中已经定义的plant_Id_Section数值。如果该过滤不匹配,则尝试另一个频率。此外,中止检索给定频率的plant_Id_definition_Table,将意味着跳到在VOD_initialization_table的当前lookup_frequecy_list_descriptor内的下一个被描述的频率。
如果进行了全部的循环而没有任何匹配,则显示一个明显的错误,或者对可得到的整个频率表进行新的尝试。
明显的错误是指以下的可能性之一:
·没有找到频率
·对于调谐的频率没有找到Plant_id表格
·没有找到该频率上的PAT信令
·没有找到该频率上的PMT信令
其它方面,藉助于在VOD_initialization_table中的IP_descriptors(IP描述符),找到服务器的地址,以便建立VOD会话连接。
上述的说明根据以下方法定义专用表格结构:
·用于短段的模型;
·用于长段的模型;以及
·取决于描述符的应用方面的例子。
上述的这个系统提供以下的策略上的优点:
·它允许更有效的发展;
·它允许创建不依赖于接收机/译码器13的制造商和条件接入系统的制造商的应用实现;
·增加可被使用的数据量,而不增加花费-这是通过数据压缩来完成的;以及
·产品更新的更容易开发。
该系统也为应用广播提供以下的优点:
·提供通用表格分析器;
·分析器的改变对于现有的应用没有大的影响;
·专用表格的定义的正常化;
·开发者可集中注意力在所需要的数据过滤和特定的描述符上;
·更容易处理表格内容;
·数据的提取由分析器执行;
·保持数据格式的后向兼容性;
·与现有的格式相结合-专用段可以使用现有的DVB描述符,而DVB表格可使用专用描述符;
·保证无回退;
·对象方法与描述符相联系;
·方便于单一测试和集成;
·方便于操作上的综合(就地的,不会负面影响实况广播);以及
·减少了开发应用所需要的时间。
可以看到,本发明已经完全通过例子的方式在以上被描述,以及可以在本发明的范围内作出细节上的修正。
在本说明、以及(在适当的场合)权利要求和附图中揭示的每个特性可以独立地或以任何适当的组合的方式被提供。