CN116830587A - Stream repair memory management - Google Patents

Stream repair memory management Download PDF

Info

Publication number
CN116830587A
CN116830587A CN202280012567.3A CN202280012567A CN116830587A CN 116830587 A CN116830587 A CN 116830587A CN 202280012567 A CN202280012567 A CN 202280012567A CN 116830587 A CN116830587 A CN 116830587A
Authority
CN
China
Prior art keywords
buffer
dtv
data elements
receiver
dtv data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202280012567.3A
Other languages
Chinese (zh)
Inventor
B·坎德洛尔
A·戈德堡
F·安斯菲尔德
G·克利夫特
L·F·皮内达
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Group Corp
Original Assignee
Sony Group Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US17/506,592 external-priority patent/US11792473B2/en
Application filed by Sony Group Corp filed Critical Sony Group Corp
Priority claimed from PCT/IB2022/057325 external-priority patent/WO2023012751A1/en
Publication of CN116830587A publication Critical patent/CN116830587A/en
Pending legal-status Critical Current

Links

Landscapes

  • Circuits Of Receivers In General (AREA)

Abstract

Techniques for extending and/or improving the Advanced Television Systems Committee (ATSC) 3.0 television protocol in terms of robustly delivering next generation broadcast television services are described. Multiple memory buffers are used to manage broadcast packet repair and presentation or storage.

Description

