Detailed Description
The present disclosure relates to digital television (such as Advanced Television Systems Committee (ATSC) 3.0 televisionIn (c) a) technical advancement. An example system herein may include an ATSC 3.0 source component and a client component that are connected via broadcast and/or over a network such that data may be exchanged between the client component and the ATSC 3.0 source component. The client component may include one or more computing devices including portable televisions (e.g., smart TVs, internet-enabled TVs), portable computers (such as laptop computers and tablet computers), and other mobile devices, including smartphones and additional examples discussed below. These client devices may operate with a variety of operating environments. For example, some client computers may employ an operating system from Microsoft or Unix operating system or an operating system produced by Apple Computer or Google (such as). These operating environments may be used to execute one or more browsing programs, such as a browser made by Microsoft or Google or Mozilla, or other browser programs that may access websites hosted by Internet servers discussed below.
ATSC 3.0 publication a/344, which is incorporated herein by reference, may be particularly relevant to the techniques described herein.
The ATSC 3.0 source component may comprise a broadcast transmission component and server and/or gateway that may include one or more processors executing instructions that configure the source component to broadcast and/or transmit data over a network such as the internet. By, for example, sonySuch as a game console, personal computer, etc., to instantiate a client component and/or a local ATSC 3.0 source component.
Information may be exchanged between the client and the server over a network. For this purpose and for security, the server and/or client may include firewalls, load balancers, temporary storage and proxy agents, and other network infrastructure for reliability and security.
As used herein, instructions refer to computer-implemented steps for processing information in a system. The instructions may be implemented in software, firmware, or hardware and include any type of programmed steps performed by components of the system.
The processor may be a single-chip or multi-chip processor capable of executing logic through various lines, such as address lines, data lines, and control lines, as well as registers and shift registers.
Software modules described herein by way of flow charts and user interfaces may include various subroutines, procedures, and the like. Without limiting the disclosure, the logic stated as being executed by a particular module may be reassigned to other software modules and/or combined together in a single module and/or available in a shareable library. Although flow chart formats may be used, it should be understood that software may be implemented as a state machine or other logic method.
The present principles described herein may be implemented as hardware, software, firmware, or a combination thereof; thus, the illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality.
In addition to what has been mentioned above, logic blocks, modules, and circuits may be implemented or performed with a general purpose processor, a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), or other programmable logic device such as an Application Specific Integrated Circuit (ASIC), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A processor may be implemented as a combination of controllers or state machines or computing devices.
When implemented in software, the functions and methods described hereinafter may be written in a suitable language such as, but not limited to, hyperText markup language (HTML) -5,/Javascript、C#Or c++, and the functions and methods may be stored on or transmitted through a computer-readable storage medium, such as Random Access Memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), compact disk read-only memory (CD-ROM) or other optical disk storage, such as a Digital Versatile Disk (DVD), magnetic disk storage or other magnetic storage devices, including a removable Universal Serial Bus (USB) thumb drive, and the like. The connection may establish a computer readable medium. By way of example, such connections may include hardwired cables including fiber optic and coaxial lines and Digital Subscriber Lines (DSL) and twisted pairs.
The components included in one embodiment may be used in other embodiments in any suitable combination. For example, any of the various components described herein and/or depicted in the figures may be combined, interchanged, or excluded from other embodiments.
The recitations of "having at least one of A, B and C" (likewise, "having at least one of A, B or C" and "having at least one of A, B, C") include a alone a, a alone B, a alone C, A and B together, a and C together, B and C together, and/or A, B and C together, etc.
The present principles may employ various machine learning models, including deep learning models. Machine learning models consistent with the present principles may use various algorithms trained in a manner that includes supervised learning, unsupervised learning, semi-supervised learning, reinforcement learning, feature learning, self-learning, and other forms of learning. Examples of such algorithms that may be implemented by the circuit include one or more neural networks, such as Convolutional Neural Networks (CNNs), recurrent Neural Networks (RNNs), and one type of RNN known as long-term memory (LSTM) networks. Support Vector Machines (SVMs) and bayesian networks can also be considered examples of machine learning models.
As understood herein, performing machine learning may thus involve accessing a model and then training the model on training data to enable the model to process further data to make inferences. The artificial neural network/artificial intelligence model trained through machine learning may thus include an input layer, an output layer, and a plurality of hidden layers therebetween, which are configured and weighted to infer an appropriate output.
Turning to fig. 1, an example of an ATSC 3.0 source component is labeled "broadcaster apparatus" 10 and may include an over-the-air (OTA) apparatus 12 for broadcasting television data wirelessly, typically in a one-to-many relationship, via Orthogonal Frequency Division Multiplexing (OFDM) to a plurality of receivers 14, such as ATSC 3.0 television. One or more receivers 14 may be accessible byBluetooth low energy, other Near Field Communication (NFC) protocols, infrared (IR), etc. implemented short-range, typically wireless, links 18 communicate with one or more companion devices 16 such as remote controls, headphones, tablet computers, mobile telephones, etc.
Further, one or more receivers 14 may communicate with an over-the-top (OTT) device 22 of the broadcaster device 10 via a wired and/or wireless network link 20, such as the internet, typically in a one-to-one relationship. The OTA device 12 may be co-located with the OTT device 22 or both sides 12, 22 of the broadcaster device 10 may be remote from each other and may communicate with each other by suitable means. In any event, receiver 14 may receive an ATSC 3.0 television signal over the OTA by tuning to an ATSC 3.0 television channel and may also receive related content, including television, over the OTT (wideband). Note that the computerized devices described in all of the figures herein may include some or all of the components set forth for the various devices in fig. 1 and 2.
Referring now to FIG. 2, details of an example of the components shown in FIG. 1 can be seen. Fig. 2 illustrates an example protocol stack that may be implemented by a combination of hardware and software. Using the ATSC 3.0 protocol stack shown in fig. 2 and appropriately modified for the broadcaster side, the broadcaster can send a hybrid service delivery in which one or more program elements are delivered via a computer network (referred to herein as "broadband" and "over the top" (OTT)) and via wireless broadcasting (referred to herein as "broadcast" and "over the air" (OTA)). Fig. 2 also illustrates an example stack with hardware that can be implemented by the receiver.
According to the broadcaster device 10 disclosure of fig. 2, one or more processors 200 accessing one or more computer storage media 202 (such as any memory or storage device described herein) may be implemented to provide one or more software applications in a top application layer 204. The application layer 204 may include one or more software applications running in a runtime environment, written in, for example, HTML 5/Javascript. Applications in the application stack 204 may include, but are not limited to, a linear TV application, an interactive service application, a companion screen application, a personalization application, an emergency alert application, and a usage reporting application. Applications are typically implemented in software that represents elements of the viewer experience, including video encoding, audio encoding, and runtime environments. As an example, applications may be provided that enable a user to control conversations, use alternate tracks, control audio parameters (such as normalization and dynamic range), and so forth.
Below the application layer 204 is a presentation layer 206. On the broadcast (OTA) side, the presentation layer 206 includes a broadcast audio-video playback device called a Media Processing Unit (MPU) 208, which Media Processing Unit (MPU) 208, when implemented in a receiver, decodes and plays back the audio-video content of the wireless broadcast on one or more displays and speakers. The MPU 208 is configured to present an International organization for standardization (ISO) Base Media File Format (BMFF) data representation 210 and video with High Efficiency Video Coding (HEVC) of audio, for example, in dolby Audio compression (AC-4) format. ISO BMFF is a generic file structure for time-based media files that is divided into "segments" and represents metadata. Each file is essentially a collection of nested objects, each object having a type and a length. To facilitate decryption, the MPU 208 may access a broadcast side Encrypted Media Extension (EME)/Common Encryption (CENC) module 212.
Fig. 2 further illustrates: on the broadcast side, the presentation layer 206 may include signaling modules including a Moving Picture Experts Group (MPEG) media transport protocol (MMTP) signaling module 214 or a real-time object delivery over unidirectional transport (ROUTE) signaling module 216 for delivering non-real-time (NRT) content 218 that is accessible to the application layer 204. NRT content may include, but is not limited to, stored replacement advertisements.
On the broadband (OTT or computer network) side, when implemented by a receiver, the presentation layer 206 may include one or more dynamic adaptive streaming over hypertext transfer protocol (HTTP) (DASH) players/decoders 220 for decoding and playing audio-video content from the internet. To this end, DASH player 220 may access broadband side EME/CENC module 222. DASH content may be provided as DASH segments 224 in ISO/BMFF format.
As in the case of the broadcast side, the broadband side of the presentation layer 206 may include NRT content in a file 226 and may also include a signaling object 228 for providing playback signaling.
Below the presentation layer 206 in the protocol stack is a session layer 230. On the broadcast side, the session layer 230 includes an MMTP protocol 232 or a ROUTE protocol 234. Note that the ATSC standard provides the option of using MPEG MMT for transmission, although it is not shown here.
On the broadband side, the session layer 230 includes the HTTP protocol 236, which may be implemented as secure HTTP (S)). The broadcast side of the session layer 230 may also employ an HTTP proxy module 238 and a Service List Table (SLT) 240. The SLT 240 includes a table of signaling information for establishing a basic service list and providing guided discovery of broadcast content. The Media Presentation Description (MPD) is included in a "ROUTE signaling" table delivered by the ROUTE transport protocol over User Datagram Protocol (UDP).
In the protocol stack, the transport layer 242 is below the session layer 230 for establishing low latency and loss tolerant connections. On the broadcast side, the transport layer 242 uses UDP 244, and on the broadband side, the transport layer 242 uses Transmission Control Protocol (TCP) 246.
The example non-limiting protocol stack shown in fig. 2 also includes a network layer 248 below the transport layer 242. Network layer 248 uses Internet Protocol (IP) on both sides for IP packet communications, with multicast delivery being typical on the broadcast side and unicast on the broadband side.
Below the network layer 248 is a physical layer 250, the physical layer 250 including broadcast transmitting/receiving means 252 and computer network interface(s) 254 for communicating over respective physical media associated with both sides. The physical layer 250 converts Internet Protocol (IP) packets to be suitable for transmission over the relevant medium and may add forward error correction functionality to enable error correction at the receiver and include modulation and demodulation modules to incorporate the modulation and demodulation functionality. This converts bits into symbols for long distance transmission and increases bandwidth efficiency. On the OTA side, the physical layer 250 typically includes a wireless broadcast transmitter to wirelessly broadcast data using Orthogonal Frequency Division Multiplexing (OFDM), while on the OTT side, the physical layer 250 includes a computer transmission component to transmit data over the internet.
DASH industry forum (DASH-IF) profiles sent over various protocols (HTTP/TCP/IP) in the protocol stack may be used on the broadband side. Media files in the ISO BMFF based DASH-IF profile may be used as delivery, media encapsulation and synchronization formats for both broadcast and broadband delivery.
Each receiver 14 typically includes a protocol stack that is complementary to the protocol stack of the broadcaster device.
As shown in fig. 2, the receiver 14 in fig. 1 may include an internet-enabled TV with an ATSC 3.0TV tuner (equivalently, a set top box that controls the TV) 256. The receiver 14 may be based onIs a system of (a). Alternatively, the receiver 14 may be implemented by a computerized internet-enabled ("smart") phone, a tablet computer, a notebook computer, a wearable computerized device such as Virtual Reality (VR) goggles or smart glasses, or the like. Regardless, it should be understood that the receiver 14 and/or other computers described herein are configured to perform the present principles (e.g., communicate with other devices to perform the present principles, execute the logic described herein, and perform any other functions and/or operations described herein).
Thus, to perform such principles, the receiver 14 may be established by some or all of the components shown in fig. 1. For example, the number of the cells to be processed, The receiver 14 may include one or more displays 258, the one or more displays 258 may be implemented as a high definition or ultra-high definition "4K" or higher flat screen, and the one or more displays 258 may or may not be touch-enabled for receiving user input signals via touches on the displays. The receiver 14 may also include one or more speakers 260 for outputting audio in accordance with the present principles and at least one additional input device 262 (such as, for example, an audio receiver/microphone) for inputting audible commands to the receiver 14 to control the receiver 14. The example receiver 14 may also include one or more network interfaces 264 for communicating over at least one network (such as the internet, WAN, LAN, PAN, etc.) under the control of one or more processors 266. Thus, interface 264 may be, but is not limited to, a Wi-Fi transceiver, such as, but not limited to, a mesh network transceiver, as an example of a wireless computer network interface. Interface 264 may be, but is not limited toTransceiver, < - > on>Transceivers, infrared data association (IrDA) transceivers, wireless USB transceivers, wired USB, wired LAN, power line, or multimedia over coax alliance (MoCA). It should be appreciated that the processor 266 controls the receiver 14 to perform the present principles, including other elements of the receiver 14 described herein, such as, for example, controlling the display 258 to present images on the display 258 and receive inputs therefrom. Further, note that network interface 264 may be, for example, a wired or wireless modem or router or other suitable interface, such as, for example, a wireless telephone transceiver or Wi-Fi transceiver as described above, or the like.
In addition to the foregoing, the receiver 14 may also include one or more input ports 268, such as a High Definition Multimedia Interface (HDMI) port or a USB port for physically connecting (using a wired connection) to another CE device and/or a headset port for connecting a headset to the receiver 14 to present audio from the receiver 14 to a user through the headset. For example, the input port 268 may be connected via a wire or wirelessly to a satellite source or cable of audiovisual content. Thus, the source may be a separate or integrated set top box or satellite receiver. Alternatively, the source may be a game console or a disk player.
The receiver 14 may also include one or more computer memories 270, such as disk-based or solid state storage that is not a transitory signal, in some cases the one or more computer memories 270 are implemented as stand-alone devices in the chassis of the receiver, or as a personal video recording device (PVR) or video disk player inside or outside the chassis of the receiver for playback of Audio Video (AV) programs, or as a removable memory medium. Further, in some embodiments, the receiver 14 may include a positioning or location receiver 272, such as, but not limited to, a cellular telephone receiver, a Global Positioning Satellite (GPS) receiver, and/or an altimeter, the positioning or location receiver 272 being configured to receive geolocation information, for example, from at least one satellite or cellular telephone tower, and provide the information to the processor 266 and/or in conjunction with the processor 266 determine the altitude at which the receiver 14 is disposed. However, it should be understood that another suitable positioning receiver other than a cellular telephone receiver, a GPS receiver, and/or an altimeter may be used in accordance with the present principles to determine the position of the receiver 14, for example in all three dimensions.
Continuing with the description of the receiver 14, in some embodiments, the receiver 14 may include one or more cameras 274, which one or more cameras 274 may include one or more of the following: a thermal imaging camera, a digital camera (such as a webcam), and/or a camera integrated into the receiver 14 and controllable by the processor 266 to capture pictures/images and/or video in accordance with the present principles. May also include on the receiver 14Transceiver 276 or other Near Field Communication (NFC) element for use with +.>And/or NFC technology with other devices. An example NFC element may be a Radio Frequency Identification (RFID) element.
Further, the receiver 14 may include one or more auxiliary sensors 278 (such as motion sensors, such as accelerometers, gyroscopes, gyrometers, or magnetic sensors and combinations thereof), infrared (IR) sensors for receiving IR commands from a remote control, optical sensors, speed and/or cadence sensors, gesture sensors (for sensing gesture commands), and the like, which provide inputs to the processor 266. An IR sensor 280 may be provided to receive commands from a wireless remote control. A battery (not shown) may be provided to power the receiver 14.
The companion device 16 may contain some or all of the elements shown with respect to the receiver 14 described above.
The methods described herein may be implemented as software instructions executed by a processor, as suitably configured Application Specific Integrated Circuits (ASICs) or Field Programmable Gate Array (FPGA) modules, or in any other convenient manner as will be appreciated by those skilled in the art. Where software instructions are employed, the software instructions may be implemented in a non-transitory device such as a CD ROM or flash drive. Alternatively, the software code instructions may be implemented in a transitory arrangement (such as a radio or optical signal) or via download over the internet.
Referring now to fig. 3, a simplified digital TV system, such as an ATSC 3.0 system, is shown. In fig. 3, a mobile or stationary digital TV receiver (such as ATSC 3.0 receiver 300), which may include any or all of the related components discussed above with respect to fig. 1 and 2, is located in a border region 302 between first and second ATSC 3.0 broadcast stations or components 304, signals from both broadcast stations 304 being picked up by the receiver 300 in region 302. A first ATSC 3.0 service ("service a") is broadcast from a first broadcast station 304 over a first frequency 306 and the same service a is broadcast from a second broadcast station 304 over a second frequency 308 that is different from the first frequency 306. The receiver 300 picks up two frequencies, i.e., the receiver 300 picks up signals from two broadcasting stations 304.
Fig. 4 illustrates an example non-limiting embodiment of a digital TV receiver (such as ATSC 3.0 receiver 400) that may include any or all of the related components discussed above with respect to fig. 1 and 2. In the example shown, ATSC 3.0 receiver 400 may be a stationary receiver, such as a receiver located inside a home. In some examples, ATSC 3.0 receiver 400 may be a mobile receiver, for example, as implemented in a mobile phone or disposed in a moving vehicle.
The example ATSC 3.0 receiver 400 shown in fig. 4 includes a tuner 402, which tuner 402 transmits signals picked up by the tuner from one or more antennas 406 to a demodulator 404. In the example shown, receiver 400 includes one and only one tuner, one and only one demodulator, and one and only one antenna.
In contrast, fig. 5 illustrates an example non-limiting embodiment of a digital TV receiver (such as ATSC 3.0 receiver 500) that may include any or all of the related components discussed above with respect to fig. 1 and 2. In the example shown, ATSC 3.0 receiver 500 may be a mobile receiver, for example, as implemented in a mobile phone or disposed in a moving vehicle. In some examples, ATSC 3.0 receiver 500 may be a stationary receiver, such as a receiver located inside a home.
The example ATSC 3.0 receiver 500 shown in fig. 5 includes a plurality of tuners 502 that transmit signals picked up by the tuners from one or more antennas 506 to respective demodulators 504. In the non-limiting example shown, ATSC 3.0 receiver 500 has two tuners and two demodulators, it being understood that the receiver may have a greater or lesser number of tuners/demodulators. In the non-limiting example shown, ATSC 3.0 receiver 500 has four antennas, it being understood that the receiver may have a greater or lesser number of antennas. The receiver 500 may have the capability to switch the antenna inputs to the tuners such that a first tuner may receive signals from, for example, three antennas and a second tuner may receive signals from a fourth antenna, and then may switch to exchange antenna inputs between tuners. Two antennas may provide inputs to each respective tuner. All four antennas may provide inputs to a single tuner. These and other antenna-tuner configurations may be dynamically changed during operation as desired. It should be noted that receiver 500 may maintain broadband connection 250 with telephone, WI-FI, or satellite data services, although different configurations using terrestrial antennas are contemplated for receiving OTA signals.
Any of the above devices, systems, and configurations may be used to implement the techniques herein.
As set forth in more detail below, the techniques for repairing content described herein utilize a plurality of buffers that are sequentially arranged and divided into separate blocks of memory. In all of the various ATSC 3.0 transmission scenarios, ATSC link layer protocol (ALP) packets are used to transmit content and related metadata. For example, buffer 1 receives incoming and UDP/IP content using ALP packets. This is the layer above the Physical Layer Pipe (PLP). There is often a low-level demodulator-to-memory connection that allows content to be received into the buffer 1 without too many processors 200 being involved other than the settings. Buffer 1 may be monitored to determine how much data it contains to determine when the amount of data meets a threshold, such as 80% full or 100% full or other threshold. Packets with errors may be marked in memory by setting an error indicator bit associated with each ALP packet. When a packet fails a Cyclic Redundancy Check (CRC), the demodulator may typically set the value of this bit when it is received. And the lost packet may be marked as a null packet. When full or otherwise containing an amount of data that meets the threshold, buffer 1 may be reinitialized by processor 200 with a new memory pointer to free up, for example, reclaimed memory. In the repair scenario outlined herein, the memory for buffer 1 is now buffer 2. In general, the buffer 2 may be linked to a decompression engine. In this case, however, the repair process requires the processor to examine each packet in the buffer 2 to see if there is a set error indicator bit indicating that the FEC is unable to correct one or more errors and that the received resulting data fails the hardware checksum operation. The processor may determine whether the repair operation is significant. If it is just one packet, a simple error concealment in decompression may be sufficient. The processor may take action if multiple packets have errors or are lost. Because the same content is not processed in the broadcast system in exactly the same way due to possible transcoding differences in order to save bandwidth by different transmission systems, it is safest that the processor replaces packets of the group of pictures starting with the start of frame (SOF) of an intra-coded frame (I-frame) before the lost packet or the packet with the error and all packets containing B-frames and P-frames. The audio is not compressed as severely. And all audio packets received with the affected video packets may be replaced as desired.
The data is processed by a repair application that examines the content segments to locate lost or corrupted content segments (and attempts to replace them from an adjoining service transmission (which may be tuned in parallel) or through the internet (transmitted back to the broadcaster broadband OTT service 22)), and the buffer 3 is a buffer with content in the best repair state ready to be sent to the decompression or storage engine. When buffer 3 is exhausted, its pointer is zeroed and it becomes buffer 1 to accept new content. The memory is thus partitioned and certain applications are locked out of contiguous memory that is not in its task allocation. In practice it is possible that there are 4 buffers. When buffer 3 is used up it becomes a temporary buffer, buffer 4, which may become buffer 1 (when the incoming write to buffer 1 has terminated).
The present technique repairs errors from noise and lost packets, and from content available from another antenna/demodulator in the same receiver or from the internet (e.g., broadcaster or aggregator web content 22), if possible. This must be done while the content is continuously streaming into the receiver and being rendered on the display or stored to memory 270. The buffer should be large enough to accommodate the time required to process the repair buffer to determine lost content and request and receive repair data from the remote server or to retrieve content from a separate memory connected to the second tuner/demodulator. This is generally less expensive than retrieving repair data from a cellular or satellite network.
Fig. 6 illustrates one or more memories 600 that may be accessed by one or more processors 602 in a digital TV receiver (such as any of the receivers discussed herein, e.g., multi-tuner/demodulator receiver 500 in fig. 5) to receive and process broadcast digital TV (such as ASC 3.0) content packets 604. Memory 600 includes at least three buffers in one example, and four buffers 1-4 (labeled 606, 608, 610, and 612 in FIG. 6) in the example shown. Each buffer is assigned a persistent memory register, registers 0 through N-1 for first buffer 606, registers N through M-1 for second buffer 608, registers M through P-1 for third buffer 610, and registers P through Q for fourth buffer 612, respectively. Applications executed by the processor 602 to operate on the respective functions of the respective buffers are not allowed to access memory addresses of other buffers at the same time.
Thus, the processor concurrently executes a first application to execute packet reception logic in the first buffer 606 as described in fig. 7, a second application to execute packet repair logic in the second buffer 608 as described in fig. 8, and a third application to execute packet readout logic in the third buffer 610 as described in fig. 9, which applications are not allowed to access other buffers until the other buffers loop to the appropriate function, as further described below.
The data read from the third buffer may be sent to a decompression engine 614 or other suitable processing component (such as a storage engine 615) for final display of the content on a display 616 (such as any of the displays herein).
Thus, the first application may be allocated the memory registers of the first buffer when the first buffer receives packets, and may be locked out of the memory registers of the second and third buffers during this time. The second application and the third application are allocated memory registers of the second buffer and the third buffer, respectively, during this time. Then, when the first buffer is full or contains enough data to meet a threshold (such as a high percentage of full, e.g., 90% full) and take the role of the second buffer, the first application may be locked out of the memory register of the first buffer and may be allocated the memory register of a new buffer (e.g., a third buffer or a fourth buffer when provided) to receive the incoming packet. According to this conversion, the second application (error correction) is allocated the memory register of the first buffer and locked out of the other buffers, while the third application (data readout to decompressor) is allocated the memory register of the second buffer, which is now corrected, and locked out of the other buffers. This transition for the application's memory register allocation continues as content flows in, and each buffer transition occurs to prevent contention between applications.
Beginning at block 700 in fig. 7, packets of broadcast data (or depacketized content data received via broadcast) are delivered to a first buffer. At block 702, the first buffer may detect and signal whether any errors are detected, such as corrupted or lost data. Decision diamond 704 indicates: this process continues until the buffers have enough data to meet the threshold (such as by being full), at which point the logic moves to block 706, at which point the first buffer assumes the error correction function of the second buffer, the second buffer loops from the error correction to the read function of the third buffer, and the third buffer loops from the read function to the receive function of the first buffer. In some cases, a fourth "spare" buffer may be provided to take over the receiving function of the first buffer before the third buffer has completed its data readout.
Thus, in fig. 7, the IP addresses may be filtered and the receiver hardware configured to deliver ATSC 3.0IP packets directly to the particular memory range that includes the first buffer 606. The hardware signals an error on any packet received in memory. The buffer may be an interrupt driven buffer or a poll driven buffer. When the first buffer 606 is full or otherwise contains enough data to meet the threshold, it is marked as a second buffer 608 (assuming the role of the second buffer 608), the second buffer 608 is marked as a third buffer 610 (assuming the role of the third buffer 610), and the third buffer is marked as a first buffer or (when a fourth buffer 612 is provided) a fourth buffer 612 (assuming the role of the first buffer or the fourth buffer 612).
FIG. 8 illustrates error correction logic of a second application operating on a buffer that is filled and ready for error correction. Block 800 indicates identifying whether the hardware signaled any errors when the buffer was filled with data. If an error is not signaled, the logic ends. However, assuming that errors are signaled, the logic moves to decision diamond 802 to determine if replacement content is available for any signaled errors. If the replacement content is not available, at block 804, the content is not modified and such results may be signaled to the decompression engine to allow the decompression engine to attempt to mask or conceal any errors in the content. Additionally or alternatively, the data may be sent along this path of logic to a storage engine, such as storage engine 615 in fig. 6.
On the other hand, if alternative content is available, the logic flows to block 806 to retrieve the alternative content from another broadcast frequency, e.g., being received over the OTA and carrying the same service as the service being processed, or from the broadcaster over a broadband, as may occur, for example, in border region 302 in FIG. 3. Recall that such a repeated stream may be received by a second tuner/demodulator pair such as that shown in fig. 5. Alternatively, the replacement content may be obtained from an aggregator or broadcaster's web server via OTT. At the appropriate location of the corrupted data, the replacement content is inserted into the data and the corrupted data is removed.
In replacing the content, it is possible to identify what a particular error is, what data is lost, whether the entire group of pictures in which a corrupted or lost packet is found needs to be replaced as is usual. This process requires locating the group of images in the received second stream or in the broadcaster content cache. It may need to locate the particular IP packet where the frame start is located and start there from, etc.
At block 808, blocks of content may be moved around and added to the acquired content to create the contiguous memory required by the decompression logic of fig. 9 executed by a third one of the applications described above.
In effect, FIG. 9 illustrates that a third application communicates with decompression engine 614 in FIG. 6 at block 900 to supply the decompression engine hardware with the memory register identification of the buffer that has just completed error correction from the logic of FIG. 8. Block 902 indicates that the application signals to the decompression or storage engine that new content is available for readout for decompression and display or storage, and the decompression engine decompresses the data from the buffer and provides it to the display 616 in fig. 6. This is typically a "fire and forward" operation. The same applies to the operation of writing the content to the memory 270.
It should be understood that while the present principles have been described with reference to some example embodiments, these are not intended to be limiting and various alternative arrangements may be used to implement the subject matter claimed herein.