CN120642216A

CN120642216A - Method for signaling memory requirements in ATSC 3.0 when utilizing out-of-order data

Info

Publication number: CN120642216A
Application number: CN202380093342.XA
Authority: CN
Inventors: G·克利夫特; L·费伊
Original assignee: Sony Group Corp
Current assignee: Sony Group Corp
Priority date: 2023-02-22
Filing date: 2023-12-13
Publication date: 2025-09-12
Also published as: WO2024175991A1; EP4646792A1

Abstract

Techniques for extending and/or improving the Advanced Television Systems Committee (ATSC) 3.0 television protocol to robustly deliver next generation broadcast television services are described. To increase the robustness of the data broadcast files to a memory limited platform, each file is divided into partitions, and then the packets in the partitions are arranged out of order (OOO), and then the partitions are sent in sequence, with the respective packets of the partitions being OOO.

Description

Method for signaling memory requirements at ATSC3.0 when out-of-order data is utilized

Technical Field

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

Background

The Advanced Television Systems Committee (ATSC) 3.0 standard suite is a set of more than ten industry technology standards as shown in a/300 for providing next generation broadcast television. ATSC 3.0 supports the provision of a wide range of television services including video for television play, interactive services, non-real time delivery of data, and custom advertising for a large number of receiving devices from ultra-high definition televisions to radiotelephones. ATSC 3.0 also orchestrates the coordination between broadcast content (referred to as "over the air") and related broadband delivered content and services (referred to as "over the top"). ATSC 3.0 is designed to be flexible so that as technology advances can be easily incorporated without requiring thorough modification of any of the relevant technology standards.

As understood herein, ATSC 3.0 can be used to communicate data to a mobile receiver, such as to a mobile vehicle for example, a map or an operator manual. For file transfer, as further understood herein, any packet loss can result in corruption. The present principles introduce error correction techniques to improve the reception of data for all files, including video media.

Disclosure of Invention

As understood herein, application layer forward error correction (AL-FEC) in ATSC3 is specified in ATSC standard a/331 to use the error correction technique described in publication RFC 6330 ("RaptorQ"). To take into account the possibility of file transfer in case of temporary blocking of reception, such as when the mobile receiver passes through a tunnel or in other echo or signal loss areas, in order to increase robustness, all packets of the transmitted file may be transmitted out of order (OOO), or the parts of the file may be separated in time. Thus, during blocking, the loss is limited to a small portion of the file, where fewer repair bits can correct lost or corrupted packets.

However, as recognized herein, sending a packet in an OOO manner across an entire file means that it is not known where in memory the next packet is located. Discontinuous data is typically stored in non-persistent memory, such as RAM, because the persistent memory (e.g., flash memory) that holds the individual packets to a random access location is typically too slow for typical data reception rates provided by ATSC 3.0. This means that non-persistent memory up to the file length is required for OOO packet delivery without repair, which may not be feasible for some receivers (limited storage capacity). In addition, source data that can be repaired requires the generation of intermediate symbols that are additionally stored in non-persistent memory. Performing fountain code based repairs (RAPTOR-Q) is CPU intensive, requiring timely processing of source data along with repair data, while persistent storage such as flash memory can extend the length of time for repairs.

Thus, the present principles recognize the advantages of first decomposing a data file into partitions and then randomly ordering the packets in an OOO fashion for each partition. By partitioning the OOO packet transfer, it is known that successive blocks (partitions) of data are transferred OOO at any time, which reduces non-persistent memory requirements. The memory requirements should still be sufficient to contain two partitions, one for the data currently being received and the other for simultaneously moving the previously received data to persistent memory in order to free up memory for the next partition. Thus, for example, repair of data in non-persistent memory requires two partitions plus repair data (e.g., 2x percent repair). With 10% repair, the memory requirement becomes 2.2 times the partition size. In the case where the receiver generates intermediate symbols for repair when receiving the source symbols, then the memory requirement is four times that of the partition.

