Audio splitting with codec-enforced frame sizes

220482/2 prnin-CODEC maon ηιτη dp nynw wnnn

AUDIO SPLITTING WITH CODEC-ENFORCED FRAME SIZES ECHOSTAR ADVANCED TECHNOLOGIES L.L.C. C:76454 220482/2 PCT/US2010/061658 WO 2011/084823

Audio Splitting With Codec-Enforced Frame Sizes

TECHNICAL FIELD (0001 ] Embodiments of Lhe invention relate to the field of delivery of media eonlcnt over the Internet; and more specifically, to splitting the audio of media content into separate content files without introducing boundary artifacts.

BACKGROUND

[0002.] 'Die Internet is becoming a primary method for distributing media eontenL (e.g., video and audio or audio) and other information to end users. It is currently possible to download music, video, games, and other media information to computers, cell phones, and virtually any network capable device. The percentage of people accessing the Internet for media content is growing rapidly. The quality of the viewer experience is a key barrier Lo the growth of video viewing on-line. Consumer expectations for online video are set by their television and movie viewing experiences.

[()0()3] Audience numbers for streaming video on the web are rapidly growing, and there are a growing interest and demand for viewing video on the Internet. Streaming of data files or “streaming media” refers to technology that delivers sequential media content at a rale sufficient to presenL the media to a user at the originally anticipated playback speed wiLhouL significant interruption. Unlike downloaded data of a media file, streamed data may be stored in memory until Lhe data is played back and then subsequently deleLed after a specified amount of time has passed.

[0004] Streaming media content over the Internet has some challenges, as compared to regular broadcasts over the air, satellite, or cable. One concern that arises in the context of encoding audio of the media content is the introduction of boundary arlifacLs when segmenting Lhe video and audio into fixed-Lime portions. In one conventional approach, the audio is segmented into portions having a fixed-time duration that matches Lhe fixed-time duration of the corresponding video, for example, two seconds. In this approach, Lhe audio boundaries always align with the video boundaries. rDie conventional approach starts a new encode session of an audio codec to encode each audio portion for each eontenL file, for example, using Low Complexity Advanced Audio Coding (AAC LC). By using a new encode session for each portion of audio, the audio codec interprets the beginning and end of the waveform as transitions from zero, resulting in a pop or click noise in the playback of the -I- 220482/2 PCT/US20t 0/061658 WO 2011/084823 encoded portion at the portion boundaries, such as illustrated in figure 1. The pop or click noises are referred to as boundary artifacts. Also, the audio codec encodes the audio of the fixed-time duration according to a codec-enforced frame size. This also introduces boundary artifacts when the number of samples produced by the audio codec is not evenly divisible by the codec-enforced frame size. (0005] figure 1 is a diagram illustrating an exemplary audio waveform 100 for two portions of audio using a conventional approach. The audio waveform 100 illustrates the transition from zero 102 between the first and second portions of video. When the audio codec has a fixed-frame size (referred to herein as a codec-enforced frame size), the audio coded requires that the last frame 104 be padded with zeros when the number of samples of the porLion is noL evenly divisible by the number of samples per frame according to the codec-enforced frame size, for example, when using a sampling rate of 48 kHz, there are 96,000 samples generated for an audio segment of two seconds. When dividing the number of samples, 96,000, by the number of samples per frame (e.g., 1024 samples for AAC LC and 2048 samples High Efficiency AAC (HE AAC)), the result is 93.75 frames. Since the number 93.75 is not an integer, the audio codec pads the last frame 104 with zeros. In this example, the last 256 samples of the last frame are given a zero value. Although the zero values represents silent audio, the padding of the last frame with zeros results in a pop or click noise during playback of the encoded portion of audio at the portion boundaries. The transitions from zero 102 and the padded zeros in the last frame 104 introduce boundary artifacts. The introduction of boundary artifacts can decrease the overall quality of the audio, affecting the user’s experience during playback of the media content.

[00061 Another conventional approach attempts to limit the number of boundary artifacts by using portions of audio having a longer duration in order to align with frame boundaries. However, by using a larger duration porLion for the audio, the audio and video may be required to be packaged separately. This may present a drawback for streaming media content having audio and video, especially when the same media content is encoded at different quality levels, for example, as used in the context of adaptive streaming, which allows shifting between the different quality levels during playback of the media content. .9. 220482/2 PCT/US2010/061658 WO 2« Π/«84823

BRIEF DESCRIPTION OF THE DRAWINGS 100071 The invention may be best understood by referring to the following deseripLion and aecompanying drawings that are used to illustrate embodiments of the invention. In the drawings: [0008] Figure 1 is a diagram illustrating an exemplary audio waveform for two portions of audio using a eonventional approaeh.

[0009] Figure 2 is a schematic block diagram illustrating one embodiment of a computing environment in which an encoder of the present embodiments may be employed.

[001 Oj Figure 3A is a schematic block diagram illustrating another embodiment of a computing environment in which an encoding system, including multiple hosts each employing the encoder of Figure 2, may be employed. (00111 Figure 3B is a schematic block diagram illustrating one embodiment of parallel encoding of streamlets according to one embodiment. 1.0012j Figure 4 is a flow diagram of one embodiment of a method of encoding audio of media content according to codec-enforced frame sizes for splitting full audio frames between content Files having fixed-time video portion of the media content.

[0013] Figures 5A-5C are flow diagrams of one embodiment of generating content Files with fixed-time video porLions and full audio frames having codec-enforced frame sizes. [0014) Figure 6Λ is a diagrammatic representation of audio portions, video portions, and streamlets according to one embodiment of audio splitting.

[0015] Figure 6B is a diagram illustrating one embodiment of an audio waveform for four porLions of audio using audio splitting. 10016] Figure 7 illustrates a diagrammatic representation of a machine in the exemplary form of a computer system for audio splitting according to one embodiment.

DETAILED DESCRIPTION (00171 A method and apparatus for splitting the audio of media content into separate content Oles without introducing boundary artifacts is described. In one embodiment, a meLhod, implemented by a computing system programmed to perform operations, includes receiving media content including audio and video, encoding the video according to a frame rate, encoding the audio according to a codec-enforced frame size (i.e., fixed frame size), and generating content Hies, each of the content files includes an encoded portion of the video -3- 220482/2 PCT/US2010/061658 WO 2011/084823 having a fixed-time duration and an encoded portion of the audio having full audio frames having the codec-enforced frame size. In one embodiment, the last of the audio frames is not padded with zeros as done conventionally.

[0018] Embodiments of the present invention provide an improved approach to streaming audio. Unlike the conventional approaches that use a new encoding session for each portion of audio of the media content, the embodiments described herein allow the media content Lo be segmented into small portions without introducing boundary artifacts. The embodiments described herein segment the audio using full audio frames. When the audio is staged for playback, the audio is presented lo the decoder as a single stream, rather than many small segments having boundary artifacts. In the embodiments described herein, Lhe encoder becomes aware of Lhe codec frame size (e.g., 1024 samples for AAC-LC or 2048 samples for HE A AC) and how many audio frames are produced with each invocation of Lhe codec. The encoder storage as many audio frames that can fit into an encoded streamlet (i.e., a content file), which has a portion of the video based on a fixed-time duration. Rather than padding the last audio frame with zeros, a full frame of the next portion of audio is encoded and added to the current streamlet. This results in a small amount of audio that would otherwise be in Lhe subsequent streamlet being written instead to the current streamlet. The subsequent streamlet is then given a Lime offset for Lhe audio stream to indicate a gap, so that the audio can be presented to the decoder as a continuous stream when played back. This same amount of time is deducted from the target duration of the audio for this streamlet, if the end of the audio of this subsequent streamlet does not fall on a frame boundary, then audio is again borrowed from Lhe subsequent streamlet Lo fill the final frame. This process repeats until the end of the stream of Lhe media content is reached. 'Hie gaps inserted at the beginning of streamlets where audio is borrowed may be eliminated when the audio portions of Lhe streamlcLs are staged prior to decode and playback. When seeking to a random streamleL, silent audio may played for the duration of Lhe gap in order to maintain audio/video synchronization.

[00191 The embodiments of audio splitting as described herein provide the ability to encode Lhe audio of Lhe media content using audio codecs with large codec-enforced frame sizes (AAC, AC3, etc.) without introducing boundary arLifacts while still maintaining Lhe same fixed-time duration for Lhe video. -4- 220482/2 PCT/US2010/061658 WO 2011/084823 [0020J In the following description, numerous details are set forth. It will be apparent, however, to one of ordinary skill in the art having the benefit of this disclosure, Lhat embodiments of the present invention may be practiced without these specific details. In some instances, well-known structures and devices arc shown in block diagram form, rather than in detail, in order to avoid obscuring the embodiments of Lhe present invention.

[0021 ] Some portions of the detailed description that follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations arc Lhe means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading Lo a desired result. rfhe steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take Lhe form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. IL has proven convenient at times, principally for reasons of common usage, Lo refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0()22] IL should be borne in mind, however, that all oflhese and similar terms are to be associated with Lhe appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically slated otherwise as apparent from Lhe following discussion, it is appreciated lhat throughout the description, discussions utilizing terms such as “receiving,” “encoding,” “generating,” “splitting,” “processing,” “computing,” “calculating,” “determining,” “displaying,” or the like, refer to the actions and processes of a computer system, or similar electronic computing systems, that manipulates and transforms data represented as physical (e.g., electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices. 100231 Embodiments of Lhe present invention also relate Lo an apparatus for performing Lhe operations herein. This apparatus may be specially constructed for Lhe required purposes, or it may comprise a general-purpose computer system specifically programmed by a computer program stored in the computer system. Such a computer program may be stored in a -5- 220482/2 PCT/US20111/061658 WO 2011/084823 computer-readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions. 10024] The term “encoded streamlet,” as used herein, refers to a single encoded representation of a portion of the media content. Each streamlet may be an individual content file that includes a portion of the media, and may be encapsulated as an independent media object, allowing the streamlet to be cached individually and to be independently rcqueslable and independently playable by a media player. These individual files are also referred to herein as QSS Hies. In one embodiment, a streamlet is a static file that can be served by a non-specialized server, instead of a specialized media server. In one embodiment, Lhe media content in a streamlet may have a predetermined length of playback time (also referred to as the fixed-time duration). The predetermined length of time may be in the range of between about approximately 0.1 and 8.0 seconds, for example.

Alternatively, other predetermined lengths may be used. The media content in the streamlet may have a unique time index in relation to the beginning of the media content contained in a stream. The filename may include part of the time index. Alternatively, the streamleLs may be divided according Lo a file size, instead of a time index. The term “stream,” as used herein, may refer to a collection of streamlets of the media content encoded by the same video quality profile, for example, portions of the video that have been encoded aL the same video bit rate. The stream represents a copy of the original media content. The streamlets may be stored as separate files on any one or more of content servers, web servers, cache servers, proxy caches, or other devices on the network, such as found in a content delivery network (CDN). The separate files (e.g., streamlets) may be requested by the client device from the web server using ΙΤΓΓΡ. Using a standard protocol, such as ΙΤΓΓΡ, eliminates the need for neLwork administrators to configure firewalls to recognize and pass through network traffic for a new, specialized protocol, such as Real Time Streaming Protocol (RTSP). Additionally, since the media player initiates the request, a web server, for example, is only required to retrieve and serve the requested streamlet, not the entire sLream. The media player may also retrieve streamlets from more than one web server. These web servers may be without specialized server-side intelligence Lo retrieve the requested portions. In another -6- 220482/2 PCT/US2010/061658 WO 2011/084823 embodiment, the streamlets are stored as separate files on a eaehe server of a network infrastructure operator (e.g., an ISP), or other components of a CDN. Although some of the present embodiments describe Lhc use of streamlets, the embodiments described herein are not limited to use in computing systems that use streamlets, but may also be implemented in other systems that use other techniques for delivering live media content over the Internet.

For example, in another embodiment, the media content is stored in a single 111c that is divided into portions that can be requested using Ι-ΓΓΓΡ range requests and cached in the CDN. 100251 There are two general types of media streaming, namely push-based streaming and pull-based streaming. Push technology describes a method of Internet-based communication where the server, such as a publisher’s content server, initiates the request for a given transaction. Pull technology, in contrast, describes a method of Internet-based communication where the request for transmission of information is initiated by Lhe client device, and then is responded to by the server. One type of request in pull technology is a Ι-ΓΓΓΡ request (e.g., ΙΤΓΓΡ GET request). In contrast, in push-based technology, typically a specialized server uses specialized protocol, such as RTSP to push the data to the client device. Alternatively, some push-based technologies may use ΙΤΓΓΡ to deliver the media content. In pull-based technology, a CDN may be used to deliver the media to multiple client devices.

[00261 II should be noted that alLhough various embodiments described herein are directed to a pull-based model, Lhe embodiments may be implemented in other configurations, such as a push-based configuration. In Lhc push-based configuration, the embodiments of audio splitting by Lhe encoder can be done in a similar manner as the pull-based configuration described with respect to Figure 2, and the encoded content filc(s) can be stored on a conLent server, such as a media server to deliver the media content to the client device for playback using push-based technologies. IL should also be noted that these embodiments can be used to provide different quality levels of the media content, and allow switching between the different quality levels, commonly referred to as adaptive streaming. One difference may be that, in the push-based model, the media server determines which content file(s) to send to the client device, whereas in the pull-based model, the client device determines which conLent file(s) to requesL from the content server. -7- 220482/2 PCT/US2010/061658 WO 2011/084823 [0027 J Figure 2 is a schematic block diagram illustrating one embodiment of a computing environment 200 in which an encoder 220 of the present embodiments may be employed, lhe computing environment 200 includes a source 205, the encoder 220, an origin content server 210 (also referred to as a media server or origin server) of a content delivery network 240, and media players 200, each operating on a client device 204. The content server 210, encoder 220, and client devices 204 may be coupled by a data communications network. The data communications network may include the InterncL. Alternatively, the conLenl server 210, encoder 220, and client devices 204 may be located on a common Local Area Network (LAN), Personal area network (PAN), Campus Area Network (CAN), Metropolitan area network (MAN), Wide area network (WAN), wireless local area network, cellular network, virtual local area network, or the like. The client device 204 may be a client workstation, a server, a computer, a portable electronic device, an entertainment system configured to communicate over a network, such as a set-lop box, a digital receiver, a digital television, or other electronic devices. For example, portable electronic devices may include, but are not limited to, cellular phones, portable gaming systems, porLable computing devices, or the like. rfhe client device 204 may have access to the InterncL via a firewall, a router, or other packet switching devices.

[0028) hi the depicted embodiment, the source 205 may be a publisher server or a publisher content repository. The source 205 may be a creator or distributor of media content. Tor example, if the media content to be streamed is a broadcast of a television program, the source 205 may be a server of a television or cable network channel such as the ABC© channel, or the MTV® channel. The publisher may transfer the media content over the Internet to the encoder 220, which may be configured to receive and process the media content and store the content file(s) of the media content in the origin content server 210. In one embodiment, the content server 210 delivers the media content to the client device 204, which is configured to play the content on a media player that is operating on the client device 204. The content server 210 delivers the media conLenL by streaming Lhe media content Lo Lhe client device 204. In a further embodiment, the clienl device 204 is configured to receive different portions of the media content from multiple locations simultaneously or concurrently as described in more detail below. -8- 220482/2 PCT/US2010/061658 WO 2011/084823 [00291 Media content stored at the content server 210 may be replicated to other web servers; or alternatively, to proxy cache servers of the CDN 240. Replicating may occur by deliberate forwarding from the content server 210, or by a web, cache, or proxy server outside of Lhe content server 210 asking for conLcnt on behalf of the client device 204. For example, the client device 204 may request and receive content from any of the multiple web servers, edge caches, or proxy cache servers. In the depicted embodiment, the web servers, proxy caches, edge caches, and content server 210 are organized in a hierarchy of the CDN 240 to deliver the media content to the client device 204. Λ CDN is a system of computers networked together across the Internet that cooperates transparently to deliver content, and may include, for example, one or more origin content servers, web servers, cache servers, edge servers, etc. Typically, the CDN is configured in a hierarchy so that a client device requests the data from an edge cache, for example, and if the edge cache does not contain the requested data, the request is sent to a parent cache, and so on up to the origin content server. rlTie CDN may also include interconnected compuLer neLworks or nodes Lo deliver the media content. Some examples of CDNs would be CDNs developed by Akamai Technologies, Levcl3 Communications, or Limelight Networks. Alternatively, other types of CDNs may be used. In other embodiments, the origin conLenl server 210 may deliver the media content Lo the client devices 204 using other configurations as would be appreciated by one of ordinary skill in Lhe arL having the benefit of this disclosure. (00301 In one embodiment, the publisher stores the media content in an original content file to be distributed from the source 205. The content file may include data corresponding lo video and/or audio corresponding to a television broadcast, sporting event, movie, music, concert, or the like. The original content file may include uncompressed video and audio; or alternatively, uncompressed video or audio. Alternatively, the content Hie may include compressed content (e.g., video and/or audio) using standard or proprietary encoding schemes. The original content Hie from the source 205 may be digital in form and may include media content having a high bit rate, such as, for example, approximately 5 Mbps or greater. 100311 In the depicted embodiment, the encoder 220 receives the original media content 231 from Lhe source 205, for example, by receiving an original content file, a signal from a direct feed of the live evenL broadcast, a stream of the live television event broadcast, or the -9- 220482/2 like. The encoder 220 maybe implemented on one or more machines including one or moreserver computers, gateways or other computing devices. In one embodiment, the encoder220 receives the original media content 231 as one or more content files from a publishingsystem (not illustrated) (e.g., publisher's server or publisher's content repository).Alternatively, the encoder 220 receives the original media content 231 as it is captured. Forexample, the encoder 220 may receive a direct feed of the live television broadcast, such as acaptured broadcast, in the form of a stream or a signal. The original media content 231 maybe captured by a capture card, configured for television and/or video capture, such as, forexample, the DRC-2600 capture card, available from Digital Rapids of Ontario, Canada.Alternatively, any capture card capable of capturing audio and video may be utilized with thepresent invention. The capture card may be located on the same server as the encoder oralternatively, on a separate server. The original media content 231 may be a capturedbroadcast, such as broadcast that is being simultaneously broadcasted over the air, cable,and/or satellite, or a pre-recorded broadcast that is scheduled to be played at a specific pointin time according to a schedule of a live event. The encoder 220 may utilize encodingschemes such as DivX® codec, Windows Media Video 9® series codec, Sorenson Video® 3video codec, TrueMotion VP7 codec from On2 Technologies®, MPEG-4 video codecs, H.263 video codec, RealVideo 10 codec, OGG Vorbis, MP3, or the like. Alternatively, acustom encoding scheme may be employed. [0032] In another embodiment, the encoder 220 receives the original media content 231 asportions of video and audio of fixed time durations, for example, two-second chunks (referred to herein as portions of the media content). The two-second chunks may includeraw audio and raw video. Alternatively, the two-second chunks may be encoded audio andraw video. In such cases, the encoder 220 decompresses the media content. In anotherembodiment, the encoder 220 receives the original media content 231 as multiple rawstreamlets, each raw streamlet containing a fixed-time portion of the media content (e.g.,multiple two-second raw streamlets containing raw audio and video). As used herein, theterm "raw streamlet" refers to a streamlet that is uncompressed or lightly compressed tosubstantially reduce size with no significant loss in quality. A lightly compressed rawstreamlet can be transmitted more quickly. In another embodiment, the encoder220 receives -10- 220482/2 PCT/US2010/061658 WO 2011/084823 the original media content 231 as a sLream or signal and segmenLs the media content into fixed-lime portions of the media content, such as raw streamlets.

[0033] In the depicted embodiment, Lhc encoder 220 includes a splitter 222, a fixed-frame audio encoder 224, an audio frame buffer 225, a fixed-time video encoder 226, a video frame buffer 227, and an audio splitting multiplexer 228. rfhc splitter 222 receives the original media content 231, for example, as a continuous stream of audio and video, and splits the media content 231 into raw audio 233 and raw video 235. In one embodiment, the fixed-frame audio encoder 224 is an audio codec. In one embodiment, the splitter 222 splits the continuous stream of audio and video inLo Lwo-second chunks of audio and video. A codec (also referred Lo as compressor-decompressor or coder-decoder) is a device or computer program capable of encoding and/or decoding a digital data stream or signal. In one embodiment, the fixed-frame audio codec 224 is software executed by one or more computing devices of the encoder 220 to encode the raw audio 233. Alternatively, the fixed-frame audio codec 224 may be hardware logic used to encode the raw audio 233. In particular, the fixed-frame audio encoder 224 receives the raw audio 233 and encodes the audio according to a codec-enforced frame size, for example, 1024 samples for AAC-LC or 2048 samples for LIE AAC. The fixed-frame audio encoder 224 outputs Lhe encoded audio frames 237 Lo the audio frame buffer 225. Similarly, Lhe fixed-time video encoder 226 receives the raw video 235 from the splitter 220, but encodes the video according to fixed-time durations, for example, 60 frames every lwo-second (30 frames per second (fps)). The fixed-time video encoder 226 outpuLs the encoded video frames 239 lo the video frame buffer 227. In one embodiment, the fixed-time video codec 226 is software executed by one or more computing devices of the encoder 220 lo encode the raw video 235. Alternatively, the fixedtime video codec 226 may be hardware logic used to encode Lhe raw video 235.

[0034) The audio-splitting multiplexer 228 generates encoded media content files 232 (referred to herein as QSS files) using the encoded audio frames 237 and the encoded video frames 239. As described above, the conventional encoder generates a content file with a portion of video and a portion of audio, each being a fixed-time duration, where the last frame of audio is padded with zeros because the number of samples of the portion are not evenly divisible by Lhe number of samples per frame according to the codec-enforced frame size used by the audio codec. Unlike the conventional encoder that pads the last frame, the -11- 220482/2 PCT/US2010/061658 WO 2011/084823 audio-splitLing multiplexer 228 uses lull audio frames to generate content files that have a fixed-Lime video portion and an audio portion that has full audio frames having the codec-enforced frame sizes. Since the audio-splitting multiplexer 228 uses full audio frames to fill the content files 232, the audio-splitting multiplexer 228 does not pad the last few samples of the frame as zeros as done conventionally, but rather encodes a subsequent portion of the audio in order Lo add a full frame to the current content file 232.

[0035J In one embodiment, the audio-splitting multiplexer 228 tracks a sample offset that represents the amount of samples used from the subsequent portion in order to determine how many frames to use for the subsequent content file. The audio-splitting multiplexer 228 also Lraeks a presentation offset that indicates a gap in audio playback. Since samples Lhat would have otherwise been played back as part of the subsequent content file are part of the current content file, the presentation offset of the subsequent contenL file indicates the gap in audio playback so that the audio portions of the current and subsequent content files arc presented to the decoder as a continuous stream. In essence, during playback of the audio, the gaps inserted at the beginning of the contenL files may be eliminated when the audio portions of the content files are staged prior to decode and playback. 'ITre presentation offset allows the audio Lo be presented to the decoder as a continuous stream rather than many small segments having boundary artifacts. In one embodiment when seeking Lo a random portion of the video, silent audio may be played for the duration of the gap in order to maintain audio/vidco synchronization.

[00361 In one embodiment, the audio-splitting multiplexer 228 generates a first content file by filling the first content file wiLh a first video portion (e.g., 60 frames) having a fixed-time duration (e.g., 2 seconds), and a first audio portion having a number of buffered, full audio frames. The duration oflhe buffered audio frames is greater than the fixed-time duration. [0037.1 In one embodiment, the audio-splitting multiplexer 228 generates the content files 232 by determining a number of encoded audio frames 237 needed to fill the current contenL file. In one embodiment, the number of frames is the smallest integer that is not less than a number of samples needed Lo fill the current contenL files divided by the codec-enforced frame size (e.g., samples per frame). In one embodiment, this number can be calculated using a ceiling function that maps a real number to the next largest integer, for example, -12- 220482/2 ceiling(x) = [x] is the smallest integer not less than x. One example of the ceiling function isrepresented in the following expression(l): ceil ((samplesPerStreamlet - offsetSamples]/sampIesPerFrame] (1) Alternatively, other equations may be used.

[0038] The audio-splitting multiplexer 228 determines if there are enough of the encodedaudio frames 237 in the audio frame buffer 225 to fill a current content file. If there areenough encoded frames buffered, the audio-splitting multiplexer 228 fills the current contentfile with the determined number of frames. If there are not enough encoded frames buffered,the audio-splitting multiplexer 228 waits until there are enough encoded frames stored in thebuffer 225, and fills the current content file with the determined number of encoded framesstored in the buffer 225. Inone embodiment, the audio-splitting multiplexer 228 determinesif there is enough encoded frames buffered by 1) multiplying the number of buffered framesby the samples per frame, 2) adding a sample offset, if any, from a previous content file tothe product of the multiplication, and 3) determining if the sum is greater than or equal to anumber of samples needed to fill the current content file. One example of this operation isrepresented in the following equation (2): numBufferedFrames * samplesPerFrame + offsetSamples >= samplesPerStreamlet (2) [0039] The audio-splitting multiplexer 228 determines a sample offset, if any, for asubsequent content file. In one embodiment, the audio-splitting multiplexer 228 determinesthe sample offset by multiplying the number of the encoded frames by the codec-enforcedframe size (i.e., samples per frame], minus the number of samples needed to fill the current content file and plus the sample offset, if any, from a previous content file. One example thisoperation is represented in the following equations (3] and (4): offsetSamples= framesToSend * samplesPerFrame - samplesPerStreamlet-offsetSamples (3] where framesToSend = ceil((samplesPerStream!et- offsetSamples]/samplesPerFrame] (4] [0040] In another embodiment, the audio-splitting multiplexer 228 generates the contentfiles 221 by calculating a number of samples needed (e.g., 96,000] to fill a current contentfile. The audio-splitting multiplexer 228 calculates a number of frames (e.g., 93 frames for a48K sampling rate for two second portions] needed for the current content file, and adds a frame to the number of frames (e.g., totaling 94 frames] when the number of samples dividedby the samples per frame is not equally divisible. In effect this rounds up the number of -13- 220482/2 PCT/US2010/061658 WO 2011/084823 frames Lo Lhe nexL largest integer. The audio-spliLLing multiplexer 228 fills Lhe current content file with Lhe rounded number of frames.

[00411 In another embodiment, the audio-splitting multiplexer 228 generates the contcnL files 221 by calculating a number of samples needed (e.g., 96,000) to fill a current content file by multiplying the sampling rate (e.g., 48K) by the duration of fixed-time duraLion (e.g., 2 sec), 'Lhe audio-spliLting multiplexer 228 calculates a number of frames needed for the current content Hie by dividing Lhe number of samples by the codec-enforced frame size (e.g., 1024 samples per frame). If the remainder of the division is zero, the audio-splitting multiplexer 228 fills the current conLcnt file with the number of frames. However, if the remainder of the division is greater than zero, the audio-splitting multiplexer 228 increments the number of frames by one and fills the current content file with the incremented number of frames.

[0042] In a further embodiment, the audio-splitLing multiplexer 228 generates the contcnL Hies 221 by multiplying Lhe number of frames by the codec-enforced frame size to convert back to the number of samples needed to fill the current content 111c, and calculating a duration of the audio of Lhe current content file by dividing Lhe number of samples by the sampling rale (e.g., StreamletDuralion = samplesPerSLreamlet / sampling rale). The audio-splitting multiplexer 228 determines a presentation offset for a subsequent content file by subtracting the duration from Lhe fixed-time duration. The audio-splitting multiplexer 228 updates Lhe sample offset for Lhe subsequent content file by multiplying the number of frames by the codec-enforced frame size minus Lhe number of samples used to fill the currcnL content Hie and plus the sample offset, if any, from a previous content Hie (e.g., equaLion (3)).

[0043J Referring back to figure 2, in one embodiment, when the splitter 222 receives the original media contcnL 231 as raw streamlets, the splitter 222 receives HrsL and second raw streamlets and splits Lhe audio and the video of the first and second raw streamlets. 'The Hxed-timc video encoder 226 encodes Lhe video of the first and second raw sLreamlels, and audio-splitting multiplexer 228 stores Lhe encoded video of the first raw streamlet in a Hrst content IIle and the encoded video of the second raw sLreamlcl in a second content file. The fixed-frame audio encoder 224 encodes the audio of the Hrst raw streamlet into a first set of audio frames and stores Lhe Hrst set in the audio frame buffer 225. The audio-splitting -14- 220482/2 PCT/US2010/061658 WO 2011/084823 multiplexer 228 determines if there are enough buffered frames to fill the first eontent file. If not, the fixed-frame audio encoder 224 encodes the audio of the second raw streamlet into a second set of audio frames and sLores the second set in the audio frame buffer 225. When there are enough buffered frames (in some eases when one more full frame is stored in the buffer 225) to fill the first content file, the audio-splitting multiplexer 228 stores the buffered audio frames into the firsL content file. The encoder 220 continues this process until the media content ends. 10044) Also, since the audio-splitting multiplexer 228 uses full audio frames, the audio frames in one content file 232 do noL necessarily align with the video portion boundaries as illustrated in Figures 6Λ and 6B. For example, the duration of the audio portion of the conLent File 232 may be 2.0053 seconds, while the fixed-time duration of the video portion of the conLent file 232 may be 2.00 seconds. In this example, the codec-enforced frame size is 1024 samples per frame and the sampling rate of Lhe audio is 48K, and there are 96256 samples of 94 frames stored in Lhe audio portion stored in the content file 232. Since there is an extra 53 milliseconds (ms) in the content file 232, the audio-splitting multiplexer 228 gives Lhe next content File a presentation offset of 53 ms because the current content file 232 uses samples having a duration of 53 ms that would have otherwise been in the nexL content file when using a fixed-time duration audio encoding scheme. The audio-splitting multiplexer 228 also tracks the sample offset to determine how many audio frames are needed to fill the nexL conLent file. In one embodiment, the audio-splitting multiplexer 228 1111s each of Lhe conLent files with one the encoded video portions having the Hxcd-time duration (e.g., 2 seconds for 60 video frames when the frame rate is 30 frames per second). The audio-splitting multiplexer 228 fills some of the content files wiLh a number of buffered audio frames whose duration may be greater than the fixed-time duration, less than the fixed-time duration, or equal to the fixed-time duration, dependent upon whether the audio frames align with Lhe video portion boundaries as determined by the audio-splitting multiplexer 228. [0045] With reference to Figure 6Λ, in one embodiment, the audio-splitting multiplexer 228 generates a llrsL streamlet (i.e. content file) 601 by filling the first streamlet 601 wiLh a first video portion 611, having approximately sixLy video frames whose duration is equal to the fixed-time duration of two seconds, and wiLh a first audio portion 621 having nincLy-four audio frames, each having 1024 samples per frame, totaling 96,256 samples. The duration of -15- 220482/2 the first audio portion 621 is approximately 2.0053 seconds. The audio-splitting multiplexer228 determines that the presentation offset of the first audio portion 621of the first streamlet603 is zero, since the audio and video boundaries 652 and 654 of the first streamlet 601 are aligned for playback.

[0046] The audio-splitting multiplexer 228 generates a second streamlet 602by filling thesecond streamlet 602 with a second video portion 612 (60 frames and two seconds), and witha second audio portion 622having ninety-four audio frames. The duration of the secondaudio portion 622 is approximately 2.0053 seconds. The audio-splitting multiplexer 228 determines that the presentation offset of the second audio portion 622of the secondstreamlet 602 is approximately 5.3 milliseconds (ms), since the duration of the first audioportion 621 of the first streamlet 601 is approximately 2.0053 seconds. The presentationoffset indicates a gap in the audio between the first and second streamlets 601 and 602. Asshown in Figure 6B, audio and video boundaries 652 and 654 of the second streamlet 602 arenot aligned for playback. The presentation offset can be used to allow the audio portions ofthe first and second streamlets 601 and 602 to be staged for presentation to the decoder as acontinuous stream.

[0047] The audio-splitting multiplexer 228 generates a third streamlet 603 by filling thethird streamlet 603 with a third video portion 613 (60 frames and two seconds), and with athird audio portion 623 having ninety-four audio frames. The duration of the third audioportion 623 is approximately 2.0053 seconds. The audio-splitting multiplexer 228 determines that the presentation offset of the third audio portion 62 3 of the third streamlet603 is approximately 10.66 ms, since the duration of the second audio portion 622 of thesecond streamlet 602 is approximately 2.0053 seconds. The presentation offset indicates a gap in the audio between the second and third streamlets 602 and 603. As shown in Figure6B, audio and video boundaries 652 and 654 of the third streamlet 603 are not aligned forplayback. The presentation offset can be used to allow the audio portions of the second andthird streamlets 602 and 603 to be staged for presentation to the decoder as a continuousstream.

[0048] The audio-splitting multiplexer 228 generates a fourth streamlet 604 by filling the fourth streamlet 604 with a fourth video portion 614 (60 frames and two seconds), and with afourth audio portion 624 having ninety-three audio frames. The duration of the fourth audio -16- 220482/2 portion 624 is approximately 1.984 seconds. The audio-splitting multiplexer 228 determinesthat the presentation offset of the fourth audio portion624of the fourth streamlet 604 isapproximately 16 ms, since the duration of the third audio portion 623 of the third streamlet603 is approximately 2.0053 seconds. The presentation offset indicates a gap in the audiobetween the third and fourth streamlets 603 and 604. As shown in Figure 6B, audio andvideo boundaries 652 and 654 of the fourth streamlet 603 are not aligned for playback. The presentation offset can be used to allow the audio portions of the third and fourth streamlets603 and 604 to be staged for presentation to the decoder as a continuous stream. After thefourth streamlet 604, however, the audio and video boundaries 652 and 654 are aligned,meaning the fifth streamlet (not illustrated) will have a presentation offset of zero. It shouldbe noted that the embodiments of Figures 6A and 6B assume that the sampling rate is 48kHz, the fixedtime duration is two seconds, and the codec-enforced frame size is 1024samples per frame.

[0049] In the embodiments described above, the audio portions of the first three streamlets601-603 have ninety-four audio frames, and the audio portion of a fourth streamlet 604 hasninety-three audio frames. In this embodiment, each of the video portions of the four content files 601-604 has approximately sixty video frames when the video is encoded at thirty frames per second. This pattern repeats until the end of the media content has been reached.lt should be noted that in this embodiment, after every fourth content file, the presentationoffset and sample offset are zero, meaning the audio boundaries 652 and video boundaries654 align after every fourth content file. [0050] As can be seen in Figure 6B, after eight seconds of media content, the video andaudio boundaries align. As such, another approach to decreasing boundary artifact frequencyand to align AAC frame sizes would be to use eight seconds for the fixed-time duration.However, such approach has the following disadvantages: 1) This approach requires largechunk sizes of video, such as 8,16, or 32 seconds. 2) This approach ties the implementationto a specific frame size, i.e., 1024 samples per frame. If the frame size were to change, suchas to 2048, for example, this approach would have to switch to an audio codec with adifferent frame size, and would also have to change the chunk duration of the video. 3) Thisapproach requires the audio sample rate to always be 48 kHz. Other common sample rates, such as 44.1 kHz, would require a different and potentially much larger chunk size. -17- 220482/2 PCT/US2010/061658 WO 2011/084823

Alternatively, Lhe source audio would have to be up-sampled to 48kHz. The up-sampling, however, may introduee artifacts and may reduce the efficiency of the audio codec. The embodiments described herein, however, have the ability to encode using audio codec’s with large frame sizes (AAC, AC3, etc) without introducing chunk boundary artifacts while still maintaining Lhe same chunk duraLion.

[0051] Alternatively, other sampling rales (c.g., 44.1 kHz), fixed-time durations (c.g., 0.1 -5.0 seconds), video frame rates (e.g., 24 fps, 30lps, etc), and/or codec-enforced frame sizes (c.g., 2048) may be used. Different source videos use different frame rales. Most over-the-air signals in the U-S. are 30 frames per second (29.97, actually). Some HD signals are 60 frames per second (59.94). Some of the file-based content is 24 frames per second. In one embodiment, the encoder 220 does not increase the frame rale of the video because doing so would require the encoder 220 to generate additional frames. However, generating additional frames does not provide much bene lit for this additional burden. So, for example, if the original media content has a frame rate of 24 fps, the encoder 220 uses a frame rale of 24 fps, instead of up-sampling to 30 fps. However, in some embodiments, the encoder 220 may down-sample the frame rate, for example, if the original media content has a frame rale of 60 fps, the encoder 220 may down-sample to 30 fps. lliis may be done because using 60 fps doubles the amount of data needed to be encoded at Lhe target bit rate, which may make Lhe quality suffer. In one embodiment, once the encoder 220 determines the frame rate that will be received or after down-sampling (generally 30 fps or 24 fps), the encoder 220 uses this frame rate for most of Lhe quality profiles. Some of Lhe quality profiles, such as the lowest quality profile, may use a lower frame rate. However, in other embodiments, the encoder 220 may use different frame rates for the different quality profiles, such as to target mobile phones and other devices with limited resources, such as less computational power. In these cases, it may be advantageous to have more profiles with lower frame rates.

[00521 It should be noted that when using other values for these parameters, the audio boundaries 652 and the video boundaries 654 may differ from the illustrated embodiment of Figure 6B. For example, when using 44.1 kHz sampling rale, 1024 codec-enforced frame size and two seconds for the fixed-time duration, the audio portion of the first content 1'ile will have eighty-seven audio frames, and the second thru seventh content files will have eight-six audio frames. This pattern repeals itself until there is not enough video remaining -18- 220482/2 PCT/US2010/061658 WO 2011/084823 in the media conlcnl. Il should be noLed thaL in this embodiment, after every 128 eontenl files, the presentation offset and sample offset are zero, meaning the audio boundaries 652 and video boundaries 654 align after every 128th eontenL file, as illustrated in the abbreviated Table l-l.

Table 1-1

Streamlet offset frames samples 1 0 87 89088 2 888 86 88064 3 752 86 88064 4 616 86 88064 5 480 86 88064 6 344 86 88064 7 208 86 88064 8 72 87 89088 9 960 86 88064 10 824 86 88064 11 688 86 88064 12 552 86 88064 13 416 86 88064 14 280 86 88064 15 144 86 88064 16 8 87 89088 17 896 86 88064 18 760 86 88064 19 624 86 88064 20 488 86 88064 124 680 86 88064 125 544 86 88064 126 408 86 88064 127 272 86 88064 128 136 86 88064 129 0 87 89088

It should be noted that Lhc sample offset in the above table is illustrated in units of samples, not seeonds or milliseeonds for ease of illustration. To eonvert Lhe sample offset to the presentation offset, the sample offset can be divided by 44,100 to get the presentation offset in seeonds, and multiplied by 1,000 Lo gel the presentation offset in milliseconds. In one embodiment, Lhe presentation offset in milliseconds can be stored in the streamlet header. -19- 220482/2 PCT/US2010/061658 WO 2011/084823

Alternatively,' Lhe presentation offset or the sample offset ean be stored in the streamlet header in other units.

[0053J In another embodiment, the audio-splitting multiplexer 228 generates the eneoded conLenl Hies 232 by filling caeh of the eontent files 232 with the eneoded video frames 239 having a fixed-time duration (e.g., a fixed-time duration portion), and fills Lhe content files 232 with a number of full audio frames 237 wiLh the duration of the audio frames 237 being less than or greater than the fixed-lime duration to accommodate the full audio frames being used in the eontent files 232. For example, a first content file can be filled with a portion of the video having Lhe fixed-time duration, such as two seconds, and with an audio portion having multiple full audio frames having a duraLion that is greater than the fixed-time duration. Eventually, the sample offset will be big enough that less audio frames can be used, in which case the duration of the audio frames may be less than the fixed-time duration. At times, the audio boundary of the audio may match the video boundary of the video.

[0054) In another embodiment, the audio-splitting multiplexer 228 generates the eneoded content files 232 by generating a first content file having the video frames of a first portion of video and audio frames from the first portion of the audio and an audio frame from a second portion. The audio-splitting multiplexer 228 generates a second content file having the video frames of a second portion of Lhe video. For Lhe audio, the audio-splitting multiplexer 228 determines if Lhe audio boundary falls on the video boundary. If the audio boundary falls on the video boundary, the audio-splitting multiplexer 228 fills the second content file with the remaining audio frames of the second portion. However, if Lhe audio boundary does not fall on the video boundary, the audio-splitting multiplexer 228 encodes an audio frame of a third portion of Lhe media content, and fills the second eontent file with the remaining audio frames of the second portion and the audio frame from the third portion. TTiis process repeals until the end of the media content is reached.

[00551 Referring back to Figure 2, once the encoder 220 encodes the original media conlenl 231, the encoder 220 sends Lhe encoded media content files 232 to the origin content server 210, which delivers the encoded media content 232 to Lhe media player 200 over the network connections 241. When a media player 200 receives the content files having the fixed-time duration of video and the variable-time duration of audio, the media player 200 uses the presentation offset of the content files to stage the audio to be presented to a decoder -20- 220482/2 PCT/US2010/06I658 WO 2011/084823 as a continuous stream, eliminating or reducing the pop or click noises presented by boundary artifacts. In essence, during playback of the audio, the media player 2U0 removes the gaps inserted at the beginning of the content flics when Lhe audio portions of the content files are staged prior to decode and playback. In another embodiment, if the audio splitting, as described herein, is not performed and the last frame is padded with zeros, the media player 200 may be configured to remove the padded samples of Lhe last frame before sending the audio to the decoder. However, this approach may noL be practical in certain situations, for example, when the media player is provided by a third-party or when access to the data of the audio frames after decoding is restricted.

[0056J b should be noLed Lhat, although one line has been illustrated for each media player 200, each line 241 may represent multiple network connections to the CON 240. In one embodiment, each media player 200 may establish multiple Transport Control Protocol (TCP) connections to the CON 240. In another embodiment, the media contenL is stored in multiple CONs, for example, stored in the origin servers associated with each of the multiple CON. The CON 240 may be used for the purpose of improving performance, scalability, and cost efficiency to the end users (e.g., viewers) by reducing bandwidth costs and increasing global availability of content. CONs may be implemented in various manners, and the details regarding their operation would be appreciated by one of ordinary skill in Lhe art. As such, additional details regarding Lheir operation have not been included. In other embodiments, other delivery techniques may be used to deliver the media content to the media players from Lhe origin servers, such as peer-to-peer networks, or the like. 100571 In the embodiments described above, the content files 232 represent one copy of the original media content sLream 231. However, in other embodiments, each portion of the original media content 231 may be encoded into multiple encoded representation of the same porLion of content. The multiple encoded representations may be encoded according to different quality profiles and stored as separate files thaL arc independently requeslable and independently playable by the client device 204. Each of the files may be stored in one or more contenL servers 210, on the web servers, proxy caches, edge caches of the CDN 240, and may be separately requested and delivered Lo Lhe client device 204. In one embodiment, the encoder 220 simultaneously encodes the original content media 231 aL several different quality levels, for example, ten or thirteen such levels. Each quality level is referred to as a -21- 220482/2 PCT/US2010/061658 WO 2011/084823 quality profile or a profile. For example, if the media content has a one-hour duration and the media content is segmented into QSS files having two-second durations, there are 1800 QSS files for each encoded representation of the media content. If the media content is encoded according to ten different quality profiles, there are 18,000 QSS files for the media content. The quality profiles may indicate how the stream is to be encoded, for example, the quality profiles may specify parameters, such as width and height of the image (i.c., image size), video bit rale (i.e., rate at which the video is encoded), audio bit rale, audio sample rate (i.c., rale at which the audio is sampled when captured), number of audio tracks (e.g., mono, stereo, or the like), frame rate (e.g., frame per second), staging size, or the like. For example, the media players 200 may individually request different quality levels of Lhe same media content 232; for example, each media player 200 may request the same portion (e.g., same time index) of the media content 232, but at different quality levels. For example, one media player may request a sLreamlet having HD quality video, since the computing device of the requesting media player has sufficient computational power and sufficient network bandwidth, while another media player may request a streamlet having a lower qualiLy, since its computing device may not have sufficient network bandwidth, for example. In one embodiment, Lhe media player 200 shifts between quality levels at the portion boundaries by requesting portions from different copies (e.g., different qualiLy streams) of Lhe media content, as described in U.S. Patent Application Publication No. 2005/0262257, filed April 28, 2005. Alternatively, the media player 200 can request the portions using other techniques lhaL would be appreciated by those of ordinary skill in the art having Lhe benefit of this disclosure.

(00581 l he encoder 220 may also specify which quality profiles are available for the particular portion of the media content, and may specify how much of Lhe media content is available for delivery, for example, using a QMX file. The QMX file indicates the current duration of Lhe media content represented by Lhe available QSS files, 'fhe QMX file may operaLe as a table of contents for Lhe media content, indicating which QSS files are available for delivery, and from where the QSS files can be retrieved. The QMX file may be sent Lo the media player 200 via Lhe CDN 240, for example. Alternatively, the media player 200 can request the available quality profiles for the particular media content. In other embodiments, this configuration can be scaled using the scaling capabilities of CDNs to deliver HTTP -22- 220482/2 PCT/US2010/061658 WO 2011 /084823 traffic Lo multiple media players 200. For example, a data center that stores the encoded media content may have a cluster of origin content servers 210 to service multiple media players that request the encoded media content from the data center. Alternatively, other configurations may be used as would be appreciated by one of ordinary skill in the art having the benefit of this disclosure.

[0()59] In one contemplated embodiment, the media player 200 requests portions of the media con ten L by requesting individual streamlet files (e.g., QSS files), 'fhc media player 200 requests the QSS files according to a metadata descriptor file (e.g., QMX file). The media player 200 fetches a QMX file, for example, in response to a user selecting the media content for presentation, and the media player 200 reads the QMX file to determine when to sturt playback of the media content using the current duration, and where to request the QSS files. The QMX file includes a QMX timestamp, such as a UTC (Coordinated Universal Time) indicator, which indicates when the encoding process started (e.g., start time of the media content), and a current duration that indicates how much of Lhc media content is available for delivery. For example, the QMX timestamp may indicate that the encoding process started at 6:00pm (MDT), and 4,500 QSS files of the media content are available for delivery. The media player 200 can determine that the content duration (live playoul) is approximately fifteen minutes, and decide to start requesting QSS files corresponding to the playback of the program at fifteen minutes into the program or slightly before that point. In one embodiment, the media player 200 can determine the point in the media content at which Lhe media player 200 should start playing the content by fetching the corresponding streamlets at that offset into the media contenL. Each time the encoder stores another set of QSS files on the content server (e.g., set of ten QSS files representing the next two seconds of media content at the ten different quality profiles), the QMX file is updated, and the QMX file can be fetched by the media player 200 to indicate that two more seconds are available for delivery over the Internet. The media player 200 can periodically check for updated QMX files. Alternatively, the QMX file and any updates may be pushed to the media player 200 to indicate when Lhe media content is available for delivery over Lhe Internet. |0060| It should be noted thaL although the origin content server 210 has been illustrated as being within Lhe CON 240, the origin content server 210 may reside outside of the CON 240 and still be associated with the CON 240. For example, one entity may own and operate the -23- 220482/2 PCT/US2010/061658 WO 2011/084823 content server that stores the sLreamleLs, but the CDN 240, whose devices may be owned and operated by one or more separate entities, delivers the streamlets.

[0061 ] It should be noted that Lhe media content is data that when processed by a media player 200 (operating on an electronic device (i.e., client device)) allows the media player 200 to present a visual and/or audio representation of an event to a viewer of the media player 200. The media player 200 may be a piece of software that plays the media content (e.g., displays video and plays audio), and may be a standalone software application, a web browser plug-in, a combination of browser plug-in and supporting web page logic, or the like. For example, the event may be a television broadcast, such as of a sporting event, a live or recorded performance, a live or recorded news report, or the like. Λ live event or scheduled television event in this conLext refers to media content that is scheduled to be played back al a particular point in time, as dictated by a schedule. The live event may also have pre-recorded content intermingled with the live media content, such as slow-motion clips of important events within Lhe live event (e.g., replays), which are played in between the live telecast. It should be noted that the embodiments described herein may also be used for streaming video-on-demand (VOD).

[00621 Figure 3Λ is a schematic block diagram illustrating another embodiment of a computing environment 300 in which an encoding system 320, including multiple hosts 314 each employing the encoder 220, may be employed. In one embodiment, the encoding system 320 includes a master module 322 and multiple host computing modules (hereinafter “host”) 314. Each of the hosts 314 employ the encoder 220, as described above with respect to Figure 2. The hosLs 314 may be implemented on one or more personal computers, servers, etc. In a further embodiment, the hosts 314 may be dedicated hardware, for example, cards plugged into a single computer.

[0063] In one embodiment, the master module (hereinafter “masLer”) 322 is configured to receive raw streamlets 312 from the streamlet generation system 301, which includes a receiving module 302 Lhat receives the media content from a publisher 310, and a streamlet module 303 that segments the media content into raw streamlets 312. The master module 322 stages the raw sLreamlets 312 for processing. In another embodiment, the master 322 may receive source sLreamlets Lhat arc encoded and/or compressed and the master 322 decompress each source streamlet to produce a raw streamlet. As used herein, the term “raw -24- 220482/2 PCT/US2010/061658 WO 2011/084823 sLreamleL” refers Lo a streamlet 312 Lhat is uncompressed or lightly compressed to substantially reduce size with no significant loss in quality. A lightly compressed raw streamlet can be transmitted more quickly and to more hosts. Bach host 314 is coupled with the master 322 and configured to receive a raw streamlet from the master 322 for encoding. The hosts 314, in one example, generate multiple streamlets having identical time indices and fixed-lime durations, and varying bilrates. In one embodiment, each host 314 is configured to generate a set 306 of encoded sLreamlcts from the raw streamlet 312 sent from the master 322, where the encoded streamlets of the set 306 represent the same portion of the media content at each of the supported bit rates (i.c., each streamlet is encoded according to one of Lhe available quality profiles). Alternatively, each host 314 may be dedicated Lo producing a single encoded streamlet at one of the supported bit rates in order to reduce the time required for encoding.

[0064] Upon encoding completion, the host 314 returns Lhe seL 306 to Lhe master 322 so that the encoding system 320 may store the set 306 in the streamlcL database 308. 'ITie master 322 is further configured to assign encoding jobs to the hosts 314. In one embodiment, each host 314 is configured to submit an encoding job completion bid (hereinafter “bid”) to the master 322. 'Lhe master 322 assigns encoding jobs depending on the bids from the hosts 314. Bach host 314 generates a bid depending upon multiple computing variables which may include, but are not limited to, current encoding job completion percentage, average job completion time, processor speed, physical memory capacity, or Lhe like.

[00651 Bor example, a host 314 may submit a bid that indicates that the host 314 would be able Lo complete the encoding job in 15 seconds based on pasL performance history. The master 322 is configured to select from among the multiple bids the best bid and subsequently submit the encoding job Lo Lhe host 314 wiLh Lhe best bid. As such, the described encoding system 320 does not require that each host 314 have identical hardware, but beneficially lakes advantage of the available computing power of the hosLs 314. Alternatively, Lhe master 322 selecLs the host 314 based on a first come first serve basis, or some other algorithm deemed suitable for a particular encoding job. 100661 The Lime required Lo encode one streamlet is dependent upon the computing power of the host 314, and the encoding requirements of the content file of Lhe original media eontenl. Bxamplcs of encoding requirements may include, but are not limited to, two or -25- 220482/2 PCT/US2010/061658 WO 2011/084823 mu ld-pass encoding, and mu 1 Li pie sLreams of different biLrates. One benefit of the presen L invention is the ability to perform two-pass encoding on a live content file. Typically, in order to perform Lwo-pass encoding prior art systems must wait for the contcnL file to be completed before encoding. StreamleLs, however, may be encoded as many Limes as is deemed necessary. Because the streamlet is an encapsulated media object of a small duraLion (e.g., 2 seconds), mulLi-pass encoding may begin on a live evenL once the first streamlet is captured.

[0067 ] In one embodiment, the encoder 220 segments the original content file into source streamlets and performs two-pass encoding of the mulLiple copies (e.g., streams) on each corresponding raw streamlet 312 without waiting for a TV show to end, for example. As such, the web server 316 is capable of streaming the sLreamlets over the Internet shortly after the streamlet generation system 301 begins capLure of the original content file. The delay between a live broadcast transmitted from the publisher 310 and the availability of the conLcnl depends on the computing power of Lhe hosts 314.

[0068] Figure 3B is a schematic block diagram illustrating one embodiment of parallel encoding of sLreamlets 312 according to one embodiment. In one example, the streamlet generation system 301 begins to capture the original content file, generates a first streamlet 312a, and passes Lhe streamlet to Lhe encoding system 320. Ibe encoding sysLem 320 may take 10 seconds, for example, Lo generate the first seL 306a of streamlets 304a (304ai, 304a2, 304u3, etc. represent stream lets 304 of different bitraLes). Figure 3B illustrates the encoding process generically as block 308 to graphically illustrate the time duration required to process a raw or lightly encoded streamlet 312 as described above with reference lo the encoding system 320. The encoding system 320 may simultaneously process more than one streamlet 312, and processing of streamlets will begin upon arrival of the streamlet from the streamlet generation module 301. 10069j During the 10 seconds required lo encode Lhe first streamlet 312a, the streamlet module 404 has generated five additional 2-second streamlets 312b, 312c, 312d, 312c, 312f, for encoding and Lhe master 322 has prepared and staged the corresponding raw sLreamlets. Two seconds after the first set 306a is available the next set 306b is available, and so on. As such, the original content 11 le is encoded at different quality levels for streaming over the Internet and appears live. The 10-second delay is given herein by way of example only. -26- 220482/2 PCT/US2010/061658 WO 2011/084823

Multiple hosLs 314 may be added lo Lhe encoding system 320 in order to inerease the proeessing eapacity of the eneoding system 320. The delay may be shortened to an almost unperecivablc level by the addition of high CPU powered systems, or alternatively mulLiplc low powered systems.

[0070J Any specific eneoding scheme applied Lo a streamlet may take longer to complete than the time duration of the streamlet itself. For example, a very high quality encoding of a 2-second streamlet may take 5 seconds to finish. Alternatively, the processing Lime required for each streamlet may be less than the Lime duration of a sLreamlel. However, because the offset parallel encoding of successive streamlets are encoded by the eneoding system 320 at regular intervals (maLehing the intervals at which the those sLreamlcLs are submitted to the eneoding system 320, for example 2 seconds) the output Liming of the encoding system 320 does not fall behind Lhe real-time submission rate of Lhe un-eneoded streamlets 312.

[0071J Returning now to Figure 3Λ, as depicted, the master 322 and the hosts 314 may be located within a single local area network, or in other terms, the hosts 314 may be in close physical proximity lo the master 322. Alternatively, the hosts 314 may receive encoding jobs from the master 322 over Lhe Internet or other communications network. For example, consider a live sports cvenL in a remoLe localion where it would be difficult to set up multiple hosts. In this example, a master performs no encoding or alternatively light encoding before publishing the streamlets online. The hosts 314 would Lhcn retrieve those streamlets and encode the streamlets into Lhe multiple bit rate sets 306 as described above. I.0072J Furthermore, hosts 314 may be dynamically added or removed from the eneoding system 320 without restarting the encoding job and/or interrupting the publishing of streamlets. If a host 314 experiences a crash or some failure, its encoding work is simply reassigned to another host.

[0073] The encoding system 320, in one embodiment, may also be configured to produce streamlets thaL are specific Lo a particular playback plaLform. For example, for a single raw streamlet, a single hosL 314 may produce streamlets for different quality levels for personal computer playback, streamlets for playback on cell phones with a different, proprietary codec, a small video-only sLreamlel for use when playing just a thumbnail view of the slream (like in a programming guide), and a very high qualiLy streamlet for use in archiving. -27- 220482/2 PCT/US2010/061658 WO 2011/084823 [0074] In the depicted embodiment, the computing environment 300 includes a content management system (CMS) 340. The CMS 340 is a publishing sysLem Lhal manages the encoded media content 220, for example, using the streamlet database 308, and allows a publisher to generate and modify timelines (referred to herein as a virtual timeline (QVT)) to schedule the playback of the media content 232. The QVT is metadata that may define a play list for the viewer may indicate when the media players 200 should play the media content. For example, the timeline may specify a starting time of the media content 232, and a current duration of the media conlenL 232 (e.g., amount of available portions of the media content available for delivery) to allow playback of the media event according to the schedule. In the example above, Lhe encoders 220 update the CMS 240 with information abouL streams (e.g., copies of the media content 232) to indicate that certain portions (e.g., streamlets) of the stream have been sent to the origin content server 210 associated with the CDN 240. In this embodiment, Lhe CMS 340 receives information from the encoder 220, such as, for example, any of the following: the encryption keys; availability information that indicates that Lhe set of encoders 220 has sent portions of the encoded media content 232 to the origin conLent server 210; information that indicates what quality levels are available for a particular portion of the media content 232; metadata, including, for example, air date of the content, title, acLrcsses, actors, a start index, an end index, proprietary publisher data, encryption level, conLenL duration, episode or program name, publisher; available tools for the end-user navigational environment, such as available menus, thumbnails, sidebars, advertising, fast-forward, rewind, pause, and play, or Lhe like; or bit-rate values, including frame size, audio channel information, codecs, sample rale, and frame parser information. Alternatively, the encoder 22U may send more or less information than the information described above.

[0075] In Lhe depicted embodiment, the computing environment 300 includes a digital rights management server (DRM) 350 that provides digital rights management capability to Lhe sysLem. The DRM server 350 is further configured to supply encryption keys to the end user upon authenticating the end user. In one embodiment, the DRM server 350 is configured Lo authenticate a user based upon login credentials. One skilled in the art will recognize the various different ways Lhe DRM server 350 may authenticate an end user, including, buL not limiLcd to encrypted cookies, user profile, gco-locaLion, source website, etc. -28- 220482/2 PCT/US2010/061658 WO 2011/084823 [0076J In olher embodiments, the computing environment 300 may include other devices, such as directory servers, management servers, messaging servers, statistic servers, devices of a network infrastructure operator (e.g., an ISP), or the like.

[0077J Figure 4 is a How diagram of one embodiment of a method 400 of encoding audio of media content according to codcc-enforced frame sizes for splitting full audio frames between content files having fixed-lime video portions of the media content. The melhod 400 is performed by processing logic that may include hardware (circuitry, dedicated logic, or the like), software (such as is run on a general purpose computer system or a dedicated machine), firmware (e.g., embedded software), or any combination thereof. In one embodiment, the meLhod 400 is performed by the encoder 220 of Figures 2 and 3Λ. In another embodiment, some of the operations of the methods may be performed by the fixed-frame audio encoder 224 and the audio-spliLting multiplexer 228 of Figure 2.

[0078] In Figure 4, processing logic starts by initializing sample offset to zero (block 402), and receives a raw portion of audio of the media content (block 404). The processing logic encodes the raw portion of audio using the fixed-frame audio codec (block 406) and buffers the encoded audio frames that arc output by the audio codec (block 408). Processing logic determines if there are enough audio frames to fill a streamlet (block 410). In this embodiment, each streamlet also includes video frames whose duration is Fixed, as described herein. If there are not enough audio frames to Fill the streamlet, the processing logic returns to receive a subsequent raw portion of audio at block 404, encodes the raw portion of audio, and buffers the encoded audio frames at block 408. When the processing logic determines that there are enough audio frames to fill the streamlet at block 410, the processing logic sends the audio frames to the audio-splitting multiplexer and removes the sent frames from the buffer (block 412). The processing logic updates the sample offset (block 414), and determines if the media content is at the end (block 416). If the media content is not at the end at block 416, the processing logic returns to block 404 to receive another raw portion of audio. Otherwise, the melhod ends.

[00791 As described above with respect to Figure 2, processing logic may be configured to perform the various operations of the components of the encoder 220. For example, the method 400 may be performed by the fixed-frame audio encoder 224, which receives Lhe raw audio 233 from the splitter 222, encodes the audio frames, and stores the encoded audio -29- 220482/2 PCT/US2010/061658 WO 2011/084823 frames 237 in Ihc audio frame buffer 225. In this embodiment, the operations at block 402-408 may be performed by the fixed-frame audio encoder 224, while the operations at blocks 410-416 may be performed by audio-splitting multiplexer 228. Alternatively, the operations may be performed by other combination of components of the encoder 220.

[00801 Figures 5A-5C are flow diagrams of one embodiment of generating content files with fixed-time video portions and full audio frames having codec-enforced frame sizes. rfhe methods 500, 550, and 570 are performed by processing logic that may include hardware (circuitry, dedicated logic, or the like), software (such as is run on a general purpose compuLer system or a dedicated machine), firmware (e.g., embedded software), or any combination thereof. In one embodiment, the methods 500, 550, and 570 are performed by the encoder 220 of figures 2 and 3Λ. In anoLher embodiment, the method 500 is performed by the fixed-frame audio encoder 224, the method 550 is performed by the fixed-time video encoder 226, and the method 570 is performed by the audio-splitting multiplexer 228. Alternatively, the operations of methods 500, 550, and 570 may be performed by other combination of components of the encoder 220.

[00811 In figure 5A, processing logic of method 500 starts by receiving a raw portion of audio (block 502). The processing logic encodes the raw portion of audio according to a codec-enforced frame size (block 504), and buffers the encoded audio frames (block 506). The processing logic determines if the media content is at the end (block 508). If the media content is not at the end at block 508, the processing logic returns to block 502 to receive another raw portion of audio. Otherwise, Lhe method ends. 10082J In figure 5B, processing logic of method 550 starts by receiving a raw portion of video (block 552). The processing logic encodes the raw portion of video according to a frame rate (block 554) and buffers the encoded video frames (block 556). The processing logic determines if the media content is at the end (block 558). If at block 558 the media content is not at the end, the processing logic returns to block 552 to receive another raw portion of video. Otherwise, the method ends.

[0083] In figure 5C, processing logic of method 570 starts by receiving encoded audio frames from the buffer (block 572) and receiving video frames from the buffer (block 574). 'Phe processing logic generates a streamlet (block 576) and sends the streamlet to the origin content server (block 578). The processing logic determines if the media content is at the end -30- 220482/2 (block 580). If the media content is not at the end at block 580, the processing logic returns to block 572. Otherwise, the method ends.

[0084] In one embodiment, the processing logic at block 576 determines how many video frames are needed to fill the streamlet and how many audio frames are needed to fill the streamlet. In one embodiment, the number of video frames for each streamlet is roughly fixed according to the fixed-time duration. For example, if the frame rate is 30 fps, then there will be 60 frames in a two-second streamlet. It should be noted however that, in reality, the video is not always exactly 30 fps, but rather 29.97 fps. So, some two-second streamlets might have 59 frames, some might have 60, and some even with 61 frames. Each frame in a streamlet has a presentation time relative to the start of the streamlet. So, if a streamlet represents seconds 30-32, the first frame in that streamlet might have a presentation time of 6ms, rather than 0. That frame would be displayed at 30006ms from the start of the stream. In the case of livebroadcast, if computing resources are limited and the encoder is unable to keep up with the live horizon, the encoder may drop frames in order to catch up. So, some streamlets may have gaps in the video, which may be another cause of variations in the number of frames per streamlet. Alternatively, frame rates otherthan 30 fps may be used, such as 24 fps or the like. The number of audio frames for each streamlet is not fixed. The number of audio frames is determined by the operations described above with respect to the audio-splitting multiplexer 228. The processing logic determines if there are enough full frames stored in the buffer to fill the current streamlet. If there are not enough audio frames, the processing logic receives and encodes a subsequent portion of the audio, for example, one full frame of audio from the subsequent portion as described herein. In some cases, the duration of the audio frames in a streamlet may be greater than the fixed-time duration, and in other cases the duration of the audio frames may be less than the fixedtime duration.

[0085] Figure 7 illustrates a diagrammatic representation of a machine in the exemplary form of a computer system 700 for audio splitting. Within the computer system 700 is a set of instructions for causing the machine to perform any one or more of the audio-splitting methodologies discussed herein, may be executed. In alternative embodiments, the machine may be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, or the Internet. The machine may operate in the capacity of a server or a client machine in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) -31- 220482/2 PCT/US2010/061658 WO 2011/084823 network environment. The machine may be a PC, a tablet PC, a STB, a PDA, a cellular telephone, a web appliance, a server, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein for operations of audio splitting, such as the methods 400, 500, 550, and 570 described above. In one embodiment, the computer system 700 represents various components that may be implemented in the encoder 220 or the encoding system 320 as described above. Alternatively, the encoder 220 or the encoding system 320 may include more or less components as illustrated in Lhe computer system 700. 100861 The exemplary computer system 700 includes a processing device 702, a main memory 704 (e.g., read-only memory (ROM), Hash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or DRAM (RDRAM), etc.), a static memory 706 (e.g., Hash memory, static random access memory (SRAM), etc.), and a data storage device 716, each of which communicate with each other via a bus 730.

[0087] Processing device 702 represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. More particularly, the processing device 702 may be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VIJW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. The processing device 702 may also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or Lhe like. The processing device 702 is configured to execute Lhe processing logic (e.g., audio splitting 726) for performing the operations and steps discussed herein. [0088] The computer system 700 may further include a network interface device 722. The computer system 700 also may include a video display uniL 710 (e.g., a liquid crystal display (LCD) or a caLhode ray lube (CRT)), an alphanumeric input device 712 (e.g., a keyboard), a cursor control device 714 (e.g., a mouse), and a signal generation device 720 (e.g., a speaker). -32- 220482/2 PCT/US2010/061658 WO 2011/084823 [0089) The data storage device 716 may include a computer-readable storage medium 724 on which is stored one or more sets of instructions (e.g., audio splitting 726) embodying any one or more of the methodologies or functions described herein. The audio splitting 726 may also reside, completely or at least partially, within the main memory 704 and/or within the processing device 702 during execution thereof by the computer system 700, the main memory 704 and the processing device 702 also constituting computer-read able storage media. The audio splitting 726 may further be transmitted or received over a network via the network interface device 722.

[00901 While the computer-readable storage medium 724 is shown in an exemplary embodiment to be a single medium, the term “computer-readable storage medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. 'Die term “computer-readable storage medium” shall also be taken to include any medium that is capable of storing a seL of instructions for execution by the machine and that causes the machine to perforin any one or more of the methodologies of the present embodiments. The term “computer-readable storage medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical media, magnetic media, or other types of mediums for storing the instructions. The term “computer-readable transmission medium” shall be taken to include any medium Lhat is capable of transmitting a set of instructions for execution by the machine to cause the machine to perform any one or more of the methodologies of the present embodiments.

[00911 The audio splitting module 732, components, and other feaLurcs described herein (for example in relation to Figures 2 and 3Λ) can be implemented as discrete hardware components or integrated in the functionality of hardware components such as ASICS, FPGAs, DSPs or similar devices. In addition, the audio splitting module 732 can be implemented as firmware or functional circuitry within hardware devices. Further, the audio splitting module 732 can be implemented in any combination hardware devices and software compbnents.

[ 00921 The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, Lhc illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many -33- 220482/2 PCT/US2010/061658 WO 2011/084823 modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications, to Lhereby enable others skilled in the art to utilize the invention and various embodiments with various modifications as may be suited to the particular use contemplated. -34-