Stream repair memory management
Technical Field
The present application relates to technological advances that necessarily stem in computer technology and are directed to digital television, and more particularly, to Advanced Television Systems Committee (ATSC) 3.0.
Background
The Advanced Television Systems Committee (ATSC) 3.0 standard suite is a collection of more than ten industry technology standards for delivering next generation broadcast television as indicated in a/300. ATSC 3.0 supports delivery of a wide range of television services (including television video, interactive services, non-real-time delivery of data, and customized advertising) to a large number of receiving devices (from ultra-high definition televisions to wireless telephones). ATSC 3.0 also schedules coordination between broadcast content (referred to as "over the air" or OTA) and related broadband delivery content and services (referred to as "over the top" or OTT). ATSC 3.0 is designed to be flexible so that as technology evolves, advances can be easily incorporated without requiring any thorough modification of the relevant technology standards.
As understood herein, an ATSC 3.0 receiver scans for services in a Single Frequency Network (SFN) or a multi-frequency network (MFN). In addition, when neither type of frequency network is available, the ATSC 3.0 receiver can receive a service through a broadband. The receiver may attempt to render the content to the display in real time or record the content to the storage device.
Disclosure of Invention
As further understood herein, when broadcast content is received, it is processed and corrected for errors. The ATSC broadcast stream has built-in Forward Error Correction (FEC) in the modulation scheme employed that will repair many single bit errors in the ATSC link layer packet (ALP). A multi-bit or lost packet is a serious error that may occur in boundary conditions where the signal path is degraded or where there is a loss of signal lock. These types of errors cannot be repaired with FEC. As appreciated herein, it is desirable to improve such content by replacing lost or uncorrectable packets prior to rendering or writing to storage. This process needs to check the content for errors and then decide whether extensive repair processing should be initiated or what the main broadcast feed is likely to be reselected, e.g., whether a second frequency is present in the MFN. Even if a comparable service exists on the second frequency, it may be determined that the access is temporary and the main broadcast feed should not change. However, if repair is to be attempted, it typically involves replacing not just the lost or erroneous packets, but all the packets associated with the group of frames in which those packets are located. These may be taken from packets obtained from the service on the second frequency or, if the second frequency is not available, from packets obtained over the broadband. Repair applications require unrestricted access to the content store. However, concurrent writing to the content memory by different software applications or hardware circuits running on the same device and attempting to access the same memory may cause problems. More specifically, when one software application or hardware circuit is accessing memory, it may lock the memory for other applications or hardware circuits. This means that there may be competition between applications or hardware circuits, such as when applications involving repair need to replace lost or corrupted content segments, while receiving applications or circuits need to store incoming content segments, and rendering or storing applications or circuits need to access the memory for decompression and playback purposes or longer term storage (e.g., hard disk drives or solid state drives), thereby competing for access to the same memory.
Accordingly, in a digital television in which at least one receiver is capable of receiving broadcast signals, a method includes: broadcast Digital Television (DTV) data elements are received in a buffer. The method comprises the following steps: identifying whether any replacement content for packet errors in DTV data elements in the buffer is available in response to the buffer containing an amount of data that meets a threshold; and responsive to the alternate content being available, repairing at least the first DTV data element in the buffer. The method further comprises the steps of: the DTV data elements in the buffer are transmitted to at least one decompression or storage engine to process the DTV data elements for presentation on at least one display or for storage to a recording medium.
In some embodiments, the method may include: signaling (signal) to a decompression or storage engine that at least the second DTV data element contains at least one error in response to the alternate content of the second DTV data element being unavailable.
In an example implementation, the DTV data elements may include DTV packets.
In an example embodiment, the buffer is a first buffer having a first range of memory addresses, and the method includes: errors in the DTV data elements are repaired in a second buffer having a second range of memory addresses when the DTV data elements are being received into the first buffer before the first buffer is full. In some implementations, when a DTV data element is being received into a first buffer and an error is being repaired in a second buffer before the first buffer is full, the method includes: the DTV data elements are transmitted from the third buffer to a decompression or storage engine. The third buffer has a third range of memory addresses. When the third buffer is empty, its memory pointer is changed to the memory pointer for the second buffer. Then, it is assumed that after completing the repair of the error in the DTV data element in the second buffer, the DTV data element from the second buffer and now in the third buffer may be transferred to a decompression or storage engine.
The memory addresses of the buffers are all different from each other and do not overlap each other as needed. The pointers to the various buffers may be changed as desired. When the first buffer contains an amount of data that meets the threshold, such as when the buffer is full, it becomes the second buffer. The repair application may be given a memory location point of what was the first buffer. The buffer may be given a termination address or buffer size. The pointer of the older second buffer is now given to the application involving rendering-where the second buffer now becomes the third buffer. The old third buffer with the old content can now become the available buffer to become the first buffer for receiving incoming packets.
In another aspect, a Digital Television (DTV) apparatus includes: at least one Digital Television (DTV) receiver, and at least one processor programmed with instructions to configure the processor to: controlling at least the first buffer, the second buffer, and the third buffer to simultaneously receive broadcast Digital Television (DTV) data elements, repair the DTV data elements, and transmit the DTV data elements to a processing engine for presentation of content represented in the DTV data elements on at least one display or storage to a recording medium, respectively.
In another aspect, an apparatus includes: at least one processor configured to: a received broadcast Digital Television (DTV) is cycled between at least three buffer operations including reception, error correction, and data readout. Each buffer operation is performed sequentially in each of at least a first buffer, a second buffer, and a third buffer with a respective memory register allocation. The processor is configured to: contention for buffer usage is prevented between applications performing buffer operations.
The details of the present application, both as to its structure and operation, can best be understood in reference to the accompanying drawings, in which like reference numerals refer to like parts, and in which:
drawings
FIG. 1 illustrates an Advanced Television Systems Committee (ATSC) 3.0 system;
FIG. 2 illustrates components of the device shown in FIG. 1;
FIG. 3 illustrates an example particular system;
fig. 4 illustrates a first example embodiment of a digital TV receiver;
FIG. 5 illustrates a second exemplary embodiment of a digital TV receiver;
FIG. 6 illustrates an example particular receiver memory system;
FIG. 7 illustrates example logic of an example flow diagram format of a first buffer;
FIG. 8 illustrates example logic of an example flow diagram format of a second buffer; and is also provided with
FIG. 9 illustrates example logic of an example flow diagram format of a third buffer;
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.

Claims (20)

