Time-shifted playback

Abstract

To provide an apparatus, a computer readable medium and a method that allow time-shifted playback with interactive content available during a live broadcast.SOLUTION: A reception apparatus includes receiver circuitry configured to receive a broadcast stream that includes (i) a first broadcaster service selected by a user and (ii) a second broadcaster service. The reception apparatus further includes a demodulator configured to demodulate the broadcast stream into a plurality of data packets. The reception apparatus further includes processing circuitry configured to: store the plurality of data packets corresponding to the first and second broadcaster services in a pause buffer; process each data packet associated with the selected first broadcaster service to extract audio and video content; and output, as part of a live TV broadcast, the extracted audio and video content associated with the first broadcaster service to the user during a first time period.SELECTED DRAWING: Figure 10

Description

[Technical Field]

[0001] The present disclosure relates to an apparatus, computer-readable medium, and method for enabling time-shifted playback with interactive content available during a live broadcast. [Background technology]

[0002] Generally, a personal video recorder (PVR) allows a user to enjoy playback of previously recorded content. To fully enjoy the features of a personal video recorder (PVR), a user can choose to capture live broadcast programs into memory for later viewing. Data in an electronic program guide (EPG) identifies the service, time, and duration of the program. When the program is scheduled to be broadcast, the receiver tunes to the indicated service and begins saving media segments to persistent storage. When the user returns later, or even if the program is being recorded, these media segments can be provided to the media engine for decoding and presentation. Additionally, trick play modes such as pause, fast forward, and rewind can be provided during playback.

[0003] In typical live TV operation, media segments (e.g., MPEG DASH media segments or MPEG MMT media processing units [MPUs]) are collected and buffered long enough to be fed to a media engine for decoding and presentation. If the receiver includes PVR functionality, these media segments can be buffered for later viewing. For example, DTVs can provide a "pause live TV" feature.

[0004] Furthermore, content playback with precise audio and video time synchronization is essential for television viewing. Advanced Television Systems Committee (ATSC) 3.0 receivers can be written as dedicated applications that run on a software operating system (OS) platform. For the example OS platform "Android TV," an ATSC 3.0 application, an example of a television receiver application, is written as an Android application within a digital television (DTV) product that supports the OS, allowing application designers to access the features and functionality of the Android OS through standard system calls.

[0005] To acquire and present a live television broadcast, the television receiver application can receive and process signaling associated with the selected service, examine the service's MPEG DASH Media Presentation Description (MPD) file, and process the Availability Start Time (AST) parameters in the MPD to determine which media segment files (e.g., a separate file for the time segment and a set of separate files for audio, video, and captions) were most recently transmitted. By selecting from among these files, the television receiver application can join the live broadcast with the lowest latency (implementing "fast channel change").

[0006] The MPEG DASH standard (ISO / IEC 23009-1) defines the AST as a UTC time that signals "anchor for calculating the earliest availability time (in UTC) of any segment in a media presentation." The MPEG DASH standard is described in ISO / IEC 23009-1:2014, "Information technology - Dynamic Adaptive Streaming over HTTP (DASH) - Part 1: Media presentation description and segment formats," International Organization for Standardization, 15 May 2014 (hereinafter "MPEG DASH Standard"), the contents of which are incorporated by reference in their entirety. The AST is the only time specified in absolute format in the MPD; all other times in the MPD are relative to the AST's anchor point. [Prior art documents] [Non-patent literature]

[0007] [Non-Patent Document 1] "Guidelines for Implementation: DASH-IF Interoperability Points," Dash Industry Forum, V.4.1, September 7, 2017 Summary of the Invention [Means for solving the problem]

[0008] According to an embodiment of the present disclosure, there is provided a receiving device including a receiver circuit configured to receive a broadcast stream including (i) a first broadcast station service selected by a user and (ii) a second broadcast station service. The receiving device further includes a demodulator configured to demodulate the broadcast stream into a plurality of data packets. The receiving device further includes a processing circuit configured to store the plurality of data packets corresponding to the first and second broadcast station services in a pause buffer, process each data packet associated with the selected first broadcast station service to extract audio and video content, and output the extracted audio and video content associated with the first broadcast station service to a user as part of a live TV broadcast during a first time period.

[0009] According to an embodiment of the present disclosure, there is provided a receiving device including a receiver circuit configured to receive a broadcast stream including a broadcast station service selected by a user. The receiving device further includes a demodulator configured to demodulate the broadcast stream into a plurality of data packets. The receiving device stores the plurality of data packets in a pause buffer, processes each data packet related to the selected broadcast station service to extract audio and video content, and outputs the extracted audio and video content to a user as part of a live TV broadcast during a first time period. During a second time period subsequent to the first time period, the receiving device receives a user input indicating a request to generate audio and video content related to the first broadcast station service available during an intermediate time period between the first time period and the second time period. The receiving device retrieves data packets related to the audio and video content available during the intermediate time period from the pause buffer. The data packets retrieved from the pause buffer are processed to extract the audio and video content available during the intermediate time period, and output the audio and video content available during the intermediate time period as part of a time-shifted playback. During the time-shifted playback of the audio and video content available during the intermediate time period, the receiving device performs at least one Content Service Functions and further comprising a processing circuit configured to provide at least one Content Service Functionsare contained in multiple data packets that are stored in and retrieved from the pause buffer.

[0010] According to an embodiment of the present disclosure, a receiving device is provided, the receiving device including a receiver circuit configured to receive a broadcast stream including a broadcast station service selected by a user. The receiving device further includes a demodulator configured to demodulate the broadcast stream into a plurality of data packets. The receiving device further includes a processing circuit configured to determine an operating system time, process the data packets to determine a signaled availability start time (AST) of television content associated with the broadcast station service, determine an expected reception time of media segments corresponding to the television content based on the signaled AST, determine an actual reception time of the media segments corresponding to the television content, determine an observed AST representing the sum of the signaled AST and a difference between the reception time of the media segment and the expected reception time of the media segment, determine a playback time offset from the operating system time according to the observed AST, and output audio and video content associated with the received broadcast station service according to the determined playback time.

[0011] According to an embodiment of the present disclosure, there is provided a non-transitory computer-readable medium having stored thereon instructions that, when executed by a processor in a receiving device, cause the processor to perform a method, the method including storing in a pause buffer a plurality of data packets corresponding to a first broadcast station service and a second broadcast station service selected by a user, the first and second broadcast station services being received in a broadcast stream demodulated into a plurality of data packets, the method further including processing each data packet associated with the selected first broadcast station service to extract audio and video content, and outputting the extracted audio and video content associated with the first broadcast station service to the user as part of a live TV broadcast during a first time period.

[0012] According to an embodiment of the present disclosure, a non-transitory computer-readable medium having stored thereon instructions that, when executed by a processor in a receiving device, cause the processor to perform a method, the method including: processing each data packet associated with a selected broadcast station service to extract audio and video content; outputting the extracted audio and video content to a user during a first time period as part of a live TV broadcast; receiving, during a second time period subsequent to the first time period, a user input indicating a request to generate audio and video content associated with the first broadcast station service that is available during an intermediate time period between the first time period and the second time period; retrieving data packets associated with the audio and video content that is available during the intermediate time period from a pause buffer; processing each data packet retrieved from the pause buffer to extract the audio and video content that is available during the intermediate time period; and outputting the audio and video content that is available during the intermediate time period as part of a time-shifted playback; and during the time-shifted playback of the audio and video content that is available during the intermediate time period, Content Service Functions and providing at least one Content Service Functions is included in a plurality of data packets that are stored in and retrieved from a pause buffer.

[0013] According to an embodiment of the present disclosure, there is provided a non-transitory computer-readable medium having stored thereon instructions that, when executed by a processor in a receiving device, cause the processor to perform a method, the method including: processing data packets demodulated from a received broadcast stream to determine a signaled availability start time (AST) of television content associated with a broadcast station service included in the received broadcast stream; determining an expected reception time of a media segment corresponding to the television content based on the signaled AST; determining an actual reception time of the media segment corresponding to the television content; determining an observed AST representing the sum of the signaled AST and a difference between the reception time of the media segment and the expected reception time of the media segment; determining a playback time offset from an operating system time according to the observed AST; and outputting audio and video content associated with the received broadcast station service according to the determined playback time.

[0014] A more complete understanding of the present disclosure and many of the attendant advantages will be readily obtained as the same becomes better understood by reference to the following detailed description considered in conjunction with the accompanying drawings, in which: [Brief explanation of the drawings]

[0015] [Figure 1] FIG. 1 illustrates an exemplary digital television broadcast system. [Figure 2] FIG. 1 illustrates an exemplary receiving device. [Figure 3] FIG. 2 is a processor-centric block diagram of an exemplary receiving device. [Figure 4] FIG. 1 illustrates an exemplary broadcast stream. [Figure 5] FIG. 1 illustrates an exemplary database structure within a pause buffer. [Figure 6] FIG. 1 illustrates an exemplary display including an electronic program guide. [Figure 7]FIG. 1 illustrates an illustrative time-shifted viewing example. [Figure 8] FIG. 1 illustrates an exemplary display including multiple content service features. [Figure 9] FIG. 1 illustrates an exemplary relationship between the operating system clock and media arrival time seconds. [Figure 10] FIG. 1 illustrates an exemplary process performed by a receiving device. [Figure 11] FIG. 1 illustrates an exemplary process performed by a receiving device. [Figure 12] FIG. 2 illustrates an example of the hardware configuration of a computer. DETAILED DESCRIPTION OF THE INVENTION

[0016] While the present disclosure is susceptible of embodiment in many different forms, specific embodiments are shown in the drawings and described in detail herein, and it should be understood that the disclosure of such embodiments is to be considered as an example of the present principles and is not intended to limit the disclosure to the specific embodiments shown and described.

[0017] The term "a" or "an" as used herein is defined as one or more than one. The term "multiple" as used herein is defined as two or more than two. The term "another" as used herein is defined as at least a second or more. The terms "including" and / or "having" as used herein are defined as "comprising" (i.e., open language). The term "coupled" as used herein is defined as "connected," although not necessarily directly, and not necessarily mechanically. The terms "program" or "computer program" or similar terms as used herein are defined as a set of instructions designed to be executed on a computer system. A "program" or "computer program" may include subroutines, program modules, scripts, functions, procedures, object methods, object implementations in executable applications, applets, servlets, source code, object code, scripts, program modules, shared libraries / dynamic load libraries, and / or other sets of instructions designed to be executed on a computer system.

[0018] The term "program" as used herein can also be used in a second context (the above definition being the first context). In the second context, the term is used to mean a "television program." In this context, the term is used to mean any coherent series of audio-video content, such as that which is interpreted as a single television program and conveyed in an electronic program guide (EPG), regardless of whether this content is a movie, a sporting event, a segment of a series, a news broadcast, etc. The term can also be interpreted to include commercial spots and other program-like content that may not be conveyed as a program in an EPG.

[0019] Throughout this specification, references to "one embodiment," "some embodiments," "an embodiment," "an implementation," "an example," or similar terms mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of such phrases in various places throughout this specification do not necessarily all refer to the same embodiment. Furthermore, these particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments, without limitation.

[0020] The term "or" as used herein should be construed as inclusive, i.e., meaning either one or any combination. Thus, "A, B, or C" means any of "A, B, C, A and B, A and C, B and C, A, B and C." Exceptions to this definition occur only when combinations of elements, features, steps, or acts are inherently mutually exclusive in some respect.

[0021] Referring now to the drawings, in which like reference numerals indicate identical or corresponding parts throughout the several views, the following description relates to providing access to protected content.

[0022] Embodiments of the present disclosure disclose implementing a PVR in a television receiving device (e.g., an ATSC 3.0 receiver) that provides multiple novel features over traditional PVR capabilities, including support during time-shifted playback of any interactive features that a broadcaster may have provided during a live broadcast. Users can enjoy different presentation options, such as audio tracks or captions in different languages, during program playback. Embodiments of the present disclosure further include storing audio / video / caption / application data from a broadcast in the form of Internet Protocol (IP) packets or ATSC 3.0 Link Layer Protocol (ALP) packets as described in ATSC Standard A / 300-ATSC 3.0 System, dated October 19, 2017, which is incorporated herein by reference in its entirety (hereinafter, the "A / 300 Standard").

[0023] Embodiments of the present disclosure relate to adding features to a receiver, including PVR capabilities such as: (1) The ability to interact with a program during time-shifted playback as if the program were broadcast live. (2) The availability of recordings of multiple audio languages ​​or video tracks so that the user can select the desired presentation of the recorded program as if the program were broadcast live. (3) Conventional receivers only buffer the service that the user is currently watching, whereas ATSC 3.0 broadcasts can buffer multiple services in a "pause buffer" when the broadcast contains multiple sub-channels.

[0024] For example, the ATSC 3.0 broadcast protocol allows program elements such as audio, video, captions, and applications to be delivered in separate file-based content streams. A PVR design that stores all available program elements provides viewers with the ability to select their desired presentation during playback, just as if they were watching the program live in real time (as opposed to time-shifted). Furthermore, a program can be played back with one or more elements selected differently than before (e.g., different languages ​​or viewing angles can be played during repeated playback of the same content).

[0025] In some embodiments, television receivers operate in a "runtime application environment" that allows broadcasters to provide broadcaster applications (e.g., HTML5 applications) that can be launched simultaneously with the program being viewed. Broadcaster applications can run quietly in the background to perform tasks such as service usage monitoring or personalized advertising, or they can provide text and graphics to the user so that the user can interact with the program content. Designers of broadcaster applications can take advantage of a rich set of television-related features, including the ability to design broadcaster applications to select different services, different audio, video, or caption tracks, and the ability to have the video presentation scaled and positioned on the screen.

[0026] For example, if the receiver is built on the Android platform, the broadcaster may provide a native broadcaster application (e.g., an Android application) that cooperates with or replaces the broadcaster application delivered in the broadcast signal, as described in patent application Ser. No. [Insert Application Number], entitled Receiver Device Including Native Broadcaster Application, filed on [Insert Date], the contents of which are incorporated herein by reference in their entirety. Either or both of the broadcaster application or the native broadcaster application may provide an interactive experience for the user.

[0027] Embodiments of the present disclosure also include a method for deriving "wall clock time" in a receiver based on analysis of MPD files provided by a broadcaster. To process the AST and utilize it for fast service acquisition, the receiver can compare the signaled AST value with the time specified by the receiver's operating system to calculate which media segment(s) have just become available. These are files that have just arrived at the receiver; that is, if the receiver begins by decoding and presenting these just-arrived files, the receiver will have joined the service at the so-called "live edge." The DASH Interoperability Forum (DASH-IF) has published a guideline document for DASH implementation in "Guidelines for Implementation: DASH-IF Interoperability Points," Dash Industry Forum, V.4.1, September 7, 2017, the contents of which are incorporated herein by reference in their entirety. As will be appreciated by those skilled in the art, the DASH-IF guidelines disclose the dynamic MPD and the "live edge" features of live streaming.

[0028] The ATSC standard may require broadcasters to operate using highly accurate time clocks synchronized to a Global Positioning System (GPS) source. Acquisition of services at the live edge by a receiver requires that the receiver know the correct time with good accuracy (e.g., 100 milliseconds is acceptable). However, the time clocks in typical consumer receivers may not be accurate. Some operating systems only resynchronize the system clock that provides time services to applications once a week. Therefore, during the week between system clock resynchronizations, the clock may gain or lose time.

[0029] If an incorrect value for system time is used, the calculation of the correct media segment to use for service acquisition may refer to a media segment that has not yet been transmitted, or may indicate one that is older than the one most recently received. In the former case, acquisition is delayed while the receiver waits for the requested file to arrive, thus slowing down acquisition. In the latter case, the referenced file may not be available at all, because it was broadcast before the receiver started the service acquisition process. Therefore, embodiments of the present invention address these inaccuracies by deriving the "wall clock time" in the receiver based on analysis of the MPD file provided by the broadcaster.

[0030] 1 illustrates an exemplary digital television broadcast system 100 that provides access to television content. The system includes a service provider 102, a receiving device 120, and an input device 140. The receiving device 102 may be configured to receive data via an antenna. The receiving device 102 may further be configured to connect to the Internet 130 to receive the data.

[0031] In one example, the service provider 102 is a broadcaster of television content, and the receiving device 120 can be any device configured to operate as a television, such as a flat-screen TV, laptop, tablet, or smartphone. The input device 140 can be physically or wirelessly connected to the receiving device 120 and can be any device suitable for operating the receiving device 120, such as a remote control with numeric and / or alphanumeric keys or a QWERTY keyboard. The keys of the input device 140 can be physical buttons or digital representations of numeric or alphanumeric keys on a touchscreen. Embodiments of the present disclosure can be utilized to provide access to other broadcast content (e.g., executable applications such as HTML5 applications). The service provider 102 can transmit a broadcast stream containing television content, which can be distributed via a digital television broadcast signal.

