Patent Application
20140025839
The present invention relates to transmission of digital content to users, and in particular to systems and methods for increasing the efficiency of transmission bandwidth.
A number of systems exist for delivering digital content to users' receivers and other content playback devices such as satellite digital audio radio service (SDARS), other digital audio broadcast (DAB) systems or high definition (HD) radio systems, streaming content delivery systems, digital cable television systems, Direct-to-home satellite video transmission systems, and wireless data networks (3G, 4G etc.), among others.
The type of content which can be distributed in a SDARS system or other digital content delivery system can include, for example, audio programs such as music recordings, news programs and talk shows, among other programs and advertisements, but can also include video files of various lengths and types ranging from advertisements of a few seconds in duration, to short clips of the sort popular on various internet humor sites, to television programs or “webisodes”, to feature length movies. Further, the distributed content can be data files.
A significant amount of the content that is to be broadcast or otherwise delivered can be predetermined prior to transmission such as popular songs or other popular content files such as, for example, videos. Radio stations, for example, frequently use play lists to determine how often a selected number of songs, which are identified as being most popular at a given point in time, are to be broadcast. A digital broadcast, however, can also include dialogue content files from a broadcast channel host or other program host which occur between the audio programs and any advertisements presented on a broadcast channel, as well as news programs or live programming events. Popular songs and other programs which can be repeated on one or more broadcast channels, and are generally not time or date sensitive, are distinguishable from live commentary provided by a broadcast channel host, talk show host or other commentator, for example, or live programming event, or advertisements and other content that is time or date sensitive.
Since bandwidth in a digital broadcast system and other content delivery systems is typically limited and valuable, efficient use of the transmission bandwidth is desirable. This is especially the case as regards music and/or personalized music delivery systems or services which provide users' cellular phones, smartphones and other devices with a custom stream of content over wireless networks of ever changing bandwidth and conditions. A need therefore exists for a digital content delivery system wherein content is provided in a transmitted signal in an optimal manner to use transmission bandwidth as efficiently as possible.
The above and other problems are overcome, and additional advantages are realized, by illustrative embodiments of the present invention.
In accordance with an illustrative embodiment of the present invention, a method and system are provided for improving efficiency of content transmission whereby digitally encoded content files to be transmitted are split or divided into plural parts. For example, an original content file to be broadcast or streamed to receivers in a content stream can, for example, be divided into two derived files. A first derived file can generally include a majority of the information contained in the original content file, but, as generated, the first derived file can be denatured in some way, or intentionally corrupted, and is therefore incomplete for purposes of playback. Such denaturing involves processing such that, if the denatured file were to be played, the result would be unrecognizable as the original content file, and where the sequence of bits are no longer the same or interpreted in the same way. The second derived file, can contain, for example, data missing from the first file, as well as instructions to the receiver to facilitate, inter alia, combining the two (or more) derived files. The second file can be transmitted (e.g., either broadcast or streamed via a wired or wireless internet connection, wireless network, or a dedicated fiber optic or cable connection) to the receivers. Upon receipt of the transmitted second derived file at the receiver, the first and second derived files can be combined or otherwise processed to recover (or substantially recover) the information contained in the original content file in a manner sufficient for real-time or near real-time playback, or for local storage on the receiver.
In accordance with other aspects of illustrative embodiments of the present invention, an original content file to be transmitted can be divided into at least two files. As an example, one of the files can be stored locally in or at a receiver and can be denatured so as to be unable to be played or used, and the second file can be transmitted (e.g., broadcast over the air in real-time). The first file can, for example, be loaded into the receiver when it is manufactured, or, for example, subsequently transmitted to the receiver (e.g., wirelessly transmitted or streamed via the Internet), and can, for example, be periodically updated (e.g., over the air). When the second file is delivered (e.g., broadcast to receivers), a receiver can combine the received second file with the corresponding locally stored first file to reconstruct the content (e.g., in real-time with the received broadcast) of the original file. The reconstructed content can then be consumed, for example, during playback or other content rendering application, in similar manner to content that is normally broadcast or streamed. In the absence of any ephemeral replay or storage buffers, and after any playback or content rendering has finished, only the first file will remain in the receiver. Thus, by asymmetrically splitting the content such that a larger portion of the content is provided to the receiver and a smaller portion of the content is transmitted, a significant increase in transmission bandwidth efficiency can be achieved. In the case of a SDARS or similar content provider, the second file can be part of a program content stream comprising other content. The second file can, for example, constitute about 10 percent of the file content, while the remaining 90 percent of the file content can be reconstructed using the first file which has been stored at the receivers, to significantly increase the efficiency of the transmission mode. Additionally, in exemplary embodiments of the present invention, a small amount of information can be added to the transmitted (second) file so that the receiver can reliably locate the correct stored first file (e.g., the decoder file); however, this can generally represent a trivial amount of overhead compared to the overall savings in bandwidth. For ease of description the first file, which can be stored on a receiver beforehand, will sometimes be referred to herein as a “decoder” file, and the second file, which can be transmitted as part of a broadcast or streaming service, will sometimes be referred to herein as a “broadcast” file
In another illustrative embodiment, plural decoder files can be combined into a single decoder file library. Receivers can, for example, store multiple decoder file libraries, with each decoder file in a library sharing certain common attributes, such as, for example, encoder type, encoding bitrate, and file-splitting algorithm with the other decoder files in the library. These common attributes can, for example, allow the receiver to recombine broadcast files with corresponding decoder files to reconstruct, or substantially reconstruct, the information of the content file. By combining the decoder files into libraries with common characteristics, overhead can be appreciably reduced since the common information need only be stored once. Libraries at receivers can also be modified and even customized based on user preferences.
In accordance with aspects of illustrative embodiments of the present invention, the content in the original content files can be, for example, songs or other audio files, video files of varying lengths, data files, images, electronic books, etc.
The present invention will be more readily understood with reference to the illustrative embodiments thereof as shown in the attached drawing figures, in which:
Throughout the drawing figures, like reference numbers will be understood to refer to like elements, features and structures.
In exemplary embodiments of the present invention, the efficiency of transmission bandwidth can be increased by splitting a digitally encoded, original content file to be transmitted into least two derived files, tables or other data structures or groupings. As an example, one of two files, which can include a majority of the original content file, can be stored locally in a receiver. The second derived file can be transmitted (e.g., broadcast over the air in real-time or streamed) to a receiver. For example, the first file can be loaded into the receiver when it is manufactured, or it can be subsequently transmitted to the receiver (e.g., wirelessly transmitted or streamed via the Internet) and periodically updated. In accordance with illustrative embodiments of the present invention, the first file is generally available at the receiver prior to the receiver's receipt of the second file.
Once the second file is delivered (e.g., broadcast or streamed to one or more receivers), a receiver combines the second file with the locally stored first file to reconstruct, or substantially reconstruct, the information of the original content file (e.g., in real-time with the received broadcast). For example, the encoded content can be reconstructed by inserting missing data segments received over the air (e.g., the second file) into the locally stored first file or by using intelligent algorithms to otherwise combine the segments received over the air with the locally stored first file segments. Upon consumption of the combined segments, the second file segments are no longer available in the receiver, whereas the first file segments remain in local storage (albeit denatured and effectively unusable to varying degrees), as described in more detail below.
As explained below, the first file can be denatured such that no segment of it relates to any portion of the corresponding encoded original content file. To create the first and second files, the original content file can be encoded, and the encoded file then split into at least two files using various algorithms, where bits or groups of bits can be removed from the encoded original content file to create the second file. The remaining compressed data can be used to create the first file. In illustrative embodiments of the present invention, the split can be implemented so that the first file no longer contains any of the structure or framing information for packets or frames of the original encoded content file that serve to identify bit positions for the encoded data, or even any reference to the encoded file packets or frames. In such embodiments, the bits in the first file are thus essentially random (i.e., generally not in the same or similar sequence as the encoded content file) and unrecognizable with respect to the encoded original content file without using the data from the transmitted second file and having knowledge of the process or algorithm(s) that were used to perform the split. This latter knowledge can be provided to the receiver by way of a split file decoding process, shown, for example, as “EBT Decoder Process (E)” in
Split file decoding reconstructs the encoded original content file from the received second file by first locating its corresponding stored first file and combining the first and second files. The combined or reconstructed encoded file, or encoded file segments, can then be subject to content file decoding using a technique corresponding to the encoding technique employed by the encoder. Thus, instead of simply encrypting an original content file such that all of its content remains present (i.e., in an encrypted form) in the receiver or receiving device, part of the actual content has been removed from the stored file, and the reconstitution process requires that missing content to be replaced. In accordance with illustrative embodiments of the present invention, the denatured first file cannot be decrypted. Thus, any attempt to recover the original content without the second file requires guessing at what information is missing, as well as where it belongs in relation to the other information, and is therefore qualitatively more complex than, for example, guessing at a decryption key. Further, the transmitted second file is not a key, but rather contains additional information derived from the encoded content file that was excluded from the stored first file.
In exemplary embodiments of the present invention, a significant increase in transmission bandwidth efficiency can be achieved by asymmetrically splitting the content file such that a larger portion of the content is pre-provided to the receiver (e.g., via the first file) and a lesser portion of the content is transmitted (e.g., via the second file). For example, if the ratio of the size of a locally stored file to a broadcast file is greater than 10:1, then an increase in broadcast efficiency is achieved of at least 10 times greater than the bandwidth efficiency of transmitting a full copy of content file even as compressed. Since the locally stored file is a denatured file that does not contain sufficient information to replay all or even part of the original content file, and its segments do not relate to any portion of the encoded content file without first combining with the transmitted file, the first file (e.g., a local file) cannot be decoded without the use of the transmitted file. Instead, the locally stored first file can be characterized as a custom file table database for the audio (or video) decoder, similar to the Huffman Coding tables stored in the receiver 14, for example. In this respect, the first file table can be seen as a highly compressed version of the original content file that has been denatured such that none of its segments relate to any portion of the content file when decoded by itself and without reconstruction using the transmitted second file. With the exception of the file combining process, the second file table is handled at the receiver in a manner equivalent to a normally compressed original content file in that only the file portions required for normal receiver operations (e.g., content rendering or playback) are retained in RAM.
The content delivery approach will now be exemplified with reference to
Content File: the original information to be made available to a user such as audio content, video content, data, etc. The term “file” is understood to be very general. Thus a table or other grouping of data or data structure can be a type of file. As explained below, and as referred to in the figures, different types of table files can be used (e.g., a Broadcast Table File and a Decoder Table File).
Encoded Content File: the Content File after being encoded. For audio content, an audio encoder can be used that employs USAC, AAC, Mp3, or PAC, among other coding methods. For video content, a video encoder can be used that employs MPEG-4, WMV, AVC/H.264, or DVB-S2, among other coding methods. For static images, an image encoder can be used that employs JPEG, PNG, or GIF, among other coding methods. For data, an entropy coding technique (e.g., ZIP) can be used.
Encoded File Segment: the smallest portion of an encoded file that can be decoded by a suitable decoder into a format resembling the original content such as an “audio frame” or a “video frame.” File segments can vary in length.
Enhanced Bandwidth Technology (EBT): content encoding and corresponding decoding wherein a Content File that has been encoded is split into at least two parts hereinafter referred to as “EBT files” in accordance with illustrative embodiments of the present invention. As noted above, at least one of the EBT files is provided to a receiver(s) in advance of its receiving the transmitted EBT file and another is transmitted.
Broadcast Table File: one of at least two EBT files. The Broadcast Table File (BTF) is transmitted (e.g., broadcast or streamed) in real-time or near real-time and is typically the smaller of the two files.
Decoder Table File: one of at least two EBT files. The Decoder Table File (DTF) is stored locally in the EBT receiver in advance of the real-time transmission of the BTF, and is used to decode the Broadcast Table File (BTF). The Decoder Table File (DTF) is typically the larger of the two files so as to improve transmission bandwidth efficiency of the BTF.
BTF and DTF segments: the smallest fragment of a BTF or DTF which contains the information necessary for decoding in accordance with illustrative embodiments of the present invention. The BTF segments and DTF segments have a one to one correspondence with each other. The BTF and DTF segments do not necessarily have a one-to-one correspondence with Encoded File Segments. For example, the combination of a single audio DTF segment and its corresponding BTF segment (i.e., one EBT audio segment) can correspond, for example, to 9 or 10 encoded audio frames.
Decoded Content File: the file that results from decoding an Encoded Content File. In some special cases (e.g., lossless encoding), the Decoded Content File is identical to the original Content File. However, in the more general case, the Decoded Content File is merely similar to the original content file. In other words, for the case of an original Content File consisting of audio, the Decoded Content File can be an audio file that sounds, to varying degrees, like the original content when played for a user. If the original content file were a video, the resulting Decoded Content File can be a video file that looks like, to varying degrees, the original Content File when viewed by a user.
Reconstructed Content File—an Encoded Content File created by combining the two EBT files at a receiver, or by combining a series of BTF and DTF segments at a receiver.
With reference to
With continued reference to
Alternatively, and with reference to
EBT Encoding Process (B′) described herein creates first files (i.e., denatured, stored files) that are uniquely designed for individual pieces of content to achieve high efficiency (e.g., high levels of compression) in a broadcast or other transmission stream. Thus, rather than a decoder table that is optimized for “music” or “talk,” for example, an EBT decoder table file can be, for example, optimized for a particular specific piece of content. In accordance with illustrative embodiments of the present invention, the degree of denaturing, which is a function of the EBT File Splitting Process (D) in
Because the Encoded File (C) is compressed, it is more subject to small data errors. In other words, even small data errors can result in large perceived changes in the quality of the decoded file. Some encoding processes add a Cyclical Redundancy Checksum (CRC) to the entire Encoded File (C), or, for example, to encoded packets or segments within the Encoded File. Both types of CRC placements are illustrated with respect to the Encoded File (C) in
Since a CRC provides information about missing or erroneous bits, it can be important to the security of an EBT implementation to strip CRC data, if present, from the Encoded File (C) altogether and not place it the stored file (i.e., the DTF); otherwise, the CRC data could be used to facilitate an attempt to reconstruct the DTF. Ensuring that the DTF does not contain the CRC or any part of the CRC makes reconstruction of the Encoded File (C) without the BTF much more difficult; therefore, higher ratios of compression (e.g., larger ratios of DTFs to DTFs) are possible. Alternatively, as described below in connection with
With reference to
As noted, a Broadcast Table File (BTF) can be the smaller of two files resulting from the encoding and file splitting process. With reference to
With reference to
Operations at a receiver to combine locally stored DTF segments with transmitted and received BTF segments are next described with reference to
A transmitted stream can, for example, use information or metadata to instruct a receiver(s) on which DTF to combine with a particular BTF for decoding as per an EBT Decoder Process. Uncertainty, however, can occur when decoding. For example, if DTFs are broadcast to receiver(s) as opposed to streaming DTFs (e.g., a receiver must be powered on for a selected amount of time over a selected broadcast period to receive transmitted DTF updates), uncertainty exists as to whether the receiver actually received the necessary DTF to decode a given BTF. Use of libraries or collections of files in accordance with illustrative embodiments of the present invention can overcome such uncertainty and realize a number of advantages. For example, a library can be a structured group of files, or the files in a library can, but are not required to, share some common characteristics. In another example, multiple DTFs can be combined into a decoder table file library stored at the receiver. As described in more detail below, metadata can be transmitted to receiver(s) to indicate that a particular program channel uses a particular library (e.g., a map or table can be transmitted that relates the channel numbers or indices of EBT channels to a decoder file library or set of libraries required to process the content on that channel). Storage of that library at a receiver(s) facilitates determination by the receiver of whether it can play that program channel when transmitted using EBT files. The metadata can also be pre-programmed into the radio. If the receiver cannot locate the particular DTF needed to playback a currently tuned channel, it can, for example, be configured to playback silence for an audio channel and display a message that content is unavailable and an optional reminder to update the library for that channel.
In exemplary embodiments of the present invention, libraries of DTFs are also advantageous in that they can indicate encoder properties used to create the corresponding BTFs. It is to be understood, however, that other methods can be used to communicate encoder properties to receivers. For example, as explained above, a transmitted EBT file, i.e., a BTF, can optionally include information about encoder properties. Alternatively, messaging can be used, although it is not as efficient in terms of bandwidth. For example, message bits can be sent with a code indicating how a receiver should combine transmitted file bits in a BTF with stored file bits in a DTF.
With reference to
With reference to
With reference to
Maintaining libraries at EBT-capable receivers will be now described with reference to
With reference to
Alternatively, DTF libraries can be replaced as well as added.
DTF libraries can also be updated. As shown in
For illustrative purposes, a group of DTFs 58 that constitute a collection or library of EBT files (e.g., DTFs) for storage in a receiver memory 56 is shown in
As stated above, library and file indices can be embedded in the stored files (e.g., EBT files for storage at the receiver such as DTFs or libraries or collections of files for storage). Alternatively, library and file indices can be added as a wrapper at the time of transmission of the stored files so that the appropriate stored files, DTFs, can be located by the receiver and combined with the transmitted EBT files, BTFs, in real-time. As stated above, indexing and tagging the files within a decoder table file library or collection 58 can also be employed so that the transmitted EBT files and the stored EBT files, or portions of these files (e.g., segments as shown in
The EBT files or libraries for storage at the receiver can be embedded with encoding and file splitting information or parameters such as the type of audio or video encoder used and the encoded bit rate in the stored files or the algorithm or technique for providing missing bits from a transmitted file or file segment to a stored file or file segment. As stated above, the embedded information simplifies the determination by the receiver of the processes needed for EBT decoding (e.g., via EBT Decoder Process (E) in
As stated above, a content delivery approach is provided to increase the efficiency of transmission bandwidth by splitting an original content file to be transmitted into at least two files, tables or other data structures or groupings (e.g., EBT files), in accordance with exemplary embodiments of the present invention. As stated above, at least one of the EBT files can be transmitted in real-time or near-real time. At least one other EBT file can be generated and provided to receiver(s), for example previous to the transmitted file and then pre-stored, for combining with the transmitted EBT file to generate a decoded content file. The original content file can, for example, be split such that the EBT file stored at the receiver(s) is denatured and either cannot be decoded for play back to a user (i.e., without data from the transmitted EBT file), or plays back decoded sounds or pixelations bearing no resemblance to the original content file. Examples of different approaches for splitting the content file are next described with reference to
With reference to
A second illustrative approach for splitting content files is independent of the audio transcoder transport and uses secret sharing techniques. For example, an output of an audio encoder (e.g., at a programming center or other location where content is prepared for transmission) can be, for example, split into two asymmetrical tables. Assume the following binary coefficient matrix is applied to a content file X comprising 5 file segments [X1 X2 . . . X5] and generates polynomial product symbols [S1 S2 . . . S5]:
Bold symbol S1 can be broadcast over the air or otherwise transmitted (BTF), and the remaining symbols can be stored locally at the receiver(s) (DTF). The polynomial product symbols [S2 . . . S5] are thus cached at the receiver(s), but cannot be decoded without receiving the bold symbol S1. Once the bold symbol is received, and file segment X1 is decoded, the remaining file segments [X2 . . . X5] can be decoded by the receiver(s).
In this example, [X2 . . . X5] are differentially encoded file segments, so a differential decoder is used to retrieve the remaining encoded file segments.
In accordance with another illustrative embodiment of the present invention, a third approach can be used which is also independent of the audio transcoder transport. Data from the audio encoder output can, for example, be split into two separate tables, or other types of data structure, to generate the at least two EBT files. As shown in
In accordance with another illustrative embodiment of the present invention and as described below in connection with
In accordance with an illustrative embodiment of the present invention, segments of different lengths can be used, which allows for greater control of instantaneous bandwidth when transmitting EBT files (e.g., BTFs) and, optionally, other content. Such control is useful for performing crossfades or inserting interstitial content between consecutive EBT files, for example, without increasing the instantaneous transmission rate. As shown in
With reference to
In accordance with another illustrative embodiment of the present invention, more information-dense or significant portions (e.g. more significant bits) of an encoded content file can be selected for placement into a selected one of the EBT files such as the transmitted EBT file (e.g., BTF in
In some exemplary embodiments, the broadcast stream or other transmission mode (e.g., BTF in
The Universal Speech and Audio Codec (USAC) is an example of an entropy-encoded audio compression standard. Entropy encoding maximizes compression by reducing redundancy in the compressed data file. As a result, almost all bits in the compressed data file are of significant importance to the decoding process. Puncturing even a small percentage of the bits in the data file can remove enough information such that the remaining data is not usable for generating even a rough approximation of the original content. Entropy encoding also maximizes the randomness and minimizes correlation between bits. This makes it almost impossible to intelligently guess the position and value of the punctured content. The following example demonstrates how reconstruction of the original information from the punctured data file alone is not a solvable problem. When an audio segment is encoded with the USAC audio encoder at a rate of 24 kbps, each 46 mS segment of the input audio stream is encoded to yield a variable length compressed output data packet averaging 138 bytes in length. Each output data packet has a total of 10 bytes punctured. Since each packet contains a 2 byte CRC, 2 of the 10 bytes are used to remove the CRC. The remaining 8 bytes (64 bits) are removed using a 1-bit resolution cryptographic puncture pattern from a 100 byte section (800 bits) of the packet which does not include certain fields, such as those containing common header bits, Spectral Band Reproduction (SPR) bits and/or parametric stereo bits. The remaining 736 bits (800-64) of the 100 byte section are stored along with the remaining non-punctured data packet bits in the receiver. In the absence of the transmitted data file, reassembling the original packet from the punctured packet presents a problem of the number of possible combinations 64 bits that can be added to the 736 bits. The number of possible puncturing position combinations is 800!/(64!*(800−64)!)=˜1095. The possible values of the 64 bits, is 264 or ˜1020 which results in an aggregate number of possible combinations of puncture patterns and values of ˜10115. Assuming that of these possible combinations, approximately one in a million will form a valid audio packet, then the possible number of valid audio packets which can be formed by the punctured packet is ˜10109. Without the transmit file, each of the ˜10109 packets is a possible solution, although only one is correct. If an average song is 3.5 minutes in length, it will contain approximately 4565 packets, where based on the punctured file, each packet in the song could have ˜10109 possible options. The transmission file containing the punctured information is required in order to reconstruct the packet. Even though the punctured file stored at the receiver is not usable without the transmit file, typically the punctured file will be encrypted consistent with normal security practices. The puncturing method employed in this illustrative implementation can be scaled commensurately for use with other types of content (e.g., video) and encoding techniques or standards.
In its simplest form, the EBT encoder could puncture a block of N bits every M bits to achieve a puncture rate of N/M. However puncturing in this deterministic and non-targeted way, would not maximize the denaturing of the compressed audio packets. Thus, in many exemplary embodiments it is better to puncture the critical portions of the packets, in a non-deterministic pseudo random pattern, and in way that disrupts the decompression process the most. The following is an example of how this can be achieved with High Efficiency AAC v2 encoded content.
For HE-AACv2, each packet consists of a Mono Main Channel (0-5 KHz band), a Spectral Band Replication (5-15 kHz band), and Parametric Stereo (Left-Right Channel) subpackets. The Spectral Band Replication reproduces the higher frequency content by transposing harmonics from the Mono Main Channel and is therefore dependent of the Mono Main Channel. The Parametric Stereo is also dependent on the Mono Main Channel. Therefore, targeting mainly the Mono Main Channel for puncturing will not only degrade it, but also the Spectral Band Replication and Parametric Stereo.
The Mono Main Channel information is primarily compressed using an entropy encoder. Entropy decoding is a recursive algorithm based on making decisions along a binary tree. At each branching point, the entropy decoder determines whether the next bit is “1” or “0” based on the previous decision statistics (i.e., where it has been), and the remaining compressed bits (directions forward). A single puncture of the compressed bits will result in a wrong decision being made (e.g., a “0” is decoded instead of a “1”), which in turn changes the decision statistics, and causes additional wrong decisions later on. In addition, having more separate sparsely placed, amplifies the number of wrong decisions. Therefore, in exemplary embodiments of the present invention it is best to have many small punctured portions as opposed to a single large punctured portion in the entropy encoded content. In this example, instead of puncturing a single block of N bits, N single noncontiguous bits may be punctured in the Mono Main Channel entropy encoded content.
As a last step, the locations of the puncture bits may, for example, be distributed in a pseudo-random pattern. In this way, any attempt to reconstruct the original content is obfuscated both by the value and position of the punctured content. In this example, assuming that 1 in 10 bits are punctured, and a simple Pseudo Number generator is used to generate an integer (Ri) 0 and 9, the puncture position of the i th bit (Pi) would be Pi=10*i+Ri. In the depuncturing operation, the seed for the PN generator can be sent over the air along with the punctured content to facilitate decoding.
As stated above, one of the EBT files is transmitted whereas another corresponding EBT file is present and stored at a receiver(s). The transmitted EBT file (e.g., a BTF as described in
In accordance with additional aspects of illustrative embodiments of the present invention, multiple approaches are available to transmit at least one of the EBT files created from a content file. For example, the transmitted EBT file (e.g., BTF in
In accordance with additional illustrative embodiments of the present invention, the end of one transmitted EBT file (e.g., BTF in
As an illustrative alternative to the example of using puncturing for crossfades (e.g. described below in connection with
As mentioned above in connection with EBT file libraries, an EBT channel can be created by transmitting a continuous sequence of EBT files (e.g., BTFs) corresponding to respective content files. In the above example, an EBT audio channel is generated using songs from a library. It is to be understood, however, that the sequence of EBT files need not be generated from content files that are the same content type, nor do the files need to correspond to a particular library of files at the receiver. In other words, the transmitted sequence of EBT files can comprise some form of metadata in the files themselves or within the channel to instruct a receiver on which stored EBT files (e.g., DTFs) are needed to decode the EBT channel.
Additional bandwidth efficiency, however, can be realized by employing libraries as exemplified above. For example, files transmitted on a particular EBT channel can be limited to files that are contained in a particular decoder table library or libraries. In accordance with another example, a customized sequence of EBT files (e.g., BTFs) can be transmitted that is tailored to the contents of a custom decoder table library, which is described further below, to create a custom EBT channel. In addition, library index and decoder file index information can be transmitted at substantially the same time as transmitted EBT file (e.g., the smaller of the two EBT files) and in the same transmission path.
As stated above, the stored EBT file (e.g., a DTF as described in
The stored EBT file can be loaded into the receiver when it is manufactured or subsequently transmitted to the receiver (e.g., wirelessly transmitted or streamed via the internet), and can be periodically updated (e.g., over the air). The stored EBT file can also be provided to the receiver via downloading over the internet or transferred from another memory location (e.g., a portable memory device). In any event, the stored EBT file (e.g., DTF in
As stated above, receivers can be provided with EBT files (e.g., DTFs), as well as groups of EBT files (e.g., one or more libraries of files) for storage in read only memory (ROM) or other non-volatile memory associated with the receiving device (e.g., internal to the receiving device, or external to the receiving device and capable of being coupled thereto for file transfer and management operations). The stored EBT files and/or a library or libraries of stored EBT files can be provided on a removable digital storage medium (e.g., a flash memory device such as USB thumbdrive or micro SD, SDHC or SDXC card) from which the receiver is capable of retrieving EBT files and other data, code or instructions for accessing stored EBT files (e.g., for updating stored EBT files and/or libraries, or for combining with transmitted EBT files for decoding). In addition, a library or libraries of stored EBT files can be built into an application (i.e., an “App”) that can be downloaded into a multi-purpose internet-connected device for decoding and playing back content transmitted using EBT in accordance with illustrative embodiments of the present invention.
A radio receiver or other receiving device can be provided with a fixed set of libraries and, in addition, can optionally support expansion through the addition of more libraries (e.g., as exemplified in
As exemplified above in connection with
The file produced by the combining of EBT files can be temporarily buffered in random access memory (RAM) or volatile memory. As stated above, the EBT files (e.g., the stored and transmitted files) can, for example, be combined to recover the original digitally encoded file or at least a decoded and recognizable version of the original content file. As described herein, the transmitted EBT file (e.g., BTF) is generally not (but may be) stored at the receiver, for example, an EBT-enabled channel is played by decoding the file(s) in real-time. A receiver, however, can, for example, temporarily store the decoded file, such as buffering the EBT channel (e.g., stored in volatile memory) for various receiver operations such as, but not limited to, instant replay operations (e.g., rewind, fast forward, skip and pause/resume operations during real-time or near real-time playback), content preview operations (e.g., buffering EBT channels for scanning), channel surfing operations (e.g., ensuring certain types of content tracks are played from their starting points following channel changes), personalized channel operations (e.g., buffering selected EBT channels to automatically create personalized playlists), among other receiver operations. The decoded file can also be stored for longer periods of time such as, for example, for recording an EBT channel (e.g., recording an EBT channel for a limited period of time for deferred playback, or storing a data file decoded from EBT files). Illustrative operations using buffered channels are disclosed in Patent Application Publication Nos. 20080163290, 20090320075 and 20100268361, the entire contents of which are incorporated herein by reference.
Combined files can be played back at a receiver in real-time. In addition, buffered combined files from a single channel can be played in the same order that their corresponding EBT files were transmitted. As stated above, buffering combined files allows for files obtained from a single EBT channel to be played back in a user-controlled sequence using pause, rewind, and fast forward functions of the receiver or associated user playback device.
In accordance with an illustrative embodiment of the present invention, the transmitted EBT files from multiple broadcast EBT channels can be buffered in volatile memory at a receiver for playback in near real-time. For example, multiple, simultaneously transmitted EBT channels can be selected for buffering at the receiver to give the user the opportunity to switch between the buffered channels to hear preferred content from among them. The multiple buffered EBT channels can be a subset of EBT program channels that use the same library for channel content programming (e.g., channels carrying the same genre of music that use content from the same library of music to create their respective playlists). The library employed by the multiple buffered EBT channels is provided to receiver(s). A semi-customized playback channel can then be generated at a receiver by playing back buffered EBT files in a sequence from the multiple buffered EBT channels in a channel agnostic manner. For example, a user can skip a track on a currently tuned buffered EBT channel by changing to the buffered track of another buffered EBT channel. Even though a library may contain a similar genre of content, the variation of tracks stored in the library can be significant, adding to the content diversity among different channels (e.g., even among channels playing the same genre of music). This example of multiple buffered EBT channels permits a user to choose preferred content from among different simultaneously transmitted EBT files. Alternatively, a receiver can be programmed with existing technology to compare parameters and characteristics of content consumed by the user with the parameters and characteristics of buffered decoded files, as well as durations of time content shall remain in a buffer and any optionally stored user profile, to automatically select buffered content for playback based on the user's preferences. Coupled with the bandwidth saving benefits of using EBT files, this approach also provides programming sources with the opportunity to create additional programming channels to mine the contents of a library more comprehensively and effectively.
Thus, this use of buffered EBT channels produces essentially a semi-custom playback channel but without using a custom library or custom streamed content as will be described below, or any stored content. That is, this approach can be implemented in a one-way transmission system such as a digital audio broadcast system, in contrast to a two-way Internet Protocol connection to a programming source that can receive user feedback from the user receiving device or otherwise monitor user behaviors with regard to streamed content (e.g., types of streamed content requested and rejected, search queries and preferences, frequency and number of times of use, pauses, rewinds, skips, deletions, and the like). Only tracks or files in the currently playing buffer are available for inclusion in this semi-custom EBT channel, and the buffered content is erased when the radio is turned off. In an alternative embodiment, the combined EBT files (i.e., the files resulting from combining DTFs and corresponding BTFs) can be acquired for authorized storage and use. The stored, combined files can then be played back to a user in a random or pseudo-random order. Thus, if a receiver stores a certain library of content, the user can receive the BTFs for preferred content files for EBT decoding and pay to play preferred content from the library at their will. Again, this example implementation of EBT can produce a semi-custom channel using only a one-way transmission channel and therefore without using either a custom stream or a custom decoder table library as described below.
Overview of Illustrative System Architecture
Illustrative embodiments of the present invention are described herein with respect to a satellite digital audio radio service (SDARS) that is transmitted to receivers by one or more satellites and/or terrestrial repeaters. It is to be understood that the advantages of the improved efficiency content delivery method and system of the present invention can be achieved in other broadcast delivery systems (e.g., other digital audio broadcast (DAB) systems or high definition (HD) radio systems), as well as other wireless or wired methods for content transmission (e.g., streaming music or video content over wireless or wired networks). Further, it is to be understood that the advantages of the present invention can be achieved by user devices other than radio receivers, including but not limited to smart phones, tablets, personal computers, and personal navigation devices.
As illustrated in
With reference to
In addition, it is to be understood that there could be many more channels (e.g., hundreds of channels); that the channels can be broadcast, multicast, or unicast to the receiver 14; that the channels can be transmitted over satellite, a terrestrial wireless system (FM, HD Radio, etc.), over a cable TV carrier, streamed over an internet, cellular or dedicated IP connection; and that the content of the channels could include any assortment of music, news, talk radio, traffic/weather reports, comedy shows, live sports events, commercial announcements and advertisements, etc. “Broadcast channel” herein is understood to refer to any of the methods described above or similar methods used to convey content for a channel to a receiving product.
An exemplary receiver (e.g., for SDARS) will be now described with reference to
As shown in
The system controller in the radio receiver 14 is connected to memory (e.g., Flash and DRAM), a user interface, and at least an audio decoder. Storage of the local file tables at the receiver 14, for example, can be in Flash, ROM, Hard Drive or other non-volatile memory. In one example, an 8 GB Flash device, which can store content tables for 24 kbps parametric stereo audio files of 4 minute duration each, can hold decoder file tables for over 10,000 songs or similar duration and quality audio content files.
With continued reference to
Content Delivery in a Digital Audio Broadcasting (DAB) System Using EBT
With reference to
In this example, an “EBT Channel” refers to music channels broadcast using Enhanced Broadcast Technology (EBT), which increases the broadcast efficiency in the range of 2.8× to 10×, depending on the broadcast configuration. EBT Channels can contain interstitials (e.g., channel introductions, DJ banter, and the like) which are added by the programming staff in a manner similar to normal channels (e.g., the basic SDARS channels such as those described with reference to
Briefly, systems and methods for transmitting and receiving additional data, such as video data or additional dynamically added music channels, over legacy satellite digital audio radio signals can employ hierarchical modulation to transmit secondary information over a legacy signal. For example, a SDARS system 10 as illustrated in
In the illustrative embodiment, an EBT Channel is generated from a fixed music library of generally less than 500 songs and contains interstitial content totaling less than five minutes per hour. The EBT Channel increases the efficiency of broadcast bandwidth by splitting the music library content into two compressed table files or data tables. The first data table (i.e., the Tx Data Table 64 in
The Tx and Rx Data Tables 62 and 64 can be generated in advance for each individual encoded content file broadcast with EBT. For example, with reference to
As shown in
In accordance with an illustrative embodiment of the present invention and with reference to
Under this example, the Rx Data Table 112 stored in the receiver 14 is comprised of incomplete compressed audio data packets which cannot be used to recreate all or even a portion of the uncompressed audio since the critical data needed for playback (e.g., both the missing data and the locations where the data is missing) is contained in the separate Tx Data Table 114 located at the broadcast site. When the Tx Data Table 114 is broadcast, streamed or otherwise transmitted as indicated at 120 in
The 2 kbps transmit stream 122 in
In the event the 2 kbps transmit stream 122 is interrupted as a result of channel impairments, the receiver 14 is unable to reconstruct audio packets for the duration of the interruption. Standard error concealment techniques are applied to the audio output stream during interruptions of the 2 kbps transmit stream 122 which is equivalent to the error concealment used when a 24 kbps channel containing complete audio packets is interrupted. The local Rx Data Table 114 does not provide a benefit to the receiver 14 when errors are present on the transmission channel.
With reference to
The receiver 14 combines the reconstructed music broadcast stream 132 and the 8 kbps interstitial stream 124 in real-time to generate the EBT Channel audio. An example of the instantaneous broadcast bandwidth requirements for one EBT channel over the period of approximately one hour is shown in
With continued reference to
Interstitial Content Insertion with EBT Files
As noted above in connection with
EBT Content Delivery with Regional or Multi-Lingual Interstitial Content
The bandwidth savings realized by delivery content such as music or video programming using EBT files allows content providers and programming stations to expand their interstitial content reach more audiences with different demographics. For example, a multi-lingual channel can be produced in which music or video program content is delivered via EBT files, while the DJ interstitial material and other commentary on the music is delivered as interstitial content. Instead of delivering a single piece of interstitial material to fill a gap in the sequence of transmission of the transmitted EBT files (e.g., BTFs), a broadcast server can transmit two or more interstitial segments in respective languages for the same interstitial gap. A receiver, in turn, can play one of the two or more interstitial segments depending on a user-selectable language preference. This application is useful for a European radio broadcast system or other regional broadcast system in which multiple languages must be supported for variable content such as advertising and DJ commentary, while quasi-static content (e.g., music, video, data, images) is common to all languages.
Similarly, an EBT channel can be produced with regionalized commercial insertion. For example, quasi-static content such is delivered via EBT files to all users, while interstitial advertising is regionalized in some or all cases. The broadcast or transmission channel would transmit two or more interstitial segments of advertising with a tag or wrapper that is associated with a geographical region. The receiver, in turn, can play the segment that most closely matches the current location of the receiver, along with the content decoded from the EBT files. This permits segmentation of advertising space on broadcast voice-tracked EBT channels or similar types of programming channels to multiple regions.
EBT Channels can be categorized as either long duration channels which can be broadcast for years, short duration channels which can broadcast for a few weeks, or Custom EBT channels which are continually being modified in response to user feedback. In order to play a short duration or long duration EBT Channel, the receiver 14 employs a complete Rx Data Table for that channel stored in local Flash memory. Both long duration and short duration EBT channels can be transmitted over satellite or other broadcast media or one-way transmission system, for example. On the other hand, in order to play Custom EBT channels, the receiver 14 employs a customized decoder table library or libraries, as described below. EBT-capable Receivers may support any one of these EBT channel types, any combination of these types (for example Long duration and Custom), or all three types of EBT channels.
Long duration EBT Channels can be programmed, for example, using music libraries which are not subject to change, with examples including the SDARS programmer-defined or Billboard-defined top 300 Country Hits of the 80s, the top 400 Country Hits of the 90s, the top 400 Dance/Club Songs of the 90s and the top 400 Rock Hits of the 60s and 70s. The Rx Data Tables 114 to support the reception of long duration channels can be loaded into the receiver 14 at the time of manufacture. These channels realize an approximate 10:1 bandwidth efficiency factor since broadcast bandwidth to download Rx Data Tables to the receiver is not required. If an EBT Channel service is comprised of only long duration channels, each channel is buffered at the transmitter 120 to enable time averaging of the interstitial bandwidth peaks. This introduces a delay in the ability of the receiver to play a live interstitial each time the receiver is powered up while the interstitial time averaging buffers are filled. If an interstitial is scheduled for play during this initial buffering period, a default interstitial stored in flash may be substituted. Once the buffers are full, live EBT interstitials can be immediately available.
The Rx Data Table Files to support the reception of short duration channels are generally not expected to be available at the time of manufacture and therefore are scheduled for delivery to the receiver 14 over-the-air. These tables can be broadcast to the receiver, for example, using the Reliable File Delivery (RFD) protocol (e.g., the data encoding technology described in commonly owned U.S. Patent Application Publication No. US 2010/0106514, the entire contents of which are incorporated by reference herein) prior to commencement of the live broadcast, for example. By way of an example, a short duration EBT Channel can be programmed using a 200 song music library and support a broadcast duration of 6 weeks or longer. The Rx Data Table for the 200 songs can be broadcast for one week using 72 kbps, and would require a cumulative “receiver on” time of 4 hours to complete the download. Receivers 14 that are not active during any given Data Table RFD broadcast period would not be able to receive the associated EBT Channel broadcast. Devices with IP connectivity can have these Rx Data Tables downloaded automatically when connected to the SDARS provider servers. Subscribers could also have the option to download the missing Rx Data Tables via USB or WiFi, or to provide the missing tables to the receiver with a removable Flash device. Alternatively, the Rx Data Table transmission duration can be extended beyond a week to assure that more of the target radio population receives the table.
Provided each 200 song library supports two simultaneous channels, a short duration EBT Channel service comprising 12 channels in a staggered 6 week rotation would require 72 kbps RFD bandwidth (BW), 24 kbps Channel BW and 8 kbps interstitial BW for a total of 104 kbps. The broadcast bandwidth profile is shown in
Each new receiver typically starts out with no short duration Rx Data Tables and therefore cannot initially tune into the short duration EBT Channels. After receiving the first song library Rx Data Table in Week 1, Channels 1 & 2, each programmed with the first song library, would become available with the channel broadcast beginning in Week 2. Continuing RFD song table downloads, after receiving the second song library tables in Week 2, Channels 3 & 4 would become available with the channel broadcast beginning in Week 3. This process can continue until 12 EBT channels are available at the beginning of Week 7. Thereafter, two new EBT Channels can be rotated into the group of 12 channels every week. Subscribers have the option to manually download any missing song library data tables at any time.
As a result of the additional RFD bandwidth required to continuously update the song libraries (Rx Data Tables) over the air, the average bandwidth per channel for this service is 104/12=8.67 kbps. With the broadcast configurations defined here, the bandwidth efficiency factor for the short duration EBT Channel is 24/8.67=2.8× (e.g., 2.8 times greater than a transmission of the channel content without use of data tables), while the bandwidth efficiency factor for the long duration EBT Channel is 24/2.4=10×.
An EBT Channel service that includes a mix of long duration channels and short duration channels provides mid-range bandwidth efficiency factor and enables a technical solution for management of the bandwidth peaks created when the 8 kbps interstitials are present on multiple channels simultaneously. A typical mixed service configuration for 24 channels is shown in
With reference to
With an even mix of long and short duration channels, the EBT Channels service achieves a bandwidth efficiency factor of 4.5×. With a 2:1 mix of long and short duration channels the efficiency factor could be improved to 5.7×.
The interstitial bandwidth allocation of 8 kbps in Table 1 assumes that each of the 24 channels will average 2.5 minutes of interstitials per hour and the interstitials are encoded at 8 kbps. For the 24 channels, the total interstitial time per hour is the 2.5 minutes/channel×24 channels=60 minutes. The total interstitial bandwidth averages out to 8×(60 min./1 hour)=8 kbps although the instantaneous bandwidth can vary considerably. The RFD bandwidth associated with the short duration channels is available to support the instantaneous bandwidth peaks which occur when multiple channels simultaneously play interstitials. For example, if interstitials were to line up on 7 channels at the same time, the instantaneous bandwidth requirement would be 7×8 kbps=56 kbps, which temporarily exceeds the allocated interstitial bandwidth of 8 kbps in Table 1. This bandwidth is required for each 432 mS frame wherein all 7 channels overlap. Since the RFD bandwidth can be adjusted on a frame by frame basis without a negative impact on the download, the 8 kbps interstitial bandwidth and 72 kbps RFD bandwidth are pooled to allow frame by frame peak allocations of up to 80 kbps for either RFD or interstitials as required. Independent of the peak frame bandwidth allocations, the average bandwidths for RFD and the interstitials are maintained 72 kbps and 8 kbps, respectively.
In order to characterize the probability for interstitials to simultaneously align on multiple channels over the course of 1 year, simulations were generated based on 12 and 24 channels with 2.5 and 5 minutes of interstitials per channel per hour. Results for 24 Channels and 2.5 minutes of interstitials are shown below.
In summary, the simulations in this example show that with 24 channels and 2.5 minutes of interstitials per hour, the peak interstitial bandwidth requirement is 72 kbps and this will occur during 28 frames per year. Since 80 kbps of pooled bandwidth is available to support peak interstitial BW needs, the broadcast bandwidth profile supports a real-time EBT Channel Service without the need for time averaging buffers at the broadcast site 20 or at the receiver 14.
The scenarios described above illustrate a specific operational intent of providing a pair of new short duration channels every week, with each short duration channel “on air” for 6 weeks, and a total of 12 short duration channels on air at any given point in time. Other operational variants can be supported, with more or fewer short duration channels on air at a time; longer times to send the Rx Data Channels; longer or shorter on-air times for the channels; less regularity in the start time and duration for the channels; etc. All these variations can have some effect on the bandwidth required (more or less required), but are technically feasible.
Thus, an EBT Channel Service can be configured to provide long duration channels which use Flash song tables loaded at the factory, short duration channels which use Flash song tables loaded via RFD bandwidth, or a combination both long and short duration channels.
This result can also be understood in terms of
As noted above, there are different types of decoder table file libraries. In one implementation, the decoder table files stored locally can be common to a large population of radios or receivers (e.g., for long duration or short duration EBT channel service as illustrated in
Support for Custom EBT channels can be accomplished with a software application (i.e., an “App”) running on any one of a number of wirelessly connected multi-purpose devices such as a communication device or portable computing device, including but not limited to a smart phone, tablet, or personal navigation device, or it could be accomplished with a radio device that also receives broadcast transmissions from satellite or terrestrial sources.
In this implementation, a user can specify favorite artists and/or songs, and a corresponding baseline decoder table library is then loaded on the radio device. Alternatively, the user can chose from among several preset baseline libraries. Subsequent to the initial decoder table library installation, a custom stream is then created using only content in the custom decoder table library. While listening to this custom stream, the user can indicate approval or disapproval for the currently playing content, and this approval or disapproval feedback then triggers the download of additional decoder table files, as well as the removal of stored decoder table files. The listener would have a user experience similar to other customized streaming music services; however, the bandwidth used for streaming would be substantially reduced since repeats of individual songs would require only the transmission of the BTF or streaming file. In this implementation, updates to the decoder table files could be preferentially performed over a WiFi or other “free” connection, while the streaming listening experience could take place over a wireless network (3G, 4G etc.) that charges by the amount of bandwidth used. An example cellular streaming application is described below.
It is thus noted that the various EBT techniques described above can be applied in a variety of ways to both support, and optimize bandwidth usage for, transmission of audio content to a user in a personalized music service. In sophisticated embodiments of such personalized music services, complicated cross-fades and other interstitial effects are performed to give a user a full “broadcast experience” on his or her smartphone, tablet or other intelligent mobile device. In order to facilitate such complex cross-fades, including those utilizing multiple elements, the relevant audio files and interstitials, along with detailed instructions as to how to implement the cross-fade (e.g., the audio trajectory, timing, intro and outro information, etc.) can be present to the user's device. This process is dynamic, and what is present, as well as how long before the actual cross-fade is implemented is it present, is a function of numerous metrics, including bandwidth, available memory on the user device, then present network conditions, etc., all of which can be processed, for example, by an intelligent download manager. In exemplary embodiments of the present invention, this download manager can be configured to include file splitting of encoded audio files and sending them in two or more files as described hereinabove, to optimize the use of often precious bandwidth and on-device memory to presend the vast majority of the audio content to such user devices. Details of such systems and methods, and the various considerations in presending elements of complex cross-fades and other effects are described in U.S. Provisional Patent Applications Nos. 61/631,440, filed on Jan. 3, 2012, and 61/561,593, filed on Nov. 18, 2011, each entitled “Systems and Methods for Implementing Cross-Fading, Interstitials and Other Effects/Processing of Two or More Media Elements Downstream,” and the corresponding PCT patent application, PCT/US2012/065943, filed on Nov. 18, 2012. These provisional patent applications, and the PCT patent application claiming priority to them, are under common assignment herewith, and are hereby fully incorporated herein by reference.
In accordance with an illustrative embodiment of the present invention, EBT can be used to leverage data stored at a mobile phone to achieve a cellular streaming system that reduces data consumption (e.g., data service plan bits) and power consumption at the smartphone, while also realizing the above-described advantages of increased bandwidth efficiency in the content delivery systems providing the streamed content. As noted above, EBT channels can be transmitted via satellite service such as the SDARS currently available in the United States and Canada; however, EBT channels can also be distributed via cellular services which are available world-wide. Also, as noted above, using EBT reduces music streaming rates to about 3 kbps, realizing a significant advantage over existing music streaming services that use 32 kbps, 64 kbps or higher. This reduced rate provides measurable advantages for smartphone users since data plan loading for streaming music is reduced by greater than 90%. Further, modem power consumption for streaming music may be reduced. Such EBT advantages can also be extended to other platforms such as a data load audio service via a telematics platform.
By way of an example, a smartphone can be configured with 32 GB flash reserved for EBT, which may be partitioned to contain a 30 GB song library loaded at manufacture (e.g., about 45,000 songs) and 2 GB for library updates (e.g., about 3,000 songs). If EBT were implemented to deliver an existing streaming service, for example, the song library can be specified based on the song usage statistics for that service. Library IDs as described above can be used to identify the library contents stored at manufacture.
The EBT streaming service can include, for example, as many as 100 streams programmed based on the device library ID. New songs can be downloaded based on user preferences, as described above. The streaming content service engine maintains a unique library per user or subscriber, and therefore maintains knowledge of what is in a user's library to stream selected content (e.g., custom-curated content based on user preferences indicated by content requests, rewinds, skips, and other user content interactions via the two-way interface) via corresponding transmitted EBT files (e.g., BTFs) with certainty that the user device stores the necessary DTFs for EBT decoding as described above. More specifically, custom EBT channels can be created with two-way transmission systems (e.g., using a smartphone or internet radio or other internet device). This example applies to music but is understood to be applicable to other types of streamed media. A user provides a profile to a music server or other content server, for example, that in turn selects suggested content (e.g., 500 songs) based on that profile. The songs are prepared for delivery to users by encoding and splitting them into EBT files (e.g., BTFs and DTFs as described above in connection with
Since receiving the BTFs at a smartphone consumes a comparatively small amount of service minutes, streaming content providers have incentive to offer more streaming services. A streaming service would benefit from commercial free radio streams generated using EBT, in addition to the improved bandwidth efficiency and opportunity to offer more services. Further, EBT can be employed to deliver a custom-curated streaming service.
As described above in connection with
As an example, a currently stored library or libraries can be replaced or a new library or libraries added by distributing a physical storage medium such as solid state memory device (SD, SDHC, and the like) or an optical disk that is provided to the receiving device. As stated above, a library or libraries can also be replaced or updated using a broadcast transmission channel and a non-real-time file distribution method. When updating, substantial amounts of a library generally remain unchanged, while individual files can be removed and others added. Alternatively, a library or libraries can be updated or modified using a two-way wired or wireless internet connection (e.g., to produce a custom decoder table library or libraries), whereby substantial amounts of a library would generally remain unchanged while individual files can be removed and/or added.
As described above, in the case of a SDARS provider or similar content provider, the transmitted EBT file (e.g., BTF) can be part of a program content stream comprising other content (e.g., a SDARS broadcast stream generated at the programming center 20 in
In accordance with illustrative, alternative distribution approaches, one of the file tables can be sent to the receiver 14 over a wireless data network (e.g., a 3G or 4G network) as a data stream rather than as a broadcast stream. Alternatively, one of the file tables can be sent over an internet protocol (IP) network (e.g., wired or wireless). In another alternative distribution approach, both files can be streamed but using different repeat frequencies, transmission rates, or transmission protocols, with the larger file (e.g., DTF) getting less frequent updates using a non-real-time data caching distribution method, and the smaller file (e.g., BTF) being sent in real-time on a scheduled basis as part of a channel stream or on-demand. For example, as shown in
Alternatively, a library or set of libraries can be stored on a flash memory device such as USB thumbdrive or micro SD card (or micro SDHC or SDXC card) and sold at a retail establishment. Alternatively, a library can be customized in real-time for a particular subscriber by the addition or removal of decoder table files in response to feedback from the listener (“like”/“dislike”). The approach in which both files are transmitted, but at different rates over different transmission channels is ideally suited to a video application in which a multiplicity of popular video files (e.g. television shows or movies) are downloaded (“pushed”) to a receiving device over a low-cost data channel and then the smaller file is either streamed in real-time if the user chooses to purchase the rights to watch the content, or is downloaded in its entirety if the user chooses to purchase the rights to permanently store the content. In another example of such an implementation, a database containing data corresponding to networks of roads, points of interest, bus schedules, restaurant reviews and other useful information could be compressed with an entropy coding technique and the resulting encoded database file could then be split into two parts using EBT such that the larger of the two parts could be transmitted using a non-real-time data caching distribution method or even embedded in an informational “App” that could be distributed for free or at low cost, while the smaller file could be transmitted rapidly on-demand to customers that pay an additional fee for the updated database functionality.
The efficient transmission bandwidth afforded using EBT files for content delivery enables users to request and download significant amounts of video content (e.g., television programs, movies, videos) that most likely exceeds the amount of time the user has to watch the content. The use of EBT files, however, provides a convenient means to structure pricing plans to meet the various degrees to which the user actually consumes the requested content.
For example, a network-connected device can be used to allow a user to view menus and schedules of available content and to request and download DTFs for selected content (e.g., television programs, movies, videos). As described above, the DTFs can be downloaded or received via broadcast. For example, a content provider or distributor such as Amazon can configure and send a personalized library of DTFs based on user requests. The corresponding BTFs are then only streamed when the user has requested to watch a particular program from the selected content. Thus, a base fee can be charged to request and store DTFs of prospective programming content, and an extra fee can be charged per real-time or near real-time consumption as BTFs are received for a program in volatile memory on a per-view basis. Finally, the user device can be configured with built-in logic to trigger a payment process to download and store a program in non-volatile memory. Multiple transmitted EBT files corresponding to the requested content can be buffered as described above to enable the user to skip among them. EBT content can therefore be decoded and enjoyed (e.g., a favorite video or song) while a user waits for another live content stream to be buffered (e.g., when the connection is too slow) for playback.
In another illustrative business model, DTFs for a particular service or application (e.g., a navigation service or data application) can be preloaded onto devices, and the devices therefore distributed with essentially a non-working data file to implement the service or application. For example, the DTFs can be for a raw database file needed to implement a service that users may or may not elect to activate when they acquire the device. In the event the user desires the service, the missing data needed to make the stored data file operational can be sent via a reduced bandwidth EBT file (e.g., BTF).
As noted above, in addition to sending audio clips via EBT that allow a series of songs, for example, to be played at a receiver, interstitials may also be sent which may be played between two songs. In addition, to perform fade-in, fade-out and cross-fading functions, a segmented attenuation mask can, for example, be sent in a packet header. For example, for each master frame, the attenuation for the 5th audio frame (mid-master frame) and the last audio frame can, for example, be transmitted in the packet header. A linear fade is applied between the end attenuation of the previous frame and the mid attenuation of the current frame. The same between mid and end attenuation for the current frame.
For the beginning of the track or channel change, an initial attenuation needs to be implied, since there is no end attenuation from the previous frame. In these cases, the following Table 2 can, for example, be used to provide implied previous end attenuations.
As noted above, in exemplary embodiments of the present invention, a set of broadcast table files can be sent over the air to receivers. The receivers may be pre-loaded with a set of decoder table files, or have otherwise stored such files, for example, via an over the air update, via a satellite communications path, or for example, via a cellular network communications path. Each of these sets of files can be organized as a library. The first one, the library of BTFs, may be stored on an uplink device ready to be sent over the air, and the other, the DTFs, stored on receivers.
Finally,
Illustrative embodiments of the present invention have been described with reference to operations at a programming center or similar content source, and receivers or other user devices. It is to be understood, however, that the present invention can also be embodied as computer-readable codes on a computer-readable recording medium. The computer-readable recording medium is any data storage device that can store data which can thereafter be read by a computer system. Examples of the computer-readable recording medium include, but are not limited to, read-only memory (ROM), random-access memory (RAM), CD-ROMs, DVDs, magnetic tapes, floppy disks, optical data storage devices. It is envisioned that aspects of the present invention can be embodied as carrier waves (such as data transmission through the Internet via wired or wireless transmission paths). The computer-readable recording medium can also be distributed over network-coupled computer systems so that the computer-readable code is stored and executed in a distributed fashion. Also, functional programs, codes, and code segments for accomplishing the present invention can be easily construed as within the scope of the invention by programmers skilled in the art to which the present invention pertains.
While the invention herein disclosed has been described by means of specific embodiments and applications thereof, numerous modifications and variations can be made thereto by those skilled in the art without departing from the scope of the invention.
This application is a continuation-in-part of PCT Patent Application No. US2012/028637, filed on Mar. 9, 2012, and published as WO 2012/122543 on Sep. 13, 2012. Additionally, priority to U.S. Provisional Patent Application Ser. No. 61/450,840, filed on Mar. 9, 2011, is claimed herein (and was claimed in PCT/US2012/028637), and that provisional application is hereby fully incorporated herein by reference. Related subject matter is disclosed and claimed in U.S. Pat. Nos. 6,834,156, 7,454,166, 7,555,020, 7,778,335 and 8,223,975, the entire contents of which are also incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 61450840 | Mar 2011 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | PCT/US2012/028637 | Mar 2012 | US |
| Child | 14021833 | US |
