CN110073665A - 具有uri消息水印有效载荷的广播系统 - Google Patents
具有uri消息水印有效载荷的广播系统 Download PDFInfo
- Publication number
- CN110073665A CN110073665A CN201780076681.1A CN201780076681A CN110073665A CN 110073665 A CN110073665 A CN 110073665A CN 201780076681 A CN201780076681 A CN 201780076681A CN 110073665 A CN110073665 A CN 110073665A
- Authority
- CN
- China
- Prior art keywords
- resource identifier
- uniform resource
- message
- type
- watermark
- 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
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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
- H04N21/2389—Multiplex stream processing, e.g. multiplex stream encrypting
- H04N21/23892—Multiplex stream processing, e.g. multiplex stream encrypting involving embedding information at multiplex stream level, e.g. embedding a watermark at packet level
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
- H04H20/28—Arrangements for simultaneous broadcast of plural pieces of information
- H04H20/30—Arrangements for simultaneous broadcast of plural pieces of information by a single channel
- H04H20/31—Arrangements for simultaneous broadcast of plural pieces of information by a single channel using in-band signals, e.g. subsonic or cue signal
-
- 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
- H04H—BROADCAST COMMUNICATION
- H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
- H04H20/86—Arrangements characterised by the broadcast information itself
- H04H20/93—Arrangements characterised by the broadcast information itself which locates resources of other pieces of information, e.g. URL [Uniform Resource Locator]
-
- 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
-
- 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/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
-
- 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/84—Generation or processing of descriptive data, e.g. content descriptors
-
- 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/85—Assembly of content; Generation of multimedia applications
- H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
- H04N21/8586—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H2201/00—Aspects of broadcast communication
- H04H2201/50—Aspects of broadcast communication characterised by the use of watermarks
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Security & Cryptography (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Editing Of Facsimile Originals (AREA)
- Television Systems (AREA)
Abstract
一种用于广播的系统,其包括水印有效载荷(图24A,24B,24F和24G)。
Description
技术领域
本发明总体上涉及具有视听内容水印的系统。
背景技术
在许多数字广播系统中,广播站发送视听(AV)内容流和一个或多个增强的服务数据流两者。增强的服务数据可以与AV内容一起提供以提供信息和服务,或者可以与AV内容分开提供以提供信息和服务。
在许多广播环境中,不直接由AV呈现设备从广播站接收视听内容和一个或多个增强的服务数据。而是诸如电视的AV呈现设备通常连接到广播接收设备,该广播接收设备以压缩形式接收视听内容和一个或多个增强的服务数据,并向AV呈现设备提供未压缩的视听内容。
在一些广播环境中,广播接收设备从服务器(有时称为多信道视频节目分发商(MVPD))接收视听内容。MVPD从广播站接收视听广播信号,从接收的视听广播信号中提取内容,将提取的内容转换为具有适合传输格式的视听信号,并将转换后的视听信号提供给广播接收设备。在转换过程期间,MVPD经常移除从广播站提供的增强的服务数据,或者可以合并提供给广播接收设备的不同的增强的服务数据。以这种方式,广播站可以提供具有增强的服务数据的视听内容,但是最终提供给AV呈现设备和/或广播接收设备的增强的服务数据(如果有的话)可能不同于广播电台提供的。
由于广播接收设备从接收自MVPD的信号中提取视听内容并且向AV呈现设备仅提供未压缩的视听数据,因此仅提供给广播接收设备的增强的服务数据是可用的。此外,可以不向广播接收设备和/或AV呈现设备提供由广播站提供的相同的增强的服务数据。
通过结合附图考虑本发明的以下详细描述,将更容易理解本发明的前述和其他目的、特征和优点。
发明内容
在一个示例中,一种处理数据流的方法,该方法包括:
(a)接收包括在所述数据流内编码的水印消息的所述数据流;
(b)从与传递统一资源标识符有关的所述水印消息中提取对应的统一资源标识符消息;
(c)从所述统一资源标识符消息中提取统一资源标识符类型,其标识在所述统一资源标识符消息内要跟随的统一资源标识符的类型;
(d)选择性地确定标识要跟随的统一资源标识符的类型的所述统一资源标识符类型是否具有值0x01,其指示提供对服务层信令的访问的信令服务器的统一资源标识符;
(e)选择性地确定标识要跟随的统一资源标识符的类型的所述统一资源标识符类型是否具有值0x02,其指示提供对电子服务指南数据的访问的电子服务指南数据服务器的统一资源标识符;
(f)选择性地确定标识要跟随的统一资源标识符的类型的所述统一资源标识符类型是否具有值0x03,其指示用于报告服务使用的服务使用数据收集报告服务器的统一资源标识符;
(g)选择性地确定标识要跟随的统一资源标识符的类型的所述统一资源标识符类型是否具有值0x04,其指示提供经由WebSocket协议对动态事件的访问的动态事件WebSocket服务器的统一资源标识符。
在一个示例中,一种用于处理数据流的设备,该设备包括一个或多个处理器,其被配置为:
(a)接收包括在所述数据流内编码的水印消息的所述数据流;
(b)从与传递统一资源标识符有关的所述水印消息中提取对应的统一资源标识符消息;
(c)从所述统一资源标识符消息中提取统一资源标识符类型,其标识在所述统一资源标识符消息内要跟随的统一资源标识符的类型;
(d)选择性地确定标识要跟随的统一资源标识符的类型的所述统一资源标识符类型是否具有值0x01,其指示提供对服务层信令的访问的信令服务器的统一资源标识符;
(e)选择性地确定标识要跟随的统一资源标识符的类型的所述统一资源标识符类型是否具有值0x02,其指示提供对电子服务指南数据的访问的电子服务指南数据服务器的统一资源标识符;
(f)选择性地确定标识要跟随的统一资源标识符的类型的所述统一资源标识符类型是否具有值0x03,其指示用于报告服务使用的服务使用数据收集报告服务器的统一资源标识符;
(g)选择性地确定标识要跟随的统一资源标识符的类型的所述统一资源标识符类型是否具有值0x04,其指示提供经由WebSocket协议对动态事件的访问的动态事件WebSocket服务器的统一资源标识符。
附图说明
[图1]图1说明了具有增强的服务信息的系统。
[图2]图2说明了具有增强的信息的另一系统
[图3]图3说明了具有增强的信息的系统的数据流。
[图4]图4说明了具有增强的信息的另一系统
[图5]图5说明了水印有效载荷。
[图6]图6说明了另一水印有效载荷。
[图7]图7说明了水印有效载荷之间的关系。
[图8]图8说明了水印有效载荷之间的关系。
[图9]图9说明了水印有效载荷之间的关系。
[图10]图10说明了具有增强的信息的另一系统
[图11]图11说明了获得同步和保持同步。
[图12]图12说明了另一水印有效载荷。
[图13]图13说明了SDO私有数据。
[图14]图14使用cmdID说明了封装在SDO私有数据内作为SDO有效载荷的元数据。
[图15]图15说明了水印嵌入系统。
[图16]图16说明了水印提取系统。
[图17]图17说明了紧急消息的到期时间值、紧急标记、严重性指示符和确定性指示符。
[图18]图18说明了示例性紧急警报消息。
[图19]图19说明了另一示例性紧急警报消息
[图20]图20说明了确定性和严重性代码的示例性组。
[图21]图21说明了另一示例性紧急警报消息
[图22]图22说明了另一示例性紧急警报消息
[图23]图23说明了另一示例性紧急警报消息
[图24A]图24A说明了水印消息块的示例性比特流语法。
[图24B]图24B是字段wm_message_id到水印消息wm_message()的示例性映射。
[图24C]图24C说明了wm_message()的示例性语法。
[图24D]图24D说明了URI消息的示例性语法。
[图24E]图24E说明了从uri_type字段的值到URI的类型的示例性映射。
[图24F]图24F说明了URI消息的另一示例性语法。
[图24G]图24G说明了从uri_type字段的值到URI的类型的另一示例性映射。
[图25A]图25A说明了示例性动态事件消息。
[图25B]图25B说明了传递协议类型字段编码。
[图25C]图25C说明了另一示例性动态事件消息。
[图26A]图26A说明了emergency_alert_message()的示例性语法。
[图26B]图26B说明了严重性和确定性的示例性编码。
具体实施方式
定义
uimsbf的格式表示无符号整数高位在先格式。
当比特数列中的值等于var时,它表示可变长度字段。
保留字段指示对应于该字段的比特被保留以供将来使用。
十六进制(也是基数16,或十六进制(hex))是一个进制或基数为16的位数数字系统。它使用十六个不同的符号,最常见的是符号0-9表示值0到9,以及A、B、C、D、E、F(或者a、b、c、d、e、f)表示值10到15。十六进制数通常使用前缀“0x”。
当用于表示算术运算时,xy对应于求幂运算,即x到y的幂。在其他情况下,这种符号用于上标而非用于解释为求幂。
优选实施例的详细描述
参考图1,该系统可以包括内容源100、内容识别服务提供服务器120、多信道视频节目分发商130、增强的服务信息提供服务器140、广播接收设备160、网络170和AV呈现设备180。
内容源100可以对应于广播包括一个或多个视听内容(例如,音频和/或视频)流的广播信号的广播站。广播信号还进一步包括增强的服务数据和/或信令信息。增强的服务数据优选地涉及一个或多个视听广播流。增强的数据服务可以具有任何合适的格式,诸如,例如服务信息、元数据、附加数据、编译的执行文件、web应用、超文本标记语言(HTML)文档、可扩展标记语言(XML)文档、层叠样式表(CSS)文档、音频文件、视频文件、高级电视系统委员会(ATSC)2.0或未来版本内容,以及诸如统一资源定位器(URL)的地址。
内容识别服务提供服务器120提供内容识别服务,其允许AV呈现设备180基于来自内容源100的视听内容识别内容。内容识别服务提供服务器120可以诸如通过包括水印来可选地修改视听广播内容。在一些情况下,AV呈现设备180是数字视频记录设备。
内容识别服务提供服务器120可以包括水印插入器。水印插入器可以插入水印,该水印被设计为当对观看者不可察觉或至少最小程度地干扰的同时携带增强的服务数据和/或信令信息。在其他情况下,可以插入易于可观察的水印(例如,易于可观察可以是在图像中易于看到和/或易于可观察可以是易于可听)。例如,易于可观察的水印可以是标志,诸如在每帧的左上或右上的内容提供商的标志。
内容识别服务提供服务器120可以包括水印插入器,其修改视听内容以包括不易于可观察的水印(例如,不易于可观察可以是在图像中不易于看到和/或不易于可观察可以是不易于可听)。例如,不易于可观察的水印可以包括安全信息、跟踪信息、数据、或其他。另一示例包括信道、内容、定时、触发器和/或URL信息。
多信道视频节目分发商130从一个或多个广播站接收广播信号,并且通常向广播接收设备160提供多路复用的广播信号。多信道视频节目分发商130可以对接收的广播信号执行解调和信道解码以提取视听内容和增强的服务数据。多信道视频节目分发商130还可以对提取的视听内容和增强的服务数据执行信道编码,以生成用于进一步分发的多路复用信号。多信道视频节目分发商130可以排除提取的增强的服务数据和/或可以包括不同的增强的服务数据。
广播接收设备160可以调谐到由用户选择的信道并接收调谐信道的视听信号。广播接收设备160通常对接收的信号执行解调和信道解码,以提取期望的视听内容。广播接收设备160使用诸如例如H.264/运动图像专家组-4高级视频编码(MPEG-4AVC)、H.265/高效视频编码(HEVC)、杜比AC-3和运动图像专家组-2高级音频编码(MPEG-2AAC)的任何合适的技术来对提取的视听内容进行解码。广播接收设备160通常向AV呈现设备180提供未压缩的视听内容。
增强的服务信息提供服务器140响应于来自AV呈现设备180的请求,向视听内容提供增强的服务信息。
AV呈现设备180可以包括诸如例如电视、笔记本计算机、数字视频记录器、移动电话和智能电话的显示器。AV呈现设备180可以从广播接收设备160接收未压缩的(或压缩的)视听或视频或音频内容,从内容源100接收包括编码的视听或视频或音频内容的广播信号,和/或编码从多信道视频节目分发商130接收编码的或未编码的视听或视频或音频内容。在一些情况下,可以经由HDMI电缆接收未压缩的视频和音频。AV呈现设备180可以通过网络170从内容识别服务提供服务器120接收与来自增强的服务信息提供服务器140的视听内容有关的增强的服务的地址。
应当理解,可以根据需要组合或省略内容源100、内容识别服务提供服务器120、多信道视频节目分发商130和增强的服务信息提供服务器140。应该理解,这些是逻辑角色。在某些情况下,这些实体中的一些可以是单独的物理设备。在其他情况下,这些逻辑实体中的一些可以在相同的物理设备中实现。例如,如果需要,可以组合广播接收设备160和AV呈现设备180。
参考图2,修改的系统可以包括水印插入器190。水印插入器190可以修改视听(例如,音频和/或视频)内容以在视听内容中包括附加信息。多信道视频节目分发商130可以接收和分发包括具有水印的修改的视听内容的广播信号。
水印插入器190优选地以包括以数字信息的形式的不易于(例如,视觉地和/或听觉地)可观察的附加信息的方式修改信号。在不易于可观察的水印中,插入的信息可以是在音频和/或视频中易于可识别的。在不易于观察的水印中,尽管信息包括在视听内容(例如,音频和/或视频)中,但是用户不容易知道该信息。
水印的一个用途是用于禁止数字媒体的非法复制的版权保护。水印的另一个用途是数字媒体的源跟踪。水印的进一步用途是数字媒体的描述性信息。水印的另一个用途是提供用于可以接收与数字媒体相关联的附加内容的位置信息。另一个用途是识别内容和正在观看的内容源以及内容中的当前时间点,然后允许设备经由因特网连接访问期望的附加功能。区别于与视听内容一起传递的元数据,水印信息包括在视听内容本身内。作为示例,可以通过使用扩频技术、量化技术、和/或幅度调制技术来包括水印信息。
参考图3,说明了示例性数据流。内容源100将包括至少一个视听内容和增强的服务数据201的广播信号发送到水印插入器190。
水印插入器190接收内容源100提供的广播信号,并且在视听内容中包括易于可观察和/或不易于可观察的水印。具有水印的修改的视听内容与增强的服务数据203一起被提供给MVPD 130。
与水印相关联的内容信息可以包括,例如,提供视听内容的内容提供商的标识信息、视听内容标识信息、在内容信息获取中使用的内容部分的时间信息、通过其广播视听内容的信道的名称、通过其广播视听内容的信道的标记、通过其广播视听内容的信道的描述、报告周期的使用信息、使用信息获取的最小使用时间、体育事件的统计、有用信息的显示、小部件、应用程序、可执行文件、和/或与视听内容有关的可用的增强的服务信息。
可用的增强的服务数据的获取路径可以以诸如基于因特网协议的路径或高级电视系统委员会-移动/手持(ATSC M/H)的任何方式表示。
MVPD 130接收包括水印的视听内容和增强的数据服务的广播信号,并且可以生成复用信号以将其提供205给广播接收设备160。此时,复用的信号可以排除接收的增强的服务数据和/或可以包括不同的增强的服务数据。
广播接收设备160可以调谐到用户选择的信道,并接收调谐信道的信号,解调接收的信号,对解调的信号执行信道解码和音频-视频解码以生成未压缩的音频-视频内容,然后向AV呈现设备180提供206未压缩的视听内容。内容源100还可以通过信道向AV呈现设备180广播207视听内容。MVPD 130可以直接发送208包括视听内容的广播信号到AV呈现设备180而不经过广播接收设备160。在另一种情况下,一些AV信息可以通过宽带连接发送到AV呈现设备180。在某些情况下,这可能是管理的宽带连接。在另一种情况下,它可能是非管理的宽带连接。
AV呈现设备180可以从广播接收设备160接收未压缩(或压缩)的视听内容。另外,AV呈现设备180可以通过来自内容源100的信道接收广播信号,然后,可以解调和解码接收的广播信号以获得视听内容。另外,AV呈现设备180可以从MVPD 130接收广播信号,然后可以对接收的广播信号进行解调和解码以获得视听内容。AV呈现设备180(或广播接收设备160)从一个或多个视频帧或所接收的视听内容的音频样本的选择中提取水印信息。AV呈现设备180可以使用从(一个或多个)水印获得的信息来向增强的服务信息提供服务器140(或任何其他设备)请求209附加信息。增强的服务信息提供服务器140可以响应于此提供回复211。
参考图4,进一步的示例包括向水印插入器190提供视听内容以及增强的服务数据(如果需要)的内容源100。此外,内容源100可以向水印插入器190提供代码300以及视听内容。代码300可以是任何合适的代码以标识多个视听流当中的哪个应该用水印修改。例如,code=1可以标识第一视听流,code=2可以标识第二视听流,code=3可以标识来自ABC的第四视听流,code=4可以标识来自国家广播公司(NBC)的第四视听流,等。该代码可以包括视听内容内的时间位置信息。如果需要,代码可以包括其他元数据。
带水印的视听内容和相关数据、信令由水印插入器190提供给MVPD,MVPD又可以将带水印的压缩视听内容提供给广播接收设备160(例如,机顶盒)。广播接收设备160可以向AV呈现设备180提供带水印的视听内容(例如,通常未压缩的)。AV呈现设备180可以包括水印能力接收器310以及水印客户端320。水印能力接收器310适合于检测视听内容中水印的存在,并从视听内容中提取水印数据。水印客户端320适合于使用从水印提取的数据来基于其请求附加数据,并且随后以合适的方式使用该附加数据。
AV呈现设备180可以使用来自所提取的水印的代码300来向元数据服务器350发出请求。代码数据库370从包括代码300和相关联的元数据360的内容源100接收数据。代码300和相关联的元数据360存储在代码数据库370中以供后续使用。以这种方式,提供给在视听内容内编码的水印插入器190的代码300也与其相关联的元数据360一起存储在代码数据库370中。在MVPD 130,或者否则移除关联的元数据或者否则改变关联的元数据的情况下,其从元数据服务器350通过AV呈现设备180可恢复,元数据服务器350使用提供的代码351来查询代码数据库370并且向AV呈现设备180提供具有元数据353的关联响应。由AV呈现设备180使用由元数据服务器350提供的回复元数据以形成提供给内容和信令服务器380的请求355。内容和信令服务器380响应于该请求,提供选择的内容和信令357到AV呈现设备180。通常,内容和信令服务器380可以与元数据服务器350不同。
然而,向元数据服务器发出第一请求以获得对所提供的代码的响应,然后随后使用元数据向内容和信令服务器380提供请求是繁重的,并且由于利用两个不同的服务器/或请求而容易失败。此外,它可能会增加延迟。
以示例来说,元数据可以包括以下语法元素中的一个或多个:
(1)内容和信令服务器的位置(例如,服务器在哪里,诸如其网络地址。网络地址的示例是域名、IPv4地址等);
(2)用于与内容和信令服务器通信的协议(例如,超文本传输协议-http、超文本传输协议安全-https等);
(3)标识视听内容中的时间位置的时间码(例如,视听内容中元数据应该与其相关联的位置);
(4)时间敏感事件触发(例如,广告或视听内容中特定位置的事件);
(5)信道识别(例如,信道特定信息;本地信道内容);
(6)客户端随机执行内容和信令服务器请求的持续时间(例如,用于负载平衡)。为简洁起见,该语法元素也可称为内容服务器请求的持续时间;
(7)等。
当水印的音频-视频广播具有不易于可观察的信息时,嵌入在音频-视频内容中的(一个或多个)水印通常具有仅携带几比特的有效载荷信息的能力。对于相对小的有效载荷大小,时间码(上面的元素3)和/或内容和信令服务器的位置(上面的元素1)倾向于占用可用有效载荷的很大一部分,为剩余数据留下有限的附加有效载荷,这往往是有问题的。
为了在水印内包括足够的元数据,使得时间码和位置信息两者可以与附加信息一起提供,可能需要跨越多个水印有效载荷划分元数据。每个水印有效载荷同样优选地包括在视听内容的不同部分内。从多个水印有效载荷中提取的数据被组合在一起以形成用于发出请求的一组所需信息。在下面的描述中,术语有效载荷可以用于指示水印有效载荷。每个语法元素可以包括在单个有效载荷内、跨越多个有效载荷、和/或分段跨越多个有效载荷。可以为每个有效载荷分配有效载荷类型以用于识别。此外,可以在属于相同或近似相同时间线位置的多个有效载荷之间建立关联。而且,根据需要,该关联可以是单向的或双向的。
可以从跨越视听内容的若干时间位置的(一个或多个)有效载荷获得期望的时间码数据。因此,一些系统可以建立规则以将所确定的时间码与视听内容的特定时间位置相关联。在示例中,所选择的时间位置可以对应于预先确定的水印有效载荷结束时的时间位置。
例如,有效载荷大小可以是50比特,而期望的元数据可以是70比特,因此超过单个水印的有效载荷大小。期望的元数据的示例可以如下:
内容和服务器的位置(I)32比特(因特网协议“IP”地址)
应用层协议(A)1比特(http/https)
时间码(T)25比特(1年唯一性,粒度为1秒)
时间敏感触发(D)1比特(值为1指示AV呈现设备应查询交互内容。值为0指示AV呈现设备不应查询交互内容(例如,如在时间基础触发中))
信道识别(L)9比特
内容服务器请求的持续时间(R)2比特
期望的元数据的另一示例可以如下:
内容和服务器的位置(I)32比特(IP地址)
应用层协议(A)2比特(00=http/01=https、10=保留、11=保留)
时间码(T)25比特(1年唯一性,粒度为1秒)
时间敏感触发(D)1比特
信道识别(L)9比特
内容服务器请求的持续时间(R)2比特
划分元数据的一种方式是将内容和信号服务器通信信息(CSSCI)包括在一个有效载荷中,并将时间线信息包括在另一个有效载荷中。CSSCI有效载荷可以包括,例如,哪里信息(例如,内容和信令服务器的位置)、关联信息(例如,将CSSCI有效载荷与一个或多个其他有效载荷相关联的标识符)、以及如何信息(例如,应用层协议、内容服务器请求的持续时间)。时间线信息可以包括例如关联信息(例如,将时间线与一个或多个其他有效载荷相关联的标识符)、何时信息(例如,时间码信息)、和哪些信息(例如,信道识别)。
参考图5,说明了示例性CSSCI有效载荷。
参考图6,说明了示例性时间位置有效载荷。可以替代地使用术语时间位置(timelocation)来代替术语时间位置(temporal location)。
有效载荷类型可以由第一比特“Y”标识。当Y被设置为0时,有效载荷对应于CSSCI有效载荷,并且14比特有效载荷标识符(P)用于标记CSSCI。当Y被设置为1时,有效载荷对应于时间位置有效载荷,并且14比特有效载荷标识符(P)发信号通知对应的CSSCI。结果,具有相同有效载荷标识符(P)值的不同有效载荷类型彼此相关联。标识符R指示传播内容和信令服务器请求的持续时间。在又一示例中,“Y”可以对应于2比特字段,其中值00指示CSSCI有效载荷,值01指示时间位置有效载荷,以及值10、11被保留以供将来使用。
参考图7,说明了示例性时间线。第一CSSCI类型有效载荷(例如,CSSCI-0)具有第一组关联信息P,而第二CSSCI类型有效载荷(例如,CSSCI-1)具有第二不同组关联信息P。具有用于CSSCI-0和CSSCI-1的两个不同的关联信息P来区分和识别两个CSSCI有效载荷。第一时间位置有效载荷(例如,时间线-0)具有与CSSCI-0的关联信息P匹配的第一组关联信息P,第二时间位置有效载荷(例如,时间线-1)具有与CSSCI-0的关联信息P匹配的相同的第一组关联信息P,第三时间位置有效载荷(例如,时间线-2)具有与CSSCI-1的关联信息P匹配的相同的第二组关联信息P。以这种方式,CSSCI-0,时间线-0;CSSCI-0,时间线-1;和CSSCI-1,时间线-2被关联在一起作为具有横跨的水印信息的对。这允许相同的CSSCI类型有效载荷被用于多个不同的时间位置有效载荷。
如所说明的,每个时间位置有效载荷与先前接收的CSSCI类型有效载荷相关联,因此在其关联中是单向的。在与时间位置有效载荷匹配的先前CSSCI类型有效载荷不可用的情况下,系统可能能够确定分组已丢失或否则水印无效。水印数据的丢失以某种频率发生,因为音频-视频内容倾向于通过音频-视频转码来修改,诸如以降低音频-视频内容的比特率。
参考图8,说明了示例性时间线。第一CSSCI类型有效载荷(例如,CSSCI-0)具有第一组关联信息P,而第二CSSCI类型有效载荷(例如,CSSCI-1)具有第二不同组关联信息P。具有用于CSSCI-0和CSSCI-1的两个不同的关联信息P来区分和识别两个CSSCI有效载荷。第一时间位置有效载荷(例如,时间线-0)具有与CSSCI-0的关联信息P匹配的第一组关联信息P,第二时间位置有效载荷(例如,时间线-1)具有与CSSCI-0的关联信息P匹配的相同的第一组关联信息P,第三时间位置有效载荷(例如,时间线-2)具有与CSSCI-1的关联信息P匹配的相同的第二组关联信息P。以这种方式,CSSCI-0,时间线-0;CSSCI-0,时间线-1;和CSSCI-1,时间线-2被关联在一起作为具有横跨的水印信息的对。这允许相同的CSSCI类型有效载荷被用于多个不同的时间位置有效载荷。如所说明的,两个时间位置有效载荷与先前接收的CSSCI类型有效载荷相关联,并且CSSCI类型有效载荷中的一个与随后接收的时间位置有效载荷相关联,因此在其关联中是双向的。在与时间位置有效载荷匹配的对应CSSCI类型有效载荷不可用的情况下,则系统可能能够确定分组已丢失或否则水印无效。类似地,在与CSSCI有效载荷匹配的对应时间线类型有效载荷不可用的情况下,则系统可能能够确定分组已丢失或否则水印无效。水印数据的丢失以某种频率发生,因为音频-视频内容倾向于通过音频-视频转码来修改,诸如以降低音频-视频内容的比特率。
在示例中,CSSCI类型有效载荷(例如,CSSCI-0)具有两组关联信息P0和P1。时间位置有效载荷,例如时间线-0具有两组关联信息P0和P1,它们与CSSCI-0的关联信息P0和P1相匹配。在该示例中,对于CSSCI-0,时间线-0对,存在双向关联,其中P0指向CSSCI-0并且P1指向时间线-0。
分配给有效载荷标识符(P)的比特数可以根据需要(例如,对于期望的鲁棒性)修改。类似地,可以根据需要修改分配给I、A、T、D、L和R的比特数。
在示例中,AV呈现设备180可以保持由最近接收的(一个或多个)CSSCI有效载荷“c”的变量listC表示的列表。如果需要,可以在水印中提供“c”,或者由系统设置。以这种方式,AV呈现设备180可以仅需要在存储器中保持有限数量的CSSCI有效载荷。在c=1的情况下,一旦接收到CSSCI有效载荷,它就保持有效直到接收到另一个CSSCI有效载荷,如图9所说明的。可以使用有效载荷标识符(P)来检测CSSCI有效载荷的丢失,例如,时间位置有效载荷包含不对应于listC中的任何CSSCI有效载荷的P。以这种方式,可以跨不同的AV呈现设备180实现相同的用户体验。
在示例中,AV呈现设备180可以保持多于一个的接收的(一个或多个)CSSCI有效载荷列表。每个列表的大小可以不同,并且可以使用不同的规则集合来保持(即,在列表内添加/删除条目)。应该理解,这并不排除列表的子集可以具有相同大小和/或相同保持规则的可能性。作为示例,可以存在由180保持的两个列表,其中一个列表包含最近接收的(一个或多个)CSSCI有效载荷“c1”,其中每个有效载荷以(一个或多个)“0”CSSCI有效载荷的间隔被接收;而另一个列表包含最近接收的(一个或多个)CSSCI有效载荷“c2”,其中每个有效载荷以(一个或多个)“d”CSSCI有效载荷的间隔被接收。
参考图10,修改的系统可以包括内容源100、水印插入器190、MVPD 130、广播接收设备160和AV呈现设备180以及其水印能力接收器310和水印客户端320。内容服务器400可以被修改为包括代码数据库370、元数据服务器350以及(一个或多个)内容和信令服务器380。代码300和元数据360由内容源100提供给内容服务器400。内容和信令数据被提供给内容和信令服务器390。
AV呈现设备180可以基于来自音频-视频广播的解码的一个或多个水印在请求中提供代码。内容服务器400接收具有来自AV呈现设备180的代码的请求。然后,元数据服务器380解析所接收的代码请求,并且基于来自代码数据库370的信息,向(一个或多个)内容和信令服务器390发出请求以确定然后被提供给AV呈现设备180的内容和信令信息。以这种方式,AV呈现设备180仅需要向单个内容服务器400发出单个请求,该单个内容服务器400进而向AV呈现设备180提供响应。应当理解,内容服务器400的不同功能可以通过将现有功能组合在一起、将现有功能分成更多组件、省略组件、和/或任何其他技术来实现。
当时间敏感触发D等于1时,与图5和图6中的有效载荷相对应的http/https请求URL(将被发送到内容服务器400),可以被定义为:
如果A等于0,则http请求URL为:
http://IIIIIIII.IIIIIIII.IIIIIIII.IIIIIIII/LLLLLLLLL?time=TTTTTTTTTTTTTTTTTTTTTTTTT
否则,https请求URL为:
https://IIIIIIII.IIIIIIII.IIIIIIII.IIIIIIII/LLLLLLLLL?time=TTTTTTTTTTTTTTTTTTTTTTTTT
其中上述IIIIIIII.IIIIIIII.IIIIIIII.IIIIIIII对应于CSSCI有效载荷中发信号通知的32比特IP地址。
在示例中,指定诸如内容服务器位置、通信协议、通信端口、登录信息、内容服务器上的文件夹的信息的URL子集以设计的有效载荷类型携带。
在一些实施方式中,可以使用解码过程来导出语法元素的值,该解码过程可以访问横跨多个有效载荷的信息。例如,时间码可以被分段成多个水印有效载荷,然后重新组装以构造完整的时间码。在示例中,时间码可以对应于视听内容内的时间位置。在示例中,时间码可以对应于视听内容的时间线数据。
例如,有效载荷大小可以是50比特,而期望的元数据可以是66比特,因此超过单个水印的有效载荷大小。期望的元数据的示例可以如下:
内容和服务器的位置(I)32比特(IP地址)
应用层协议(A)1比特(http/https)
时间码(T)25比特(1年唯一性,粒度为1秒)
时间敏感触发(D)1比特
信道识别(L)5比特
内容服务器请求的持续时间(R)2比特
期望的元数据的另一示例可以如下:
内容和服务器的位置(I)32比特(IP地址)
应用层协议(A)2比特(00=http/01=https、10=保留、11=保留)
时间码(T)25比特(1年唯一性,粒度为1秒)
时间敏感触发(D)1比特
信道识别(L)5比特
内容服务器请求的持续时间(R)2比特
参考图11,状态转变图说明了一种计算时间码的技术。为了获得时间码同步,以有效载荷类型“start sync”开始的多个连续有效载荷之后是“not start sync”类型的有效载荷,其总数等于“r”。通过使用每个具有一些时间信息包含在其中的“r”个连续有效载荷的和,可以通过计算锚点时间来确定时间同步。在计算锚点时间码之后,可以通过接收其中包括部分时间码信息的附加有效载荷,以不需要接收另外的总共“r”个连续有效载荷以确定下一个时间码的方式来更新时间码。实现该时间同步的一种技术是在连续有效载荷中划分时间码,并在每个连续有效载荷中划分增量时间码。当同步丢失时,诸如通过改变信道,执行获得同步过程。首次打开时的视频显示设备进入初始“获得同步”状态。
参考图12,说明了水印有效载荷的示例性结构。Z指示有效载荷类型,其中Z等于1指示时间同步的开始,Z等于0指示时间同步的不开始。S指示用于确定绝对时间码的时间同步有效载荷比特。M指示用于保持时间码的时间同步有效载荷比特。
以示例来说,AV呈现设备180可以接收n=7个连续水印有效载荷,其中第一有效载荷具有Z=1,而后续水印有效载荷具有Z=0。对应于“SSSS”的比特从第(t-n+1)个到第t个水印有效载荷中提取并被连接在一起以获得时间位置的时间码“Tt”的28比特表示。锚点时间代码“Ct”也被设置为“Tt”。“Tt”可以表示为SSSSz=1,t-n+1...SSSSz=0,t-1SSSSz=0,t;“Ct”=“Tt”。在另一个示例中,可以添加(以选择未来时间)和/或乘以(以改变粒度)常数到导出值。在又一替代示例中,通过使用映射函数将导出值映射到另一个值。
一旦获得初始化同步,使用每个有效载荷更新锚点时间和有效载荷时间。例如,这可以如下执行:
Tt=f(Ct-1,MMMMt)
Ct=g(Tt)
其中,f表示将2个值作为输入并输出1个值的映射函数;g表示将1个值作为输入并输出1个值的映射函数;/表示结果截断趋向0的整数除法,例如,7/4和-7/-4被截断为1,-7/4和7/-4被截断为-1。在一个例子中:
Tt=Ct-1+MMMMt
CT=Tt
如上所述,每个“n”个有效载荷,也可以使用对应于“SSSS”的比特来确定锚点时间。使用“SSSS”确定的锚点时间必须与上面的锚点时间推导相匹配,并且能够用于验证保持的时间码的正确性。
由于水印可以跨越非零时间,因此时间码Tt的时间位置可以由一组规则确定,诸如,例如,Tt可以对应于第t个水印有效载荷结束时的时刻。
应该理解,可以组合多个语法元素以形成代码。然后,代码可以由AV呈现设备180或使用另一服务器映射到不同的语法元素值。例如,服务器信息(例如,(一个或多个)内容和信令服务器的位置和/或应用层协议等)和时间码被组合成单个代码。然后将单个代码映射到未压缩音频-视频流中的时间位置,以及(一个或多个)内容和信令服务器的位置。以这种方式,可以向服务器发出对于附加信息的单个请求。
以许可时间码中的冲突的方式,有限数量的比特可以用于时间码。例如,对时间码使用20比特允许最多12天的唯一性,粒度为1秒。12天后,对应于时间码的代码空间将被重用,趋于导致冲突。
在一个示例中,水印有效载荷可以使用cmdID封装在标准开发组织(SDO)私有数据命令中作为SDO有效载荷。作为示例,图5或图6的水印有效载荷可以封装为SDO有效载荷。cmdID值0x05可以指基于水印的交互服务触发(触发的声明对象-TDO模型)。cmdID值0x06可以指基于水印的交互服务触发(直接执行模型)。这有助于重复使用为触发传输而构建的现有分段和重组模块。如果需要,可以将分段命令嵌入水印中。可能需要SDO私有数据,诸如在图13中所说明的,其中分组作为SDO_payload()的一部分包括在内。在一些示例中,以这种方式接收的水印有效载荷可以被传递到处理这些定义的cmdID类型的接收器中的实体/模块。然后,如果需要将水印有效载荷分组分成多个分组——取决于所选择的水印方案在比特数方面的容量,则可以重用该模块的分段和重组功能。
参数类型T是一个2比特字段,指示SDOPrivatedata命令的实例是否是分段可变长度命令的一部分,如CEA-708的第7.1.11.2节(“CEA:“Digital Television(DTV)ClosedCaptioning,CEA-708-E,Consumer Electronics Association(消费电子协会),2013年6月”)中所定义的,如果是,则该实例是第一、中间还是最后一段。SDOPrivateData命令中的Type字段如CEA-708的7.1.11.2节中的指定进行编码。pr是一个标记,当被设置为‘1’时,指示该命令的内容被声明为节目相关。当标记被设置为‘0’时,命令的内容不会如此声明。长度(L)是指示标题后面的字节数的无符号整数,在2到27的范围内,并在SDOPrivateData命令中表示为比特L4到L0的集合,其中L4是最重要的,L0是最不重要的。cid(cmdID)是标识已定义要跟随的SDO_payload()数据结构的语法和语义的SDO的8比特字段。如图14所示,可以使用cmdID将元数据封装在SDO私有数据中作为SDO有效载荷。
图5和图6中定义的有效载荷可以使用cmdID封装在标准开发组织(SDO)私有数据(SDOPrivateData)命令中作为SDO有效载荷。cmdID值0x05和0x06可以分别指图5和图6中定义的有效载荷的封装。这有助于重复使用为触发传输而构建的现有分段和重组模块。如果需要,可以将分段命令嵌入水印中。可能需要SDO私有数据,诸如图13中所说明的,其中有效载荷分组作为SDO_payload()的一部分被包括在内。
图12中定义的有效载荷可以使用cmdID封装在标准开发组织(SDO)私有数据命令中作为SDO有效载荷。cmdID值0x05可以指图12中定义的有效载荷的封装。这有助于重复使用为触发传输而构建的现有分段和重组模块。如果需要,可以将分段命令嵌入水印中。可能需要SDO私有数据,诸如图13中所说明的,其中有效载荷分组作为SDO_payload()的一部分被包括在内。
参考图15,系统的发射器可以接收将作为水印嵌入到实质(essence)(例如,音频和/或视频内容)中的一个或多个消息530A、530B、530C。一个或多个消息530A、530B、530C可以以一个或多个片段520A、520B、520C的形式分组。以示例来说,每个消息可以以对应片段的形式分组。以示例来说,每个消息可以以一个或多个对应片段的形式分组。以示例来说,可以划分消息,其每个对应于消息片段。在一些情况下,超过片段的许可长度的消息可以被扩展成多个对应的片段。在一些情况下,长消息可以分布在多个对应的片段上。在示例中,每个片段被编码为仅在不需要发送其他片段时才发送。发射器可以接收(一个或多个)消息片段并创建一系列一个或多个有效载荷510以嵌入在实质内。在一些情况下,该系列可以包括多次嵌入和/或发送相同的(一个或多个)消息片段。在示例中,一个有效载荷嵌入有一个实质单元(例如,视频的一个图片和/或音频的一个片段)。每个有效载荷510可以包括(一个或多个)片段的附加报头和信令信息。可以是例如视频图像和/或音频片段的实质可以由水印嵌入器500接收,其将有效载荷510嵌入其中,以创建标记的实质。
在示例系统中,可能需要:如果视频片段内的图片携带水印,则视频片段内的所有图片将携带水印。然后,接收器可以通过检测在当前视频片段中没有检测到水印片段而在较早的情况下视频片段内的图片包含水印来检测图片的丢失。视频片段将对应于一组连续图片。在接收器内,可以由水印提取器通过一些外部手段识别视频片段。
参考图16,系统的解码器或接收器可以接收一个或多个标记的实质,诸如由图15的发射器提供的那些。水印有效载荷提取器600从标记的实质中提取有效载荷。可以从一个或多个有效载荷中提取610一个或多个消息片段。提取610的结果是一系列一个或多个消息片段。可以对一个或多个消息片段中的每一个进行适合地分组(例如,使用消息片段的头信息)并输入到消息重组620A、620B、620C。消息重组620A、620B、620C的结果是一系列消息630A、630B、630C。消息630A、630B、630C中的每一个可以是一个或多个片段的重组的结果,其可以是一个或多个有效载荷的结果,其可以是一个或多个标记的实质的结果。在示例中,图16中的提取和重组的消息1(630A)、...、消息(N-1)(630B)、消息N(630C)将分别与图15中的消息1(530A)、...、消息(N-1)(530B)、消息N(530C)相同。作为示例,消息重组可以涉及以特定顺序连接包括在一组消息片段中的消息数据。
在示例中,“1X”视频水印(发射格式)每视频帧传递30字节的有效载荷数据,而“2X”视频水印(发射格式)系统每帧传递60字节。它们有时分别被称为1X系统和2X系统。
在示例中,视频水印的有效载荷格式在1X和2X系统两者中是相同的。
在用于视频水印的示例有效载荷格式中,运转(run-in)模式之后跟随消息块的一个或多个实例。
消息片段可以包括指示片段中携带的特定信息类型的类型信息。例如,消息类型可以指示该信息包括预定义的一组语法元素(例如,内容标识符、媒体时间)的子集。在一些情况下,一些语法元素所采用的值可用于确定消息片段中包括的语法元素的确切子集。例如,消息类型可以指示该信息可以包括信道标识符。例如,消息类型可以指示该信息可以包括统一资源标识符(URI)和URI类型。在另一示例中,消息类型可以指示该信息包括内容标识符。
在示例中,消息片段可以包括可以对应于娱乐标识符注册表(EntertainmentIdentifier Registry,EIDR)的内容标识符。
在示例中,消息片段可以包括对应于用于跟踪广告资产的广告标识符(Ad-ID)的内容标识符。
在示例中,消息片段可以包括关于其中包括的可变长度信息的长度信息。
在示例中,水印有效载荷可以包括消息。
在示例中,消息能够被包括在一个消息片段中。
在示例中,水印有效载荷可以携带一个或多个消息片段。
在示例中,消息片段可以包括关于其中包括的可变长度信息的长度信息,例如,URI、Ad-ID。
在示例中,消息片段可以包括关于消息片段内包括的第一可变长度信息的长度信息。第一可变长度信息可包括固定长度部分和第二可变长度信息。可以如第一可变长度信息的长度减去固定长度部分的长度来导出第二可变长度信息的长度。固定长度部分的长度可以以任何合适的方式导出。例如,可以基于消息类型、第一可变长度信息的长度、属于包括在消息片段内的固定长度部分的语法元素的长度来导出固定长度部分。在示例中,包括在消息片段中的第二可变长度信息的部分的长度被导出为第一可变长度信息的长度减去包括在消息片段中的固定长度部分的长度。在示例中,可以不连续地包括消息片段中包括的固定长度部分。在示例中,包括在消息片段中的固定长度部分可以位于第二可变长度信息的任一侧。在示例中,固定长度部分仅部分地包括在消息片段内。在示例中,固定长度部分可以不包括在消息片段内。
在一些音频-视频环境中,期望系统具有对音频-视频内容进行时移的能力。通常,这指的是将视听内容记录在诸如硬盘驱动器的存储介质上,然后即使记录尚未完成也在稍后时间观看记录的节目。在一些音频-视频环境中,还希望系统能够具有特技模式(trickmode)功能,诸如回放先前记录的内容、暂停、暂停直播、跳转到下一段、跳到最后一段、恢复直播内容的广播等。在一些音频-视频环境中,期望系统具有启用在紧急警报的情况下必须覆盖的用户偏好和交互式应用程序。通常,紧急警报是源自联邦、州或地方政府的重要信息,这些信息提供紧急信息,诸如地震、洪水以及国家性质和/或区域性质的其他事件。对于通常提供有视听内容的这种紧急警报,希望能够覆盖正在AV呈现设备180上显示的图形,诸如视频叠加或其他图形内容,以便以在AV呈现设备上易于看到的方式呈现紧急警报消息。例如,在观看者正在诸如电视的AV呈现设备上观看视频内容以及与交互式TV应用程序交互的AV呈现设备上打开的另一窗口的情况下,期望覆盖视频内容和交互式TV应用程序两者,以便在AV呈现设备上易于看到紧急警报消息。在视频内容被诸如交互式TV应用程序的另一应用程序遮挡的一些情况下,仅在视频内容中显示紧急警报消息可能是不够的。在所有发射的广播服务对于从MVPD(诸如有线电视、卫星或互联网协议电视(IPTV)运营商)接收的广播电视服务的观众是不可用的程度的一些音频-视频环境中,该系统应该是能够使接收器经由替代网络(例如,宽带网络连接)检索服务的缺失组件。通常,这可能包括紧急警报消息及其内容,其可能不可用于AV呈现设备180,因为接收音频视觉内容的广播接收器设备160(例如,机顶盒)正在使用到AV呈现设备的高清晰度多媒体接口(HDMI),其仅向AV呈现设备提供未压缩的音频和视频信息,同时省略否则可能希望提供给AV呈现设备的其他类型的组件。应当理解,AV呈现设备可以是能够表达音频和/或视觉内容的任何设备,并且其可以在多屏幕交互式TV会话中联网在一起。
在呈现由广播者同时提供的广播音频-视频内容的同时,包括在音频视频内容中的任何紧急警报消息,诸如被嵌入在音频和/或视频内容内包括的水印内,具有水印能力接收器310和水印客户端320的AV呈现设备180将检测并响应于紧急警报信号。然而,在观看者对音频-视频内容具有时移的情况下,当AV呈现设备180接收到时移的音频-视频内容以及包括紧急警报信号的水印时,AV呈现设备180将同样检测并响应于紧急警报信号。虽然如果时移是最小持续时间,这种延迟检测和响应可能是适合的,这可能导致在时移不是最小持续时间时对观看者体验的干扰,因为通常紧急警报不再相关。以示例来说,当时移不是最小持续时间时,具有水印能力接收器310和水印客户端320的AV呈现设备180将检测并响应于可能涉及修改视频内容的紧急警报信号,并且可能涉及移除当前在AV呈现设备180上呈现的任何其他应用程序,导致观看体验中的不必要的中断。
参考图17,期望包括在音频和/或视频内容内的紧急警报水印包括到期时间值700。到期时间值700指示表示对应紧急警报的时间范围的时间值。例如,时间范围可以在音频和视频水印的情况下以分钟表示,或者在视频水印的情况下以秒表示。优选地,时间范围与广播者的警报消息的文本内容一致。例如,直到下午5点的时间范围适合于广播者的“直到下午5点的闪电洪水警告”的警报消息。
还期望包括在音频和/或视频内容内的紧急警报水印包括紧急标记710。紧急标记710向设备发信号通知需要立即注意紧急警报的程度。例如,如果设置了紧急标记710,则即使作为紧急警报消息的剩余部分仍在检索中,也可以清除所有屏幕上显示对象(例如,在AV呈现设备180上运行的诸如电视的交互式TV应用程序),以便可以以更紧急的方式呈现紧急警报消息。例如,如果未设置紧急标记710,则当仍然检索紧急警报消息的剩余部分时,不一定以这种及时方式清除屏幕上显示对象。在未设置紧急标记710的情况下,可以进一步解析和匹配紧急警报消息以进一步确认其对当前观看者的适用性。例如,进一步处理可以包括地理定位处理以确定消息是否适用于特定观看者。
还期望包括在音频和/或视频内容内的紧急警报水印包括严重性指示符720。例如,严重性指示符720可以包括一系列值,诸如,例如极端、严重、中等、轻微、和/或未知的。以这种方式,紧急警报信号可以提供与紧急事件的严重性相关的信息。
还期望包括在音频和/或视频内容内的紧急警报水印包括确定性指示符730。例如,确定性指示符730可以包括一系列值,诸如,例如,观察到的、很可能的(likely)、可能的(possible)、不太可能的、和/或未知的。以这种方式,紧急警报信号可以提供与紧急事件的确定性相关的信息。
通过提供包括到期时间值700、紧急标记710、严重性指示符720和/或确定性指示符730的紧急警报水印使广播者能够灵活地向接收器发信号通知适合于环境的时间敏感紧急警报,其包括经由MVPD广播接收设备160的重新分发和/或视听内容的时移使用。优选地,在音频视频内容的音频水印和/或视频水印中提供包括到期时间值700、紧急标记710、严重性指示符720和/或确定性指示符730的紧急警报信号。并且,通过提供包括到期时间值700、紧急标记710、严重性指示符720和/或确定性指示符730的紧急警报信号使接收器能够正确地识别时间敏感警报并提供合适的响应。此外,通过提供包括到期时间值700、紧急标记710、严重性指示符720和/或确定性指示符730的紧急警报信号有助于减少对观看者体验的不必要的干扰,尤其在时移的音频视频内容的情况下。此外,通过提供包括到期时间值700、紧急标记710、严重性指示符720和/或确定性指示符730的紧急警报信号向观看者提供信息,使得观看者可以适合地响应紧急警报信号。
参考图18,在诸如视频水印的具有中等容量的水印技术的有效载荷中携带的水印消息块800的结构可以包括水印消息识别(wm_message_id)802,其指示由水印消息块800发信号通知的消息的类型,诸如紧急警报信号和消息。水印消息块800可以包括完整的wm_message()或wm_message()的片段。表805可以被用于基于wm_message_id 802的类型选择适合的水印解码和/或处理集合。在wm_message_id是0x05的情况下,806指示水印消息块800包括紧急警报(EA)信号和消息(EA_message())808。当wm_message_id被指示(例如,经由信令)没有使用碎片(fragmentation)时,wm_message_bytes()包括由wm_message_id的值标识的wm_message()的完整实例,否则wm_message_bytes()包括wm_message()的片段。根据需要,同样可以使用用于水印消息的其他结构。
EA_message()808的结构可以包括一个或多个不同的数据字段。EA_message()808可以包括EA_Expiry 852,其可以是表示当当前紧急消息结束时的以分钟为粒度的协调世界时(UTC)的26比特整数值。EA_Expiry值为0指示警报结束时间未知。在接收设备中,可以将当前时间的UTC与EA_Expiry 852的UTC进行比较,如果当前时间的UTC小于或等于EA_Expiry 852的UTC,则紧急警报事件仍然适合进行相应的处理。在EA_Expiry 852值为0的情况下,指示警报到期时间未知,则AV呈现设备180可以自动表达警报消息。EA_Expiry 852对应于到期时间值700。
EA_message()808可以包括EA_Urgency 854,其可以是表示紧急警报事件的紧急程度的1比特值。值1向诸如电视的AV呈现设备180发信号通知立即注意是优选的。值0向诸如电视的AV呈现设备180发信号通知警报实质上是正常紧急的信号。这样的AV呈现设备180可以进一步将信号传播到当前与诸如电视的AV呈现设备180进行联网的多屏互动TV会话的一个或多个伴随设备。EA_Urgency 854对应于紧急标记710。
EA_message()808可以包括EA_message_body_present 856,其可以是指示与EA_message 808相关的附加数据的存在的1比特值。
EA_message()808可以包括用于字节对齐的填充的保留4比特858。
EA_message()808可以包括发信号通知与EA_message 808相关的附加数据的条件语句860。
附加数据可以包括可以提供紧急警报消息的ID的EA_message_ID 862。
附加数据可以包括EA_message_version 864,其可以提供紧急警报消息的版本号。
附加数据可以包括EA_message_text_length 866,其可以是给出EA_message_text 866的长度的8比特无符号整数。
附加数据可以包括EA_message_text(8*N)868,其可以是紧急警报文本的文本串。
应该理解,水印消息和/或其中的任何其他字段可以以任何合适的方式构造。应该理解,可以将更少和/或更多数量的比特用于信令。应当理解,数据优选地在音频和/或视频水印中接收,但是同样可以以任何其他方式获得。
参考图19,用于在视频内发信号通知水印消息的另一示例可以包括用EA_Certainty_severity_code 900替换保留4比特858,EA_Certainty_severity_code 900指示对应紧急消息的确定性和/或严重性。
参考图20,表格表示确定性和严重性的不同组合。确定性1000可以包括一系列值,诸如,例如观察到的、很可能的、可能的、不可能的和/或未知的。为了用2比特表示5个值,可以组合未知的和不可能的。严重性1010可以包括一系列值,诸如,例如极端、严重、中度、次要和/或未知的。为了用2比特表示5个值,可以组合未知的和次要。
参考图21,用于在视频内发信号通知水印消息的另一示例可以包括用保留6比特1102替换保留4比特858。此外,在视频内发信号通知水印消息可以包括用EA_Expiry 1100(32比特)替换EA_Expiry 852(26比特)。32比特提供了额外的粒度以使用秒粒度更适合地发信号通知UTC时间码。
参考图22,用于在视频内发信号通知水印消息的另一示例可以包括用保留2比特1104替换保留6比特1102。此外,在视频内发信号通知水印消息可以包括EA_Certainty_severity_code 900。
参考图23,包括在适合于音频内容的水印内的水印消息块800的结构可以包括具有1比特的紧急警报标记(EA_flag)1200,其指示由水印消息发信号通知的消息的类型,诸如紧急警报信号。当EA_flag具有值0时,则水印消息不是紧急警报类型。在这种情况下,水印消息优选地包括server_code 1210,其可以是用于查询音频水印服务器以获得关于非紧急警报消息的进一步信息的22比特代码。查询可以是“http://{server_code}.vp1.tv/atsc30/interval_code”形式,其中interval_code 1220指示视频内容中对应于server_code 1210的时间线位置。可以提供触发1230以指示应该执行前一个或多个server_code和/或interval_code水印数据。
当EA_flag 1200具有值1时,则水印消息是紧急警报类型。在这种情况下,水印消息优选地包括server_code 1210,其可以是用于查询音频水印服务器以获得关于紧急警报消息的进一步信息的22比特代码。查询可以是“http://{server_code}.vp1.tv/atsc30/AEA/?zip=zipcode”的形式,其中查询包括具有水印能力接收器310和水印客户端320的AV呈现设备180的5比特邮政编码以使服务器能够向这样的AV呈现设备提供相关的紧急警报信息。水印消息还可以包括EA_Expiry 1240,其可以是用于确定到期时间的22比特代码。水印消息还可以包括EA_Urgency 1250,其以与EA_Urgency 854相似的方式指示水印消息的紧急性。
采用视听水印的系统可以包括要求采用这种水印技术的广播者应该确保无论何时广播者发信号通知发射信号中的其他地方EA事件生效,则EA标记应该相应地被设置为1并且wm_message_id相应地被设置为0x05。
采用视听水印的系统可以包括要求采用这种水印技术的广播者应该确保无论何时广播者发信号通知发射信号中的其他地方没有EA事件生效,则EA标记应该相应地被设置为0并且wm_message_id相应地不被设置为0x05。
图24A表示视频水印消息块(wm_message_block())的示例性比特流结构,其中:
wm_message_id是唯一标识消息块中携带的数据字节的语法和语义的值。
wm_message_version是当且仅当wm_message()中的任何内容变化时,可以递增的4比特值,并在值达到15后将其循环为0。
fragment_number是指定当前消息片段的数量减1的2比特值。
last_fragment是指定用于传递完整wm_message()的最后一个片段的片段号的2比特值。last_fragment中的值‘00’指示未使用碎片(其中包含的wm_message()已完成)。last_fragment中的值‘01’指示wm_message()将在两部分中传递,值‘10’表示wm_message()将在三部分中传递,值‘11’表示其将在四部分中传递。可以认为fragment_number和last_fragment这对值发信号通知“N的部分M”。
wm_message_bytes()-当last_fragment的值为0时,wm_message_bytes()可以是由wm_message_id的值标识的水印消息的完整实例。当last_fragment的值不为0时,wm_message_bytes()可以是该水印消息wm_message()的片段。wm_message_bytes()的所有实例与给定的wm_message_id和wm_message_version数的串联导致与该wm_message_id相关联的完整wm_message()。来自一个或多个wm_message_block()实例的wm_message()的组装可以如图24C所说明的。wm_message_block(i)可以指示第i个实例,例如其fragment_number值等于i的对应的wm_message_block()实例。
图24B是wm_message_id到wm_message()的示例性映射。其用于确定wm_message_bytes()中包括的字节。
在示例系统中,fragment_number被约束为小于或等于last_fragment。
图24D表示用于传递各种类型的URI的示例性URI消息。可以以片段发送URI消息(例如,消息报头中的last_fragment的值可以是非0的)。字段uri_type的值标识URI的类型。字段uri_strlen的值发信号通知要跟随的URI_string()字段中的字符数。字段URI_string()是一个由字符组成的URI,其值可以被IETF请求评议(Request for Comments,RFC)3986(https://www.ietf.org/rfc/rfc3986.txt)限制为统一资源标识符(URI)所允许的值,其通过引用并入本文。URI字符串的长度(URI_string())可以由uri_strlen的值给出。重组后,如果URI是以片段发送的,则字符串被限制为每个RFC 3986一个有效URI。
在示例中,当在视频水印内发信号通知可变长度字段时,可以首先发信号通知该字段的长度值,即L(例如,以字节数或比特数为单位),然后跟随包含该字段数据的字节。由于1X和2X系统的容量是有限的,因此长度L可以采用的值是上限。更具体地,可变长度字段的长度的和可以不超过最大视频水印有效载荷长度的容量减去视频水印有效载荷中的各种固定长度字段的长度。固定长度字段可以包括可变长度数据的长度字段。
参考图24D,由于字段uri_strlen的允许的最大值为255,整个uri_message()可能变得大于水印1X或2X系统的最大允许容量。因此,下面在字段uri_strlen上描述约束以确保在使用1X或2X系统时整个消息可以适应水印消息的容量。在没有这种约束的情况下,可以创建不能够适应水印系统并且能够导致接收器无法解析所接收的消息的消息。
参考图24D,可变长度字段URI_string()前面是其长度字段uri_strlen。在示例中,对于1X视频水印发射格式(1X系统),uri_strlen字段的值可以小于或等于86。在另一示例中,对于1X视频水印发射格式(1X系统),uri_strlen字段的值可以小于或等于78。
参考图24E,可变长度字段URI_string()前面是其长度字段uri_strlen。在示例中,对于2X视频水印发射格式(2X系统),uri_strlen字段的值可以小于或等于206。在另一示例中,对于2X视频水印发射格式(2X系统),uri_strlen字段的值可以小于或等于198。
图24F说明了URI消息的另一示例性语法。
图24G说明了从URI消息中的uri_type字段的值到URI的类型的另一示例性映射。
在示例中并且参照图24F,字段uri_type可以是8比特无符号整数字段,其可以根据图24G中给出的编码来标识要跟随的URI的类型。
如图24G中所说明的,uri_type 0x04可以指示动态事件WebSocket服务器的URL,该服务器提供经由WebSocket协议对动态事件的访问。在示例中,可以使用ATSC WorkingDraft A/337-Application Signaling(应用程序信令)中描述的技术来完成经由WebSocket协议对动态事件的访问,该技术其整体并入本文。除了广播之外,还可以通过宽带传递各种动态事件。由于可能需要在任何时间动态地通信新事件信息,对于动态事件的宽带传递支持经由WebSocket服务器的通知的使用。uri_type 0x04为这样的WebSocket服务器提供URL。WebSocket协议在IETF RFC 6455中定义,其在http://www.ietf.org/rfc/rfc6455.txt上可获得,并其在此处通过引用整体并入本文。
在一个示例中,aa动态事件能够旨在用于在运行时环境中运行的应用程序,或者作为第二示例,它能够向服务信令文件或数据发信号通知未调度更新的可用性。在当动态事件被计划用于在运行时环境中运行的应用程序的情况下,设备可以经由回调(callback)例程使该事件对应用程序可用。在该行为的进一步示例中,橄榄球应用程序可以在橄榄球比赛中无论何时发生触地得分时,经由动态事件WebSocket服务器动态地接收“触地得分(Touchdown)”事件。在另一示例中,可以经由动态事件WebSocket服务器将目标广告插入动态事件发送到应用程序。然后,在运行时环境中运行的应用程序接收这些动态事件并采取适合的动作(例如,向用户显示触地得分警报消息或向用户显示目标广告)。接收器可以连接到示例应用程序中指示的服务器并在启动足球应用时或在接收器要接收动态事件的事件中映射上述目标广告应用程序。
图25A示出了示例性动态事件消息。如图24B所示,动态事件消息(dynamic_event_message())是水印消息之一。
事件是对指示要采取某些动作的接收器软件或应用程序的定时通知。
事件流是事件的流。
广播站可以经由广播信道或宽带向接收器发送事件。可以根据需要动态发送事件。作为示例,可以发送事件以发信号通知接收器以启动或停止与当前程序相关联的特定应用程序。其他示例事件可以包括携带正在运行的应用程序所需的一些数据的事件。这些只是示例,并且其他类型的数据可能由事件发送。
dynamic_event_message()支持在视频水印中动态事件的传递。在示例中,动态事件消息的语法和比特流语义可以如图25A中给出。图25A中的各种语法元素的语义描述可以如下所示。
delivery_protocol_type是可以表示动态事件应用的服务的传递的4比特字段。图25B说明了该字段的示例性编码。例如,传递协议可以是MPEG媒体传输协议(MMTP)或单向传输的实时对象传递(ROUTE),其可以在HTTP的动态自适应流传输(Dynamic AdaptiveStreaming of HTTP,DASH)的顶部操作。MMTP在ISO/IEC:ISO/IEC23008-1,“Informationtechnology-High efficiency coding and media delivery in heterogeneousenvironments-Part 1:MPEG media transport(MMT)(信息技术-异构环境中的高效编码和媒体传递-第1部分:MPEG媒体传输(MMT)),”中描述,其通过引用整体并入本文。在“ISO/IEC23009-1Dynamic adaptive streaming over HTTP(DASH)-Part 1:Media presentationdescription and segment formats(ISO/IEC 23009-1基于HTTP的动态自适应流传输(DASH)-第1部分:媒体呈现描述和片段格式)”中进一步描述了DASH,其通过引用整体并入本文。
scheme_id_uri_strlen是以字节为单位给出scheme_id_uri_string字段的长度8位无符号整数字段。
scheme_id_uri_string是为事件的事件流给出schemeIdUri的字符串。该元素的语义特定于此属性指定的方案。schemeIdUri可以是统一资源号(URN)或统一资源定位符(URL)。URN和URL在IETF RFC 3986中定义,可在https://tools.ietf.org/html/rfc3986获得,其通过引用整体并入。
value_strlen是以字节为单位给出value_string字段的长度的8比特无符号整数字段。
value_string是给出事件的事件流的值字符串。
timescale是给出事件的事件流的时间刻度的32比特无符号整数,其以“ISO/IEC23009-1Dynamic adaptive streaming over HTTP(DASH)-Part 1:Media presentationdescription and segment formats(ISO/IEC 23009-1HTTP上的动态自适应流传输(DASH)-第1部分:媒体演示文稿描述和片段格式)”中描述的MPEG DASH标准中定义的刻度/秒为单位。
presentation_time是指示事件的呈现时间的32比特无符号整数,如自从1970年1月1日00:00:00的、国际原子时间(TAI)以秒数计数的最低有效32比特。
presentation_time_ms是指示从presentation_time中指示的时间的毫秒偏移的在0到999范围内的10比特无符号整数,这使得公式presentation_time+(presentation_time_ms/1000)产生最接近的1毫秒的实际呈现时间。
duration是以事件的时间刻度给出事件的持续时间的32比特无符号整数。
id是事件的32比特无符号整数字段标识符(ID),在事件流中是唯一的。
data_length是以字节为单位给出数据字段的长度的8比特整数。
data是包含响应于事件所需数据的字段——如果有的话。数据的格式和使用由事件流规范确定,注册为接收用于针对应用程序的任何事件的事件的任何应用程序将知道该事件流规范。
期望动态事件消息的扩展以支持将来的可扩展性。图25A中所示的动态事件消息仅在传递协议是ROUTE/DASH或MMTP时提供语法元素。这能够通过图25A构建体中的if(delivery_protocol_type==‘1’||‘2’){…}的使用看出,其包含与这两个传递协议相对应的动态事件相关语法元素。然而,在将来使用另一传递协议时,图25A中的动态事件消息不允许为其发信号通知动态事件信息。
动态事件消息的扩展在图25C中说明。在图25C中,在text_event_message()的接近结束的else{...}部分中添加附加字段。这些字段包括“proto_reserved_field_length”和“reserved”字段。这些字段的语义如下所述。
proto_reserved_field_length是紧跟在reserved字段之后给出此字段的字节长度的8比特无符号整数字段。
reserved是长度为proto_reserved_field_length的字段。
将来,当定义新的传递协议时,则保留字段中的字节能够被用于发信号通知任何期望的数据元素。
如果不知道新传递协议的先前的接收器接收到跟随图25C中所示的语法的消息,它能够跳过reserved字段,因为它知道其长度。相反,如果知道新传递协议的reserved字段内的格式的新接收器接收到跟随图25C中所示语法的消息,它能够在保留字段内部进行解析。
因此,图25C中所示的语法以向后兼容的方式提供未来的可扩展性。
参考图25A和图25C,语法包括三个可变长度字段,即:scheme_id_uri_string、value_string、data field。这些字段中的每一个都在指示这些可变长度字段的长度的字段(scheme_id_uri_length、value_length、data_length)之后。由于字段(scheme_id_uri_length、value_length、data_length)中每个的允许的最大值是255,所以整体dynamic_event_message()可能变得大于水印1X或2X系统的最大允许容量。因此,下面描述这些字段中的约束,以确保在使用1X或2X系统时整个消息能够配合水印消息的容量。在没有这些约束的情况下,可能创建不能够配合水印系统并且能够导致接收器无法解析所接收的消息的消息。
在delivery_protocol_type具有等于1或2的值的示例中,scheme_id_uri_length字段的值、value_length字段的值和data_length字段的值的和对于1X视频水印发射格式(1X系统)可以小于或等于66,并且对于2X视频水印发射格式(2X系统)可以小于或等于186。
否则,当delivery_protocol_type具有值1或2以外的值时,proto_reserved_field_length的值对于1X视频水印发射格式(1X系统)可以小于或等于87,并且对于2X视频水印发射格式(2X系统)可以小于或等于207。
在另一示例中,当delivery_protocol_type具有等于1或2的值时,scheme_id_uri_length字段的值、value_length字段的值和data_length字段的值的和对于1X视频水印发射格式(1X系统)可以小于或等于58,并且对于2X视频水印发射格式(2X系统)可以小于或等于178。
否则,当delivery_protocol_type具有值1或2以外的值时,proto_reserved_field_length的值对于1X视频水印发射格式(1X系统)可以小于或等于78,并且对于2X视频水印发射格式(2X系统)可以小于或等于198。
在另一示例中,字段proto_reserved_field_length可以被称为另一字段名称。在示例中,字段proto_reserved_field_length可以被称为字段reserved1_field_length。
参考图24B,emergency_alert_message()可以对应于图26中所说明的示例性语法。
下面列出了图26A中的字段的示例性语义:
CAP_message_ID_length-此8比特无符号整数字段以字节为单位给出CAP_message_ID字段的长度。
CAP_message_ID是可以给出OASIS“Common Alerting Protocol”1.2版本,2010年7月1日中定义的CAP消息的ID的字符串。
http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.pdf(其整体通过引用并入本文)。它可以是CAP_message_url指示的CAP消息的cap.alert.identifier元素的值。
CAP_message_url_length是以字节为单位给出CAP_message_url字段的长度的8比特无符号整数字段。
CAP_message_url是可以给出能够被用于检索CAP消息的URL的字符串。
expires是可以指示CAP消息中任何<info>元素的最晚到期日期和时间的参数,其编码为自从1970年1月1日00:00:00、国际原子时间(TAI)以秒数的32比特计数。
urgency是当设置为“1”时,可以指示CAP消息中最紧急的<info>元素的紧急度是“立即”的标记。当设置为“0”时,它可以指示其他情况。
severity_certainty是从确定性和严重性所需的CAP元素的值派生来的4比特字段代码。对于这两个元素,已合并最低的两个值。severity_certainty的编码可以如图26B中给出的。
参考图26A,可变长度字段CAP_message_ID之前是其长度字段CAP_message_ID_length。可变长度字段CAP_message_url之前是其长度字段CAP_message_url_length。由于字段CAP_message_url_length的允许最大值是255,因此整个emergency_alert_message()可以变得大于水印1X或2X系统的最大允许容量。因此,下面描述在字段CAP_message_url_length上的约束,以确保在使用1X或2X系统时整个消息可以配合水印消息的容量。在没有这种约束的情况下,可以创建不能够配合水印系统并且可能导致接收器无法解析所接收的消息的消息。
在示例中,对于1X视频水印发射格式(1X系统),CAP_message_ID_length字段的值和CAP_message_url_length字段的值的和可以小于或等于80。在又一示例中,对于1X视频水印发射格式(1X系统),CAP_message_ID_length字段的值和CAP_message_url_length字段的值的和可以小于或等于73。
在示例中,对于2X视频水印发射格式(2X系统),CAP_message_ID_length字段的值和CAP_message_url_length字段的值的和可以小于或等于200。在又一示例中,对于2X视频水印发射格式(2X系统),CAP_message_ID_length字段的值和CAP_message_url_length字段的值的和可以小于或等于193。
在示例中,参考图26A,可以不在消息中发信号通知expires字段。信令可以通过标记来控制,例如当标记值为0时,不发信号通知expires字段。当标记值为1时,发信号通知expires字段。可以在emergency_alert_message()中发信号通知该标记。
在示例中,参考图26A,可以为expires字段留出特殊值。特殊值将指示emergency_alert_message()的有效到期是未知的。例如,特殊值可以是值0。
应用视听水印的系统可以由广播者自行决定包括将到期时间设置为0以减轻确定合适的持续时间和/或结束时间的需要。
应用视听水印的系统可以基于视听内容中包括的或者显示设备可用的其他元素来确定到期时间。
此外,在上述每个实施例中使用的基站设备和终端设备(视频解码器和视频编码器)的每个功能块或各种特征可以由电路实现或执行,该电路通常是集成电路或多个集成电路。设计用于执行本说明书中描述的功能的电路可以包括通用处理器、数字信号处理器(DSP)、专用或通用应用集成电路(ASIC)、现场可编程门阵列(FPGA)、或者其他可编程逻辑设备、离散门或晶体管逻辑、或分立硬件组件、或其组合。通用处理器可以是微处理器,或者可替代地,处理器可以是传统处理器、控制器、微控制器或状态机。上述通用处理器或每个电路可以由数字电路配置,或者可以由模拟电路配置。此外,当由于半导体技术的进步而出现取代当前集成电路的集成电路的技术时,也能够使用通过该技术的集成电路。
应该理解,权利要求不限于上面说明的精确配置和组件。在不脱离权利要求的范围的情况下,可以对本文描述的系统、方法和装置的布置、操作和细节进行各种修改、改变和变化。
Claims (4)
1.一种处理数据流的方法,所述方法包括:
(a)接收包括在所述数据流内编码的水印消息的所述数据流;
(b)从与传递统一资源标识符有关的所述水印消息中提取对应的统一资源标识符消息;
(c)从所述统一资源标识符消息中提取统一资源标识符类型,所述统一资源标识符类型标识在所述统一资源标识符消息内要跟随的统一资源标识符的类型;
(d)选择性地确定标识要跟随的统一资源标识符的类型的所述统一资源标识符类型是否具有值0x01,所述值0x01指示提供对服务层信令的访问的信令服务器的统一资源标识符;
(e)选择性地确定标识要跟随的统一资源标识符的类型的所述统一资源标识符类型是否具有值0x02,所述值0x02指示提供对电子服务指南数据的访问的电子服务指南数据服务器的统一资源标识符;
(f)选择性地确定标识要跟随的统一资源标识符的类型的所述统一资源标识符类型是否具有值0x03,所述值0x03指示用于报告服务使用的服务使用数据收集报告服务器的统一资源标识符;
(g)选择性地确定标识要跟随的统一资源标识符的类型的所述统一资源标识符类型是否具有值0x04,所述值0x04指示提供经由WebSocket协议对动态事件的访问的动态事件WebSocket服务器的统一资源标识符。
2.权利要求1所述的方法,进一步包括:
(a)在视频数据流中接收视频数据;
(b)根据所述统一资源标识符类型和所述统一资源标识符中的一个来显示所述视频数据。
3.一种用于处理数据流的设备,所述设备包括一个或多个处理器,所述处理器被配置为:
(a)接收包括在所述数据流内编码的水印消息的所述数据流;
(b)从与传递统一资源标识符有关的所述水印消息中提取对应的统一资源标识符消息;
(c)从所述统一资源标识符消息中提取统一资源标识符类型,所述统一资源标识符类型标识在所述统一资源标识符消息内要跟随的统一资源标识符的类型;
(d)选择性地确定标识要跟随的统一资源标识符的类型的所述统一资源标识符类型是否具有值0x01,所述值0x01指示提供对服务层信令的访问的信令服务器的统一资源标识符;
(e)选择性地确定标识要跟随的统一资源标识符的类型的所述统一资源标识符类型是否具有值0x02,所述值0x02指示提供对电子服务指南数据的访问的电子服务指南数据服务器的统一资源标识符;
(f)选择性地确定标识要跟随的统一资源标识符的类型的所述统一资源标识符类型是否具有值0x03,所述值0x03指示用于报告服务使用的服务使用数据收集报告服务器的统一资源标识符;
(g)选择性地确定标识要跟随的统一资源标识符的类型的所述统一资源标识符类型是否具有值0x04,所述值0x04指示提供经由WebSocket协议对动态事件的访问的动态事件WebSocket服务器的统一资源标识符。
4.权利要求3所述的设备,进一步被配置为:
(a)在视频数据流中接收视频数据;
(b)根据所述统一资源标识符类型和所述统一资源标识符中的一个来显示所述视频数据。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201662434393P | 2016-12-14 | 2016-12-14 | |
US62/434,393 | 2016-12-14 | ||
PCT/JP2017/044587 WO2018110557A1 (en) | 2016-12-14 | 2017-12-12 | Broadcast system with a uri message watermark payload |
Publications (1)
Publication Number | Publication Date |
---|---|
CN110073665A true CN110073665A (zh) | 2019-07-30 |
Family
ID=62558596
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201780076681.1A Pending CN110073665A (zh) | 2016-12-14 | 2017-12-12 | 具有uri消息水印有效载荷的广播系统 |
Country Status (7)
Country | Link |
---|---|
US (1) | US10887669B2 (zh) |
KR (1) | KR102135255B1 (zh) |
CN (1) | CN110073665A (zh) |
CA (1) | CA3046595C (zh) |
MX (1) | MX2019006819A (zh) |
TW (1) | TWI640195B (zh) |
WO (1) | WO2018110557A1 (zh) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3668101B1 (en) * | 2017-08-10 | 2024-03-20 | Saturn Licensing, LLC | Transmission device, transmission method, reception device, and reception method |
US11936638B2 (en) * | 2019-06-28 | 2024-03-19 | Salesforce Inc. | Link protocol agents for inter-application communications |
US11094314B2 (en) * | 2020-01-18 | 2021-08-17 | Interra Systems | System and method for detecting a simulated emergency alert signal (EAS) |
US11647178B2 (en) * | 2020-02-07 | 2023-05-09 | Sony Corporation | Digital television rendering verification |
TWI733393B (zh) * | 2020-03-30 | 2021-07-11 | 中華電信股份有限公司 | Iptv防災警示系統及其方法 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102217225A (zh) * | 2008-10-03 | 2011-10-12 | 杰出网络公司 | 内容递送网络加密 |
US20130276062A1 (en) * | 2012-04-13 | 2013-10-17 | Cable Television Laboratories, Inc. | Watermarks for roaming |
US20140150022A1 (en) * | 2012-11-28 | 2014-05-29 | Lg Electronics Inc. | Apparatus and method for processing an interactive service |
US20150104153A1 (en) * | 2003-12-08 | 2015-04-16 | Sonic Ip, Inc. | Multimedia Distribution System |
CN104584574A (zh) * | 2012-08-22 | 2015-04-29 | Lg电子株式会社 | 处理交互服务的设备和方法 |
CN105075274A (zh) * | 2013-03-19 | 2015-11-18 | Lg电子株式会社 | 信号发送装置、信号发送方法及发送和接收信号的系统 |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
TWI228376B (en) * | 2003-12-23 | 2005-02-21 | Ind Tech Res Inst | Watermark encoding method and recording medium thereof |
CN101866475B (zh) * | 2005-08-04 | 2012-11-21 | 日本电信电话株式会社 | 电子水印检测方法及装置 |
WO2014042368A1 (en) * | 2012-09-12 | 2014-03-20 | Lg Electronics Inc. | Apparatus and method for processing an interactive service |
CN107210828A (zh) * | 2015-01-12 | 2017-09-26 | Lg电子株式会社 | 广播信号发送装置、广播信号接收装置、广播信号发送方法和广播信号接收方法 |
US10277934B2 (en) * | 2015-03-13 | 2019-04-30 | Qualcomm Incorporated | Permissions management for watermarked data in a broadcast environment |
CN113438517B (zh) * | 2015-07-06 | 2023-02-28 | Lg电子株式会社 | 处理广播数据的方法、接收系统和发送系统 |
JPWO2017029990A1 (ja) * | 2015-08-17 | 2018-06-07 | ソニー株式会社 | 受信装置、送信装置、およびデータ処理方法 |
US20190069043A1 (en) * | 2016-03-01 | 2019-02-28 | Sharp Kabushiki Kaisha | Systems and methods for signaling resource identifiers using watermarks |
US10681147B2 (en) * | 2016-08-15 | 2020-06-09 | Saturn Licensing Llc | URLs for acquiring or transmitting data |
-
2017
- 2017-12-11 TW TW106143319A patent/TWI640195B/zh active
- 2017-12-12 CN CN201780076681.1A patent/CN110073665A/zh active Pending
- 2017-12-12 CA CA3046595A patent/CA3046595C/en active Active
- 2017-12-12 MX MX2019006819A patent/MX2019006819A/es unknown
- 2017-12-12 US US16/467,647 patent/US10887669B2/en active Active
- 2017-12-12 WO PCT/JP2017/044587 patent/WO2018110557A1/en active Application Filing
- 2017-12-12 KR KR1020197017491A patent/KR102135255B1/ko active IP Right Grant
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150104153A1 (en) * | 2003-12-08 | 2015-04-16 | Sonic Ip, Inc. | Multimedia Distribution System |
CN102217225A (zh) * | 2008-10-03 | 2011-10-12 | 杰出网络公司 | 内容递送网络加密 |
US20130276062A1 (en) * | 2012-04-13 | 2013-10-17 | Cable Television Laboratories, Inc. | Watermarks for roaming |
CN104584574A (zh) * | 2012-08-22 | 2015-04-29 | Lg电子株式会社 | 处理交互服务的设备和方法 |
US20140150022A1 (en) * | 2012-11-28 | 2014-05-29 | Lg Electronics Inc. | Apparatus and method for processing an interactive service |
CN105075274A (zh) * | 2013-03-19 | 2015-11-18 | Lg电子株式会社 | 信号发送装置、信号发送方法及发送和接收信号的系统 |
Non-Patent Citations (1)
Title |
---|
ATSC: "ATSC Candidate Standard:content recovery in redistribution scenarios (A/336)", 《HTTP://WWW.ATSC.ORG/WP-CONTENT/UPLOADS/2016/03/S33-178R2-CONTENT-RECOVERY-IN-REDISTRIBUTION-SCENARIOS.PDF》 * |
Also Published As
Publication number | Publication date |
---|---|
WO2018110557A1 (en) | 2018-06-21 |
KR102135255B1 (ko) | 2020-07-17 |
US10887669B2 (en) | 2021-01-05 |
KR20190085986A (ko) | 2019-07-19 |
US20200077159A1 (en) | 2020-03-05 |
CA3046595A1 (en) | 2018-06-21 |
TW201824879A (zh) | 2018-07-01 |
TWI640195B (zh) | 2018-11-01 |
MX2019006819A (es) | 2019-08-22 |
CA3046595C (en) | 2021-02-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11516495B2 (en) | Broadcast system with a watermark payload | |
CN110073665A (zh) | 具有uri消息水印有效载荷的广播系统 | |
US20170070790A1 (en) | A method of decoding a content bitstream | |
CN107852526B (zh) | 用于处理数据流的方法和接收机 | |
KR101805538B1 (ko) | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 | |
KR20150048669A (ko) | 양방향 서비스를 처리하는 장치 및 방법 | |
US10986218B2 (en) | Broadcast system with a watermark payload | |
CA3017447C (en) | Emergency messages in watermarks |
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 |
Application publication date: 20190730 |
|
WD01 | Invention patent application deemed withdrawn after publication |