[0032] In one embodiment, the service provider 102 (e.g., a broadcast entity or station) is a service delivery system that includes a transmitting device having a transmitter configured to transmit content, applications, and / or services in a data stream (e.g., a broadcast stream) to the receiving device 120. The transmitter is configured to provide the data stream to the receiving device 120, for example, via digital terrestrial broadcasting. In other examples, the data stream can be transmitted to the receiving device 120 via one or a combination of digital terrestrial broadcasting, a cellular network, a broadband network such as the Internet, a cable network, and a satellite link. The service delivery system can convey the data stream to the receiving device 120 using any one or a variety of transmission technologies.

[0033] A service delivery system according to one embodiment includes a source encoder, a channel encoder, and a modulator. The source encoder includes a data encoder, an audio encoder, and a video encoder that compress audio data, video data, signaling data, control data, or other data received from a source. The channel encoder randomizes, interlaces, channel codes, and frame-maps the compressed media data and signaling data. For example, the channel encoder includes a frame builder that forms a number of data cells into a sequence carried by an Orthogonal Frequency Division Multiplexing (OFDM) symbol. A modulator (e.g., a multiplexer) converts the processed digital data into modulation symbols, which may be, for example, OFDM symbols. This multiplexed data is then passed to an Inverse Fast Fourier Transformer (IFTF) that converts the frequency-domain signal to a time-domain signal. The time-domain signal is then provided to a guard insertion module that generates guard intervals (GI) between symbols, before being provided to a digital-to-analog (D / A) converter. Upconversion, RF amplification, and over-the-air broadcasting are then performed to transmit the broadcast stream.

[0034] In other embodiments, some components of the transmitter or receiver may not be required. Details of OFDM transmitters and receivers can be found, for example, in the DVB-T2 standard (ETSI EN 302 755 V1.4.1, dated July 1, 2015), ATSC Standard A / 322 - Physical Layer Protocol, dated June 6, 2017 (hereinafter the "A / 322 Standard"), and ATSC Standard A / 321 - System Discovery and Signaling, dated March 23, 2016 (hereinafter the "A / 321 Standard"), each of which is incorporated herein by reference in its entirety.

[0035] 2 illustrates an exemplary receiving device 120 configured to access television content and broadcast station applications. Receiver device 120 can be a stationary or mobile device, such as a television set, a set-top box, a smartphone, a tablet computer, a laptop, a portable computer, or any other device configured to receive television content. Furthermore, receiver device 120 can be a digital television receiver integrated into a vehicle or any of the aforementioned stationary or mobile devices.

[0036] Receiver device 120 includes receiver circuitry configured to receive data streams (e.g., broadcast streams) from one or more service providers 102 and processing circuitry configured to perform various functions of receiver device 120. In one embodiment, tuner / demodulator 202 receives broadcast emissions including the broadcast streams. Alternatively or additionally, receiver device 200 may be configured to receive cable television transmissions or satellite broadcasts, depending on the embodiment.

[0037] Once the ATSC 3.0 broadcast emissions are acquired by the tuner / demodulator 202, data packets such as ALP packets are forwarded to a processor 270 which converts the packets into Internet Protocol (IP) packets for further processing. The ALP packets may also be buffered and stored in persistent storage 280 for purposes of time-shifting the broadcast. The persistent storage 280 may be implemented using disk storage forms and other forms of storage such as non-transitory storage including, for example, network memory devices, magnetic storage elements, magneto-optical storage elements, flash memory, core memory, and / or other non-volatile storage technologies.

[0038] The demultiplexer 204 can demultiplex the IP packetized data stream using any necessary files from storage 280 and provide the demultiplexed data to the media engine 290 for decoding into separate audio and video (A / V) streams. Files output by the demultiplexer 204, such as metadata, low-level signaling (LLS) and service layer signaling (SLS) files, media files, and electronic service guide (ESG) files, can be provided to the CPU 238 for processing. ATSC Standard A / 331—Signaling, Delivery, Synchronization, and Error Protection, dated December 6, 2017 (hereinafter, the “A / 331 Standard”), which is incorporated by reference in its entirety, defines the LLS and SLS for ATSC 3.0. Audio is decoded by the audio decoder 210, and video is decoded by the video decoder 214.

[0039] Generally, receiving device 200 operates under the control of at least one processor, such as CPU 238, coupled via one or more buses (e.g., bus 250) to persistent storage 280, working memory 240, program memory 242, and graphics subsystem 244. According to one embodiment, CPU 238 is configured to generate a user interface through which a user can obtain license information and access protected services. Graphics output by graphics subsystem 244 are composited with video images by compositor and video interface 260, which generates output suitable for display on a video display.

[0040] The CPU 238 operates to perform functions of the receiving device 200, including, for example, executing script objects (control objects) included in a broadcaster application (e.g., an HTML5 application) using an HTML5 user agent stored in the program memory 242. The native broadcaster application may also reside in the program memory 242.

[0041] In one embodiment, a collection of files that make up a broadcaster application can be delivered as a package over the air via, for example, the ROUTE protocol described in the A / 331 standard. An exemplary broadcaster application framework is described in ATSC Standard A / 344-ATSC 3.0 Interactive Content, dated December 18, 2017, which is incorporated by reference in its entirety.

[0042] In some embodiments, CPU 238 may be coupled to any one or combination of resources of receiver device 120 to centralize control of one or more functions. In one embodiment, CPU 238 also operates to oversee control of receiver device 120, including tuner / demodulator 202 and other television resources.

[0043] 3 shows a more processor-centric view of receiving device 120. Memories 240 and 242 are collectively referred to as memory 310. Processor 300 further includes one or more processing units, such as CPU 238. Similarly, various demodulators, decoders, etc., that initially process the digital television signal are collectively referred to as television receiver / tuner 320. Receiver 120 also includes a remote control device 360 ​​in communication with remote control receiver interface 340. Display 350 is also connected to display interface 330, which includes combiner 260, and may be a display integrated into receiver 120, such as a television set, or a connected display device if receiver 120 is integrated into a set-top box.

[0044] The memory 310 includes various functional program modules and data. The memory 310 stores data used by the receiving device 120. The memory 310 in the receiving device 120 can be implemented using disk storage and other forms of storage, such as non-transitory storage devices including, for example, network memory devices, magnetic storage elements, magneto-optical storage elements, flash memory, core memory, and / or other non-volatile storage technologies. The term "non-transitory" refers to the medium itself (i.e., tangible, not a signal) as opposed to the permanence of the data storage (e.g., RAM vs. ROM). Also included is storage 380, which can correspond to storage 280 (FIG. 2), for storing recordings for time-shift playback.

[0045] The memory 310 includes a television receiver application 311. The memory 310 stores both a broadcaster application 316a and a native broadcaster application 316b. The broadcaster application 316a can be an HTML5 application included in the broadcast stream. The native broadcaster application 316b can be provided with the receiving device 120 or can be installed at a later time (e.g., downloaded from an App Store). The broadcaster application 316a and the native broadcaster 316b are executed by the processor 300. Furthermore, these applications can cause the processor 300 to control the receiving device 120 to retrieve alternative content 318, which is stored in the memory 310 for later retrieval. In another embodiment, the processor 300 causes the receiving device 120 to retrieve or stream the alternative content 318 upon presentation.

[0046] Technical aspects of PVR design that enable users to take advantage of the features described above include, for example: (1) Storing content in memory (volatile or non-volatile) other than the primary video and audio tracks corresponding to the default language or a user-selected language. (2) Appropriate modification of service layer signaling data to achieve time-shifted playback (described in more detail below). (3) Management of the broadcaster application and / or native broadcaster application to achieve synchronization of the audio, video, caption and interactive content portions of the program during playback.

[0047] In related PVR designs involving time-shifting digital television content based on the ATSC 1.0 (existing DTV system) standard, or in designs where analog TV signals were digitized, compressed, and stored on disk, typically only the primary video and one audio track were stored for later playback. Related DTV systems used the MPEG-2 Transport Stream (TS) as the transport mechanism. In this situation, the PVR generated a "partial" transport stream consisting of only MPEG-2 TS packets from the video elementary stream (ES) and audio elementary stream. Captions were encoded within the video ES. The partial TS could be played back using a time-shifting method. The ES elements included a Program Clock Reference (PCR) for the video and a Presentation Time Stamp (PTS) for both the video and audio, making synchronization and timing adjustments easy. The ATSC 1.0 system did not standardize broadcaster applications.

[0048] Advances in digital video compression technology (HEVC vs. MPEG-2) and improvements in physical layer (e.g., modulation and coding) efficiency have resulted in higher capacity broadcast signals. In some embodiments, a broadcast stream, such as an ATSC 3.0 broadcast signal, includes two or more ATSC 3.0 services. Thus, a broadcast stream can be configured to carry broadcasts from multiple broadcast stations, with each broadcast station providing one primary channel and one or two secondary channels within the broadcast stream's allocated bandwidth (e.g., 6 MHz for a U.S. terrestrial broadcast system).

[0049] 4 illustrates an embodiment of a broadcast stream received by receiving device 120. As an example, a user may select a particular channel associated with a broadcast station while operating a television. Once a channel is selected, a broadcast stream is presented that includes at least the channel selected by the user. Furthermore, the broadcast stream may include multiple channels from the same broadcast station or multiple channels from different broadcast stations (e.g., station B).

[0050] Figure 5 shows an embodiment of a database structure 500 representing files stored in any type of memory that function as pause buffers. As shown in Figure 5, this database structure may store a media presentation description file 500a for each broadcaster service (e.g., A_1). The media presentation description file may indicate the AST and the location of the media segments 500b that correspond to the selected service. The database structure 500 includes LLS and SLS files 500c for each broadcaster service. The database structure for a broadcaster service may also include any associated application files 500d, such as a broadcaster application.

[0051] Buffering packets from a broadcast stream can determine which services are available for playback. In some embodiments, a receiving device can buffer all IP packets in any broadcast stream (e.g., an ATSC 3.0 broadcast signal) in a "pause buffer." Furthermore, DTV products that are not advertised or configured as having "PVR capabilities" can implement a pause buffer using existing memory in the DTV product, such as volatile memory or persistent storage. If a DTV product stores all data broadcast in a broadcast stream, significant advantageous features are achieved, such as: (1) When a user chooses to switch to a different service transmitted over the same broadcast signal, the switching time is nearly instantaneous. (2) Even when playing content from the pause buffer, users can choose from a range of available audio and caption language options. (3) The interactive elements can be paused along with the audio / video / captions while maintaining synchronization between the interactive elements and program playback. (4) If a user starts watching service A and then switches to service B, which is broadcast on the same signal, they may be able to "rewind" and watch some of the content already broadcast on this service, depending on the depth of the pause buffer and the length of time the receiver has been tuned to this broadcast signal.

[0052] It would be inefficient to record every broadcast packet because some packets deliver files that are repeated within the broadcast signal for receivers that have just joined the broadcast. Examples of repeated files include low-level signaling (LLS) and service layer signaling (SLS) files, initialization segment (IS) files (see the MPEG DASH standard), and files containing broadcaster applications.

[0053] In some embodiments, by storing only the first instance of any repeated file, an advantageous optimization over storing all broadcast packets is achieved. For example, instead of storing every IP or ALP packet in a broadcast, the individual files resulting from processing the IP or ALP packets are stored. Thus, if a file found in a broadcast is found to be a duplicate of an already stored file, the duplicate file can be discarded once the new copy is stored in memory, or the already stored copy can be erased (i.e., freeing up the memory occupied by the file).

[0054] Storing all file objects delivered in a given ATSC 3.0 transmission signal can impose a significant processing burden on the receiver. The tuner / demodulator 202 provides ALP packets after demodulation, but the process of converting the ALP packets to files involves 1) converting the ALP packets to IP packets, 2) processing the Lower Layer Signaling (LLS) and Service Layer Signaling (SLS) files for each service multiplexed into the broadcast signal to discover information about each file object in the broadcast stream, and 3) retrieving and storing each file object in the file system.

[0055] The disclosed embodiments provide a significant advantage by buffering ALP packets directly in a pause buffer, eliminating the need to process all ALP packets and files contained in the broadcast stream. As shown in FIG. 2, ALP packets can either flow downstream for direct live playback (e.g., output of decoded audio and video) or can be stored in a pause buffer, which can be implemented in storage 280. ALP packets stored in the pause buffer can be retrieved from the pause buffer and forwarded to the same decoding and media presentation functions. In some embodiments, all ALP packets arriving from tuner / demodulator 202 are stored in the pause buffer. In some embodiments, all files derived from ALP packets are stored in the pause buffer. Furthermore, in some embodiments, all ALP packets associated with a given service are stored in the pause buffer. Also, in some embodiments, all files associated with a given service are stored in the pause buffer.

[0056] In some embodiments, a television receiver application utilizes a file in the broadcast stream to determine parameters used for time-shifted playback. The A / 331 standard specifies two options for the transport protocol: MPEG Dynamic Adaptive Streaming over HTTP (DASH) (along with a FLUTE-like broadcast file delivery protocol called ROUTE), and MPEG MMT (ISO / IEC 23008-1:2017, “Information technology—High Efficiency coding and media delivery in heterogeneous environments—Part 1: MPEG Media Transport (MMT),” International Organization for Standardization, August 2017, the contents of which are incorporated herein by reference in their entirety). As noted above, MPEG DASH is standardized in ISO / IEC 23009-1. According to some embodiments, a receiving device supports DASH / ROUTE transmission.

[0057] In MPEG DASH, a Media Presentation Description (MPD) file is a data structure that references the locations of media segments that carry audio, video, and captions. In some embodiments, the MPD includes a parameter called the Availability Start Time (AST), which can be identified in the MPD file as the MPD@availabilityStartTime attribute. The AST anchors all timing aspects of the broadcast to a time (date and time). A receiver that has information corresponding to the current time uses the AST parameter to determine which media segment it can find to begin initial playback of the service's content.

[0058] In some embodiments of a receiving device operating as an ATSC 3.0 receiver based on the Android OS platform, a media player library is included to decode and render content. The standard audio and video components of the media player can be based on the Android MediaCodec API. Additionally, the media player can support DASH.

[0059] When a media player receives a request to play live streaming content, it can adjust the AST provided in the broadcast MPD so that the media player attempts to retrieve the optimal media segment for the fastest acquisition of the selected service when the receiver first acquires the service. This method can result in the shortest channel change time. Adjusting the AST may be necessary if the internal time clock used by the Android OS does not precisely match the GPS time used by the broadcaster. This clock adjustment is described below.

[0060] If a receiving device or PVR includes a pause buffer for pausing live TV, it can make the media player aware of the availability of older media segments, for example, to support pause and rewind operations. The DASH MPD includes an attribute called MPD@timeShiftBufferDepth to indicate the availability of older media segments. Broadcasters can set this parameter to a low value, aware of the fact that media segments are pushed via broadcast rather than being available for pulling from an HTTP server. A receiving device can adjust the value of MPD@timeShiftBufferDepth to reflect the availability of media segments in the time-shift buffer, allowing the media player to operate more efficiently and provide the user with the most flexible playback experience. For example, if the time-shift buffer contains audio / video / caption segments from the past five minutes, the receiver can set MPD@timeShiftBufferDepth to a value of five minutes (e.g., set the attribute value to "PT5M").

[0061] In some embodiments, a media player can be used to play time-shifted content, such as content that has been recorded and stored for later viewing, for example by performing a PVR function. The MPD sent by the broadcaster can be of the "dynamic" type (see MPD@type, MPEG DASH Standard, Section 5.3.9.5.3, Media Segment Information). In some embodiments, once DASH content is stored, a "static" MPD can be created to reference the stored media segment files. A static MPD is suitable for video-on-demand content, which becomes video-on-demand content after it is stored. Information describing the program content, such as title, rating, synopsis, and first air date and time, can be stored in a separate manifest file.

[0062] Typically, a DASH client in a user device accesses a DASH server to access the MPD and then accesses the referenced media segment files. This access occurs over the Internet using the HTTP protocol. However, when DASH is implemented in an ATSC 3.0 receiver, the full HTTP stack does not need to be used because the content is stored and consumed locally. For example, the HTTP GET operation can be replaced by fetching the file through a file system supported by the OS hosting the ATSC 3.0 receiver application.

[0063] According to some embodiments, ATSC 3.0 receiver implementations that employ a media player for media rendering use the media player's native support for MPEG DASH. The DASH MPD, like any device acting as a DASH client, prompts for a selection of which media segment files (e.g., which parts of a program) to render. When a DASH client is requested to render a live TV broadcast, it can calculate which media segment is the most recent (i.e., most recently transmitted) and use it to begin playback based on the time and processing the ASTs included in the broadcast MPD (e.g., MPD@availabilityStartTime) along with other parameters in the MPD. This process can occur when the receiver first encounters the broadcast service after a channel change.

[0064] According to some embodiments, when a receiver is configured to render time-shifted content using a DASH client, the receiver can adjust the AST to indicate a time that is earlier than the actual time by a predetermined amount, and the DASH client requests older media segment files from the buffer based on this adjustment.

[0065] 2, in some embodiments, the ALP packets provided by the tuner / demodulator 202 of the receiving device 120 may be stored directly in a pause buffer, which may be implemented in storage 280. In further embodiments, the pause buffer may be implemented in working memory 240 (e.g., RAM).

[0066] In some embodiments, for ATSC 3.0 broadcast emissions in which broadcasters are using IP protocols defined in the ATSC 3.0 standard (e.g., A / 330, A / 331, A / 337, A / 344), the ALP packets are a combination of compressed IP packets interspersed with a small number of signaling packets. The A / 337 standard is defined in ATSC Standard: Application Signaling (document A / 337:2018, dated January 2, 2018) (hereinafter the "A / 337 standard"), the contents of which are incorporated by reference in their entirety. The IP packet compression is primarily header compression employed to optimize the delivery efficiency of multicast UDP / IP packets within a broadcast.

[0067] A certain amount of CPU overhead is used to process the ALP protocol defined in the A / 330 standard, e.g., to decompress the ALP packets to obtain IP packets. In some embodiments, whenever a user requests to view one of the (possibly many) services included in a broadcast stream, the ALP packets associated with the requested service are processed in real time. Meanwhile, ALP packets carrying services other than the selected service do not need to be processed in real time and can be stored directly in a pause buffer.

[0068] As those skilled in the art will appreciate, UDP / IP packets corresponding to a given IP source / destination address and port number can be transmitted on a particular physical layer pipe (PLP) as defined in the A / 321 and A / 322 standards. In some embodiments, a given broadcast emission can have up to 64 different PLPs. If a user selects to view service A and all components and signaling (SLS) of service A are carried in PLP#1, in some embodiments, all ALP packets from PLP#1 are processed into IP packets to achieve real-time viewing of service A. ALP packets from PLPs other than PLP#1 can be stored in a pause buffer without being processed into IP packets.

[0069] If the user subsequently wishes to switch to service B and ALP packets for that service are present in the pause buffer, the receiver can play service B by retrieving the appropriate ALP packets and / or files from the pause buffer, and can even allow the user to rewind to view the portion of the program that was missed while watching service A. After retrieving the appropriate ALP packets corresponding to service B from the pause buffer, the receiver can then process the retrieved ALP packets as if service B had been originally selected for live broadcast viewing.

[0070] Because all ALP (and IP) packets associated with every service are buffered, users can choose different options when watching live TV to view and enjoy the program, including turning on closed captions with multiple language choices, or choosing to swap in alternate audio tracks in different types of languages ​​when available. Because all ALP packets associated with every service included in the broadcast stream are stored in the pause buffer, users have these same options available when watching time-shifted content.

[0071] 6 shows an exemplary display 600 in which an electronic program guide 602 is also displayed. As shown in the electronic program guide 602, a broadcast station may have three channels A_1, A_2, and A_3. Channel A_1 may have program 1 available from 7:00 PM to 9:00 PM. Channel A_2 may have program 2 available from 7:00 PM to 8:00 PM and program 3 available from 8:00 PM to 9:00 PM. Channel A_3 may have program 4 available from 7:00 PM to 7:30 PM, program 5 available from 7:30 PM to 8:00 PM, and program 6 available from 8:00 PM to 9:00 PM.

[0072] Figure 7 illustrates an example viewing scenario based on the available programs shown in Figure 6. For example, in Figure 7(a), a user may have selected channel A_1 and started watching program 1 at 7 PM. In Figure 7(b), at 8 PM, the user requests that program 1 be played back starting from a time before 8 PM (e.g., around 7:15 PM). Because content related to program 1 is stored in a pause buffer, the audio and video content of program 1 corresponding to the playback time of 7:15 PM, as well as any language or viewing angle selections that would have been available if the user had been watching program 1 live at 7:15 PM, are stored in the pause buffer. Content Service Functions FIG. 7(c) illustrates another scenario in which a user can stop playback of Program 1 at 8:00 PM and choose to watch Program 2 provided by Channel A_2. Additionally, the user can also request playback of content from Program 2 that was available before 8:00 PM (e.g., at 7:15 PM). Because Program 2 would have been downloaded in the broadcast stream at the time Program 1 was selected by User 1, the audio and video content of Program 2 corresponding to the playback time of 7:15 PM, as well as the audio and video content that would have been available if the user had been watching Program 2 live at 7:15 PM, would be available. Content Service Functions (e.g. language selection, viewing angle, etc.) are available.

[0073] As described above, according to some embodiments, the runtime environment of the receiving device is configured to run at least two different applications: (1) a broadcaster application (e.g., a broadcaster HTML5 application), and (2) a native broadcaster application (e.g., an Android application if the receiver is based on the Android platform).

[0074] In some embodiments, a broadcaster application is transmitted simultaneously with the audio / video / caption content containing the selected service. The broadcaster application may include files referenced by an SLS table called HELD (an acronym for HTML Entry pages Location Description) as defined in the A / 337 standard.

[0075] When executed, the broadcaster application can provide an interactive experience synchronized with the program content. For example, in an interactive experience with a game show, the broadcaster application could allow the user to guess the answer to a quiz question that is asked at a point in the program. In this example, the broadcaster application could display the dialogue "Yes or No?" at the appropriate point and record any answers so that the results can be viewed later.

[0076] According to some embodiments, the broadcaster application determines the appropriate timing of events (such as dialogue in the game show example) by responding to events (see A / 344 Standard, Section 6.3.2, Broadcaster Application Events [Static / Dynamic]). Events can be "dynamic" or "static".

[0077] In some embodiments, if the event is a dynamic event, the broadcaster embeds an 'emsg (event message) box in one of the media segment files of the representation so that the 'emsg is encountered and processed at the appropriate point during playback. A representation is a collection of one or more media streams encapsulated in a delivery format and can have associated descriptive metadata. For example, a representation can be an audio stream (e.g., one representation per language), or one or more video tracks or caption tracks. If the receiving device encounters an 'emsg box in the stream corresponding to an event of a type for which the broadcaster application has registered (see A / 344 Standard, Section 9.5), it can handle dynamic event processing by sending an Event Stream Event WebSocket message (see A / 344 Standard, Section 9.5.3) to the broadcaster application. This message can contain information the broadcaster application needs to know to display a specific dialog box. For example, at a specific point in the playback of the content, the broadcaster application can encounter an 'emsg that causes the broadcaster application to display interactive information (e.g., selectable icons) to the user.

[0078] For static events, in some embodiments, the broadcaster application needs to know where the user is currently watching in the playback timeline, since trick play modes (e.g., pause, fast forward, rewind, etc.) may occur during playback. For example, to signal static events, the MPD includes an EventStream element that identifies when a given event is scheduled to occur within the context of an MPD Period. See ISO / IEC 23009-1, section 5.10.2, "MPD Events."

[0079] Static events can be processed so that, if the receiving device knows the point in the media where a given event is scheduled to occur, the receiving device can synchronize to the media timeline as the user plays the content, effectively enabling interactivity when the appropriate point in the playback occurs. For example, the ATSC 3.0 runtime application environment can support application / content playback synchronization through WebSocket APIs known to those skilled in the art, such as those specified in the A / 344 Standard, Section 9.13, RMP, Content Synchronization APIs. If a broadcaster application needs to know the current presentation time of the content being presented, it can call the Content Synchronization API to enable the broadcaster application to present auxiliary content synchronized to the content being presented (e.g., displaying a graphical overlay at a predetermined point in the program).

[0080] In some embodiments, if the user performs any trick play operations during playback, the broadcaster application can be notified of this trick play operation by subscribing to RMP media time change event notifications (see A / 344 standard, section 9.6.12, Subscribe RMP Media Time Change Notification API). Thus, the broadcaster application can present content that is synchronized with the content that is being played from the pause buffer by keeping the broadcaster application informed of trick play operations.

[0081] Unlike broadcaster applications, for which a WebSocket API is defined to establish time synchronization between the application and the playback of content, native broadcaster applications do not have a standardized method that allows them to communicate with a receiving device. U.S. patent application Ser. No. [insert application number], filed on [insert date] and entitled "Broadcaster Application Remote Control Key Handling," discloses a proprietary API that allows manufacturers to provide a generic communication path between a broadcaster native application and a broadcaster application, the contents of which are incorporated herein by reference in their entirety. As disclosed above, according to some embodiments, a broadcaster application can synchronize with content being played from a pause buffer and use this communication path to notify the native broadcaster application of the timeline of the content being played from the pause buffer and any adjustments to the timeline (e.g., fast forward, rewind, pause) that occur as a user interacts with the content.

[0082] According to some embodiments, a broadcaster service (e.g., an ATSC 3.0 service) may be broadcast using multiple video tracks that allow users to select from which perspective they wish to view the program. For example, a car race may provide views from inside the cockpits of different cars. The selection of which video view a given viewer will see at a given time is likely to occur as that viewer interacts with the broadcaster application. The broadcaster application may provide a user interface that allows the user to make the view selection.

[0083] FIG. 8 shows an example display 800 of content and available Content Service Functions For example, Content Service Functions 800a to 800c provide different viewing options, View 1 to View 3, respectively. Content Service Functions800d-800f indicate the available language choices, such as English, Spanish, and French, respectively. Content Service Functions 800a to 800f can be used during the live broadcast of the content shown in display 800. Content Service Functions can also be utilized during time-shifted playback of the content, as if the user were watching the content live. As will be appreciated by those skilled in the art, this embodiment utilizes the Content Service Functions Any method known to those skilled in the art may be used, including but not limited to: Content Service Functions may include:

[0084] Thus, embodiments of the present disclosure, including the feature of including all possible video tracks in the time-shifted content, provide users with the significant advantage of selecting viewing features that would have been available during the live broadcast. Additionally, users may play the same program or portion of a program multiple times, selecting different video views at different viewing times.

[0085] According to some embodiments, the receiving device can adjust its operating system clock based on the clock referenced or used by the broadcaster. In this regard, the receiving device can obtain the current time using a standard system call such as: import java.util.Calendar Calendar rightNow=Calendar.getInstance()

[0086] However, this standard system call may result in a more or less incorrect current time value. Any discrepancy between the current time clock in the receiving device and the broadcaster's clock may cause problems in obtaining the service. Therefore, it is necessary to improve the acquisition of an accurate clock in the receiving device in order to reduce or eliminate the significant disadvantages caused by an inaccurate time clock in the receiving device.

[0087] In some embodiments, a television receiver application executed by the receiving device derives the time mechanism to use to manage the service acquisition process from the AST value and timing of the received media segment itself. Since broadcasters are likely to synchronize their program timing via GPS systems, the clock observed by the broadcaster is likely to be more accurate than the television receiving device's clock. For example, if the AST indicates that a given media segment just received will be available at time X based on the broadcaster's understanding of time, in some embodiments the corresponding system time is derived as follows: Wall Clock Time (elapsed real time) = OS_clock + (signaled_AST - observed_AST) where: (a) Wall Clock Time is the time used by television receiver applications in calculations involving time of day; (b) OS_clock is the time reported by the operating system, (c) signaled_AST is the availabilityStartTime signaled in the broadcast MPD, (d) observed_AST is the AST calculated by the receiver based on the observation of when a given media segment was received relative to when it would have been expected to be received if the OS_clock were accurate (e.g., observed_AST = signaled_AST + (media arrival time - expected media arrival time)).

[0088] According to the example equation above, if the observed AST is the same as the signaled AST, then OS_clock is accurate and no adjustment needs to be made. On the other hand, if the observed AST indicates a time that is advanced from the signaled AST (i.e., a time that is in the future with respect to the signaled AST), then the media segment is arriving earlier than would be expected if OS_clock were correct. Therefore, in this scenario, Wall Clock Time is decremented by an amount corresponding to the discrepancy with respect to OS_clock.

[0089] If the observed AST indicates a time that is later than the signaled AST (i.e., a time that is in the past relative to the signaled AST), then the media segment is arriving later than would be expected if the OS_clock were correct. Thus, in this scenario, the Wall Clock Time is set to an amount that corresponds to the discrepancy relative to the OS_clock. During initial time (e.g., time=0, such as upon power-up of the receiving device), the Wall Clock Time can be set to the OS_clock. While the Wall Clock Time is being adjusted, the OS_clock is not adjusted.

[0090] Based on this method, even larger errors in the OS_clock relative to the precise time used by the broadcaster can be accommodated. Figure 9 illustrates example scenarios for the predicted time at which a media segment is expected to arrive and the actual arrival time of the media segment. For example, Figure 9(a) illustrates a scenario in which the OS_clock is 20 seconds behind. In this situation, the media segment is observed to arrive and become "available" 20 seconds before the predicted time. As shown in Figure 9(a), the media segment is expected to arrive at 7:00, but it arrives 20 seconds earlier (e.g., at 6:59:40) than the expected arrival time (e.g., 7:00:00). Therefore, the observed AST is 20 seconds less than the signaled AST (e.g., signaled_AST - observed_AST = 20 seconds). Therefore, to obtain the accurate Wall Clock Time, a 20-second adjustment is made by adding 20 seconds to the OS_clock.

[0091] For example, Figure 9(b) illustrates a scenario in which the OS_clock is 20 seconds ahead. As shown in Figure 9(b), a media segment is observed to arrive and become "available" 20 seconds later (e.g., at 7:00:20) than the time it was expected to arrive (e.g., 7:00:00). Therefore, the observed AST is 20 seconds greater than the signaled AST (e.g., signaled_AST - observed_AST = -20 seconds). Therefore, to obtain the accurate Wall Clock Time, 20 seconds are subtracted from the OS_clock by making a -20 second adjustment.

[0092] 10 shows an embodiment of a process performed by receiving device 120. Generally, the process begins in step S1000, where a user selects a broadcast service (e.g., selects a program while viewing an EPG). The process proceeds to step S1002, where the receiving device receives a broadcast stream (e.g., the broadcast stream shown in FIG. 4) including the selected broadcast service. The process proceeds to step S1004, where the receiving device stores the ALP packets in a pause buffer (e.g., storage 280).

[0093] The process proceeds to step S1006, where ALP packets and files corresponding to the selected broadcast service are processed, including 1) converting the ALP packets to IP packets, 2) processing the Lower Layer Signaling (LLS) and Service Level Signaling (SLS) files of each service multiplexed into the broadcast signal to discover information about each file object in the broadcast stream, and 3) retrieving and saving each file object to the file system. The process proceeds to step S1008, where it is determined whether a file generated from the processed ALP packets is stored in the pause buffer. If the file generated from the processed ALP packets is not stored in the pause buffer, the process proceeds to step S1010, where the generated file is stored in the pause buffer. If the file generated from the processed ALP packets is stored in the pause buffer, the process proceeds to step S1012, where the audio and video content is output to a display, and the audio and video content is displayed, such as for language selection. Content Service Functions are available, and users can press a button to Content Service Functions You can enable one of them.

[0094] The process proceeds to step S1014 to determine whether a time-shift playback request has been received. For example, the time-shift playback request may correspond to a request to rewind or fast-forward content currently being viewed by the user, or a request to change from the selected broadcast service to another broadcast service, in which case the user may rewind or fast-forward the other broadcast service relative to the time at which the selected broadcast service is currently being viewed.

[0095] If a time-shift playback request is not received, the process returns to step S1012, allowing the user to continue viewing and listening to playback of the content. If a time-shift playback request is received, the process proceeds to step S1016, where it determines whether the requested content is present in the pause buffer. As content is written to the pause buffer or files are deleted, the receiver can track the duration of playback time available in the buffer, taking into account all elements of the program (e.g., video, audio, captions, and interactive content). This duration can then be used to determine whether the requested content is available in the pause buffer. If the requested content is present in the pause buffer, the process proceeds to step S1018, where it retrieves the ALP packets and files associated with the requested content from the pause buffer. The process proceeds from step S1018 to step S1006, where it processes the retrieved ALP packets and files corresponding to the requested content associated with the time-shift playback request.

[0096] If the requested content is not present in the pause buffer, the process proceeds from step S1016 to step S1020, which determines whether the user is time-shifting content backward (e.g., the user is pressing the rewind button). If the user is time-shifting content backward, the process proceeds to step S1022, where the closest available content in the pause buffer is selected. For example, such a scenario may occur if the user wants to rewind the content by five minutes, but only three minutes of recording is available in the pause buffer. When this situation occurs, the user is provided with the available content that is closest to the desired time-shifted content. The process proceeds from step S1022 back to step S1014.

[0097] Returning to step S1020, if the user is not time-shifting the content backward, the user is time-shifting the content forward (e.g., the user is pressing the fast-forward button), and therefore the process returns from step S1020 to step S1002 to obtain the latest available content. The process shown in Figure 10 may end when the user shuts down the television receiver application or the television receiver device.

[0098] 11 illustrates an embodiment of a process performed by a receiving device. Generally, the process begins in step S1100, where an operating system time (e.g., OS_clock) is determined. The process proceeds to step S1102, where an availability start time of television content of the broadcaster service is determined from the received broadcast stream (e.g., signaled_AST). This availability start time may be retrieved from an MPD file included in the broadcast stream. The process proceeds to step S1104, where an expected reception time of media segments corresponding to the television content is determined based on the availability start time. The expected reception time of the media segments may be determined based on the availability start time included in the MPD file.

[0099] The process proceeds to step S1106, where it determines the actual reception time of the media segment corresponding to the television content. The process proceeds to step S1108, where it determines an observed AST representing the availability start time (e.g., signaled_AST) plus the difference between the reception time of the media segment and the expected reception time of the media segment (e.g., observed_AST = signaled_AST + (media arrival time - expected media arrival time)). The process proceeds to step S1110, where it adjusts the operating system clock according to the observed AST (e.g., Wall Clock Time = OS_clock + (signaled_AST - observed_AST)).

[0100] 12 is a block diagram illustrating an example hardware configuration of a computer that may be configured to perform the functions of the receiving device and / or the service delivery system. For example, in one embodiment, the computer is configured to perform one or a combination of the functions described herein with respect to the receiving device 20 and / or the service provider 102.

[0101] As shown in Figure 12, the computer includes a CPU 1202, a ROM (Read Only Memory) 1204, and a RAM (Random Access Memory) 1206, which are interconnected via one or more buses 1208. The one or more buses 1208 are further connected to an input-output interface 1210. The input-output interface 1210 is connected to an input unit 1212 formed by a keyboard, a mouse, a microphone, a remote control device, etc. The input-output interface 1210 is also connected to an output unit 1214 formed by an audio interface, a video interface, a display, speakers, etc., a storage unit 1216 formed by a hard disk, a communication unit 1218 formed by a non-volatile memory or other non-transitory computer-readable storage medium, a network interface, a modem, a USB interface, a FireWire interface, etc., and a drive 1220 that drives removable media 1222 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory.

[0102] According to one embodiment, the CPU 1202 loads a program stored in the storage unit 1216 into the RAM 1206 via the input-output interface 1210 and the bus 1208, and then executes the program configured to provide one or a combination of the functions described herein with respect to the receiving device 120 and / or the service provider 102.

[0103] The above hardware description exemplified by any one of the example structures shown in Figures 2 and 12 may constitute or include specialized corresponding structures programmed or configured to execute the algorithms described above with reference to Figures 10 and 11. For example, any one or combination of the algorithms shown in Figures 10 and 11 may be executed entirely by circuitry contained in a single device as shown in Figure 2.

[0104] Obviously, numerous modifications and variations are possible in light of the above teachings. It is therefore to be understood that, within the scope of the appended claims, the present disclosure may be practiced otherwise than as specifically described herein.

[0105] Accordingly, the foregoing description discloses and describes merely exemplary embodiments of the present disclosure. As will be understood by those skilled in the art, the present disclosure may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Accordingly, the present disclosure is intended to be illustrative, and not limiting, of the scope of the present disclosure and other claims. The present disclosure defines in part the scope of the following claim terms, including all readily discernible variations of the teachings herein, so that the subject matter of the present invention is not open to the general public.

[0106] Embodiments of the present disclosure include the following significantly advantageous features: (1) Available storage with sufficient capacity to buffer a significant amount of content. (2) Direct buffering of ALP packets received from the tuner / demodulator for playback from the pause buffer. (3) The amount of time shift to be set is adjustable from zero (for example, for live TV viewing) to any desired amount according to the free memory capacity of the pause buffer. (4) The ability to record multiple TV services into a pause buffer to provide instant channel changes to services carried in the same broadcast stream, and the ability to rewind and view content previously broadcast on such a service after switching to it. (5) The availability of trick play (e.g., fast forward, rewind, pause, etc.) when playing content from the pause buffer. (6) Playback options, such as selecting audio or caption languages ​​or different video tracks during time-shifted playback, as if the content were being played live (e.g., Content Service Functions ) ability to select. (7) Ability to interact with time-shifted content. (8) Ability to address deviations in the accuracy of the operating system time relative to the precise time of the GPS used by the station.

[0107] The above disclosure also includes the following embodiments:

[0108] (1) A receiving device, comprising: a receiver circuit configured to receive a broadcast stream including (i) a first broadcast station service and (ii) a second broadcast station service selected by a user; a demodulator configured to demodulate the broadcast stream into a plurality of data packets; and a processing circuit, wherein the processing circuit is configured to store the plurality of data packets corresponding to the first and second broadcast station services in a pause buffer, process each data packet associated with the selected first broadcast station service to extract audio and video content, and output the extracted audio and video content associated with the first broadcast station service to the user as part of a live TV broadcast during a first time period.

[0109] (2) The receiving device described in feature (1), wherein the processing circuit is further configured to: receive, during a second period after the first period, a user input indicating a request to generate audio and video content related to the second broadcast station service that is available during an intermediate period between the first period and the second period; retrieve data packets related to the audio and video content that is available during the intermediate period from the pause buffer; process each data packet retrieved from the pause buffer to extract the audio and video content that is available during the intermediate period; and output the audio and video content that is available during the intermediate period as part of time-shift playback for the second broadcast station service.

[0110] (3) The processing circuitry is configured to: Content Service Functionsfor the second broadcast station service during the time-shifted playback of the audio and video content available during the intermediate period.

[0111] (4) The processing circuit receives, during a second period after the first period, a user input indicating a request to generate audio and video content related to the first broadcast station service that is available during an intermediate period between the first period and the second period; retrieves data packets related to the audio and video content that is available during the intermediate period from the pause buffer; processes each data packet retrieved from the pause buffer to extract the audio and video content that is available during the intermediate period; and outputs the audio and video content that is available during the intermediate period as part of time-shift playback for the second broadcast station service; and Content Service Functions The receiving device described in any one of features (1) to (3), further configured to provide for the first broadcast station service during the time-shifted playback of the audio and video content available during the intermediate period.

[0112] (5) The receiving device described in feature (3) or (4), wherein the at least one content service associated with the first broadcast station service is selected from the group consisting of closed captioning, non-primary language audio, non-primary language subtitles, and alternative viewing angles.

[0113] (6) The processing circuit is configured to execute a broadcast station application provided with the received broadcast stream, the broadcast station application Content Service Functions The receiving device according to any one of features (3) to (5), wherein the receiving device displays a plurality of user-selectable options including:

[0114] (7) The broadcast station application Content Service Functionswith the time-shifted playback of the audio and video content available during the intermediate period.

[0115] (8) The receiving device described in any one of features (1) to (7), wherein the processing circuit is further configured to determine whether each file generated from the processing of each data packet is stored in the pause buffer, and in response to determining that a file from the generated file is not stored in the pause buffer, store the file in the pause buffer, and in response to determining that a file from the generated file is stored in the pause buffer, discard the file.

[0116] (9) A receiving device described in any one of features (1) to (7), wherein each broadcast station service included in the received broadcast stream is an Advanced Television Systems Committee (ATSC) service, and the plurality of data packets are ATSC Link Layer Protocol (ALP) packets.

[0117] (10) A receiving device, comprising: a receiver circuit configured to receive a broadcast stream including a broadcast station service selected by a user; a demodulator configured to demodulate the broadcast stream into a plurality of data packets; and a processing circuit, wherein the processing circuit stores the plurality of data packets in a pause buffer; processes each data packet related to the selected broadcast station service to extract audio and video content; outputs the extracted audio and video content to the user as part of a live TV broadcast during a first period; receives, during a second period after the first period, a user input indicating a request to generate audio and video content related to the first broadcast station service that is available during an intermediate period between the first period and the second period; retrieves data packets related to the audio and video content that is available during the intermediate period from the pause buffer; processes each data packet retrieved from the pause buffer to extract the audio and video content that is available during the intermediate period; and outputs the audio and video content that is available during the intermediate period as part of a time-shifted playback; and during the time-shifted playback of the audio and video content that is available during the intermediate period, Content Service Functions and wherein the at least one Content Service Functions is included in the plurality of data packets stored in and retrieved from the pause buffer.

[0118] (11) The receiving device described in feature (10), wherein the plurality of data packets stored in and retrieved from the pause buffer are IP packets or Advanced Television Systems Committee (ATSC) Link Layer Protocol (ALP) packets.

[0119] (12) A receiving device according to feature (10) or (11), wherein the plurality of data packets stored in the pause buffer and retrieved from the pause buffer include Dynamic Adaptive Streaming over HTTP (DASH) content or MPEG Media Transport (MMT) content.

[0120] (13) A receiving device described in any one of features (10) to (12), wherein the at least one content service related to the broadcast station service is selected from the group consisting of closed captioning, non-primary language audio, non-primary language subtitles, and alternative viewing angles.

[0121] (14) A receiving device comprising: a receiver circuit configured to receive a broadcast stream including a broadcast station service selected by a user; a demodulator configured to demodulate the broadcast stream into a plurality of data packets; and a processing circuit, wherein the processing circuit is configured to: determine an operating system time; process the data packets to determine a signaled availability start time (AST) of television content associated with the broadcast station service; determine an expected reception time of media segments corresponding to the television content based on the signaled AST; determine an actual reception time of the media segments corresponding to the television content; determine an observed AST representing the sum of the signaled AST and a difference between the reception time of the media segment and the expected reception time of the media segment; determine a playback time offset from the operating system time according to the observed AST; and output audio and video content associated with the received broadcast station service according to the determined playback time.

[0122] (15) The receiving device according to feature (14), wherein the playback time is offset from the operating system clock by adding a difference between the signaled AST and the observed AST to the operating system clock.

[0123] (16) The receiving device according to feature (14) or (15), wherein the signaled AST is included in a media presentation description file.

[0124] (17) The receiving device described in feature (14), wherein the broadcast station service included in the broadcast stream is an Advanced Television Systems Committee (ATSC) service, and the plurality of data packets are ATSC Link Layer Protocol (ALP) packets.

[0125] (18) A non-transitory computer-readable medium having stored thereon instructions that, when executed by a processor in a receiving device, cause the processor to perform a method, the method including storing in a pause buffer a plurality of data packets corresponding to a first broadcast station service and a second broadcast station service selected by a user, the first and second broadcast station services being received in a broadcast stream demodulated into the plurality of data packets, the method further including processing each data packet associated with the selected first broadcast station service to extract audio and video content, and outputting the extracted audio and video content associated with the first broadcast station service to a user as part of a live TV broadcast during a first time period.

[0126] (19) A non-transitory computer-readable medium having stored thereon instructions that, when executed by a processor in a receiving device, cause the processor to perform a method, the method comprising: processing each data packet associated with the selected broadcast station service to extract audio and video content; outputting the extracted audio and video content to the user as part of a live TV broadcast during a first time period; receiving, during a second time period subsequent to the first time period, a user input indicating a request to generate audio and video content associated with the first broadcast station service that is available during an intermediate time period between the first time period and the second time period; retrieving data packets associated with the audio and video content that is available during the intermediate time period from the pause buffer; processing each data packet retrieved from the pause buffer to extract the audio and video content that is available during the intermediate time period; and outputting the audio and video content that is available during the intermediate time period as part of a time-shifted playback; and performing at least one of the following during the time-shifted playback of the audio and video content that is available during the intermediate time period. Content Service Functions and providing said at least one Content Service Functions is included in the plurality of data packets stored in and retrieved from the pause buffer.

[0127] (20) A non-transitory computer-readable medium storing instructions that, when executed by a processor in a receiving device, cause the processor to perform a method, the method including: processing data packets demodulated from a received broadcast stream to determine a signaled availability start time (AST) of television content associated with a broadcast station service included in the received broadcast stream; determining an expected reception time of a media segment corresponding to the television content based on the signaled AST; determining an actual reception time of the media segment corresponding to the television content; determining an observed AST representing the sum of the signaled AST and a difference between the reception time of the media segment and the expected reception time of the media segment; determining a playback time offset from the operating system time according to the observed AST; and outputting audio and video content associated with the received broadcast station service according to the determined playback time.

Claims

1. A receiving device, a receiver circuit configured to receive a broadcast stream using Internet Protocol (IP) that includes (i) a first broadcast service and (ii) a second broadcast service; a demodulator configured to demodulate the broadcast stream into a plurality of data packets; a processing circuit; The processing circuitry comprises: storing the plurality of data packets, wherein the stored plurality of data packets include service-related signaling of the first broadcast service and the second broadcast service; processing the data packets associated with the first broadcast service to extract audio and video content; outputting the extracted audio and video content associated with the first broadcast service as part of a live TV program during a first time period; It is configured as follows: A receiving device characterized by:

2. The processing circuitry receiving, during a second time period subsequent to the first time period, a user input indicating a request to generate audio and video content related to the second broadcast service that is available during an intermediate time period between the first time period and the second time period; retrieving stored data packets associated with said audio and video content available during said intermediate period; processing the retrieved data packets to extract the audio and video content available during the intermediate period; outputting audio and video content associated with the second broadcast service that is available during the intermediate period as part of time-shifted playback; The receiving device according to claim 1 , configured to:

3. the processing circuitry is configured to provide at least one content service feature included in the broadcast stream during the time-shifted playback of audio and video content associated with the second broadcast service available during the intermediate period.

3. The receiving device according to claim 2.

4. The processing circuitry receiving, during a second time period after the first time period, a user input indicating a request to generate audio and video content related to the first broadcast service that is available during an intermediate time period between the first time period and the second time period; retrieving stored data packets associated with said audio and video content available during said intermediate period; processing the retrieved data packets to extract the audio and video content available during the intermediate period; outputting audio and video content associated with the first broadcast service that is available during the intermediate period as part of a time-shifted playback; providing at least one content service feature included in the broadcast stream during the time-shifted playback of audio and video content associated with the first broadcast service available during the intermediate period; The receiving device according to claim 1 , configured to:

5. the at least one content service feature associated with the first broadcast service is selected from the group consisting of closed captioning, non-primary language audio, non-primary language subtitles, and alternative viewing angles; 4. The receiving device according to claim 3.

6. the processing circuitry is configured to execute a broadcast station application provided with the received broadcast stream, the broadcast station application displaying a plurality of user-selectable options including the at least one content service feature.

4. The receiving device according to claim 3.

7. the broadcaster application is configured to synchronize the at least one content service feature with the time-shifted playback of the audio and video content available during the intermediate period.

7. The receiving device according to claim 6.

8. The processing circuitry determining whether each file generated from said processing of said data packets is stored; storing the file in response to determining that the file from the generated file is not stored; In response to determining that a file from the generated file is stored, discarding the file. The receiving device according to claim 1 , configured to:

9. each broadcast service included in the received broadcast stream is a different service, and the plurality of data packets are link layer packets; each broadcast service associated with a different data packet of the plurality of data packets; 2. The receiving device according to claim 1.

10. 1. A non-transitory computer-readable medium having stored thereon instructions that, when executed by a processor in a receiving device, cause the processor to perform a method, the method comprising: storing a plurality of data packets, wherein a first broadcast service and a second broadcast service are received in a broadcast stream demodulated into the plurality of data packets using Internet Protocol (IP), and wherein the stored plurality of data packets include service-related signaling for the first broadcast service and the second broadcast service, the method comprising: processing the data packets associated with the first broadcast service to extract audio and video content; outputting the extracted audio and video content associated with the first broadcast service as part of a live TV program during a first time period; 10. A non-transitory computer-readable medium, further comprising:

11. 2. The receiving device of claim 1, wherein the processing circuit is configured to store the plurality of data packets corresponding to both the first broadcast service and the second broadcast service of the broadcast stream in response to a user's selection of the first broadcast service.

12. 2. The receiving device of claim 1, wherein the processing circuit is configured to store the plurality of data packets corresponding to both the first broadcast service and the second broadcast service of the broadcast stream, regardless of whether the second broadcast service has already been selected by a user.

13. A receiving method, comprising: receiving a broadcast stream using Internet Protocol (IP) that includes (i) a first broadcast service and (ii) a second broadcast service; demodulating the broadcast stream into a plurality of data packets; storing, by a processing circuit, the plurality of data packets, wherein the stored plurality of data packets include service-related signaling for the first broadcast service and the second broadcast service; processing the data packets associated with the first broadcast service to extract audio and video content; outputting the extracted audio and video content associated with the first broadcast service as part of a live TV program during a first time period; A receiving method comprising:

14. The receiving device of claim 1 , wherein the processing circuitry is configured to store low-level signaling of the first broadcast service and the second broadcast service.

15. The computer-readable medium of claim 10 , wherein the method includes storing low-level signaling of the first broadcast service and the second broadcast service.

16. 14. The receiving method of claim 13, comprising storing low-level signaling of the first broadcast service and the second broadcast service.

Images