CN108702548A - 使用水印来信令资源标识符的系统和方法 - Google Patents

使用水印来信令资源标识符的系统和方法 Download PDF

Info

Publication number
CN108702548A
CN108702548A CN201780013834.8A CN201780013834A CN108702548A CN 108702548 A CN108702548 A CN 108702548A CN 201780013834 A CN201780013834 A CN 201780013834A CN 108702548 A CN108702548 A CN 108702548A
Authority
CN
China
Prior art keywords
message
watermark
uri
code
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201780013834.8A
Other languages
English (en)
Inventor
吴筱波
凯兰·穆凯什·米斯拉
萨钦·G·德施潘德
克里斯托弗·安德鲁·西格尔
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sharp Corp
Original Assignee
Sharp Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sharp Corp filed Critical Sharp Corp
Priority to CN201811234800.4A priority Critical patent/CN109275035A/zh
Publication of CN108702548A publication Critical patent/CN108702548A/zh
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/835—Generation of protective data, e.g. certificates
    • H04N21/8358—Generation of protective data, e.g. certificates involving watermark
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H04N21/4353—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream involving decryption of additional data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/4722—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting additional data associated with the content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H04N21/4351—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream involving reassembling additional data, e.g. rebuilding an executable program from recovered modules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44008—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving operations for analysing video streams, e.g. detecting features or characteristics in the video stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6581—Reference data, e.g. a movie identifier for ordering a movie or a product identifier in a home shopping application
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8126—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts
    • H04N21/814—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts comprising emergency warnings

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Human Computer Interaction (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Emergency Management (AREA)
  • Theoretical Computer Science (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Editing Of Facsimile Originals (AREA)
  • Television Systems (AREA)

Abstract

一种装置，其可以被配置成：使用水印来信令信息。一种装置，其可以被配置成：确定与关联于多媒体内容的资源的地址相关联的标识符并且将所述标识符嵌入到表示多媒体内容的信号中。一种装置，其可以被配置成：接收多媒体信号；从所述多媒体信号解析与资源的地址相关联的标识符；生成包括所述标识符的查询；以及响应于所述查询接收补充内容。

Description

使用水印来信令资源标识符的系统和方法
技术领域
本公开涉及交互式电视领域。
背景技术
数字媒体播放功能可以包含在各种装置中，包括数字电视包括所谓的“智能”电视、机顶盒、膝上型计算机或桌面型计算机、平板计算机、数字录音装置、数字媒体播放器、视频游戏装置、蜂窝电话包括所谓的“智能”电话、专用视频流装置等。数字媒体内容(例如，视频和/或音频节目、和基于应用的增强)可以源自多个源和/或从多个源分配，包括例如空中电视提供商或广播公司、卫星电视提供商、有线电视提供商、在线媒体服务提供商包括所谓的流媒体服务提供商等。数字媒体内容可以通过分组交换网络传送，包括双向网络诸如互联网协议(IP)网络和单向网络诸如数字广播网络。
可以根据传输标准将数字媒体内容从源传输到接收器装置(例如，数字电视或智能电话)。传输标准的示例包括数字视频广播(DVB)标准、综合服务数字广播(ISDB)标准、以及由高级电视系统委员会(ATSC)开发的标准，包括例如ATSC 2.0标准。ATSC目前正在开发所谓的ATSC 3.0标准体系。传输标准可以定义用于封装数字媒体内容以进行传输的机制，并且可以定义用于信令与数字媒体内容相关联的信息的机制。用于信令与数字媒体内容相关联的信息的当前技术可能不太理想。
发明内容
大体上讲，本公开描述了信令资源标识符的技术。具体地，本公开描述了使用水印来信令资源标识符的示例技术。本文描述的技术可以用于提高使用水印来信令资源标识符时的安全性。本文描述的技术可能对多媒体表示的再分配特别有用。应该注意的是，尽管在一些示例中，本公开的技术是相对于ATSC标准包括目前正在开发的那些ATSC标准描述的，但是本文描述的技术通常适用于任何传输标准。例如，本文描述的技术通常适用于DVB标准、ISDB标准、ATSC标准、数字地面多媒体广播(DTMB)标准、数字多媒体广播(DMB)标准、混合广播宽带电视(HbbTV)标准、和其它视频编码标准中的任何标准。进一步地，应该注意的是，将文档通过引用并入本文是出于描述的目的，并且不应该被构造为限制和/或相对于本文使用的术语产生歧义。例如，在一个引用的参考文献提供了与另一个引用的参考文献不同的术语定义和/或与本文使用的术语不同的术语定义的情况下，应该以广泛地包括每个相应的定义的方式和/或以包括替代方案中的每个特定定义的方式来解释该术语。
本发明的方面是一种用于请求补充内容的方法，该方法包括：接收多媒体信号；从该多媒体信号提取水印消息；从水印消息解析指示权限组件的一部分的语法元素；从水印消息解析指示路径组件的语法元素；以及通过形成包括权限组件的一部分和路径组件的资源标识符来创建对补充内容的请求。
本发明的方面是一种装置，该装置包括一个或多个处理器，该一个或多个处理器被配置成：从多媒体信号提取水印消息；从水印消息解析指示权限组件的一部分的语法元素；从水印消息解析指示路径组件的语法元素；以及通过形成包括权限组件的一部分和路径组件的资源标识符来创建对补充内容的请求。
本发明的方面是一种用于在水印消息的有效载荷中信令不透明用户数据的方法，该方法包括：确定信息所需的数据片段数量；基于信息所需的数据片段数量，信令识别消息块类型的语法元素；以及信令指示消息块有效载荷的长度的语法元素，其中，指示消息块有效载荷的长度的语法元素的位数基于消息块类型。
附图说明
图1是图示了可以实施本公开的一个或多个技术的系统的示例的框图。
图2是图示了可以实施本公开的一个或多个技术的机顶盒和示例接收器装置的示例的框图。
图3A是图示了根据本公开的一个或多个技术的信令资源标识符的示例的通信流程图。
图3B是图示了根据本公开的一个或多个技术的信令资源标识符的示例的通信流程图。
图4是图示了根据本公开的一个或多个技术的信令资源标识符信息的示例的流程图。
图5是图示了根据本公开的一个或多个技术的解析资源标识符信息的示例的流程图。
具体实施方式
计算装置和/或传输系统可以基于包括一个或多个抽象层的模型，其中，每个抽象层处的数据都是根据特定结构来表示的，例如，分组结构、调制方案等。开放式系统互联(OSI)模型定义了7层堆栈模型，包括应用层、表示层、会话层、传输层、网络层、数据链路层、和物理层。应该注意的是，在描述堆栈模型(例如，内容传送协议模型)中的层时的术语上和下的使用可以基于作为最上层的应用层和作为最下层的物理层。进一步地，在一些情况下，术语“层1”或“L1”可以用于指代物理层，术语“层2”或“L2”可以用于指代链路层，并且术语“层3”或“L3”或“IP层”可以用于指代网络层。物理层通常可以指电信号形成数字数据的层。例如，物理层可以指定义调制的射频(RF)符号如何形成数字数据帧的层。数据链路层也可以称为链路层可以指在发送侧的物理层处理之前和接收侧的物理层接收之后使用的抽象。应该注意的是，发送侧和接收侧是逻辑角色，并且单个装置可以在一个实例中充当发送侧而在另一个实例中充当接收侧。网络层通常可以指发生逻辑寻址的层。即，网络层通常可以提供寻址信息(例如，互联网协议(IP)地址)，使得数据分组可以被传送到网络内的特定节点(例如，计算装置)。传输层、会话层、表示层、和应用层中的每一个都可以定义如何传送数据以供用户应用使用。
就数字媒体内容而言，水印技术通常可以指将信息嵌入到视频和/或音频信号中的过程。即，在一些示例中，水印技术可以从高层信号(例如，从能够呈现或渲染多媒体数据的信号)提取补充数据。水印可以用于再分配场景中。再分配场景的示例可以包括装置接收多媒体信号(例如，视频和/或音频信号)并且从该多媒体信号恢复嵌入的信息的情境。例如，接收器装置(例如，数字电视)可以接收来自多媒体接口(例如，高清多媒体接口(HDMI)等)的未压缩的视频信号，并且接收器装置可以从该未压缩的视频信号恢复嵌入的信息。在一些情况下，当所谓的多频道视频节目分销商(MVPD)(例如，有线电视服务运营商、卫星电视服务运营商、互联网协议电视(IPTV)服务运营商等)充当接收器装置与内容提供商(例如，本地网络附属机构)之间的中介时，可能会发生再分配场景。在这些情况下，机顶盒可以通过特定的物理层、链路层、和/或网络层来接收多媒体服务数据流并且将未压缩的多媒体信号输出到接收器装置。因此，在再分配场景中，接收器装置可以在不访问内容传送协议模型的较低层的情况下接收多媒体信号。应该注意的是，在一些示例中，再分配场景可以包括机顶盒或者家用媒体服务器充当家庭视频分配器并且将数据(例如，通过本地的有线或无线网络)提供给连接的装置(例如，智能手机、平板计算机等)的情境。
水印技术可以用于确保，无论如何分配多媒体内容，接收器装置都可以检索到补充内容(例如，紧急消息、替代音轨、应用数据、隐藏字幕数据等)。在一些情况下，内容提供商可能想要确保，在将内容渲染给查看者时，补充内容是可用的。例如，本地网络附属机构可以将水印嵌入到视频信号中以确保，接收器装置可以检索与本地电视呈现相关联的补充信息(例如，本地新闻广播)，从而将补充内容呈现给查看者。进一步地，在一些情况下，MVPD可以将水印嵌入到视频信号中以增强源自内容提供商的内容(例如，提供目标补充广告)。
应该注意的是，如本文所使用的，术语“接收器装置”可以指能够接收视频和/或音频信号并且根据接收到的信号渲染视觉和听觉数据的装置(例如，接收未压缩的多媒体信号的数字电视)。进一步地，术语“机顶盒”可以指被配置成接收多媒体服务数据流(例如，空中广播、有线电视服务、卫星电视服务、所谓的互联网(OTT)电视服务等)并且输出可以被渲染以由接收器装置呈现的视频和/或音频信号。应该注意的是，接收器装置和机顶盒的这种示例定义不应该被构造为限制本文描述的技术的范围。例如，单个装置可以被配置成执行机顶盒和接收装置的功能。即，例如，数字电视可以被配置成接收多媒体数据流并且执行低层处理以提取未压缩的多媒体信号并根据该多媒体信号渲染多媒体内容。进一步地，无论如何描述多媒体内容，本文描述的技术通常都可以适用于水印。例如，本文描述的技术可以适用于包括在通过使用物理介质(例如，光盘)分配的多媒体内容中的水印。
在一些示例中，水印可以信令资源标识符。如本文所使用的，资源标识符可以包括URI、URL、统一资源名称(URN)、其组合和/或其组件。如通过引用全部并入本文Request forComment(RFC)3986IETF：“Uniform Resource Identifiers(URI):Generic Syntax”，RFC3986，2005年1月所描述的，URI通常可以被描述为具有根据以下格式设置的组件部分：
scheme://authority/path
在上文的示例中，方案(scheme)组件可以包括定义的方案(例如，HTTP、HTTPSecure(HTTPS)、文件传输协议(FTP)等)，权限(authority)组件可以包括主机，包括例如由注册名称(例如，域名)识别的主机，并且路径(path)组件可以包括一系列路径片段以识别特定资源。
传输标准、包括目前正在开发的传输标准可以指定兼容装置可以提取数据的水印发射协议以及可以从该水印发射协议提取的数据类型。在候选标准(Candidate Standard)中描述了目前正在开发的ATSC 3.0标准套件的各个方面，该候选标准可以包括用于包括在ATSC 3.0标准的已出版(即，“最终的”或者“采用的”)版本中的提出方面。在下文中称为“A/335”、通过引用全部并入本文的ATSC Candidate Standard:Video Watermark Emission(A/335),Doc.S33-156r1,2015年11月30日描述了在ATSC 3.0系统内使用的视频水印的发布格式的特定提出方面。在下文中称为“A/334”、通过引用全部并入本文的ATSC CandidateStandard:Audio Watermark Emission(A/334),Doc.S33-160r4,描述了在ATSC 3.0系统内使用的音频水印的发布格式的特定提出方面。进一步地，在下文中统称为“A/336”、通过引用全部并入本文的ATSC Candidate Standard:Content Recovery(A/336),Doc.S33-178r2,2016年1月15日及其随后的修订版、包括Doc.S33-3-327r7.2016年9月12日指定了如何可以在音频水印有效载荷、视频水印有效载荷、和音轨的用户区域中携带某些信令信息以及该信息如何可以在再分配场景中用于访问补充内容。
根据A/335，视频水印可以将数据信号嵌入到视频帧的顶行的亮度值中。应该注意的是，通常不渲染视频帧的顶行，因此，在这种情况下，对查看者来说水印可能是难以察觉的。A/336描述了视频水印有效载荷可以包括一种或多种消息。表1提供了在A/336的2016年1月15日的Doc.S33-178r2(在下文中称为“A/336r2”)所提供的视频水印有效载荷中包括的消息的语法。
表1
A/336r2为相应语法元素wm_message_id、wm_message_block_length、wm_message_version、fragment_number、last_fragment、wm_message_bytes()、message_CRC_32、和CRC_32提供了以下定义。应该注意的是，在表1和包括在本公开的其它表中，uimsbf可以指首先从最高有效位传输的无符号整数。进一步地，应该注意的是，在一些示例中，wm_message_id、wm_message_block_length、wm_message_version、fragment_number、和last_fragment可以被称为形成水印消息的报头，并且wm_message_bytes()可以被称为水印消息的实例。
wm_message_id——这个8位值应唯一地识别根据下面的表[2]编码的、在消息块中携带的数据字节的语法和语义。
表2
wm_message_block_length——这个8位值应指定紧接在该字段之后的直到并包括CRC_32字段的wm_message_block()中的剩余字节的数量。
wm_message_version——当且仅当wm_message()中的任何东西变化时，这个4位值应递增，在该值达到15之后转到0。接收装置中的水印处理器预计应使用wm_message_version以丢弃副本。视频信号可以包括相同的wm_message()的重复实例以提高传送的可靠性。
fragment_number——这个2位值应指定当前消息片段的编号减去一。例如，fragment_number中的值‘00’指示wm_message_block()携带了消息的第一(或者唯一)片段，fragment_number的值‘01’指示wm_message_block()携带了消息的第二片段等。fragment_number的值应小于或等于last_fragment的值。
last_fragment——这个2位的值应指定用于传送完整的wm_message()的最后一个片段的片段编号。last_fragment中的值‘00’指示未使用分段(包含在内的wm_message()是完整的)。last_fragment中的值‘01’指示wm_message()应被分为两部分进行传送，值‘10’指示wm_message()应被分为三部分进行传送，并且值‘11’指示wm_message()应被分为四部分进行传送。fragment_number和last_fragment的这一对值可以被认为是信号“N的部分M”。
wm_message_bytes()——当last_fragment的值是0时，wm_message_bytes()应是由wm_message_id的值识别的水印消息的完整实例。当last_fragment的值非零时，wm_message_bytes()应是该水印消息的片段，其中，根据[A/336r2]的章节5.1.2中给定的规则来构造每个片段。将具有给定的wm_message_id和wm_message_fragment_version数量的wm_message_block()的全部实例级联应产生与该wm_message_id相关联的完整的wm_message_id。
message_CRC_32——当将消息分为两个或多个片段(例如，last_fragment>0)发送时，应在分段消息的最后一个片段中提供覆盖完整消息(在分段之前)的32位[循环冗余检验(CRC)]。对于未分段的消息(例如，当last_fragment的值为0时)，或者在除了最后一个片段的任何片段中(例如，当fragment_number≠last_fragment时)，不存在message_CRC_32字段。当存在message_CRC_32时，message_CRC_32应包含CRC值，该CRC值在处理了整个重组的消息有效载荷之后在ISO/IEC 13818-1[ISO:“ISO/IEC IS 13818-1(2013)(E),International Standard,Information technology-Generic coding of movingpictures and associated audio information：systems”，其通过引用全部并入本文]Annex A中定义的解码器中给出寄存器的零输出。生成的多项式为1+x+x2+x4+x5+x7+x8+x10+x11+x12+x16+x22+x23+x26。
CRC_32——这个32位字段应包含CRC值，该CRC值在处理了整个消息块之后，在ISO/IEC 13818-1,Annex A中定义的解码器中给出寄存器的零输出。生成的多项式为1+x+x2+x4+x5+x7+x8+x10+x11+x12+x16+x22+x23+x26。
表3提供了在A/336的2016年9月12日的Doc.S33-3-327r7(在下文中称为“A/336r7”)所提供的视频水印有效载荷中包括的消息的语法。
表3
在A/336r7中，相应语法元素wm_message_block_length和wm_message_version的定义与上文相对于表1提供的定义类似。A/336r7提供了相应语法元素wm_message_id、fragment_number、last_fragment、wm_message_bytes()、message_CRC_32、和CRC_32的以下定义。
wm_message_id——这个8位值应唯一地识别根据下面的表[4]编码的、在消息块中携带的数据字节的语法和语义。
表4
fragment_number——这个2位或者8位值应指定当前消息片段的编号减去一。当(wm_message_id&0x40)＝＝0)，即第六位的值是'0'时，那么fragment_number在长度上应是2位。当(wm_message_id&1x40)＝＝1)，即，第六位的值是'1'时，那么fragment_number在长度上应是8位。例如，fragment_number中的值0指示wm_message_block()携带了消息的第一(或者唯一)片段，fragment_number的值1指示wm_message_block()携带了消息的第二片段等。fragment_number的值应小于或等于last_fragment的值。
last_fragment——这个2位或者8位值应指定用于传送完整的水印消息的最后一个片段的片段编号。当(wm_message_id&0x40)＝＝0)，即，第六位的值是'0'时，那么last_fragment在长度上应是2位。当(wm_message_id&0x40)＝＝1)，即，第六位的值是'1'时，那么last_fragment在长度上应是8位。last_fragment中的值0指示未使用分段(包含在内的水印消息是完整的)。last_fragment中的值1指示wm_message()应被分为两部分进行传送，值2指示水印消息应被分为三部分进行传送，并且值3指示其应被分为四部分进行传送等。fragment_number和last_fragment的这一对值可以被认为是信号“N的部分M”。
wm_message_bytes()——当last_fragment的值是0时，wm_message_bytes()应是由wm_message_id的值识别的水印消息的完整实例。当last_fragment的值非零时，wm_message_bytes()应是该水印消息的片段。将具有给定的wm_message_id和wm_message_fragment_version数量的wm_message_block()的全部实例级联应产生与该wm_message_id相关联的完整的水印消息。
message_CRC_32——当将消息分为两个或多个片段(例如，last_fragment>0)发送时，应在分段消息的最后一个片段中提供覆盖完整消息(在分段之前)的32位CRC。对于未分段的消息来说(例如，当last_fragment的值为0时)，或者在除了最后一个片段的任何片段中(例如，当fragment_number≠last_fragment时),不存在message_CRC_32字段。当存在message_CRC_32时，message_CRC_32应包含CRC值，该CRC值在处理了通过级联表[5]中指定的wm_message_id和wm_message_bytes(i)而形成的整个重组的消息有效载荷之后，在ISO/IEC 13818-1,Annex A中定义的解码器中给出寄存器的零输出。生成的多项式应是1+x+x2+x4+x5+x7+x8+x10+x11+x12+x16+x22+x23+x26。
表5
相对于表5，wm_message_block()可以传送打算在进行进一步处理之前要重组的水印消息的片段。在下面的表5中指定的wm_message()数据结构表示了重组的片段。上文针对wm_message_block()指定了表5中的wm_message_id、last_fragment、和message_CRC_32的定义。wm_message_bytes(i)字段表示包含在消息的第i个片段(从零开始计数)中的wm_message_bytes()。
CRC_32——这个32位字段应包含CRC值，该CRC值在处理了整个消息块之后，在ISO/IEC 13818-1,Annex A中定义的解码器中给出寄存器的零输出。生成的多项式应是1+x+x2+x4+x5+x7+x8+x10+x11+x12+x16+x22+x23+x26。
参照表1至2和表3至4，A/336描述了视频水印有效载荷可以包括uri_message()。uri_message()可以指统一资源标识符(URI)消息并且可以用于传送各种类型的URI。表6提供了A/336所提供的uri_message()的语法。
表6
A/336提供了语法元素uri_type、uri_strlen、和URI_string()的以下定义。
uri_type：根据表[7]中给定的编码识别遵循的URI类型的8位无符号整数字段。
表7
uri_strlen——8位无符号整数，应信令跟随的uri_string()中的字符数量。uri_strlen字段的值应针对1X视频水印发射格式(1X系统)小于或等于[A/366r2中的86和A/336r7中的78]，并且应针对2X视频水印发射格式(2X系统)小于或等于[A/366r2中的206和A/336r7中的198][如A/335所提供的]。
URI_string()——由字符组成的URI，该字符的值应被限制到由RFC 3986针对统一资源标识符(URI)允许的那些值。应由uri_strlen的值来给定字符串的长度。如果分段发送URI，则根据RFC 3986，重组之后的字符串是有效URI。
相对于表6，应该注意的是，URI_string()可以包括RFC 3986所提供的任何有效URI，因此可以包括完整的统一资源定位符(URL)，并且不受权限组件的可能值的限制。下面应进一步详细地描述URI的权限组件。
参照表1至2和表3至4，A/336描述了视频水印有效载荷可以包括emergency_alert_message()。emergency_alert_message()支持传送视频水印中的应急警报信息。表8提供了A/336所提供的emergency_alert_message()的语法。
表8
A/336提供了相应语法元素CAP_message_ID_length、CAP_message_ID、CAP_message_url_length、CAP_message_url、expires、urgency、severity_certainty的以下定义。应该注意的是，在表8和所包括的其它表中，bslbf可以指左边位优先的位串。
CAP_message_ID_length——这个8位无符号整数字段给出了以字节为单位的CAP_message_ID字段的长度。
CAP_message_ID——这个字符串应给出在[2010年7月1日的OASIS:“CommonAlerting Protocol”版本1.2，其通过引用并入本文]中定义的CAP消息的ID。这应是由CAP_message_url指示的[通用警报协议(CAP)]的cap.alert.identifier元素的值。
CAP_message_url_length——这个8位无符号整数字段给出了以字节为单位的CAP_message_url字段的长度。
CAP_message_url——这个字符串应给出可以用于检索CAP消息的URL。
expires——这个参数应指示CAP消息中的任何<info>元素的最后届满日期和时间，该参数被编码为自国际原子时间(TAI)1970年1月1日00:00:00的32位计数的秒数。
urgency——当设置为‘1’时，该标志应指示CAP消息中的最紧急的<info>元素的紧急性是“即时的”。当设置为‘0’时，它应另外指示。
severity_certainty——这是来源于确定性和严重性所需的CAP元素的值的4位字段代码……
相对于表8，应该注意的是，CAP_message_url不限于特定权限。如上所述，相对于表6，URI_string()也不限于特定权限。如下面进一步详细描述的，启用要在水印中信令的相对于可能值、包括可能权限不受限制的URI可能会对接收器装置构成安全隐患。
根据A/334，音频水印可以将数据信号嵌入到线性脉冲代码调制(PCM)音频信号中。应该注意的是，对查看者来说音频水印是难以察觉的。A/336描述了音频水印有效载荷可以包括一种或多种消息的情况。表9提供了包括在A/336r7所提供的音频水印有效载荷中的消息的语法。如表9所图示的，在表10中提供了small_domain()的语法，并且在表11中提供了large_domain()的语法。
表9
表10
表11
A/336r7提供了相应语法元素domain_type、server_field、interval_field、和query_field的以下定义：
domain_type——这个1位的值指定了有效载荷信息是针对于small_domain()还是large_domain()的。
server_field——这个字段包含服务器代码。根据由ATSC指定的注册授权机构发布的任务来设置服务器代码值。
interval_field——这个字段包含间隔码。
query_flag——当动态事件可用时，这个字段发出信号。在VP1音频水印部分中的连续的VP1有效载荷之间或者VP1视频水印部分中的连续的VP1消息组之间的该字段的值的变化指示了可以从动态事件HTTP服务器访问动态事件(如A/337[ATSC:“ApplicationSignaling and Triggers,”Document A/337,Advanced Television Systems Committee,S33-3-27r3-WD-App-Signaling，其通过引用并入本文]中定义的)。
表12提供了作为域类型的函数的服务器代码和间隔码的范围。
域类型 服务器代码范围(十六进制) 间隔码范围(十六进制)
小域 00000000-7FFFFFFF 00000000-0001FFFF
大域 00000000-007FFFFF 00000000-01FFFFFF
表12
参照表2和表4，A/336描述了视频水印有效载荷可以包括vp1_message()。包括在视频水印有效载荷中的vp1_message()可以基于表9所提供的语法。因此，在A/336中，音频水印和视频水印中的每一个都可以通过使用vp1_payloads()来信令域。域可以包括资源标识符，如上所述。如上文进一步描述的，再分配场景可以包括接收器装置接收多媒体信号并且根据该多媒体信号恢复嵌入的信息的情境。在一些示例中，嵌入到水印中的URI可以使接收器装置能够连接至(多个)服务器以下载附加数据，诸如，服务相关的表。在一些实例中，这些表可以依次指导接收器从互联网检索附加数据和/或应用。恢复过程可以指再分配场景中的接收器装置通过使用水印来访问补充内容的过程。例如，恢复过程可以包括智能电视通过使用在水印中信令的URL来下载文档的过程。
A/336描述了可以经由对包括与正在呈现的服务相关的信令数据的文件发布HTTPGET或者HTTPS GET请求来对文件服务器做出数据请求。该文件可以被称为恢复文件，并且可以包括可以用于访问补充信令和内容的信令信息的URL。根据A/336，恢复文件是JavaScript对象标记(JSON)文档。为了简洁起见，在本文中不提供A/336恢复文件格式的规范JSON模式，然而，对A/336中的Annex B进行引用。应该注意的是，在A/336中，每个VP1有效载荷都对应于包括信令数据的一个且仅一个恢复文件。
根据A/336，当接收器装置正在接收音频水印或视频水印中的VP1消息时，应通过使用以下URL模板来根据VP1有效载荷构造与恢复文件相对应的URL。
http[s]：//{hostName}/a336/rdt/{subdName}/{serverCode}-{intervalCode}.rdt
其中，
方括号中的项[..]指示可选字符串；以及
波形括号中的{..}项指示具名元素；
当查询采用HTTP时，请求应使用前缀http；以及
当查询采用HTTPS时，请求应使用前缀https。
进一步地，根据A/336，
如果VP1有效载荷的domain_type是’0’，那么：
hostName元素应具有值：
a336.{serverCode1}.{serverCode2}.{serverCode3}.{serverCode4}.0.vp1.tv；
subName元素应具有值：
{serverCode4}{serverCode3}/{serverCode2}/{serverCode1}；以及
serverCode元素应具有值：
{serverCode4}{serverCode3}{serverCode2}{serverCode1}；
以及如果VPI水印代码的domain_type是‘1’，那么：
hostName元素应具有值：
a336.{serverCode1}.{serverCode2}.{serverCode3}.1.vp1.tv；
subName元素应具有值：
{serverCode3}{serverCode2}/{serverCode1}；以及
serverCode元素应具有值：
{serverCode3}{serverCode2}{serverCode1}
其中serverCode1、serverCode2、serverCode3、和serverCode4应分别表示表达为两个字符的仅大写字母的十六进制值的VP1有效载荷(在最高有效位处对下一字节边界进行零填充)的server_field的最低有效字节至最高有效字节。
根据A/336，intervalCode元素是表达为仅大写字母的十六进制值(当domain_type＝0时，VP1有效载荷在长度上为6个字符，并且当domain_type＝1时，VP1有效载荷在长度上为8个字符)的VP1有效载荷(在最高有效位处对下一字节边界进行零填充)的interval_field的值。进一步地，A/336提供了到未指定的IP地址(在IPv4地址的情况下的0.0.0.0/32或者在IPv6地址的情况下的::/128)的{hostName}的DNS解析应指示针对代码域不支持恢复协议的情形，以及不应该将恢复文件请求发布到未指定的地址的情形。因此，VP1有效载荷可以信令资源标识符。
因此，在A/336中，针对小域，可以将与具有服务器代码值07ABCDEF和间隔码0001ABCD的恢复文件相对应的URL构造为如下：
http[s]://a336.EF.CD.AB.07.0.vp1.tv/a336/rdt/07AB/CD/EF/07ABCDEF-01ABCD.rdt
并且针对大域，可以将与具有服务器代码值07ABCD和间隔码01ABCDEF的恢复文件相对应的URL构造为如下：
http[s]://a336.CD.AB.07.1.vp1.tv/a336/rdt/07AB/CD/07ABCD-01ABCDEF.rdt
如上所述，在一些情况下，接收器装置可以独立于多媒体信号的特定源来处理水印。例如，无论水印是按照合法方式生成的(例如，从内容提供商)还是意外至恶意生成的，接收器装置都可以从通过HDMI输入接收到的任何视频信号提取水印。如上所述，嵌入到水印中的URI可以使接收器装置能够连接至(多个)服务器以下载附加数据，诸如，服务相关的表。在一些实例中，这些表可以依次指导接收器从互联网检索附加数据和/或应用。因此，恶意生成的水印可以使接收器装置能够下载恶意应用(例如，病毒、间谍软件等)。本文描述的技术可以用于提高关于接收器装置通过水印访问的URI的安全。
应该注意的是，尽管在本文的示例中相对于根据ATSC候选标准生成的水印描述了本文描述的技术，但是本文描述的技术通常适用于包括与资源标识符相关联的信息的水印。如下面进一步详细描述的，本文描述的技术可以用于为内容提供商提供形成消息的灵活性，该消息可以用于访问补充内容并且可以进一步在再分配场景中通过使用水印信道来安全携带临界消息。
图1是图示了可以实施在本公开中描述的一个或多个技术的系统的示例的框图。系统100可以被配置成根据本文描述的技术传送数据。在图1所图示的示例中，系统100包括一个或多个机顶盒102A至102N、电视服务网络104、电视服务提供商站点106、广域网112、一个或多个内容提供商站点114A至114N、一个或多个数据提供商站点116A至116N、和注册授权机构站点117。进一步地，如图1所图示的，相应的接收器装置103(仅示出了一个)可以与一个或多个机顶盒中的一个机顶盒通信。系统100可以包括软件模块。软件模块可以存储在存储器中并且由处理器执行。系统100可以包括一个或多个处理器以及多个内部和/或外部存储器装置。存储器装置的示例包括文件服务器、文件传输协议(FTP)服务器、网络附加存储(NAS)装置、本地磁盘驱动器、或者能够存储数据的任何其它类型的装置或存储介质。存储介质可以包括蓝光光盘、DVD、CD-ROM、磁盘、闪存、或者任何其它合适的数字存储介质。当本文描述的技术部分地实施在软件中时，装置可以将软件的指令存储在合适的非暂时性计算机可读介质中并且通过使用一个或多个处理器来执行硬件中的指令。
系统100代表了可以被配置成能够分配并且通过一个或多个计算装置诸如接收器装置103渲染数字媒体内容诸如例如电视节目、电影、现场运动赛事等以及与其相关联的数据和应用和多媒体表示(例如，字幕服务)的系统的示例。在图1所图示的示例中，机顶盒102A至102N可以包括被配置成接收来自电视服务提供商站点106的数据的任何装置。例如，机顶盒102A至102N可以配备用于有线和/或无线通信，并且可以包括电视包括所谓的智能电视、机顶盒、和数字视频录像机。进一步地，机顶盒102A至102N可以包括被配置成接收来自电视服务提供商站点106的数据的桌面型计算机、膝上型计算机、或平板计算机、游戏控制台、移动装置包括例如智能电话、蜂窝电话和个人游戏装置。接收器装置103可以包括被配置成接收来自机顶盒的多媒体信号的任何装置，并且可以是不同于机顶盒的装置或者可以作为机顶盒的一部分集成。应该注意的是，尽管将系统100图示为具有不同站点，但是这种图示是出于描述的目的，并且不将系统100限制到特定的物理架构。可以通过使用硬件、固件和/或软件实施方式的任何组合来实现系统100和其中包括的站点的功能。
电视服务网络104是被配置成能够分配和/或再分配数字媒体内容可以包括电视服务的网络的示例。例如，电视服务网络104可以包括由MVPD维护的网络，并且可以包括例如公共或基于订阅的空中电视网络、公共或基于订阅的卫星电视服务提供商网络、和公共或基于订阅的有线电视提供商网络和/或OTT或互联网服务提供商网络。应该注意的是，尽管在一些示例中，电视服务网络104主要可以用于提供电视服务，但是电视服务网络104还可以根据本文描述的电信协议的任何组合来提供其它类型的数据和服务。进一步地，应该注意的是，在一些示例中，电视服务网络104可以实现电视服务提供商站点106与一个或多个机顶盒102A至102N之间的双向通信。电视服务网络104可以包括无线和/或有线通信介质的任何组合。电视服务网络104可以包括同轴电缆、光缆、双绞线、无线发射器和接收器、路由器、交换机、中继器、基站、或者可以用于促进各种装置和站点之间的通信的任何其它设备。电视服务网络104可以根据一个或多个电信协议的组合来操作。电信协议可以包括专有方面和/或可以包括标准化电信协议。标准化电信协议的示例包括DVB标准、ATSC标准、ISDB标准、DTMB标准、DMB标准、有线电缆数据服务接口规范(DOCSIS)标准、HbbTV标准、电缆电信工程师协会(SCTE)标准、W3C标准、和UPnP标准。
再次参照图1，电视服务提供商站点106可以被配置成经由电视服务网络104分配电视服务。例如，电视服务提供商站点106可以包括一个或多个广播站、有线电视提供商、卫星电视提供商、或者基于互联网的电视提供商。即，电视服务提供商站点106可以是由MVPD维护的站点。在图1所图示的示例中，电视服务提供商站点106可以被配置成再分配电视内容，例如，电视服务提供商站点106可以包括由MVPD维护的站点，并且可以接收来自一个或多个内容提供商站点114A至114N的一个或多个内容馈送。内容提供商站点114A至114N代表了可以生成多媒体内容的站点的示例。例如，内容提供商站点可以包括具有被配置成将多媒体文件和/或流提供给电视服务提供商站点106的一个或多个工作室内容服务器的工作室。在一个示例中，内容提供商站点可以包括电视台(例如，国家广播公司站点、本地附属机构等)，并且可以被配置成通过物理传输机制将电视节目提供给电视服务提供商站点106。物理传输机制可以包括卫星上行和/或下行机制、广播传输及其组合。在一个示例中，电视服务提供商站点106可以包括有线电视服务站点，并且电视服务提供商站点106可以通过电视服务网络104将电视广播从本地电视台再分配至机顶盒102A至102N。进一步地，如图1所图示的，电视服务提供商站点106可以与广域网112通信，并且可以被配置成接收来自内容提供商站点114A至114N的数据并进一步通过广域网112接收来自数据提供商站点116A至116N的数据。应该注意的是，在一些示例中，电视服务提供商站点106可以包括电视演播室，并且可以由其产生内容。在一个示例中，内容提供商站点114A至114N可以被配置成通过使用IP套组来提供多媒体内容。例如，内容提供商站点可以被配置成根据实时协议(RTP)、实时串流协议(RTSP)、或超文本传输协议(HTTP)将多媒体内容提供给接收器装置和/或电视服务提供商站点106。
在图1所图示的示例中，电视服务提供商站点106包括服务分配引擎108和数据库110。服务分配引擎108可以被配置成接收数据，包括例如多媒体内容、交互式应用和消息，并且通过电视服务网络104将数据分配给机顶盒102A至102N。例如，服务分配引擎108可以被配置成根据上述的一个或多个传输标准(例如，ATSC标准)的方面接收电视服务。数据库110可以包括存储装置，该存储装置被配置成存储数据，包括例如多媒体内容以及与其相关联的数据，包括例如描述性数据和可执行的交互式应用。例如，运动赛事可以与提供统计更新的交互式应用相关联。可以根据定义的数据格式诸如例如超文本标记语言(HTML)、动态HTML、可扩展标记语言(XML)、和JSON来规定与多媒体内容相关联的数据的格式，并且与多媒体内容相关联的数据可以包括使机顶盒102A至102N和/或相应的接收器装置103能够访问，例如，来自数据提供商站点116A至116N之一的数据的URL和URI。在一些示例中，电视服务提供商站点106可以被配置成提供对存储的多媒体内容的访问并且通过电视服务网络104将多媒体内容分配给一个或多个机顶盒102A至102N。例如，可以在所谓的按需基础上经由电视服务网络104将存储在数据库110中的多媒体内容(例如，音乐、电影、和电视(TV)节目)提供给用户。
广域网112可以包括基于分组的网络，并且可以根据一个或多个电信协议的组合进行操作。标准化电信协议的示例包括全球移动通信系统(GSM)标准、码分多址(CDMA)标准、第三代合作伙伴计划(3GPP)标准、欧洲电信标准组织(ETSI)标准、欧洲(EN)标准、IP标准、无线应用协议(WAP)标准、以及电气和电子工程师协会(IEEE)标准诸如例如一个或多个IEEE 802标准(例如，Wi-Fi)。广域网112可以包括无线和/或有线通信介质的任何组合。广域网112可以包括同轴电缆、光缆、双绞线、以太网电缆、无线发射器和接收器、路由器、交换机、中继器、基站、或者可以用于促进各种装置和站点之间的通信的任何其它设备。在一个示例中，广域网112可以包括互联网。
数据提供商站点116A至116N可以被配置成通过广域网112将数据(包括基于超文本的内容)等提供给接收器装置103和/或电视服务提供商站点106。数据提供商站点116A至116N可以包括一个或多个web服务器。进一步地，数据提供商站点116A至116N可以包括可能与上述的数据库110类似的一个或多个数据库。可以根据数据格式诸如例如HTML、动态HTML、XML、和JSON来定义由数据提供商站点116A至116N提供的数据。数据提供商站点的示例包括美国专利及商标局网站。应该注意的是，在一些示例中，由数据提供商站点116A至116N提供的数据可以用于再分配场景。进一步地，在一些示例中，由数据提供商站点116A至116N提供的数据可以用于启用所谓的第二屏幕或配套装置应用。例如，与接收器装置通信的(多个)配套装置可以结合正在接收器装置上呈现的电视节目来显示网站。应该注意的是，由数据提供商站点116A至116N提供的数据可以包括音频和视频内容。例如，数据提供商站点116A至116N可以包括电视网网站(例如，NBC.com)、广告服务器等。通过这种方式，多个站点可以以可互换的方式来提供数据和内容。例如，电视网网站可以在主要呈现电视节目期间提供视频内容和数据，并且广告服务器可以在商业广告期间提供视频内容和数据(例如，弹出式窗口)。进一步地，在一个示例中，数据提供商站点116A至116N可以被配置成根据本文描述的一个或多个技术来生成数据或者包括应用和/或描述应用的数据元素的数据的文档。
注册授权机构站点117可以被配置成响应于查询提供与数据提供商站点116A至116N之一相对应的IP地址。例如，如下面详细描述的，接收器装置可以查询注册授权机构站点117以获得与广播公司标识符相对应的IP地址。进一步地，注册授权机构站点117可以被配置成将请求转发到数据提供商站点116A至116N之一。例如，如下面详细描述的，接收器装置可以通过使用包括广播公司标识符的URI来请求补充内容。可以将请求定向到注册授权机构站点117，并且注册授权机构站点117可以基于广播公司标识符的值来将请求转发给数据提供商站点116A至116N中的一个特定数据提供商站点。
如上所述，服务分配引擎108可以被配置成接收数据，包括例如多媒体内容、交互式应用和消息，并且通过电视服务网络104将数据分配给机顶盒102A至102N。例如，服务分配引擎108可以被配置成接收一个或多个数据流，并且输出专有信号以将内容分配给机顶盒102A至102N。数据流通常可以指封装在一个或多个数据分组的集合中的数据。
如上文进一步描述的，再分配场景的示例可以包括接收器装置接收来自机顶盒的多媒体信号并且根据该多媒体信号恢复嵌入的信息的情境。图2是图示了可以实施本公开的一个或多个技术的机顶盒和示例接收器装置的示例的框图。机顶盒200是可以被配置成接收来自通信网络的数据并且输出表示多媒体内容的信号的计算装置的示例。接收器装置300是可以被配置成接收表示多媒体内容的信号，并且根据接收到的信号渲染视觉和听觉数据，并且进一步根据本公开的一个或多个技术从接收到的信号提取水印的计算装置的示例。在图2所图示的示例中，出于说明目的，将机顶盒200和接收器装置300图示为分离的不同装置。应该注意的是，在其它示例中，机顶盒200和接收器装置300可以合并为单个装置。进一步地，在图2所图示的示例中，机顶盒200被配置成经由电视网诸如例如上述的电视服务网络104接收数据。应该注意的是，在其它示例中，机顶盒200可以被配置成另外或可替代地通过广域网接收数据。
如图2所图示的，机顶盒200包括(多个)中央处理单元202、系统存储器204、系统接口210、数据提取器212、音频解码器214、视频解码器216、多媒体接口218、(多个)I/O装置220、和水印插入器222。如图2进一步图示的，系统存储器204包括操作系统206和应用208。(多个)中央处理单元202、系统存储器204、系统接口210、数据提取器212、音频解码器214、视频解码器216、多媒体接口218、(多个)I/O装置220、和水印插入器222中的每一个都可以(物理地、通信地、和/或可操作地)互相连接以进行组件间通信，并且可以实施为各种合适的电路系统中的任何电路系统，诸如一个或多个微处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、离散逻辑、软件、硬件、固件或者它们的任何组合。应该注意的是，尽管将机顶盒200图示为具有不同功能块，但是这种图示是出于描述的目的，并且不将机顶盒200限制到特定的硬件架构。可以通过使用硬件、固件和/或软件实施方式的任何组合来实现机顶盒200的功能。
(多个)CPU 202可以被配置成实施功能和/或处理指令以在机顶盒200中执行。(多个)CPU 202可以包括单核和/或多核中央处理单元。(多个)CPU 202可以检索并处理指令、代码、和/或数据结构以实施本文描述的一个或多个技术。可以将指令存储在计算机可读介质上，诸如，系统存储器204。可以将系统存储器204描述为非暂时性或者有形计算机可读存储介质。在一些示例中，系统存储器204可以提供临时和/或长期存储。在一些示例中，可以将系统存储器204或其部分描述为非易失性存储器，并且在其它示例中，可以将系统存储器204的部分描述为易失性存储器。系统存储器204可以被配置成存储可以在操作期间由机顶盒200使用的信息。系统存储器204可以用于存储程序指令以供(多个)CPU 202执行，并且可以由在机顶盒200上运行的程序使用以在程序执行期间临时存储信息。进一步地，在将机顶盒200作为数字视频录像机的部分包括在内的示例中，系统存储器204可以被配置成存储许多视频文件。
应用208可以包括在机顶盒200内实施或由机顶盒200执行的应用，并且可以实施或包含在机顶盒200的组件内、由机顶盒200的组件操作或执行、和/或可操作地/通信地耦合至机顶盒200的组件。应用208可以包括可以使机顶盒200的(多个)CPU 202执行特定功能的指令。应用208可以包括用计算机编程语句诸如for循环、while循环、if语句、do循环等表示的算法。可以通过使用特定的编程语言来开发应用208。编程语言的示例包括JavaTM、JiniTM、C、C++、Objective C、Swift、Perl、Python、PhP、UNIX Shell、Visual Basic、和Visual Basic Script。如图2所图示的，应用208可以结合操作系统206执行。即，操作系统206可以被配置成促进应用208与机顶盒200的(多个)CPU 202和其它硬件组件的交互。操作系统206可以是设计为安装在机顶盒、数字视频录像机、电视等上的操作系统。应该注意的是，本文描述的技术可以由被配置成通过使用软件架构的任何和全部组合进行操作的装置使用。
系统接口210可以被配置成实现机顶盒200的组件之间的通信。在一个示例中，系统接口210包括能够将数据从一个对等装置传递到另一个对等装置或者传递到存储介质的结构。例如，系统接口210可以包括支持基于加速图形端口(AGP)的协议、基于外围组件互连(PCI)总线的协议诸如例如由外围组件互连专业组维护的PCI ExpressTM(PCIe)总线规范、或者可以用于使对等装置互相连接的任何其它形式的结构(例如，专有总线协议)的芯片集。如上所述，机顶盒200被配置成经由电视服务网络接收数据。如上所述，电视服务网络可以根据电信标准进行操作。电信标准可以定义通信属性(例如，协议层)诸如例如物理信令、寻址、信道访问控制、分组属性、和数据处理。在图2所图示的示例中，数据提取器212可以被配置成从信号提取视频、音频、和数据。可以根据专有方面和/或标准化方面来定义信号。数据提取器212可以被配置成从由上述的电视服务提供商站点106生成的信号提取视频、音频、和数据。
可以由(多个)CPU 202、音频解码器214、和视频解码器216来处理数据分组。音频解码器214可以被配置成接收并处理音频分组。例如，音频解码器214可以包括被配置成实施音频编解码器的各个方面的硬件和软件的组合。即，音频解码器214可以被配置成接收音频分组并输出音频数据信号。音频数据可以通过使用多声道格式来编码，诸如，由杜比系统和数字影院系统开发的那些格式。音频数据可以通过使用音频压缩格式来编码。音频压缩格式的示例包括运动图像专家组(MPEG)格式、高级音频编码(AAC)格式、DTS-HD格式、和杜比数字(AC-3)格式。视频解码器216可以被配置成接收并处理视频分组。例如，视频解码器216可以包括用于实施视频编解码器的各个方面的硬件和软件的组合。在一个示例中，视频解码器216可以被配置成对根据任何数量的视频压缩标准编码的视频数据进行解码，诸如，ITU-T H.262或ISO/IEC MPEG-2 Visual、ISO/IEC MPEG-4 Visual、ITU-T H.264(也称为ISO/IEC MPEG-4 AVC)、和高效视频编码(HEVC)。应该注意的是，来自内容提供商的在电视服务提供商站点106处接收的视频数据和音频数据可以根据一种格式进行解码并且根据另一种格式进行重新编码，包括MVPD的专有格式。
(多个)I/O装置220可以被配置成在机顶盒200的操作期间接收输入并提供输出。即，(多个)I/O装置220可以使用户能够选择要渲染的多媒体内容。可以从输入装置诸如例如按钮式遥控器、包括触敏屏幕的装置、基于运动的输入装置、基于音频的输入装置、或者被配置成接收用户输入的任何其它类型的装置生成输入。(多个)I/O装置220可以通过使用标准化通信协议诸如例如通用串行总线(USB)协议、蓝牙、ZigBee或者专有通信协议诸如例如专有的红外通信协议来可操作地耦合至机顶盒200。
如上所述，在一些示例中，MVPD可以将水印嵌入到视频信号中以增强源自内容提供商的内容。在图2所图示的示例中，机顶盒包括水印插入器222，该水印插入器222可以被配置成根据本公开的一个或多个技术来将水印嵌入到多媒体信号中。下面会更详细地描述水印插入器222如何可以将水印嵌入到多媒体信号中的示例。如上文进一步描述的，接收器装置可以接收来自多媒体接口的多媒体信号(例如，未压缩的视频信号)。多媒体接口218被配置成将多媒体信号输出到接收器装置300。多媒体接口218可以被配置成根据定义的多媒体信号格式来输出多媒体信号，包括例如HDMI格式、DisplayPort格式、和其它数字格式或模拟格式(例如，分量视频格式)。进一步地，应该注意的是，在一些示例中，多媒体接口218可以被配置成根据无线信号格式(例如，WirelessHD等)输出多媒体信号。应该注意的是，无论接收器装置如何接收多媒体数据，本文描述的技术通常都是适用的。
再次参照图2，接收器装置300包括显示系统302、音频输出系统304、水印处理器310、和网络接口312。显示系统302、音频输出系统304、水印处理器310、和网络接口312中的每一个都可以(物理地、通信地、和/或可操作地)互相连接以进行组件间通信，并且可以实施为各种合适的电路系统中的任何电路系统，诸如一个或多个微处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、离散逻辑、软件、硬件、固件或者它们的任何组合。应该注意的是，尽管将接收器装置300图示为具有不同功能块，但是这种图示是出于描述的目的，并且不将接收器装置限制到特定的硬件架构。可以通过使用硬件、固件和/或软件实施方式的任何组合来实现接收器装置的功能。进一步地，应该注意的是，接收器装置300可以包括具有与包括在机顶盒200中的功能块类似的功能的功能块。例如，接收器装置300可以包括(多个)中央处理单元、系统存储器、系统接口、数据提取器、音频解码器、视频解码器、多媒体接口、和/或(多个)I/O装置中的一个或多个。例如，在接收器装置300包括数字电视的情况下，接收器装置300可以被配置成除了接收来自机顶盒200的多媒体信号之外，接收来自通信网络(例如，空中广播)的数据并且提取表示多媒体内容的信号。在这种情况下，接收器装置300可以被配置成按照与上文针对机顶盒200描述的方式类似的方式来接收来自通信网络的数据并且提取表示多媒体内容的信号。为了简洁起见，不再针对接收器装置300重复对被配置成接收来自通信网络的数据并且提取表示多媒体内容的信号的这种功能块的描述。
显示系统302可以被配置成检索并处理视频数据以进行渲染。例如，显示系统302可以接收来自视频信号的像素数据并且输出数据以进行视觉呈现。进一步地，显示系统302可以被配置成结合视频数据例如图形用户界面来输出图形。显示系统302可以包括各种显示装置中的一种显示装置，诸如，液晶显示器(LCD)、等离子显示器、有机发光二极管(OLED)显示器、或者能够将视频数据呈现给用户的其它类型的显示装置。显示装置可以被配置成显示标清内容、高清内容、或者超高清内容。进一步地，在一些示例中，显示装置可以被配置成根据过扫描模式来进行操作。音频输出系统304可以被配置成渲染音频数据。例如，音频输出系统304可以包括音频处理器、数模转换器、放大器、和扬声器系统。扬声器系统可以包括各种扬声器系统中的任何扬声器系统，诸如，耳机、集成立体声扬声器系统、多扬声器系统、环绕声系统。
水印处理器310可以被配置成根据本文描述的一个或多个技术来从多媒体数据信号提取水印。下面会更详细地描述水印处理器如何可以提取嵌入到多媒体信号中的水印的示例。网络接口312可以被配置成使接收器装置300能够经由局域网和/或广域网发送和接收数据。网络接口312可以包括网络接口卡(诸如，以太网卡)、光收发机、射频收发机、或者被配置成发送和接收信息的任何其它类型的装置。网络接口312可以被配置成根据网络中使用的物理层和媒体访问控制(MAC)层执行物理信令、寻址、和信道访问控制。如上所述，包括嵌入到水印中的URI的URI可以使接收器装置能够连接至(多个)服务器以下载附加数据。网络接口312可以被配置成接收URI(包括从水印处理器310接收的那些URI)并且连接至在URI中识别的(多个)服务器。
如上所述，包括在内容提供商站点(例如，内容提供商站点114N)、电视服务提供商站点(例如，电视服务提供商站点106)、或者机顶盒(例如，机顶盒200)处包括的水印插入器的水印插入器可以被配置成将水印嵌入到多媒体信号中。进一步地，水印插入器可以被配置成生成包括与资源标识符相关联的信息、包括具有根据上述的scheme://authority/path格式设置的组件部分的URI的水印。
在一个示例中，如下面会更详细地描述的，权限组件可以包括受信任的域名服务器(DNS)根域。在一个示例中，权限组件可以包括广播公司标识符。在一个示例中，广播公司标识符可以包括由注册授权机构发布的唯一标识符。在一个示例中，注册授权机构可以包括开发传输标准(例如，ATSC等)的组织或者另一个管理团体(例如，联邦通信委员会(FCC)等)。注册授权机构可以维护已发布的广播公司标识符列表。下面会更详细地描述广播公司标识符的示例。进一步地，在一些示例中，接收器装置可以被配置成通过将广播公司标识符与特定根域例如与注册授权机构相关联的受信任的根域组合来生成资源标识符。因此，在一些示例中，水印插入器可以被配置成基于以下资源标识符格式来生成包括资源标识符的水印：
scheme://{registration authority root}/{broadcaster identifier}/path
或者
scheme://{broadcaster identifier}.{registration authority root}/path
在一些示例中，{registration authority root}包括受信任的DNS，并且在一些示例中，不应该从水印数据可推导{registration authority root}。在一个示例中，{registration authority root}可以存储在接收器装置上。在一些示例中，可以更新或修改{registration authority root}的值。在一个示例中，仅注册授权机构可以更新{registration authority root}。通过这种方式，可以维护{registration authorityroot}的安全。
进一步地，在一些示例中，水印插入器可以被配置成使得信令权限组件的部分作为水印消息的报头的部分，并且信令路径组件(例如，资源指定的字符串)的部分或者全部作为水印消息的实例的部分。进一步地，在一些示例中，可以在水印消息的报头中信令路径组件的部分或者全部。因此，在一些示例中，水印插入器可以被配置成基于以下资源标识符格式来生成包括资源标识符的水印：
scheme：//{broadcaster identifier}.{registration authority root}/uri_string_i()
或者
scheme：//{broadcaster identifier}.{registration authority root}/uri_string_h()/uri_string_i()
其中，在水印消息报头中信令{broadcaster identifier}，并且在水印消息报头中信令uri_string_h()，并且在水印消息的实例中信令uri_string_i()。
如下面进一步详细描述的，接收器装置可以将{broadcaster identifier}提供给与{registration authority root}相对应的服务器，并且与{registration authorityroot}相对应的服务器可以提供与{broadcaster identifier}相关联的IP地址和/或将请求转发到与{broadcaster identifier}相关联的IP地址相关联的服务器。通过这种方式，接收器装置可以通过受信任的服务器接收到补充内容。
如上所述，相对于表6和表8，在A/336中，uri_message()和emergency_alert_message()可以包括资源识别信息。在一些示例中，水印插入器可以被配置成使得根据以下格式信令包括在uri_message()或者emergency_alert_message()中的资源识别信息：
https://{BSID_code}.atsc3.tv/a336/{wm_message_id_code}/{uri_type_code}/uri_string()
或者
http://{BSID_code}.atsc3.tv/a336/{wm_message_id_code}/{uri_type_code}/uri_string()
其中
在一个示例中，{BSID_code}是在wm_message_block()报头中发送的16位broadcaster_id的4字符的十六进制表示，并且16位broadcaster_id是由ATSC注册授权机构发布的唯一标识符。
在一个示例中，atsc3.tv是与ATSC注册授权机构相关联的受信任的DNS的主机名。
在一个示例中，{wm_message_id_code}是在wm_message_block()报头中发送的8位wm_message_id的2字符的十六进制表示。在一个示例中，针对URI消息，{wm_message_id_code}的值可以等于“03”。在一个示例中，针对应急警报消息，{wm_message_id_code}的值可以等于“06”。
在一个示例中，{uri_type_code}是8位uri_type的2字符的十六进制表示；并且在一些示例中，针对不具有定义的uri_type的应急警报消息，使用CAP_message_ID作为替代。如上所述，在一些示例中，CAP_message_ID可以具有多字节长度，因此，在一些情况下，产生的{CAP_message_id_code}可以具有多个2字符的十六进制代码。
在一个示例中，uri_string()是在各种水印消息中定义的字符串。
表13根据本文描述的一个或多个技术提供了包括在水印有效载荷中的uri_message()的报头的示例语法。在表13所图示的示例中，在一些示例中，相应语法元素wm_message_id、wm_message_block_length、wm_message_version、fragment_number、last_fragment、wm_message_bytes()、message_CRC_32、和message_CRC_32可以具有基于上文相对于表1提供的定义的定义。
表13
参照表13，broadcaster_id语法元素可以基于以下定义：
broadcaster_id：这个16位无符号整数字段应唯一地识别广播公司。该ID预计会由ATSC 3.0注册授权机构发布。
应该注意的是，尽管在表13所图示的示例中，broadcaster_id被图示为包括在第一个片段中，但是在其它示例中，broadcaster_id可以存在于附加片段中。在其它示例中，broadcaster_id也可以存在于诸如wm_message_bytes()等消息主体内。
表14根据本文描述的一个或多个技术提供了uri_message()的实例的示例语法。在表14中，在一些示例中，语法元素uri_type和uri_strlen可以具有基于上文相对于表6提供的定义的定义。
表14
参照表14，在一些示例中，语法元素URI_string()可以基于以下示例定义：
URI_string()——由字符组成的URI，该字符的值应被限制到由RFC 3986针对统一资源标识符(URI)允许的那些值。应由uri_len的值来给定字符串的长度。如果分段发送URI，则根据RFC 3986，重组之后的字符串应仅包含路径、查询、和片段的URI语法组件。URI_string()应用于构造如下的HTTPS请求：
https://{BSID_code}.atsc3.tv/a336/{wm_message_id_code}/{uri_type_code}/URI_string()
或者
http://{BSID_code}.atsc3.tv/a336/{wm_message_id_code}/{uri_type_code}/URI_string()
通过这种方式，可以由接收器装置根据URI_string()得到的资源标识符的可能值可以被限制到可以由接收器装置确认有效的特定权限，并因此，可以防止接收器装置从未知源下载恶意数据。
参照表3至4，A/336r7描述了视频水印有效载荷可以包括uri_message()。表15A至15C根据本文描述的一个或多个技术提供了uri_message()的实例的示例语法。
表15A
表15B
表15C
在表15A至15C中的每个表中，语法元素uri_type可以基于上文相对于表6提供的定义。在表15A至15B中的每个表中，语法元素ans_id可以基于以下定义：
ans_id——这个8位字段应指示授权的ATSC 3.0名称服务器(ANS)的标识符代码。
因此，ans_id可以是下面相对于表16描述的{code_type}的示例。参照表15A，在一些示例中，语法元素bsid和URI_string()可以基于以下示例定义：
bsid——这个16位标识符应指示与服务相关联的广播流的BSID。它的唯一性落在由ans_id字段指示的名称服务器的范围内。
URI_string()——由字符组成的URI，该字符的值应被限制到由RFC 3986针对统一资源标识符(URI)允许的那些值。应由uri_strlen的值来给定字符串的长度。如果分段发送URI，则根据RFC 3986，重组之后的字符串应是有效URL，并且根据RFC 3986，应仅包含路径、查询、和片段的URI语法组件。URI_string()应用于构造如下的HTTPS请求：
https://{bsidCode}.{ansidCode}.vp1.tv/uri_string()
其中
{bsidCode}是16位bsid的4字符的十六进制表示。
{ansidCode}是8位ans_id的2字符的十六进制表示。
参照表15B，在一些示例中，语法元素ans_strien_minus1、ans_string、uri_strlen、和URI_string()可以基于以下示例定义：
ans_strlen_minus1——这个8位无符号整数加上1应指示ans_string()的长度。
ans_string——这个UTF-8编码的字符串是服务的唯一标识符，并且它的唯一性落在由ans_id字段指示的名称服务器的范围内。
uri_strlen——8位无符号整数，应信令跟随的uri_string()中的字符数量。ans_strlen_minus1+1和uri_strlen字段的组合值针对1X视频水印发射格式(1X系统)应小于或等于84，并且针对2X视频水印发射格式(2X系统)应小于或等于204[如A/335所提供的]。
URI_string()——由字符组成的URI，该字符的值应被限制到由RFC 3986针对统一资源标识符(URI)允许的那些值。应由uri_strlen的值来给定字符串的长度。如果分段发送URI，则根据RFC 3986，重组之后的字符串应是有效URL，并且根据RFC 3986，应仅包含路径、查询、和片段的URI语法组件。URI_string()应用于构造如下的HTTPS请求——
https://{ans_string}.{ansidCode}.vp1.tv/uri_string()
其中
{ansidCode}是8位ans_id的2字符的十六进制表示。
参照表15C，语法元素ans_string可以基于上文针对表15B提供的定义，并且在一些示例中，语法元素ans_id、ans_strlen_minus1、uri_strlen和URI_string()可以基于以下示例定义：
ans_id——这个4位字段应指示授权的ATSC 3.0名称服务器(ANS)的标识符代码。
ans_strleng_minus1——这个4位无符号整数加上1应指示ans_string()的长度。
uri_strlen——8位无符号整数，应信令跟随的uri_string()中的字符数量。ans_strlen_minus1+1和uri_strlen字段的组合值应针对1X视频水印发射格式(1X系统)小于或等于85，并且针对2X视频水印发射格式(2X系统)小于或等于205[如A/335所提供的]。
URI_string()——由字符组成的URI，该字符的值应被限制到由RFC 3986[8]针对统一资源标识符(URI)允许的那些值。应由uri_strlen的值来给定字符串的长度。如果分段发送URI，则根据RFC 3986[8]，重组之后的字符串应是有效URL，并且根据RFC 3986[8]，应仅包含路径、查询、和片段的URI语法组件。URI_string()应用于构造如下的HTTPS请求：
https://{ans_string}.{ansidCode}.vp1.tv/uri_string()
其中
{ansidCode}是4位ans_id的1字符的十六进制表示。
通过这种方式，uri_message()可以指示授权的ANS的标识符代码，该标识符代码用于构造HTTP(S)请求。通过这种方式，表15A至15C所图示的示例提供了水印插入器可以被配置成基于以下资源标识符格式来生成包括资源标识符的水印的示例：
scheme://{service_identifier}.{code_type}.{registration authorityroot}/path
表16根据本文描述的一个或多个技术提供了uri_message()的实例的示例语法。
表16
在表16中，语法元素uri_type可以基于上文针对表6提供的定义，并且在一些示例中，语法元素domain_code、entity_strlen、entity_string()、uri_strlen和URI_string()可以基于以下示例定义：
domain_code：根据一个示例中的表17A或者一个示例中的表17B，这个8位无符号整数应指示应识别要用于URL构造的域的标识符代码。
表17A
表17B
在一个示例中，表17A和表17B中的保留值可以与另一种类型的域字符串相关联。例如，具有格式“x.atsc.org”的域字符串，其中x是整数，或者包括字母数字字符的字符串。
尽管上文的描述使用了8位domain_code语法元素，但是在另一替代示例中，针对domain_code语法元素可以使用不同的位数。例如，针对domain_code可以使用4位、12位或者16位。在一个示例中，如果domain_code使用4位，那么可以修改uri_type字段以使用4位，使得uri_type和domain_code字段共同占用1个字节。在另一示例中，如果domain_code使用12位，那么可以在domain_code字段之后发送4位保留字段以促进字段的字节对齐。
entity_strlen——8位无符号整数，应信令跟随的entity_string()中的字符数量。
在一个示例中，可以信令字段entity_strlen作为字段entity_strlen_minus1。
在这种情况下，语义可以如下：
entity_strlen_minus1——8位无符号整数，加上1应信令跟随的entity_string()中的字符数量。
在其它示例中，减2、减3、或者减4编码可以用于指示entity_string()的长度。
在这些相应情况中的每种情况下，信令以指示entity_string()的长度的语法元素可以是以下之一：
entity_strlen_minus2——8位无符号整数，加上2应信令跟随的entity_string()中的字符数量。
entity_strlen_minus3——8位无符号整数，加上3应信令跟随的entity_string()中的字符数量。
entity_strlen_minus4——8位无符号整数，加上4应信令跟随的entity_string()中的字符数量。
应该注意的是，在一些情况下，减4信令可以优选为最短顶级域，该最短顶级域可以是2字符，并且一个句点(‘.’)需要一个字符，并且最短二级域可以是至少1字符。
entity_string()——这个字符串是至少由顶级域和二级域组成的IANA注册的域名。可以存在更高级的域。将句点字符(“.”)包括在顶级域、二级域、和任何更高级的域之间。由entity_strlen的值来给定entity_string()的长度。
uri_strlen——8位无符号整数，应信令跟随的uri_string()中的字符数量。entity_strlen和uri_strlen字段的组合值应针对1X视频水印发射格式(1X系统)小于或等于84，并且针对2X视频水印发射格式(2X系统)小于或等于204[如A/335所提供的]。
URI_string()——由字符组成的URI，该字符的值应被限制到由RFC 3986针对统一资源标识符(URI)允许的那些值。应由uri_strlen的值来给定字符串的长度。
接收器预计应形成URL，它将使用该URL来通过以下过程检索引用内容。通过将字符串domain_string在“URI_string”字符串之后的“/”之后附加到实体字符串，来形成URL。如果分段发送URL，则根据RFC3986，重组之后的URL应是有效URL，并且根据RFC 3986，应仅包含路径、查询、和片段的URI语法组件。URI_string()应用于构造如下的HTTPS请求：
https://entity_string.domain_string/URI_string()
表18根据本文描述的一个或多个技术提供了emergency_alert_message()的实例的示例语法。在表18中，在一些示例中，语法元素CAP_message_ID_length、CAP_message_ID、CAP_message_url_length、expires、urgency、severity_certainty可以具有基于上文相对于表8提供的定义的定义。
表18
参照表18，在一些示例中，语法元素CAP_message_url可以基于以下定义：
CAP_message_url——这个字符串应给出可以用于检索CAP消息的URL。根据RFC3986，CAP_message_url应仅包含路径、查询、和片段的URI语法组件。CAP_message_url应用于构造如下的HTTPS请求：
https://{BSID_code}.atsc3.tv/a336/{wm_message_id_code}/{CAP_message_id_code}/CAP_message_url
或者
http://{BSID_code}.atsc3.tv/a336/{wm_message_id_code}/{CAP_m essage_id_code}/CAP_message_url
通过这种方式，可以由接收器装置从CAP_message_url得到的资源标识符的可能值可以被限制到可以由接收器装置确认有效的特定权限，并因此，可以防止接收器装置从未知源下载恶意数据。
如上所述，水印插入器可以被配置成基于以下资源标识符格式中的一个或多个来生成包括资源标识符的水印：
scheme://{registration authority root}/{broadcaster identifier}/path
scheme://{broadcaster identifier}.{registration authority root}/path
scheme://{broadcaster identifier}.{registration authority root}/uri_string_i()
scheme://{broadcaster identifier}.{registration authority root}/uri_string_h()/uri_string_i()
在一些示例中，它可以用于将与注册授权机构的国家和/或广播公司的国家相关联的信息包括在资源标识符中。即，在一些示例中，它可以用于将国家信息包括在{broadcaster identifier}和/或{registration authority root}中。在一个示例中，国家信息可以包括国家代码。应该注意的是，在一些示例中，它可以用于将其它类型的代码包括在{broadcaster identifier}和/或{registration authority root}中。其它类型的代码的示例包括URL构造代码、域代码、非关联化代码、本地服务器代码等。如上所述，{broadcaster identifier}可以包括{BSID_code}，并且{registration authority root}可以是atsc3.tv，即，与ATSC注册授权机构相关联的受信任的DNS的主机名。因此，在将与注册授权机构的国家和/或广播公司的国家相关联的信息包括在资源标识符中的示例中，水印插入器可以被配置成使得根据以下格式来信令包括在uri_message()或者emergency_alert_message()中的资源识别信息：
https://{BSID_code}.{country_code}.atsc3.tv/path
或者
http://{BSID_code}.{country_code}.atsc3.tv/path
在将其它类型的代码包括在资源标识符中的示例中，水印插入器可以被配置成使得根据以下格式来信令包括在uri_message()或者emergency_alert_message()中的资源识别信息：
https://{BSID_code}.{code_type}.atsc3.tv/path
或者
http://{BSID_code}.{code_type}.atsc3.tv/path
国家代码可以基于唯一地识别特定国家的一组定义的值，例如，标准化国家代码集。标准化国家代码集的示例包括在ISO 3166国家代码集标准中定义的国家代码集。通过引用并入本文的ISO 3166-2:2013国家名称表示及其细分的代码的第二部分：国家细分代码提供了示例国家代码。{country_code}可以基于包括在ISO 3166-2:2013中的国家代码。
参照表14和表18，在一些示例中，当将广播公司和/或注册授权机构的国家信息包括在URI中时，相应语法元素URI_string()和CAP_message_url可以基于以下示例定义：
URI_string()——由字符组成的URI，该字符的值应被限制到由RFC 3986针对统一资源标识符(URI)允许的那些值。应由uri_len的值来给定字符串的长度。如果分段发送URI，则根据RFC 3986，重组之后的字符串应仅包含路径、查询、和片段的URI语法组件。URI_string()应用于构造如下的HTTPS请求：
https://{BSID_code}.{country_code}.atsc3.tv/a336/{wm_message_id_code}/{uri_type_code}/URI_string()
或者
http://{BSID_code}.{country_code}.atsc3.tv/a336/{wm_message_id_code}/{uri_type_code}/URI_string()
CAP_message_url——这个字符串应给出可以用于检索CAP消息的URL。根据RFC3986，CAP_message_url应仅包含路径、查询、和片段的URI语法组件。CAP_message_url应用于构造如下的HTTPS请求：
https://{BSID_code}.{country_code}.atsc3.tv/a336/{wm_message_id_code}.{CAP_message_id_code}/CAP_message_url
或者
http://{BSID_code}.{country_code}.atsc3.tv/a336/{wm_message_id_code}.{CAP_message_id_code}/CAP_message_url
其中，{BSID_code}和{country_code}可以基于以下示例定义：
在一个示例中，{BSID_code}是由广播公司进行操作的国家和/或区域中的适当的ATSC注册授权机构发布的唯一的广播公司标识符的4字符的十六进制表示。
在一个示例中，{country_code}是适当的ATSC注册授权机构进行操作的国家和/或区域的2字符的表示。在一个示例中，这个2字符的国家代码是根据ISO 3166-2的国际名称。
相对于{BSID_code}和{country_code}的示例定义，在一个示例中，可以根据上文相对于表13描述的语法元素broadcaster_id来确定{BSID_code}和{country_code}。在该示例中，语法元素broadcaster_id可以基于以下示例定义：
broadcaster_id——这个16位无符号整数字段应唯一地识别广播公司和适当的注册授权机构进行操作的国家。这个ID预计由使用ATSC 3.0的国家中的ATSC 3.0注册授权机构发布。
在一个示例中，16位broadcaster_id可以包括两个部分：第一部分，包括国家代码；以及第二部分，包括由进行操作的国家中的适当的ATSC注册授权机构发布的唯一的广播公司标识符。在一个示例中，broadcaster_id的第一部分可以基于ISO 3166-2包括与2字符国家代码相对应的可变长度码字。在一个示例中，broadcaster_id的第一部分可以基于ISO 3166-2包括与2字符国家代码相对应的固定长度码字。
应该注意的是，在上述的示例URI中，字符串“a336”通常可以表示{usage}组件的示例，其中，可以如下定义{usage}：
{usage}是指示特定http或https请求结构遵守的特定ATSC标准的字符串。
进一步地，应该注意的是，在一些示例中，上述的URI中的组件的顺序可以互换，例如，可以在{BSID_code}之前将{usage}包括在URI中等。
如上所述，在A/336中，vp1_payload()可以包括在音频水印或者视频水印中。表19根据本文描述的一个或多个技术提供了vp1_payload()的实例的示例语法。如表19所图示的，在表20中提供了small_domain()的语法，并且在表21中提供了large_domain()的语法。在表19至21中，语法元素large_domain()、interval_field、和query_flag可以基于上文相对于表9至11提供的定义，并且ans_id可以基于上文相对于表15C提供的示例定义。应该注意的是，通过这种方式，在一些示例中，{code_type}可能是各种类型的水印消息所共有的。这种通用性可以简化接收器装置处对资源标识符的解析。
表19
表20
表21
在表19至21所图示的示例中，server_field可以基于下面提供的示例定义，并且作为域类型的函数的服务器代码和间隔码的示例范围
可以基于表22。
server_field——这个字段包含服务器代码(Server Code)。根据由ans_id识别的授权ATSC 3.0名称服务器发布的任务来设置服务器代码值。
域类型 服务器代码范围(十六进制) 间隔码范围(十六进制)
小域 00000000-07FFFFFF 00000000-0001FFFF
大域 00000000-0007FFFF 00000000-01FFFFFF
表22
如上所述，根据A/336，应通过使用以下URL模板来根据VP1有效载荷构造与恢复文件相对应的URL：
http[s]://{hostName}/a336/rdt/{subdName}/{serverCode}-{intervalCode}.rdt
在表19至22所图示的示例中，可以按照上文所描述的那样得到intervalCode，并且在一个示例中，可以得到元素hostName、subdName、
和serverCode，如下：
如果VP1有效载荷的domain_type是’0’，那么：
hostName元素应具有值：
a336.{serverCode1}.{serverCode2}.{serverCode3}.{serverCode4}.0.{ansidCode}vp1.tv；
subName元素应具有值：
{serverCode4}{serverCode3}/{serverCode2}/{serverCode1}；以及
serverCode元素应具有值：
{serverCode4}{serverCode3}{serverCode2}{serverCode1}；
其中ansidCode应表示表达为单个字符的大写字母的十六进制值的4位ans_id，并且serverCode1、和serverCode2、serverCode3、和serverCode4可以分别表示表达为两个字符的仅大写字母的十六进制值的VP1有效载荷(在最高有效位处对下一字节边界进行零填充)的server_field的最低有效字节至最高有效字节。
以及如果VPI水印代码的domain_type是’1’，那么：
hostName元素应具有值：
a336.{serverCode1}.{serverCode2}.{serverCode3}.1.vp1.tv；
subName元素可以具有值：
{serverCode3}{serverCode2}/{serverCode1}；以及
serverCode元素可以具有值：
{serverCode3}{serverCode2}{serverCode1}
其中ansidCode可以表示表达为单个字符的大写字母的十六进制值的4位ans_id，并且serverCode1、serverCode2、和serverCode3可以分别表示表达为两个字符的仅大写字母的十六进制值的VP1有效载荷(在最高有效位处对下一字节边界进行零填充)的server_field的最低有效字节至最高有效字节。
因此，根据本文描述的技术，针对6的ansidCode，针对小域，可以将与具有服务器代码值07ABCDEF和间隔码0001ABCD的恢复文件相对应的URL构造为如下：
http[s]://a336.EF.CD.AB.07.0.6.vp1.tv/a336/rdt/07AB/CD/EF/07ABCDEF-01ABCD.rdt
并且针对大域，可以将与具有服务器代码值07ABCD和间隔码01ABCDEF的恢复文件相对应的URL构造为如下：
http[s]://a336.CD.AB.07.1.6.vp1.tv/a336/rdt/07AB/CD/07ABCD-01ABCDEF.rdt
通过这种方式，可以针对小域和大域两者信令共有元素名称服务器例如ansidCode，并且针对小域和大域两者，在server_code上减少4位。
参照表4，A/366r7提供了语法元素wm_message_id可以识别用户私有消息的情形。用户私有消息可以支持按照管理方式来传送不透明用户数据。表23提供了已经针对用户私有消息user_private_message()提出的语法的示例。
表23
在表23中，语法元素domain_length、domain、payload_length和payload可以基于以下示例定义：
domain_length——这个8位无符号整数字段应指示以字节为单位的domain字段的长度。
domain——这个可变长度字段应符合在IETF RFC 4151的章节2.1[2005年10月的IETF:“The'tag'URI Scheme”,RFC 4151]中所定义的taggingEntity令牌，例如，“atsc.org,2016”。taggingEntity令牌中的authorityName的注册者定义了payload字段的内容。
payload_length——这个8位无符号整数字段应指示以字节为单位的payload字段的长度。
payload——这个可变长度字段包含未在本说明书中定义的数据。
应该注意的是，允许将示例用户私有消息包括在content_id_message内或者作为具有wm_message_id值的单独的水印消息发送，其中，允许将其分为最多4个片段发送。例如，参照表4，当wm_message_id的值在0x80至0xBF的范围内时，允许它具有最多4个片段。进一步地，允许将用户私有消息作为具有wm_message_id值的单独的水印消息发送，其中，允许将其分为最多256个片段发送。例如，参照表4，当wm_message_id的值在0xC0至0xFF的范围内时。应该注意的是，在其它示例中，wm_message_id的其它值可以分别指示用户私有消息的4个片段中的最大尺寸和256个片段中的最大尺寸。
在表23所图示的示例user_private_message()中，payload_length是8位，因此其范围可以是从0到255。因此，表23中的payload_length不能信令比255字节更大的用户私有有效载荷，并因此，不能容纳具有最大尺寸多达256个片段的用户私有消息。在一个示例中，根据本文描述的技术，payload_length可以基于以下定义：
payload_length——这个16位无符号整数字段应指示以字节为单位的payload字段的长度。
表24根据本公开的一个或多个技术提供了用户私有消息user_private_message()的语法的示例。
表24
在表24中，语法元素domain_length、domain、和payload可以基于相对于表23提供的定义。语法元素payload_length可以基于以下示例定义。
payload_length——这个字段应指示以字节为单位的payload字段的长度。
当user_private_message作为ID_Value字段包括在content_id_message()(wm_message_id等于0x01)中或者在具有指示最大尺寸多达4个片段的用户私有消息的wm_message_id的wm_message_block()内信令user_private_message时，这个字段是8位无符号整数。
当在具有指示最大尺寸多达256个片段的用户私有消息的wm_message_id的wm_message_block()内信令user_private_message时，这个字段是14位无符号整数。
通过这种方式，表24所图示的示例允许在使用0xC0-0xFF的(例如，0xFF)wm_message_id的情况下的payload_length更大。应该注意的是，payload_length的14位长度是基于由2X视频水印系统和最大片段数量支持的最大容量。应该注意的是，在一些示例中，表24所图示的示例中的payload_length在具有指示最大尺寸多达256个片段的用户私有消息的wm_message_id的wm_message_block()内信令user_private_message的情况下可以是16位。
在一个示例中，可以信令不同的用户私有消息。例如，可以针对指示具有最大尺寸多达4个片段的用户私有消息的wm_message_id信令user_private_message_short，并且可以针对指示具有最大尺寸多达256个片段的用户私有消息的wm_message_id信令user_private_message_long。在该示例中，user_private_message_short可以包括具有8位的payload_length，并且user_private_message_long可以包括具有14位(或者在一些示例中是16位)的payload_length。
进一步地，要注意的是，在上文任何示例用户私有消息中，可以用减一编码来对domain_length和payload_length进行编码。即，例如，可以分别用以下语法元素来替换domain_length和payload_length：
domain_length_minus1——这个8位无符号整数字段加上1应指示以字节为单位的domain字段的长度。
payload_length_minus1——这个字段应指示以字节为单位的payload字段的长度。
当user_private_message作为ID_Value字段被包括在content_id_message()(wm_message_id等于0x01)中或者在具有指示具有最大尺寸多达4个片段的用户私有消息的wm_message_id的wm_message_block()内信令user_private_message时，这个字段是8位无符号整数加上1。
当在具有指示具有最大尺寸多达256个片段的用户私有消息的wm_message_id的wm_message_block()内信令user_private_message时，这个字段是14位[或者在一些示例中是16位]的无符号整数加上1。
通过这种方式，本文描述的装置可以被配置成根据本文描述的示例用户私有消息来信令和/或解析水印消息的可变长度有效载荷中的信息。
图3A和图3B是图示了根据本公开的一个或多个技术信令资源标识符的示例的通信流程图。图3A图示了内容提供商站点114A在将内容馈送传输到电视服务提供商站点106以进行分配之前将水印嵌入到内容馈送中的示例。进一步地，图3A图示了注册授权机构站点117使用往返机制来提供与数据提供商站点116A相关联的IP地址的示例。
图3B图示了在内容提供商站点114A将内容馈送传输到电视服务提供商站点106以进行分配之后嵌入水印的示例。在图3B所图示的示例中，机顶盒200将水印嵌入到未压缩的多媒体信号中。进一步地，图3B图示了注册授权机构站点117使用转发机制来提供具有与接收器装置300相关联的地址的与数据提供商站点116A相关联的IP地址，使得数据提供商站点116A可以履行对接收器装置300的请求的示例。应该注意的是，往返机制可以为接收器装置的用户提供附加的隐私层，并且转发机制可以使接收器装置300能够在较短延迟的情况下接收并渲染补充内容。在一些示例中，接收器装置300可以被配置成使得用户能够设置是否使用往返机制或转发机制。
参照图3A，内容提供商站点114A将水印插入到多媒体信号中。在一些示例中，将水印插入到多媒体信号中可以包括基于水印发射格式(例如，上述的A/334和/或A/335等)将数字数据嵌入到多媒体信号中。内容提供商站点114A可以通过使用嵌入的数字数据来信令URI的部分。通过使用嵌入的数字数据来信令URI的部分可以包括根据定义的水印语法(例如，表1至20中提供的语法)来信令数据。在一个示例中，定义的水印语法可以包括标识符。例如，定义的水印语法可以包括如上所述的广播公司标识符。内容提供商站点114A将包括嵌入的水印的内容馈送传输到电视服务提供商站点106以进行分配。电视服务提供商站点106根据物理传输协议将内容馈送传输到机顶盒200。机顶盒200接收物理传输。机顶盒200从物理传输提取多媒体数据流。例如，机顶盒200可以执行如上所述的物理层、链路层和网络层处理。机顶盒200从提取到的多媒体数据流来解码多媒体信号。机顶盒200可以根据上述技术来从提取到的多媒体数据流解码多媒体信号(例如，机顶盒200可以根据HEVC兼容位流来解码视频信号)。
再次参照图3A，机顶盒200将包括嵌入的水印的未压缩的多媒体信号传输到接收器装置。接收器装置300接收包括嵌入的水印的未压缩的多媒体信号。接收器300提取嵌入的水印。在一些示例中，提取水印可以包括基于水印发射格式(例如，上述的A/334和/或A/335等)检索数字数据。接收器装置300从提取到的数字数据形成URI。从提取到的数字数据形成URI可以包括根据定义的水印语法(例如，上述任何表中提供的语法)来解析数据。在一个示例中，定义的水印语法可以包括URI权限组件的一部分。例如，定义的水印语法可以包括如上所述的广播公司标识符。进一步地，定义的水印语法可以包括服务标识符和代码类型。在一个示例中，接收器300可以通过将注册授权机构根作为URI权限组件的一部分附加到广播公司标识符来形成URI。如上所述，注册授权机构根可以识别受信任的DNS。在图3A所图示的示例中，注册授权机构根识别注册授权机构站点117。
在图3A所图示的示例中，接收器装置300查询注册授权机构站点117以获得与广播公司标识符相对应的IP地址。注册授权机构站点117在响应中提供与广播公司标识符相对应的IP地址。在一些示例中，内容提供商站点114A至114N和/或数据提供商站点116A至116N的操作者可以在注册授权机构站点注册以便与唯一的广播公司标识符相关联。接收器装置300请求来自数据提供商站点116A的补充内容。即，在该示例中，数据提供商站点116A与广播流标识符(BSID)相关联。接收器装置300接收来自数据提供商站点116A的包括补充内容的响应。接收器装置300渲染补充内容(例如，显示与运动赛事相关联的现场统计数字等)。
参照图3B，内容提供商站点114A将内容馈送传输到电视服务提供商站点106以进行分配。电视服务提供商站点106根据物理传输协议将内容馈送传输到机顶盒200。机顶盒200接收物理传输。机顶盒200从物理传输提取多媒体数据流。机顶盒200从提取到的多媒体数据流来解码多媒体信号。机顶盒200将水印插入到多媒体信号。机顶盒200可以根据上述的一个或多个技术来将水印插入到多媒体信号中。机顶盒200将包括嵌入的水印的未压缩的多媒体信号传输到接收器装置300。接收器装置300接收包括嵌入的水印的未压缩的多媒体信号。接收器300提取嵌入的水印。接收器装置300从提取到的数字数据形成URI。接收器装置可以根据上述技术来从提取到的数字数据形成URI。在图3B所图示的示例中，接收器装置300请求注册授权机构站点117将对补充内容的请求转发到与广播公司标识符相对应的IP地址。注册授权机构站点117确定与广播公司标识符相对应的IP地址并且将请求转发到数据提供商站点116A。即，在该示例中，数据提供商站点116A与BSID相关联。接收器装置300接收来自数据提供商站点116A的包括补充内容的响应。接收器装置300渲染补充内容(例如，显示与运动赛事相关联的现场统计数字等)。
图4是图示了根据本公开的一个或多个技术信令与相关联的信息的示例的流程图。应该注意的是，尽管图4是相对于电视服务提供商站点106描述的，但是可以通过本文描述的组件的任何组合来执行相对于图4描述的技术。如图4所图示的，电视服务提供商站点106接收多媒体信号(402)。电视服务提供商站点106确定与补充内容相关联的资源(404)。例如，电视服务提供商站点106可以确定与由特定应用服务器托管的多媒体相关联的应用。电视服务提供商站点106确定与资源的地址相关联的标识符(406)。例如，电视服务提供商站点106可以确定托管应用的服务器的IP地址与特定广播标识符相关联。电视服务提供商站点106生成包括标识符的数据(408)。例如，电视服务提供商站点106可以根据上述的一个或多个示例语法结构来生成数据。电视服务提供商站点106将数据嵌入到多媒体信号中(410)。例如，电视服务提供商站点106可以根据特定的水印发射，包括上述的示例指定的水印发射，将数据嵌入到多媒体信号中。例如，电视服务提供商站点106传输包括具有嵌入的数据的多媒体信号的内容(412)。例如，电视服务提供商站点106可以通过电视服务网络包括例如电视服务网络104传输数据。通过这种方式，电视服务提供商站点106代表了被配置成信令与资源标识符相关联的信息的装置的示例。
图5是图示了根据本公开的一个或多个技术的从资源检索补充内容的示例的流程图。应该注意的是，尽管图5是相对于接收器装置300描述的，但是可以通过本文描述的组件的任何组合来执行相对于图5描述的技术。如图5所图示的，接收器装置300接收多媒体信号(502)。在一个示例中，多媒体信号可以包括通过多媒体接口接收到的信号。接收器装置300从接收到的多媒体信号提取数据(504)。在一个示例中，可以根据特定的水印发射来嵌入多媒体信号中的数据。接收器装置300从提取到的数据解析标识符(506)。在一个示例中，标识符可以与资源的地址相关联。例如，特定广播标识符可以与托管应用的服务器的IP地址相关联。接收器装置300可以根据上述的一个或多个示例语法结构来解析数据。接收器装置300查询受信任的站点(508)。例如，如上所述，接收器装置可以形成包括标识符和注册授权机构站点根域的URI。接收器装置300响应于查询接收来自与标识符相对应的站点的补充内容(510)。接收器装置300渲染补充内容(512)。例如，接收器装置300可以使应用被显示。通过这种方式，接收器装置代表了被配置成从资源检索补充内容的装置的示例。
在一个或多个示例中，可以将所描述的功能实施在硬件、软件、固件、或者它们任何组合中。如果实施在软件中，可以将功能作为一个或多个指令或者代码存储在计算机可读介质上或者通过计算机可读介质传输并且通过基于硬件的处理单元执行。计算机可读介质可以包括计算机可读存储介质，该计算机可读存储介质与有形介质诸如数据存储介质或者通信介质对应，并且包括促进计算机程序例如根据通信协议从一个地方传送到另一个地方的任何介质。按照这种方式，计算机可读介质大体上可以对应于(1)非暂时性的有形计算机可读存储介质或者(2)通信介质(诸如，信号或者载波)。数据存储介质可以是可以通过一个或多个计算机或者一个或多个处理器访问以检索用于本公开描述的技术的实施方式的指令、代码和/或数据结构的任何可用介质。计算机程序产品可以包括计算机可读介质。
例如，但不限于，这种计算机可读存储介质可以包括RAM、ROM、EEPROM、CD-ROM或者其它光盘存储装置、磁盘存储装置、或者其它磁存储装置、闪速存储器、或者可以用于以指令或者数据结构的形式存储期望的程序代码并且可以通过计算机访问的任何其它介质。同样，任何连接被恰当地称为计算机可读介质。例如，如果指令是使用同轴电缆、光缆、双绞线、数字用户线(DSL)、或者无线技术诸如红外、无线电、和微波从网站、服务器、或者其它远程源传输，那么同轴电缆、光缆、双绞线、DSL、或者无线技术诸如红外、无线电、和微波被包括在介质的定义中。然而，应该理解的是，计算机可读存储介质和数据存储介质不包括连接、载波、信号、或者其它暂时性介质，而是涉及非暂时性有形存储介质。本文所使用的磁盘和光盘包括：压缩式光盘(CD)、激光视盘、光盘、数字多功能光盘(DVD)、软盘和蓝光光盘，其中，磁盘通常磁性地复制数据，而光盘利用激光光学地复制数据。上述的组合还应该被包括在计算机可读介质的范围内。
指令可以通过一个或多个处理器诸如一个或多个数字信号处理器(DSP)、通用微处理器、专用集成电路(ASIC)、现场可编程逻辑阵列(FPGA)、或者其它等效的集成或者离散逻辑电路系统执行。因此，本文所使用的术语“处理器”可以指任何前述的结构或者适用于实施本文描述的技术的任何其它结构。另外，在一些方面中，可以将本文描述的功能提供在被配置成编码和解码的专用硬件模块和/或软件模块内，或者包括在组合式编解码器中。同样，可以将该技术充分地实施在一个或多个电路或者逻辑元件中。
本公开的技术可以实施在各种装置或者设备中，包括，无线手机、集成电路(IC)、或者一组IC(例如，芯片集)。在本公开中，将各种组件、模块、或者单元描述为用于强化被配置成执行所公开的技术的装置的功能的方面，但并不一定需要通过不同的硬件单元实现。相反，如上所述，结合合适的软件和/或固件，可以将各种单元组合在编解码器硬件单元中或者可以通过交互操作的硬件单元的集合包括上文描述的一个或多个处理器来提供。
而且，用于前述实施例中的每一个的基站装置和终端装置的各个功能块或者各种特征可以由通常是集成电路或者多个集成电路的电路系统实施或者执行。旨在执行本说明书中描述的功能的电路系统可以包括通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、或者通用集成电路、现场可编程门阵列(FPGA)、或者其它可编程逻辑装置、离散门或者晶体管逻辑、或者离散硬件组件、或者它们的组合。通用处理器可以是微处理器，或者可替代地，处理器可以是常规处理器、控制器、微控制器、或者状态机。可以通过数字电路来配置或者可以通过模拟电路来配置上述的通用处理器或者各个电路。进一步地，当制成接替目前的集成电路的集成电路的技术由于半导体技术的进步而出现时，还能够使用依据这种技术的集成电路。
已经对各种示例进行了描述。这些和其它示例在以下权利要求书的范围内。
<概述>
根据本公开的一个示例，一种信令水印消息的可变长度有效载荷中的信息的方法包括：确定信息所需的数据片段数量；信令识别消息块类型的语法元素；以及信令指示消息块有效载荷的长度的语法元素，其中，指示消息块有效载荷的长度的语法元素的位数基于消息块类型。
根据本公开的另一个示例，一种信令水印消息的可变长度有效载荷中的信息的装置包括一个或多个处理器，该一个或多个处理器被配置成：确定信息所需的数据片段数量；信令识别消息块类型的语法元素；以及信令指示消息块有效载荷的长度的语法元素，其中，指示消息块有效载荷的长度的语法元素的位数基于消息块类型。
根据本公开的另一个示例，非暂时性计算机可读存储介质包括存储在其上的指令，该指令在执行时使装置的一个或多个处理器：确定信息所需的数据片段数量；信令识别消息块类型的语法元素；以及信令指示消息块有效载荷的长度的语法元素，其中，指示消息块有效载荷的长度的语法元素的位数基于消息块类型。
根据本公开的另一个示例，一种设备包括：用于确定信息所需的数据片段数量的装置；用于信令识别消息块类型的语法元素的装置；以及用于信令指示消息块有效载荷的长度的语法元素的装置，其中，指示消息块有效载荷的长度的语法元素的位数基于消息块类型。
在下面的附图和说明中陈述一个或多个示例的细节。其它特征、目的、和优点将通过说明书、附图和权利要求书而变得显而易见。
<交叉引用>
本非临时申请根据35 U.S.C.§119要求于2016年3月1日提交的临时申请第62/302,133号、于2016年5月9日提交的临时申请第62/333,683号、于2016年6月23日提交的临时申请第62/353,617号、于2016年9月27日提交的临时申请第62/400,603号、于2016年10月14日提交的临时申请第62/408,614号的优先权，其全部内容通过引用并入本文。