1. In a digital television in which at least one receiver is capable of receiving broadcast signals, a method comprising:
receiving broadcast Digital Television (DTV) data elements in a buffer;
identifying whether any replacement content for packet errors in DTV data elements in the buffer is available in response to the buffer containing an amount of data that meets a threshold;
responsive to the alternate content being available, at least repairing the first DTV data element in the buffer; and
the DTV data elements in the buffer are transmitted to at least one decompression or storage engine to process the DTV data elements for presentation or storage.
2. The method according to claim 1, comprising: in response to the alternate content of the second DTV data element being unavailable, signaling to a decompression or storage engine that at least the second DTV data element contains at least one error.
3. The method of claim 1 wherein the DTV data elements comprise DTV packets.
4. The method of claim 1, wherein the buffer is a first buffer comprising a first range of memory addresses, and the method comprises: errors in the DTV data elements are repaired in a second buffer comprising a second range of memory addresses when the DTV data elements are being received into the first buffer before the first buffer is full.
5. The method of claim 4, wherein the method comprises: when a DTV data element is being received into the first buffer and an error is being repaired in the second buffer before the first buffer is full, the DTV data element is transferred from the third buffer to the decompression or storage engine, the third buffer including a third range of memory addresses.
6. The method of claim 5, comprising: after completion of the repair of the error in the DTV data element in the second buffer, the DTV data element is transmitted from the second buffer to the decompression or storage engine.
7. The method of claim 6, comprising: after completing the transfer of the DTV data elements from the third buffer, the DTV data elements are received into the third buffer.
8. The method of claim 1 wherein the DTV receiver comprises an Advanced Television Systems Committee (ATSC) 3.0 receiver.
9. A Digital Television (DTV) apparatus, comprising:
at least one Digital Television (DTV) receiver; and
at least one processor associated with the DTV receiver and programmed with instructions to configure the processor to:
controlling at least the first, second and third buffers to simultaneously receive broadcast Digital Television (DTV) data elements, repair the DTV data elements, and communicate the DTV data elements to a processing engine for presentation of content represented in the DTV data elements on at least one display or storage of content represented in the DTV data elements, respectively.
10. The DTV device of claim 9, wherein the instructions are executable to:
receiving DTV data elements in a first buffer;
identifying whether any replacement content for packet errors in DTV data elements in the first buffer is available in response to the first buffer containing an amount of data that meets a threshold;
responsive to replacement content being available, at least repairing the first DTV data element in the first buffer; and
the DTV data elements in the first buffer are communicated to a processing engine.
11. The DTV device of claim 10, wherein the instructions are executable to:
in response to the alternate content of the second DTV data element being unavailable, signaling to the processing engine that at least the second DTV data element contains at least one error.
12. The DTV device of claim 9, wherein the DTV data elements comprise DTV packets.
13. The DTV device of claim 9, wherein the first buffer comprises a first range of memory addresses, and the instructions are executable to:
errors in the DTV data elements are repaired in a second buffer, the second buffer comprising a second range of memory addresses, when the DTV data elements are being received into the first buffer before the first buffer is full.
14. The DTV device of claim 13, wherein the instructions are executable to: when a DTV data element is being received into the first buffer and an error is being repaired in the second buffer before the first buffer is full, the DTV data element is transferred from the third buffer to the processing engine, the third buffer including a third range of memory addresses.
15. The DTV device of claim 14, wherein the instructions are executable to: after completion of the repair of the error in the DTV data element in the second buffer, the DTV data element is transmitted from the second buffer to the processing engine.
16. The DTV device of claim 15, wherein the instructions are executable to: after completing the transfer of the DTV data elements from the third buffer, the DTV data elements are received into the third buffer.
17. The DTV device of claim 9, wherein the DTV receiver comprises an Advanced Television Systems Committee (ATSC) 3.0 receiver.
18. An apparatus, comprising:
at least one processor configured to:
cycling a received broadcast Digital Television (DTV) between at least three buffer operations including reception, error correction, and data readout, each buffer operation being sequentially performed in each of at least a first buffer, a second buffer, and a third buffer having respective memory register allocations; and
Contention for buffer usage is prevented between applications performing buffer operations.
19. The apparatus of claim 18, wherein the apparatus comprises an Advanced Television Systems Committee (ATSC) 3.0 receiver.
20. The apparatus of claim 18, wherein the processor is configured to: the first, second, and third buffers are controlled to simultaneously receive broadcast Digital Television (DTV) data elements, repair the DTV data elements, and transmit the DTV data elements to the processing engine for presentation or storage of content, respectively.
CN202280012567.3A 2021-08-06 2022-08-05 Stream repair memory management Pending CN116830587A (en)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US63/260,022 2021-08-06
US17/506,592 2021-10-20
US17/506,592 US11792473B2 (en) 2021-08-06 2021-10-20 Stream repair memory management
PCT/IB2022/057325 WO2023012751A1 (en) 2021-08-06 2022-08-05 Stream repair memory management

Publications (1)

Publication Number Publication Date
CN116830587A true CN116830587A (en) 2023-09-29

Family

ID=88128036

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202280012567.3A Pending CN116830587A (en) 2021-08-06 2022-08-05 Stream repair memory management

Country Status (1)

Country Link
CN (1) CN116830587A (en)

Similar Documents

Publication Publication Date Title
US11323768B2 (en) Reducing latency during service change and improving robustness in advanced television systems committee (ATSC) 3.0 system
US11729456B2 (en) Long duration error correction with fast channel change for ATSC 3.0 real-time broadcast mobile application
US11825155B2 (en) ATSC boundary condition fall over to internet
US11553245B1 (en) Techniques for receiving non-real time (NRT) data whilst traversing a multi-frequency network boundary
US11792473B2 (en) Stream repair memory management
CN116830587A (en) Stream repair memory management
JP2024531929A (en) Stream Repair Memory Management
WO2023012751A1 (en) Stream repair memory management
US20240281164A1 (en) Method for signaling memory requirements in atsc3.0 when out-of-order data is being utilized
US11611792B2 (en) ATSC 3 reception across boundary conditions using location data
US11838680B2 (en) Techniques for ATSC 3.0 broadcast boundary area management using complete service reception during scan to determine signal quality of frequencies carrying the duplicate service
US11848716B2 (en) Techniques for ATSC 3.0 broadcast boundary area management using signal quality and packet errors to differentiate between duplicated services on different frequencies during scan
US11711568B2 (en) Techniques for ATSC 3.0 broadcast boundary area management using plural tuners handing off between presentation and scanning
US20240107111A1 (en) Digital tv reception using ott backchannel communication
US11601707B2 (en) Techniques for ATSC 3.0 broadcast boundary area management using plural tuners
US11159831B2 (en) Non-real time (NRT) memory management in advanced television systems committee (ATSC) 3.0 system
US20240283464A1 (en) Robustness when using application layer forward error correction (al-fec) in an atsc3 receiver
WO2024175991A1 (en) Method for signaling memory requirements in atsc3.0 when out-of-order data is being utilized
WO2023012750A1 (en) Improving atsc 3 reception across boundary conditions using location data
WO2023012732A1 (en) Techniques for atsc 3.0 broadcast boundary area management using complete service reception during scan to determine signal quality of frequencies carrying the duplicate service
CN116868524A (en) ATSC 3 reception using location data to improve cross boundary conditions
WO2023012748A1 (en) Techniques for receiving non-real time (nrt) data whilst traversing a multi-frequency network boundary
WO2024175990A1 (en) Improving robustness when using application layer forward error correction (al-fec) in an atsc3 receiver
WO2023012756A1 (en) Techniques for atsc 3.0 broadcast boundary area management using plural tuners handing off between presentation and scanning
CN116724554A (en) ATSC 3 application context switching and sharing

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination