TW201824879A - 具有統一資源識別符訊息浮水印有效負載之廣播系統 - Google Patents

具有統一資源識別符訊息浮水印有效負載之廣播系統 Download PDF

Info

Publication number
TW201824879A
TW201824879A TW106143319A TW106143319A TW201824879A TW 201824879 A TW201824879 A TW 201824879A TW 106143319 A TW106143319 A TW 106143319A TW 106143319 A TW106143319 A TW 106143319A TW 201824879 A TW201824879 A TW 201824879A
Authority
TW
Taiwan
Prior art keywords
uniform resource
message
resource identifier
value
watermark
Prior art date
Application number
TW106143319A
Other languages
English (en)
Other versions
TWI640195B (zh
Inventor
賽欽 G 迪斯潘迪
Original Assignee
日商夏普股份有限公司
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 日商夏普股份有限公司 filed Critical 日商夏普股份有限公司
Publication of TW201824879A publication Critical patent/TW201824879A/zh
Application granted granted Critical
Publication of TWI640195B publication Critical patent/TWI640195B/zh

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)
  • Television Systems (AREA)
  • Editing Of Facsimile Originals (AREA)

Abstract

本發明提供一種包含一浮水印有效負載之廣播系統。

Description

具有統一資源識別符訊息浮水印有效負載之廣播系統
本發明大體上係關於一種具有視聽內容浮水印之系統。
在諸多數位廣播系統中，一廣播站傳輸視聽(AV)內容之串流與一或多個增強型服務資料兩者。該增強型服務資料可與該AV內容物一起提供以提供資訊及服務，或可獨立於該AV內容物提供以提供資訊及服務。 在諸多廣播環境中，視聽內容及一或多個增強型服務資料並非由一AV呈現裝置自廣播站直接接收。確切而言，諸如一電視之AV呈現裝置通常連接至一廣播接收裝置，該廣播接收裝置依一經壓縮形式接收該視聽內容及該一或多個增強型服務資料並將未經壓縮視聽內容提供至該AV呈現裝置。 在一些廣播環境中，廣播接收裝置自一伺服器(有時稱之為一多頻道視訊程式化分配器(MVPD))接收視聽內容。該MVPD自廣播站接收一視聽廣播信號、自該經接收視聽廣播信號提取內容、將該經提取內容物轉換成具有用於傳輸之一適當格式之視聽信號、及將該等經轉換視聽信號提供至該廣播接收裝置。在轉換程序期間，該MVPD通常移除自廣播站提供之增強型服務資料，或可併入提供至廣播接收裝置之一不同增強型服務資料。依此方式，廣播站可提供具有增強型服務資料之視聽內容，但最終提供至AV呈現裝置及/或廣播接收裝置之增強型服務資料(若存在)可能與由廣播站提供之增強型服務資料不同。 因為廣播接收裝置自從MVPD接收之信號提取視聽內容，並僅將未經壓縮視聽資料提供至AV呈現裝置，故僅提供至廣播接收裝置之增強型服務資料可用。此外，由廣播站提供之相同增強型服務資料可能不提供至廣播接收裝置及/或AV呈現裝置。 在考慮結合隨附圖式進行之本發明之以下詳細描述後，將更容易理解前述內容及本發明之其他目的、特徵及優點。
在一個實例中，揭示一種處理一資料串流之方法，該方法包括：(a)接收該資料串流，其包含編碼於該資料串流內之一浮水印訊息；(b)自該浮水印訊息提取與遞送統一資源識別符相關之一對應統一資源識別符訊息；(c)自該統一資源識別符訊息提取一統一資源識別符類型，其識別該統一資源識別符訊息內將遵循之統一資源識別符之一類型；(d)選擇性地判定識別將遵循之統一資源識別符之一類型之該統一資源識別符類型是否具有一值0x01，該值0x01指示一發訊伺服器之一統一資源識別符以提供對一服務層發訊之存取；(e)選擇性地判定識別將遵循之統一資源識別符之一類型之該統一資源識別符類型是否具有一值0x02，該值0x02指示一電子服務導引資料伺服器之一統一資源識別符以提供對電子服務導引資料之存取；(f)選擇性地判定識別將遵循之統一資源識別符之一類型之該統一資源識別符類型是否具有一值0x03，該值0x03指示一服務使用資料收集報告伺服器之一統一資源識別符以用於報告服務使用；(g)選擇性地判定識別將遵循之統一資源識別符之一類型之該統一資源識別符類型是否具有一值0x04，該值0x04指示一動態事件WebSocket伺服器之一統一資源識別符以經由WebSocket協定提供對動態事件之存取。 在一個實例中，揭示一種用於處理一資料串流之裝置，該裝置包括一或多個處理器，該一或多個處理器經組態以：(a)接收該資料串流，其包含編碼於該資料串流內之一浮水印訊息；(b)自該浮水印訊息提取與遞送統一資源識別符相關之一對應統一資源識別符訊息；(c)自該統一資源識別符訊息提取一統一資源識別符類型，其識別該統一資源識別符訊息內將遵循之統一資源識別符之一類型；(d)選擇性地判定識別將遵循之統一資源識別符之一類型之該統一資源識別符類型是否具有一值0x01，該值0x01指示一發訊伺服器之一統一資源識別符以提供對一服務層發訊之存取；(e)選擇性地判定識別將遵循之統一資源識別符之一類型之該統一資源識別符類型是否具有一值0x02，該值0x02指示一電子服務導引資料伺服器之一統一資源識別符以提供對電子服務導引資料之存取；(f)選擇性地判定識別將遵循之統一資源識別符之一類型之該統一資源識別符類型是否具有一值0x03，該值0x03指示一服務使用資料收集報告伺服器之一統一資源識別符以用於報告服務使用；(g)選擇性地判定識別將遵循之統一資源識別符之一類型之該統一資源識別符類型是否具有一值0x04，該值0x04指示一動態事件WebSocket伺服器之一統一資源識別符以經由WebSocket協定提供對動態事件之存取。
如技術方案1之方法，其進一步包括： (a)接收一視訊資料串流中之一視訊資料； (b)取決於該統一資源識別符類型及該統一資源識別符之一者顯示該視訊資料。 如技術方案3之裝置，其經組態以： (a)接收一視訊資料串流中之一視訊資料； (b)取決於該統一資源識別符類型及該統一資源識別符之一者顯示該視訊資料。定義 uimsbf之一格式表示一不帶正負號整數最高有效位元第一格式。 當位元行數中之值等於var時，其表示一可變長度欄位。 一經保留欄位指示對應於該欄位之位元經保留以供將來使用。十六進位(亦係十六進制或hex)係以16為一基數或基之一進位制。其使用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可對應於廣播包含一或多個視聽內容串流(例如，音訊及/或視訊)之一廣播信號之一廣播站。廣播信號可進一步包含增強型服務資料及/或發訊資訊。增強型服務資料較佳地係關於視聽廣播串流之一或多者。增強型資料服務可具有任何適合格式，諸如(例如)服務資訊、後設資料、額外資料、編譯執行檔案、網路應用程式、超文件標示語言(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-4 AVC)、H.265/高效視訊編碼(HEVC)、杜比AC-3及動畫專家組第2版進階音訊編碼(MPEG-2 AAC))解碼經提取視聽內容。廣播接收裝置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可調至一使用者選擇之一頻道且接收所調至之頻道之信號、解調該等經接收信號、對該等經解調信號執行頻道解碼及視聽解碼以產生一未經壓縮視聽內容，且接著，將該未經壓縮視聽內容提供206至AV呈現裝置180。內容源100亦可透過一頻道將視聽內容廣播207至AV呈現裝置180。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作為對AV呈現裝置180之回應可提供一回覆211。 參考圖4，一進一步實例包含將視聽內容與增強型服務資料(若需要)一起提供至浮水印插入器190之內容源100。另外，內容源100可將一碼300與視聽內容一起提供至浮水印插入器190。碼300可係用於識別複數個視聽串流中之哪一者應使用浮水印修改之任一合適碼。例如，碼=1可自ABC識別第一視聽串流，碼=2可自ABC識別第二視聽串流，碼=3可自ABC識別第四視聽串流，碼=4可自美國國家廣播公司(NBC)識別第四視聽串流，等等。該碼可包含視聽內容內之暫時位置(temporal location)資訊。該碼可包含其他後設資料(若需要)。 由浮水印插入器190將經浮水印化視聽內容及相關聯資料、發訊提供至MVPD，MVPD繼而可將加浮水印的經壓縮視聽內容提供至廣播接收裝置160 (例如，一機頂盒)。廣播接收裝置160可將(例如，通常未經壓縮之)加浮水印的視聽內容提供至AV呈現裝置180。AV呈現裝置180可包含具備一浮水印能力之接收器310以及一浮水印用戶端320。具備浮水印能力之接收器310適於偵測浮水印在視聽內容內之存在，並自該視聽內容內提取浮水印資料。浮水印用戶端320適於使用自浮水印提取之資料以基於其請求額外資料，且隨後依一合適方式使用此額外資料。 AV呈現裝置180可使用來自該經提取浮水印之碼300以向一後設資料伺服器350提出一請求。一碼資料庫370自內容源100接收包含碼300及相關聯後設資料360之資料。碼300及相關聯後設資料360經儲存於碼資料庫370中以供後續使用。依此方式，提供至浮水印插入器190之在視聽內容內編碼之碼300亦與其相關聯後設資料360經儲存於碼資料庫370中。在MVPD 130或其他移除相關聯後設資料或依其他方式改變該相關聯後設資料之情況中，可由AV呈現裝置180自後設資料伺服器350復原該資料，後設資料伺服器350使用經提供碼351查詢碼資料庫370且將具有後設資料353之一相關聯回應提供至AV呈現裝置180。由後設資料伺服器350提供之回覆後設資料由AV呈現裝置180使用以形成提供至內容及發訊伺服器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，繪示一例示性時間位置(time location)有效負載。可替代地使用術語時間位置取代術語暫時位置(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有效負載且識別該兩個CSSCI有效負載。一第一時間位置有效負載(例如，Timeline-0)具有匹配CSSCI-0之關聯資訊P之第一組關聯資訊P，一第二時間位置有效負載(例如，Timeline -1)具有匹配CSSCI-0之關聯資訊P之相同第一組關聯資訊P，一第三時間位置有效負載(例如，Timeline-2)具有匹配CSSCI-1之關聯資訊P之相同第二組關聯資訊P。依此方式，CSSCI-0、Timeline-0；CSSCI-0、Timeline-1；與CSSCI-1、Timeline-2關聯在一起作為具有延伸的加浮水印資訊之對。此准許相同CSSCI類型有效負載用於多個不同時間位置有效負載。 如所繪示，各暫時位置有效負載與一先前經接收CSSCI類型有效負載相關聯，且因此，在其關聯中係單向的。在匹配一暫時位置有效負載之一先前CSSCI類型有效負載不可用之情況中，則系統能夠判定一封包已丟失或另外浮水印係無效的。浮水印資料之丟失因為視聽內容往往藉由視聽轉碼修改例如以減小該視聽內容之位元率而依某一頻率發生。 參考圖8，繪示一例示性時間線。一第一CSSCI類型有效負載(例如，CSSCI-0)具有一第一組相關聯資訊P，而一第二CSSCI類型有效負載(例如，CSSCI-1)具有一第二組不同相關聯資訊P。針對CSSCI-0與CSSCI-1存在兩種不同相關聯資訊P區分該兩個CSSCI有效負載且識別該兩個CSSCI有效負載。一第一時間位置有效負載(例如，Timeline-0)具有匹配CSSCI-0之相關聯資訊P之該第一組相關聯資訊P，一第二時間位置有效負載(例如，Timeline -1)具有匹配CSSCI-0之相關聯資訊P之相同第一組相關聯資訊P，一第三時間位置有效負載(例如，Timeline-2)具有匹配CSSCI-1之相關聯資訊P之相同第二組相關聯資訊P。依此方式，CSSCI-0、Timeline-0；CSSCI-0、Timeline-1；與CSSCI-1、Timeline-2關聯在一起作為具有延伸的加浮水印資訊之對。此准許相同CSSCI類型有效負載用於多個不同時間位置有效負載。如所繪示，暫時位置有效負載之兩者與一先前經接收CSSCI類型有效負載相關聯，且CSSCI類型有效負載之一者與一隨後經接收暫時位置有效負載相關聯，且因此，在其關聯性中係雙向的。在匹配一暫時位置有效負載之一對應CSSCI類型有效負載不可用之情況中，則系統能夠判定一封包已丟失或另外浮水印係無效的。類似地，在匹配一CSSCI有效負載之一對應時間線類型有效負載不可用之情況中，則系統能夠判定一封包已丟失或另外浮水印係無效的。浮水印資料之丟失因為視聽內容往往藉由視聽轉碼修改例如以減小該視聽內容之位元率而依某一頻率發生。 在一實例中，一CSSCI類型有效負載(例如，CSSCI-0)具有兩組關聯資訊P0與P1。一時間位置有效負載，例如，Timeline-0，具有匹配CSSCI-0之關聯資訊P0與P1之兩組關聯資訊P0與P1。在此實例中，針對對CSSCI-0、Timeline-0存在一雙向關聯，其中P0指向CSSCI-0，且P1指向Timeline-0。 可根據期望(例如，針對一所要穩健性)修改指派至有效負載識別符(P)之位元之數目。類似地，可根據期望修改指派至I、A、T、D、L及R之位元之數目。 在一實例中，AV呈現裝置180可維持由「c」個最近經接收CSSCI有效負載之一可變listC標示之一清單。若需要，可將「c」設置於浮水印中，或「c」可由系統依其他方式設定。依此方式，AV呈現裝置180可僅必須在記憶體中維持一有限數目個CSSCI有效負載。在c=1之情況中，則在接收一CSSCI有效負載後，其保持生效直至接收另一CSSCI有效負載，如圖9中所繪示。可使用有效負載識別符(P)偵測一CSSCI有效負載之一丟失，例如，暫時位置有效負載含有不對應於listC中之CSSCI有效負載之任一者之一P。依此方式，可跨不同AV呈現裝置180達成相同使用者體驗。 在一實例中，AV呈現裝置180可維持(若干)經接收CSSCI有效負載之一個以上清單。各清單之大小可不同，且可使用一組不同規則維護各清單(即，清單內之項目之添加/移除)。應理解，此不排除清單之一子組可具有相同大小及/或相同維持規則之可能性。作為一實例，可能存在由180維持之兩個清單，其中一個清單含有(若干)「c1」最近經接收CSSCI有效負載，其中按(若干)「0」CSSCI有效負載之一間隔接收各有效負載；而另一清單含有(若干)「c2」最近經接收CSSCI有效負載，其中按(若干)「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-lSSSSz=0,t；「Ct」=「Tt」。在另一實例中，可加上常數(以選擇一將來時間)及/或乘以常數(以改變粒度)經導出值。在又另一替代實例中，藉由使用一映射函數將經導出值映射至另一值。 在獲得初始化同步後，使用各有效負載更新錨時間及有效負載時間。例如此可執行如下： Tt=f(Ct-1, MMMMt) Ct=g(Tt) 其中，f表示取2個值作為輸入且輸出1個值之一映射函數；g表示取1個值作為輸入且輸出1個值之一映射函數；/表示朝向零截尾之整數除法，例如，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個位元容許1秒之一粒度下之至多12天之單獨性。在12天後，將重新使用對應於時間碼之碼空間，從而導致衝突。 在一個實例中，浮水印有效負載可使用cmdID囊封於一標準制定組織(SDO)私用資料命令內作為SDO有效負載。作為一實例，圖5或圖6之浮水印有效負載可經囊封作為SDO有效負載。一cmdID值0x05可係指一基於浮水印之互動式服務觸發(經觸發聲明物件-TDO模型)。一cmdID值0x06可係指一基於浮水印之互動式服務觸發(直接執行模型)。此促進既有分段及針對觸發運輸建置之重新組裝模組之重新使用。若需要，則經分段命令可嵌入於浮水印中。可期望SDO私用資料，諸如圖13中所繪示，其中包含封包作為SDO_payload()之部分。在一些實例中，依此方式接收之浮水印有效負載可傳遞至接收器中處置此等經定義cmdID類型之一實體/模組。接著，若浮水印有效負載封包需分離至多個封包中，則可重新使用彼模組之分段及重新組裝功能性，此取決於就位元數目而言之所選擇浮水印方案之容量。 參數類型T係一2位元欄位，其指示SDOPrivatedata命令之例項是否係一經分段可變長度命令之部分，如CEA-708 (CEA：「數位電視(DTV)隱藏字幕，CEA-708-E，消費電子協會，2013年6月」)之區段7.1.11.2中所定義，且若如此，則無論例項是否係第一分段、中間分段或最後分段。SDOPrivateData命令中之Type欄位如CEA-708之區段7.1.11.2中所指定般編碼。pr係一旗標，其在設定至「1」時指示命令之內容經確證為係相關之程式。當旗標設定至「0」時，命令之內容並不如此確證。長度(L)指示標頭之後之位元組之數目(在範圍2至27內)之不帶正負號整數，且其在SDOPrivateData命令中表示作為該組位元L4至L0，其中L4係最高有效的，且L0係最低有效的。cid (cmdID)係一8位元欄位，其識別已定義需遵循之SDO_payload()資料結構之語法及語義之SDO。後設資料可使用cmdID囊封於SDO私用資料內作為SDO有效負載，如圖14中所展示。 圖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，系統之一傳輸器可接收一或多個訊息530A、530B、530C，其等作為一浮水印嵌入於一本體(例如，音訊及/或視訊內容)中。一或多個訊息530A、530B、530C可封裝成一或多個碎片520A、520B、520C之形式。以實例方式，各訊息可包裝成一對應碎片之形式。以實例方式，各訊息可包裝成一或多個對應碎片之形式。以實例方式，一訊息可經分割，其中各者對應於一訊息碎片。在一些情況中，超過一碎片之一經准許長度之一訊息可傳播至複數個對應碎片中。在一些情況中，一長訊息可在複數個對應碎片內傳播。在一實例中，碎片之各者經編碼以僅在不需要傳輸之其他碎片時傳輸。傳輸器可接收(若干)訊息碎片，且創建待嵌入於本體內之一系列一或多個有效負載510。在一些情況中，該系列可包含多次嵌入及/或發送(若干)相同訊息碎片。在一實例中，一個有效負載嵌入本體之一個單元(例如，視訊之一個圖像及/或音訊之一個分段)。有效負載510之各者可包含(若干)碎片之額外標頭及發訊資訊。可係例如一視訊圖像及/或一音訊分段之本體可由一浮水印嵌入器500接收，浮水印嵌入器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 pattern)其後接著一訊息塊之一或多個例項。 訊息碎片可包含類型資訊，其指示攜載於碎片中之資訊之特定類型。例如，訊息類型可指示資訊包含一組預定義語法元素(例如，內容識別符、媒體時間)之一子組。在一些情況中，一些語法元素所採用之值可用於判定包含於訊息碎片中之語法元素之精確子組。例如，訊息類型可指示資訊可包含一頻道識別符。例如，訊息類型可指示資訊可包含一統一資源識別符(URI)及一URI類型。在另一實例中，訊息類型可指示資訊包含一內容識別符。 在一實例中，一訊息碎片可包含可對應於一娛樂識別符註冊(EIDR)之一內容識別符。 在一實例中，一訊息碎片可包含可對應於用於追蹤廣告資產之一廣告識別符(Ad-ID)之一內容識別符。 在一實例中，訊息碎片可包含關於包含於其內之可變長度資訊之長度資訊。 在一實例中，浮水印有效負載可包含一訊息。 在一實例中，訊息可包含於一個訊息碎片內。 在一實例中，一浮水印有效負載可攜載一或多個訊息碎片。 在一實例中，一訊息碎片可包含關於包含於其內之可變長度資訊之長度資訊，例如，URI、Ad-ID。 在一實例中，訊息碎片可包含關於包含於訊息碎片內之一第一可變長度資訊之長度資訊。第一可變長度資訊可包含一固定長度部分及一第二可變長度資訊。可如第一可變長度資訊之長度減去固定長度部分之長度般導出第二可變長度資訊之長度。可依任一合適方式導出固定長度部分之長度。例如，固定長度部分可基於訊息類型、第一可變長度資訊之長度、屬於包含於訊息碎片內之一固定長度部分之語法元素之長度而導出。在一實例中，可如第一可變長度資訊之長度減去包含於訊息碎片中之固定長度部分之長度般導出包含於一訊息碎片中之第二可變長度資訊之部分之長度。在一實例中，包含於一訊息碎片中之固定長度部分可能被不連續地包含。在一實例中，包含於一訊息碎片中之固定長度部分可位於第二可變長度資訊之任一側上。在一實例中，固定長度部分僅部分包含於訊息碎片內。在一實例中，固定長度部分可能不包含於訊息碎片內。 在一些視聽環境中，期望系統具有時移視聽內容之能力。通常，此係指將視聽內容記錄於一儲存媒體(諸如一硬碟機)上，且接著，在一稍後時間觀看經記錄演出，即使該記錄尚未完成。在一些視聽環境中，亦可期望系統具有特技模式功能，諸如先前經記錄內容之重播、暫停、暫停直播、跳至下一分段、跳至最後分段、直播內容之恢復廣播等等。在一些視聽環境中，期望系統能夠使得使用者喜好及互動式應用能夠在一緊急警示之情況中根據需要被覆蓋。通常，緊急警示係源自聯邦政府、州政府或地方政府之提供緊急資訊(諸如地震、洪水及其他國家性及/或地區性事件)之重要訊息。對於通常與視聽內容一起提供之此等緊急警示，可期望能夠覆蓋顯示於AV呈現裝置180上之圖形(諸如視訊疊對或其他圖形內容)，使得緊急警示訊息依可在AV呈現裝置上容易看到之一方式呈現。例如，在觀看者觀看AV呈現裝置(諸如一電視)上之視訊內容以及與一互動式TV應用互動之AV呈現裝置上打開之另一視窗之情況中，期望覆蓋視訊內容與互動式TV應用兩者，使得可在AV呈現裝置上容易看見緊急警示訊息。在視訊內容由另一應用(諸如互動式TV應用)遮擋之一些情況中，僅在視訊內容中顯示緊急警示訊息可能係不足夠的。在一些視聽環境中，在全部經發射廣播服務自來自諸如纜線、衛星或網際網路協定電視(IPTV)運營商之一MVPD之一經接收廣播電視服務對觀看者而言不可用之程度上，系統應能夠使得接收器能夠以經由替代網路(例如，寬帶網路連接)擷取服務之缺失組件。通常，此可包含緊急警示訊息及其內容，此等可能對一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指示表示對應緊急警示之時間範圍之一時間值。例如，在音訊及視訊浮水印之情況中時間範圍可依分鐘表示，或在視訊浮水印之情況中依秒表示。較佳地，時間範圍與廣播器之警示訊息之文本內容一致。例如，對於「生效至5pm之驟發洪水警報」之一廣播器之警示訊息，直至5 PM之一時間範圍應係適當的。亦期望包含於音訊及/或視訊內容內之緊急警示浮水印包含一緊迫性旗標710。緊迫性旗標710發訊告知裝置對緊急警示之期望即時關注程度。例如，若緊迫性旗標710經設定，則可清除所有螢幕上顯示物件(例如，運行於AV呈現裝置180 (諸如一電視)之一互動式TV應用)，即使在仍擷取緊急警示訊息之剩餘部分時亦可如此，使得緊急警示訊息可依一更緊迫方式呈現。例如，若緊迫性旗標710未經設定，則當仍在擷取緊急警示訊息之剩餘部分時螢幕上顯示物件不必依此一及時方式清除。在緊迫性旗標710未經設定之情況中，可進一步剖析及匹配緊急警示訊息以進一步確認其對當前觀看者之適用性。例如，進一步處理可包含用以判定訊息是否適用於特定觀看者之地理位置處理。 亦期望包含於音訊及/或視訊內容內之緊急警示浮水印包含一嚴重性指示符720。例如，嚴重性指示符720可包含一系列值，諸如(例如)極端嚴重、嚴重、中等、較輕及/或未知。依此方式，緊急警示信號可提供有關緊急事件之嚴重性之資訊。 亦期望包含於音訊及/或視訊內容內之緊急警示浮水印包含一確定性指示符730。例如，確定性指示符730可包含一系列值，諸如(例如)觀察到、很可能、可能、不可能及/或未知。依次方式，緊急警示信號可提供有關緊急事件之確定性之資訊。 藉由提供包含期滿時間值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_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。 參考圖20，一表表示確定性與嚴重性之不同組合。確定性1000可包含一系列值，諸如(例如)觀察到、很可能、可能、不可能及/或未知。為了藉由兩個位元表示5個值，可組合未知與不可能。嚴重性1010可包含一系列值，諸如(例如)極端嚴重、嚴重、中等、較輕及/或未知。為了藉由兩個位元表示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數位郵政ZIP碼，以使得伺服器能夠將相關緊急警示資訊提供至此AV呈現裝置。浮水印資訊亦可包含EA_Expiry 1240，其可係用於判定期滿時間之一22位元碼。浮水印訊息亦可包含依類似於EA_Urgency 854之方式之一方式指示浮水印訊息之緊迫性之一EA_Urgency 1250。 運用視聽浮水印之一系統可包含一要求：運用此浮水印技術之廣播器應確保無論何時一廣播器在經發射信號中之別處發訊一EA事件生效，則EA旗標應對應地於設定至1，且wm_message_id應對應地設定至0x05。 運用視聽浮水印之一系統可包含一要求：運用此浮水印技術之廣播器應確保無論何時一廣播器在經發射信號中之別處發訊沒有EA事件生效，則EA旗標應對應地於設定至0，且wm_message_id應對應地不設定至0x05。 圖24A表示視訊浮水印訊息塊(wm_message_block())之一例示性位元流結構，其中： wm_messgae_id係唯一識別攜載於訊息塊中之資料位元組之語法與語義之一值。 wm_message_version係一4位元值，當且僅當wm_message()中的任何事物改變時該值可遞增，在該值達到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之值係非零時，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_byte()中之位元組。 在一例示性系統中， fragment_number經約束而小於或等於last_fragment。 圖24D表示用於遞送各種類型之URI之一例示性URI訊息。可在碎片中發送URI訊息(例如，訊息標頭中之last_fragment之值可係非零)。欄位uri_type之值識別URI之類型。欄位uri_strlen之值發訊將遵循之URI_string()欄位中之字元之數目。欄位URI_string()係由字元組成之一URI，其值可經限制成由IETF意見請求(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。在一實例中，uri_strlen欄位之值針對1X視訊浮水印發射格式(1X系統)可小於或等於86。在另一實例中，uri_strlen欄位之值針對1X視訊浮水印發射格式(1X系統)可小於或等於78。 參考圖24E，可變長度欄位URI_string()前面係其長度欄位uri_strlen。在一實例中，uri_strlen欄位之值針對2X視訊浮水印發射格式(2X系統)可小於或等於206。在另一實例中，uri_strlen欄位之值針對2X視訊浮水印發射格式(2X系統)可小於或等於198。 圖24F繪示URI訊息之另一例示性語法。 圖24G繪示自URI訊息中之uri_type欄位之值至URI之類型之另一例示性映射。 在一實例中且關於圖24F，欄位uri_type可為根據圖24G中給定之編碼可識別將遵循URI之類型之一8位元不帶正負號整數欄位。 如圖24G中所繪示，uri_type 0x04可指示經由WebSocket協定提供對動態事件之存取之動態事件WebSocket伺服器之一URL。在一實例中，可使用在全文併入本文中之ATSC工作草案A/337-Application Signaling中描述之一技術完成經由WebSocket協定對動態事件之存取。除廣播外，亦可藉由寬帶遞送各種動態事件。由於新事件資訊可需要在任何時間動態傳達，支援經由一WebSocket伺服器使用通知以進行動態事件之寬帶遞送。uri_type 0x04將URL提供至此一WebSocket伺服器。在可於http://www.ietf.org/rfc/rfc6455.txt處獲得且以全文引用方式併入本文中之IETF RFC 6455中定義WebSocket協定。 在一個實例中，一動態事件可意欲用於在運行時間環境中運行之一應用程式，或作為一第二實例，其可發訊對一服務發訊檔案或資料之一未經排程更新之可用性。在一動態事件意欲用於在一運行時間環境中運行之應用程式之情況中，一裝置可經由一回叫常式使事件可用於應用程式。在行為之一進一步實例中，每當在足球遊戲中發生一Touchdown (達陣)時，一足球應用程式可經由動態事件WebSocket伺服器動態地接收一「Touchdown」事件。在另一實例中，一目標廣告插入動態事件可經由動態事件WebSocket伺服器發送至一應用程式。在運行時間環境中運行之應用程式接著接收此等動態事件且採取適當動作(例如，向使用者展示一達陣警示訊息或向使用者展示目標廣告)。當起始一足球應用程式、一目標添加應用程式時或在一接收器待接收動態事件之一情況中，該接收器可連接至在上述例示性語法及映射中指示之一伺服器。 圖25A繪示一例示性動態事件訊息。如圖24B中所展示，動態事件訊息(dynamic_event_message())係浮水印訊息之一者。 Event係對一接收器軟體或一應用程式指示待採取某一動作之一定時通知。 Event Stream係一事件串流。 一廣播站可經由廣播頻道或寬帶將事件發送至一接收器。可根據需要動態地發送事件。作為一實例，事件可經發送以發訊至接收器以開始或停止與當前節目相關聯之一特定應用程式。其他例示性事件可包含攜載一運行應用程式所需之一些資料之一事件。此等僅係實例且可由事件發送其他類型之資料。 dynamic_event_message()支援視訊浮水印中之動態事件之遞送。在一實例中，動態事件訊息之語法及位元串流語義可如圖25A中給定般。圖25A中之各種語法元素之語義描述可如下展示般。 delivery_protocol_type係可表示應用動態事件之服務之遞送之一4位元欄位。圖25B繪示此欄位之一例示性編碼。例如，遞送協定可為可在HTTP動態自適應串流(DASH)之頂部上操作之MPEG媒體輸送協定(MMTP)或單向輸送即時物件遞送(ROUTE)。在以全文引用方式併入本文中之ISO/IEC: ISO/IEC 23008-1「異質環境中之資訊技術-高效編碼及媒體遞送-部分1：MPEG媒體運輸(MMT)(Information technology-High efficiency coding and media delivery in heterogeneous environments-Part 1: MPEG media transport (MMT))」中描述MMTP。在以全文引用方式併入本文中之「ISO/ IEC 23009-1 HTTP動態自適應串流(DASH)-部分1：媒體呈現描述及分段格式(ISO/ IEC 23009-1 Dynamic adaptive streaming over HTTP (DASH) - Part 1: Media presentation description and segment formats)」中進一步描述DASH。 scheme_id_uri_strlen係給定scheme_id_uri_string欄位之長度(以位元組計)之一8位元不帶正負號整數欄位。 scheme_id_uri_string係給定事件之事件串流之schemeIdUri之一字串。指定一URI以識別方案。此元素之語義專用於由此屬性指定之方案。schemeIdUri可為一統一資源數(URN)或統一資源定位符(URL)。在可於https://tools.ietf.org/html/rfc3986獲得之IETF RFC 3986(其以全文引用方式併入)中定義URN及URL。 value_strlen係給定value_string欄位之長度(以位元組計)之一8位元不帶正負號整數欄位。 value_string係給定事件之事件串流之值之一字串。 timescale係給定如在「ISO/ IEC 23009-1 HTTP動態自適應串流(DASH)-部分1：媒體呈現描述及分段格式」中描述之MPEG DASH標準中所定義、待用於duration欄位之事件之事件串流之時間標度(以刻點(tick)/秒計)之一32位元不帶正負號整數。 presentation_time係指示事件之呈現時間、作為自國際原子時間(TAI) 1970年1月1日00:00:00起之秒數之計數之最低效32個位元之一32位元不帶正負號整數。 presentation_time_ms係在0至999之範圍中、指示自presentation_time中指示之時間之毫秒偏移使得公式presentation_time + (presentation_time_ms/1000)產生最接近1毫秒之實際呈現時間之一10位元不帶正負號整數。 duration係事件之持續時間(以事件之時間標度計)之一32位元不帶正負號整數。 id係在事件串流中獨有之事件之一32位元不帶正負號整數欄位識別符(ID)。 data_length係給定資料欄位之長度(以位元組計)之一8位元整數。 data係含有回應於事件所需之資料(若有)之一欄位。由將為針對標定至應用程式之任何事件登記以接收事件之任何應用程式所知之事件串流規範判定資料之格式及使用。 期望擴展動態事件訊息以支援未來可擴展性。圖25A中所展示之動態事件訊息僅在遞送協定係ROUTE/ DASH或MMTP時提供語法元素。此可藉由使用圖25A中之if (delivery_protocol_type == ‘1’ || ‘2’){ … }建構所見，此涵蓋對應於彼兩個遞送協定之動態事件相關語法元素。然而，在未來，當使用另一遞送協定時，圖25A中之動態事件訊息不容許對其發訊動態事件資訊。 圖25C中繪示動態事件訊息之一擴展。在圖25C中，額外欄位添加於朝向dynamic_event_message()之末端之一else {…}內。此等欄位包含「proto_reserved_field_length」及「reserved」欄位。下文描述此等欄位之語義。 proto_reserved_field_length係給定經保留欄位之長度(以位元組計)之一8位元不帶正負號整數欄位，經保留欄位緊接在此欄位之後。 reserved係長度proto_reserved_field_length之一欄位。 在未來，若定義一新遞送協定，則經保留欄位中之位元組可用於發訊任何所要資料元素。 若未知新遞送協定之一先前接收器接收遵守圖25C中所展示之語法之此一訊息，則其可跳過經保留欄位，因為該接收器知道其長度。若代替地知道新遞送協定之經保留欄位內之格式之一新接收器接收遵守圖25C中所展示之語法之一訊息，則其可在經保留欄位內進行剖析。 因此，圖25C中所展示之語法以一回溯相容方式提供未來可擴展性。 參考圖25A及圖25C，語法包含三個可變長度欄位，即：scheme_id_uri_string、value_string、data欄位。此等欄位之各者前面係指示此等可變長度欄位之長度之欄位(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_field欄位之長度(以位元組計)。 CAP_message_ID係可給定在2010年7月1日OASIS: 「Common Alerting Protocol」版本1.2 http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.pdf (以全文引用方式併入)中定義之CAP訊息之ID之一字串。其可為由CAP_message _url指示之CAP訊息之cap.alert.identifier元素之值。 CAP_message_url_length係給定CAP_message_url欄位之長度(以位元組計)之一8位元不帶正負號整數欄位。 CAP_message_url係可給定可用於擷取CAP訊息之URL之一字串。 expire係可指示在CAP訊息中、編碼為自國際原子時間(TAI) 1970年1月1日00:00:00起之秒數之一32位元計數之任何＜info＞元素之最新期滿日期及時間之一參數。 urgency係當設定為「1」時可指示CAP訊息中之最緊迫＜info＞元素之緊迫性係「Immediate」之一旗標。當設定為「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系統時確保總體訊息可適合浮水印訊息之容量。在無此約束之情況下，可創建可不適合浮水印系統且可導致接收器無法剖析經接收訊息之一訊息。 在一實例中，CAP_message_ID_length欄位之值及CAP_message_url_length之值之和針對1X視訊浮水印發射格式(1X系統)可小於或等於80。在又一實例中，CAP_message_ID_length欄位之值及CAP_message_url_length之值針對1X視訊浮水印發射格式(1X系統)可小於或等於73。 在一實例中，CAP_message_ID_length欄位之值及CAP_message_url_length之值之和針對2X視訊浮水印發射格式(2X系統) 可小於或等於200。在又一實例中，CAP_message_ID_length欄位之值及CAP_message_url_length之值針對2X視訊浮水印發射格式(2X系統)可小於或等於193。 在一實例中，參考圖26A，可不在訊息中發訊expire欄位。可藉由一旗標控制發訊，例如，當旗標值係0時，未發訊expire欄位。當旗標值係1時，發訊expire欄位。可在emergency_alert_message()中發訊旗標。 在一實例中，參考圖26A，可為expire欄位預留一特殊值。特殊值將指示emergency_alert_message()之有效期滿係未知的。例如，特殊值可為一值0。 運用視聽浮水印之一系統可任憑廣播器處理，此包含將期滿時間設定至0以減輕對判定合適持續時間及/或結束時間之需要。 運用視聽浮水印之一系統可基於包含於視聽內容內或另外對顯示器裝置可用之其他元素判定期滿時間。 此外，可由一電路實施或執行用於前述實施例之各者中之基地台裝置及終端裝置(視訊解碼器及視訊編碼器)之各功能塊或各種特徵，該電路通常係一積體電路或複數個積體電路。經設計以執行本說明書中所描述之功能之電路課包括一通用處理器、一數位信號處理器(DSP)、一專用或通用積體電路(ASIC)、一場可程式化閘陣列(FPGA)或其他可程式化邏輯裝置、離散閘或電晶體邏輯或一離散硬體組件或其等之一組合。通用處理器可係一微處理器，或替代地，處理器可係一習知處理器、一控制器、一微控制器或一狀態機。通用處理器或上文所描述之各電路可由一數位電路進行組態，或可由一類比電路進行組態。此外，當由於一半導體技術之進步而出現製造替代當前積體電路之一積體電路之一技術時，亦能夠使用藉由此技術製造之積體電路。 應理解，申請專利範圍不限於上文所繪示之準確組態及組件。可在本文所描述之系統、方法及設備之配置、操作及細節中進行各種修改、改變及變動而不脫離申請專利範圍之範疇。
100‧‧‧內容源
120‧‧‧內容辨識服務提供伺服器
130‧‧‧多頻道視訊程式分配器
140‧‧‧增強型服務資訊提供伺服器
160‧‧‧廣播接收裝置
170‧‧‧網路
180‧‧‧av呈現裝置
190‧‧‧浮水印插入器
310‧‧‧具備浮水印能力之接收器
320‧‧‧浮水印用戶端
350‧‧‧後設資料伺服器
370‧‧‧碼資料庫
380‧‧‧內容及發訊伺服器
圖1繪示具有增強型服務資訊之一系統。 圖2繪示具有增強型資訊之另一系統。 圖3繪示具有增強型資訊之一系統之一資料流。 圖4繪示具有增強型資訊之另一系統。 圖5繪示一浮水印有效負載。 圖6繪示另一浮水印有效負載。 圖7繪示浮水印有效負載之間之關係。 圖8繪示浮水印有效負載之間之關係。 圖9繪示浮水印有效負載之間之關係。 圖10繪示具有增強型資訊之另一系統。 圖11繪示獲得同步並維持同步。 圖12繪示另一浮水印有效負載。 圖13繪示SDO私用資料。 圖14繪示使用cmdID作為SDO有效負載在SDO私用資料內囊封之後設資料。 圖15繪示一浮水印嵌入系統。 圖16繪示一浮水印提取系統。 圖17繪示一緊急訊息之一期滿時間值、一緊迫性旗標、一嚴重性指示符及一確定性指示符。 圖18繪示一例示性緊急警示訊息。 圖19繪示另一例示性緊急警示訊息。 圖20繪示一組例示性確定性碼及嚴重性碼。 圖21繪示另一例示性緊急警示訊息。 圖22繪示另一例示性緊急警示訊息。 圖23繪示另一例示性緊急警示訊息。 圖24A繪示浮水印訊息塊之一例示性位元流語法。 圖24B係欄位wm_message_id至浮水印訊息wm_message()之一例示性映射。 圖24C繪示wm_message()之一例示性語法。 圖24D繪示URI訊息之一例示性語法。 圖24E繪示自uri_type欄位之值至URI之類型之一例示性映射。 圖24F繪示URI訊息之另一例示性語法。 圖24G繪示自uri_type欄位之值至URI之類型之另一例示性映射。 圖25A繪示一例示性動態事件訊息。 圖25B繪示遞送協定類型欄位編碼。 圖25C繪示另一例示性動態事件訊息。 圖26A繪示emergency_alert_message()之一例示性語法。 圖26B繪示嚴重性及確定性之一例示性編碼。

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)取決於該統一資源識別符類型及該統一資源識別符之一者顯示該視訊資料。
TW106143319A 2016-12-14 2017-12-11 具有統一資源識別符訊息浮水印有效負載之廣播系統 TWI640195B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662434393P 2016-12-14 2016-12-14
US62/434,393 2016-12-14

Publications (2)

Publication Number Publication Date
TW201824879A true TW201824879A (zh) 2018-07-01
TWI640195B TWI640195B (zh) 2018-11-01

Family

ID=62558596

Family Applications (1)

Application Number Title Priority Date Filing Date
TW106143319A TWI640195B (zh) 2016-12-14 2017-12-11 具有統一資源識別符訊息浮水印有效負載之廣播系統

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)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI733393B (zh) * 2020-03-30 2021-07-11 中華電信股份有限公司 Ｉｐｔｖ防災警示系統及其方法

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA3071560C (en) * 2017-08-10 2024-01-23 Sony Corporation Transmission apparatus, transmission method, reception apparatus, 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

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7519274B2 (en) * 2003-12-08 2009-04-14 Divx, Inc. File format for multiple track digital data
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 日本电信电话株式会社 电子水印检测方法及装置
CN102217225B (zh) * 2008-10-03 2014-04-02 杰出网络公司 内容递送网络加密
US8850523B2 (en) * 2012-04-13 2014-09-30 Cable Television Laboratories, Inc. Watermarks for roaming
MX342972B (es) * 2012-08-22 2016-10-20 Lg Electronics Inc Aparato y metodo para procesamiento de un servicio interactivo.
MX368285B (es) * 2012-09-12 2019-09-27 Lg Electronics Inc Aparato y metodo para procesar un servicio interactivo.
EP2926568A4 (en) * 2012-11-28 2016-06-08 Lg Electronics Inc APPARATUS AND METHOD FOR PROCESSING AN INTERACTIVE SERVICE
EP2978227A4 (en) * 2013-03-19 2016-08-17 Lg Electronics Inc SIGNAL TRANSMITTING APPARATUS, SIGNAL TRANSMITTING METHOD, AND SIGNAL TRANSMITTING AND RECEIVING SYSTEM
EP3247111A4 (en) * 2015-01-12 2018-06-20 LG Electronics Inc. Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method, and broadcast signal reception method
US10277934B2 (en) * 2015-03-13 2019-04-30 Qualcomm Incorporated Permissions management for watermarked data in a broadcast environment
EP3322195A4 (en) * 2015-07-06 2019-03-06 LG Electronics Inc. BROADCAST SIGNAL DEVICE, BROADCAST SIGNAL RECEIVER, BROADCAST SENDING METHOD AND BROADCAST SIGNAL RECEPTION PROCEDURE
US10791381B2 (en) * 2015-08-17 2020-09-29 Saturn Licensing Llc Receiving apparatus, transmitting apparatus, and data processing method
KR102134597B1 (ko) * 2016-03-01 2020-07-16 샤프 가부시키가이샤 불투명 사용자 데이터를 시그널링하기 위한 방법
US10681147B2 (en) * 2016-08-15 2020-06-09 Saturn Licensing Llc URLs for acquiring or transmitting data

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI733393B (zh) * 2020-03-30 2021-07-11 中華電信股份有限公司 Ｉｐｔｖ防災警示系統及其方法

Also Published As

Publication number Publication date
CA3046595A1 (en) 2018-06-21
TWI640195B (zh) 2018-11-01
US10887669B2 (en) 2021-01-05
CA3046595C (en) 2021-02-16
US20200077159A1 (en) 2020-03-05
KR20190085986A (ko) 2019-07-19
CN110073665A (zh) 2019-07-30
MX2019006819A (es) 2019-08-22
KR102135255B1 (ko) 2020-07-17
WO2018110557A1 (en) 2018-06-21

Similar Documents

Publication Publication Date Title
US11659195B2 (en) Method for receiving a universal resource identifier (URI) message in a video watermark and device for receiving a universal resource identifier (URI) message in a video watermark
TWI640195B (zh) 具有統一資源識別符訊息浮水印有效負載之廣播系統
CN107852526B (zh) 用于处理数据流的方法和接收机
US20130271653A1 (en) Broadcast service transmitting method, broadcast service receiving method and broadcast service receiving apparatus
KR101838084B1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
CA2948117A1 (en) A method of decoding a content bitstream
US10986218B2 (en) Broadcast system with a watermark payload
CA3017447C (en) Emergency messages in watermarks
TWI793106B (zh) 具內容識別符之恢復資料
WO2016185794A1 (ja) 送信装置及び送信方法、並びに受信装置及び受信方法