Claims (20)

1.一种用于请求补充内容的方法，所述方法包括：
接收多媒体信号；
从所述多媒体信号提取水印消息；
从所述水印消息解析指示权限组件的一部分的语法元素；
从所述水印消息解析指示路径组件的语法元素；以及
通过形成包括所述权限组件的所述一部分和所述路径组件的资源标识符来创建对补充内容的请求。
2.根据权利要求1所述的方法，其中，所述权限组件的所述一部分紧接在所述资源标识符中的方案之后。
3.根据权利要求2所述的方法，其中，指示权限组件的一部分的所述语法元素包括可变长度字符串。
4.根据权利要求1所述的方法，所述方法进一步包括：解析指示与域字符串相对应的代码的语法元素，并且其中，所述资源标识符进一步包括所述域字符串。
5.根据权利要求4所述的方法，其中，指示代码值的所述语法元素是8位的。
6.根据权利要求4所述的方法，其中，零的代码值与包括字符串vp1.tv的域字符串相对应。
7.根据权利要求1所述的方法，其中，所述水印消息包括被指示为统一资源标识符类水印消息的水印消息。
8.根据权利要求1所述的方法，其中，所述水印消息包括被指示为应急警报消息类水印消息的水印消息。
9.一种装置，所述装置包括一个或多个处理器，所述一个或多个处理器被配置成：
从多媒体信号提取水印消息；
从所述水印消息解析指示权限组件的一部分的语法元素；
从所述水印消息解析指示路径组件的语法元素；以及
通过形成包括所述权限组件的所述一部分和所述路径组件的资源标识符来创建对补充内容的请求。
10.根据权利要求9所述的装置，其中，所述权限组件的所述一部分紧接在所述资源标识符中的方案之后。
11.根据权利要求10所述的装置，其中，指示权限组件的一部分的所述语法元素包括可变长度字符串。
12.根据权利要求9所述的装置，其中，所述一个或多个处理器进一步被配置成：解析指示与域字符串相对应的代码的语法元素，并且其中，所述资源标识符进一步包括所述域字符串。
13.根据权利要求12所述的装置，其中，指示代码值的所述语法元素是8位的。
14.根据权利要求12所述的装置，其中，零的代码值与包括字符串vp1.tv的域字符串相对应。
15.根据权利要求9所述的装置，其中，从多媒体信号提取水印包括：根据特定的水印发射来提取嵌入到视频或音频信号中的水印。
16.根据权利要求9所述的装置，其中，从由以下组成的组中选择所述装置：桌面型计算机或膝上型计算机、移动装置、智能手机、蜂窝电话、个人数字助理(PDA)、电视机、机顶盒、平板装置、或者个人游戏装置。
17.一种用于在水印消息的有效载荷中信令不透明用户数据的方法，所述方法包括：
确定所述信息所需的数据片段数量；
基于所述信息所需的所述数据片段数量，信令识别消息块类型的语法元素；以及
信令指示消息块有效载荷的长度的语法元素，其中，指示所述消息块有效载荷的长度的所述语法元素的位数基于所述消息块类型。
18.根据权利要求16所述的方法，其中，指示所述消息块有效载荷的长度的所述语法元素的位数对于第一消息块类型来说是8，并且对于第二消息块类型来说是14。
19.根据权利要求17所述的方法，其中，所述第一消息块类型允许4个片段的最大消息块有效载荷。
20.根据权利要求18所述的方法，其中，所述第二消息块类型允许256个片段的最大消息块有效载荷。
CN201780013834.8A 2016-03-01 2017-03-01 使用水印来信令资源标识符的系统和方法 Pending CN108702548A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201811234800.4A CN109275035A (zh) 2016-03-01 2017-03-01 信令不透明用户数据的方法

Applications Claiming Priority (11)

Application Number Priority Date Filing Date Title
US201662302133P 2016-03-01 2016-03-01
US62/302,133 2016-03-01
US201662333683P 2016-05-09 2016-05-09
US62/333,683 2016-05-09
US201662353617P 2016-06-23 2016-06-23
US62/353,617 2016-06-23
US201662400603P 2016-09-27 2016-09-27
US62/400,603 2016-09-27
US201662408614P 2016-10-14 2016-10-14
US62/408,614 2016-10-14
PCT/JP2017/008100 WO2017150607A1 (en) 2016-03-01 2017-03-01 Systems and methods for signaling resource identifiers using watermarks

Related Child Applications (1)

Application Number Title Priority Date Filing Date
CN201811234800.4A Division CN109275035A (zh) 2016-03-01 2017-03-01 信令不透明用户数据的方法

Publications (1)

Publication Number Publication Date
CN108702548A true CN108702548A (zh) 2018-10-23

Family

ID=59742974

Family Applications (2)

Application Number Title Priority Date Filing Date
CN201780013834.8A Pending CN108702548A (zh) 2016-03-01 2017-03-01 使用水印来信令资源标识符的系统和方法
CN201811234800.4A Pending CN109275035A (zh) 2016-03-01 2017-03-01 信令不透明用户数据的方法

Family Applications After (1)

Application Number Title Priority Date Filing Date
CN201811234800.4A Pending CN109275035A (zh) 2016-03-01 2017-03-01 信令不透明用户数据的方法

Country Status (6)

Country Link
US (2) US20190069043A1 (zh)
KR (2) KR102134597B1 (zh)
CN (2) CN108702548A (zh)
CA (2) CA3021346C (zh)
MX (2) MX2018010333A (zh)
WO (1) WO2017150607A1 (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110826080A (zh) * 2019-09-18 2020-02-21 平安科技（深圳）有限公司 多媒体文件生成方法、装置、设备及计算机可读存储介质
CN111064993A (zh) * 2019-12-24 2020-04-24 深圳Tcl数字技术有限公司 基于水印的数据传递、生成方法、电视、机顶盒及系统
CN112565780A (zh) * 2020-12-18 2021-03-26 咪咕互动娱乐有限公司 游戏状态信息共享方法、网络设备、存储介质
CN114071050A (zh) * 2020-07-29 2022-02-18 北京字节跳动网络技术有限公司 一种基于视频的互动方法、装置、电子设备及介质

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10148728B2 (en) * 2014-12-31 2018-12-04 Level 3 Communications, Llc Network address resolution
TWI640195B (zh) * 2016-12-14 2018-11-01 日商夏普股份有限公司 具有統一資源識別符訊息浮水印有效負載之廣播系統
MX2020001303A (es) * 2017-08-10 2020-03-09 Sony Corp Aparato de transmision, metodo de transmision, aparato de recepcion y metodo de recepcion.
US10871935B2 (en) 2018-09-18 2020-12-22 Roku, Inc. Audio cancellation and content recognition of audio received over HDMI/ARC

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020199014A1 (en) * 2001-03-26 2002-12-26 Accton Technology Corporation Configurable and high-speed content-aware routing method
WO2005089476A2 (en) * 2004-03-18 2005-09-29 Digimarc Corporation Synchronizing broadcast content with corresponding network content
WO2015084004A1 (en) * 2013-12-03 2015-06-11 Lg Electronics Inc. Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals
CN104904230A (zh) * 2012-10-18 2015-09-09 Lg电子株式会社 处理交互服务的设备和方法
US20160055606A1 (en) * 2014-08-20 2016-02-25 Verance Corporation Watermark detection using a multiplicity of predicted patterns

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003010975A1 (en) * 2001-07-23 2003-02-06 Thomson Licensing S.A. System and method for broadcast of independently encoded signals on atsc channels
JP3943516B2 (ja) * 2003-03-27 2007-07-11 松下電器産業株式会社 画像再生装置
CN107659418B (zh) * 2011-10-13 2020-09-11 三星电子株式会社 从内容提供装置接收与内容包消费有关的信令信息的方法
CA2876061A1 (en) * 2012-07-05 2014-01-09 Lg Electronics Inc. Method and apparatus for processing digital service signals
CN104135670B (zh) * 2014-07-22 2018-01-19 乐视网信息技术（北京）股份有限公司 一种视频播放方法及装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020199014A1 (en) * 2001-03-26 2002-12-26 Accton Technology Corporation Configurable and high-speed content-aware routing method
WO2005089476A2 (en) * 2004-03-18 2005-09-29 Digimarc Corporation Synchronizing broadcast content with corresponding network content
CN104904230A (zh) * 2012-10-18 2015-09-09 Lg电子株式会社 处理交互服务的设备和方法
WO2015084004A1 (en) * 2013-12-03 2015-06-11 Lg Electronics Inc. Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals
US20160055606A1 (en) * 2014-08-20 2016-02-25 Verance Corporation Watermark detection using a multiplicity of predicted patterns

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ATSC: "ATSC Candidate Standard: Content Recovery in Redistribution Scenarios", 《ATSC CANDIDATE STANDARD: CONTENT RECOVERY IN REDISTRIBUTION SCENARIOS》 *
BERNERS-LEE: "Uniform Resource Identifier (URI): Generic Syntax", 《UNIFORM RESOURCE IDENTIFIER (URI): GENERIC SYNTAX》 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110826080A (zh) * 2019-09-18 2020-02-21 平安科技（深圳）有限公司 多媒体文件生成方法、装置、设备及计算机可读存储介质
CN110826080B (zh) * 2019-09-18 2024-03-08 平安科技（深圳）有限公司 多媒体文件生成方法、装置、设备及计算机可读存储介质
CN111064993A (zh) * 2019-12-24 2020-04-24 深圳Tcl数字技术有限公司 基于水印的数据传递、生成方法、电视、机顶盒及系统
CN114071050A (zh) * 2020-07-29 2022-02-18 北京字节跳动网络技术有限公司 一种基于视频的互动方法、装置、电子设备及介质
CN112565780A (zh) * 2020-12-18 2021-03-26 咪咕互动娱乐有限公司 游戏状态信息共享方法、网络设备、存储介质

Also Published As

Publication number Publication date
US10506302B2 (en) 2019-12-10
CA3015749A1 (en) 2017-09-08
CN109275035A (zh) 2019-01-25
US20190069043A1 (en) 2019-02-28
MX2018012768A (es) 2022-03-23
WO2017150607A1 (en) 2017-09-08
US20190200100A1 (en) 2019-06-27
KR20180107781A (ko) 2018-10-02
CA3015749C (en) 2020-12-29
KR20180115803A (ko) 2018-10-23
MX2018010333A (es) 2018-11-09
CA3021346A1 (en) 2017-09-08
CA3021346C (en) 2021-01-26
KR102134597B1 (ko) 2020-07-16

Similar Documents

Publication Publication Date Title
CN108702548A (zh) 使用水印来信令资源标识符的系统和方法
US11025940B2 (en) Method for signalling caption asset information and device for signalling caption asset information
CN108702535B (zh) 用于上层信息的链路层信令的系统和方法
CN105165018B (zh) 基于地面广播网络和网际协议网络的连接在混合广播系统中发送和接收广播服务的方法和装置
CA3018476C (en) Systems and methods for signaling of information associated with audio content
US11502763B2 (en) Method for signaling, method for receiving, signaling device, and receiving device
CN109792549A (zh) 用于发信号通知视频参数的系统和方法
US20190141361A1 (en) Systems and methods for signaling of an identifier of a data channel
CA2978534C (en) Systems and methods for content information message exchange
CN109661821A (zh) 用于用信号发送紧急警报消息的系统和方法
CA3041449C (en) Dynamic event signaling
WO2017213234A1 (en) Systems and methods for signaling of information associated with a visual language presentation
CN109845273A (zh) 用于实现与数字媒体分发相关联的通信的系统和方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
WD01 Invention patent application deemed withdrawn after publication
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20181023