Ideally, the receiver will also retain some of the data attributed to the receiving a partition that is incomplete starting from the middle of the partition. This example sets the non-persistent memory requirement to 3 partitions plus repair data, or 6 times, if intermediate symbols are being generated, so that the first received partition can be filled with lost data while the second file is carousel. In any case, the total RAM memory may be much smaller than the size required to store the entire file sent in packet OOO. The time required for the receiver to move the data from the non-persistent memory to the persistent memory, if needed to repair the data, can be estimated based on the bit rate and partition size.

In a first aspect, a method in a digital television includes dividing at least one file into a plurality of partitions. The method includes, within each partition, ordering out-of-order (OOO) packets for that partition, and sequentially transmitting the resulting partitions to at least one receiver, wherein the respective packets for the partitions are OOO.

In some embodiments, the method may include interleaving a plurality of source blocks of the file with repair symbols, wherein each partition includes the plurality of source blocks.

In an example implementation that includes repair, a file has Z source blocks, where Z is greater than or equal to an integer-up value (lifting) of F/T divided by k _max, where k _max represents the number of symbols in each source block, T is the number of bytes in each symbol, and F is the size of the file. At least some of the partitions include Zl source blocks, where Zl is equal to Z divided by the ceiling of P _n, where P _n is the total number of partitions. In another aspect, the at least one partition may include Z _s source blocks, where Z _s is equal to the downward rounding of Z divided by P _n. Rounding up means rounding up to the nearest integer, and rounding down means rounding down to the nearest integer.

In another aspect, a digital television apparatus includes at least one receiver configured to receive digital television from a digital television transmitter system. The receiver in turn includes at least one processor programmed with instructions for receiving at least some of a plurality of partitions of at least one file into non-persistent memory, each partition including out-of-order packets (OOOs). The instructions are executable to order the packets into a correct order, send at least one partition in the non-persistent memory to the persistent memory, and receive additional partitions into the non-persistent memory.

In another aspect, a digital television apparatus includes at least one transmitter, which in turn includes at least one processor programmed with instructions to configure the processor to divide at least one file into a plurality of partitions, and within each partition, arrange the groupings of the partitions out of order (OOO). The instructions are executable to sequentially transmit the partitions to at least one receiver while their respective packets are OOO.

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 apparatus shown in FIG. 1;

FIG. 3 illustrates an example transmitter side architecture;

FIG. 4 illustrates an example receiver-side architecture;

FIG. 5 illustrates schematic partitions sent in sequence, with their internal packets arranged out of order (OOO);

FIG. 6 illustrates example transmitter logic in an example flow chart format;

FIG. 7 illustrates example receiver logic in an example flow chart format;

FIG. 8 illustrates source blocks of a file;

FIG. 9 illustrates a partition including the source block of FIG. 8, and

FIG. 10 illustrates OOO transfer with repair data and partitions.

Detailed Description

The present disclosure relates to technological advances in digital television, such as Advanced Television Systems Committee (ATSC) 3.0 television. 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 notebook computers and tablet computers, and other mobile devices including smart phones and other examples discussed below. These client devices may operate using 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, inc. or google, such asThese operating environments may be used to execute one or more browsing programs, such as a browser manufactured 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/331, which is incorporated herein by reference, appendix a may be particularly relevant to the techniques described herein.

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

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

Instructions as used herein 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 programming steps assumed by the components of the system.

The processor may be a single-chip or multi-chip processor that may execute logic through various lines such as address lines, data lines, and control lines, as well as registers and shift registers.

The software modules described herein by the flowcharts 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 redistributed 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 in hardware, software, firmware, or a combination thereof, and thus, the illustrative components, blocks, modules, circuits, and steps are presented in terms of their functionality.

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

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

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

"Element 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") includes a alone, B alone, C, A alone and B together, a and C together, B and C together, and/or A, B and C together, and the like.

Turning to fig. 1, an example of an ATSC 3.0 source component is labeled "broadcast device" 10 and may include an Over The Air (OTA) device 12 for broadcasting television data wirelessly, typically via Orthogonal Frequency Division Multiplexing (OFDM), in a one-to-many relationship to a plurality of receivers 14, such as ATSC 3.0 televisions. The receiver 14 may have non-persistent storage 14A, such as some type of solid state RAM, and persistent storage 14B, such as flash memory. One or more of the receivers 14 may communicate with one or more of the companion devices 16 (e.g., remote control, tablet, mobile phone, etc.) via a short-range, generally wireless link 18, the link 18 may be viaBluetooth low energy, other Near Field Communication (NFC) protocols, infrared (IR), etc.

Further, one or more of the receivers 14 may communicate with an over-the-top (OTT) device 22 of the broadcast 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 broadcast device 10 may be remote from each other and may communicate with each other by suitable means. In any event, receiver 14 may receive ATSC 3.0 television signals over the air by tuning to an ATSC 3.0 television channel and may also receive related content, including television, OTT (wideband). Note that the computerized devices depicted in all of the figures herein may include some or all of the components set forth for the various devices in fig. 1 and 2.

Referring now to FIG. 2, details of an example of the assembly 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 modified as appropriate for the broadcaster side, the broadcaster can send a hybrid service delivery in which one or more program elements are transmitted 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"). Fig. 2 also illustrates an example stack with hardware that may be embodied by the receiver.

From the perspective of the broadcast device 10, fig. 2 is disclosed, one or more processors 200 accessing one or more computer storage media 202 (such as any memory or storage 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 written in, for example, HTML5/Javascript running in a runtime environment. 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 embodied in software that represents elements of the viewer experience, including video encoding, audio encoding, and runtime environments. For 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 audiovisual playback device called a Media Processing Unit (MPU) 208, which when implemented in a receiver, the MPU 208 decodes and plays back the wirelessly broadcasted audiovisual content 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 High Efficiency Video Coding (HEVC) video with audio in, for example, dolby Audio compression (AC-4) format. ISO BMFF is a generic file structure for time-based media files that are divided into "segments" and represent 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 that 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 distribution over unidirectional transport (ROUTE) signaling module 216 for distributing 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 is the case on the broadcast side, the broadband side of presentation layer 206 may include NRT content in file 226 and may also include signaling objects 228 for providing playback signaling.

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

On the broadband side, the session layer 230 includes the HTTP protocol 236, which may be implemented as HTTP-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 signaling information table for constructing a basic service list and providing guided discovery of broadcast contents. The Media Presentation Description (MPD) is contained in a "ROUTE signaling" table conveyed by the ROUTE transport protocol over User Datagram Protocol (UDP).

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

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) for IP packet communications on both sides, 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 devices 252 and a computer network interface 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 combine the modulation and demodulation functionality. This converts bits to symbols for long distance transmission and improves bandwidth efficiency. On the OTA side, the physical layer 250 typically includes a wireless broadcast transmitter that wirelessly broadcasts data using Orthogonal Frequency Division Multiplexing (OFDM), while on the OTT side, the physical layer 250 includes a computer transmission component that transmits 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 ISO BMFF based DASH-IF profiles may be used as delivery, media encapsulation and synchronization formats for broadcast and broadband delivery.

Each receiver 14 typically includes a protocol stack that is complementary to the protocol stack of the broadcast device.

As shown in fig. 2, the receiver 14 in fig. 1 may include an internet-enabled TV with an ATSC 3.0TV tuner (equivalent to a set top box that controls the TV) 256. The receiver 14 may be based onIs a system of (a). Or the receiver 14 may be implemented by a computerized internet ("smart") enabled telephone, tablet, notebook, wearable computerized device, or the like. Regardless, it should be understood that the receiver 14 and/or other computer described herein is configured to follow the present principles (e.g., communicate with other devices to follow the present principles, to perform the logic described herein, and to perform any other functions and/or operations described herein).

Thus, to follow such principles, the receiver 14 may be built up from some or all of the components shown in fig. 1. For example, the receiver 14 may include one or more displays 258, the display 258 may be implemented as a high definition or ultra high definition "4K" or higher flat panel display, and may or may not be a touch-enabled display for receiving user input signals via touches on the display. The receiver 14 may also include one or more speakers 260 for outputting audio in accordance with the present principles, and at least one additional input device 262, such as, 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, which is an example of a wireless computer network interface, such as, but not limited to, a mesh network transceiver. Interface 264 may be, but is not limited toA transceiver(s),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 follow the present principles, including other elements of the receiver 14 described herein, such as, for example, controlling the display 258 to present images thereon 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 telephony transceiver, or Wi-Fi transceiver as described above, or the like.

In addition to the above, 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, to physically connect (using a wired connection) to other CE devices and/or to a headset port, thereby connecting a headset to the receiver 14 for presenting audio from the receiver 14 to a user through the headset. For example, input port 268 may be connected by wire or wirelessly to a wired source or satellite source of audiovisual content. Thus, the source may be a separate or integrated set top box, or a satellite receiver. Or the source may be a gaming machine or a disk player.

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

Continuing with the description of the receiver 14, in some embodiments, the receiver 14 may include one or more cameras 274, which may include one or more of a thermal imaging camera, a digital camera such as a webcam, and/or a camera integrated into the receiver 14 and controllable by the processor 266 to collect pictures/images and/or video in accordance with the present principles. The receiver 14 may also include thereonA transceiver 276 or other Near Field Communication (NFC) element for use with eachAnd/or NFC technology with other devices. An example NFC element may be a Radio Frequency Identification (RFID) element.

Still further, the receiver 14 may include one or more auxiliary sensors 278 (such as motion sensors, such as accelerometers, gyroscopes, gyrators or magnetic sensors, and combinations thereof), infrared (IR) sensors for receiving IR commands from a remote control, optical sensors, speed and/or prosodic sensors, gesture sensors (for sensing gesture commands), etc., providing inputs to the processor 266. IR sensor 280 may be configured 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, an Application Specific Integrated Circuit (ASIC) or Field Programmable Gate Array (FPGA) module, or any other convenient manner as will be appreciated by those skilled in the art. Where employed, the software instructions may be embodied in a non-transitory device such as a CD ROM or flash drive. The software code instructions may be embodied either in a transient arrangement such as a radio or optical signal or via a download over the internet.

Referring now to fig. 3, a ROUTE session 300 is established at an ATSC 3.0 transmitter delivering Layered Coded Transport (LCT) packets 302. These packets may carry source object or FEC repair data. From a top-down approach, the source protocol consists of one or more LCT channels, each of which carries a delivery object and optionally object metadata 304. The metadata may be communicated statically in signaling metadata or may be communicated dynamically as a composite object in entity mode or as an LCT extension header in a packet header. Packets are carried in ROUTE using a specific FEC scheme 306 that allows flexible segmentation of objects at arbitrary byte boundaries. In addition, the delivery object may be FEC protected alone or in the form of a bundle 308. In either case, the bundled objects are encoded and the repair symbols are passed via a routing session over UDP/IP 310. The received repair symbols, alone or in combination with any received source packets, allow for delivery of recovery of object bundles. Note that one or more repair streams may be generated, each having different characteristics, e.g., to support different latency requirements, different protection requirements, etc.

Fig. 4 illustrates the basic receiver operation. A receiver 400, such as any suitably configured receiver herein, receives packets 402 and filters the packets accordingly. The receiver regenerates the delivery object 404 from the ROUTE session and each included LCT channel. The delivery object is in turn passed to an appropriate processor 406 for further data processing for use by an application or media player 408.

Reference is now made to fig. 5. The file has been partitioned into a plurality of partitions 500. The first partition P1 represents a first data sequence in the file, the second partition P2 represents a next subsequent data sequence in the file, and so on, such that the partitions P ₁、…、P_n are arranged in the order defined by the file for transmission.

However, as shown in FIG. 5, the packets 502 within each partition 500 are not ordered, but are arranged out of order (OOO), for example, by random distribution of the packets within the partition. Thus, for example, packet #8 in first partition P ₁, then packet #2, then packet #20, then packet #3, and so on, until all packets within first partition P ₁ are OOO ordered.

Fig. 6 illustrates transmitter logic consistent with fig. 5. Beginning at state 600, the number and/or size of partitions of a requested file to be transmitted using ATSC 3.0 technology, e.g., OTA, is determined. Moving to state 602, the file is partitioned into a plurality of partitions.

Proceeding to state 604, within each partition, the data packets of the partition are arranged (or reordered) to be out of order (OOO). In one example, packets are randomly ordered within the partition to which they belong. At the end of state 606, the partitions are sent to one or more receivers in the correct partition order but their respective packets are OOOs.

Fig. 7 illustrates receiver side logic. Beginning at state 700, the receiver first receives a first partition of a transmitted file, which partition is stored in non-persistent memory. At block 702, packets in the received partition may be reordered into the correct order using packet information in ATSC 3.0 signaling. Note that the reordering may be done later after the partition is transferred to persistent memory.

State 704 indicates that the next subsequent partition is received into non-persistent memory. That is, multiple partitions may reside in non-persistent memory at the same time, although typically not all partitions will reside in non-persistent memory at the same time, as the partitions are offloaded into persistent memory while a file is being received, as described below.

State 706 indicates that errors in the packet can be corrected if needed, in the example shown, while the partition is still resident in non-persistent memory, but it should be understood that error correction can occur after the partition has been offloaded to persistent memory in states 708 (for the first partition) and 712 (for the second partition). Then, at state 710, one or more subsequent partitions of the file are received into non-persistent memory, and the process continues with loop 714, which receives partitions of the file into non-persistent memory, offloads them into persistent memory, and continues with receiving subsequent partitions into non-persistent memory. Some or all of the files may be displayed or provided for use by other applications.

Reference is now made to fig. 8 and 9. The partition equations discussed herein may be built on top of RaptorQ AL-FEC so that incremental repair may be implemented while the next partition of a packet is being received. This involves re-encoding the original AL-FEC OTI parameters (as defined in RFC 6330) to support this partitioning of source blocks. In this way, the receiver can support the reception and repair of OOO data for very large files in RAM, where the limit of the size of the file is determined only by the size of the available flash memory and OOO partition and any repair data and intermediate symbols required to perform the RaptorQ repair algorithm in RAM.

A plurality of source blocks 800 of the file are interleaved with repair symbols 801. As described later, each partition includes a plurality of source blocks.

As shown in fig. 8, the file contains Z source blocks. As shown in the # source block equation in fig. 8, Z is greater than or equal to F/T divided by the upward rounding value of k _max, where k _max (shown as 806 in fig. 8) represents the number of symbols in each source block, T (shown as 804 in fig. 8) is the number of bytes in each symbol, and F (shown as 802 in fig. 8) is the size of the file.

In one non-limiting example, 5% -25% of the symbols in the source block may be repair symbols. In a particularly specific embodiment, 10% of the symbols in the source block may be repair symbols.

Fig. 9 shows additional disclosure. As shown in fig. 9, at least some partitions 900 include Z _l source blocks (shown at 902 in fig. 9), where Z _l is equal to Z divided by the rounded up value of P _n (shown at 904 in fig. 9), where P _n is the total number of partitions in the file. On the other hand, at least one partition (shown at 906 in fig. 9) includes Z _s source blocks, where Z _s is equal to Z divided by the downward rounding value of P _n. Thus, some partitions will have a different number of source blocks than other partitions.

Referring now to fig. 10, a top bar graph represents data symbols 1000 of a source block interleaved with repair symbols 1002. Non-persistent storage 1004 and persistent storage 1006 are shown in FIG. 10. For devices that do fast block reads from persistent flash, incomplete data or data that is not enough to repair the data may be saved 1010 to flash (persistent storage example) along with a record of repair 1012 and/or a gap in the data, as shown at 1008 in fig. 10. When a partition occurs, the incomplete data can be retrieved next time around the carousel. This maximizes the chance of partition completion. In this case, the incomplete partition may be deleted from the non-persistent memory.

ATSC 3.0 signaling, such as in an extension of the File Delivery Table (FDT) instance, may contain the following elements to support current technology. The signaling enables the receiver to evaluate whether it has OOO transferred but also partitioned storage capability of large files in RAM. Additional signaling indicating the percentage of repair data is also included to complete the memory requirement assessment.

MaxCacheMemory-when the FDT-Instance order attribute is false, the optional 32-bit unsigned integer attribute represents the maximum memory required to store received file data in cache at any time. This allows the receiver to evaluate its ability to receive data in non-persistent storage before transmitting a complete block of consecutive data blocks to persistent storage, or to allow the receiver to repair the data blocks if repairFlow is utilized. When FDT-instance. The receiver should use the LCT header transmission length or the entity pattern content length. If the FDT-Instance order attribute is true, the data is not sent out of order.

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

Claims

1. A method in a digital television, comprising:

dividing at least one file into a plurality of partitions;

Within each partition, out-of-order (OOO) ordering the packets of the partition, and

The partitions are sequentially transmitted to at least one receiver, wherein their respective packets are OOO.

2. The method of claim 1, comprising:

a plurality of source blocks of the file are interleaved with repair symbols, each partition including a plurality of source blocks.

3. The method of claim 2, wherein the file comprises Z source blocks, wherein Z is greater than or equal to an upper rounded value of F/T divided by k _max, wherein k _max represents the number of symbols in each source block, T is the number of bytes in each symbol, F is the size of the file, and upper rounded represents rounding up to the nearest integer.

4. A method as recited in claim 3, wherein at least some of the partitions comprise Zl source blocks, wherein Zl is equal to a ceiling value of Z divided by Pn, wherein Pn comprises a total number of partitions.

5. The method of claim 4, wherein the at least one partition comprises Z _s source blocks, wherein Z _s is equal to Z divided by a down-integer value of P _n, wherein the down-integer represents rounding down to the nearest integer.

6. The method of claim 1, wherein the digital television comprises an Advanced Television Systems Committee (ATSC) 3.0 system.

7. A digital television apparatus comprising:

At least one receiver configured to receive digital television from a digital television transmitter system, the receiver comprising at least one processor programmed with instructions for:

receiving at least some of a plurality of partitions of at least one file into non-persistent memory, each partition comprising out-of-order packets (OOOs);

Ordering the packets into the correct order;

transmitting at least one partition in non-persistent memory to persistent memory, and

Additional partitions are received into non-persistent memory.

8. The digital television apparatus of claim 7, wherein said digital television receiver comprises an Advanced Television Systems Committee (ATSC) 3.0 receiver.

9. The digital television apparatus of claim 7, wherein the plurality of source blocks of the file are interleaved with repair symbols, each partition comprising a plurality of source blocks.

10. The digital television apparatus of claim 9, wherein the file comprises Z source blocks, wherein Z is greater than or equal to an upper rounded value of F/T divided by k _max, wherein k _max represents the number of symbols in each source block, T is the number of bytes in each symbol, and F is the size of the file.

11. The digital television apparatus of claim 10, wherein at least some of the partitions comprise Z _l source blocks, wherein Z _l is equal to Z divided by a rounded up value of P _n, wherein P _n comprises the total number of partitions.

12. The digital television apparatus of claim 11, wherein the at least one partition comprises Z _s source blocks, wherein Z _s is equal to a floor down value of Z divided by P _n.

13. The digital television apparatus of claim 7, wherein the instructions are executable to:

errors in the packet are corrected when the packet is in non-persistent memory.

14. The digital television apparatus of claim 7, wherein the instructions are executable to

Errors in the packet are corrected when the packet is in persistent memory.

15. The digital television apparatus of claim 7, wherein the instructions are executable for rendering the file.

16. A digital television apparatus comprising:

at least one transmitter comprising at least one processor programmed with instructions that configure the processor to:

dividing at least one file into a plurality of partitions;

17. The digital television apparatus of claim 16, wherein the instructions are executable to:

18. The digital television apparatus of claim 17, wherein the file comprises Z source blocks, wherein Z is greater than or equal to an upper rounded value of F/T divided by k _max, wherein k _max represents the number of symbols in each source block, T is the number of bytes in each symbol, and F is the size of the file.

19. The digital television apparatus of claim 18, wherein at least some of the partitions comprise Z _l source blocks, wherein Z _l is equal to a rounded up value of Z divided by P _n, wherein P _n comprises the total number of partitions.

20. The digital television apparatus of claim 19, wherein the at least one partition comprises Z _s source blocks, wherein Z _s is equal to a floor down value of Z divided by P _n.