|||||||||||||||||||||||||||||l||||||||||||||||||||||||||||l||||||||||||||||||||||||l||||||
`
`US 2()[)3(]2369U6/\1
`
`(19) United States
`(12) Patent Application Publication (10) Pub. N0.: US 2003/0236906 A1
`Klemcts ct al.
`(43) Pub. Date:
`Dec. 25, 2003
`
`(54) CI.Il*1N'I‘-Sll)l£CACHING or s'rRI«:AM1N(:
`MEDIA CONTENT
`
`I-..I,II.;I.m,.. Claggificatiun
`
`(75)
`
`Inva:nIur.-5: Anders E. Klemets, Scaltlc, WA (US);
`Troy 1). Batterlrerry, Kirkland, WA
`(US); Eduardo P. Oliveira, Rccirnond,
`WA (Us)
`
`(_jm—l—¢5p(,m1cnCc Acidmag:
`11;]; 3; HAy].;g p[‘[Jc
`421 w R[V[.;Rg[])1g AVENUE guru; 500
`gp()[(AN[.;, WA 9920]
`
`(31) App}, No;
`
`10)']79,77[|
`
`(22)
`
`Filed:
`
`Jun. 24, 2002
`
`Int. Cl.’ ................................................... .. G061’ 15116
`(51)
`.. 709E231; 709,-’250
`(53) U.S. Cl.
`
`ABSTRACT
`(57)
`,
`,
`.
`.
`,
`.
`,
`VEIFIDLIS l1mI::l1onaIILy wnth respect In Sll'c:iI111I1g mccha con-
`
`1I:rIl is made .'1Vaila|"Ilr: I0 LlSErS.‘SIlCl'I lunclmnalrly 'll'IL2l1J(.ll:S
`one or more of: strcamlng mcclla oomcm at a rate Indepen-
`Ilcnl ol the cnvoalcd ln_1 ralc oflhc contcnl, allomng strcamw
`mg of comI:I1I to conlmuc even when the user has sclcclccl
`various shulllt: conlro] 0p1i0rI:5(I:.g., pause. slop, fasl [or-
`ward, :-:-Isck, rewind, I;II.'.}, allowing slrcaming I.‘IJrIlI:rII It.) be
`rt:I.'0rdt:d for playback at a later lime, and allowing slrcalning
`I:0n1I: nl to be lime-shiflcd.
`
`146
`
`
`SERVER DEVICE
`
`
`— 144
`142 H
`CLIENT DEVICE
`
`
`
`STREAMING
`S
`
`TREAMING
`:
`MODULE
`
`
`MEDIA PLAYER
`
`
`148
`
` CONTENT
`FILE
`
`150
`
`STORAGE
`
`
`
`NONVOLATILE
`
`
`
`
`DEVICE (CACHE)
`
`APPLE 1009
`
`APPLE 1009
`
`

`

`Patent Application Publication Dec. 25, 2003 Sheet 1 of 8
`
`US 200300236906 A1
`
`100
`
`104(2)
`
`ORKHN
`SERVER
`
`102(1)
`
`llEiEHH|I'
`
`106-
`
`, 1040»)
`
`lliiififilll
`
`SERVER
`
`108(2)
`
`CACWNG
`PROXY
`SERVER
`
`NETWORK
`
`02
`
`1
`
`0‘)
`
`CLENT
`
`104(1)
`
`ORIGIN
`
`SERVER
`
`102(2)
`
`CLIENT
`
`75¢. I
`
`2
`
`

`

`Patent Application Publication Dec. 25, 2003 Sheet 2 of 8
`
`US 2003/0236906 A1
`
`142
`
`146-
`
`
`102 '
`
`
` CLIENT DEVICE
`
`
`STREAMING
`_
`MEDIA PLAYER
`
`
`
`
`
`
`
`SERVER DEVICE
`
`STREAMING
`MODULE
`
`CONTENT '|
`
`FILE
`
`/ 144
`
`148
`
`152 ’'‘'x
`
`
`
`150
`
`CACHE
`MANAGER
`
`NDNVOLATILE
`STORAGE
`
`
`
`DEVICE (CACHE)
`
`
`
`HEADER (1)
`
`HEADER (h)
`
`
`
`
`
`
`
`
`
`MESSAGE BODY
`
`(OPTIONAL)
`
`‘[84
`
`186
`
`188
`
`3
`
`

`

`Patent Application Publication Dec. 25, 2003 Sheet 3 of 8
`
`US 2003/0236906 A1
`
`E
`
`NEGOTIATE STREAMING RATE FOR STREAMING
`MEDIA CONTENT THAT IS INDEPENDENT OF
`
`ENCODED BIT RATE OF THE CONTENT
`
`RATE THAT IS INDEPENDENT OF ENCODED BIT RATE
`
`MEDIA CONTENT IS STREAMED AT STREAMING
`
`2_39.
`
`RECEIVE SHUTTLE CONTROL REQUEST REGARDING
`
`PLAYBACK OF STREAMING MEDIA CONTENT
`
`ALTER PLAYBACK OF STREAMING MEDIA CONTENT
`
`IN ACCORDANCE WITH REQUEST
`
`CONTINUE RECEIVING STREAMING MEDIA CONTENT
`
`202
`
`- 204
`
`232
`
`234
`
`236
`
`4
`
`

`

`Patent Application Publication Dec. 25, 2003 Sheet 4 of 8
`
`US 2003! 0236906 A]
`
`25$
`
`RECEIVE STREAMING MEDIA
`
`CONTENT FROM SERVER
`
`SAVE STREAMING MEDIA CONTENT
`
`LOCALLY
`
`RECEIVE REQUEST TO PLAY BACK
`
`STREAMING MEDIA CONTENT AT A
`
`LATER TIME
`
`PLAY BACK LOCALLY SAVED
`
`STREAMING MEDIA CONTENT
`
`262
`
`264
`
`266
`
`268
`
`5
`
`

`

`Patent Application Publication Dec. 25, 2003 Sheet 5 of 8
`
`US 200330236906 A1
`
`£39
`
`A 302
`
`RECEIVE STREAMING MEDIA
`
`CONTENT FROM SERVER
`
`CACHING
`
`OF STREAMING MEDIA
`
`CONTENT ALLOWED
`
`?
`
`306
`
`308
`
`SAVE STREAMING MEDIA CONTENT
`
`TO NONVOLATILE STORAGE DEVICE
`
`MAKE STREAMING MEDIA CONTENT
`
`AVAILABLE FOR PLAYBACK
`
`6
`
`

`

`Patent Application Publication Dec. 25, 2003 Sheet 6 of 8
`
`US 2003/0236906 A]
`
`E
`
`- 336
`STREAMING MEDIA PLAYER ATTEMPTS TO
`
`
`ACCESS STREAMING MEDIA CONTENT
`
`STREAMING MEDIA PLAYER OBTAINS HEADER
`INFORMATION FOR CONTENT FROM SERVER
`
`338
`
`USER DISABLED CLIENT CACHING?
`
`CONTENT IDENTIFIER INDICATE NO
`
`
`
`
`
`
`
`
`
`MEDIA PLAYER
`
`
`DISABLED CLIENT CACHING?
`
`
`YES
`
`CONTENT BIT
`RATE MODIFIER INCLUDED IN
`CONTENT IDENTIFIER?
`
`STREAMING MEDIA CONTENT
`IS NOT CACI-IED AT CLIENT
`
`N0
`
`
`
`7
`
`

`

`Patent Application Publication Dec. 25, 2003 Sheet 7 of 8
`
`US 2003/0236906 A1
`
`
`
`-- 352
`
`SELECT HIGHEST SET OF
`STREAMS THAT DO NOT
`EXCEED THE VALUE OF THE
`CONTENT BIT RATE MODIFIER
`
`350
`
`LINK BANDWIDTH
`
`SELECT STREAMS BASED ON
`
`
`
`
`354
` DOES CONTENT
`
`NO
`IDENTIFIER INDICATE YES
`CACHING?
`
`356
`
`YES
`ANDWIDTH > 1.5x SELECTED
`
`
`STREAMS OR < .9X SELECTED
`
`
`
`DOES SELECTED PROTOCOL
`SUPPORT CLIENT CACHINC?
`
`
`
`
`
`
`OES SERVER A:.LOw CLIENT
`CACHING?
`
`SUFFICIENT CACHE SPACE?
`
`YES
`
`STREAMING MEDIA CONTENT IS CACHED AT
`CLIENT
`
`8
`
`

`

`Patent Application Publication Dec. 25, 2003 Sheet 8 of 8
`
`US 2003/0236906 A1
`
`400 —.
`
`415 ~-
`
`\-
`
`442
`
`MONITOR
`
`422
`
`REMOTE
`COMPUTING
`
`
`
`APPLICATION
`PROGRAMS
`
`.
`
`
`
`l]IIfl|:I
`.I H
`
`I" }[ ]|",‘II_]{'.'lId_J E]
`I
`OPERATING
`VIDEO ADAPTER
`ADAPTER
`SYSTEM @
`
`APPLICATION
`Svs E B 5
`T M ”
`PRoGRAMs_42s
`
`426 —
`
`-
`om MEDIA
`INTERFACES
`
`OPERATING E
`.5!’5TEM
`APPl.|CAT|ON423
`PROGRAMS
`
`MODULES
`
`DATA
`
`
`
` /—-—- 440
`[mgDI;IIJI:I:II:I H
`
`OTHER PROGRAM
`
`MODULES E
`
`'_p,§oGRAM
`'
`'
`I‘
`-
`DATA E
`
`PROCESSING
`UNIT
`
`1
`
`4 min:
`
`
`
`110 INTERFACES
`
`II
`
`1-———
`A ___
`PRINTER \
`MOUSE
`— 446
`
`
`.£fTZ1CT.”.'3*.-
`1*
`-'
`
`LII
`
`
`(manna; '00
`TA I5‘
`KEYBOARD
`OTHER DE\.rIcE(s)
`436
`434
`
`9
`
`9
`
`

`

`US 2003/0236906 Al
`
`Dec. 25, 2003
`
`CLIENT—SIDE CACHING OF STREAMING MEDIA
`CONTI£N'I'
`
`TECHNICAL FIELD
`
`In accordance with other embodiments, streaming
`[0009]
`ofstreaming media content can continue even when the user
`has selected various shuttle control options (e.g., pause,
`stop, fast forward, seek, rewind, etc.),
`
`[0001] This invention relates to streaming media, and
`particularly to client-side caching of streaming media con-
`lt:‘.l'tl.
`
`accordance with still other embodiments,
`In
`[0010]
`streaming media content can be recorded for playback at a
`later time
`
`BACKGROUND
`
`[0002] Content streaming, such as the streaming of audio,
`video, andfor text media content is becoming increasingly
`popular. The term “streaming” is typically used to indicate
`that
`the data representing the media is provided over a
`network to a client computer and the client computer renders
`the streaming content as it is received from a network server,
`rather than waiting for an entire “file” to be delivered.
`
`[0003] The increasing availability of streaming media
`content enables a variety of informational content that was
`not previously available over the Internet or other computer
`networks. Live content is one significant example of such
`content. Using streaming media content, audio, video, or
`audio,/visual coverage ol‘ noteworthy events can be broadcast
`over the Internet as the events unfold. Similarly, television
`and radio stations can transmit their live content over the
`Internet.
`
`is streamed
`[0004] Currently, streaming media content
`using the concept of “just in time delivery”. The content is
`delivered to the client at the content’s encoded bit rate for
`playback on the client. Some buliering of the streaming
`media content does occur (eg, to allow for lost data that
`needs to be retransmitted and other network inconsisten-
`cies). However, current client systems typically attempt to
`minimize the amount of bu llering performed on the client,
`thereby reducing the memory requirements on the client as
`well as reducing the startup latency due to bulfering.
`
`Ilowever, current streaming media content and
`[0005]
`butfering systems suffer from not having functionality that
`other types of content playback systems have. For example,
`a television program recorded on a VCR can be rewound by
`the user and previously viewed portions readily watched
`repeatedly, or watched at a later time as the user desires.
`Current streaming media content scenarios, however, do not
`allow such actions to be perforrncd by the user. Rather,
`rewinding streaming media content would involve stopping
`and re-starting the streaming of the content at a new location
`(and thus re-buffering the stream starting at the new loca-
`tion), and a user typically cannot watch streaming media
`content at a later tirne—the content is played for the user as
`it is received and if the user desires to watch the content at
`the later time he or she must have the content streamed to
`him or her at that later time.
`
`[0006] The client-side caching of streaming media content
`described below solves these and other problems.
`
`SUMMARY
`
`[0007] Client-side caching of streaming media content is
`described herein.
`
`In accordance with certain embodiments, stream-
`[0008]
`ing media content can be streamed at a rate independent of
`the encoded bit rate of the content.
`
`In accordance with yet other embodiments, stream-
`[0011]
`ing media content can be time-shifted.
`
`embodiments,
`additional
`accordance with
`In
`[0012]
`streaming media content received from a server device is
`cached on a client device. Subsequent requests for the
`streaming media content at the client device can then be
`satisfied using the cached streaming media content rather
`than re-streaming the streaming media content from the
`server device.
`
`BRIEF IDESCRIPTION OF THE DRAWINGS
`
`[0013] The same numbers are used throughout the docu-
`ment to reference like components andfor features.
`
`[0014] FIG. 1 illustrates an exemplary network environ-
`ment in which client-side caching of streaming media con-
`tent can be employed.
`
`[0015] FIG. 2 illustrates exemplary client and server
`devices.
`
`[0016] FIG. 3 illustrates an exemplary message format
`that can be used in communicating streaming media data.
`
`illustrating an exemplary
`[0017] FIG. 4 is a flowchart
`process for streaming media content from a server to a
`client.
`
`illustrating an exemplary
`[0018] FIG. 5 is a flowchart
`process For streaming media content from a server to a client
`while accepting shuttle control commands.
`
`[0019] FIG. 6 is a flowchart illustrating an exemplary
`process For recording streaming media content for subse-
`quent playback.
`
`illustrating an exemplary
`[0020] FIG. 7 is a flowchart
`process [or caching streaming media content on a client
`device.
`
`[0021] FIGS. 8A and 8B are a llowclrart illustrating an
`exemplary process for determining whether to cache stream-
`ing media contcnt on a client device.
`
`[0022] FIG. 9 illustrates an exemplary general computer
`environment, which can be used to implement
`the tech-
`niques described herein.
`
`l)E'I'A1l._.ED DES(TRIPI'ION
`
`[0023] Client-side caching of streaming media content is
`described herein. By caching the streaming media content, a
`variety of previously unavailable functionality can be made
`available to users. Examples of such functionality include:
`streaming media content at a rate independent of
`the
`encoded bit
`rate of the content, allowing streaming of
`content to continue even when the user has selected various
`shulfle control options (e.g., pause, stop, fast forward, seek,
`rewind, etc.), allowing streaming content to be recorded for
`playback at a later time, and allowing streaming content to
`
`10
`
`10
`
`

`

`US 2003/0236906 Al
`
`Dec. 25, 2003
`
`be timc—shiftcd. Different embodiments of the clicnt—side
`caching of streaming media content can include dillercnt
`ones of these functionalities or combinations of different
`ones of these functionalities.
`
`[0024] FIG. 1 illustrates an exemplary network environ-
`ment 100 in which client-side caching of streaming media
`content can be employed. In environment multiple (X) client
`computing devices 102(1), 102(2), .
`.
`.
`, l02( x) are coupled
`to multiple (y) origin server computing devices 104(1),
`l04(2), .
`.
`.
`,
`l04(y} via a network 106. Network 106 is
`intended to represent any of a variety of conventional
`network topologies and types (including optical, wired and!
`or wireless networks), employing any of a variety of con-
`ventional network protocols {including public andfor pro-
`prietary protocols). Network 106 may include, for example,
`the Internet as well as possibly at least portions of one or
`more local area networks (LAN:-i) andfor wide area networks
`(WA.Ns).
`
`[0025] When requesting streaming media content that is
`available from an origin server device 104, the request is
`routed from client device 102 to the server device 104 via
`network 106. The origin server device 104 receives the
`request and returns the requested content to the requesting
`client device 102 via network 106. One or more proxy
`servers {not shown) may be part of network 106, and
`requests from client device 102 and responses to client
`device 102 may be sent to and received from such a proxy
`server(s) rather than the actual server device 104. Whatever
`device (whether it be an origin server, proxy server, or other
`device) is streaming media content to a client device 102 is
`referred to as the source device for that streaming media
`content.
`
`[0026] Computing devices 102 and 104 can each be any of
`a variety of conventional computing devices,
`including
`desktop PCs, notebook or portable computers, workstations,
`mainframe computers,
`Internet appliances, gaming con-
`soles, handheld PCs, cellular telephones, personal digital
`assistants (PD/ks), combinations thereof, etc. One or more of
`devices 102 and 104 can be the same types of devices. or
`alternatively different types of devices.
`
`[0027] Server devices 104 can make any of a variety of
`data available for streaming to clients 102. The term
`“streaming” is used to indicate that the data representing the
`media is provided over a network to a client device and that
`playback ofthe content can begin prior to the content being
`delivered in its entirety. The data may be publicly available
`or alternatively restricted (e.g., restricted to only certain
`users, available only ifthe appropriate fee is paid, etc.). The
`data may be any of a variety of one or more types of content,
`such as audio, video, text, animation, etc. Additionally, the
`data may be “on-demand" (e.g.. pre-recorded and of a
`known
`or alternatively "broadcast” (e.g., having no
`known size, such as a digital representation of a concert
`being captured as the concert is performed and made avail-
`able for streaming shortly after capture}.
`
`[0028] FIG. 2 illustrates exemplary client and server
`devices. Client device 102 includes a streaming media
`player 142 configured to access a streaming module 144 of
`a source server device 146. Source server device 146 may
`be, for example, an origin server device 104 of FIG. 1, or
`alternatively another device (e.g., a proxy device). Source
`server device 146 also includes one or more streaming
`
`media content files MS from which a selection can be made
`by media player 142 (e.g., based on user input at player 142)
`and the selected content file streamed to player 142. Once
`received,
`the streaming media content can be cached at
`client device 102 by saving the content to a nonvolatile
`storage device 150. Although not shown in FIG. 2, one or
`more additional devices (e.g.. lirewalls, routers. gateways.
`bridges, multiple proxy servers, etc.) may be situated
`between client device 102 and server device 146. It should
`
`be noted that multiple clients 102 may access server 146 and
`that a single client 102 may access multipie servers 146,
`although only a single client 102 and server 146 have been
`shown in FIG. 2 for ease of explanation.
`[0029] Nonvolatile storage device 150 is nonvolatile in
`that it maintains its state even in the event of a power failure.
`Thus, streaming media content saved to nonvolatile storage
`device 150 persists in the event of power loss to client 102
`(c.g.,
`in the event client 102 is turned oil). A variety of
`different nonvolatile storage types may be used as device
`150, such as a magnetic disk and disk drive (c.g., a conven-
`tional hard disk), an optical disk and disk drive. Flash
`memory, and so forth.
`[0030] Communication between devices 102 and 146 can
`occur using a variety ol’ different conventional protocols. In
`one implementation, communication between devices 102
`and 146 occurs using a version of the I-lyperText Transport
`Protocol (H'l'l‘l’), such as version 1.1 (H’I'l‘l’ 1.1). In another
`implementation, communication between devices 102 and
`146 occurs using the Real Time Streaming Protocol (RTSP).
`Alternatively, other protocols may be used, such as the
`Session Initiation Protocol (SIP), the Simple Object Access
`Protocol (SOAP), and so forth.
`[0031] Additionally, streaming media content can be
`stored and streamed in accordance with any of a variety of
`dil1'erent streaming media formats. In one exemplary imple-
`mentation, media is streamed in accordance with the ASI’
`format (Advanced Systems Format or Advanced Streaming
`Format). Additional information regarding ASF is available
`from Microsoft® Corporation of Redmond, Washington.
`The same technique can be applied to other formats as well,
`such as MPEG (Moving Pictures Experts Group)—1, MPEG-
`2, MPEG-4, Quicktirne, etc.
`[0032] FIG. 3 illustrates an exemplary message format
`that can be used in communicating streaming media data.
`The data structure 180 of a message, such as an I-ITTP l.l
`message or RTSP message,
`includes a start
`line field or
`portion 182, one or more header fields or portions 184, an
`empty line field or portion 186, and an optional message
`body field or portion 188. Start line portion 182 contains
`data identifying the message or data structure type, which
`can be either a request—line {e.g., for an H‘I"I‘P l.1 GET
`request or an RTSP GIj'I'__PARAME'I'l_7.R request) or a
`status-line (c.g., for an I-ITTP l.l 200 OK response or an
`RTSP 1.0 200 OK response). One or more headers 184 are
`also included that contain data representing information
`about the message. An empty line portion 186 is used to
`identify the end of the headers 184. Additional data may
`optionally be included in message body portion 188. In the
`discussions herein, various directives are included as head-
`ers 184, although these directives may alternatively be
`situated in message body 188.
`[0033] Control information (c.g., for setting up the stream-
`ing of media content) as well as data (e.g., the streaming
`
`11
`
`11
`
`

`

`US 2003/0236906 A1
`
`Dec. 25, 2003
`
`L»)
`
`media content) is communicated between devices 102 and
`146 of FIG. 2 as appropriate using messages with data
`structure 180. These messages thus correspond to or are
`associated with the media content being streamed.
`
`[0034] Returning to FIG. 2, cache manager 152 of client
`device 102 manages the caching of streaming media content
`received by streaming media player 142 from origin server
`146. Streaming media player 142 receives the content and,
`when it determines it should cache the content, forwards the
`content to cache manager 152 for storage. Streaming media
`player 142 may make the determination on its own, or
`alternatively based at least in part on information received
`from cache manager 152 {e.g., whether there is space
`available in the cache).
`
`It should be noted that the caching of streaming
`[0035]
`media content by streaming media player 142 is different
`than buffering the streaming media content. Various dilTer—
`ences between caching and bulfering exist, typically includ-
`ing one or more of the following:
`the cached content
`is
`stored to a nonvolatile storage device rather than a volatile
`memory; the cached content can include content that has
`already been played back; and the cached content can
`include content that is not to be played back for a long time,
`rather than immediately (e.g., as with “just in time” deliv-
`ery).
`
`[0036] Dilferent pieces of streaming media content are
`illustrated as difierent tiles 148 in FIG. 2, although alterna-
`tively a piece of streaming media content may be stored as
`multiple files (or, in the case oibroadcast content, as no lilo).
`The manner in which a “piece” of content is defined can vary
`by implementation and based on the type of media. For
`example, for musical audio andtor video content each song
`can be a piece of content. Content may be separated into
`pieces along natural boundaries (e.g., dilferent songs), or
`alternatively in other arbitrary manners (e.g., every live
`minutes of content is a piece}.
`
`[0037] Conventional components that are part of client
`device 102 can optionally be leveraged to perform the cache
`management functionality. In one exemplary implementa-
`tion, the Microsoftg® Internet Explorer browser program
`includes cache management functionality, and streaming
`media player 142 leverages and uses this functionality.
`
`[0038] Each piece of media content may include multiple
`streams, even though they may be stored together as a single
`file. Each such stream represents a particular type of media
`(e.g., audio, video,
`text, etc),
`typically at a particular
`encoded bit rate. The encoded bit rate is the rate at which the
`media content is encoded for playback. It should be noted
`that the encoded bit rate is independent of the user-perceived
`playback speed of the content (for example, both a normal
`stream olcontent and a fast forward stream ofcontent which
`the user perceives as two times the playback speed of the
`normal stream typically have the same encoded bit rate).
`
`[0039] Multiple versions of the same type of media (c.g.,
`multiple audio versions, multiple video versions, etc.) may
`be included in the media content, allowing selection of
`different combinations of these streams for playback by
`media player 142. Each of these dilIerent versions is typi-
`cally encoded at a dillierent bit rate (with higher bit rates
`typically resulting in higher quality content). Which corn-
`bination ofstreams are to be included in the streaming media
`
`content can be selected in a variety of manners, such as user
`preferences (eg, for higher or lower quality content), avail-
`able network bandwidth, a desired bit rate for particular
`content (eg, a bit rate set by the content author or distributor
`and included in the identifier of the streaming media content
`so that, when the identifier is selected by the user, streaming
`media player [42 selects streams (optionally based on user
`preferences) that are as close as possible to the desired bit
`rate).
`
`[0049] When caching content, cache manager 152 stores
`in nonvolatile storage device 150 the particular streams (as
`requested by streaming media player 142) received from
`server device 146 as the streaming media content. Different
`stream combinations for the same piece of media content
`can be cached by cache manager 152. Alternatively, cache
`manager 152 may obtain all the streams for particular media
`content from server device 146 and cache all of the streams,
`but playback only the requested streams to media player
`142.
`
`[0041] Multiple pieces of content may also be grouped
`together in a play list, which is a list of one or more items
`each of which is a particular piece of content to be streamed.
`These diliferent pieces ofcontent can be selected (e.g., by the
`user or by some other party) to be grouped together in a play
`list, allowing a user to select all ofthem for rendering simply
`by selecting the play list. By way of example, a user may
`select twenty of his or her favorite songs to be part of a play
`list, and subsequently have those songs played back to him
`or her by selecting playback of the play list.
`
`[0042] Caching of streaming media content at client 102
`allows streaming media player 142 to provide various func-
`tionality and thus enhancements to the user experience.
`These include: streaming media content at a rate indepen-
`dent ofthc encoded bit rate ofthc content; allowing stream-
`ing of content to continue even when the user has selected
`various shuttle control options (e.g., pause, stop, last for-
`ward, seek, rewind, etc); allowing streaming content to be
`recorded for playback at a later time; and allowing streaming
`content to be time—shit‘ted.
`
`[0043] Caching streaming media content at client 102
`allows media content to be streamed from server device 146
`to client device 102 at a rate independent of the encoded bit
`rate. Although some situations may arise where the stream-
`ing rate is the same as the encoded bit rate, the streaming rate
`can be greater than or less than the encoded bit rate.
`Streaming media content
`received by streaming media
`player 142 is stored in the cache and, when playing back the
`content, media player 142 retrieves the content from the
`cache for playback while at the same time continuing to
`cache subsequent parts of the content being streamed from
`server device 146. In one exemplary situation where the
`streaming rate is less than the encoded bit rate, media player
`142 imposes additional delays in playback of the streamed
`content based on how much of the content has been cached,
`what the encoded bit rate is, and what the streaming rate is.
`For example, if the encoded bit rate is 300 kbps, and the
`streaming rate is 150 kbps, then media player 142 delays
`beginning playback olthe content until sullicicnt content has
`been stored so that the content can be played through from
`beginning to end without any user-noticeable pauses.
`
`In one implementation, media player 142, when
`[0044]
`requesting the streaming content from streaming module
`
`12
`
`12
`
`

`

`US 2003/0236906 A1
`
`Dec. 25, 2003
`
`144, also communicates a speed request to streaming mod-
`ule 144. This speed request indicates the rate at which media
`player 142 would like the media content streamed. Stream-
`ing module 144 may then accept the requested rate and
`proceed with streaming the media content to media player
`142 at the requested rate, or alternatively change the rate.
`For example, streaming module 144 may not be able to
`stream the content at the requested rate (eg, due to server
`policies, hardware andfor software limitations of the server,
`the current
`load of the server, and so forth). Streaming
`module 144 sends an indication to media player 142 ofwhat
`the streaming rate will be (alternatively, the streaming rate
`may be the rate requested by media player 142 unless
`streaming module 144 indicates otherwise). Additionally,
`streaming module 144 can attempt to change the streaming
`rate during streaming ofthe content (by sending a new speed
`request to streaming module 144). and streaming module
`144 may change the streaming rate during streaming of the
`content {by sending a new speed indication to media player
`142).
`
`[0045] Media player 142 can determine the streaming rate
`it desires, and thus the rate it requests from streaming
`module 144, based on a variety of dillerent factors. The
`determination can be made on a content-by-content basis. In
`one implementation, media player 142 attempts to determine
`the current available bandwidth between media player 142
`and streaming module 144. This can be determined in any of
`a variety of conventional manners, such as sending test
`messages between devices 102 and 146, monitoring current
`and past behavior of connections between device 102 and
`146, receiving an indication of the available bandwidth from
`streaming module 144, and so forth. Given the current
`available bandwidth, media player 142 initially requests a
`streaming rate that
`is a particular amount
`less than the
`current available bandwidth. This particular amount can be
`fixed (e.g., always 50 kbps) or dynamic (c.g., 15% of the
`current available bandwidth, or between 5% and 25% of the
`current available bandwidth).
`
`from media
`[0046] The streaming speed request sent
`player 142 to streaming module 144 can indicate the rate at
`which media player 142 would like the data streamed in any
`of a variety of manners. In one implementation, the rate is
`indicated by a speed factor relative to the encoded bit rate of
`the content (e.g., a speed factor of 3.2 indicates that the
`streaming rate is 3.2 times faster than the encoded bit rate of
`the content, while a speed factor of 0.5 indicates that the
`streaming rate is onc—half the encoded bit rate of the con-
`tent). In another implementation, the rate is indicated by
`simply stating the desired streaming bit rate (e.g., 300 kbps,
`500 kbps, 20 kbps, etc).
`
`indication can be sent from
`[0047] The speed request
`media player 142 to streaming module 144 in a variety of
`diflicrent manners. In one implementation, where communi-
`cation between devices 102 and 146 occurs using RTSP, the
`following RTSP header is added to a message (cg, as a
`header 184 of FIG. 3) sent from streaming media player 142
`to streaming module 144:
`
`[0043]
`
`Speed: x
`
`[0049] where x represents the requested speed factor rela-
`tive to the encoded bit rate of the content. The value x can
`be an integer or a real number (the number ofdecimal places
`may optionally be limited—typically to one or two decimal
`
`places although other values can be used). This header can
`be added to different messages, and in one implementation
`is included in a message sent from streaming media player
`142 to streaming module 144 requesting streaming of the
`media content.
`
`[0050] When streaming module 144 responds to the
`request, streaming module 144 returns an analogous header
`(Speed: y) in an RTSP PLAY resportse message to streaming
`media player 142, where y represenLs the speed (relative to
`the encoded bit rate of the content) at which streaming
`module 144 will be streaming the requested content [and
`may or may not be the same as the value x). As with the
`value x, the value y can be an integer or a real number (and
`the number of decimal places may optionally be limited-
`typically to one or two decimal places although other values
`can be used}.
`
`In another implementation, where communication
`[0051]
`between devices 102 and .146 occurs using HTTP,
`the
`following H’I'l‘P header is added to a message (e.g., as a
`header 184 of FIG. 3) sent from streaming media player 142
`to streaming module 144:
`
`[0052]
`
`Pragma: Speed=x
`
`[0053] where x represents the requested speed factor rela-
`tive to the encoded bit rate of the content. The Pragma
`header is a general-header field used in HTTP to include
`implementation specific directives. Analogous to the RTSP
`Speed header discussed above, this header can be added to
`different messages, and in one implementation is included in
`a message sent from streaming media player 142 to stream-
`ing module I44 requesting streaming of the media content.
`
`[0054] When streaming module 144 responds to the
`request, streaming module 144 returns an analogous header
`(Pragma: Speed=y) in an HTTP GET response message to
`streaming media player 14-2, where y represents the speed
`(relative to the encoded bit rate of the content) at which
`streaming module 144 will be streaming the requested
`content (and may or may not be the same as the value x). As
`with the value x, the value y can be an integer or a real
`number (and the number of decimal places may optionally
`be limited-typically to one or two decimal places although
`other values can be used).
`
`It should be noted that, although the streaming rate
`[0055]
`for the content may be identilied with reference to the
`encoded bit rate, this is done simply because it is an easy
`point of reference. The streaming rate is still independent of
`the encoded bit ratc—virtually any speed factor can be
`requested andfor selected, and the way that speed factor is
`identified is with reference to the encoded bit rate.
`
`[0056] FIG. 4 is a llowchart illustrating an exemplary
`process 200 for streaming media content from a server to a
`client. Process 200 is implemented by a client device and
`server device, such as devices 102 and 146 of FIG. 2, and
`may be performed in software, firmware, hardware, or
`combinations thereof.
`
`a streaming rate for streaming media
`Initially,
`[0057]
`content that is independent of the encoded bit rate of the
`content is negotiated between the client and server devices
`(act 202). This negotiation can be, for example, the submis-
`sion ofa requested speed by the client and a return indication
`of the streaming speed as discussed above. Alternatively, the
`
`13
`
`13
`
`

`

`US 2003/0236906 Al
`
`Dec. 25, 2003
`
`negotiation may take other forms, such as being initiated by
`the server device (or some other device} and the client
`device requesting any desired changes to the streaming rate;
`using a default rate that can be changed by the client device
`or the server device; using a rate indicated by the streaming
`media content
`identifier and that can be changed by the
`client device or the server device; and so forth. Once the
`streaming rate is negotiated, the media content is streamed
`from the server device to the client device at the negotiated
`streaming rate (act 204). The streaming rate can optionally
`be subsequently re-negotiated (initiated by the client device,
`server device, or some other device) during streaming of the
`content.
`
`[0058] Returning to FIG. 2, streaming module 144 typi-
`cally does not transfer an entire content file 148 to streaming
`media player 142 as the streaming media content. Certain
`information, such as lile headers and indexing information,
`is typically not transferred to streaming media player 142 as
`part of the streaming media content. The exact nature of this
`information can vary, based on the manner in which stream-
`ing module 144 is designed and the format used to stream
`