US20170026148A1 - Universal object delivery and template-based file delivery - Google Patents
Universal object delivery and template-based file delivery Download PDFInfo
- Publication number
- US20170026148A1 US20170026148A1 US15/076,235 US201615076235A US2017026148A1 US 20170026148 A1 US20170026148 A1 US 20170026148A1 US 201615076235 A US201615076235 A US 201615076235A US 2017026148 A1 US2017026148 A1 US 2017026148A1
- Authority
- US
- United States
- Prior art keywords
- data
- objects
- sequence
- transmission
- template file
- 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.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0041—Arrangements at the transmitter end
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0056—Systems characterized by the type of code used
- H04L1/0057—Block codes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1881—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with schedule organisation, e.g. priority, sequence management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/70—Media network packetisation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/75—Media network packet handling
- H04L65/765—Media network packet handling intermediate
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
Definitions
- the present invention relates to encoding and decoding data in communications systems and more specifically to communication systems that encode and decode data to account for errors and gaps in communicated data in an efficient manner and that handle different file delivery methods, as well as using existing infrastructures for novel file delivery processes.
- a recipient desires to receive an exact copy of data transmitted over a channel by a sender with some level of certainty.
- the channel does not have perfect fidelity (which covers most all physically realizable systems)
- one concern is how to deal with data lost or garbled in transmission.
- Lost data erasures
- errors are often easier to deal with than corrupted data (errors) because the recipient cannot always tell when corrupted data is data received in error.
- Many error-correcting codes have been developed to correct for erasures and/or for errors.
- the particular code used is chosen based on some information about the infidelities of the channel through which the data is being transmitted and the nature of the data being transmitted. For example, where the channel is known to have long periods of infidelity, a burst error code might be best suited for that application. Where only short, infrequent errors are expected a simple parity code might be best.
- source data refers to data that is available at one or more senders and that a receiver is used to obtain, by recovery from a transmitted sequence with or without errors and/or erasures, etc.
- encoded data refers to data that is conveyed and can be used to recover or obtain the source data. In a simple case, the encoded data is a copy of the source data, but if the received encoded data differs (due to errors and/or erasures) from the transmitted encoded data, in this simple case the source data might not be entirely recoverable absent additional data about the source data. Transmission can be through space or time.
- the encoded data is generated based on source data in a transformation and is transmitted from one or more senders to receivers.
- the encoding is said to be “systematic” if the source data is found to be part of the encoded data.
- redundant information about the source data is appended to the end of the source data to form the encoded data.
- input data refers to data that is present at an input of an FEC (forward-error correcting) encoder apparatus or an FEC encoder module, component, step, etc., (“FEC encoder”) and “output data” refers to data that is present at an output of an FEC encoder.
- output data would be expected to be present at an input of an FEC decoder and the FEC decoder would be expected to output the input data, or a correspondence thereof, based on the output data it processed.
- the input data is, or includes, the source data
- the output data is, or includes, the encoded data.
- the input data would be the source data if there is no processing before the input of an FEC encoder.
- the source data is processed into a different form (e.g., a static encoder, an inverse encoder or another process) to generate intermediate data that is presented to the FEC encoder instead of the source data.
- a sender device or sender program code may comprise more than one FEC encoder, i.e., source data is transformed into encoded data in a series of a plurality of FEC encoders.
- FEC decoder applied to generate source data from received encoded data.
- An encoder is a computer system, device, electronic circuit, or the like, that generates encoded symbols or output symbols from a sequence of source symbols or input symbols and a decoder is the counterpart that recovers a sequence of source symbols or input symbols from received or recovered encoded symbols or output symbols.
- the encoder and decoder are separated in time and/or space by the channel and any received encoded symbols might not be exactly the same as corresponding transmitted encoded symbols and they might not be received in exactly the same sequence as they were transmitted.
- the “size” of a symbol can be measured in bits, whether or not the symbol is actually broken into a bit stream, where a symbol has a size of M bits when the symbol is selected from an alphabet of 2 M symbols.
- symbols are measured in octets and codes might be over a field of 256 possibilities (there are 256 possible 8-bit patterns within each octet), but it should be understood that different units of data measurement can be used and it is well-known to measure data in various ways.
- FIG. 1 shows the general work flow associated with coding and decoding and the terminology used to describe the block structure of a source block, symbols, sub-blocks, etc.
- Symbols may be either source symbols (i.e., copies of the blocks constituting the original object) or repair symbols (i.e., data produced by the coding process that can be used to repair erasures in the source blocks).
- Parameters critical to the operation of the coding system might be contained within a structure called the Object Transmission Information (“OTI”).
- OTI Object Transmission Information
- the OTI for a collection of related symbols may be communicated one or more times between sender(s) and receiver(s).
- When symbols are placed into messages for delivery via a channel (e.g., a network packet over a network), bookkeeping information is sometimes added to the symbols.
- the Payload ID contains a source block number (“SBN”) and a unique encoding symbol identifier (“ESI”).
- SBN source block number
- EI unique encoding symbol identifier
- the Payload ID (and OTI) can contain different information for different types of codes and use cases.
- FEC Forward Error Correction
- OTI Object Transmission Information
- a receiver Based on the FEC OTI a receiver receives (or is able to infer), the receiver can determine the source block and sub-block structure of the file transfer.
- the FEC Payload ID contains the pair (SBN, ESI), where in [Raptor-RFC-5053] SBN is 16 bits and the ESI is 16 bits, whereas in [IETF-RFC-6330] the SBN is 8 bits and the ESI is 24 bits, as illustrated in FIG. 2 herein.
- SBN the pair (SBN, ESI)
- SBN is 8 bits and the ESI is 24 bits, as illustrated in FIG. 2 herein.
- One disadvantage of this format is that one has to pre-determine the number of bits to allocate to the SBN and to the ESI, and it is sometimes difficult to determine a proper mix that will be adequate for all file delivery parameters.
- each source block is limited to 8 MB (which might be the case if the maximum sub-block size is 256 KB, the minimum sub-symbol size is 32 octets, and the symbol size is 1,024 octets) then limiting the number of source blocks to 256 limits the file size to 2 GB.
- Erasure code processing as described above can be used in conjunction with a variety of content delivery systems and protocols.
- specialized servers are required, which can be more expensive to implement, support and maintain that using more common, conventional Internet servers to support content delivery. Therefore, it is desirable to have methods for delivering content and repair symbols that are less complex to implement.
- FLUTE FLUTE
- a receiver that implements both FLUTE and the appropriate set of erasure codes is able to identify the names and contents of file objects.
- FLUTE can, in turn, be carried within (or on “top” of) a variety of transfer mechanisms such as UDP/IP (e.g., in the Internet).
- UDP/IP e.g., in the Internet
- FLUTE has been selected for delivery of streaming content.
- the stream is delivered as a sequence of DASH formatted files.
- the signaling within FLUTE is not specifically designed for delivering sequence of related files.
- improved methods for signaling and delivering sequences of files within the FLUTE architecture is needed.
- sequences of related files using template based methods are signaled and delivered.
- improved methods of signaling and delivering DASH streams of files using the FLUTE protocol are provided.
- FIG. 1 is a diagram illustrating the general work flow associated with coding and decoding and the terminology used to describe the block structure of a source block, symbols, sub-blocks, etc.
- FIG. 2A is a diagram illustrating a conventional FEC Payload ID that illustrates an FEC Payload ID for a payload as might be used with [Raptor-RFC-5053]
- FIG. 2B is a diagram illustrating a conventional FEC Payload ID that illustrates an FEC Payload ID for a payload as might be used with [IETF-RFC-6330].
- FIG. 3 depicts elements of a block request streaming system according to embodiments of the present invention.
- FIG. 4 illustrates the block request streaming system of FIG. 3 , showing greater detail in the elements of a client system that is coupled to a block serving infrastructure (“BSI”) to receive data that is processed by a content ingestion system.
- BSI block serving infrastructure
- FIG. 5 is a diagram illustrating the possible arrangement of an application and a proxy system that is able to deliver data to an application.
- the particular example depicted is a media playback application using a manifest file that consumes multiple segments (i.e., files containing multimedia information or samples).
- FIG. 6 illustrates a hardware/software implementation of an ingestion system.
- FIG. 7 illustrates a hardware/software implementation of a client system.
- FIG. 8 illustrates possible structures of the content store shown in FIG. 3 , including segments and media presentation descriptor (“MPD”) files, and a breakdown of segments, timing, and other structure within an MPD file.
- MPD media presentation descriptor
- FIG. 9 is a diagram illustrating the FEC Payload ID for a basic universal file delivery (“UFD”) method.
- FIG. 10 is a flow chart that illustrates a sender basic UFD method.
- FIG. 11 is a flow chart that illustrates a receiver basic UFD method.
- FIG. 12 is a diagram illustrating some aspects of the overall FLUTE/ALC/LCT/FEC building block protocols.
- FIG. 13 illustrates an example object with FEC Payload ID (SBN, ESI).
- FIG. 14 illustrates an example object with FEC Payload ID (UOSI).
- file delivery is performed by an encoder/transmitter system that sends a file and a receiver/decoder system that receives a file.
- the format of the transmissions is coordinated so that the decoder understands what the encoder encoded.
- file delivery is an example of general object delivery and unless otherwise indicated, it should be apparent from these examples that objects can be treated as files and possibly vice versa.
- the data is organized into packets and transmitted as packets.
- Each packet has elements that allow a receiver to determine what is in the packet and how it is laid out.
- FEC forward error correction
- unequal FEC protection means that different portions of files, or different files, are FEC-protected to different degrees for the purpose of delivery of those files to devices over networks susceptible to packet loss.
- “Bundled delivery of files” means that FEC-protection is applied over multiple files or portions of files for the purpose of delivery of those files to one or more devices over networks susceptible to packet loss. It is well-known that when many files are delivered as separate files, the resiliency of the deliveries to packet loss can be much less than if all the files are concatenated together into a larger file and the larger file is protected in the delivery.
- a preferred file delivery system or method should allow any flexible combination of the number of source blocks and the number of encoding symbols per source block that is used as the file delivery structure for a file. It should also be the case that file delivery methods provide efficient protection against packet loss, and support delivery of the file with different parts of the file protected at different priorities (i.e., with different codes or code rates), wherein each part of the file may have a different source block structure and sub-block structure than other parts of the file.
- files are in some cases considered specific examples of objects, but herein it should be understood that the examples used herein to describe transport and handling of files can also be used for data objects that are perhaps not referred to as files, such as large chunks of data from a database, a portion of a video sequence, etc.
- the file/object delivery system or method should provide for the delivery of many smaller files/objects with the protection efficiency of a large file/object, simple signaling of the smaller file/object structures, and the capabilities for the receiver to independently recover only a subset of the smaller files/objects without recovering all of the smaller files/objects.
- a file delivery system might comprise a broadcast portion and a unicast portion.
- “broadcast” might be read to mean “broadcast, multicast, and/or other mechanisms for serving common data to a plurality of users.”
- “Unicast” refers to movement of data from one source to one destination, although one logical source might comprise multiple components and one logical destination might comprise multiple components.
- In a unicast configuration typically there is a source server and a destination client, with the source server waiting for requests from clients and responding to a received request by sending the requested data (if otherwise permitted) to the requesting client specifically.
- unicast delivery to a large number of destinations can create more scalability challenges than broadcast delivery to those same large number of destinations.
- FIG. 3 shows a simplified diagram of a block-request streaming system embodying the invention.
- a block-streaming system 100 comprising block serving infrastructure (“BSI”) 101 in turn comprising an ingestion system 103 for ingesting content 102 , preparing that content and packaging it for service by an HTTP streaming server 104 by storing it into a content store 110 that is accessible to both ingestion system 103 and HTTP streaming server 104 .
- system 100 might also include an HTTP cache 106 .
- a client 108 such as an HTTP streaming client, sends requests 112 to HTTP streaming server 104 and receives responses 114 from HTTP streaming server 104 or HTTP cache 106 .
- elements shown in FIG. 3 might be implemented, at least in part, in software, therein comprising program code that is executed on a processor or other electronics.
- the content might comprise movies, audio, 2D planar video, 3D video, other types of video, images, timed text, timed metadata or the like.
- Some content might involve data that is to be presented or consumed in a timed manner, such as data for presenting auxiliary information (station identification, advertising, stock quotes, FlashTM sequences, etc.) along with other media being played out.
- auxiliary information station identification, advertising, stock quotes, FlashTM sequences, etc.
- Other hybrid presentations might also be used that combine other media and/or go beyond merely audio and video.
- media blocks may be stored within a block serving infrastructure 101 ( 1 ), which could be, for example, an HTTP server, a Content Delivery Network device, an HTTP proxy, FTP proxy or server, or some other media server or system.
- Block serving infrastructure 101 ( 1 ) is connected to a network 122 , which could be, for example, an Internet Protocol (“IP”) network such as the Internet.
- IP Internet Protocol
- a block-request streaming system client is shown having six functional components, namely a block selector 123 , provided with the metadata described above and performing a function of selecting blocks or partial blocks to be requested from among the plurality of available blocks indicated by the metadata, a block requestor 124 , that receives request instructions from block selector 123 and performs the operations necessary to send a request for the specified block, portions of a block, or multiple blocks, to block serving infrastructure 101 ( 1 ) over network 122 and to receive the data comprising the block in return, as well as a block buffer 125 , a buffer monitor 126 , a media decoder 127 and one or more media transducers 128 that faciliate media consumption.
- a block selector 123 provided with the metadata described above and performing a function of selecting blocks or partial blocks to be requested from among the plurality of available blocks indicated by the metadata
- a block requestor 124 that receives request instructions from block selector 123 and performs the operations necessary to send a request for the specified block, portions of
- Block data received by block requestor 124 is passed for temporary storage to block buffer 125 , which stores the media data.
- the received block data can be stored directly into block buffer 125 as illustrated in FIG. 3 .
- Media decoder 127 is provided with media data by block buffer 125 and performs such transformations on this data as are necessary to provide suitable input to media transducers 128 , which render the media in a form suitable for user or other consumption. Examples of media transducers include visual display devices such as those found in mobile phones, computer systems or televisions, and might also include audio rendering devices, such as speakers or headphones.
- An example of a media decoder would be a function that transforms data in the format described in the H.264 video coding standard into analogue or digital representations of video frames, such as a YUV-format pixel map with associated presentation timestamps for each frame or sample.
- Buffer monitor 126 receives information concerning the contents of block buffer 125 and, based on this information and possibly other information, provides input to block selector 123 , which is used to determine the selection of blocks to request, as is described herein.
- each block has a “playout time” or “duration” that represents the amount of time it would take for the receiver to play the media included in that block at normal speed.
- the playout of the media within a block may depend on having already received data from previous blocks.
- the playout of some of the media in a block may depend on a subsequent block, in which case the playout time for the block is defined with respect to the media that can be played out within the block without reference to the subsequent block, and the playout time for the subsequent block is increased by the playout time of the media within this block that can only playout after having received the subsequent block. Since including media in a block that depends on subsequent blocks is a rare case, in the remainder of this disclosure we assume that media in one block does not depend on subsequent blocks, but note that those skilled in the art will recognize that this variant can be easily added to the embodiments described below.
- the receiver may have controls such as “pause”, “fast forward”, “reverse”, etc. that may result in the block being consumed by playout at a different rate, but if the receiver can obtain and decode each consecutive sequence of blocks in an aggregate time equal to or less than their agreggate playout time excluding the last block in the sequence then the receiver can present the media to the user without stalling.
- a particular position in the media stream is referred to as a particular “time” in the media, corresponding to the time that would have elapsed between the beginning of the media playout and the time when the particular position in the video stream is reached.
- the time or position in a media stream is a conventional concept.
- position or time need not be continuous, as each of the bits in the stream from the first bit of the 241st frame to just before the first bit of the 242nd frame might all have the same time value.
- a block-request streaming system comprises one or more clients that make requests to one or more content servers (for example, HTTP servers, FTP Servers, etc.).
- An ingestion system comprises one or more ingestion processors, wherein an ingestion processor receives content (in real-time or not), processes the content for use by the BRSS and stores it into storage accessible to the content servers, possibly also along with metadata generated by the ingestion processor.
- the BRSS also might contain content caches that coordinate with the content servers.
- the content servers and content caches might be conventional HTTP servers and HTTP caches that receive requests for files or segments in the form of HTTP requests that include a URL, and may also include a byte range, in order to request less than all of the file or segment indicated by the URL.
- the clients might include a conventional HTTP client that makes requests of HTTP servers and handles the responses to those requests, where the HTTP client is driven by a novel client system that formulates requests, passes them to the HTTP client, gets responses from the HTTP client and processes those (or storing, transforming, etc.) in order to provide them to a presentation player for playout by a client device.
- the client system does not know in advance what media is going to be needed (as the needs might depend on user input, changes in user input, etc.), so it is said to be a “streaming” system in that the media is “consumed” as soon as it is received, or shortly thereafter.
- a streaming system in that the media is “consumed” as soon as it is received, or shortly thereafter.
- response delays and bandwidth constraints can cause delays in a presentation, such as causing a pause in a presentation as the stream catches up to where the user is in consuming the presentation.
- a number of details can be implemented in the BRSS, either at the client end, at the ingestion end, or both.
- the details that are implemented are done in consideration of, and to deal with, the client-server interface at the network.
- both the client system and the ingestion system are aware of the enhancement, whereas in other embodiments, only one side is aware of the enhancement. In such cases, the entire system benefits from the enhancement even though one side is not aware of it, while in others, the benefit only accrues if both sides are aware of it but when one side is not aware, it still operates without failing.
- FIG. 5 is a diagram illustrating the possible arrangement of an application and a proxy system that is able to deliver data to an application.
- the particular example depicted is a media playback application using a manifest file that consumes multiple segments (i.e., files containing multimedia information or samples).
- the ingestion system may be implemented as a combination of hardware and software components, according to various embodiments.
- the ingestion system may comprise a set of instructions that can be executed to cause the system to perform any one or more of the methodologies discussed herein.
- the system may be realized as a specific machine in the form of a computer.
- the system may be a server computer, a personal computer (PC), or any system capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that system.
- PC personal computer
- system shall also be taken to include any collection of systems that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
- the ingestion system may include the ingestion processor 302 (e.g., a central processing unit (CPU)), a memory 304 which may store program code during execution, and disk storage 306 , all of which communicate with each other via a bus 300 .
- the system may further include a video display unit 308 (e.g., a liquid crystal display (LCD) or cathode ray tube (CRT)).
- the system also may include an alphanumeric input device 310 (e.g., a keyboard), and a network interface device 312 for receiving content source and delivering content store.
- the disk storage unit 306 may include a machine-readable medium on which may be stored one or more sets of instructions (e.g., software) embodying any one or more of the methodologies or functions described herein.
- the instructions may also reside, completely or at least partially, within the memory 304 and/or within the ingestion processor 302 during execution thereof by the system, with the memory 304 and the ingestion processor 302 also constituting machine-readable media.
- the client system may be implemented as a combination of hardware and software components, according to various embodiments.
- the client system may comprise a set of instructions that can be executed to cause the system to perform any one or more of the methodologies discussed herein.
- the system may be realized as a specific machine in the form of a computer.
- the system may be a server computer, a personal computer (PC), or any system capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that system.
- PC personal computer
- system shall also be taken to include any collection of systems that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
- the client system may include the client processor 402 (e.g., a central processing unit (CPU)), a memory 404 which may store program code during execution, and disk storage 406 , all of which communicate with each other via a bus 400 .
- the system may further include a video display unit 408 (e.g., a liquid crystal display (LCD) or cathode ray tube (CRT)).
- the system also may include an alphanumeric input device 410 (e.g., a keyboard), and a network interface device 412 for sending requests and receiving responses.
- the disk storage unit 406 may include a machine-readable medium on which may be stored one or more sets of instructions (e.g., software) embodying any one or more of the methodologies or functions described herein.
- the instructions may also reside, completely or at least partially, within the memory 404 and/or within the client processor 402 during execution thereof by the system, with the memory 404 and the client processor 402 also constituting machine-readable media.
- FIG. 8 illustrates possible structures of the content store shown in FIG. 3 , including segments and media presentation description (“MPD”) files, and a breakdown of segments, timing, and other structure within an MPD file. Details of possible implementations of MPD structures or files will now be described. In many examples, the MPD is described as a file, but non-file structures can be used as well.
- MPD media presentation description
- content store 110 holds a plurality of source segments 510 , MPDs 500 and repair segments 512 .
- An MPD might comprise period records 501 , which in turn might comprise representation records 502 , that contain segment information 503 such as references to initialization segments 504 and media segments 505 .
- UFD universal file delivery
- FEC Forward Error Correction
- UFD universal file delivery
- UFSI universal file symbol identifier
- FIG. 9 The sender and receiver methods for the basic UFD method will now be described in turn. Again, where files are referred to as objects, “UFSI” might be referred to instead as “UOSI” (a universal object symbol identifier).
- the sender basic UFD method is described with reference to FIG. 10 .
- the sender can use existing methods to generate the FEC Object Transmission Information (“OTI”), for example as described in the [Raptor-RFC-5053] or [IETF-RFC-6330] (see, for example, Section 4.3 of [IETF-RFC-6330]), and use the FEC OTI to determine the source block and sub-block structure to be used to transmit the file, and to determine the relationship between (SBN, ESI) pairs and the encoded symbols of the file (see, for example, Section 4.4 of [IETF-RFC-6330]).
- OTI FEC Object Transmission Information
- the generated FEC OTI can be (F, Al, T, Z, N), where F is the size of the file to be transmitted, Al is an alignment factor that is used to make sure that sub-symbols are aligned on memory boundaries that are multiples of Al, T is the size of the symbols to be generated and sent in the transmission, Z is the number of source blocks into which the file is to be partitioned for transmission, and N is the number of sub-blocks into which each source block is to partitioned for transmission. This is as shown in Step 800 of FIG. 10 .
- the sender can form encoded symbols to be sent in packets and generate the SBNs and ESIs for these encoded symbols using existing methods based on the source block, and if sub-blocking is used, then also the sub-block structure, e.g., as described in [IETF-RFC-6330].
- the sender can send the encoded symbol in a packet with the FEC Payload ID of the packet set to the UFSI C of the encoded symbol, as shown in Step 840 of FIG. 10 .
- the sender can then determine if more encoded symbols are to be sent, as shown in Step 850 of FIG. 10 , and if so then the sender can generate additional encoded symbols to send, as shown by the “Yes” branch to Step 810 of FIG. 10 and, and if not then the sender can finish, as shown by the “No” branch to Step 860 of FIG. 10 .
- the sender may predetermine how many encoded symbols to generate and determine the (SBN, ESI) values for all the encoded symbols to be generated before generating any of the encoded symbols.
- the UFSI values may be generated directly without an intermediate step of generating the (SBN, ESI) values.
- a base UFSI BU may be included in the FEC OTI for the file, that can be used as follows: the UFSI to be used by the FEC sender and receiver for an encoded symbol contained in a packet is U+BU, where U is the UFSI carried in the packet carrying the encoded symbol.
- U the UFSI carried in the packet carrying the encoded symbol.
- a Transmission Object Identifier also called a TOI
- the receiver basic UFD method is described with reference to FIG. 11 .
- the receiver can use existing techniques to determine the FEC OTI (F, Al, T, Z, N) in the same format as described above as for the sender, as shown in Step 900 of FIG. 11 .
- the FEC OTI may be embedded in a FLUTE session description, or the FEC OTI may be encoded into a URL, or the FEC OTI may be obtained via an SDP message (see [RFC 4566]).
- Step 910 the receiver sees if more encoded symbols are received, and it may stay at this step until it either receives another encoded symbol, in which case the receiver proceeds to Step 930 , or the receiver determines that more encoded symbols are not going to be received, in which case the receiver proceeds to Step 920 and either tries to recover the file using other means, for example using HTTP requests to a file repair server, or the receiver may wait for another session to receive more encoded symbols at a later time, or the receiver may decide that the file cannot be recovered.
- other means for example using HTTP requests to a file repair server, or the receiver may wait for another session to receive more encoded symbols at a later time, or the receiver may decide that the file cannot be recovered.
- Step 930 the receiver determines the UFSI C of the encoded symbol and receives the value of the encoded symbol.
- Step 970 the receiver determines if there are enough encoded symbols received to recover the file, and if so proceeds to recover the file in Step 980 , and if not proceeds to receive more encoded symbols in Step 910 .
- the receiver may predetermine how many encoded symbols to receive before attempting recovery.
- the receiver may do some processing that is specific to the FEC code used to determine if enough encoded symbols have been received to recover the file.
- the UFSI values may be used directly without an intermediate step of generating the (SBN, ESI) values in the recovery process.
- recovery of the file may happen concurrently with reception of encoded symbols.
- other forms of FEC OTI information may be used.
- Source symbols that were identified by a combination of a SBN and ESI for purposes of transmitting the file can be viewed as file symbols that are identified by a UFSI when using the basic UFD method.
- F be the size of the file in octets to be transmitted
- T be the symbol size to be used for FEC encoding/decoding purposes when transmitting the file
- the source block structure and sub-blocking structure is determined as for example described in [IETF-RFC-6330], and the basic UFD method described above is used to convert the identification of a symbol from (SBN, ESI) format to and from UFSI format
- the range of UFSIs for the file symbols are 0, 1, 2, . . . , KT
- any repair symbols generated from the file will have UFSIs in the range KT+1, KT+2, etc.
- This property allows the determination of whether a symbol is part of the original file or is a repair symbol generated from the file by simply comparing its UFSI to the value of KT.
- the data is typically packaged into messages or protocol data units (“PDUs”), sometimes informally referred to as packets.
- PDUs protocol data units
- Another application may be multiplexing multiple distinct streams (e.g., audio and video) within the same PDUs for synchronized playback.
- Another application is to further enhance the reliability of delivery of multiple small objects when the network over which the delivery is made is not perfect, e.g., there may be losses of packets between the sender and receiver. While it might be possible to carry distinct objects in different FLUTE sessions without multiplexing, there is no current provision in FLUTE for multiplexing multiple objects or object fragments in the same packet.
- the FLUTE protocol signaling methods do not fully enable the universal object delivery methods.
- the FLUTE protocol is not able to signal that data for multiple objects are carried within the same packet.
- Additional signaling and delivery methods and apparatus for extending the FLUTE protocol to enable universal object delivery We herein call these extensions “Multiplexed FLUTE”.
- UFD universal file delivery
- UOD universal object delivery
- Template-based file delivery
- UOD can be used to supplement FLUTE with multiplexed object transport encoding.
- signaling can be used to indicate when UOD provides FEC encoded data of multiple objects within the same PDUs.
- multiplexed FLUTE enhances the current FLUTE protocols to enable encoding multiple objects or object fragments within the same PDUs.
- Each FLUTE protocol data unit (“PDU”) carries a Transmission Object Identifier (“TOI”) that indicates for which object the PDU carries data.
- TOI Transmission Object Identifier
- the directory of objects, used to map TOIs to files and file attributes, is called a File Delivery Table (“FDT”). The structure is shown in FIG. 12 .
- each entry in a FDT is identified by a TOI and contains information pertaining to one file or object, and thus correspondingly each PDU carrying the same TOI carries data for the one object associated with the TOI in the FDT.
- the information may include a description of the type of FEC scheme used to encode the object and the FEC encoding structure of the object as identified by the FEC Object Transmission Information (“OTI”).
- OTI FEC Object Transmission Information
- the FEC scheme is identified by an FEC Encoding ID (see [IANA-FEC] for current standard values).
- each FLUTE PDU carries a Packet Format Identifier (“PFI”) that indicates how each PDU is structured.
- PFI Packet Format Identifier
- a PDU may contain data for one or more objects.
- Each entry in a PST is identified by a PFI and contains information about the PDU structure of the PDU carrying that PFI, i.e., the order, size and meaning of the fields in the PDU carrying FEC Payload IDs and associated symbols for objects.
- the information associated with the PFI in the PST provides the correspondence between symbols carried in such PDUs and the corresponding objects from which the symbols were generated, the correspondence between FEC Payload IDs carried in such PDUs and the corresponding symbols that the FEC Payload IDs identify, and the lengths of the FEC Payload IDs carried in such PDUs.
- the TOIs of the objects may be used to help indicate these correspondences in a PST entry.
- An entry identified by a PFI in the PST may be relatively simple or more involved.
- the entry may describe a PDU format that contains one FEC Payload ID of a given size, e.g., 2 bytes, and describe one symbol carried in the PDU for one object identified by a particular TOI.
- the entry may specify a PDU format that contains multiple FEC Payload IDs of different sizes, e.g., some may be 1 byte, some 2 bytes, some 4 bytes in size, and the symbols carried in the PDU may be for multiple objects identified in the entry by multiple TOIs, and some FEC Payload IDs may be used for identifying symbols of more than one object whereas other FEC Payload IDs may be used for identifying symbols of a single object.
- the object identified by a TOI may be a portion of a content file, e.g., as identified by specifying a URL for the content file and a byte range in the TOI entry in the FDT.
- Template-based file delivery comprises methods by which multiple related objects can be named, identified, parameterized, and delivered. Template-based file delivery is facilitated with signaling and delivery methods that use templates, somewhat akin to how [Luby2010] and [Luby2012] use templates for DASH delivery of streaming content. Template-based file delivery provides a compact way of delivering the metadata associated with a sequence or set of associated files or objects. The metadata and other properties of the sequence or set of files or objects (or portions of objects) are or can be constructed to be related in a predictable way so that templates can be used to describe these relationships in a succinct form.
- Template-based file delivery can provide an extremely compact and succinct means to signal the relationships between the locations, names, availability times, FEC information, and other metadata associated with the sequence, set, or collection of objects to be delivered, even for objects in the set of objects that have not yet been created, or are not yet available or known.
- Template-based file delivery allows the bulk of the metadata to be synthesized and delivered in a compact form to a device to which the sequence of files is to be at least partially delivered.
- Template-based file delivery allows the bulk of the metadata to be delivered to the device or client prior to when the device or client initiates reception of at least some of the sequence of files.
- the metadata can be delivered to a client or device before, during, or after reception of at least some of the sequence of files.
- Template-based file delivery removes the necessity of delivering the bulk of the metadata for files only after the file is created and available for delivery, i.e., with Template-based file delivery the metadata can be delivered even before a file is created or is known or available at the sender, wherein this metadata can comprise delivery timing information, handling details as desired, location information for the files after they are created on the receiving device, and other parameters.
- Template-based file delivery enables the delivery of the metadata for a sequence or collection of associated files to be compact and independent of the delivery of the files themselves, and also independent of the timing of the file delivery and the timing of the creation or availability of the files for delivery.
- the metadata associated with files is compact and monolithic when expressed using templates, generally the metadata can be delivered with very high reliability and using different means than is used to deliver files.
- the metadata can be delivered as a small file using HTTP to a client or device, whereas the files themselves may be delivered over a broadcast or multicast network using FLUTE.
- the metadata may be delivered within the eMBMS User Service Description (“USD”) information, or it may be delivered using the Session Description Protocol (“SDP”), or within a conventional file available off the web (e.g., using HTTP).
- USD eMBMS User Service Description
- SDP Session Description Protocol
- the metadata may be expressed using XML or HTML or any of a variety of markup languages.
- the bulk of the metadata is delivered using the same delivery method as is used to deliver the files.
- the metadata for a particular file is typically delivered at or near the same time as the file is delivered.
- there is explicit and particular metadata delivered uniquely for each particular file and the format of the metadata associated with a file does not allow the file metadata to be generated and delivered far in advance of the creation or availability of the file for delivery. If the metadata for a file is not available at the receiver, generally the recovery of the file at the receiver is not possible, even if the receiver has received enough data in the packets for the file that, together with the metadata for the file, would allow recovery of the file.
- Streaming video or audio is often delivered as a sequence of named files or fragments.
- DASH the DASH standard
- [3GP-DASH], [MPEG-DASH] specifies such a solution.
- streaming multimedia data video, audio, timed text, etc.
- multicast or broadcast enabled networks such as an eMBMS network ([IMBMS])
- FLUTE protocol [FLUTE]) uses a sequence of files that can be delivered as a sequence of separate objects, sometimes also called segments.
- the FDT in FLUTE contains the names of files but also important metadata which may be required to successfully collect and decode the file contents.
- the FDT may contain the names of certain files that must be received as a prerequisite for subsequent successful reconstruction of some multimedia stream (e.g., DASH initialization segments are ordinarily necessary as a prerequisite to decoding and rendering subsequent media samples).
- the name of any particular segment is not known at the time of transmission of the current segment. Instead, subsequent file names must be learned by receiving a newer or updated FDT. Thus, both the FDT for the object and the segment itself must be successfully received. If, for example, the receiving client receives a segment but not the associated FDT object containing the meta-data for the segment, the receiving client will not be able to interpret and deliver the segment successfully, and thus the segment is effectively lost.
- templates rules provide a succinct description of metadata and the objects to which they apply.
- the receiving client thus needs only to obtain the template rules in order to obtain all (or most) of the metadata needed for the sequence of related objects, thus eliminating the requirement that the receiving client also receive a separate FDT for each object to be delivered.
- a construction rule is provided that is either a template rule or some other rule that doesn't specify a template per se.
- the loss of the FDT containing the metadata for a segment will generally prevent the receiving client from understanding the structure of the segment, and thus cause the receiving client to have to discard the entire segment of video and/or audio.
- the methods and processes described herein thus improve the quality of experience delivered to end users by reducing the likelihood a segment will be discarded due to loss of metadata.
- Another aspect is that by substantially reducing the amount of redundant metadata sent in FDTs with the current FLUTE solution for sequences of related objects, and the corresponding overheads in sending this metadata, the amount of overall bandwidth used (and latency required) for delivering streams of objects is somewhat reduced using the methods and processes described herein.
- One advantage is that the overall delivery of streams of objects is less complex than required otherwise.
- An FDT carries metadata that relates a file or object identifier for a FLUTE session, expressed as a Transmission Object Identifier (“TOI”), to metadata associated with the file, e.g., a URI for the file, and the Forward Error Correction Object Transmission Information (“FEC OTI”) that conveys the associated FEC parameters for delivering the file over FLUTE.
- TOI Transmission Object Identifier
- FEC OTI Forward Error Correction Object Transmission Information
- a new type of FDT described herein contains template information describing some or all of the FDT metadata needed for a sequence of related objects.
- This new type FDT hereafter called a template FDT (“TFDT”), contains metadata information related to a sequence of related objects, including the FEC OTI, but also including other metadata related to delivering a sequence of related objects.
- the TOI, the FEC OTI and the corresponding URI information may be expressed as templates.
- the metadata in the PST may also be expressed as templates.
- a template is constructed as a baseline constant with zero or more varying values. Varying values can customize the parameters or characters in the URI, FEC OTI, or PST information for specific objects (usually to encode some repeating pattern).
- the delimiters of “%” may be used to indicate a template (e.g., within a substring) in which special values are defined.
- One such value, I is used to indicate the index (i.e., position in a sequence) of an object in a sequence of related objects starting within value zero and incrementing by one for each subsequent object, and (as also described above) the value of I may be used in templates to, for example, describe the sequence of TOIs for the objects and the sequence of URIs for the objects, etc.
- the sequence of related objects in the TFDT is specified using a template that specifies amongst the other possible metadata for the sequence of related objects the range of TOI values to which the TFDT parameter options apply.
- the maximum value of I can be left unspecified, in which case any TOI that fits into the pattern of TOIs specified by the template would be considered to be within the sequence of related objects.
- the TFDT also can include a substring (e.g., HTTP URI prefix) for each object, which is also specified as a template that is described using the value of I.
- the FEC OTI for example for the FEC Encoding Scheme specified in [IETF-RFC-6330] comprises the FEC Encoding ID (6), the file transfer size in bytes (F), the symbol and sub-symbol alignment factor in bytes (Al), the symbol size in bytes (T), the number of source blocks (Z) and the number of sub-blocks per source block (N).
- F file transfer size in bytes
- Al symbol and sub-symbol alignment factor in bytes
- T the symbol size in bytes
- Z the number of source blocks
- N sub-blocks per source block
- the values in the TFDT for the sequence of related objects specify that they all use the rules and protocols of [IETF-RFC-6330] associated with FEC Encoding ID 6, use the alignment factor of 8 bytes, have a symbol size of 1320 bytes, have one source block per object, and have one sub-block per source block.
- the varying parameter i.e., the file transfer size F, may be prepended to the object itself, and the number of source symbols in each object can be included as one of the parameters in the FEC Payload ID of each data packet or PDU.
- the FEC Payload ID format can comprise a two-byte SBN-value, a two-byte ESI-value, and a two-byte KT-value, where the SBN-value indicates from which source block the data carried in the PDU is generated, the ESI-value indicates an encoding symbol ID for the data carried in the PDU, and the KT-value indicates the total number of source symbols comprising the file.
- An alternate FEC Payload ID format can comprise a four-byte UOSI-value and a two-byte KT-value, where the UOSI-value indicates a universal object symbol identifier for the data carried in the PDU and the KT-value indicates the total number of source symbols comprising the file.
- the file or object itself might have prepended a four-byte F-value indicating the total number of bytes in the file, where this F-value is prepended before FEC encoding, and thus the source symbols that are to be FEC-encoded for the purpose of delivering the file comprise the F-value followed by the actual file.
- the total number of source symbols KT for the file is equal to ceil((4+F)/T), where T is the symbol size.
- the receiver can process a file as follows.
- Each received PDU for the file contains a transport session identifier (“TSI”), a TOI and an FEC Payload ID.
- TSI transport session identifier
- TOI carried in the PDU
- FEC Payload ID an FEC Payload ID
- the receiver can determine all of the FEC OTI except for the file or object size F.
- the receiver can determine the number KT of source symbols in the file from the FEC Payload ID carried in each PDU (and the receiver can identify which object the KT is associated with from the TSI and TOI carried in the PDU).
- the receiver can determine the number of source blocks and the number of source symbols in each such source block of the file (and the receiver can also determine the number of sub-blocks into which each source block is partitioned, and the size of the sub-symbol for each sub-block). Once at least enough symbols have been received for each source block, which is typically when KT or slightly more than KT symbols in total have been received for the file, the receiver can FEC-decode and recover the KT source symbols of the file. Once the KT source symbols for the file have been recovered, the receiver can determine from the value of F, or P, prepended to the source symbols, the F-bytes of the source symbols comprising the file.
- the four-byte F-value may be appended to the file or object instead of prepended, where the F-value is appended before FEC encoding, and thus the source symbols that are to be FEC-encoded for the purpose of delivering the file comprise the actual file followed by possible padding followed by the F-value as the last four bytes of the last source symbol of the file, where the total number of source symbols KT for the file is ceil((4+F)/T).
- the receiver determines the number of bytes F comprising the file from the last four bytes of the last recovered source symbol, and then the file itself comprise the first F-bytes of the recovered source symbols.
- the P-value is appended to the file instead of the F-file, with similar procedures on how the source symbols are formed and how the receiver recovers the file.
- the FEC Payload ID can comprise a two-byte SBN-value, a two-byte ESI-value, and a four-byte F-value.
- the source symbols can comprise the file itself with no values prepended or appended, as the receiver can recover the size of the file in bytes directly from the FEC Payload ID.
- the FEC Payload ID can comprise a four-byte UOSI-value, and the F-value can be carried in an extension header, for example the EXT_FTI extension header with extension header identifier 64 as specified in [LCT].
- the information that is specific to each object is (in this example) partially carried in the FEC Payload ID of the packets carrying data for the object (the number of source symbols in the object) and partially carried in the source symbols of the object, i.e., prepended or appended to the source symbols of the object before FEC encoding (the size of the file F in bytes, or equivalently the number P of bytes in the last source symbol of the object to be discarded).
- an FEC OTI for RaptorQ (see, e.g., [IETF-RFC-6330]; FEC Encoding ID 6) might have as structure such as is shown in Table 1.
- a PST for the objects might specify two objects per PDU, with a 2-byte FEC Payload ID for each object (each object uses a separate FEC Payload ID in this example, in other cases the two objects might share the same FEC Payload ID).
- the PFI is included in each PDU to indicate which packet format structure the PDUs follow.
- the PST and the FDT might be combined into a TFDT that might look as shown in Table 2.
- the PDUs will use the PFI sequence 0, 1, 2, 3, . . . for the sequence of related objects, and the PDUs containing PFI value 50 will contain one symbol of 664 bytes for each of two objects, wherein the URI for the first object is http://example.com/video50 and the URI for the second object is http://example.com/audio50, and the two objects both have one source block and one sub-block per source block, and both use FEC Encoding ID 6 and use alignment factor 8 bytes.
- the first sequence of files may for example correspond to a sequence of video segments from a DASH video representation
- the second sequence of objects corresponds to a sequence of DASH audio segments from a DASH audio representation.
- the standard FEC Payload ID specified in [IETF-RFC-6330] is used, i.e., each data packet contains one symbol for one object, and the FEC Payload ID comprises an 8-bit SBN and a 24-bit ESI.
- “%” serves as a delimiter for variables and equations.
- these sequences of objects or files correspond to representations described in a DASH MPD, i.e., the MPD at the URL http://newsfeed.video_content/sept25.2012.mpd provided after MPD_URL.
- the MPD_REP_ID specified for a sequence of files in the above TFDT provides an identifier for the corresponding representation in the MPD.
- the MPD_REP_ID is the base URI or URL provided within the MPD for that representation, which uniquely identifies the representation amongst all the representations described within the MPD.
- This signaling provides a method for linking the delivery information associated with a sequence of objects or files signaled in a TFDT with the DASH metadata information associated with representations signaled in a MPD.
- the START_TRANSMISSION and END_TRANSMISSION provided for each sequence of files in the TFDT above can be used to indicate the start transmission time of each file and the end transmission time of each file using a template. Thus, data packets for the file corresponding to I within the first sequence of files is to be transmitted between times I*20 and I*20+20 relative to the beginning transmission time of the session.
- Timescale 10
- data packets for the file corresponding to I within the second sequence of files is to be transmitted between times I*40 and I*40+80 relative to the beginning transmission time of the session.
- Timescale 10
- the receiver can use this information to determine the time interval for when data packets for a file from a sequence of files are expected to arrive.
- start and end transmission time might be indicated using a template for a sequence of files, e.g., two start and end transmission times might be indicated in the TFDT using templates to indicate a time shift broadcast of the same DASH stream of video content.
- the TOIs are scoped by the TSI in a FLUTE session, in order for a receiver to be able to determine which received packets should be associated with which file, the TOI should be distinct for all files or objects delivered with the same TSI value. Thus, if two sequences of files are to be transmitted within the same session, it is preferable that their corresponding ranges of TOI values have an empty intersection, i.e., there are no duplicate TOI values. There are many ways to achieve this.
- one method is to use sequential TOI values for each file sequence, but ensure that the starting TOI value for a first file sequence and the starting TOI value for a second file sequence with the next larger starting TOI value are separated by at least the maximum number of TOI values to be used for the first file sequence.
- the first sequence of files has a start TOI value of 2,000,000 and uses at most 100,000 consecutive TOI values, i.e., TOIs in the range 2,000,000 through 2,099,999, whereas the second sequence of files has a start TOI value of 3,000,000.
- there are 1,000,000 TOI values between the start TOI values of the first and second file sequence but only 100,000 of these TOI values are used by the first file sequence, so there are no duplicate TOI values used by the two file sequences.
- Another method to achieve no duplicate TOI values used by different sequences of files is to place an upper bound on the number of sequences of files that can be delivered within a single session. For example, if there is a limit of at most 256 sequences of files within a session, then the J-th such sequence of files can have a TOI sequence specified as:
- each TOI for a file within the J-th sequence of files will have a TOI that is equal to J modulo 256, and thus the TOIs for each of these sequences of files will be distinct at long as each sequence of files uses a different J value modulo 256 to define its sequence of TOIs.
- the above methods ensure that all TOIs used by any of the files in any of the sequences of files delivered within a session are distinct, but this requirement can be relaxed. For example, it is sufficient if the receiver can determine at the time that a packet is received which of the files it is to be associated. The start and end transmission times of each file within a sequence of files can also be used by the receiver to distinguish between different TOI sequences. Suppose in the example above that the TOI sequence for the second sequence of files was changed to
- the TOIs for the first sequence of files and for the second sequence of files would be overlapping, i.e., the TOI range for the first sequence of files is 2000000-2099999 and the TOI range for the second sequence of files is 1999990-2049989.
- a receiver that tracks time relative to the beginning of a session transmission can determine to which file a received data packet should be associated. For example, if T seconds have elapsed since the beginning of the session, then the possible TOI for a data packet associated with a file from the first sequence of files is 2000000+floor(T/2) and the possible two TOIs for a data packet associated with a file from the second sequence of files are 1999990+floor(T/4) and 1999990+floor(T/4) ⁇ 1.
- these three TOIs are always distinct, and thus the receiver can determine for a received data packet which sequence of files and which file within that sequence to associate with that data packet based on the received TOI within the data packet and the elapsed time T.
- the signaling within the TFDT should have the property that for any first file from a first sequence of files and any second file from a second sequence of files, if the signaled TOI for the first file and the second file are the same then the signaled start transmission time for the second file should be at least ten seconds after the signaled start transmission time of the first file, or the signaled end transmission time for the second file should be at least ten seconds prior to the signaled start transmission of the first file.
- the TOIs for all objects with overlapping transmission times might be unique, with the TOI, the start transmission time, and the end transmission time of each object in the sequence of objects described within the template file delivery table by a construction rule.
- a client running on an end user device often called user equipment (or “UE, in the context of 3GPP) needs to differentiate uniquely which data packets are associated with which file it is trying to recover.
- the TOI provides this mapping.
- uniqueness is a requirement, but in other embodiments, there are various ways to ensure that the client/UE uniquely associates data packets with the correct file.
- each file sent within a session can be sent with the same TSI and all unique TOIs.
- Another example is for the transmitter to ensure that all files sent within a session are sent with the same TSI over a moving period of time (with guard time intervals on either end in case the client/UE is not completely time synchronized with the transmission) all having unique TOIs, and that the client is at least somewhat synchronized with the transmission so that the client/UE can uniquely determine which data packets are associated with each file by using a combination of the TOI in the data packets and the time at which the data packets are received.
- the client would, based on the time a data packet is received, determine which files are actively being sent at that time, for example based on start and end transmission times for each file, with a guard time interval around these times to extend out the time on each side of these start and end transmission times in case the client clock is not completely synchronized with the actual times of transmission/reception of data packets for file.
- all of these files within this guard time interval will be associated with unique TOIs.
- the set of such TOIs of all files transmitted at or within a certain time period of the arrival of a given data packet might be the set S, and the client can determine which file is associated with each TOI in S. Then, the client can match the TOI in the received data packet with one of the TOIs in S, and thereby determine from which file the data in the received data packet was generated.
- One advantage of these methods is that they can greatly enhance reliability and simplicity when delivering multimedia streams e.g., as currently contemplated for delivering DASH formatted streams over eMBMS.
- Reliability is enhanced because instead of having to deliver a separate FDT for each file at or near the time the data packets for the file are sent, a single TFDT that compactly describes the FDTs for all the files can delivered reliably prior to the delivery of the individual files.
- Efficiency is enhanced because a smaller number of bytes are required to represent the same amount of information when this particular encoding is used.
- a TFDT may be delivered via as an XML object, associated with a URL, and a receiver may download the XML object referenced by the URL using HTTP.
- Other methods for formatting and delivering TFDT information to receivers include including the TFDT information in the User Service Description (“USD”) that is used in MBMS to deliver FLUTE metadata to receivers.
- USD User Service Description
- TFDT information may be formatted and delivered using combinations of methods, e.g., partially delivered via the USD, partially delivered as part of a DASH MPD. In some cases at least some portions of the TFDT information may be formatted and delivered redundantly, i.e., some portions of the TFDT information may be formatted and delivered using one method and the same portions of the TFDT information may be formatted and delivered using a different method.
- SAP Session Announcement Protocol
- SDP Session Description Protocol
- RSS Really Simple Syndication
- the TFDT information may be formatted and delivered using combinations of methods, e.g., partially delivered via the USD, partially delivered as part of a DASH MPD. In some cases at least some portions of the TFDT information may be formatted and delivered redundantly, i.e., some portions of the TFDT information may be formatted and delivered using one method and the same portions of the TFDT information may be formatted and delivered using a different method.
- the signaling for the sequences of related files may use the TFDT methods described herein, wherein the individual files delivered with the same session may be delivered using traditional FDTs.
- the metadata for the sequences of related files and for the individual files delivered within the same session make it possible for the receiver to operate correctly, e.g., the TOI for an individual file should not match the TOI of any file for any sequence of files for which data packets are transmitted at the same time as data packets for the individual file.
- the metadata for the individual files may also be included in the TFDT, and thus the TFDT information comprises the delivery metadata for the individual files as well as for the sequences of related files for a session.
- a TFDT may contain all or portions of the metadata for files delivered in multiple transport sessions.
- a TFDT or multiple TFDTs may contain metadata for files for which packets are transmitted into multiple delivery sessions.
- Template-based file delivery and UOD address complementary important use cases for joint protection of multiple objects and can be used separately or together.
- the FEC OTI for Basic UOD RaptorQ can be exactly the same as for RaptorQ in [IETF-RFC-6330], but the FEC Payload ID can be simplified.
- the FEC Payload ID for RaptorQ in [IETF-RFC-6330] is (SBN, ESI), while the FEC Payload ID for Basic UOD RaptorQ is UOSI. Transmitting symbols in UOSI sequence utilizes network resources in an efficient and flexible fashion.
- FIG. 13 illustrates an example object with FEC Payload ID (SBN, ESI).
- FIG. 14 illustrates an example object with FEC Payload ID (UOSI).
- each entry is identified by a unique PFI.
- Each entry in the PST contains (1) The number and sizes of FEC Payload IDs in a packet, (2) a specification of which object is associated with each symbol in a packet (it can use TOIs to make this association), and (3) a specification of which FEC Payload ID to use for each symbol in a packet.
- the PFI is carried in each packet to identify the format and data that is carried in the packet.
- a first PST entry might specify a packet format comprising two FEC Payload IDs of two bytes each—UOSI format, with one symbol for the first object with TOI that uses the first FEC Payload ID, and one symbol for the second object with TOI that uses the second FEC Payload ID.
- the PH could carry a list of sizes and formats of FEC Payload Ids, and the number of symbols of each of the objects carried in the packet, and the tie in to the FEC OTI.
- the PFI could also be carried in the FDT and associated with a TOI.
- the PFI could indicate that the packets associated with a TOI carries 3 objects, with associated URLs and FEC OTI, and the format of the packets are: the first object has a UOSI of 1 byte and one symbol in the packet, the second object shares the UOSI with the first object and uses two symbols in the packet, the third object has a UOSI of 2 bytes and one symbol in the packet, and in this case the packet would contain a 1 byte UOSI for the first object, this UOSI would also be used for the second object, then a 2 byte UOSI for the third object, then one symbol for the first object, 2 symbols for the second object, and one symbol for the third object.
- Recovery at a decoder can be an exact recovery or at least approximately recovery of what was transmitted. Even if some data packets are lost, some can still be associated with their original data packet using transmission object identifiers.
- These transmission object identifiers might be constructed by a transmission object identifier constructor. For example, if two transmission object identifiers, they may be deemed to be associated with the same encoded symbols.
- Data can be arranged as one or more sequences of data objects.
- the sender and/or receiver can be an electronic device or system that communicates over a packet switched network. Packets can be generated from the sequences of data objects using a packet constructor to provide a packet output.
- Meta-data is an example of data in structured form, as might be useful for automated processing. The meta-data might be generated using templates and/or a template file delivery table.
Abstract
Data objects can be delivered over a network using a file delivery system and universal object delivery and template-based file delivery. This might be done by forming source data into a sequence of data objects represented by symbols in packets, sending those to receivers on request, wherein a transmitter obtains a template file delivery table with delivery metadata for the data objects, and constructing a first transmission object identifier for a data object based on a transmission object identifier construction rule described in the template file delivery table. A receiver might receive packets, extract a second transmission object identifier, associate encoded symbols comprising the received data packet with the data object if the first transmission object identifier and the second transmission object identifier identify the same data object, and recover, at least approximately, the source data for the data object based on the encoded symbols associated with the data object.
Description
- The present application is a continuation of U.S. application Ser. No. 13/753,442, filed Jan. 29, 2013, which claims the benefit of U.S. Provisional Application No. 61/615,796 entitled “Universal Object Delivery and Template-Based FLUTE Delivery,” filed Mar. 26, 2012, the entire contents of which are herein incorporated by reference in their entireties for all purposes.
- The present invention relates to encoding and decoding data in communications systems and more specifically to communication systems that encode and decode data to account for errors and gaps in communicated data in an efficient manner and that handle different file delivery methods, as well as using existing infrastructures for novel file delivery processes.
- Techniques for transmission of files between a sender and a recipient over a communications channel are the subject of much literature. Preferably, a recipient desires to receive an exact copy of data transmitted over a channel by a sender with some level of certainty. Where the channel does not have perfect fidelity (which covers most all physically realizable systems), one concern is how to deal with data lost or garbled in transmission. Lost data (erasures) are often easier to deal with than corrupted data (errors) because the recipient cannot always tell when corrupted data is data received in error. Many error-correcting codes have been developed to correct for erasures and/or for errors. Typically, the particular code used is chosen based on some information about the infidelities of the channel through which the data is being transmitted and the nature of the data being transmitted. For example, where the channel is known to have long periods of infidelity, a burst error code might be best suited for that application. Where only short, infrequent errors are expected a simple parity code might be best.
- As used herein, “source data” refers to data that is available at one or more senders and that a receiver is used to obtain, by recovery from a transmitted sequence with or without errors and/or erasures, etc. As used herein, “encoded data” refers to data that is conveyed and can be used to recover or obtain the source data. In a simple case, the encoded data is a copy of the source data, but if the received encoded data differs (due to errors and/or erasures) from the transmitted encoded data, in this simple case the source data might not be entirely recoverable absent additional data about the source data. Transmission can be through space or time. In a more complex case, the encoded data is generated based on source data in a transformation and is transmitted from one or more senders to receivers. The encoding is said to be “systematic” if the source data is found to be part of the encoded data. In a simple example of systematic encoding, redundant information about the source data is appended to the end of the source data to form the encoded data.
- Also as used herein, “input data” refers to data that is present at an input of an FEC (forward-error correcting) encoder apparatus or an FEC encoder module, component, step, etc., (“FEC encoder”) and “output data” refers to data that is present at an output of an FEC encoder. Correspondingly, output data would be expected to be present at an input of an FEC decoder and the FEC decoder would be expected to output the input data, or a correspondence thereof, based on the output data it processed. In some cases, the input data is, or includes, the source data, and in some cases, the output data is, or includes, the encoded data. For example, the input data would be the source data if there is no processing before the input of an FEC encoder. However, in some cases, the source data is processed into a different form (e.g., a static encoder, an inverse encoder or another process) to generate intermediate data that is presented to the FEC encoder instead of the source data.
- In some cases, a sender device or sender program code may comprise more than one FEC encoder, i.e., source data is transformed into encoded data in a series of a plurality of FEC encoders. Similarly at the receiver, there may be more than one FEC decoder applied to generate source data from received encoded data.
- Data can be thought of as partitioned into symbols. An encoder is a computer system, device, electronic circuit, or the like, that generates encoded symbols or output symbols from a sequence of source symbols or input symbols and a decoder is the counterpart that recovers a sequence of source symbols or input symbols from received or recovered encoded symbols or output symbols. The encoder and decoder are separated in time and/or space by the channel and any received encoded symbols might not be exactly the same as corresponding transmitted encoded symbols and they might not be received in exactly the same sequence as they were transmitted. The “size” of a symbol can be measured in bits, whether or not the symbol is actually broken into a bit stream, where a symbol has a size of M bits when the symbol is selected from an alphabet of 2M symbols. In many of the examples herein, symbols are measured in octets and codes might be over a field of 256 possibilities (there are 256 possible 8-bit patterns within each octet), but it should be understood that different units of data measurement can be used and it is well-known to measure data in various ways. In the general literature, the term “byte” is sometimes used interchangeably with the term “octet” to indicate an 8-bit value, although in some contexts “byte” indicates an X-bit value where X is not equal to 8, e.g., X=7, and thus, in general, the term “octet” is used herein. Unless otherwise indicated, the examples herein are not limited to a particular integer or non-integer number of bits per symbol.
-
FIG. 1 shows the general work flow associated with coding and decoding and the terminology used to describe the block structure of a source block, symbols, sub-blocks, etc. Symbols may be either source symbols (i.e., copies of the blocks constituting the original object) or repair symbols (i.e., data produced by the coding process that can be used to repair erasures in the source blocks). Parameters critical to the operation of the coding system might be contained within a structure called the Object Transmission Information (“OTI”). The OTI for a collection of related symbols may be communicated one or more times between sender(s) and receiver(s). When symbols are placed into messages for delivery via a channel (e.g., a network packet over a network), bookkeeping information is sometimes added to the symbols. This information is placed within the Payload Identifier (FEC Payload ID). In several particular examples, the Payload ID contains a source block number (“SBN”) and a unique encoding symbol identifier (“ESI”). The Payload ID (and OTI) can contain different information for different types of codes and use cases. - Based on the FEC OTI a receiver receives (or is able to infer), the receiver can determine the source block and sub-block structure of the file transfer. In [Raptor-RFC-5053] and [IETF-RFC-6330], the FEC Payload ID contains the pair (SBN, ESI), where in [Raptor-RFC-5053] SBN is 16 bits and the ESI is 16 bits, whereas in [IETF-RFC-6330] the SBN is 8 bits and the ESI is 24 bits, as illustrated in
FIG. 2 herein. One disadvantage of this format is that one has to pre-determine the number of bits to allocate to the SBN and to the ESI, and it is sometimes difficult to determine a proper mix that will be adequate for all file delivery parameters. - For example, when using [Raptor-RFC-5053] with 16-bit ESIs, having only 216=65,536 ESI values available might be limiting in some situations. For example, with a source block containing 8,192 source symbols, the number of encoded symbols can only be a factor of 8 larger (i.e., because 8192*8=65536), limiting the possible code rate that could be used to below ⅛ in this case. In this example, using 16 bits to hold the SBN (providing for up to 216=65,536 source blocks) could be more than would ever be used. More concretely, with 8,192 source symbols of 1,024 octets each, the size of the file that could be supported is 524 GB, which in many applications is orders of magnitude larger than is needed.
- As another example, when using [IETF-RFC-6330], having only 28=256 SBNs available might be limiting in some situations. For a 4 GB file, if each source block is limited to 8 MB (which might be the case if the maximum sub-block size is 256 KB, the minimum sub-symbol size is 32 octets, and the symbol size is 1,024 octets) then limiting the number of source blocks to 256 limits the file size to 2 GB. In this example, it may be that having 224=16,777,216 possible encoded symbols (ESIs) are more than would ever be used, e.g., with 8,192 source symbols the number of possible encoded symbols is 2,048 times larger, which may never be needed in some applications.
- Erasure code processing as described above can be used in conjunction with a variety of content delivery systems and protocols. In some cases, specialized servers are required, which can be more expensive to implement, support and maintain that using more common, conventional Internet servers to support content delivery. Therefore, it is desirable to have methods for delivering content and repair symbols that are less complex to implement.
- In some cases, it is preferable to use more efficient signaling methods. One such method, designed for use with uni-directional communication channels and multicast communication is known as FLUTE [FLUTE]. FLUTE augments the basic capabilities of the erasure coding techniques with methods to deliver file and directory information (e.g., file names to be associated with streams of symbols). A receiver that implements both FLUTE and the appropriate set of erasure codes is able to identify the names and contents of file objects. FLUTE can, in turn, be carried within (or on “top” of) a variety of transfer mechanisms such as UDP/IP (e.g., in the Internet). In the context of MBMS and eMBMS, where the 3GPP standards defining organization sets standards, FLUTE has been selected for delivery of streaming content. In particular, the stream is delivered as a sequence of DASH formatted files. However, the signaling within FLUTE is not specifically designed for delivering sequence of related files. Thus, improved methods for signaling and delivering sequences of files within the FLUTE architecture is needed.
- Each of the references below is herein incorporated by reference in their entirety for all purposes:
- [3GP-DASH] “Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH)”, 3GPP specification TS 26.247, Rel. 10, Jun. 8, 2011.
- [FEC BB] Watson, M., Luby, M., and L. Vicisano, “Forward Error Correction (FEC) Building Block”, IETF RFC 5052 (August 2007);
- [FLUTE] Paila, T., Walsh, R., Luby, M., Roca, V., Lehtonen, R., “FLUTE—File Delivery over Unidirectional Transport”, IETF RFC 6726 (November 2012);
- [IANA-FEC] http://www.iana.org/assignments/rmt-fec-parameters
- [IETF-RFC-6330] M. Luby, A. Shokrollahi, M. Watson, T. Stockhammer, L. Minder, “RaptorQ Forward Error Correction Scheme for Object Delivery”, IETF RFC 6330 (August, 2011);
- [LCT] Luby, M., Watson, M., Vicisano, L., “Layered Coding Transport (LCT) Building Block”, IETF RFC 5651 (October 2009)
- [Luby2010] U.S. patent application Ser. No. 12/887,492 naming Mark Watson, et al. and entitled “Enhanced Block-Request Streaming Using URL Templates and Construction Rules”, filed Sep. 21, 2010.
- [Luby2011] U.S. Patent Publication 2012/0099593 naming Michael Luby and entitled “Universal File Delivery Methods for Providing Unequal Error Protection and Bundled File Delivery Services”, filed Mar. 4, 2011, published Apr. 26, 2012.
- [Luby2012] U.S. patent application Ser. No. 13/545,697 naming Michael Luby and entitled “Switch Signaling Methods Providing Improved Switching between Representations for Adaptive HTTP Streaming”, filed Jul. 10, 2012.
- [MBMS] “Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs”, 3GPP specification TS 26.346, Rel. 10, version 10.5.0, Sep. 21, 2012.
- [MPEG-DASH] “Information technology—Dynamic adaptive streaming over HTTP (DASH)—Part 1: Media presentation description and segment formats”, ISO/IEC 23009-1, First edition Apr. 1, 2012.
- [Raptor-RFC-5053] M. Luby, A. Shokrollahi, M. Watson, T. Stockhammer, “Raptor Forward Error Correction Scheme for Object Delivery”, IETF RFC 5053 (September 2007).
- [RFC 4566] M. Handley, V. Jacobson, C. Perkins, “SDP: Session Description Protocol”, IETF RFC 4566, July 2006.
- In embodiments of a file delivery method and apparatus, sequences of related files using template based methods are signaled and delivered. Thus, improved methods of signaling and delivering DASH streams of files using the FLUTE protocol are provided.
- The following detailed description together with the accompanying drawings will provide a better understanding of the nature and advantages of the present invention.
- Various elements might be implemented using computer readable media for execution by a processor for controlling data downloading over a network path between a source and a receiver coupled by the network path. Other aspects of the invention should be apparent from this description.
-
FIG. 1 is a diagram illustrating the general work flow associated with coding and decoding and the terminology used to describe the block structure of a source block, symbols, sub-blocks, etc. -
FIG. 2A is a diagram illustrating a conventional FEC Payload ID that illustrates an FEC Payload ID for a payload as might be used with [Raptor-RFC-5053], whileFIG. 2B is a diagram illustrating a conventional FEC Payload ID that illustrates an FEC Payload ID for a payload as might be used with [IETF-RFC-6330]. -
FIG. 3 depicts elements of a block request streaming system according to embodiments of the present invention. -
FIG. 4 illustrates the block request streaming system ofFIG. 3 , showing greater detail in the elements of a client system that is coupled to a block serving infrastructure (“BSI”) to receive data that is processed by a content ingestion system. -
FIG. 5 is a diagram illustrating the possible arrangement of an application and a proxy system that is able to deliver data to an application. The particular example depicted is a media playback application using a manifest file that consumes multiple segments (i.e., files containing multimedia information or samples). -
FIG. 6 illustrates a hardware/software implementation of an ingestion system. -
FIG. 7 illustrates a hardware/software implementation of a client system. -
FIG. 8 illustrates possible structures of the content store shown inFIG. 3 , including segments and media presentation descriptor (“MPD”) files, and a breakdown of segments, timing, and other structure within an MPD file. -
FIG. 9 is a diagram illustrating the FEC Payload ID for a basic universal file delivery (“UFD”) method. -
FIG. 10 is a flow chart that illustrates a sender basic UFD method. -
FIG. 11 is a flow chart that illustrates a receiver basic UFD method. -
FIG. 12 is a diagram illustrating some aspects of the overall FLUTE/ALC/LCT/FEC building block protocols. -
FIG. 13 illustrates an example object with FEC Payload ID (SBN, ESI). -
FIG. 14 illustrates an example object with FEC Payload ID (UOSI). - In the figures, like items are referenced with like numbers and sub-indices are provided in parentheses to indicate multiple instances of like or identical items. Unless otherwise indicated, the final sub-index (e.g., “N” or “M”) is not intended to be limiting to any particular value and the number of instances of one item can differ from the number of instances of another item even when the same number are illustrated and the sub-index is reused.
- In embodiments herein, file delivery is performed by an encoder/transmitter system that sends a file and a receiver/decoder system that receives a file. The format of the transmissions is coordinated so that the decoder understands what the encoder encoded. As shown in various examples below, file delivery is an example of general object delivery and unless otherwise indicated, it should be apparent from these examples that objects can be treated as files and possibly vice versa.
- In a packet delivery system, the data is organized into packets and transmitted as packets. Each packet has elements that allow a receiver to determine what is in the packet and how it is laid out. Using the techniques described herein, flexibility is provided for transmitting packets where forward error correction (“FEC”) is used.
- Using these techniques, unequal FEC protection can be provided, as well as bundled delivery of files. “Unequal FEC protection” means that different portions of files, or different files, are FEC-protected to different degrees for the purpose of delivery of those files to devices over networks susceptible to packet loss. “Bundled delivery of files” means that FEC-protection is applied over multiple files or portions of files for the purpose of delivery of those files to one or more devices over networks susceptible to packet loss. It is well-known that when many files are delivered as separate files, the resiliency of the deliveries to packet loss can be much less than if all the files are concatenated together into a larger file and the larger file is protected in the delivery. However, a signaling of the structure of the larger file as a combination of smaller files is required, and the receiver generally needs to recover the entire large file to recover any of the smaller files within the large file, even if the receiver is only interested in recovering a subset of the smaller files.
- Thus, a preferred file delivery system or method should allow any flexible combination of the number of source blocks and the number of encoding symbols per source block that is used as the file delivery structure for a file. It should also be the case that file delivery methods provide efficient protection against packet loss, and support delivery of the file with different parts of the file protected at different priorities (i.e., with different codes or code rates), wherein each part of the file may have a different source block structure and sub-block structure than other parts of the file. Again, files are in some cases considered specific examples of objects, but herein it should be understood that the examples used herein to describe transport and handling of files can also be used for data objects that are perhaps not referred to as files, such as large chunks of data from a database, a portion of a video sequence, etc.
- The file/object delivery system or method should provide for the delivery of many smaller files/objects with the protection efficiency of a large file/object, simple signaling of the smaller file/object structures, and the capabilities for the receiver to independently recover only a subset of the smaller files/objects without recovering all of the smaller files/objects.
- A file delivery system might comprise a broadcast portion and a unicast portion. For readability, “broadcast” might be read to mean “broadcast, multicast, and/or other mechanisms for serving common data to a plurality of users.” “Unicast” refers to movement of data from one source to one destination, although one logical source might comprise multiple components and one logical destination might comprise multiple components. In a unicast configuration, typically there is a source server and a destination client, with the source server waiting for requests from clients and responding to a received request by sending the requested data (if otherwise permitted) to the requesting client specifically. As is well-known in the art, unicast delivery to a large number of destinations can create more scalability challenges than broadcast delivery to those same large number of destinations.
- Examples of systems with these desirable qualities will now be described.
- One embodiment of the invention is described with reference to
FIG. 3 , which shows a simplified diagram of a block-request streaming system embodying the invention. - In
FIG. 3 , a block-streamingsystem 100 is illustrated, comprising block serving infrastructure (“BSI”) 101 in turn comprising aningestion system 103 for ingestingcontent 102, preparing that content and packaging it for service by anHTTP streaming server 104 by storing it into acontent store 110 that is accessible to bothingestion system 103 andHTTP streaming server 104. As shown,system 100 might also include anHTTP cache 106. In operation, aclient 108, such as an HTTP streaming client, sendsrequests 112 toHTTP streaming server 104 and receivesresponses 114 fromHTTP streaming server 104 orHTTP cache 106. In each case, elements shown inFIG. 3 might be implemented, at least in part, in software, therein comprising program code that is executed on a processor or other electronics. - The content might comprise movies, audio, 2D planar video, 3D video, other types of video, images, timed text, timed metadata or the like. Some content might involve data that is to be presented or consumed in a timed manner, such as data for presenting auxiliary information (station identification, advertising, stock quotes, Flash™ sequences, etc.) along with other media being played out. Other hybrid presentations might also be used that combine other media and/or go beyond merely audio and video.
- As illustrated in
FIG. 4 , media blocks may be stored within a block serving infrastructure 101(1), which could be, for example, an HTTP server, a Content Delivery Network device, an HTTP proxy, FTP proxy or server, or some other media server or system. Block serving infrastructure 101(1) is connected to anetwork 122, which could be, for example, an Internet Protocol (“IP”) network such as the Internet. A block-request streaming system client is shown having six functional components, namely ablock selector 123, provided with the metadata described above and performing a function of selecting blocks or partial blocks to be requested from among the plurality of available blocks indicated by the metadata, ablock requestor 124, that receives request instructions fromblock selector 123 and performs the operations necessary to send a request for the specified block, portions of a block, or multiple blocks, to block serving infrastructure 101(1) overnetwork 122 and to receive the data comprising the block in return, as well as ablock buffer 125, abuffer monitor 126, amedia decoder 127 and one ormore media transducers 128 that faciliate media consumption. - Block data received by
block requestor 124 is passed for temporary storage to blockbuffer 125, which stores the media data. Alternatively, the received block data can be stored directly intoblock buffer 125 as illustrated inFIG. 3 .Media decoder 127 is provided with media data byblock buffer 125 and performs such transformations on this data as are necessary to provide suitable input tomedia transducers 128, which render the media in a form suitable for user or other consumption. Examples of media transducers include visual display devices such as those found in mobile phones, computer systems or televisions, and might also include audio rendering devices, such as speakers or headphones. - An example of a media decoder would be a function that transforms data in the format described in the H.264 video coding standard into analogue or digital representations of video frames, such as a YUV-format pixel map with associated presentation timestamps for each frame or sample.
-
Buffer monitor 126 receives information concerning the contents ofblock buffer 125 and, based on this information and possibly other information, provides input to blockselector 123, which is used to determine the selection of blocks to request, as is described herein. - In the terminology used herein, each block has a “playout time” or “duration” that represents the amount of time it would take for the receiver to play the media included in that block at normal speed. In some cases, the playout of the media within a block may depend on having already received data from previous blocks. In rare cases, the playout of some of the media in a block may depend on a subsequent block, in which case the playout time for the block is defined with respect to the media that can be played out within the block without reference to the subsequent block, and the playout time for the subsequent block is increased by the playout time of the media within this block that can only playout after having received the subsequent block. Since including media in a block that depends on subsequent blocks is a rare case, in the remainder of this disclosure we assume that media in one block does not depend on subsequent blocks, but note that those skilled in the art will recognize that this variant can be easily added to the embodiments described below.
- The receiver may have controls such as “pause”, “fast forward”, “reverse”, etc. that may result in the block being consumed by playout at a different rate, but if the receiver can obtain and decode each consecutive sequence of blocks in an aggregate time equal to or less than their agreggate playout time excluding the last block in the sequence then the receiver can present the media to the user without stalling. In some descriptions herein, a particular position in the media stream is referred to as a particular “time” in the media, corresponding to the time that would have elapsed between the beginning of the media playout and the time when the particular position in the video stream is reached. The time or position in a media stream is a conventional concept. For example, where the video stream comprises 24 frames per second, the first frame could be said to have a position or time of t=0.0 seconds and the 241st frame could be said to have a position or time of t=10.0 seconds. Naturally, in a frame-based video stream, position or time need not be continuous, as each of the bits in the stream from the first bit of the 241st frame to just before the first bit of the 242nd frame might all have the same time value.
- Adopting the above terminology, a block-request streaming system (BRSS) comprises one or more clients that make requests to one or more content servers (for example, HTTP servers, FTP Servers, etc.). An ingestion system comprises one or more ingestion processors, wherein an ingestion processor receives content (in real-time or not), processes the content for use by the BRSS and stores it into storage accessible to the content servers, possibly also along with metadata generated by the ingestion processor.
- The BRSS also might contain content caches that coordinate with the content servers. The content servers and content caches might be conventional HTTP servers and HTTP caches that receive requests for files or segments in the form of HTTP requests that include a URL, and may also include a byte range, in order to request less than all of the file or segment indicated by the URL. The clients might include a conventional HTTP client that makes requests of HTTP servers and handles the responses to those requests, where the HTTP client is driven by a novel client system that formulates requests, passes them to the HTTP client, gets responses from the HTTP client and processes those (or storing, transforming, etc.) in order to provide them to a presentation player for playout by a client device. Typically, the client system does not know in advance what media is going to be needed (as the needs might depend on user input, changes in user input, etc.), so it is said to be a “streaming” system in that the media is “consumed” as soon as it is received, or shortly thereafter. As a result, response delays and bandwidth constraints can cause delays in a presentation, such as causing a pause in a presentation as the stream catches up to where the user is in consuming the presentation.
- In order to provide for a presentation that is perceived to be of good quality, a number of details can be implemented in the BRSS, either at the client end, at the ingestion end, or both. In some cases, the details that are implemented are done in consideration of, and to deal with, the client-server interface at the network. In some embodiments, both the client system and the ingestion system are aware of the enhancement, whereas in other embodiments, only one side is aware of the enhancement. In such cases, the entire system benefits from the enhancement even though one side is not aware of it, while in others, the benefit only accrues if both sides are aware of it but when one side is not aware, it still operates without failing.
-
FIG. 5 is a diagram illustrating the possible arrangement of an application and a proxy system that is able to deliver data to an application. The particular example depicted is a media playback application using a manifest file that consumes multiple segments (i.e., files containing multimedia information or samples). - As illustrated in
FIG. 6 , the ingestion system may be implemented as a combination of hardware and software components, according to various embodiments. The ingestion system may comprise a set of instructions that can be executed to cause the system to perform any one or more of the methodologies discussed herein. The system may be realized as a specific machine in the form of a computer. The system may be a server computer, a personal computer (PC), or any system capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that system. Further, while only a single system is illustrated, the term “system” shall also be taken to include any collection of systems that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. - The ingestion system may include the ingestion processor 302 (e.g., a central processing unit (CPU)), a
memory 304 which may store program code during execution, anddisk storage 306, all of which communicate with each other via abus 300. The system may further include a video display unit 308 (e.g., a liquid crystal display (LCD) or cathode ray tube (CRT)). The system also may include an alphanumeric input device 310 (e.g., a keyboard), and anetwork interface device 312 for receiving content source and delivering content store. - The
disk storage unit 306 may include a machine-readable medium on which may be stored one or more sets of instructions (e.g., software) embodying any one or more of the methodologies or functions described herein. The instructions may also reside, completely or at least partially, within thememory 304 and/or within theingestion processor 302 during execution thereof by the system, with thememory 304 and theingestion processor 302 also constituting machine-readable media. - As illustrated in
FIG. 7 , the client system may be implemented as a combination of hardware and software components, according to various embodiments. The client system may comprise a set of instructions that can be executed to cause the system to perform any one or more of the methodologies discussed herein. The system may be realized as a specific machine in the form of a computer. The system may be a server computer, a personal computer (PC), or any system capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that system. Further, while only a single system is illustrated, the term “system” shall also be taken to include any collection of systems that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. - The client system may include the client processor 402 (e.g., a central processing unit (CPU)), a
memory 404 which may store program code during execution, anddisk storage 406, all of which communicate with each other via abus 400. The system may further include a video display unit 408 (e.g., a liquid crystal display (LCD) or cathode ray tube (CRT)). The system also may include an alphanumeric input device 410 (e.g., a keyboard), and anetwork interface device 412 for sending requests and receiving responses. - The
disk storage unit 406 may include a machine-readable medium on which may be stored one or more sets of instructions (e.g., software) embodying any one or more of the methodologies or functions described herein. The instructions may also reside, completely or at least partially, within thememory 404 and/or within theclient processor 402 during execution thereof by the system, with thememory 404 and theclient processor 402 also constituting machine-readable media. -
FIG. 8 illustrates possible structures of the content store shown inFIG. 3 , including segments and media presentation description (“MPD”) files, and a breakdown of segments, timing, and other structure within an MPD file. Details of possible implementations of MPD structures or files will now be described. In many examples, the MPD is described as a file, but non-file structures can be used as well. - As illustrated there,
content store 110 holds a plurality ofsource segments 510,MPDs 500 andrepair segments 512. An MPD might compriseperiod records 501, which in turn might compriserepresentation records 502, that containsegment information 503 such as references toinitialization segments 504 andmedia segments 505. - A basic universal file delivery (“UFD”) method and corresponding system(s) will now be described, wherein the UFD includes significant advantages over existing file delivery methods. The Forward Error Correction (“FEC”) Payload ID for the basic UFD method comprises a universal file symbol identifier (“UFSI”) field, which for example can be a 32-bit field, as illustrated in
FIG. 9 . The sender and receiver methods for the basic UFD method will now be described in turn. Again, where files are referred to as objects, “UFSI” might be referred to instead as “UOSI” (a universal object symbol identifier). - The sender basic UFD method is described with reference to
FIG. 10 . The sender can use existing methods to generate the FEC Object Transmission Information (“OTI”), for example as described in the [Raptor-RFC-5053] or [IETF-RFC-6330] (see, for example, Section 4.3 of [IETF-RFC-6330]), and use the FEC OTI to determine the source block and sub-block structure to be used to transmit the file, and to determine the relationship between (SBN, ESI) pairs and the encoded symbols of the file (see, for example, Section 4.4 of [IETF-RFC-6330]). - For example, as described in [IETF-RFC-6330], the generated FEC OTI can be (F, Al, T, Z, N), where F is the size of the file to be transmitted, Al is an alignment factor that is used to make sure that sub-symbols are aligned on memory boundaries that are multiples of Al, T is the size of the symbols to be generated and sent in the transmission, Z is the number of source blocks into which the file is to be partitioned for transmission, and N is the number of sub-blocks into which each source block is to partitioned for transmission. This is as shown in
Step 800 ofFIG. 10 . - The sender can form encoded symbols to be sent in packets and generate the SBNs and ESIs for these encoded symbols using existing methods based on the source block, and if sub-blocking is used, then also the sub-block structure, e.g., as described in [IETF-RFC-6330]. Each time an encoded symbol is to be sent, the sender can determine the SBN A and the ESI B for the encoded symbol to be generated, as shown in
Step 810 ofFIG. 10 , and then the sender can generate the value of the encoded symbol based on (SBN, ESI)=(A, B) using existing techniques for example those described in [IETF-RFC-6330], as shown inStep 820 ofFIG. 10 . Then, the UFSI C for that encoded symbol is computed as C=B*Z+A, as shown inStep 830 ofFIG. 10 . - The sender can send the encoded symbol in a packet with the FEC Payload ID of the packet set to the UFSI C of the encoded symbol, as shown in
Step 840 ofFIG. 10 . The sender can then determine if more encoded symbols are to be sent, as shown inStep 850 ofFIG. 10 , and if so then the sender can generate additional encoded symbols to send, as shown by the “Yes” branch to Step 810 ofFIG. 10 and, and if not then the sender can finish, as shown by the “No” branch to Step 860 ofFIG. 10 . - There are many variations of the sender basic UFD method. For example, the sender can send more than one encoded symbol in at least some of the packets, in which case the FEC Payload ID can be set to the UFSI of the first encoded symbol contained in the packet and additional symbols contained in the packet can be chosen so that their corresponding UFSI values are consecutive. For example, if there are three encoded symbols carried in the packet and the first such symbol has UFSI=4,234, then the other two encoded symbols can be those with UFSIs 4,235 and 4,235, respectively. As examples of other alternatives, the sender may predetermine how many encoded symbols to generate and determine the (SBN, ESI) values for all the encoded symbols to be generated before generating any of the encoded symbols. As another example, the UFSI values may be generated directly without an intermediate step of generating the (SBN, ESI) values.
- As another example of a variation, other forms of FEC OTI information may be generated. For example, a base UFSI BU may be included in the FEC OTI for the file, that can be used as follows: the UFSI to be used by the FEC sender and receiver for an encoded symbol contained in a packet is U+BU, where U is the UFSI carried in the packet carrying the encoded symbol. Thus, for example, if a packet carries U=1,045, and the base UFSI in the FEC OTI is BU=2,000,000, then the encoded symbol UFSI is 2,001,045. Usage of the base UFSI has several advantages. For one, the protocol suite described in [FLUTE], [ALC], [LCT], and/or [FEC BB] associates a Transmission Object Identifier, also called a TOI, with the FEC OTI of a file or object to be transported. It is possible that encoded symbols for the same file may be sent at different times or in different sessions and can be associated with different TOIs. Also, it is advantageous to be able to send encoded packets starting with the UFSI=0 for the packets associated with each different TOI. By having the ability to specify a base UFSI as part of the FEC OTI, a different base UFSI can be associated with each TOI for which encoded symbols are to be sent for the file without sending duplicate encoded symbols for the different TOIs. For example, encoded symbols for the same file may be sent in packets associated with TOI=1 and associated with TOI=2, wherein the base UFSI associated with TOI=1 is set to 0, and wherein the base UFSI associated with TOI=2 is set to 1,000,000. Then, the encoded packets for both TOI=1 and TOI=2 can contain the sequence of
UFSIs - The receiver basic UFD method is described with reference to
FIG. 11 . The receiver can use existing techniques to determine the FEC OTI (F, Al, T, Z, N) in the same format as described above as for the sender, as shown inStep 900 ofFIG. 11 . For example, the FEC OTI may be embedded in a FLUTE session description, or the FEC OTI may be encoded into a URL, or the FEC OTI may be obtained via an SDP message (see [RFC 4566]). InStep 910, the receiver sees if more encoded symbols are received, and it may stay at this step until it either receives another encoded symbol, in which case the receiver proceeds to Step 930, or the receiver determines that more encoded symbols are not going to be received, in which case the receiver proceeds to Step 920 and either tries to recover the file using other means, for example using HTTP requests to a file repair server, or the receiver may wait for another session to receive more encoded symbols at a later time, or the receiver may decide that the file cannot be recovered. - When another encoded symbol is available, in
Step 930 the receiver determines the UFSI C of the encoded symbol and receives the value of the encoded symbol. InStep 940, the receiver calculates A=C modulo Z, and B=floor(C/Z) based on the number Z of source blocks and the UFSI C, and inStep 950 the receiver sets the (SBN, ESI) for the encoded symbol to (A, B), and inStep 960 the receiver stores the value of the encoded symbol and (A, B) to be used for file recovery. InStep 970, the receiver determines if there are enough encoded symbols received to recover the file, and if so proceeds to recover the file inStep 980, and if not proceeds to receive more encoded symbols inStep 910. - There are many variations of the receiver basic UFD method. For example, the receiver can receive more than one encoded symbol in at least some of the packets, in which case the FEC Payload ID may be set to the UFSI of the first encoded symbol contained in the packet and additional symbols in the packet may have corresponding UFSI values that are consecutive. For example, if there are three encoded symbols carried in the packet and the first such symbol has UFSI=4,234, then the other two encoded symbols can be those with UFSIs 4,235 and 4,235, respectively, and the UFSI carried in the packet might the UFSI=4,234 of the first encoded symbol. As examples of other alternatives, the receiver may predetermine how many encoded symbols to receive before attempting recovery. As another example, the receiver may do some processing that is specific to the FEC code used to determine if enough encoded symbols have been received to recover the file. As another example, the UFSI values may be used directly without an intermediate step of generating the (SBN, ESI) values in the recovery process. As another example, recovery of the file may happen concurrently with reception of encoded symbols. As another example, other forms of FEC OTI information may be used.
- Combining the basic UFD method with the techniques described in [IETF-RFC-6330] for determining the source block and sub-block structure provides many advantages. For example, what previous methods called “source symbols” that were identified by a combination of a SBN and ESI for purposes of transmitting the file can be viewed as file symbols that are identified by a UFSI when using the basic UFD method. Let F be the size of the file in octets to be transmitted, and let T be the symbol size to be used for FEC encoding/decoding purposes when transmitting the file, and thus KT=ceil(F/T) is the total number of symbols in the file, where ceil(x) is the smallest integer greater than or equal to x.
- When the source block structure and sub-blocking structure is determined as for example described in [IETF-RFC-6330], and the basic UFD method described above is used to convert the identification of a symbol from (SBN, ESI) format to and from UFSI format, the range of UFSIs for the file symbols are 0, 1, 2, . . . , KT, and any repair symbols generated from the file will have UFSIs in the range KT+1, KT+2, etc. This property allows the determination of whether a symbol is part of the original file or is a repair symbol generated from the file by simply comparing its UFSI to the value of KT. This can be useful for example to allow receivers that do not support FEC decoding to determine which symbols are part of the original file (and their position within the file) and which can be ignored as repair symbols, based on the UFSI value carried in packets, and on the value of KT for the file.
- For delivery of data over a network, the data is typically packaged into messages or protocol data units (“PDUs”), sometimes informally referred to as packets. In some circumstances, it is desirable to multiplex data for multiple objects or object fragments together within PDUs so as to enable simultaneous receipt. This might be used, for example, when mixing media streams from distinct origins within a network. Another application may be multiplexing multiple distinct streams (e.g., audio and video) within the same PDUs for synchronized playback. Another application is to further enhance the reliability of delivery of multiple small objects when the network over which the delivery is made is not perfect, e.g., there may be losses of packets between the sender and receiver. While it might be possible to carry distinct objects in different FLUTE sessions without multiplexing, there is no current provision in FLUTE for multiplexing multiple objects or object fragments in the same packet.
- The FLUTE protocol signaling methods do not fully enable the universal object delivery methods. For example, the FLUTE protocol is not able to signal that data for multiple objects are carried within the same packet. Below we describe additional signaling and delivery methods and apparatus for extending the FLUTE protocol to enable universal object delivery. We herein call these extensions “Multiplexed FLUTE”. A basic universal file delivery (“UFD”) method and corresponding system(s) will now be described, wherein the UFD uses universal object delivery (“UOD”) and Template-based file delivery.
- UOD can be used to supplement FLUTE with multiplexed object transport encoding. With multiplexed FLUTE, signaling can be used to indicate when UOD provides FEC encoded data of multiple objects within the same PDUs. Thus, multiplexed FLUTE enhances the current FLUTE protocols to enable encoding multiple objects or object fragments within the same PDUs.
- Each FLUTE protocol data unit (“PDU”) carries a Transmission Object Identifier (“TOI”) that indicates for which object the PDU carries data. The directory of objects, used to map TOIs to files and file attributes, is called a File Delivery Table (“FDT”). The structure is shown in
FIG. 12 . - In current FLUTE FDTs, each entry in a FDT is identified by a TOI and contains information pertaining to one file or object, and thus correspondingly each PDU carrying the same TOI carries data for the one object associated with the TOI in the FDT. The information may include a description of the type of FEC scheme used to encode the object and the FEC encoding structure of the object as identified by the FEC Object Transmission Information (“OTI”). The FEC scheme is identified by an FEC Encoding ID (see [IANA-FEC] for current standard values).
- With multiplexed FLUTE, there is a new structure called a Packet Structure Table (“PST”). In this extension to the FLUTE protocol, each FLUTE PDU carries a Packet Format Identifier (“PFI”) that indicates how each PDU is structured. In this extension, a PDU may contain data for one or more objects. Each entry in a PST is identified by a PFI and contains information about the PDU structure of the PDU carrying that PFI, i.e., the order, size and meaning of the fields in the PDU carrying FEC Payload IDs and associated symbols for objects.
- For PDUs carrying a particular PFI, the information associated with the PFI in the PST provides the correspondence between symbols carried in such PDUs and the corresponding objects from which the symbols were generated, the correspondence between FEC Payload IDs carried in such PDUs and the corresponding symbols that the FEC Payload IDs identify, and the lengths of the FEC Payload IDs carried in such PDUs. The TOIs of the objects may be used to help indicate these correspondences in a PST entry.
- An entry identified by a PFI in the PST may be relatively simple or more involved. For example, in a simple case, the entry may describe a PDU format that contains one FEC Payload ID of a given size, e.g., 2 bytes, and describe one symbol carried in the PDU for one object identified by a particular TOI. In a more involved example, the entry may specify a PDU format that contains multiple FEC Payload IDs of different sizes, e.g., some may be 1 byte, some 2 bytes, some 4 bytes in size, and the symbols carried in the PDU may be for multiple objects identified in the entry by multiple TOIs, and some FEC Payload IDs may be used for identifying symbols of more than one object whereas other FEC Payload IDs may be used for identifying symbols of a single object.
- Furthermore, for some objects there may be more than one symbol carried in the PDU, whereas for other objects there may be only one symbol carried in the PDU. In other cases, the object identified by a TOI may be a portion of a content file, e.g., as identified by specifying a URL for the content file and a byte range in the TOI entry in the FDT.
- Template-based file delivery, introduced herein, comprises methods by which multiple related objects can be named, identified, parameterized, and delivered. Template-based file delivery is facilitated with signaling and delivery methods that use templates, somewhat akin to how [Luby2010] and [Luby2012] use templates for DASH delivery of streaming content. Template-based file delivery provides a compact way of delivering the metadata associated with a sequence or set of associated files or objects. The metadata and other properties of the sequence or set of files or objects (or portions of objects) are or can be constructed to be related in a predictable way so that templates can be used to describe these relationships in a succinct form. Thus, Template-based file delivery can provide an extremely compact and succinct means to signal the relationships between the locations, names, availability times, FEC information, and other metadata associated with the sequence, set, or collection of objects to be delivered, even for objects in the set of objects that have not yet been created, or are not yet available or known. Template-based file delivery allows the bulk of the metadata to be synthesized and delivered in a compact form to a device to which the sequence of files is to be at least partially delivered. Template-based file delivery allows the bulk of the metadata to be delivered to the device or client prior to when the device or client initiates reception of at least some of the sequence of files. Alternately, the metadata can be delivered to a client or device before, during, or after reception of at least some of the sequence of files.
- Template-based file delivery removes the necessity of delivering the bulk of the metadata for files only after the file is created and available for delivery, i.e., with Template-based file delivery the metadata can be delivered even before a file is created or is known or available at the sender, wherein this metadata can comprise delivery timing information, handling details as desired, location information for the files after they are created on the receiving device, and other parameters. Template-based file delivery enables the delivery of the metadata for a sequence or collection of associated files to be compact and independent of the delivery of the files themselves, and also independent of the timing of the file delivery and the timing of the creation or availability of the files for delivery. Since the metadata associated with files is compact and monolithic when expressed using templates, generally the metadata can be delivered with very high reliability and using different means than is used to deliver files. For example, the metadata can be delivered as a small file using HTTP to a client or device, whereas the files themselves may be delivered over a broadcast or multicast network using FLUTE. The metadata may be delivered within the eMBMS User Service Description (“USD”) information, or it may be delivered using the Session Description Protocol (“SDP”), or within a conventional file available off the web (e.g., using HTTP). The metadata may be expressed using XML or HTML or any of a variety of markup languages.
- With the FLUTE protocol as it exists today, the bulk of the metadata is delivered using the same delivery method as is used to deliver the files. Furthermore, the metadata for a particular file is typically delivered at or near the same time as the file is delivered. Also, there is explicit and particular metadata delivered uniquely for each particular file, and the format of the metadata associated with a file does not allow the file metadata to be generated and delivered far in advance of the creation or availability of the file for delivery. If the metadata for a file is not available at the receiver, generally the recovery of the file at the receiver is not possible, even if the receiver has received enough data in the packets for the file that, together with the metadata for the file, would allow recovery of the file.
- Streaming video or audio is often delivered as a sequence of named files or fragments. For example, the DASH standard ([3GP-DASH], [MPEG-DASH]) specifies such a solution. When delivering streaming multimedia data (video, audio, timed text, etc.) over multicast or broadcast enabled networks, such as an eMBMS network ([IMBMS]), the FLUTE protocol ([FLUTE]) uses a sequence of files that can be delivered as a sequence of separate objects, sometimes also called segments.
- As mentioned above, the FDT in FLUTE contains the names of files but also important metadata which may be required to successfully collect and decode the file contents. In addition, the FDT may contain the names of certain files that must be received as a prerequisite for subsequent successful reconstruction of some multimedia stream (e.g., DASH initialization segments are ordinarily necessary as a prerequisite to decoding and rendering subsequent media samples).
- Generally with FLUTE, the name of any particular segment is not known at the time of transmission of the current segment. Instead, subsequent file names must be learned by receiving a newer or updated FDT. Thus, both the FDT for the object and the segment itself must be successfully received. If, for example, the receiving client receives a segment but not the associated FDT object containing the meta-data for the segment, the receiving client will not be able to interpret and deliver the segment successfully, and thus the segment is effectively lost.
- As explained below, the methods described herein can be used to indicate that particular metadata is common to a sequence of related objects, e.g., a sequence of DASH segments corresponding to a multimedia stream. These methods (“template rules”) provide a succinct description of metadata and the objects to which they apply. The receiving client thus needs only to obtain the template rules in order to obtain all (or most) of the metadata needed for the sequence of related objects, thus eliminating the requirement that the receiving client also receive a separate FDT for each object to be delivered.
- In the more general case, a construction rule is provided that is either a template rule or some other rule that doesn't specify a template per se.
- In the context of eMBMS streaming delivery, the loss of the FDT containing the metadata for a segment will generally prevent the receiving client from understanding the structure of the segment, and thus cause the receiving client to have to discard the entire segment of video and/or audio. The methods and processes described herein thus improve the quality of experience delivered to end users by reducing the likelihood a segment will be discarded due to loss of metadata. Another aspect is that by substantially reducing the amount of redundant metadata sent in FDTs with the current FLUTE solution for sequences of related objects, and the corresponding overheads in sending this metadata, the amount of overall bandwidth used (and latency required) for delivering streams of objects is somewhat reduced using the methods and processes described herein. One advantage is that the overall delivery of streams of objects is less complex than required otherwise.
- An FDT carries metadata that relates a file or object identifier for a FLUTE session, expressed as a Transmission Object Identifier (“TOI”), to metadata associated with the file, e.g., a URI for the file, and the Forward Error Correction Object Transmission Information (“FEC OTI”) that conveys the associated FEC parameters for delivering the file over FLUTE. A new type of FDT described herein contains template information describing some or all of the FDT metadata needed for a sequence of related objects. This new type FDT, hereafter called a template FDT (“TFDT”), contains metadata information related to a sequence of related objects, including the FEC OTI, but also including other metadata related to delivering a sequence of related objects.
- As described, the TOI, the FEC OTI and the corresponding URI information may be expressed as templates. When used in conjunction with a PST, for example, the metadata in the PST may also be expressed as templates.
- A template is constructed as a baseline constant with zero or more varying values. Varying values can customize the parameters or characters in the URI, FEC OTI, or PST information for specific objects (usually to encode some repeating pattern).
- There may be special values with special meaning. For example, as used above, the delimiters of “%” may be used to indicate a template (e.g., within a substring) in which special values are defined. One such value, I, is used to indicate the index (i.e., position in a sequence) of an object in a sequence of related objects starting within value zero and incrementing by one for each subsequent object, and (as also described above) the value of I may be used in templates to, for example, describe the sequence of TOIs for the objects and the sequence of URIs for the objects, etc.
- The sequence of related objects in the TFDT is specified using a template that specifies amongst the other possible metadata for the sequence of related objects the range of TOI values to which the TFDT parameter options apply. For example, the TFDT may use a variable I that indexes from 0 by 1 to the number of objects (which may be unbounded), and then the TOI sequence for the sequence of related objects is specified using a template that is described using the value of I, e.g., in the TFDT the TOI template may be expressed as a string like “TOI=%1000+I*3%” that specifies that the sequence of TOIs in the sequence of related objects is 1000, 1003, 1006, 1009, . . . .
- The value of I can start at 0, increment by 1, and a maximum value for I can be specified in the TFDT, e.g., “Maximum I=499”, indicating that there are 500 objects in the sequence of related objects. Alternatively, the maximum value of I can be left unspecified, in which case any TOI that fits into the pattern of TOIs specified by the template would be considered to be within the sequence of related objects. The TFDT also can include a substring (e.g., HTTP URI prefix) for each object, which is also specified as a template that is described using the value of I. For example, in the TFDT, the TOI template may include “URI=http://example.com/object%I+300%” that specifies that the sequence of URIs in the sequence of related objects is as follows:
-
- http://example.com/object300,
- http://example.com/object301,
- http://example.com/object302,
- http://example.com/object303,
- Although this example describes template rules and how they are applied in the context of FLUTE, this approach is applicable to other file delivery style protocols that contain file names that are later matched with file fragments identified with generic identifiers. Consequently this approach is applicable to other delivery systems and applied by using templates in the metadata description (for example, DASH uses a similar approach in its Media Presentation Description (“MPD”) template structure as described in [Luby2010] and [Luby2012]). Note that example.com is not a real domain, per RFC 2606.
- The FEC OTI for example for the FEC Encoding Scheme specified in [IETF-RFC-6330] comprises the FEC Encoding ID (6), the file transfer size in bytes (F), the symbol and sub-symbol alignment factor in bytes (Al), the symbol size in bytes (T), the number of source blocks (Z) and the number of sub-blocks per source block (N). Amongst these particular parameters, only the value of F typically varies from one object to the next amongst a sequence of related objects, and thus the values of all the FEC OTI parameters other than the value of F may be specified in the TFDT, e.g., as follows:
-
- “FEC Encoding ID=6”, “Al=8”, “T=1320”, “Z=1”, “N=1”
- In this example, the values in the TFDT for the sequence of related objects specify that they all use the rules and protocols of [IETF-RFC-6330] associated with
FEC Encoding ID 6, use the alignment factor of 8 bytes, have a symbol size of 1320 bytes, have one source block per object, and have one sub-block per source block. In this case, the varying parameter, i.e., the file transfer size F, may be prepended to the object itself, and the number of source symbols in each object can be included as one of the parameters in the FEC Payload ID of each data packet or PDU. - For example, the FEC Payload ID format can comprise a two-byte SBN-value, a two-byte ESI-value, and a two-byte KT-value, where the SBN-value indicates from which source block the data carried in the PDU is generated, the ESI-value indicates an encoding symbol ID for the data carried in the PDU, and the KT-value indicates the total number of source symbols comprising the file. An alternate FEC Payload ID format can comprise a four-byte UOSI-value and a two-byte KT-value, where the UOSI-value indicates a universal object symbol identifier for the data carried in the PDU and the KT-value indicates the total number of source symbols comprising the file.
- For these two types of FEC Payload IDs, the file or object itself might have prepended a four-byte F-value indicating the total number of bytes in the file, where this F-value is prepended before FEC encoding, and thus the source symbols that are to be FEC-encoded for the purpose of delivering the file comprise the F-value followed by the actual file. In this case, the total number of source symbols KT for the file is equal to ceil((4+F)/T), where T is the symbol size. Alternatively, the file may have prepended a two-byte P-value indicating the number of padding bytes in the last source symbol of the file, and in this case the file size in bytes is F=KT*T−P, where T is the symbol size. In this case, the total number of source symbols KT for the file is equal to ceil((2+F)/T). In either case, the receiver can process a file as follows. Each received PDU for the file contains a transport session identifier (“TSI”), a TOI and an FEC Payload ID. From the TSI, TOI carried in the PDU, and from the TFDT, the receiver can determine all of the FEC OTI except for the file or object size F. However, the receiver can determine the number KT of source symbols in the file from the FEC Payload ID carried in each PDU (and the receiver can identify which object the KT is associated with from the TSI and TOI carried in the PDU). From KT and the other FEC OTI parameters, the receiver can determine the number of source blocks and the number of source symbols in each such source block of the file (and the receiver can also determine the number of sub-blocks into which each source block is partitioned, and the size of the sub-symbol for each sub-block). Once at least enough symbols have been received for each source block, which is typically when KT or slightly more than KT symbols in total have been received for the file, the receiver can FEC-decode and recover the KT source symbols of the file. Once the KT source symbols for the file have been recovered, the receiver can determine from the value of F, or P, prepended to the source symbols, the F-bytes of the source symbols comprising the file.
- As another alternative, the four-byte F-value may be appended to the file or object instead of prepended, where the F-value is appended before FEC encoding, and thus the source symbols that are to be FEC-encoded for the purpose of delivering the file comprise the actual file followed by possible padding followed by the F-value as the last four bytes of the last source symbol of the file, where the total number of source symbols KT for the file is ceil((4+F)/T). Once the receiver has recovered the KT source symbols of the file, the receiver determines the number of bytes F comprising the file from the last four bytes of the last recovered source symbol, and then the file itself comprise the first F-bytes of the recovered source symbols. Another alternative is where the P-value is appended to the file instead of the F-file, with similar procedures on how the source symbols are formed and how the receiver recovers the file.
- As another alternative, the FEC Payload ID can comprise a two-byte SBN-value, a two-byte ESI-value, and a four-byte F-value. In this alternative, the source symbols can comprise the file itself with no values prepended or appended, as the receiver can recover the size of the file in bytes directly from the FEC Payload ID. As another alternative, the FEC Payload ID can comprise a four-byte UOSI-value, and the F-value can be carried in an extension header, for example the EXT_FTI extension header with extension header identifier 64 as specified in [LCT].
- With the methods described herein using the TFDT, there is no need for a separate FDT for each object, as all of the common information for the sequence of related objects is carried in the TFDT, and the information that is specific to each object is (in this example) partially carried in the FEC Payload ID of the packets carrying data for the object (the number of source symbols in the object) and partially carried in the source symbols of the object, i.e., prepended or appended to the source symbols of the object before FEC encoding (the size of the file F in bytes, or equivalently the number P of bytes in the last source symbol of the object to be discarded).
- For example, an FEC OTI for RaptorQ (see, e.g., [IETF-RFC-6330]; FEC Encoding ID 6) might have as structure such as is shown in Table 1.
-
TABLE 1 Category Details Example Value Mandatory FEC FEC Encoding ID 8 bits (value 6) OTI value Common FEC F (transfer length 40 bits (transfer length of object) OTI value [source]) with limit of 946270874880 T (symbol size) 16 bits (size of a symbol in bytes) Scheme specific Z (# of source 8 bits OTI values blocks) N (# of 16 bits sub-blocks) A1 (alignment) 8 bits - It is expected that for a session of multiple objects, these FEC OTI values would all remain constant except for the F value. If a PST were also used (e.g., to encode multiple objects together in a PDU), and the protocol allowed for variable-sized TOIs or FEC Payload IDs, it is typical that the size of each TOI and FEC Payload ID and the size of the symbols for each constituent object present in each PDU (expressed in bytes) remains unchanged for the sequence of related objects.
- For example, a PST for the objects might specify two objects per PDU, with a 2-byte FEC Payload ID for each object (each object uses a separate FEC Payload ID in this example, in other cases the two objects might share the same FEC Payload ID). With this solution, the PFI is included in each PDU to indicate which packet format structure the PDUs follow.
- With a TFDT as described herein, the PST and the FDT might be combined into a TFDT that might look as shown in Table 2.
-
TABLE 2 PFI = %I% “Number of objects = 2”, “First object FEC Payload ID size = 2 bytes” “Second object FEC Payload ID size = 2 bytes” “First object = 1 symbol per PDU” “Second object = 1 symbol per PDU” “First object URI = http://example.com/video%I%” “First object FEC OTI = (6, 8, 664, 1, 1)” “Second object URI = http://example.com/audio%I%” “Second object FEC OTI = (6, 8, 664, 1, 1)” - Thus, in this example, the PDUs will use the
PFI sequence FEC Encoding ID 6 and usealignment factor 8 bytes. - Below is an example of a TFDT where in this case there is one session with metadata provided for two sequences of related objects. In this example, the first sequence of files may for example correspond to a sequence of video segments from a DASH video representation, and the second sequence of objects corresponds to a sequence of DASH audio segments from a DASH audio representation. In this example, the standard FEC Payload ID specified in [IETF-RFC-6330] is used, i.e., each data packet contains one symbol for one object, and the FEC Payload ID comprises an 8-bit SBN and a 24-bit ESI. In this example, “%” serves as a delimiter for variables and equations.
-
// TFDT with metadata for two sequences of files specified // All sequences of files in this TFDT have the same transport session identifier TSI = 5 // All sequences of files in this TFDT use the same time scale Timescale = 10 MPD_URL = http://news.video_content/sept25.2012.mpd // First sequence of objects metadata <start_seq_template_specification> Counter %I = 0..99999% TOI = %2000000+I% URI = http://localhost.seq1/object%I% MPD_REP_ID = http://newsfeed.example.com/ video500 START_TRANSMISSION = %I*20% END_TRANSMISSION = %I*20 + 20% FEC_OTI = (6, 8, 1288, 1, 1) <end_seq_template_specification> // Second sequence of objects metadata <start_seq_template_specification> Counter %I = 0..49999% TOI = %3000000+I% URI = http://localhost.seq2/object%I% MPD_REP_ID = http://newsfeed.example.com/ audio64 START_TRANSMISSION = %I*40% END_TRANSMISSION = %I*40 + 80% FEC_OTI = (6, 4, 540, 1, 1) <end_seq_template_specification> - In this example TFDT above, these sequences of objects or files correspond to representations described in a DASH MPD, i.e., the MPD at the URL http://newsfeed.video_content/sept25.2012.mpd provided after MPD_URL. The MPD_REP_ID specified for a sequence of files in the above TFDT provides an identifier for the corresponding representation in the MPD. In the example above, the MPD_REP_ID is the base URI or URL provided within the MPD for that representation, which uniquely identifies the representation amongst all the representations described within the MPD. This signaling provides a method for linking the delivery information associated with a sequence of objects or files signaled in a TFDT with the DASH metadata information associated with representations signaled in a MPD.
- In the first sequence of files, the FEC OTI specifies that the FEC code with FEC Encoding ID=6 is used, which is the RaptorQ code specified in [IETF-RFC-6330], and that an alignment factor of 8 is to be used, and that each symbol is 1288 bytes in size, and that each object or file is FEC encoded as one source block with one sub-block per source block. For the second sequence of files, the FEC OTI specifies that the FEC code with FEC Encoding ID=6 is used, which is the RaptorQ code specified in [IETF-RFC-6330], and that an alignment factor of 4 is to be used, and that each symbol is 540 bytes in size, and that each object or file is FEC encoded as one source block with one sub-block per source block.
- The value of Timescale provides a reference for time measurements in units of ticks per second. All units of time are expressed in units of ticks per second using Timescale, e.g., in the example above Timescale=10, and thus a time duration of 55 indicates a 55 tick duration, which corresponds to a 5.5 second duration. The START_TRANSMISSION and END_TRANSMISSION provided for each sequence of files in the TFDT above can be used to indicate the start transmission time of each file and the end transmission time of each file using a template. Thus, data packets for the file corresponding to I within the first sequence of files is to be transmitted between times I*20 and I*20+20 relative to the beginning transmission time of the session. In this example, because Timescale=10, this means that data packets for each file are transmitted for 2 seconds, and the data packets for the file corresponding to I are transmitted starting at 2*I seconds after the beginning transmission time of the session, and thus there is no overlap in transmission time for packets of consecutive files from the first sequence of files. Similarly, data packets for the file corresponding to I within the second sequence of files is to be transmitted between times I*40 and I*40+80 relative to the beginning transmission time of the session. In this example, because Timescale=10, this means that data packets for each file are transmitted for 8 seconds, and the data packets for the file corresponding to I are transmitted starting at 4*I seconds after the beginning transmission time of the session, and thus there is a 4 second overlap in transmission time for packets of consecutive files from the second sequence of files. The receiver can use this information to determine the time interval for when data packets for a file from a sequence of files are expected to arrive. There are many variants of the signaling of the start and end transmission time of files using templates. For example, more than one start and end transmission time might be indicated using a template for a sequence of files, e.g., two start and end transmission times might be indicated in the TFDT using templates to indicate a time shift broadcast of the same DASH stream of video content.
- Since the TOIs are scoped by the TSI in a FLUTE session, in order for a receiver to be able to determine which received packets should be associated with which file, the TOI should be distinct for all files or objects delivered with the same TSI value. Thus, if two sequences of files are to be transmitted within the same session, it is preferable that their corresponding ranges of TOI values have an empty intersection, i.e., there are no duplicate TOI values. There are many ways to achieve this. For example, one method is to use sequential TOI values for each file sequence, but ensure that the starting TOI value for a first file sequence and the starting TOI value for a second file sequence with the next larger starting TOI value are separated by at least the maximum number of TOI values to be used for the first file sequence. This is the method used in the TFDT example above: the first sequence of files has a start TOI value of 2,000,000 and uses at most 100,000 consecutive TOI values, i.e., TOIs in the range 2,000,000 through 2,099,999, whereas the second sequence of files has a start TOI value of 3,000,000. Thus, there are 1,000,000 TOI values between the start TOI values of the first and second file sequence, but only 100,000 of these TOI values are used by the first file sequence, so there are no duplicate TOI values used by the two file sequences.
- Another method to achieve no duplicate TOI values used by different sequences of files is to place an upper bound on the number of sequences of files that can be delivered within a single session. For example, if there is a limit of at most 256 sequences of files within a session, then the J-th such sequence of files can have a TOI sequence specified as:
-
TOI=% J+256*I % - Then, each TOI for a file within the J-th sequence of files will have a TOI that is equal to J modulo 256, and thus the TOIs for each of these sequences of files will be distinct at long as each sequence of files uses a different J value modulo 256 to define its sequence of TOIs.
- The above methods ensure that all TOIs used by any of the files in any of the sequences of files delivered within a session are distinct, but this requirement can be relaxed. For example, it is sufficient if the receiver can determine at the time that a packet is received which of the files it is to be associated. The start and end transmission times of each file within a sequence of files can also be used by the receiver to distinguish between different TOI sequences. Suppose in the example above that the TOI sequence for the second sequence of files was changed to
-
TOI=%1999990+I % - In this case, the TOIs for the first sequence of files and for the second sequence of files would be overlapping, i.e., the TOI range for the first sequence of files is 2000000-2099999 and the TOI range for the second sequence of files is 1999990-2049989. However, a receiver that tracks time relative to the beginning of a session transmission can determine to which file a received data packet should be associated. For example, if T seconds have elapsed since the beginning of the session, then the possible TOI for a data packet associated with a file from the first sequence of files is 2000000+floor(T/2) and the possible two TOIs for a data packet associated with a file from the second sequence of files are 1999990+floor(T/4) and 1999990+floor(T/4)−1. It can be verified in this example that these three TOIs are always distinct, and thus the receiver can determine for a received data packet which sequence of files and which file within that sequence to associate with that data packet based on the received TOI within the data packet and the elapsed time T.
- In general, there may be some variations in the actual send time interval for data packets of a file, and also some variance in the delivery time of data packets from a sender to a receiver, and the time of a sender and a receiver might not be completely synchronized, and thus the above methods for distinguishing and determining which file is associated with a received data packet should take into account tolerances between signaled times and actual receive times of data packets. The methods described herein for determining which sequence of files and which file within the sequence to associate a received data packet based on the TOI, and possibly TSI, within the packet and on the elapsed time T, should take into account these tolerances. For example, it might be the case that from a system perspective a tolerance of ten seconds is reasonable, and thus the signaling within the TFDT should have the property that for any first file from a first sequence of files and any second file from a second sequence of files, if the signaled TOI for the first file and the second file are the same then the signaled start transmission time for the second file should be at least ten seconds after the signaled start transmission time of the first file, or the signaled end transmission time for the second file should be at least ten seconds prior to the signaled start transmission of the first file.
- The TOIs for all objects with overlapping transmission times might be unique, with the TOI, the start transmission time, and the end transmission time of each object in the sequence of objects described within the template file delivery table by a construction rule.
- A client running on an end user device, often called user equipment (or “UE, in the context of 3GPP), needs to differentiate uniquely which data packets are associated with which file it is trying to recover. The TOI provides this mapping. However, in some instances, it might be hard to have unique TOIs. For example, the TOI space of names is only so large, and streaming file delivery might exceed that space, especially if there are multiple streams scoped by the same TSI (transmission session ID, which scopes the TOI=transmission object ID).
- In some embodiments, uniqueness is a requirement, but in other embodiments, there are various ways to ensure that the client/UE uniquely associates data packets with the correct file. For example, each file sent within a session can be sent with the same TSI and all unique TOIs. Another example is for the transmitter to ensure that all files sent within a session are sent with the same TSI over a moving period of time (with guard time intervals on either end in case the client/UE is not completely time synchronized with the transmission) all having unique TOIs, and that the client is at least somewhat synchronized with the transmission so that the client/UE can uniquely determine which data packets are associated with each file by using a combination of the TOI in the data packets and the time at which the data packets are received. In that case, the client would, based on the time a data packet is received, determine which files are actively being sent at that time, for example based on start and end transmission times for each file, with a guard time interval around these times to extend out the time on each side of these start and end transmission times in case the client clock is not completely synchronized with the actual times of transmission/reception of data packets for file. Thus, all of these files within this guard time interval will be associated with unique TOIs.
- The set of such TOIs of all files transmitted at or within a certain time period of the arrival of a given data packet might be the set S, and the client can determine which file is associated with each TOI in S. Then, the client can match the TOI in the received data packet with one of the TOIs in S, and thereby determine from which file the data in the received data packet was generated.
- One advantage of these methods is that they can greatly enhance reliability and simplicity when delivering multimedia streams e.g., as currently contemplated for delivering DASH formatted streams over eMBMS. Reliability is enhanced because instead of having to deliver a separate FDT for each file at or near the time the data packets for the file are sent, a single TFDT that compactly describes the FDTs for all the files can delivered reliably prior to the delivery of the individual files. Efficiency is enhanced because a smaller number of bytes are required to represent the same amount of information when this particular encoding is used.
- There are many variants of the TFDT methods described above. For example, the format of the TFDT may be similar to that of an FDT and delivered in a similar manner, i.e., delivered within the transmission (e.g., FLUTE) session as a separate object with TOI=0. Alternatively, a TFDT may be delivered via as an XML object, associated with a URL, and a receiver may download the XML object referenced by the URL using HTTP. Other methods for formatting and delivering TFDT information to receivers include including the TFDT information in the User Service Description (“USD”) that is used in MBMS to deliver FLUTE metadata to receivers. Other methods include delivering the TFDT information via a Session Announcement Protocol (“SAP”) message, and to format the TFDT information using a Session Description Protocol (“SDP”). Other alternatives include formatting and delivering TFDT information in a Rich Site Summary or Really Simple Syndication (“RSS”) feed. The TFDT information may be formatted and delivered using combinations of methods, e.g., partially delivered via the USD, partially delivered as part of a DASH MPD. In some cases at least some portions of the TFDT information may be formatted and delivered redundantly, i.e., some portions of the TFDT information may be formatted and delivered using one method and the same portions of the TFDT information may be formatted and delivered using a different method.
- Traditional delivery of individual files and the delivery of sequences of related files or objects may all be delivered within the same file delivery session. The signaling for the sequences of related files may use the TFDT methods described herein, wherein the individual files delivered with the same session may be delivered using traditional FDTs. In any case, it is preferable if the metadata for the sequences of related files and for the individual files delivered within the same session make it possible for the receiver to operate correctly, e.g., the TOI for an individual file should not match the TOI of any file for any sequence of files for which data packets are transmitted at the same time as data packets for the individual file. Alternatively, the metadata for the individual files may also be included in the TFDT, and thus the TFDT information comprises the delivery metadata for the individual files as well as for the sequences of related files for a session. As another alternative, a TFDT may contain all or portions of the metadata for files delivered in multiple transport sessions. As another alternative, a TFDT or multiple TFDTs may contain metadata for files for which packets are transmitted into multiple delivery sessions.
- Template-based file delivery and UOD address complementary important use cases for joint protection of multiple objects and can be used separately or together.
- The FEC OTI for Basic UOD RaptorQ can be exactly the same as for RaptorQ in [IETF-RFC-6330], but the FEC Payload ID can be simplified. The FEC Payload ID for RaptorQ in [IETF-RFC-6330] is (SBN, ESI), while the FEC Payload ID for Basic UOD RaptorQ is UOSI. Transmitting symbols in UOSI sequence utilizes network resources in an efficient and flexible fashion.
- An example of mapping an (SBN, ESI) pair to a UOSI can be as follows. To determine a (SBN, ESI) pair from a UOSI value, C, for an object known to have Z source blocks, set ESI=floor(C/Z) and then set SBN=C−(ESI)*Z. To determine a UOSI value, C, from a (SBN, ESI) pair for an object known to have Z source blocks, set C=SBN+(ESI)*Z. Table 3 shows an example mapping for Z=5.
-
TABLE 3 UOSI (C) SBN ESI 0 0 0 1 1 0 2 2 0 3 3 0 4 4 0 5 0 1 6 1 1 -
FIG. 13 illustrates an example object with FEC Payload ID (SBN, ESI). -
FIG. 14 illustrates an example object with FEC Payload ID (UOSI). - In a PST, each entry is identified by a unique PFI. Each entry in the PST contains (1) The number and sizes of FEC Payload IDs in a packet, (2) a specification of which object is associated with each symbol in a packet (it can use TOIs to make this association), and (3) a specification of which FEC Payload ID to use for each symbol in a packet. The PFI is carried in each packet to identify the format and data that is carried in the packet.
- For example, a first PST entry might specify a packet format comprising two FEC Payload IDs of two bytes each—UOSI format, with one symbol for the first object with TOI that uses the first FEC Payload ID, and one symbol for the second object with TOI that uses the second FEC Payload ID.
- In general, the PH could carry a list of sizes and formats of FEC Payload Ids, and the number of symbols of each of the objects carried in the packet, and the tie in to the FEC OTI. The PFI could also be carried in the FDT and associated with a TOI. As an example of a PFI, the PFI could indicate that the packets associated with a TOI carries 3 objects, with associated URLs and FEC OTI, and the format of the packets are: the first object has a UOSI of 1 byte and one symbol in the packet, the second object shares the UOSI with the first object and uses two symbols in the packet, the third object has a UOSI of 2 bytes and one symbol in the packet, and in this case the packet would contain a 1 byte UOSI for the first object, this UOSI would also be used for the second object, then a 2 byte UOSI for the third object, then one symbol for the first object, 2 symbols for the second object, and one symbol for the third object.
- As has now been described, there are some specific examples. Further embodiments can be envisioned to one of ordinary skill in the art after reading this disclosure. In other embodiments, combinations or sub-combinations of the above-disclosed invention can be advantageously made.
- Recovery at a decoder can be an exact recovery or at least approximately recovery of what was transmitted. Even if some data packets are lost, some can still be associated with their original data packet using transmission object identifiers. These transmission object identifiers might be constructed by a transmission object identifier constructor. For example, if two transmission object identifiers, they may be deemed to be associated with the same encoded symbols. Data can be arranged as one or more sequences of data objects. The sender and/or receiver can be an electronic device or system that communicates over a packet switched network. Packets can be generated from the sequences of data objects using a packet constructor to provide a packet output. Meta-data is an example of data in structured form, as might be useful for automated processing. The meta-data might be generated using templates and/or a template file delivery table.
- The example arrangements of components are shown for purposes of illustration and it should be understood that combinations, additions, re-arrangements, and the like are contemplated in alternative embodiments of the present invention. Thus, while the invention has been described with respect to exemplary embodiments, one skilled in the art will recognize that numerous modifications are possible. For example, the processes described herein may be implemented using hardware components, software components, and/or any combination thereof. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereunto without departing from the broader spirit and scope of the invention as set forth in the claims and that the invention is intended to cover all modifications and equivalents within the scope of the following claims.
Claims (33)
1. A method of delivering one or more data objects from an electronic device or system over a packet-switched network, wherein source data of the one or more data objects is represented by encoded symbols in packets such that the source data is recoverable, at least approximately, from the encoded symbols, the method comprising:
a) generating data in a structured form, including meta-data; and
b) generating meta-data using templates for delivering sequences of related objects.
2. A method of delivering one or more data objects from an electronic device or system over a packet-switched network, wherein source data of the one or more data objects is represented by encoded symbols in packets such that the source data is recoverable, at least approximately, from the encoded symbols, the method comprising:
a) generating data in a structured form, including meta-data; and
b) generating meta-data using multiplexed object transport encoding.
3. A method of delivering a sequence of data objects from an electronic device or system over a network to a client device, wherein source data of the sequence of data objects is represented by encoded symbols in packets such that the source data is recoverable, at least approximately, from the encoded symbols, the method comprising:
obtaining a template file delivery table that comprises delivery metadata for the sequence of data objects, the sequence of data objects comprising a plurality of data objects;
constructing a first transmission object identifier for a data object from the sequence of data objects based on a transmission object identifier construction rule described in the template file delivery table for the sequence of data objects;
receiving one or more data packets;
extracting a second transmission object identifier from a received data packet;
associating encoded symbols comprising the received data packet with the data object if the first transmission object identifier and the second transmission object identifier identify the same data object; and
recovering, at least approximately, the source data for the data object based on the encoded symbols associated with the data object.
4. The method of claim 3 , wherein a start transmission time and end transmission time for the data object are constructed based on a start transmission time construction rule and an end transmission time construction rule for the sequence of data objects described in the template file delivery table, and wherein the client device receives data packets for the data object at times that are between the start transmission time and end transmission time.
5. The method of claim 3 , wherein more than one data object is recovered from the sequence of data objects.
6. The method of claim 3 , wherein more than one sequence of data objects is described within the same session in the template file delivery table.
7. The method of claim 3 , wherein the template file delivery table also comprises information that relates how the sequence of data objects are associated with segments of a representation describe in a DASH MPD.
8. The method of claim 3 , wherein the template file delivery table also comprises the FEC object transmission information that is common to all objects in the sequence of data objects.
9. The method of claim 3 , wherein the template file delivery table comprises metadata delivery information for objects within the sequence of data objects that do not exist at the time that the template file delivery table is obtained by the client device.
10. The method of claim 3 , wherein the transmission object identifiers described within the template file delivery table for all objects are unique.
11. The method of claim 10 , wherein there are at least two sequences of objects described within the same delivery session within the template file delivery table and the transmission object identifiers for all objects are unique.
12. The method of claim 3 , wherein the transmission object identifiers for all objects with overlapping transmission times are unique, wherein the transmission object identifier and the start transmission time and end transmission time of each object in the sequence of data objects is described within the template file delivery table by a construction rule.
13. The method of claim 12 , wherein there are at least two sequences of objects described within the same delivery session within the template file delivery table and the transmission object identifiers for all objects with overlapping transmission times are unique.
14. A method of delivering a sequence of data objects from an electronic device or system over a network to a client device, wherein source data of the sequence of data objects is represented by encoded symbols in packets such that the source data is recoverable, at least approximately, from the encoded symbols, the method comprising:
obtaining a template file delivery table that comprises delivery metadata for the sequence of data objects, the sequence of data objects comprising a plurality of data objects;
receiving one or more data packets;
extracting a transmission object identifier from a received data packet;
associating encoded symbols comprising the received data packet with a data object from the sequence of data objects that corresponds to the transmission object identifier as determined by the transmission object identifier construction rule for the sequence of data objects described in the template file delivery table; and
recovering, at least approximately, the source data for the data object based on the encoded symbols associated with the data object.
15. The method of claim 14 , wherein a start transmission time and end transmission time for the data object are constructed based on a start transmission time construction rule and an end transmission time construction rule for the sequence of data objects described in the template file delivery table, and wherein the client device receives data packets for the data object at times that are between the start transmission time and end transmission time.
16. The method of claim 14 , wherein more than one data object is recovered from the sequence of data objects.
17. The method of claim 14 , wherein more than one sequence of data objects is described within the same session in the template file delivery table.
18. The method of claim 14 , wherein the template file delivery table also comprises information that relates how the sequence of data objects are associated with segments of a representation describe in a DASH MPD.
19. The method of claim 14 , wherein the template file delivery table also comprises FEC object transmission information that is common to all objects in the sequence of data objects.
20. The method of claim 14 , wherein the template file delivery table comprises metadata delivery information for objects within the sequence of data objects that do not exist at the time that the template file delivery table is obtained by the client device.
21. The method of claim 14 , wherein the transmission object identifiers described within the template file delivery table for all objects are unique.
22. The method of claim 21 , wherein there are at least two sequences of objects described within the same delivery session within the template file delivery table and the transmission object identifiers for all objects are unique.
23. The method of claim 14 , wherein the transmission object identifiers for all objects with overlapping transmission times are unique, wherein the transmission object identifier and the start transmission time and end transmission time of each object in the sequence of data objects is described within the template file delivery table by a construction rule.
24. The method of claim 23 , wherein there are at least two sequences of objects described within the same delivery session within the template file delivery table and the transmission object identifiers for all objects with overlapping transmission times are unique.
25. An object delivery server for delivering a sequence of data objects over a network to one or more client device, wherein source data of the sequence of data objects is represented by encoded symbols in packets such that the source data is recoverable, at least approximately, from the encoded symbols, the object delivery server comprising:
storage for a template file delivery table representing delivery metadata for the sequence of data objects, the sequence of data objects comprising a plurality of data objects;
a packet constructor that constructs a first transmission object identifier for a data object from the sequence of data objects based on a transmission object identifier construction rule described in the template file delivery table for the sequence of data objects and a second transmission object identifier for a different data object from the sequence of data objects based on a transmission object identifier construction rule described in the template file delivery table for the sequence of data objects; and
a packet output that outputs one or more data packets as constructed by the packet constructor for the data object and the different data object, wherein data objects are encoded with transmission object identifiers
26. The object delivery server of claim 25 , the data objects further comprising a start transmission time and end transmission time for the data object constructed based on a start transmission time construction rule and an end transmission time construction rule for the sequence of data objects described in the template file delivery table, such that the one or more client device receives data packets for the data object at times that are between the start transmission time and end transmission time.
27. The object delivery server of claim 25 , wherein more than one sequence of data objects is described within the same session in the template file delivery table.
28. The object delivery server of claim 25 , wherein the template file delivery table also comprises information that relates how the sequence of data objects are associated with segments of a representation describe in a DASH MPD.
29. The object delivery server of claim 25 , wherein the template file delivery table also comprises FEC object transmission information that is common to all objects in the sequence of data objects.
30. The object delivery server of claim 25 , wherein the transmission object identifiers described within the template file delivery table for all objects are unique.
31. The object delivery server of claim 30 , wherein there are at least two sequences of objects described within the same delivery session within the template file delivery table and the transmission object identifiers for all objects are unique.
32. The object delivery server of claim 25 , wherein the transmission object identifiers for all objects with overlapping transmission times are unique, wherein the transmission object identifier and the start transmission time and end transmission time of each object in the sequence of data objects is described within the template file delivery table by a construction rule.
33. The object delivery server of claim 32 , wherein there are at least two sequences of objects described within the same delivery session within the template file delivery table and the transmission object identifiers for all objects with overlapping transmission times are unique.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/076,235 US20170026148A1 (en) | 2012-03-26 | 2016-03-21 | Universal object delivery and template-based file delivery |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201261615796P | 2012-03-26 | 2012-03-26 | |
US13/753,442 US9294226B2 (en) | 2012-03-26 | 2013-01-29 | Universal object delivery and template-based file delivery |
US15/076,235 US20170026148A1 (en) | 2012-03-26 | 2016-03-21 | Universal object delivery and template-based file delivery |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/753,442 Continuation US9294226B2 (en) | 2012-03-26 | 2013-01-29 | Universal object delivery and template-based file delivery |
Publications (1)
Publication Number | Publication Date |
---|---|
US20170026148A1 true US20170026148A1 (en) | 2017-01-26 |
Family
ID=49213500
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/753,442 Expired - Fee Related US9294226B2 (en) | 2012-03-26 | 2013-01-29 | Universal object delivery and template-based file delivery |
US15/076,235 Abandoned US20170026148A1 (en) | 2012-03-26 | 2016-03-21 | Universal object delivery and template-based file delivery |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/753,442 Expired - Fee Related US9294226B2 (en) | 2012-03-26 | 2013-01-29 | Universal object delivery and template-based file delivery |
Country Status (4)
Country | Link |
---|---|
US (2) | US9294226B2 (en) |
EP (1) | EP2832022A1 (en) |
CN (1) | CN104221315B (en) |
WO (1) | WO2013148662A1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10305953B2 (en) | 2013-09-27 | 2019-05-28 | Saturn Licensing Llc | Content supplying apparatus, content supplying method, program, terminal device, and content supplying system |
Families Citing this family (55)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6307487B1 (en) | 1998-09-23 | 2001-10-23 | Digital Fountain, Inc. | Information additive code generator and decoder for communication systems |
US7068729B2 (en) | 2001-12-21 | 2006-06-27 | Digital Fountain, Inc. | Multi-stage code generator and decoder for communication systems |
US9240810B2 (en) | 2002-06-11 | 2016-01-19 | Digital Fountain, Inc. | Systems and processes for decoding chain reaction codes through inactivation |
KR101143282B1 (en) | 2002-10-05 | 2012-05-08 | 디지털 파운튼, 인크. | Systematic encoding and decoding of chain reaction codes |
CN101834610B (en) * | 2003-10-06 | 2013-01-30 | 数字方敦股份有限公司 | Method and device for receiving data transmitted from source through communication channel |
KR101205758B1 (en) | 2004-05-07 | 2012-12-03 | 디지털 파운튼, 인크. | File download and streaming system |
WO2006020826A2 (en) * | 2004-08-11 | 2006-02-23 | Digital Fountain, Inc. | Method and apparatus for fast encoding of data symbols according to half-weight codes |
CN101686107B (en) | 2006-02-13 | 2014-08-13 | 数字方敦股份有限公司 | Streaming and buffering using variable FEC overhead and protection periods |
US9270414B2 (en) | 2006-02-21 | 2016-02-23 | Digital Fountain, Inc. | Multiple-field based code generator and decoder for communications systems |
WO2007134196A2 (en) | 2006-05-10 | 2007-11-22 | Digital Fountain, Inc. | Code generator and decoder using hybrid codes |
US9432433B2 (en) | 2006-06-09 | 2016-08-30 | Qualcomm Incorporated | Enhanced block-request streaming system using signaling or block creation |
US9380096B2 (en) | 2006-06-09 | 2016-06-28 | Qualcomm Incorporated | Enhanced block-request streaming system for handling low-latency streaming |
US9386064B2 (en) | 2006-06-09 | 2016-07-05 | Qualcomm Incorporated | Enhanced block-request streaming using URL templates and construction rules |
US9209934B2 (en) | 2006-06-09 | 2015-12-08 | Qualcomm Incorporated | Enhanced block-request streaming using cooperative parallel HTTP and forward error correction |
US9178535B2 (en) | 2006-06-09 | 2015-11-03 | Digital Fountain, Inc. | Dynamic stream interleaving and sub-stream based delivery |
US9419749B2 (en) | 2009-08-19 | 2016-08-16 | Qualcomm Incorporated | Methods and apparatus employing FEC codes with permanent inactivation of symbols for encoding and decoding processes |
JP5027305B2 (en) | 2007-09-12 | 2012-09-19 | デジタル ファウンテン, インコーポレイテッド | Generation and transmission of source identification information to enable reliable communication |
US9281847B2 (en) | 2009-02-27 | 2016-03-08 | Qualcomm Incorporated | Mobile reception of digital video broadcasting—terrestrial services |
US9288010B2 (en) | 2009-08-19 | 2016-03-15 | Qualcomm Incorporated | Universal file delivery methods for providing unequal error protection and bundled file delivery services |
US9917874B2 (en) | 2009-09-22 | 2018-03-13 | Qualcomm Incorporated | Enhanced block-request streaming using block partitioning or request controls for improved client-side handling |
KR101781873B1 (en) * | 2010-04-19 | 2017-09-26 | 엘지전자 주식회사 | Apparatus and method for transmitting and receiving contents based on internet |
US9485546B2 (en) | 2010-06-29 | 2016-11-01 | Qualcomm Incorporated | Signaling video samples for trick mode video representations |
US8918533B2 (en) | 2010-07-13 | 2014-12-23 | Qualcomm Incorporated | Video switching for streaming video data |
US9185439B2 (en) | 2010-07-15 | 2015-11-10 | Qualcomm Incorporated | Signaling data for multiplexing video components |
US9596447B2 (en) | 2010-07-21 | 2017-03-14 | Qualcomm Incorporated | Providing frame packing type information for video coding |
US8806050B2 (en) | 2010-08-10 | 2014-08-12 | Qualcomm Incorporated | Manifest file updates for network streaming of coded multimedia data |
US9270299B2 (en) | 2011-02-11 | 2016-02-23 | Qualcomm Incorporated | Encoding and decoding using elastic codes with flexible source block mapping |
US8958375B2 (en) | 2011-02-11 | 2015-02-17 | Qualcomm Incorporated | Framing for an improved radio link protocol including FEC |
US9253233B2 (en) | 2011-08-31 | 2016-02-02 | Qualcomm Incorporated | Switch signaling methods providing improved switching between representations for adaptive HTTP streaming |
US9843844B2 (en) | 2011-10-05 | 2017-12-12 | Qualcomm Incorporated | Network streaming of media data |
US9438883B2 (en) * | 2012-04-09 | 2016-09-06 | Intel Corporation | Quality of experience reporting for combined unicast-multicast/broadcast streaming of media content |
WO2014015511A1 (en) * | 2012-07-27 | 2014-01-30 | Telefonaktiebolaget L M Ericsson (Publ) | User equipment node, server node and methods performed in such nodes for performing file repair procedure |
US9282366B2 (en) | 2012-08-13 | 2016-03-08 | The Nielsen Company (Us), Llc | Methods and apparatus to communicate audience measurement information |
US10360139B2 (en) * | 2013-03-12 | 2019-07-23 | Entit Software Llc | Identifying transport-level encoded payloads |
US9135292B1 (en) | 2013-04-08 | 2015-09-15 | Google Inc. | Selecting a template for a content item |
EP3017375B1 (en) | 2013-07-03 | 2019-04-03 | Nec Corporation | A method for operating a software defined network and a software defined network |
KR102163920B1 (en) * | 2014-01-03 | 2020-10-12 | 엘지전자 주식회사 | Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals |
WO2015126223A1 (en) * | 2014-02-24 | 2015-08-27 | Lg Electronics Inc. | Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals |
CN106464677A (en) * | 2014-04-09 | 2017-02-22 | Lg电子株式会社 | Method and apparatus for transmitting/receiving broadcast signal |
US9699499B2 (en) | 2014-04-30 | 2017-07-04 | The Nielsen Company (Us), Llc | Methods and apparatus to measure exposure to streaming media |
US9621354B2 (en) | 2014-07-17 | 2017-04-11 | Cisco Systems, Inc. | Reconstructable content objects |
US9787751B2 (en) | 2014-08-06 | 2017-10-10 | At&T Intellectual Property I, L.P. | Method and apparatus for delivering media content utilizing segment and packaging information |
US10348826B2 (en) | 2014-11-17 | 2019-07-09 | Red Hat, Inc. | Pattern-based object serving |
US9853868B2 (en) | 2014-12-05 | 2017-12-26 | Accenture Global Services Limited | Type-to-type analysis for cloud computing technical components |
US9860571B2 (en) | 2014-12-10 | 2018-01-02 | Lg Electronics Inc. | Apparatus for transmitting broadcast signal, apparatus for receiving broadcast signal, method for transmitting broadcast signal and method for receiving broadcast signal |
ES2865448T3 (en) * | 2015-02-11 | 2021-10-15 | Expway | Packet loss management procedure in transmissions based on the dash standard and the flute protocol |
US10659507B2 (en) | 2015-03-02 | 2020-05-19 | Qualcomm Incorporated | Indication for partial segment |
US10749930B2 (en) | 2015-03-02 | 2020-08-18 | Qualcomm Incorporated | Indication for partial segment |
US10412138B2 (en) * | 2015-03-02 | 2019-09-10 | Qualcomm Incorporated | Indication for partial segment |
US20160286013A1 (en) * | 2015-03-24 | 2016-09-29 | General Electric Company | Management of stream metadata during high volume real-time data streams |
US10165025B2 (en) | 2015-04-03 | 2018-12-25 | Qualcomm Incorporated | Techniques for HTTP live streaming over eMBMS |
US20170060700A1 (en) | 2015-08-28 | 2017-03-02 | Qualcomm Incorporated | Systems and methods for verification of code resiliency for data storage |
US10397079B2 (en) * | 2016-09-27 | 2019-08-27 | Netscout Systems, Inc. | Video delivery performance analysis for EMBMS |
US11057447B2 (en) | 2019-11-21 | 2021-07-06 | T-Mobile Usa, Inc. | Uniform packet streaming |
US11799700B1 (en) * | 2022-08-31 | 2023-10-24 | Qualcomm Incorporated | Decoding multi-level coded (MLC) systems |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5751723A (en) * | 1996-07-01 | 1998-05-12 | Motorola, Inc. | Method and system for overhead bandwidth recovery in a packetized network |
US20020085592A1 (en) * | 2000-12-28 | 2002-07-04 | Pioneer Corporation | Transport stream multiplexing method, transport stream multiplexing apparatus, and storage and reproduction system |
US20050203927A1 (en) * | 2000-07-24 | 2005-09-15 | Vivcom, Inc. | Fast metadata generation and delivery |
US20060015568A1 (en) * | 2004-07-14 | 2006-01-19 | Rod Walsh | Grouping of session objects |
US20060130118A1 (en) * | 2004-12-10 | 2006-06-15 | Alcatel | Distributive system for marking and blocking video and audio content related to video and audio programs |
US20100067553A1 (en) * | 2008-09-12 | 2010-03-18 | Viasys Healthcare, Inc | Synchronization of video with telemetry signals method and apparatus |
US20110299629A1 (en) * | 2009-08-19 | 2011-12-08 | Qualcomm Incorporated | Methods and apparatus employing fec codes with permanent inactivation of symbols for encoding and decoding processes |
US20110307581A1 (en) * | 2010-06-14 | 2011-12-15 | Research In Motion Limited | Media Presentation Description Delta File For HTTP Streaming |
Family Cites Families (520)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3909721A (en) | 1972-01-31 | 1975-09-30 | Signatron | Signal processing system |
US4365338A (en) | 1980-06-27 | 1982-12-21 | Harris Corporation | Technique for high rate digital transmission over a dynamic dispersive channel |
US4965825A (en) | 1981-11-03 | 1990-10-23 | The Personalized Mass Media Corporation | Signal processing apparatus and methods |
US4589112A (en) | 1984-01-26 | 1986-05-13 | International Business Machines Corporation | System for multiple error detection with single and double bit error correction |
US4901319A (en) | 1988-03-18 | 1990-02-13 | General Electric Company | Transmission system with adaptive interleaving |
GB8815978D0 (en) | 1988-07-05 | 1988-08-10 | British Telecomm | Method & apparatus for encoding decoding & transmitting data in compressed form |
US5136592A (en) | 1989-06-28 | 1992-08-04 | Digital Equipment Corporation | Error detection and correction system for long burst errors |
US5701582A (en) | 1989-08-23 | 1997-12-23 | Delta Beta Pty. Ltd. | Method and apparatus for efficient transmissions of programs |
US7594250B2 (en) | 1992-04-02 | 2009-09-22 | Debey Henry C | Method and system of program transmission optimization using a redundant transmission sequence |
US5421031A (en) | 1989-08-23 | 1995-05-30 | Delta Beta Pty. Ltd. | Program transmission optimisation |
US5455823A (en) | 1990-11-06 | 1995-10-03 | Radio Satellite Corporation | Integrated communications terminal |
US5164963A (en) | 1990-11-07 | 1992-11-17 | At&T Bell Laboratories | Coding for digital transmission |
US5465318A (en) | 1991-03-28 | 1995-11-07 | Kurzweil Applied Intelligence, Inc. | Method for generating a speech recognition model for a non-vocabulary utterance |
US5379297A (en) | 1992-04-09 | 1995-01-03 | Network Equipment Technologies, Inc. | Concurrent multi-channel segmentation and reassembly processors for asynchronous transfer mode |
EP0543070A1 (en) | 1991-11-21 | 1993-05-26 | International Business Machines Corporation | Coding system and method using quaternary codes |
US5371532A (en) | 1992-05-15 | 1994-12-06 | Bell Communications Research, Inc. | Communications architecture and method for distributing information services |
US5425050A (en) | 1992-10-23 | 1995-06-13 | Massachusetts Institute Of Technology | Television transmission system using spread spectrum and orthogonal frequency-division multiplex |
US5372532A (en) | 1993-01-26 | 1994-12-13 | Robertson, Jr.; George W. | Swivel head cap connector |
EP0613249A1 (en) | 1993-02-12 | 1994-08-31 | Altera Corporation | Custom look-up table with reduced number of architecture bits |
DE4316297C1 (en) | 1993-05-14 | 1994-04-07 | Fraunhofer Ges Forschung | Audio signal frequency analysis method - using window functions to provide sample signal blocks subjected to Fourier analysis to obtain respective coefficients. |
AU665716B2 (en) | 1993-07-05 | 1996-01-11 | Mitsubishi Denki Kabushiki Kaisha | A transmitter for encoding error correction codes and a receiver for decoding error correction codes on a transmission frame |
US5590405A (en) | 1993-10-29 | 1996-12-31 | Lucent Technologies Inc. | Communication technique employing variable information transmission |
JP2576776B2 (en) | 1993-11-10 | 1997-01-29 | 日本電気株式会社 | Packet transmission method and packet transmission device |
US5517508A (en) | 1994-01-26 | 1996-05-14 | Sony Corporation | Method and apparatus for detection and error correction of packetized digital data |
CA2140850C (en) | 1994-02-24 | 1999-09-21 | Howard Paul Katseff | Networked system for display of multimedia presentations |
US5566208A (en) | 1994-03-17 | 1996-10-15 | Philips Electronics North America Corp. | Encoder buffer having an effective size which varies automatically with the channel bit-rate |
US5432787A (en) | 1994-03-24 | 1995-07-11 | Loral Aerospace Corporation | Packet data transmission system with adaptive data recovery method |
US5757415A (en) | 1994-05-26 | 1998-05-26 | Sony Corporation | On-demand data transmission by dividing input data into blocks and each block into sub-blocks such that the sub-blocks are re-arranged for storage to data storage means |
US5802394A (en) | 1994-06-06 | 1998-09-01 | Starlight Networks, Inc. | Method for accessing one or more streams in a video storage system using multiple queues and maintaining continuity thereof |
US5739864A (en) | 1994-08-24 | 1998-04-14 | Macrovision Corporation | Apparatus for inserting blanked formatted fingerprint data (source ID, time/date) in to a video signal |
US5568614A (en) | 1994-07-29 | 1996-10-22 | International Business Machines Corporation | Data streaming between peer subsystems of a computer system |
US5668948A (en) | 1994-09-08 | 1997-09-16 | International Business Machines Corporation | Media streamer with control node enabling same isochronous streams to appear simultaneously at output ports or different streams to appear simultaneously at output ports |
US5926205A (en) | 1994-10-19 | 1999-07-20 | Imedia Corporation | Method and apparatus for encoding and formatting data representing a video program to provide multiple overlapping presentations of the video program |
US5659614A (en) | 1994-11-28 | 1997-08-19 | Bailey, Iii; John E. | Method and system for creating and storing a backup copy of file data stored on a computer |
US5617541A (en) | 1994-12-21 | 1997-04-01 | International Computer Science Institute | System for packetizing data encoded corresponding to priority levels where reconstructed data corresponds to fractionalized priority level and received fractionalized packets |
JP3614907B2 (en) | 1994-12-28 | 2005-01-26 | 株式会社東芝 | Data retransmission control method and data retransmission control system |
JPH11505685A (en) | 1995-04-27 | 1999-05-21 | トラスティーズ・オブ・ザ・スティーブンス・インスティテュート・オブ・テクノロジー | High integrity transmission for time-limited multimedia network applications |
US5835165A (en) | 1995-06-07 | 1998-11-10 | Lsi Logic Corporation | Reduction of false locking code words in concatenated decoders |
US5805825A (en) | 1995-07-26 | 1998-09-08 | Intel Corporation | Method for semi-reliable, unidirectional broadcast information services |
US6079041A (en) | 1995-08-04 | 2000-06-20 | Sanyo Electric Co., Ltd. | Digital modulation circuit and digital demodulation circuit |
US5754563A (en) | 1995-09-11 | 1998-05-19 | Ecc Technologies, Inc. | Byte-parallel system for implementing reed-solomon error-correcting codes |
KR0170298B1 (en) | 1995-10-10 | 1999-04-15 | 김광호 | A recording method of digital video tape |
US5751336A (en) | 1995-10-12 | 1998-05-12 | International Business Machines Corporation | Permutation based pyramid block transmission scheme for broadcasting in video-on-demand storage systems |
JP3305183B2 (en) | 1996-01-12 | 2002-07-22 | 株式会社東芝 | Digital broadcast receiving terminal |
US6012159A (en) | 1996-01-17 | 2000-01-04 | Kencast, Inc. | Method and system for error-free data transfer |
US5936659A (en) | 1996-01-31 | 1999-08-10 | Telcordia Technologies, Inc. | Method for video delivery using pyramid broadcasting |
US5903775A (en) | 1996-06-06 | 1999-05-11 | International Business Machines Corporation | Method for the sequential transmission of compressed video information at varying data rates |
US5745504A (en) | 1996-06-25 | 1998-04-28 | Telefonaktiebolaget Lm Ericsson | Bit error resilient variable length code |
US5940863A (en) | 1996-07-26 | 1999-08-17 | Zenith Electronics Corporation | Apparatus for de-rotating and de-interleaving data including plural memory devices and plural modulo memory address generators |
US5936949A (en) | 1996-09-05 | 1999-08-10 | Netro Corporation | Wireless ATM metropolitan area network |
KR100261706B1 (en) | 1996-12-17 | 2000-07-15 | 가나이 쓰도무 | Digital broadcasting signal receiving device and, receiving and recording/reproducing apparatus |
US6141053A (en) | 1997-01-03 | 2000-10-31 | Saukkonen; Jukka I. | Method of optimizing bandwidth for transmitting compressed video data streams |
US6011590A (en) | 1997-01-03 | 2000-01-04 | Ncr Corporation | Method of transmitting compressed information to minimize buffer space |
US6044485A (en) | 1997-01-03 | 2000-03-28 | Ericsson Inc. | Transmitter method and transmission system using adaptive coding based on channel characteristics |
US5983383A (en) | 1997-01-17 | 1999-11-09 | Qualcom Incorporated | Method and apparatus for transmitting and receiving concatenated code data |
EP0854650A3 (en) | 1997-01-17 | 2001-05-02 | NOKIA TECHNOLOGY GmbH | Method for addressing a service in digital video broadcasting |
US5946357A (en) | 1997-01-17 | 1999-08-31 | Telefonaktiebolaget L M Ericsson | Apparatus, and associated method, for transmitting and receiving a multi-stage, encoded and interleaved digital communication signal |
US6014706A (en) | 1997-01-30 | 2000-01-11 | Microsoft Corporation | Methods and apparatus for implementing control functions in a streamed video display system |
US6115420A (en) | 1997-03-14 | 2000-09-05 | Microsoft Corporation | Digital video signal encoder and encoding method |
DE19716011A1 (en) | 1997-04-17 | 1998-10-22 | Abb Research Ltd | Method and device for transmitting information via power supply lines |
US6226259B1 (en) | 1997-04-29 | 2001-05-01 | Canon Kabushiki Kaisha | Device and method for transmitting information device and method for processing information |
US5970098A (en) | 1997-05-02 | 1999-10-19 | Globespan Technologies, Inc. | Multilevel encoder |
US5844636A (en) | 1997-05-13 | 1998-12-01 | Hughes Electronics Corporation | Method and apparatus for receiving and recording digital packet data |
WO1998053454A1 (en) | 1997-05-19 | 1998-11-26 | Sanyo Electric Co., Ltd. | Digital modulation and digital demodulation |
JPH1141211A (en) | 1997-05-19 | 1999-02-12 | Sanyo Electric Co Ltd | Digital modulatin circuit and its method, and digital demodulation circuit and its method |
JP4110593B2 (en) | 1997-05-19 | 2008-07-02 | ソニー株式会社 | Signal recording method and signal recording apparatus |
US6128649A (en) | 1997-06-02 | 2000-10-03 | Nortel Networks Limited | Dynamic selection of media streams for display |
US6081907A (en) | 1997-06-09 | 2000-06-27 | Microsoft Corporation | Data delivery system and method for delivering data and redundant information over a unidirectional network |
US5917852A (en) | 1997-06-11 | 1999-06-29 | L-3 Communications Corporation | Data scrambling system and method and communications system incorporating same |
KR100240869B1 (en) | 1997-06-25 | 2000-01-15 | 윤종용 | Data transmission method for dual diversity system |
US6175944B1 (en) | 1997-07-15 | 2001-01-16 | Lucent Technologies Inc. | Methods and apparatus for packetizing data for transmission through an erasure broadcast channel |
US5933056A (en) | 1997-07-15 | 1999-08-03 | Exar Corporation | Single pole current mode common-mode feedback circuit |
US6047069A (en) | 1997-07-17 | 2000-04-04 | Hewlett-Packard Company | Method and apparatus for preserving error correction capabilities during data encryption/decryption |
US6904110B2 (en) | 1997-07-31 | 2005-06-07 | Francois Trans | Channel equalization system and method |
US6178536B1 (en) | 1997-08-14 | 2001-01-23 | International Business Machines Corporation | Coding scheme for file backup and systems based thereon |
FR2767940A1 (en) | 1997-08-29 | 1999-02-26 | Canon Kk | CODING AND DECODING METHODS AND DEVICES AND APPARATUSES IMPLEMENTING THE SAME |
EP0903955A1 (en) | 1997-09-04 | 1999-03-24 | STMicroelectronics S.r.l. | Modular architecture PET decoder for ATM networks |
US6088330A (en) | 1997-09-09 | 2000-07-11 | Bruck; Joshua | Reliable array of distributed computing nodes |
US6134596A (en) | 1997-09-18 | 2000-10-17 | Microsoft Corporation | Continuous media file server system and method for scheduling network resources to play multiple files having different data transmission rates |
US6272658B1 (en) | 1997-10-27 | 2001-08-07 | Kencast, Inc. | Method and system for reliable broadcasting of data files and streams |
US6081909A (en) | 1997-11-06 | 2000-06-27 | Digital Equipment Corporation | Irregularly graphed encoding technique |
US6195777B1 (en) | 1997-11-06 | 2001-02-27 | Compaq Computer Corporation | Loss resilient code with double heavy tailed series of redundant layers |
US6163870A (en) | 1997-11-06 | 2000-12-19 | Compaq Computer Corporation | Message encoding with irregular graphing |
US6081918A (en) | 1997-11-06 | 2000-06-27 | Spielman; Daniel A. | Loss resilient code with cascading series of redundant layers |
US6073250A (en) | 1997-11-06 | 2000-06-06 | Luby; Michael G. | Loss resilient decoding technique |
JP3472115B2 (en) | 1997-11-25 | 2003-12-02 | Kddi株式会社 | Video data transmission method and apparatus using multi-channel |
US5870412A (en) | 1997-12-12 | 1999-02-09 | 3Com Corporation | Forward error correction system for packet based real time media |
US6243846B1 (en) | 1997-12-12 | 2001-06-05 | 3Com Corporation | Forward error correction system for packet based data and real time media, using cross-wise parity calculation |
US6849803B1 (en) | 1998-01-15 | 2005-02-01 | Arlington Industries, Inc. | Electrical connector |
US6097320A (en) | 1998-01-20 | 2000-08-01 | Silicon Systems, Inc. | Encoder/decoder system with suppressed error propagation |
US6226301B1 (en) | 1998-02-19 | 2001-05-01 | Nokia Mobile Phones Ltd | Method and apparatus for segmentation and assembly of data frames for retransmission in a telecommunications system |
US6141788A (en) | 1998-03-13 | 2000-10-31 | Lucent Technologies Inc. | Method and apparatus for forward error correction in packet networks |
US6278716B1 (en) | 1998-03-23 | 2001-08-21 | University Of Massachusetts | Multicast with proactive forward error correction |
US6459811B1 (en) | 1998-04-02 | 2002-10-01 | Sarnoff Corporation | Bursty data transmission of compressed video data |
US6185265B1 (en) | 1998-04-07 | 2001-02-06 | Worldspace Management Corp. | System for time division multiplexing broadcast channels with R-1/2 or R-3/4 convolutional coding for satellite transmission via on-board baseband processing payload or transparent payload |
US6067646A (en) | 1998-04-17 | 2000-05-23 | Ameritech Corporation | Method and system for adaptive interleaving |
US6018359A (en) | 1998-04-24 | 2000-01-25 | Massachusetts Institute Of Technology | System and method for multicast video-on-demand delivery system |
US6445717B1 (en) | 1998-05-01 | 2002-09-03 | Niwot Networks, Inc. | System for recovering lost information in a data stream |
US6421387B1 (en) | 1998-05-15 | 2002-07-16 | North Carolina State University | Methods and systems for forward error correction based loss recovery for interactive video transmission |
US6937618B1 (en) | 1998-05-20 | 2005-08-30 | Sony Corporation | Separating device and method and signal receiving device and method |
US6333926B1 (en) | 1998-08-11 | 2001-12-25 | Nortel Networks Limited | Multiple user CDMA basestation modem |
EP1110344A1 (en) | 1998-09-04 | 2001-06-27 | AT&T Corp. | Combined channel coding and space-block coding in a multi-antenna arrangement |
US6415326B1 (en) | 1998-09-15 | 2002-07-02 | Microsoft Corporation | Timeline correlation between multiple timeline-altered media streams |
US7068729B2 (en) | 2001-12-21 | 2006-06-27 | Digital Fountain, Inc. | Multi-stage code generator and decoder for communication systems |
US6307487B1 (en) | 1998-09-23 | 2001-10-23 | Digital Fountain, Inc. | Information additive code generator and decoder for communication systems |
US6320520B1 (en) | 1998-09-23 | 2001-11-20 | Digital Fountain | Information additive group code generator and decoder for communications systems |
US7243285B2 (en) | 1998-09-23 | 2007-07-10 | Digital Fountain, Inc. | Systems and methods for broadcasting information additive codes |
US6704370B1 (en) | 1998-10-09 | 2004-03-09 | Nortel Networks Limited | Interleaving methodology and apparatus for CDMA |
IT1303735B1 (en) | 1998-11-11 | 2001-02-23 | Falorni Italia Farmaceutici S | CROSS-LINKED HYALURONIC ACIDS AND THEIR MEDICAL USES. |
US6408128B1 (en) | 1998-11-12 | 2002-06-18 | Max Abecassis | Replaying with supplementary information a segment of a video |
US6483736B2 (en) | 1998-11-16 | 2002-11-19 | Matrix Semiconductor, Inc. | Vertically stacked field programmable nonvolatile memory and method of fabrication |
JP2000151426A (en) | 1998-11-17 | 2000-05-30 | Toshiba Corp | Interleave and de-interleave circuit |
US6166544A (en) | 1998-11-25 | 2000-12-26 | General Electric Company | MR imaging system with interactive image contrast control |
US6876623B1 (en) | 1998-12-02 | 2005-04-05 | Agere Systems Inc. | Tuning scheme for code division multiplex broadcasting system |
ES2185244T3 (en) | 1998-12-03 | 2003-04-16 | Fraunhofer Ges Forschung | APPARATUS AND PROCEDURE TO TRANSMIT INFORMATION AND APPLIANCE AND PROCEDURE TO RECEIVE INFORMATION. |
US6637031B1 (en) | 1998-12-04 | 2003-10-21 | Microsoft Corporation | Multimedia presentation latency minimization |
US6496980B1 (en) | 1998-12-07 | 2002-12-17 | Intel Corporation | Method of providing replay on demand for streaming digital multimedia |
US6223324B1 (en) | 1999-01-05 | 2001-04-24 | Agere Systems Guardian Corp. | Multiple program unequal error protection for digital audio broadcasting and other applications |
JP3926499B2 (en) | 1999-01-22 | 2007-06-06 | 株式会社日立国際電気 | Convolutional code soft decision decoding receiver |
US6618451B1 (en) | 1999-02-13 | 2003-09-09 | Altocom Inc | Efficient reduced state maximum likelihood sequence estimator |
US6041001A (en) | 1999-02-25 | 2000-03-21 | Lexar Media, Inc. | Method of increasing data reliability of a flash memory device without compromising compatibility |
AU2827400A (en) | 1999-03-03 | 2000-09-21 | Sony Corporation | Transmitter, receiver, transmitter/receiver system, transmission method and reception method |
US6785323B1 (en) | 1999-11-22 | 2004-08-31 | Ipr Licensing, Inc. | Variable rate coding for forward link |
US6466698B1 (en) | 1999-03-25 | 2002-10-15 | The United States Of America As Represented By The Secretary Of The Navy | Efficient embedded image and video compression system using lifted wavelets |
JP3256517B2 (en) | 1999-04-06 | 2002-02-12 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Encoding circuit, circuit, parity generation method, and storage medium |
US6535920B1 (en) | 1999-04-06 | 2003-03-18 | Microsoft Corporation | Analyzing, indexing and seeking of streaming information |
US6609223B1 (en) | 1999-04-06 | 2003-08-19 | Kencast, Inc. | Method for packet-level fec encoding, in which on a source packet-by-source packet basis, the error correction contributions of a source packet to a plurality of wildcard packets are computed, and the source packet is transmitted thereafter |
US6804202B1 (en) | 1999-04-08 | 2004-10-12 | Lg Information And Communications, Ltd. | Radio protocol for mobile communication system and method |
US7885340B2 (en) | 1999-04-27 | 2011-02-08 | Realnetworks, Inc. | System and method for generating multiple synchronized encoded representations of media data |
FI113124B (en) | 1999-04-29 | 2004-02-27 | Nokia Corp | Communication |
DE60028120T2 (en) | 1999-05-06 | 2006-12-28 | Sony Corp. | Data processing method and apparatus, data reproduction method and apparatus, data recording media |
KR100416996B1 (en) | 1999-05-10 | 2004-02-05 | 삼성전자주식회사 | Variable-length data transmitting and receiving apparatus in accordance with radio link protocol for a mobile telecommunication system and method thereof |
AU5140200A (en) | 1999-05-26 | 2000-12-18 | Enounce, Incorporated | Method and apparatus for controlling time-scale modification during multi-media broadcasts |
US6154452A (en) | 1999-05-26 | 2000-11-28 | Xm Satellite Radio Inc. | Method and apparatus for continuous cross-channel interleaving |
US6229824B1 (en) | 1999-05-26 | 2001-05-08 | Xm Satellite Radio Inc. | Method and apparatus for concatenated convolutional endcoding and interleaving |
JP2000353969A (en) | 1999-06-11 | 2000-12-19 | Sony Corp | Receiver for digital voice broadcasting |
US6577599B1 (en) | 1999-06-30 | 2003-06-10 | Sun Microsystems, Inc. | Small-scale reliable multicasting |
IL141800A0 (en) | 1999-07-06 | 2002-03-10 | Samsung Electronics Co Ltd | Rate matching device and method for a data communication system |
US6643332B1 (en) | 1999-07-09 | 2003-11-04 | Lsi Logic Corporation | Method and apparatus for multi-level coding of digital signals |
US6279072B1 (en) | 1999-07-22 | 2001-08-21 | Micron Technology, Inc. | Reconfigurable memory with selectable error correction storage |
JP3451221B2 (en) | 1999-07-22 | 2003-09-29 | 日本無線株式会社 | Error correction coding apparatus, method and medium, and error correction code decoding apparatus, method and medium |
US6453440B1 (en) | 1999-08-04 | 2002-09-17 | Sun Microsystems, Inc. | System and method for detecting double-bit errors and for correcting errors due to component failures |
JP2001060934A (en) | 1999-08-20 | 2001-03-06 | Matsushita Electric Ind Co Ltd | Ofdm communication equipment |
US6430233B1 (en) | 1999-08-30 | 2002-08-06 | Hughes Electronics Corporation | Single-LNB satellite data receiver |
US6332163B1 (en) | 1999-09-01 | 2001-12-18 | Accenture, Llp | Method for providing communication services over a computer network system |
JP4284774B2 (en) | 1999-09-07 | 2009-06-24 | ソニー株式会社 | Transmission device, reception device, communication system, transmission method, and communication method |
JP2003510734A (en) | 1999-09-27 | 2003-03-18 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | File splitting for emulating streaming |
US7529806B1 (en) | 1999-11-04 | 2009-05-05 | Koninklijke Philips Electronics N.V. | Partitioning of MP3 content file for emulating streaming |
JP2001094625A (en) | 1999-09-27 | 2001-04-06 | Canon Inc | Data communication unit, data communication method and storage medium |
US20050160272A1 (en) | 1999-10-28 | 2005-07-21 | Timecertain, Llc | System and method for providing trusted time in content of digital data files |
US6523147B1 (en) | 1999-11-11 | 2003-02-18 | Ibiquity Digital Corporation | Method and apparatus for forward error correction coding for an AM in-band on-channel digital audio broadcasting system |
US6678855B1 (en) | 1999-12-02 | 2004-01-13 | Microsoft Corporation | Selecting K in a data transmission carousel using (N,K) forward error correction |
US6748441B1 (en) | 1999-12-02 | 2004-06-08 | Microsoft Corporation | Data carousel receiving and caching |
US6798791B1 (en) | 1999-12-16 | 2004-09-28 | Agere Systems Inc | Cluster frame synchronization scheme for a satellite digital audio radio system |
US6487692B1 (en) | 1999-12-21 | 2002-11-26 | Lsi Logic Corporation | Reed-Solomon decoder |
US20020009137A1 (en) | 2000-02-01 | 2002-01-24 | Nelson John E. | Three-dimensional video broadcasting system |
US6965636B1 (en) | 2000-02-01 | 2005-11-15 | 2Wire, Inc. | System and method for block error correction in packet-based digital communications |
WO2001057667A1 (en) | 2000-02-03 | 2001-08-09 | Bandwiz, Inc. | Data streaming |
IL140504A0 (en) | 2000-02-03 | 2002-02-10 | Bandwiz Inc | Broadcast system |
US7304990B2 (en) | 2000-02-03 | 2007-12-04 | Bandwiz Inc. | Method of encoding and transmitting data over a communication medium through division and segmentation |
JP2001251287A (en) | 2000-02-24 | 2001-09-14 | Geneticware Corp Ltd | Confidential transmitting method using hardware protection inside secret key and variable pass code |
DE10009443A1 (en) | 2000-02-29 | 2001-08-30 | Philips Corp Intellectual Pty | Receiver and method for detecting and decoding a DQPSK-modulated and channel-coded received signal |
US6765866B1 (en) | 2000-02-29 | 2004-07-20 | Mosaid Technologies, Inc. | Link aggregation |
US6384750B1 (en) | 2000-03-23 | 2002-05-07 | Mosaid Technologies, Inc. | Multi-stage lookup for translating between signals of different bit lengths |
JP2001274776A (en) | 2000-03-24 | 2001-10-05 | Toshiba Corp | Information data transmission system and its transmitter and receiver |
US6510177B1 (en) | 2000-03-24 | 2003-01-21 | Microsoft Corporation | System and method for layered video coding enhancement |
WO2001076077A2 (en) | 2000-03-31 | 2001-10-11 | Ted Szymanski | Transmitter, receiver, and coding scheme to increase data rate and decrease bit error rate of an optical data link |
US6473010B1 (en) | 2000-04-04 | 2002-10-29 | Marvell International, Ltd. | Method and apparatus for determining error correction code failure rate for iterative decoding algorithms |
US8572646B2 (en) | 2000-04-07 | 2013-10-29 | Visible World Inc. | System and method for simultaneous broadcast for personalized messages |
JP4640723B2 (en) | 2000-04-08 | 2011-03-02 | オラクル・アメリカ・インコーポレイテッド | Stream a single media track to multiple clients |
US6631172B1 (en) | 2000-05-01 | 2003-10-07 | Lucent Technologies Inc. | Efficient list decoding of Reed-Solomon codes for message recovery in the presence of high noise levels |
US6742154B1 (en) | 2000-05-25 | 2004-05-25 | Ciena Corporation | Forward error correction codes for digital optical network optimization |
US6694476B1 (en) | 2000-06-02 | 2004-02-17 | Vitesse Semiconductor Corporation | Reed-solomon encoder and decoder |
US6738942B1 (en) | 2000-06-02 | 2004-05-18 | Vitesse Semiconductor Corporation | Product code based forward error correction system |
GB2366159B (en) | 2000-08-10 | 2003-10-08 | Mitel Corp | Combination reed-solomon and turbo coding |
US6834342B2 (en) | 2000-08-16 | 2004-12-21 | Eecad, Inc. | Method and system for secure communication over unstable public connections |
KR100447162B1 (en) | 2000-08-19 | 2004-09-04 | 엘지전자 주식회사 | Method for length indicator inserting in protocol data unit of radio link control |
JP2002073625A (en) | 2000-08-24 | 2002-03-12 | Nippon Hoso Kyokai <Nhk> | Method server and medium for providing information synchronously with broadcast program |
US7340664B2 (en) | 2000-09-20 | 2008-03-04 | Lsi Logic Corporation | Single engine turbo decoder with single frame size buffer for interleaving/deinterleaving |
US7151754B1 (en) | 2000-09-22 | 2006-12-19 | Lucent Technologies Inc. | Complete user datagram protocol (CUDP) for wireless multimedia packet networks using improved packet level forward error correction (FEC) coding |
US7031257B1 (en) | 2000-09-22 | 2006-04-18 | Lucent Technologies Inc. | Radio link protocol (RLP)/point-to-point protocol (PPP) design that passes corrupted data and error location information among layers in a wireless data transmission protocol |
US6486803B1 (en) | 2000-09-22 | 2002-11-26 | Digital Fountain, Inc. | On demand encoding with a window |
US7490344B2 (en) | 2000-09-29 | 2009-02-10 | Visible World, Inc. | System and method for seamless switching |
US6411223B1 (en) | 2000-10-18 | 2002-06-25 | Digital Fountain, Inc. | Generating high weight encoding symbols using a basis |
US7613183B1 (en) | 2000-10-31 | 2009-11-03 | Foundry Networks, Inc. | System and method for router data aggregation and delivery |
US6694478B1 (en) | 2000-11-07 | 2004-02-17 | Agere Systems Inc. | Low delay channel codes for correcting bursts of lost packets |
US6732325B1 (en) | 2000-11-08 | 2004-05-04 | Digeo, Inc. | Error-correction with limited working storage |
US20020133247A1 (en) | 2000-11-11 | 2002-09-19 | Smith Robert D. | System and method for seamlessly switching between media streams |
US7072971B2 (en) | 2000-11-13 | 2006-07-04 | Digital Foundation, Inc. | Scheduling of multiple files for serving on a server |
US7240358B2 (en) | 2000-12-08 | 2007-07-03 | Digital Fountain, Inc. | Methods and apparatus for scheduling, serving, receiving media-on demand for clients, servers arranged according to constraints on resources |
AU2002220927B2 (en) | 2000-12-15 | 2006-03-16 | British Telecommunications Public Limited Company | Transmission and reception of audio and/or video material |
ES2342357T3 (en) | 2000-12-15 | 2010-07-06 | British Telecommunications Public Limited Company | TRANSMISSION AND RECEPTION OF AUDIO AND / OR VIDEO MATERIAL. |
US6850736B2 (en) | 2000-12-21 | 2005-02-01 | Tropian, Inc. | Method and apparatus for reception quality indication in wireless communication |
US7143433B1 (en) | 2000-12-27 | 2006-11-28 | Infovalve Computing Inc. | Video distribution system using dynamic segmenting of video data files |
US20020085013A1 (en) | 2000-12-29 | 2002-07-04 | Lippincott Louis A. | Scan synchronized dual frame buffer graphics subsystem |
NO315887B1 (en) | 2001-01-04 | 2003-11-03 | Fast Search & Transfer As | Procedures for transmitting and socking video information |
US20080059532A1 (en) | 2001-01-18 | 2008-03-06 | Kazmi Syed N | Method and system for managing digital content, including streaming media |
DE10103387A1 (en) | 2001-01-26 | 2002-08-01 | Thorsten Nordhoff | Wind power plant with a device for obstacle lighting or night marking |
FI118830B (en) | 2001-02-08 | 2008-03-31 | Nokia Corp | Streaming playback |
US6868083B2 (en) | 2001-02-16 | 2005-03-15 | Hewlett-Packard Development Company, L.P. | Method and system for packet communication employing path diversity |
US20020129159A1 (en) | 2001-03-09 | 2002-09-12 | Michael Luby | Multi-output packet server with independent streams |
KR100464360B1 (en) | 2001-03-30 | 2005-01-03 | 삼성전자주식회사 | Apparatus and method for efficiently energy distributing over packet data channel in mobile communication system for high rate packet transmission |
US20020143953A1 (en) | 2001-04-03 | 2002-10-03 | International Business Machines Corporation | Automatic affinity within networks performing workload balancing |
US6785836B2 (en) | 2001-04-11 | 2004-08-31 | Broadcom Corporation | In-place data transformation for fault-tolerant disk storage systems |
US6820221B2 (en) | 2001-04-13 | 2004-11-16 | Hewlett-Packard Development Company, L.P. | System and method for detecting process and network failures in a distributed system |
US7010052B2 (en) | 2001-04-16 | 2006-03-07 | The Ohio University | Apparatus and method of CTCM encoding and decoding for a digital communication system |
US7035468B2 (en) | 2001-04-20 | 2006-04-25 | Front Porch Digital Inc. | Methods and apparatus for archiving, indexing and accessing audio and video data |
TWI246841B (en) | 2001-04-22 | 2006-01-01 | Koninkl Philips Electronics Nv | Digital transmission system and method for transmitting digital signals |
US20020191116A1 (en) | 2001-04-24 | 2002-12-19 | Damien Kessler | System and data format for providing seamless stream switching in a digital video recorder |
US6497479B1 (en) | 2001-04-27 | 2002-12-24 | Hewlett-Packard Company | Higher organic inks with good reliability and drytime |
US7962482B2 (en) | 2001-05-16 | 2011-06-14 | Pandora Media, Inc. | Methods and systems for utilizing contextual feedback to generate and modify playlists |
US6633856B2 (en) | 2001-06-15 | 2003-10-14 | Flarion Technologies, Inc. | Methods and apparatus for decoding LDPC codes |
US7076478B2 (en) | 2001-06-26 | 2006-07-11 | Microsoft Corporation | Wrapper playlists on streaming media services |
US6745364B2 (en) | 2001-06-28 | 2004-06-01 | Microsoft Corporation | Negotiated/dynamic error correction for streamed media |
US6895547B2 (en) | 2001-07-11 | 2005-05-17 | International Business Machines Corporation | Method and apparatus for low density parity check encoding of data |
US6928603B1 (en) | 2001-07-19 | 2005-08-09 | Adaptix, Inc. | System and method for interference mitigation using adaptive forward error correction in a wireless RF data transmission system |
US6961890B2 (en) | 2001-08-16 | 2005-11-01 | Hewlett-Packard Development Company, L.P. | Dynamic variable-length error correction code |
US7110412B2 (en) | 2001-09-18 | 2006-09-19 | Sbc Technology Resources, Inc. | Method and system to transport high-quality video signals |
FI115418B (en) | 2001-09-20 | 2005-04-29 | Oplayo Oy | Adaptive media stream |
US7343487B2 (en) * | 2001-10-10 | 2008-03-11 | Nokia Corporation | Datacast distribution system |
US6990624B2 (en) | 2001-10-12 | 2006-01-24 | Agere Systems Inc. | High speed syndrome-based FEC encoder and decoder and system using same |
US7480703B2 (en) | 2001-11-09 | 2009-01-20 | Sony Corporation | System, method, and computer program product for remotely determining the configuration of a multi-media content user based on response of the user |
US7003712B2 (en) | 2001-11-29 | 2006-02-21 | Emin Martinian | Apparatus and method for adaptive, multimode decoding |
US7363354B2 (en) | 2001-11-29 | 2008-04-22 | Nokia Corporation | System and method for identifying and accessing network services |
JP2003174489A (en) | 2001-12-05 | 2003-06-20 | Ntt Docomo Inc | Streaming distribution device and streaming distribution method |
FI114527B (en) | 2002-01-23 | 2004-10-29 | Nokia Corp | Grouping of picture frames in video encoding |
KR100931915B1 (en) | 2002-01-23 | 2009-12-15 | 노키아 코포레이션 | Grouping of Image Frames in Video Coding |
EP1472847A1 (en) | 2002-01-30 | 2004-11-03 | Koninklijke Philips Electronics N.V. | Streaming multimedia data over a network having a variable bandwidth |
US7249291B2 (en) | 2002-02-15 | 2007-07-24 | Digital Fountain, Inc. | System and method for reliably communicating the content of a live data stream |
JP4126928B2 (en) | 2002-02-28 | 2008-07-30 | 日本電気株式会社 | Proxy server and proxy control program |
JP4116470B2 (en) | 2002-03-06 | 2008-07-09 | ヒューレット・パッカード・カンパニー | Media streaming distribution system |
FR2837332A1 (en) | 2002-03-15 | 2003-09-19 | Thomson Licensing Sa | DEVICE AND METHOD FOR INSERTING ERROR CORRECTION AND RECONSTITUTION CODES OF DATA STREAMS, AND CORRESPONDING PRODUCTS |
MXPA04010058A (en) | 2002-04-15 | 2004-12-13 | Nokia Corp | Rlp logical layer of a communication station. |
US6677864B2 (en) | 2002-04-18 | 2004-01-13 | Telefonaktiebolaget L.M. Ericsson | Method for multicast over wireless networks |
JP3689063B2 (en) | 2002-04-19 | 2005-08-31 | 松下電器産業株式会社 | Data receiving apparatus and data distribution system |
JP3629008B2 (en) | 2002-04-19 | 2005-03-16 | 松下電器産業株式会社 | Data receiving apparatus and data distribution system |
US20030204602A1 (en) | 2002-04-26 | 2003-10-30 | Hudson Michael D. | Mediated multi-source peer content delivery network architecture |
US7177658B2 (en) | 2002-05-06 | 2007-02-13 | Qualcomm, Incorporated | Multi-media broadcast and multicast service (MBMS) in a wireless communications system |
US7124163B2 (en) * | 2002-05-24 | 2006-10-17 | Convedia Corporation | Data server |
US7200388B2 (en) | 2002-05-31 | 2007-04-03 | Nokia Corporation | Fragmented delivery of multimedia |
WO2003105484A1 (en) | 2002-06-11 | 2003-12-18 | Telefonaktiebolaget L M Ericsson (Publ) | Generation of mixed media streams |
EP2278720B1 (en) | 2002-06-11 | 2013-12-25 | Digital Fountain, Inc. | Decoding of chain reaction codes through inactivation |
US9240810B2 (en) | 2002-06-11 | 2016-01-19 | Digital Fountain, Inc. | Systems and processes for decoding chain reaction codes through inactivation |
US6956875B2 (en) | 2002-06-19 | 2005-10-18 | Atlinks Usa, Inc. | Technique for communicating variable bit rate data over a constant bit rate link |
JP4120461B2 (en) | 2002-07-12 | 2008-07-16 | 住友電気工業株式会社 | Transmission data generation method and transmission data generation apparatus |
WO2004019521A1 (en) | 2002-07-31 | 2004-03-04 | Sharp Kabushiki Kaisha | Data communication device, its intermittent communication method, program describing its method, and recording medium on which program is recorded |
JP2004070712A (en) | 2002-08-07 | 2004-03-04 | Nippon Telegr & Teleph Corp <Ntt> | Data delivery method, data delivery system, split delivery data receiving method, split delivery data receiving device and split delivery data receiving program |
CN100542157C (en) | 2002-08-13 | 2009-09-16 | 诺基亚公司 | Symbol interleaving |
US6985459B2 (en) | 2002-08-21 | 2006-01-10 | Qualcomm Incorporated | Early transmission and playout of packets in wireless communication systems |
WO2004030273A1 (en) | 2002-09-27 | 2004-04-08 | Fujitsu Limited | Data delivery method, system, transfer method, and program |
JP3534742B1 (en) | 2002-10-03 | 2004-06-07 | 株式会社エヌ・ティ・ティ・ドコモ | Moving picture decoding method, moving picture decoding apparatus, and moving picture decoding program |
KR101143282B1 (en) | 2002-10-05 | 2012-05-08 | 디지털 파운튼, 인크. | Systematic encoding and decoding of chain reaction codes |
JP2004135013A (en) | 2002-10-10 | 2004-04-30 | Matsushita Electric Ind Co Ltd | Device and method for transmission |
FI116816B (en) | 2002-10-14 | 2006-02-28 | Nokia Corp | Streaming media |
US8320301B2 (en) | 2002-10-25 | 2012-11-27 | Qualcomm Incorporated | MIMO WLAN system |
US7289451B2 (en) | 2002-10-25 | 2007-10-30 | Telefonaktiebolaget Lm Ericsson (Publ) | Delay trading between communication links |
AU2003269352A1 (en) | 2002-10-30 | 2004-05-25 | Koninklijke Philips Electronics N.V. | Adaptative forward error control scheme |
JP2004165922A (en) | 2002-11-12 | 2004-06-10 | Sony Corp | Apparatus, method, and program for information processing |
WO2004047455A1 (en) | 2002-11-18 | 2004-06-03 | British Telecommunications Public Limited Company | Transmission of video |
GB0226872D0 (en) | 2002-11-18 | 2002-12-24 | British Telecomm | Video transmission |
KR100502609B1 (en) | 2002-11-21 | 2005-07-20 | 한국전자통신연구원 | Encoder using low density parity check code and encoding method thereof |
US7086718B2 (en) | 2002-11-23 | 2006-08-08 | Silverbrook Research Pty Ltd | Thermal ink jet printhead with high nozzle areal density |
JP2004192140A (en) | 2002-12-09 | 2004-07-08 | Sony Corp | Data communication system, data transmitting device, data receiving device and method, and computer program |
JP2004193992A (en) | 2002-12-11 | 2004-07-08 | Sony Corp | Information processing system, information processor, information processing method, recording medium and program |
US8135073B2 (en) | 2002-12-19 | 2012-03-13 | Trident Microsystems (Far East) Ltd | Enhancing video images depending on prior image enhancements |
US7164882B2 (en) | 2002-12-24 | 2007-01-16 | Poltorak Alexander I | Apparatus and method for facilitating a purchase using information provided on a media playing device |
WO2004068715A2 (en) | 2003-01-29 | 2004-08-12 | Digital Fountain, Inc. | Systems and processes for fast encoding of hamming codes |
US7525994B2 (en) | 2003-01-30 | 2009-04-28 | Avaya Inc. | Packet data flow identification for multiplexing |
US7756002B2 (en) | 2003-01-30 | 2010-07-13 | Texas Instruments Incorporated | Time-frequency interleaved orthogonal frequency division multiplexing ultra wide band physical layer |
US7231404B2 (en) | 2003-01-31 | 2007-06-12 | Nokia Corporation | Datacast file transmission with meta-data retention |
US7062272B2 (en) | 2003-02-18 | 2006-06-13 | Qualcomm Incorporated | Method and apparatus to track count of broadcast content recipients in a wireless telephone network |
EP1455504B1 (en) | 2003-03-07 | 2014-11-12 | Samsung Electronics Co., Ltd. | Apparatus and method for processing audio signal and computer readable recording medium storing computer program for the method |
JP4173755B2 (en) | 2003-03-24 | 2008-10-29 | 富士通株式会社 | Data transmission server |
US7610487B2 (en) | 2003-03-27 | 2009-10-27 | Microsoft Corporation | Human input security codes |
US7266147B2 (en) | 2003-03-31 | 2007-09-04 | Sharp Laboratories Of America, Inc. | Hypothetical reference decoder |
US7408486B2 (en) | 2003-04-21 | 2008-08-05 | Qbit Corporation | System and method for using a microlet-based modem |
JP2004343701A (en) | 2003-04-21 | 2004-12-02 | Matsushita Electric Ind Co Ltd | Data receiving reproduction apparatus, data receiving reproduction method, and data receiving reproduction processing program |
US7113773B2 (en) | 2003-05-16 | 2006-09-26 | Qualcomm Incorporated | Reliable reception of broadcast/multicast content |
JP2004348824A (en) | 2003-05-21 | 2004-12-09 | Toshiba Corp | Ecc encoding method and ecc encoding device |
EP1632081B1 (en) | 2003-05-23 | 2016-08-17 | Kirusa, Inc. | A method and system for communicating a data file over a network and teleconferencing over a telephony network |
JP2004362099A (en) | 2003-06-03 | 2004-12-24 | Sony Corp | Server device, information processor, information processing method, and computer program |
JP2006514806A (en) | 2003-06-07 | 2006-05-11 | サムスン エレクトロニクス カンパニー リミテッド | Multimedia data providing apparatus, providing method thereof, and recording medium recording the method |
KR101003413B1 (en) | 2003-06-12 | 2010-12-23 | 엘지전자 주식회사 | Method for compression/decompression the transferring data of mobile phone |
US7603689B2 (en) | 2003-06-13 | 2009-10-13 | Microsoft Corporation | Fast start-up for digital video streams |
RU2265960C2 (en) | 2003-06-16 | 2005-12-10 | Федеральное государственное унитарное предприятие "Калужский научно-исследовательский институт телемеханических устройств" | Method for transferring information with use of adaptive alternation |
US7391717B2 (en) | 2003-06-30 | 2008-06-24 | Microsoft Corporation | Streaming of variable bit rate multimedia content |
US20050004997A1 (en) | 2003-07-01 | 2005-01-06 | Nokia Corporation | Progressive downloading of timed multimedia content |
US8149939B2 (en) | 2003-07-07 | 2012-04-03 | Samsung Electronics Co., Ltd. | System of robust DTV signal transmissions that legacy DTV receivers will disregard |
US7254754B2 (en) | 2003-07-14 | 2007-08-07 | International Business Machines Corporation | Raid 3+3 |
KR100532450B1 (en) | 2003-07-16 | 2005-11-30 | 삼성전자주식회사 | Data recording method with robustness for errors, data reproducing method therefore, and apparatuses therefore |
US20050028067A1 (en) | 2003-07-31 | 2005-02-03 | Weirauch Charles R. | Data with multiple sets of error correction codes |
US8694869B2 (en) | 2003-08-21 | 2014-04-08 | QUALCIMM Incorporated | Methods for forward error correction coding above a radio link control layer and related apparatus |
CN1871804B (en) | 2003-08-21 | 2010-09-01 | 高通股份有限公司 | Outer coding methods for broadcast/multicast content and related apparatus |
IL157885A0 (en) | 2003-09-11 | 2004-03-28 | Bamboo Mediacasting Ltd | Iterative forward error correction |
IL157886A0 (en) | 2003-09-11 | 2009-02-11 | Bamboo Mediacasting Ltd | Secure multicast transmission |
JP4183586B2 (en) | 2003-09-12 | 2008-11-19 | 三洋電機株式会社 | Video display device |
EP2426940A1 (en) | 2003-09-15 | 2012-03-07 | The DirecTV Group, Inc. | Method and system for adaptive transcoding and transrating in a video network |
KR100608715B1 (en) | 2003-09-27 | 2006-08-04 | 엘지전자 주식회사 | SYSTEM AND METHOD FOR QoS-QUARANTED MULTIMEDIA STREAMING SERVICE |
DE60307852D1 (en) | 2003-09-30 | 2006-10-05 | Ericsson Telefon Ab L M | In-place deinterlacing of data |
US7559004B1 (en) | 2003-10-01 | 2009-07-07 | Sandisk Corporation | Dynamic redundant area configuration in a non-volatile memory system |
CN101834610B (en) | 2003-10-06 | 2013-01-30 | 数字方敦股份有限公司 | Method and device for receiving data transmitted from source through communication channel |
US7516232B2 (en) | 2003-10-10 | 2009-04-07 | Microsoft Corporation | Media organization for distributed sending of media data |
US7614071B2 (en) | 2003-10-10 | 2009-11-03 | Microsoft Corporation | Architecture for distributed sending of media data |
EP1673690B1 (en) | 2003-10-14 | 2010-08-25 | Panasonic Corporation | Data converter |
US7650036B2 (en) | 2003-10-16 | 2010-01-19 | Sharp Laboratories Of America, Inc. | System and method for three-dimensional video coding |
US7168030B2 (en) | 2003-10-17 | 2007-01-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Turbo code decoder with parity information update |
US8132215B2 (en) | 2003-10-27 | 2012-03-06 | Panasonic Corporation | Apparatus for receiving broadcast signal |
JP2005136546A (en) | 2003-10-29 | 2005-05-26 | Sony Corp | Transmission apparatus and method, recording medium, and program |
DE602004011445T2 (en) | 2003-11-03 | 2009-01-15 | Broadcom Corp., Irvine | FEC decoding with dynamic parameters |
JP4787167B2 (en) | 2003-12-01 | 2011-10-05 | デジタル ファウンテン, インコーポレイテッド | Protecting data from erasures using subsymbol-based codes |
US7428669B2 (en) | 2003-12-07 | 2008-09-23 | Adaptive Spectrum And Signal Alignment, Inc. | Adaptive FEC codeword management |
US7574706B2 (en) | 2003-12-15 | 2009-08-11 | Microsoft Corporation | System and method for managing and communicating software updates |
US7590118B2 (en) | 2003-12-23 | 2009-09-15 | Agere Systems Inc. | Frame aggregation format |
JP4536383B2 (en) | 2004-01-16 | 2010-09-01 | 株式会社エヌ・ティ・ティ・ドコモ | Data receiving apparatus and data receiving method |
KR100770902B1 (en) | 2004-01-20 | 2007-10-26 | 삼성전자주식회사 | Apparatus and method for generating and decoding forward error correction codes of variable rate by using high rate data wireless communication |
JP4321284B2 (en) | 2004-02-03 | 2009-08-26 | 株式会社デンソー | Streaming data transmission apparatus and information distribution system |
US7599294B2 (en) | 2004-02-13 | 2009-10-06 | Nokia Corporation | Identification and re-transmission of missing parts |
US7609653B2 (en) | 2004-03-08 | 2009-10-27 | Microsoft Corporation | Resolving partial media topologies |
US20050207392A1 (en) | 2004-03-19 | 2005-09-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Higher layer packet framing using RLP |
US7240236B2 (en) | 2004-03-23 | 2007-07-03 | Archivas, Inc. | Fixed content distributed data storage using permutation ring encoding |
JP4433287B2 (en) | 2004-03-25 | 2010-03-17 | ソニー株式会社 | Receiving apparatus and method, and program |
US8842175B2 (en) | 2004-03-26 | 2014-09-23 | Broadcom Corporation | Anticipatory video signal reception and processing |
US20050216472A1 (en) | 2004-03-29 | 2005-09-29 | David Leon | Efficient multicast/broadcast distribution of formatted data |
WO2005096301A1 (en) | 2004-03-30 | 2005-10-13 | Koninklijke Philips Electronics N.V. | System and method for supporting improved trick mode performance for disc-based multimedia content |
TW200534875A (en) | 2004-04-23 | 2005-11-01 | Lonza Ag | Personal care compositions and concentrates for making the same |
FR2869744A1 (en) | 2004-04-29 | 2005-11-04 | Thomson Licensing Sa | METHOD FOR TRANSMITTING DIGITAL DATA PACKETS AND APPARATUS IMPLEMENTING THE METHOD |
KR101205758B1 (en) | 2004-05-07 | 2012-12-03 | 디지털 파운튼, 인크. | File download and streaming system |
US7633970B2 (en) | 2004-05-07 | 2009-12-15 | Agere Systems Inc. | MAC header compression for use with frame aggregation |
US20050254575A1 (en) | 2004-05-12 | 2005-11-17 | Nokia Corporation | Multiple interoperability points for scalable media coding and transmission |
US20060037057A1 (en) | 2004-05-24 | 2006-02-16 | Sharp Laboratories Of America, Inc. | Method and system of enabling trick play modes using HTTP GET |
US8331445B2 (en) | 2004-06-01 | 2012-12-11 | Qualcomm Incorporated | Method, apparatus, and system for enhancing robustness of predictive video codecs using a side-channel based on distributed source coding techniques |
US20070110074A1 (en) | 2004-06-04 | 2007-05-17 | Bob Bradley | System and Method for Synchronizing Media Presentation at Multiple Recipients |
US7139660B2 (en) | 2004-07-14 | 2006-11-21 | General Motors Corporation | System and method for changing motor vehicle personalization settings |
US8544043B2 (en) | 2004-07-21 | 2013-09-24 | Qualcomm Incorporated | Methods and apparatus for providing content information to content servers |
US7409626B1 (en) | 2004-07-28 | 2008-08-05 | Ikanos Communications Inc | Method and apparatus for determining codeword interleaver parameters |
US7590922B2 (en) | 2004-07-30 | 2009-09-15 | Nokia Corporation | Point-to-point repair request mechanism for point-to-multipoint transmission systems |
US7376150B2 (en) | 2004-07-30 | 2008-05-20 | Nokia Corporation | Point-to-point repair response mechanism for point-to-multipoint transmission systems |
US7930184B2 (en) | 2004-08-04 | 2011-04-19 | Dts, Inc. | Multi-channel audio coding/decoding of random access points and transients |
WO2006020826A2 (en) | 2004-08-11 | 2006-02-23 | Digital Fountain, Inc. | Method and apparatus for fast encoding of data symbols according to half-weight codes |
JP4405875B2 (en) | 2004-08-25 | 2010-01-27 | 富士通株式会社 | Method and apparatus for generating data for error correction, generation program, and computer-readable recording medium storing the program |
JP2006074335A (en) | 2004-09-01 | 2006-03-16 | Nippon Telegr & Teleph Corp <Ntt> | Transmission method, transmission system, and transmitter |
JP4576936B2 (en) | 2004-09-02 | 2010-11-10 | ソニー株式会社 | Information processing apparatus, information recording medium, content management system, data processing method, and computer program |
JP2006115104A (en) | 2004-10-13 | 2006-04-27 | Daiichikosho Co Ltd | Method and device for packetizing time-series information encoded with high efficiency, and performing real-time streaming transmission, and for reception and reproduction |
US7529984B2 (en) | 2004-11-16 | 2009-05-05 | Infineon Technologies Ag | Seamless change of depth of a general convolutional interleaver during transmission without loss of data |
US7751324B2 (en) | 2004-11-19 | 2010-07-06 | Nokia Corporation | Packet stream arrangement in multimedia transmission |
EP1815684B1 (en) | 2004-11-22 | 2014-12-31 | Thomson Research Funding Corporation | Method and apparatus for channel change in dsl system |
JP5425397B2 (en) | 2004-12-02 | 2014-02-26 | トムソン ライセンシング | Apparatus and method for adaptive forward error correction |
KR20060065482A (en) | 2004-12-10 | 2006-06-14 | 마이크로소프트 코포레이션 | A system and process for controlling the coding bit rate of streaming media data |
JP2006174032A (en) | 2004-12-15 | 2006-06-29 | Sanyo Electric Co Ltd | Image data transmission system, image data receiver and image data transmitter |
JP2006174045A (en) | 2004-12-15 | 2006-06-29 | Ntt Communications Kk | Image distribution device, program, and method therefor |
US7398454B2 (en) | 2004-12-21 | 2008-07-08 | Tyco Telecommunications (Us) Inc. | System and method for forward error correction decoding using soft information |
JP4391409B2 (en) | 2004-12-24 | 2009-12-24 | 株式会社第一興商 | High-efficiency-encoded time-series information transmission method and apparatus for real-time streaming transmission and reception |
CN101116306A (en) | 2005-02-08 | 2008-01-30 | 艾利森电话股份有限公司 | On-demand multi-channel streaming session over packet-switched networks |
US7822139B2 (en) | 2005-03-02 | 2010-10-26 | Rohde & Schwarz Gmbh & Co. Kg | Apparatus, systems, methods and computer products for providing a virtual enhanced training sequence |
US20090222873A1 (en) | 2005-03-07 | 2009-09-03 | Einarsson Torbjoern | Multimedia Channel Switching |
US8028322B2 (en) | 2005-03-14 | 2011-09-27 | Time Warner Cable Inc. | Method and apparatus for network content download and recording |
US7219289B2 (en) | 2005-03-15 | 2007-05-15 | Tandberg Data Corporation | Multiply redundant raid system and XOR-efficient method and apparatus for implementing the same |
US7418649B2 (en) | 2005-03-15 | 2008-08-26 | Microsoft Corporation | Efficient implementation of reed-solomon erasure resilient codes in high-rate applications |
US7450064B2 (en) | 2005-03-22 | 2008-11-11 | Qualcomm, Incorporated | Methods and systems for deriving seed position of a subscriber station in support of unassisted GPS-type position determination in a wireless communication system |
JP4487028B2 (en) | 2005-03-31 | 2010-06-23 | ブラザー工業株式会社 | Delivery speed control device, delivery system, delivery speed control method, and delivery speed control program |
US7715842B2 (en) | 2005-04-09 | 2010-05-11 | Lg Electronics Inc. | Supporting handover of mobile terminal |
EP1869891A4 (en) | 2005-04-13 | 2014-06-11 | Coding, storage and signalling of scalability information | |
JP4515319B2 (en) | 2005-04-27 | 2010-07-28 | 株式会社日立製作所 | Computer system |
US7961700B2 (en) | 2005-04-28 | 2011-06-14 | Qualcomm Incorporated | Multi-carrier operation in data transmission systems |
US8683066B2 (en) | 2007-08-06 | 2014-03-25 | DISH Digital L.L.C. | Apparatus, system, and method for multi-bitrate content streaming |
JP2006319743A (en) | 2005-05-13 | 2006-11-24 | Toshiba Corp | Receiving device |
KR20100037659A (en) | 2005-05-24 | 2010-04-09 | 노키아 코포레이션 | Method and apparatus for hierarchical transmission/reception in digital broadcast |
US7676735B2 (en) | 2005-06-10 | 2010-03-09 | Digital Fountain Inc. | Forward error-correcting (FEC) coding and streaming |
US7644335B2 (en) | 2005-06-10 | 2010-01-05 | Qualcomm Incorporated | In-place transformations with applications to encoding and decoding various classes of codes |
JP2007013436A (en) | 2005-06-29 | 2007-01-18 | Toshiba Corp | Coding stream reproducing apparatus |
US20070006274A1 (en) | 2005-06-30 | 2007-01-04 | Toni Paila | Transmission and reception of session packets |
JP2007013675A (en) | 2005-06-30 | 2007-01-18 | Sanyo Electric Co Ltd | Streaming distribution system and server |
US7725593B2 (en) | 2005-07-15 | 2010-05-25 | Sony Corporation | Scalable video coding (SVC) file format |
US20070022215A1 (en) | 2005-07-19 | 2007-01-25 | Singer David W | Method and apparatus for media data transmission |
ATE514246T1 (en) | 2005-08-19 | 2011-07-15 | Hewlett Packard Development Co | SUGGESTION OF LOST SEGMENTS ACROSS LAYER BOUNDARIES |
US7924913B2 (en) | 2005-09-15 | 2011-04-12 | Microsoft Corporation | Non-realtime data transcoding of multimedia content |
US20070067480A1 (en) | 2005-09-19 | 2007-03-22 | Sharp Laboratories Of America, Inc. | Adaptive media playout by server media processing for robust streaming |
US20070078876A1 (en) | 2005-09-30 | 2007-04-05 | Yahoo! Inc. | Generating a stream of media data containing portions of media files using location tags |
US7720062B2 (en) | 2005-10-05 | 2010-05-18 | Lg Electronics Inc. | Method of processing traffic information and digital broadcasting system |
US7164370B1 (en) | 2005-10-06 | 2007-01-16 | Analog Devices, Inc. | System and method for decoding data compressed in accordance with dictionary-based compression schemes |
CN100442858C (en) | 2005-10-11 | 2008-12-10 | 华为技术有限公司 | Lip synchronous method for multimedia real-time transmission in packet network and apparatus thereof |
US7720096B2 (en) | 2005-10-13 | 2010-05-18 | Microsoft Corporation | RTP payload format for VC-1 |
JP4727401B2 (en) | 2005-12-02 | 2011-07-20 | 日本電信電話株式会社 | Wireless multicast transmission system, wireless transmission device, and wireless multicast transmission method |
JP4456064B2 (en) | 2005-12-21 | 2010-04-28 | 日本電信電話株式会社 | Packet transmission device, reception device, system, and program |
DK1969857T3 (en) | 2006-01-05 | 2012-07-16 | Ericsson Telefon Ab L M | MANAGING FILES CONTAINING MEDIA DATA |
US8214516B2 (en) | 2006-01-06 | 2012-07-03 | Google Inc. | Dynamic media serving infrastructure |
US8767818B2 (en) | 2006-01-11 | 2014-07-01 | Nokia Corporation | Backward-compatible aggregation of pictures in scalable video coding |
KR100934677B1 (en) | 2006-01-12 | 2009-12-31 | 엘지전자 주식회사 | Processing multiview video |
WO2007086654A1 (en) | 2006-01-25 | 2007-08-02 | Lg Electronics Inc. | Digital broadcasting system and method of processing data |
US7262719B2 (en) | 2006-01-30 | 2007-08-28 | International Business Machines Corporation | Fast data stream decoding using apriori information |
RU2290768C1 (en) | 2006-01-30 | 2006-12-27 | Общество с ограниченной ответственностью "Трафиклэнд" | Media broadcast system in infrastructure of mobile communications operator |
GB0602314D0 (en) | 2006-02-06 | 2006-03-15 | Ericsson Telefon Ab L M | Transporting packets |
US8990153B2 (en) | 2006-02-07 | 2015-03-24 | Dot Hill Systems Corporation | Pull data replication model |
JP5237119B2 (en) | 2006-02-08 | 2013-07-17 | トムソン ライセンシング | Method and apparatus for decoding raptor code |
CN101686107B (en) | 2006-02-13 | 2014-08-13 | 数字方敦股份有限公司 | Streaming and buffering using variable FEC overhead and protection periods |
US20070200949A1 (en) | 2006-02-21 | 2007-08-30 | Qualcomm Incorporated | Rapid tuning in multimedia applications |
US9270414B2 (en) | 2006-02-21 | 2016-02-23 | Digital Fountain, Inc. | Multiple-field based code generator and decoder for communications systems |
JP2007228205A (en) | 2006-02-23 | 2007-09-06 | Funai Electric Co Ltd | Network server |
US8320450B2 (en) | 2006-03-29 | 2012-11-27 | Vidyo, Inc. | System and method for transcoding between scalable and non-scalable video codecs |
US20090100496A1 (en) | 2006-04-24 | 2009-04-16 | Andreas Bechtolsheim | Media server system |
US20080010153A1 (en) | 2006-04-24 | 2008-01-10 | Pugh-O'connor Archie | Computer network provided digital content under an advertising and revenue sharing basis, such as music provided via the internet with time-shifted advertisements presented by a client resident application |
US7640353B2 (en) | 2006-04-27 | 2009-12-29 | Microsoft Corporation | Guided random seek support for media streaming |
WO2007134196A2 (en) | 2006-05-10 | 2007-11-22 | Digital Fountain, Inc. | Code generator and decoder using hybrid codes |
US7525993B2 (en) | 2006-05-24 | 2009-04-28 | Newport Media, Inc. | Robust transmission system and method for mobile television applications |
US9209934B2 (en) | 2006-06-09 | 2015-12-08 | Qualcomm Incorporated | Enhanced block-request streaming using cooperative parallel HTTP and forward error correction |
US9178535B2 (en) | 2006-06-09 | 2015-11-03 | Digital Fountain, Inc. | Dynamic stream interleaving and sub-stream based delivery |
US9386064B2 (en) | 2006-06-09 | 2016-07-05 | Qualcomm Incorporated | Enhanced block-request streaming using URL templates and construction rules |
US9380096B2 (en) | 2006-06-09 | 2016-06-28 | Qualcomm Incorporated | Enhanced block-request streaming system for handling low-latency streaming |
US9432433B2 (en) | 2006-06-09 | 2016-08-30 | Qualcomm Incorporated | Enhanced block-request streaming system using signaling or block creation |
US20100211690A1 (en) | 2009-02-13 | 2010-08-19 | Digital Fountain, Inc. | Block partitioning for a data stream |
TWM302355U (en) | 2006-06-09 | 2006-12-11 | Jia-Bau Jeng | Fixation and cushion structure of knee joint |
JP2008011404A (en) | 2006-06-30 | 2008-01-17 | Toshiba Corp | Content processing apparatus and method |
JP4392004B2 (en) | 2006-07-03 | 2009-12-24 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Encoding and decoding techniques for packet recovery |
JP4982563B2 (en) | 2006-07-20 | 2012-07-25 | サンディスク コーポレイション | Improved AV player apparatus and content distribution system and method using the same |
US7711797B1 (en) | 2006-07-31 | 2010-05-04 | Juniper Networks, Inc. | Optimizing batch size for prefetching data over wide area networks |
US8209736B2 (en) | 2006-08-23 | 2012-06-26 | Mediatek Inc. | Systems and methods for managing television (TV) signals |
CA2661578C (en) | 2006-08-24 | 2014-06-17 | Nokia Corporation | System and method for indicating track relationships in media files |
US20080066136A1 (en) | 2006-08-24 | 2008-03-13 | International Business Machines Corporation | System and method for detecting topic shift boundaries in multimedia streams using joint audio, visual and text cues |
JP2008109637A (en) | 2006-09-25 | 2008-05-08 | Toshiba Corp | Motion picture encoding apparatus and method |
EP2084928B1 (en) | 2006-10-30 | 2017-08-23 | LG Electronics Inc. | Method of performing random access in a wireless communication system |
JP2008118221A (en) | 2006-10-31 | 2008-05-22 | Toshiba Corp | Decoder and decoding method |
WO2008054100A1 (en) | 2006-11-01 | 2008-05-08 | Electronics And Telecommunications Research Institute | Method and apparatus for decoding metadata used for playing stereoscopic contents |
US8345743B2 (en) | 2006-11-14 | 2013-01-01 | Qualcomm Incorporated | Systems and methods for channel switching |
US8027328B2 (en) | 2006-12-26 | 2011-09-27 | Alcatel Lucent | Header compression in a wireless communication network |
EP4184341A1 (en) | 2007-01-05 | 2023-05-24 | DivX, LLC | Video distribution system including progressive playback |
CN101669323A (en) | 2007-01-09 | 2010-03-10 | 诺基亚公司 | Method for supporting file versioning in mbms file repair |
US20080172430A1 (en) | 2007-01-11 | 2008-07-17 | Andrew Thomas Thorstensen | Fragmentation Compression Management |
WO2008084876A1 (en) | 2007-01-11 | 2008-07-17 | Panasonic Corporation | Method for trick playing on streamed and encrypted multimedia |
EP1994721A4 (en) | 2007-01-12 | 2013-09-25 | Univ Kyung Hee Univ Ind Coop Group | Packet format of network abstraction layer unit, and algorithm and apparatus for video encoding and decoding using the format, qos control algorithm and apparatus for ipv6 label switching using the format |
KR20080066408A (en) | 2007-01-12 | 2008-07-16 | 삼성전자주식회사 | Device and method for generating three-dimension image and displaying thereof |
US8135071B2 (en) | 2007-01-16 | 2012-03-13 | Cisco Technology, Inc. | Breakpoint determining for hybrid variable length coding using relationship to neighboring blocks |
US7721003B2 (en) | 2007-02-02 | 2010-05-18 | International Business Machines Corporation | System and method to synchronize OSGi bundle inventories between an OSGi bundle server and a client |
US7805456B2 (en) | 2007-02-05 | 2010-09-28 | Microsoft Corporation | Query pattern to enable type flow of element types |
US20080192818A1 (en) | 2007-02-09 | 2008-08-14 | Dipietro Donald Vincent | Systems and methods for securing media |
US20080232357A1 (en) | 2007-03-19 | 2008-09-25 | Legend Silicon Corp. | Ls digital fountain code |
JP4838191B2 (en) | 2007-05-08 | 2011-12-14 | シャープ株式会社 | File reproduction device, file reproduction method, program for executing file reproduction, and recording medium recording the program |
JP2008283571A (en) | 2007-05-11 | 2008-11-20 | Ntt Docomo Inc | Content distribution device, system and method |
US8275002B2 (en) | 2007-05-14 | 2012-09-25 | Samsung Electronics Co., Ltd. | Broadcasting service transmitting apparatus and method and broadcasting service receiving apparatus and method for effectively accessing broadcasting service |
BRPI0811117A2 (en) | 2007-05-16 | 2014-12-23 | Thomson Licensing | APPARATUS AND METHOD FOR ENCODING AND DECODING SIGNS |
WO2008153294A2 (en) | 2007-06-11 | 2008-12-18 | Samsung Electronics Co., Ltd. | Method and apparatus for generating header information of stereoscopic image |
WO2009001313A2 (en) | 2007-06-26 | 2008-12-31 | Nokia Corporation | System and method for indicating temporal layer switching points |
US7917702B2 (en) | 2007-07-10 | 2011-03-29 | Qualcomm Incorporated | Data prefetch throttle |
JP2009027598A (en) | 2007-07-23 | 2009-02-05 | Hitachi Ltd | Video distribution server and video distribution method |
US8327403B1 (en) | 2007-09-07 | 2012-12-04 | United Video Properties, Inc. | Systems and methods for providing remote program ordering on a user device via a web server |
JP5027305B2 (en) | 2007-09-12 | 2012-09-19 | デジタル ファウンテン, インコーポレイテッド | Generation and transmission of source identification information to enable reliable communication |
US8233532B2 (en) | 2007-09-21 | 2012-07-31 | Fraunhofer-Gesellschaft Zur Foerderung Der Angewandten Forschung E.V. | Information signal, apparatus and method for encoding an information content, and apparatus and method for error correcting an information signal |
US8346959B2 (en) | 2007-09-28 | 2013-01-01 | Sharp Laboratories Of America, Inc. | Client-controlled adaptive streaming |
KR101446359B1 (en) | 2007-10-09 | 2014-10-01 | 삼성전자주식회사 | Apparatus and method for generating and parsing a mac pdu in a mobile communication system |
US8635360B2 (en) | 2007-10-19 | 2014-01-21 | Google Inc. | Media playback point seeking using data range requests |
US8706907B2 (en) | 2007-10-19 | 2014-04-22 | Voxer Ip Llc | Telecommunication and multimedia management method and apparatus |
US20090125636A1 (en) | 2007-11-13 | 2009-05-14 | Qiong Li | Payload allocation methods for scalable multimedia servers |
EP2215595B1 (en) | 2007-11-23 | 2012-02-22 | Media Patents S.L. | A process for the on-line distribution of audiovisual contents with advertisements, advertisement management system, digital rights management system and audiovisual content player provided with said systems |
US8543720B2 (en) | 2007-12-05 | 2013-09-24 | Google Inc. | Dynamic bit rate scaling |
TWI355168B (en) | 2007-12-07 | 2011-12-21 | Univ Nat Chiao Tung | Application classification method in network traff |
JP5385598B2 (en) | 2007-12-17 | 2014-01-08 | キヤノン株式会社 | Image processing apparatus, image management server apparatus, control method thereof, and program |
US9313245B2 (en) | 2007-12-24 | 2016-04-12 | Qualcomm Incorporated | Adaptive streaming for on demand wireless services |
EP2086237B1 (en) | 2008-02-04 | 2012-06-27 | Alcatel Lucent | Method and device for reordering and multiplexing multimedia packets from multimedia streams pertaining to interrelated sessions |
US8151174B2 (en) | 2008-02-13 | 2012-04-03 | Sunrise IP, LLC | Block modulus coding (BMC) systems and methods for block coding with non-binary modulus |
US7984097B2 (en) | 2008-03-18 | 2011-07-19 | Media Patents, S.L. | Methods for transmitting multimedia files and advertisements |
US8606996B2 (en) | 2008-03-31 | 2013-12-10 | Amazon Technologies, Inc. | Cache optimization |
US20090257508A1 (en) | 2008-04-10 | 2009-10-15 | Gaurav Aggarwal | Method and system for enabling video trick modes |
CN103795511B (en) | 2008-04-14 | 2018-05-01 | 亚马逊技术股份有限公司 | A kind of method that uplink transmission is received in base station and base station |
US20100049865A1 (en) | 2008-04-16 | 2010-02-25 | Nokia Corporation | Decoding Order Recovery in Session Multiplexing |
US8855199B2 (en) | 2008-04-21 | 2014-10-07 | Nokia Corporation | Method and device for video coding and decoding |
EP2286585A4 (en) | 2008-05-07 | 2015-06-17 | Digital Fountain Inc | Fast channel zapping and high quality streaming protection over a broadcast channel |
WO2009140208A2 (en) | 2008-05-12 | 2009-11-19 | Swarmcast, Inc. | Live media delivery over a packet-based computer network |
JP5022301B2 (en) | 2008-05-19 | 2012-09-12 | 株式会社エヌ・ティ・ティ・ドコモ | Proxy server, communication relay program, and communication relay method |
CN101287107B (en) | 2008-05-29 | 2010-10-13 | 腾讯科技(深圳)有限公司 | Demand method, system and device of media file |
US7949775B2 (en) | 2008-05-30 | 2011-05-24 | Microsoft Corporation | Stream selection for enhanced media streaming |
US20100011274A1 (en) | 2008-06-12 | 2010-01-14 | Qualcomm Incorporated | Hypothetical fec decoder and signalling for decoding control |
US8775566B2 (en) | 2008-06-21 | 2014-07-08 | Microsoft Corporation | File format for media distribution and presentation |
US8387150B2 (en) | 2008-06-27 | 2013-02-26 | Microsoft Corporation | Segmented media content rights management |
US8468426B2 (en) | 2008-07-02 | 2013-06-18 | Apple Inc. | Multimedia-aware quality-of-service and error correction provisioning |
US8539092B2 (en) | 2008-07-09 | 2013-09-17 | Apple Inc. | Video streaming using multiple channels |
US20100153578A1 (en) | 2008-07-16 | 2010-06-17 | Nokia Corporation | Method and Apparatus for Peer to Peer Streaming |
US8638796B2 (en) | 2008-08-22 | 2014-01-28 | Cisco Technology, Inc. | Re-ordering segments of a large number of segmented service flows |
US8325796B2 (en) | 2008-09-11 | 2012-12-04 | Google Inc. | System and method for video coding using adaptive segmentation |
US8370520B2 (en) | 2008-11-24 | 2013-02-05 | Juniper Networks, Inc. | Adaptive network content delivery system |
US20100169458A1 (en) | 2008-12-31 | 2010-07-01 | David Biderman | Real-Time or Near Real-Time Streaming |
US8743906B2 (en) | 2009-01-23 | 2014-06-03 | Akamai Technologies, Inc. | Scalable seamless digital video stream splicing |
US9036714B2 (en) | 2009-01-26 | 2015-05-19 | Thomson Licensing | Frame packing for video coding |
US9281847B2 (en) | 2009-02-27 | 2016-03-08 | Qualcomm Incorporated | Mobile reception of digital video broadcasting—terrestrial services |
US8909806B2 (en) | 2009-03-16 | 2014-12-09 | Microsoft Corporation | Delivering cacheable streaming media presentations |
US8621044B2 (en) | 2009-03-16 | 2013-12-31 | Microsoft Corporation | Smooth, stateless client media streaming |
US9807468B2 (en) | 2009-06-16 | 2017-10-31 | Microsoft Technology Licensing, Llc | Byte range caching |
US8903895B2 (en) | 2009-07-22 | 2014-12-02 | Xinlab, Inc. | Method of streaming media to heterogeneous client devices |
US8355433B2 (en) | 2009-08-18 | 2013-01-15 | Netflix, Inc. | Encoding video streams for adaptive video streaming |
US20120151302A1 (en) | 2010-12-10 | 2012-06-14 | Qualcomm Incorporated | Broadcast multimedia storage and access using page maps when asymmetric memory is used |
US9288010B2 (en) | 2009-08-19 | 2016-03-15 | Qualcomm Incorporated | Universal file delivery methods for providing unequal error protection and bundled file delivery services |
CA2772100C (en) | 2009-09-02 | 2016-06-28 | Hang Zhang | Mac packet data unit construction for wireless systems |
US9917874B2 (en) | 2009-09-22 | 2018-03-13 | Qualcomm Incorporated | Enhanced block-request streaming using block partitioning or request controls for improved client-side handling |
US20110096828A1 (en) | 2009-09-22 | 2011-04-28 | Qualcomm Incorporated | Enhanced block-request streaming using scalable encoding |
US9438861B2 (en) | 2009-10-06 | 2016-09-06 | Microsoft Technology Licensing, Llc | Integrating continuous and sparse streaming data |
JP2011087103A (en) | 2009-10-15 | 2011-04-28 | Sony Corp | Provision of content reproduction system, content reproduction device, program, content reproduction method, and content server |
EP2491495A4 (en) | 2009-11-04 | 2013-01-02 | Huawei Tech Co Ltd | System and method for media content streaming |
KR101786051B1 (en) | 2009-11-13 | 2017-10-16 | 삼성전자 주식회사 | Method and apparatus for data providing and receiving |
KR101786050B1 (en) | 2009-11-13 | 2017-10-16 | 삼성전자 주식회사 | Method and apparatus for transmitting and receiving of data |
CN101729857A (en) | 2009-11-24 | 2010-06-09 | 中兴通讯股份有限公司 | Method for accessing video service and video playing system |
EP2510669A4 (en) | 2009-12-11 | 2013-09-18 | Nokia Corp | Apparatus and methods for describing and timing representations in streaming media files |
KR101709903B1 (en) | 2010-02-19 | 2017-02-23 | 텔레폰악티에볼라겟엘엠에릭슨(펍) | Method and arrangement for adaptation in http streamimg |
JP5996439B2 (en) | 2010-02-19 | 2016-09-21 | テレフオンアクチーボラゲット エルエム エリクソン(パブル) | Method and apparatus for representation switching in HTTP streaming |
JP5071495B2 (en) | 2010-03-04 | 2012-11-14 | ウシオ電機株式会社 | Light source device |
ES2845643T3 (en) | 2010-03-11 | 2021-07-27 | Electronics & Telecommunications Res Inst | Method and apparatus for transmitting and receiving data in a MIMO system |
US9225961B2 (en) | 2010-05-13 | 2015-12-29 | Qualcomm Incorporated | Frame packing for asymmetric stereo video |
US8918533B2 (en) | 2010-07-13 | 2014-12-23 | Qualcomm Incorporated | Video switching for streaming video data |
US9185439B2 (en) | 2010-07-15 | 2015-11-10 | Qualcomm Incorporated | Signaling data for multiplexing video components |
KR20120010089A (en) | 2010-07-20 | 2012-02-02 | 삼성전자주식회사 | Method and apparatus for improving quality of multimedia streaming service based on hypertext transfer protocol |
US9131033B2 (en) | 2010-07-20 | 2015-09-08 | Qualcomm Incoporated | Providing sequence data sets for streaming video data |
US9596447B2 (en) | 2010-07-21 | 2017-03-14 | Qualcomm Incorporated | Providing frame packing type information for video coding |
US8711933B2 (en) | 2010-08-09 | 2014-04-29 | Sony Computer Entertainment Inc. | Random access point (RAP) formation using intra refreshing technique in video coding |
US8806050B2 (en) | 2010-08-10 | 2014-08-12 | Qualcomm Incorporated | Manifest file updates for network streaming of coded multimedia data |
KR101737325B1 (en) | 2010-08-19 | 2017-05-22 | 삼성전자주식회사 | Method and apparatus for reducing decreasing of qualitly of experience in a multimedia system |
US10511887B2 (en) * | 2010-08-30 | 2019-12-17 | Saturn Licensing Llc | Reception apparatus, reception method, transmission apparatus, transmission method, program, and broadcasting system |
US8615023B2 (en) | 2010-10-27 | 2013-12-24 | Electronics And Telecommunications Research Institute | Apparatus and method for transmitting/receiving data in communication system |
US9270299B2 (en) | 2011-02-11 | 2016-02-23 | Qualcomm Incorporated | Encoding and decoding using elastic codes with flexible source block mapping |
US8958375B2 (en) | 2011-02-11 | 2015-02-17 | Qualcomm Incorporated | Framing for an improved radio link protocol including FEC |
US20120208580A1 (en) | 2011-02-11 | 2012-08-16 | Qualcomm Incorporated | Forward error correction scheduling for an improved radio link protocol |
US9253233B2 (en) | 2011-08-31 | 2016-02-02 | Qualcomm Incorporated | Switch signaling methods providing improved switching between representations for adaptive HTTP streaming |
US9843844B2 (en) | 2011-10-05 | 2017-12-12 | Qualcomm Incorporated | Network streaming of media data |
EP2888892B1 (en) * | 2012-10-24 | 2019-06-12 | Huawei Technologies Co., Ltd. | Communication receiver |
-
2013
- 2013-01-29 US US13/753,442 patent/US9294226B2/en not_active Expired - Fee Related
- 2013-03-26 CN CN201380017023.7A patent/CN104221315B/en not_active Expired - Fee Related
- 2013-03-26 WO PCT/US2013/033852 patent/WO2013148662A1/en active Application Filing
- 2013-03-26 EP EP13715555.2A patent/EP2832022A1/en not_active Withdrawn
-
2016
- 2016-03-21 US US15/076,235 patent/US20170026148A1/en not_active Abandoned
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5751723A (en) * | 1996-07-01 | 1998-05-12 | Motorola, Inc. | Method and system for overhead bandwidth recovery in a packetized network |
US20050203927A1 (en) * | 2000-07-24 | 2005-09-15 | Vivcom, Inc. | Fast metadata generation and delivery |
US20020085592A1 (en) * | 2000-12-28 | 2002-07-04 | Pioneer Corporation | Transport stream multiplexing method, transport stream multiplexing apparatus, and storage and reproduction system |
US20060015568A1 (en) * | 2004-07-14 | 2006-01-19 | Rod Walsh | Grouping of session objects |
US20060130118A1 (en) * | 2004-12-10 | 2006-06-15 | Alcatel | Distributive system for marking and blocking video and audio content related to video and audio programs |
US20100067553A1 (en) * | 2008-09-12 | 2010-03-18 | Viasys Healthcare, Inc | Synchronization of video with telemetry signals method and apparatus |
US20110299629A1 (en) * | 2009-08-19 | 2011-12-08 | Qualcomm Incorporated | Methods and apparatus employing fec codes with permanent inactivation of symbols for encoding and decoding processes |
US20110307581A1 (en) * | 2010-06-14 | 2011-12-15 | Research In Motion Limited | Media Presentation Description Delta File For HTTP Streaming |
Non-Patent Citations (1)
Title |
---|
IEEE 100, The authoritative dictionary of IEEE standards terms, 2000, seventh edition, IEEE standards information network, IEEE press. (Year: 2000) * |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10305953B2 (en) | 2013-09-27 | 2019-05-28 | Saturn Licensing Llc | Content supplying apparatus, content supplying method, program, terminal device, and content supplying system |
US10623463B2 (en) | 2013-09-27 | 2020-04-14 | Saturn Licensing Llc | Content supplying apparatus, content supplying method, program, terminal device, and content supplying system |
Also Published As
Publication number | Publication date |
---|---|
US9294226B2 (en) | 2016-03-22 |
CN104221315A (en) | 2014-12-17 |
CN104221315B (en) | 2017-09-05 |
EP2832022A1 (en) | 2015-02-04 |
US20130254634A1 (en) | 2013-09-26 |
WO2013148662A1 (en) | 2013-10-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9294226B2 (en) | Universal object delivery and template-based file delivery | |
US9350488B2 (en) | Content delivery system with allocation of source data and repair data among HTTP servers | |
KR102127733B1 (en) | Method and apparatus for transmitting media content in multimedia system | |
JP6445527B2 (en) | Method for distribution of a flow of objects through a broadcast / multicast capable network | |
EP2630766B1 (en) | Universal file delivery methods for providing unequal error protection and bundled file delivery services | |
EP1969856B1 (en) | Media container file management | |
EP2894831B1 (en) | Transport mechanisms for dynamic rich media scenes | |
JP5795446B2 (en) | Content delivery system with allocation of source data and repair data between HTTP servers | |
EP3257216B1 (en) | Method of handling packet losses in transmissions based on dash standard and flute protocol | |
WO2021195398A1 (en) | Determination of availability of chunks of data for network streaming media data |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: QUALCOMM INCORPORATED, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LUBY, MICHAEL GEORGE;FALL, KEVIN ROLAND;STOCKHAMMER, THOMAS;SIGNING DATES FROM 20130211 TO 20130304;REEL/FRAME:038054/0683 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |