CN118339839A - Blurring alternative content in Advanced Television Systems Committee (ATSC) 3.0 system - Google Patents

Abstract

Techniques for hiding aspects of RC in the Advanced Television Systems Committee (ATSC) 3.0 television protocol to deliver next generation broadcast television services in a robust manner are described. In this way, the skip strategy may be frustrated by delivering (304) the information needed to play the RC a short time before insertion occurs.

Description

Blurring alternative content in Advanced Television Systems Committee (ATSC) 3.0 system

Technical Field

The present application relates to technological advances that necessarily stem from computer technology and are directed to digital television, and more particularly to Advanced Television Systems Committee (ATSC) 3.0.

Background

The Advanced Television Systems Committee (ATSC) 3.0 suite of standards is a collection of over ten industry technology standards as demonstrated in a/300 for delivering next generation broadcast television. ATSC 3.0 supports a variety of data services including television media, interactive services, non-real-time data delivery, and custom advertising for a large number of receiving devices from ultra-high definition televisions to wireless telephones. ATSC 3.0 also orchestrates coordination between broadcast content (referred to as "over the air") and related broadband delivery content and services (referred to as "over the top"). The term "service" as used herein is defined in ATSC 3.0 as the aggregate set of content components that are aggregated for presentation to a user; the components belong to different media types. The service may be continuous or intermittent. The service may be real-time or non-real-time, and the real-time service may be made up of a sequence of TV programs. ATSC 3.0 is designed to be flexible so that as technology advances, advances can be easily incorporated without requiring complete modification of any relevant technical standards. As shown below, the present principles are directed to such advances.

Disclosure of Invention

The present principles are directed to blurring the start time and duration of ATSC 3.0 advertisements to prevent receivers from employing advertisement skipping strategies that may be unfriendly to the broadcaster's business model.

As understood herein, ATSC 3.0 may provide television content using dynamic adaptive streaming over hypertext transfer protocol (HTTP) (DASH) as described in international standard ISO/IEC 23009-1, which specifies a Media Presentation Description (MPD). ATSC 3.0 specifies the use of two types of dynamic live MPDs to facilitate real-time encoding and delivery of content and, in addition, allows for replacement of particular content with Replacement Content (RC) tailored to a particular user. The first type of dynamic live MPD uses a segment naming convention based on segment templates and with an incremental numbering scheme, which may or may not need to be continuously updated as the content is played, and requires synchronization to the broadcast clock at the receiver in order to correctly infer the number and thus also the name of the segments available and residing at the so-called "live edge" of the encoded stream. A dynamic live MPD of the segment numbering template type is suitable for over-the-air (OTA) delivered content, where the decoder's clock can be synchronized with the OTA broadcast clock and maintained even in standby state.

The second type of dynamic live MPD uses a segment time template to explicitly include the Presentation Time Stamp (PTS) of the start of the segment in the segment name and lists only the segments available for playback at the receiver. This is particularly suitable for live top (OTT) delivered clips when no synchronized broadcast clock is available, or where live encoding of the clip results in a variable clip duration that is not known in advance. The segment timeline is represented in SEGMENTTIMELINE units in the DASH MPD. Unlike the indexing mode of the segment numbering template, well-defined segments in the dynamic live segment time template must always be available to the receiver, thus knowing that the last segment in the list is a live edge without requiring clock synchronization. Thus, this second type of dynamic live MPD addresses the challenge that the receiver clock may not be synchronized (or even unsynchronizable) with the broadcaster clock for technical reasons, especially when there is no precise synchronization with the clock in the broadcast channel for segments in the OTT delivery stream. A receiver tuned to a particular channel can begin playing immediately from there, simply by deriving the live edge from the information in the MPD.

Accordingly, in one aspect, a digital television system, such as an Advanced Television Systems Committee (ATSC) 3.0 system, includes at least one receiver of digital television content with segment timeline signaling. The broadcast stream is configured to use SEGMENTTIMELINE-based MPD, which SEGMENTTIMELINE-based MPD may include periods of replaceable content, but initially does not include any information about when the start time of the content needs to be played, any indication of the duration of the content to be replaced, or any indication of when the content is to be replaced. The ATSC 3.0 system provides a broadcaster application (app) to be received and launched, and by the mechanism defined in ATSC 3.0, may be able to take the metadata in the reflux, delivering the metadata to the app, where the metadata is typically obscured using schemes known only to the app. The app may be able to interpret the start time and duration from the metadata, as well as know the appropriate time to instruct the receiver to download and cache the RC and the appropriate time to prepare the receiver for the MPD period in which the RC may be replayed. Typically, this last step is immediately before the playback start time of the RC.

In an example implementation, the instructions may be executable to receive information in a hypertext transfer protocol dynamic adaptive streaming (HTTP) (DASH) Media Presentation Description (MPD) segment timeline data structure. Information about the RC may be received in an early usable period (EAP) as described in ISO/IEC 23009-1 (DASH), which contains only extensible markup language (XML) link language (XLink) metadata (no content), content duration, and/or start time. In this case, the broadcaster app may utilize a computer network to interpret the metadata to receive the start time and content duration necessary to replace the content at a future time.

Or may receive information about the RC in an Early Available Period (EAP) that contains only XLink and no content and contains the start time and/or the length of the content in a form that can be read by only the broadcaster app. In this case, the instructions may be executable to receive, at the receiver app, a start time and a content duration in unencrypted form from the broadcaster app, to configure the receiver app to play the RC at the start time.

Likewise, the instructions may be executed to receive an indication of a start time and/or a content duration in an event stream notification contained in a DASH period prior to EAP containing XLink.

In some examples, a plurality of Early Available Periods (EAP) each have XLink associated with a corresponding content duration to be replaced. In response to receiving the indication of the start time, the instructions may be executed to select an EAP having an XLink associated with the duration of the RC.

In another aspect, a digital television system includes at least one broadcast digital television content source and at least one processor configured with instructions executable to transmit information to at least one receiver in a hypertext transfer protocol dynamic adaptive streaming (HTTP) (DASH) Media Presentation Description (MPD) segment timeline data structure. The information is about the Replacement Content (RC) and does not include a start time for playing back the RC and/or a duration of the content to be replaced, or includes the start time and/or the duration in a form that can be read only by a broadcasting application (app) provided by the digital television broadcaster, so that the receiver can use the information to prepare for insertion of the RC and play the RC by receiving an indication about the start time after the insertion of the RC is prepared. The digital television logic may select the alternative content itself (client-side content replacement) or allow the broadcaster application to make the selection (server-side content replacement).

In another aspect, in a digital television system, a method includes receiving information about Replacement Content (RC) that does not include a start time for playing back the RC or a duration of content to be replaced, or includes the start time and the duration in a form that is readable only by a broadcast application (app) provided by a digital television broadcaster. The method includes using the information to prepare for insertion of an RC and receiving an unencrypted indication of a start time after receiving information about the RC. And playing RC at the starting time.

Details of the present application, both as to its structure and operation, can best be understood in reference to the accompanying drawings, in which like reference numerals refer to like parts, and in which:

Drawings

FIG. 1 is a block diagram of an Advanced Television Systems Committee (ATSC) 3.0 system;

FIG. 2 is a block diagram illustrating components of the device shown in FIG. 1;

FIG. 3 illustrates exemplary overall logic in an exemplary flow chart format;

FIG. 4 illustrates exemplary early period of availability (EAP) based logic in an exemplary flowchart format;

FIG. 5 illustrates exemplary event stream based logic in an exemplary flow chart format;

Fig. 6 shows an exemplary portion of a DASH manifest file in which the RC start time is left blank; and

Fig. 7 shows an exemplary portion of a DASH manifest file in which the RC start time is encrypted so that only the broadcaster app can decode and read it.

Detailed Description

The present disclosure relates to technological advances in Advanced Television Systems Committee (ATSC) 3.0 television. The systems herein may include an ATSC 3.0 source component and a client component that are connected via broadcast and/or over a network such that data may be exchanged between the client and the ATSC 3.0 source component. The client component may include one or more computing devices including televisions (e.g., smart TVs, internet enabled TVs), personal computers such as laptops and tablet computers, and mobile devices including smartphones and additional examples discussed below. These client devices may operate in a variety of operating environments. For example, some of the client computers may employ an operating system from Microsoft, or Unix operating system, or an operating system produced by Apple Computer or Google, such asThese operating environments may be used to execute one or more browsing programs, such as a browser made by Microsoft or Google or Mozilla, or other browser programs that may access websites hosted by Internet servers discussed below.

The ATSC 3.0 source component may comprise a broadcast transport component and a server and/or gateway that may include one or more processors executing instructions that configure the source component to broadcast data and/or transmit data over a network such as the internet. The client component and/or the native ATSC 3.0 source component may be made of, for example, sonyEtc. game hosts, personal computers, etc.

Information may be exchanged between the client and the server over a network. To this end and for security purposes, the server and/or client may include firewalls, load balancers, temporary storage and proxies, as well as other network infrastructure for reliability and security.

"Instructions" as used herein refers to computer-implemented steps for processing information in a system. The instructions may be implemented in software, firmware, or hardware and include any type of programming steps taken by the components of the system.

The processor may be any conventional general purpose single-chip or multi-chip processor and the logic may be implemented by various lines such as address lines, data lines, and control lines, as well as registers and shift registers.

The software modules described herein by flow charts and user interfaces may include various subroutines, procedures, and the like. Without limiting the disclosure, the logic stated as being performed by a particular module may be redistributed to other software modules and/or combined together in a single module and/or made available in a shareable library. Although a flowchart format may be used, it should be understood that software may be implemented as a state machine or other logic method.

The present principles described herein may be implemented as hardware, software, firmware, or a combination thereof; thus, the illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality.

In addition to the foregoing, the logic blocks, modules, and circuits may be implemented or performed with a general purpose processor, a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA) or other programmable logic device such as an Application Specific Integrated Circuit (ASIC), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A processor may be implemented by a controller or a combination of state machines or computing devices.

When implemented in software, the functions and methods described below may be written in a suitable language such as, but not limited to, hypertext markup language (HTML) -5,Javascript, c# or c++, and may be stored on or transmitted through a computer-readable storage medium, such as Random Access Memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disk storage such as Digital Versatile Disks (DVD), magnetic disk storage or other magnetic storage devices including removable thumb drives, and the like. The connection may establish a computer readable medium. Such connections may include, for example, hardwired cables, including fiber optic and coaxial cables, and Digital Subscriber Lines (DSL) and twisted pairs.

Components included in one embodiment may be used in other embodiments in any suitable combination. For example, any of the various components described herein and/or depicted in the figures may be combined, interchanged, or excluded from other embodiments.

"A system having at least one of A, B and C" (likewise, "a system having at least one of A, B or C" and "a system having at least one of A, B, C") includes a system having only a, only B, only C, both a and B, both a and C, both B and C, and/or both A, B and C.

Referring to fig. 1, an example of an ATSC 3.0 source component is labeled "broadcaster equipment" 10 and may include Over The Air (OTA) equipment 12 for broadcasting television data wirelessly, typically in a one-to-many relationship, by Orthogonal Frequency Division Multiplexing (OFDM) to a plurality of receivers 14, such as ATSC 3.0 television. One or more receivers 14 may communicate with one or more companion devices 16, such as remote controls, tablet computers, mobile phones, etc., over a short distance, typically by way of a wireless communication linkLow power Bluetooth, other Near Field Communication (NFC) protocols, infrared (IR), etc.

Further, one or more of the receivers 14 may communicate with over-the-top (OTT) equipment 22 of the broadcaster equipment 10, typically in a one-to-many relationship, via wired and/or wireless network links 20, such as the internet. The OTA equipment 12 may be co-located with the OTT equipment 22 or both sides 12, 22 of the broadcaster equipment 10 may be remote from each other and communicate with each other by suitable means. In any event, receiver 14 may receive an ATSC 3.0 television signal OTA by tuning to an ATSC 3.0 television service and may also receive related content including television over an OTT (wideband) path. It should be noted that the computerized devices depicted in all of the figures herein may include some or all of the components set forth for the various devices in fig. 1 and 2.

Referring now to FIG. 2, details of the components shown in FIG. 1 can be seen. Fig. 2 illustrates a protocol stack that may be implemented by a combination of hardware and software. As discussed below, using the ATSC 3.0 protocol stack shown in fig. 2 and appropriately modified for the broadcaster side, the broadcaster may send a hybrid service delivery in which one or more program units are delivered over a computer network (referred to herein as "broadband" and "over the top" (OTT)) and over the air (referred to herein as "broadcast" and "over the air").

The broadcaster equipment 10 may include one or more processors 200 that access one or more computer storage media 202, such as any memory or storage device described herein, to provide one or more software applications in a top application layer 204. The application layer 204 may include one or more software applications running in a runtime environment, for example written in HTML 5/Javascript. Without limitation, applications in the application stack 204 may include a linear TV application, an interactive service application, a companion screen application, a personalization application, an emergency alert application, and a usage reporting application. The applications are typically embodied in software that represents the units experienced by the viewer, including video coding, audio coding, and runtime environments. As an example, applications may be provided that allow a user to control dialog, use alternate audio tracks, control audio parameters such as normalization and dynamic range.

Below the application layer 204 is a presentation layer 206. The presentation layer 206 includes a broadcast audio-video playback device on the broadcast (OTA) side called a Media Processing Unit (MPU) 208 that, when implemented in a receiver, decodes and plays back the wirelessly broadcast audio-video content on one or more displays and speakers. The MPU 208 is configured to present an International Standardization Organization (ISO) Basic Media File Format (BMFF) data representation 210 and video in High Efficiency Video Coding (HEVC) with audio input (e.g., dolby Audio Compression (AC) -4 format). ISO BMFF is a generic file structure for time-based media files that are broken down into "clips" and presentation metadata. Each file is essentially a collection of nested objects each having a type and a length. To facilitate decryption, the MPU 208 may access a broadcast side Encrypted Media Extension (EME)/Common Encryption (CENC) module 212.

Fig. 2 also shows that on the broadcast side, the presentation layer 206 may include a signaling module including a Moving Picture Experts Group (MPEG) media transport protocol (MMTP) signaling module 214 or a real-time object delivery over unidirectional transport (ROUTE) signaling module 216 for delivering non-real-time (NRT) content 218 accessible to the application layer 204. NRT content may include, but is not limited to, stored replacement advertisements.

On the broadcast (OTT or computing network) side, when implemented by a receiver, presentation layer 206 may include one or more hypertext transfer protocol dynamic adaptive streaming (HTTP) (DASH) player/decoders 220 for decoding and playing audio-video content from the internet. To this end, DASH player 220 may access broadband side EME/CENC module 222.DASH content may be provided as DASH segments 224 in ISO/BMFF format.

As is the case for the broadcast side, the broadband side of the presentation layer 206 may include NRT content in the file 226 and may also include a signaling object 228 for providing playback signaling.

Below presentation layer 206 in the protocol stack is session layer 230. The session layer 230 includes an MMTP protocol 232 or a ROUTE protocol 234 on the broadcast side. It should be noted that the ATSC standard provides the option of using MPEG MMT for transmission, although not shown here.

On the broadband side, the session layer 230 includes the HTTP protocol 236, which may be implemented as secure HTTP (S)). The broadcast side of the session layer 230 may also employ an HTTP proxy module 238 and a Service List (SLT) 240. The SLT 240 includes a table of signaling information used to build a basic service list and provide guided discovery of broadcast content. The Media Presentation Description (MPD) is included in a "ROUTE signaling" table delivered over User Datagram Protocol (UDP) via ROUTE transport protocol.

Transport layer 242 is below session layer 230 in the protocol stack for establishing low latency and lossy connections. On the broadcast side, the transport layer 242 uses UDP 244 and on the broadband side uses Transmission Control Protocol (TCP) 246.

The protocol stack also includes a network layer 248 below the transport layer 242. The network layer 248 uses Internet Protocol (IP) for IP packet communications on both sides, typically multicast delivery on the broadcast side and unicast on the broadband side.

Below the network layer 248 is a physical layer 250, the physical layer 250 including a send/receive equipment 252 and computer network interface(s) 254 for communicating over corresponding physical media associated with both sides. The physical layer 250 converts the Machine Access Code (MAC) format to be suitable for transmission over the relevant medium and may add forward error correction functionality to allow error correction at the receiver and include modulation and demodulation modules to combine the modulation and demodulation functionality. This converts bits into symbols for long-range transmission and improves bandwidth efficiency. On the OTA side, the physical layer 250 typically includes a radio transmitter to radio data using Orthogonal Frequency Division Multiplexing (OFDM), and on the OTT side the physical layer 250 includes a computer transmission component to transmit data over the internet.

DASH industry forum (DASH-IF) profiles sent over various protocols (HTTP/TCP/IP) in the protocol stack may be used on the broadband side. Media files in the ISO BMFF based DASH-IF profile may be used as delivery, media encapsulation and synchronization formats for both broadcast and broadband delivery.

Each receiver 14 typically includes a protocol stack complementary to the broadcaster equipment.

As shown in fig. 2, the receiver 14 in fig. 1 may include an internet enabled TV having an ATSC 3.0TV tuner (equivalently a set top box that provides an audiovisual display to a TV monitor) 256. The software architecture in the receiver 14 may be based onAn operating system. The receiver 14 may alternatively be implemented by a computerized internet enabled ("smart") phone, tablet computer, notebook computer, wearable computerized device, or the like. Regardless, it should be appreciated that the receiver 14 and/or other components described herein are configured to implement the present principles (e.g., communicate with other devices to implement the present principles, perform the logic described herein, and implement any other functions and/or operations described herein).

Accordingly, to implement such principles, the receiver 14 may be established by some or all of the components shown in fig. 1. For example, the receiver 14 may include one or more displays 258 that may be implemented by a high-definition or ultra-high-definition "4K" or higher flat screen, and may or may not have touch functionality for receiving user input signals via touches on the display. The receiver 14 may also include one or more speakers 260 for outputting audio in accordance with the present principles, and at least one additional input device 262, such as an audio receiver/microphone for inputting audible commands to the receiver 14 to control the receiver 14. The exemplary receiver 14 may also include one or more network interfaces 264 for communicating over at least one network, such as the internet, WAN, LAN, PAN, etc., under the control of one or more processors 266. Thus, interface 264 may be, but is not limited to, a Wi-Fi transceiver as an example of a wireless computer network interface, such as, but not limited to, a mesh network transceiver, and the like. Interface 264 may be (without limitation)A transceiver(s),Transceivers, infrared data association (IrDA) transceivers, wireless USB transceivers, wired USB, wired LAN, powerline, or multimedia over coax alliance (MoCA). It should be appreciated that the processor 266 controls the receiver 14 to implement the present principles, including other elements of the receiver 14 described herein, such as controlling the display 258 to present images and receive inputs. It should also be noted that the network interface 264 may be, for example, a wired or wireless modem or router or other suitable interface, such as a wireless telephone transceiver or the aforementioned Wi-Fi transceiver, etc.

In addition to the foregoing, the receiver 14 may also include one or more input ports 268 to physically connect (using a wired connection) to another CE device, such as a High Definition Multimedia Interface (HDMI) port or a USB port, etc., and/or a headset port to connect a headset to the receiver 14 in order to present audio from the receiver 14 to a user through the headset. For example, the input port 268 may be connected by wire or wirelessly to a cable television or satellite source of audio video content. Thus, the source may be a separate or integrated set top box, or a satellite receiver. Or the source may be a game host or a disc player.

The receiver 14 may also include one or more computer memories 270, such as disk-based or solid state storage that is not a transient signal, in some cases embodied in the housing of the receiver as a stand-alone device, or as a personal video recording device (PVR) or video disk player, either internal or external to the housing of the receiver, for playback of Audio Video (AV) programs, or as a removable memory medium. Further, in some embodiments, the receiver 14 may include a position or orientation receiver 272, such as, but not limited to, a cellular telephone receiver, a Global Positioning Satellite (GPS) receiver, and/or an altimeter, configured to receive geographic location information, for example, from at least one satellite or cellular telephone tower, and provide the information to the processor 266 and/or in conjunction with the processor 266 determine the altitude at which the receiver 14 is located. It should be understood that other suitable position receivers other than a cellular telephone receiver, a GPS receiver, and/or an altimeter may be used in accordance with the present principles to determine the orientation of the receiver 14 in, for example, all three dimensions.

Continuing with the description of the receiver 14, in some embodiments, the receiver 14 may include one or more cameras 274, which may include one or more of a thermal imaging camera, a digital camera such as a webcam, and/or a camera integrated into the receiver 14, and may be controlled by the processor 266 to collect photos/images and/or video in accordance with the present principles. Also included on the receiver 14 isTransceiver 276 or other Near Field Communication (NFC) unit for separate useAnd/or NFC technology with other devices. An exemplary NFC unit may be a Radio Frequency Identification (RFID) unit.

Further, the receiver 14 may include one or more auxiliary sensors 278 (motion or magnetic sensors such as accelerometers, gyroscopes, gyrators, and the like, and combinations thereof), infrared (IR) sensors for receiving IR commands from a remote control, optical sensors, speed and/or cadence sensors, gesture sensors (for sensing gesture commands), and the like, which provide inputs to the processor 266. IR sensor 280 may be provided to receive commands from a wireless remote control. A battery (not shown) may be provided for powering the receiver 14.

Companion device 16 may incorporate some or all of the elements shown with respect to the previously described receiver 14.

The methods described herein may be implemented as software instructions executed by a processor, as an Application Specific Integrated Circuit (ASIC) or Field Programmable Gate Array (FPGA) module, as appropriate, or in any other convenient manner as will be appreciated by those skilled in the art. When employed, the software instructions may be embodied in a non-transitory device such as a CD ROM or flash drive. The software code instructions may alternatively be embodied in a transient arrangement such as a radio or optical signal, or downloaded over the internet.

Prior to referring to fig. 3, in ATSC 3.0, MPEG DASH is used to transmit AV content, which may contain alternative content (RC) such as advertisements or content intended for personalized replacement by a user. Multiple periods with XLink tags are used by ATSC 3.0 to signal the location of such an RC (as discussed in ATSC a/344). As understood herein, however, this may give advance notice of the location of the RC that can be easily skipped by the client, and thus not friendly to the broadcaster's business model. The present principles may utilize SEGMENTTIMELINE unit MPEG DASH MPD that delivers just-in-time (JIT) information in a DASH manifest file (with each additional segment updating the MPD). The JIT information prevents the advance knowledge of new time periods until the last minute and eliminates the easy-to-resolve RC replacement strategy of "bad" receivers. It should be appreciated that XLink is an early notification that tells the broadcaster that an application (an application provided from the broadcaster and running on the client receiver's HTML5 service) will need to call the client receiver to cache the content and prepare to replace the existing content. Since XLink is attached to the period to be replaced, knowing XLink in advance may allow skipping if XLink contains the RC start time of the plaintext and/or the duration of the content to be replaced.

To address this issue, XLink may be sent in an early period without a start time, as further explained below. In DASH this is called Early Available Period (EAP), see ISO/IEC 23009-1.EAP is allowed to have metadata in a Period (Period) tag but not the start time or duration of the content to be replaced, or at least the start time or duration of the plaintext, that is to say in unencrypted or uncorrupted form. Thus, by using SEGMENTTIMELINE, the start time of the EAP need only be the revealed JIT (with the most recent MPD update), resulting in insufficient time to implement the RC skip strategy. EAP may be used at any time to reveal the XLink itself to allow for preparation time for content replacement.

Reference is now made to fig. 3. Beginning at block 300, information regarding Replacement Content (RC), such as a replacement advertisement tailored to a particular user of a particular receiver, is sent from a broadcaster in advance for storage by the receiver. The replacement content may also be made available to the receiver in advance (in a cached advertisement replacement system). In an exemplary embodiment, the information may include XLink. But the information does not include the start time of the RC and the duration of the content to be replaced, or at least does not include an unencrypted or unblurred version of the start time.

Moving to block 302, a waiting period is entered (or triggered from the program guide or broadcast studio equipment) such that the start time is revealed to components of the receiver other than the broadcaster app at block 304 just prior to the start time of the RC. In general, the start time is revealed after a certain time of revealing information about the RC, and may be revealed just a few milliseconds or seconds before the start time, so that the cracked receiver does not have enough time to perform the skip strategy. The start time and/or duration of the content to be replaced may be revealed by sending the start time/duration out of band to the receiver or by other techniques described herein, or may be revealed by the broadcaster app receiving the start time/duration in encrypted or otherwise obscured form along with XLink, and simply not letting the rest of the components of the receiver provide a clear text indication about the start time/duration until immediately before the start time.

Fig. 4 shows a specific technique. Beginning at block 400, one or more EAPs with respective XLink are sent with an encryption start time and, if desired, an encryption duration of content to be replaced. XLink is provided to the necessary components instead of start time/duration to allow the receiver to parse XLink at block 402 in preparation for RC insertion. The broadcaster app may decode the start time at block 404 but not share with other components of the receiver. At block 405, the broadcaster app may prepare for content replacement by instructing the receiver to cache OTA content or obtain and cache from OTT, or make content available from the OTT server without caching, and then pass the instructions to replace the period containing XLink at the appropriate time. At block 406, the broadcaster reveals the start time of the RC to the receiver in EAP, which then becomes the new period to be played. At block 407, the receiver replaces the period with an RC period if previously instructed to do so.

Block 408 shows that multiple EAP's may be used, each with its own duration that is known only to the broadcaster app by decoding XLink. In other words, multiple EAP's may be signaled in the DASH manifest file, each with its own XLink and each allowing for caching of different types or durations of RC, so that the broadcaster may choose the JIT of EAP to be populated with subsequent over-the-air AV clips depending on what is ultimately needed to be replaced. If the selection matches one of the xlink of the replacement content of the notified cache, the receiver will replace it at this time.

Block 410 indicates whether the original or alternate RC period was played by the receiver at the start time.

Fig. 5 illustrates an alternative technique. Part or all of the RC information, including an indication of type, duration and start time, is carried in the event stream notification and sent to the receiver. Details of DASH event stream notification can be found in ATSC a/344. Event stream notifications are added to the period of current play to signal to the broadcaster app (using ATSC 3.0 signaling method) the type and duration of the alternative content that will soon appear. The broadcaster app is notified of this information and may then cache the RC at block 502. The client receiver does not know when the replacement start time will occur until the JIT at block 504 to allow the RC to be played at the start time at block 506.

Fig. 6 shows a segment timeline slot 600 with a start time 602 and without data. The period 600 contains only metadata such as XLink and does not contain content. The period 600 may also omit the duration of the content to be replaced.

On the other hand, fig. 7 shows a segment timeline slot 700 with an encryption start time 702. Period 700 contains only metadata such as XLink and does not contain content. Period 700 may also include the duration of the content to be replaced in encrypted form.

SEGMENTTIMELINE are ideal for ambiguous content because DASH manifests need to be refreshed continuously and at the correct time. This places a heavy burden on the recording and playback of the client receiver, a technique that also allows for pausing of live TV. Pause and recording is a way that clients can allow higher-order knowledge about content, but SEGMENTTIMELINE places a heavy burden on them.

The techniques herein may be implemented by ATSC 3.0 and possibly by DASH IOP. The client implementation may require the client receiver to support EAP from the MPEG DASH main standard in a clip timeline mode.

A more detailed multi-slot timeline DASH manifest file is set forth below, where the EAP shown contains xlink metadata intended to be interpreted only by the broadcaster app. The receiver expects to notify xlink when it first occurs, where the broadcaster app then decides what to do, caches OTT, caches OTA, prepares for live OTT replacement, or does not replace at all. The broadcaster app then instructs the receiver to perform a caching action and prepare for period replacement as needed:

A multi-period dynamic MPD is now described in which EAP is replaced by a non-null period containing the most recent segment delivered OTA along the start time of the period. The receiver may have been instructed by the broadcaster app to replace the period with a replacement period for the replaced content. Receivers that are not instructed to replace the period will continue to play back into the period as usual. The earlier segments disappear from the first period while the second period is filled with the latest "live" segments. In the event that xLink for the RC was told in the past and was previously instructed to replace this period, the receiver now sees the start time within the period being used to play the alternative content, the MPD will be edited on the receiver to ensure that the replaced content is played instead of the segment delivered by the OTA. In the third MPD herein, another multi-period with period id p14 becomes a new period for the broadcaster to start filling. The periods id p13 and p14 have a start time, the difference between which defines the duration of p13, which should perfectly match the replaced content for seamless playback. To ensure this match, the duration may have been encoded in xLink for interpretation by the broadcaster app, or the broadcaster app may contact the OTT server to obtain the duration:

the period containing the replaceable content has elapsed and a new non-replaceable period appears at the live point:

It should be appreciated that while the present principles have been described above with reference to some exemplary embodiments, these exemplary embodiments are not intended to be limiting and that various alternative arrangements may be used to implement the subject matter claimed herein.

Claims (20)

1. A digital television system, comprising:

at least one receiver of digital television content having segment timeline signaling, wherein the receiver is programmed with instructions to configure the receiver to:

Receiving information about alternative content (RC), the information not including a start time for playing the RC or including the start time in a form that can be read only by a broadcasting application (app) provided by a digital television broadcaster;

receiving an indication of the start time immediately prior to the start time; and

And playing RC at the starting time.

2. The system of claim 1, wherein the instructions are executable to:

the information is received in a hypertext transfer protocol dynamic adaptive streaming (HTTP) (DASH) Media Presentation Description (MPD) segment timeline time-based data structure.

3. The system of claim 2, wherein the information is received in an Early Available Period (EAP) that contains only metadata and no content or a start time or duration of content to be replaced.

4. The system of claim 3, wherein the instructions are executable to receive an indication of the start time from a computer network.

5. The system of claim 2, wherein the information is received in an Early Available Period (EAP) that contains only metadata and no content and contains an indication of the start time in a form that is readable only by a broadcaster app.

6. The system of claim 5, wherein the instructions are executable to receive, in unencrypted form, at the receiver app from the broadcaster app at least an indication of the start time to configure the receiver app to play the RC at the start time.

7. The system of claim 1, wherein the instructions are executable to receive an indication of the start time in an event stream notification contained in a DASH period.

8. The system of claim 2, wherein the instructions are executable to:

Receiving a plurality of early periods of availability (EAP) each associated with a corresponding extensible markup language (XML) link language (XLink), each XLink associated with a corresponding duration; and

EAP is selected with XLink associated with the duration of the RC.

9. A digital television system, comprising:

At least one source of broadcast digital television content; and

At least one processor configured with instructions executable to perform operations comprising:

Information is sent to at least one receiver in a hypertext transfer protocol dynamic adaptive streaming (HTTP) (DASH) Media Presentation Description (MPD) segment timeline time-based data structure, the information about alternative content (RC) not including a start time for playing the RC, or in a form that can be read only by a broadcast application (app) provided by a digital television broadcaster, such that the receiver can use the information to prepare for insertion of the RC and play the RC by receiving an indication of the start time after preparation of insertion of the RC.

10. The digital television system of claim 9, wherein the information is transmitted in an Early Available Period (EAP) that contains only metadata and no content or start time.

11. The digital television system of claim 10, wherein the instructions are executable to send an indication of the start time to a receiver using a computer network.

12. The digital television system of claim 9, wherein the information is transmitted in an Early Available Period (EAP) that contains only metadata and no content and that contains the start time in a form that is readable only by a broadcaster app in the receiver.

13. The digital television system of claim 9, wherein the instructions are executable to send an indication of the start time in an event stream notification contained in a DASH period.

14. The digital television system of claim 9, wherein the instructions are executable to:

Transmitting to the receiver a plurality of early periods of availability (EAP) each associated with a corresponding extensible markup language (XML) link (XLink), each XLink associated with a corresponding duration; and

An indication of the length is sent to the receiver to enable the receiver to select an EAP having an XLink associated with the duration of the RC.

15. In a digital television system, a method comprising:

Receiving information about alternative content (RC), the information not including a start time for playing the RC or including the start time in a form that can be read only by a broadcasting application (app) provided by a digital television broadcaster;

receiving the start time after receiving the information about RC; and

And playing RC at the starting time.

16. The method of claim 15, comprising:

the information is received in a hypertext transfer protocol dynamic adaptive streaming (HTTP) (DASH) Media Presentation Description (MPD) segment timeline time-based data structure.

17. The method of claim 16, comprising receiving the information in an Early Available Period (EAP) that contains only metadata and no content or indication of the start time.

18. The method of claim 17, comprising receiving an indication of the start time from a computer network.

19. The method of claim 16, comprising receiving the information in an Early Available Period (EAP) that contains only metadata and no content and the start time in a form that can only be read by a broadcaster app, and receiving the start time at a receiver app from the broadcaster app in unencrypted form to configure the receiver app to play an RC at the start time.

20. The method of claim 16, comprising receiving an indication of the start time in an event stream notification contained in a DASH period.