Systems and methods to provide trick play during streaming playback.

(54) Title: SYSTEMS AND METHODS TO PROVIDE REPRODUCTION NOT STANDARD DURING REPETITION OF CONTINUOUS TRANSMISSION.

(54) Title: SYSTEMS AND METHODS TO PROVIDE TRICK PLAY DURING STREAMING PLAYBACK.

(57) Summary

Systems and methods are described for providing non-standard playback functions such as fast forward, reverse or slow motion during streaming media content playback. Multiple sets of tiny streams (132,134,136) or other media files representing the same media stream are encoded differently from each other (for example, at different frame rates and / or frame addresses), and each set of files is simultaneously maintained on a server. Files encoded in a first format (132) are made available to the client device during regular repetition, and files encoded at a different frame rate and / or a different encoding address (134, 136) are made available to support non-standard reproduction.

(57) Abstract

Systems and methods are described for providing trick play functions such as fast forward, rewind or slow motion during playback of streaming media content. Multiple sets of streamlets (132,134,136) or other media files that represent the same media stream are encoded differently from each other (eg, at different frame rates and / or frame directions), and each set of files is simultaneously maintained at a server. Files encoded at a first format (132) are made available to the client device during regular playback, and files encoded at a different frame rate and / or a different direction of encoding (134,136) are made available to support trick play.

IMPI

<img file="MX354192B_D0001.tif" />

<img file="MX354192B_D0002.tif" />

PATENT TITLE No. 354192

Owner (s): ECHOSTAR ADVANCED TECHNOLOGIES LLC

D micilio:

100 Inverness Terrace East, Englewood, Colorado, 80112, USA

<td>nomination:</td><td>SYSTEMS AND METHODS TO PROVIDE NON-STANDARD REPRODUCTION DURING REPETITION OF CONTINUOUS TRANSMISSION.</td>

Classification:

Inventor (s):

CIP:

CPC:

MARK BsJWRST

H04N21 /? 343; ^ 1 | BVfb0 ^ HQ4N5 / Z83; H04N7 / 173

H0 # l21 / 23 * 438l; H04N5 / 783; H04N11 / Í387; H04N21 / 23439; H04N21 / 47202

<img file="MX354192B_D0003.tif" />

i

Number:

MX / a / 2012/008358 n International:

from 2011

Number:

61/303,579

Validity: Twenty years

VelMhmiento sheet ^ 1 £ 2031

EXPADITION SHEET February 6 cte 2018, '' ^J'' “Fun5arrie ^ o in the Industrial Property.

The patent of referent ^ atg ^ rga with f

In accordance with the arlh ^ fo * * the Law leaves ProMed ^ lJ as of the date of presentheíji Vt the solicfWinteejaciü

Who subscribes the present title lofundtH¡n | nto in I (Official Gazette of the Federation (PSDtjy, 27 / ββ / 194Τ leformaj 01/25/2006, 06/05 / 2009,06 / 01 / 2010.1 # $ 6 / ^ 0. ¿06/08/201 Of 27 / (1 Regulations of the Mexican Institute &lt;laAi «| ted latótriS (í articles 1^or, 3^or, 4^or, 5^or fraction \ Z subsection a), ^ fteccionas ImJII and 12/27/1999, amended on 10/10/2002, 07/29 WÓ4 ^ / © wM3 ^ Deputy Generals, Coordinator, Directors^í8'9 ^ 4 ^ fó | »ie ^_FT Departmental and other subordinates of the Institute M ^ xiq ^ o ^ lam 08/04/2004 and 09/13/2007).

of twenty years- ^ n extendable, counted to be current WWechos.

ί ^ ιΐφ íraGciQQ ^ III y 7^or bis 2 of the tey of Industrial Property the ^ 2®8 (1994, »/ 10 / ^ 006, 12/26/1097, 05/17/1999, 01/26/2004, 06/16/2005, ^ / 2012¼OWÓ0 / 2O12M artrtM &amp; l⁰. 3^or fra ^ dón&gt; lncfsfi a). 4^or and 12th fractions I and III of the Jif. 14 (12 (11999, I¿j | ofrnada4l 01Í67 / 2M02, 07/15/2004, 07/28/2004 and 7/7/2007); 30 '^ S »» S «tei« tr © rgánijjMfeÜostitu | e' Industrial Property Method (split DOF that delegates powers to the Directors is, Divisional Deputy Directors, Coordinators 12/1999, amended on 02/04/2000, 07/29/2004,

<img file="MX354192B_D0004.tif" />

<img file="MX354192B_D0005.tif" />

This letter is signed with an advanced electronic signature (FIEL), based on the articles of its Regulations, and 1 section III, 2 section V, 26 BIS and 26 TER of the Agreement establishing the guidelines for the use of the Portal of Payments and Electronic Services (PASE) of the Mexican Institute of Industrial Property, in the procedures indicated.

BIS 2 of the Industrial Property Law; 3rd of

THE DIVISIONAL DIRECTOR OF PATENTS

NAHANNY CANAL REYES

<img file="MX354192B_D0006.tif" />

Original string.

NAHANNY MARISOL CANAL REYES | 00001000000403252793 | Tax Administration Service | 1695 || MX / 2018/14012 | MX / a / 2012/009358 | Patent title PCT | 1220 | RRGO | Page (s) | 7oBhDvqaMh7R2tWVh / nJ4u6Z7x

Digital stamp:

Zoyhf7MbQX7GYJItKtnu / rbCJJV + E0qMb7JjAoTuy2wUZEO0Fp0vz / NWFRZ83EYG / 9IWXqbi90NRcYSGinPHrpy6Ay Fxivc9n6jdSrxhTPBHxfPINwnw4tqKT09kAjaKnpyN2pCy43ZeJybunvrRurQtu / VKLyuZs7kU45tyNKgjAUTOz0 + b + S3L7n8kpRZN88X2Flv3PUW0B9tzEwB9yN JB4vyiNNRRCHnsnfslQUtSg3VJ5qeQXT + sMFjorpkLWKIkLYG / == 5nRtZr RlmxmZ9RkzVOnlmT1xuuip5QlcSQpOgRKIPdkYrv16D9WPIfxlYs2dbjdAHSHo4ijxoX7VXw

Arenal No. 550. Floor 1. Santa María Tepepan Town. Xochimilco. 16020. Mexico City.

(55) 53340700 www.gob.mx/impi

<img file="MX354192B_D0007.tif" />

im piy

W

SYSTEMS AND METHODS FOR PROVIDING NON-STANDARD PLAYBACK

DURING REPETITION OF CONTINUOUS TRANSMISSION

DESCRIPTION OF THE INVENTION

The following discussion relates to streaming media content over a network, and more specifically, to non-standard playback such as fast forward and reverse streaming media content.

A wide variety of streaming audio, video and / or other media content is now available to users from any number of various sources. Frequently, streaming media content is maintained on a media server that provides the content to the user for playback via one or more wired or wireless telecommunication networks. So-called Internet television, for example, is typically provided as a transmission over the Internet or a similar network. Media broadcasts are also used to provide other types of network-based media content, as well as live and prerecorded broadcast television, on-demand content, and the like.

Although streaming formats can be convenient for many applications, the implementation of non-standard playback (such as forward functions)

J. ·

IMPI

INSTITUTE MI'Zlf »* ', from the prc;': e:&gt;. U lh¡ DuS D'.ÍÁL fast and reverse) is often relatively difficult in many conventional continuous transmission environments. To fast-forward a conventional media stream, for example, some streaming media players simply accumulate decode future content that has been received but not yet played, and then discard those unnecessary decoded media frames.

Conversely, to implement a rollback feature, the video player typically jumps back into a previously received content cache or memory to play back the previously decoded media frames. The rollback feature is often limited, however, to previously received content that is kept in local storage on the player.

If the user wants to roll back beyond the content that remains in the local store, then the previous content typically needs to be fetched from the server and re-decoded to continue the rollback.

This can consume substantial amounts of memory, as well as significant processing resources.

This relatively inefficient operation is especially troublesome for software decoders and the like, which may have limited processing resources.

Furthermore, the non-sequential and irregular nature of

<img file="MX354192B_D0008.tif" />

Many popular streaming media formats can create challenges in identifying the particular media frames that are rendered during most conventional non-standard playback functions. Some fast forward or reverse functions simply forward (or backward) in the transmission by locating and displaying certain keyframes that carry information without dependence on other frames (for example, the I-frames of a conventional MPEG transmission). These keyframes, however, are not typically located at regular intervals or at other predictable locations within the media stream. As a result, Obtaining keyframes frequently involves scanning almost, if not all, the stream to locate the keyframes, and then downloading the remaining decoded content.

Therefore, it is desirable to implement an effective non-standard playback feature that is suitable for use in streaming media applications. Ideally, such a feature can reduce or eliminate the need for additional processing resources or special buffer memory, as well as the need to scan keyframes at irregular intervals. These and other desirable features will become apparent from the description.

IMPI

EXOAI'a INSTITUTE

FROM THE 'RCi lE'. 'AO

INDUSTRIAL detailed below and the appended claims, taken in conjunction with the accompanying drawings and this background section.

In accordance with various modalities, systems and methods are described to provide standard playback functions such as fast forward, reverse or slow motion during streaming media content playback. Many sets of tiny streams or other media objects represented in the same media stream are encoded at different frame rates, and each set of objects is held simultaneously in a network accessible service, such as a media server or network content distribution (CDN). Objects encoded in a first way are made available to the client device during repeat place, and objects encoded in a different way (eg, at a different frame rate and / or frame order) are made available to support non-standard playback. Fast forward or reverse operations, for example, may support tiny streams or other files that provide a lower frame rate than regular repeat stream. For backspace functions, frames can be arranged in reverse order within the media object so that subsequent frames during regular repeat are arranged first in the transmission of

<img file="MX354192B_D0009.tif" />

<img file="MX354192B_D0010.tif" />

recoil. Slow motion (in a forward or backward direction) can be supported using tiny streams or other objects that have a higher frame rate than regular repeat streaming, as desired. Objects that have different frame rates and / or reverse frames can be intermixed to support non-standard playback functions as desired.

Various modes provide a method that can be executed by a computer, media player and / or other client device to process a media transmission received over a network. The method suitably comprises receiving a first portion of the media stream on the client device over the network, wherein the frames in the first portion of the media stream are encoded in a first manner; render the first portion of the media stream for replay; receiving a user instruction on the client device indicating a non-standard playback function; receiving a second portion of the media stream, wherein the frames of the second portion of the media stream are encoded in a different way than the first portion of the media stream; and rendering at least part of the second portion of the media stream for repeat to thereby perform the non-standard playback function.

IMPI

<img file="MX354192B_D0011.tif" />

Other modes provide a method that can be executed by a file server, content distribution system, or other data processing system to provide a media stream to a client device over a network. The method suitably comprises maintaining a first set of files that collectively represents the media stream, where each of the first set of files is encoded at a first frame rate and where the first set of files is arranged so that sequential according to a time index; simultaneously maintain a second set of files that collectively represents the same media stream sequentially ordered according to the same time index as the first set of files, where the second set of files is encoded into a second frame rate that is different from the first frame rate; Sequentially provide files from the first set of files to the client device over the network during normal repetition of media streaming, and provide files from the second set of files to the client device during a non-standard replay operation .

Still other modalities provide a data processing system that provides a transmission of

-' 3

V '- (S. V ¹

IMPI

INSTITUTO MEl.'fWO

OE LA l'ROl. '.' PAO

INDUSTRIAL media to a client device via a network. The data processing system suitably comprises a network interface, a database, and a media server. The database is configured to simultaneously maintain a first set of files and a second set of data files that each collectively represent the same media stream and are each ordered sequentially according to an index. common time. The media server communicates with the database and interface, and is configured to sequentially provide files from the first set of files to the client device over the network during normal media streaming and, in response to a user of the client device instructing a non-standard replay operation, Provides files from the second set of files to the client device during the non-standard replay operation.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the subject matter can be derived by referring to the detailed description and claims when considered in conjunction with the following figures, where similar reference numbers refer to similar elements throughout the figures.

Figure illustrates a technique for generating a

IMPI

INSTITUTE \ 'Ζ. &lt;Α ··. · Ο JE LA ·' ί-ΌΗΐΊν;] -)

RjAL

<img file="MX354192B_D0012.tif" />

media stream suitable for non-standard playback.

Figure 2 is a schematic block diagram illustrating an embodiment of a computing environment in which non-standard playback of a media stream can be performed.

Figure 3 is a flow chart of an exemplary process for processing standard replay operations.

The following detailed description of the invention is exemplary in nature only and is not intended to limit the invention or the application and uses of the invention. Furthermore, there is no intention to link to any theory presented in the foregoing background or the following detailed description.

In accordance with the various modalities described herein, apparatus, methods, and systems present standard playback media display experiences in an implementation of streaming content. In accordance with at least one embodiment, a fast reverse or fast forward viewing experience on a network based streaming stream platform is described. Other modalities can be used to implement broadcast television, video on demand, network television and / or any other desired operation.

Returning now to the figures in the drawings and with

<img file="MX354192B_D0013.tif" />

<img file="MX354192B_D0014.tif" />

<img file="MX354192B_D0015.tif" />

V * initial reference to FIGURE 1, an exemplary embodiment suitably represents a common portion of a media stream using two or more separate and differently encoded media content objects 132, 134, 136. Objects 132, 134, 136 can be encoded at different frame rates, for example, and / or with the various video frames encoded in reverse order to facilitate standard playback operations. In the example in FIGURE 1, object 132 that has a higher frame rate could be used to display content during regular replay, while objects that have a lower frame rate (for example, objects 134 and 136 in this example) , could be used to present the same content in a non-standard playback mode in which fewer frames from the same portion of the media stream are presented to the viewer, but at an accelerated repetition rate. Furthermore, the various frames of content in one or more objects (eg object 136 in FIGURE 1) can be encoded in reverse order compared to other objects 132, 134 to facilitate more effective backward operations when repeating proceeds backward in time. Similar concepts could be applied equivalently to presenting forward and / or reverse slow motion transmission using objects encoded with a higher frame rate, so that

<img file="MX354192B_D0016.tif" />

<img file="MX354192B_D0017.tif" />

allows a higher frame resolution than can be obtained otherwise. Any number of media content objects 132, 134, 136 can be encoded at any number of different frame rates to support any number of faster, slower or equal repetition rates, in a forward or reverse direction, as want.

In the example illustrated in FIGURE 1, object 132 contains approximately sixty video frames 102 providing approximately two seconds of video content (for example, a frame rate of approximately 30 frames / second; exemplary display times shown in FIGURE 1 is based on a repetition rate of 29-97 frames / second, although other rates could be used equivalently). Objects 134 and 136 are shown representing the same two seconds of media content as object 132 with approximately wink video frames 102, so that the frame rate of objects 134 and 136 in this example a quarter of the object

132 (for example, approximately

7-5 frames / second).

Object 136 also shows the various frames

102 arranged in reverse sequence compared to objects 132 and 134 so that during regular repetition they are decoded and present frames that are presented later in time

<img file="MX354192B_D0018.tif" />

<img file="MX354192B_D0019.tif" />

first, so they facilitate a more efficient backward function. Other modalities could encode the objects

132, 134 and

136 (as well as any number of additional objects representing the same portion of the media stream) to have different durations, frame rates, and / or other parameters. Forward and reverse transmissions are not required to have the same frame rates, nor are the same number of forward and reverse transmissions required to be provided. Any number of additional or alternative transmissions having any number of different frame rates proceeding in the forward or reverse direction could be provided in any number of equivalent modes.

By selecting from streams including objects 132, 134 and 136, then, the frame rate of the media stream can be tailored to compensate for user changes in repeat rate. If the user wants to fast forward (or rewind) the media stream at a faster rate than normal, conventional techniques can simply decode the entire stream, even if they then present only a subset of the frames so that the schedule appears to move. at a faster rate. Using FIGURE 1 as an example, the sixty frames in object 132 could be presented

IMPI

<img file="MX354192B_D0020.tif" />

within the two-second time frame during normal repeat. If the viewer wants to fast-forward through the content represented by object 132, one way to accomplish this may be to simply present frames 102 (or a subset of the frames, such as keyframes) contained within object 132 within a shorter period of time. If all frames of object 132 will be presented within a half second, for example, the program would appear to advance at a repetition rate of 4x, with a frame rate that was similarly multiplied by a factor of four (i.e. 120 frames / seconds in this example). Receiving, decoding, and rendering all of this data within this time frame, however, typically can require a relatively large amount of network bandwidth, as well as relatively powerful data processing resources on the client device.

Only a subset of the frames in object 132 may need to be displayed during accelerated repeat (eg fast forward or reverse) to retain the same effective frame rate experienced during regular repeat. That is, the same effective frame rate experienced during regular replay could be preserved during 4x replay using only 25% of the frames contained within

<img file="MX354192B_D0021.tif" />

of object 132. In more conventional implementations, however, the player still needs to identify the keyframes that may occur during accelerated replay, so it still needs to get the entire content of the object to find and process some frames that will actually render . Additional frames on object 132 are discarded at the end, though only after they have been transported and processed by the media player. However, since keyframes are not necessarily separated at regular intervals, keyframe-only repetition may seem uneven and inconsistent to the viewer.

A more efficient procedure may be to use a different 134 or 136 object that provides the same portion of the transmission as object 132, but at a different frame rate that is more suitable for the current repeat rate. If the user commands a 4x repeat rate in the forward direction, for example, object 132 could be replaced with object 134, which contains all the frames needed to support faster repetition without degrading the frame rate. Object 134, despite having fewer frames than object 132, may nevertheless be able to provide an equivalent frame rate as object 132 during faster repetition. However,

<img file="MX354192B_D0022.tif" />

Because object 134 contains fewer 102 frames than object 132, object 134 will typically require less network bandwidth for transport and fewer processor resources for decoding. The particular parameters and values ​​used in this example could be modified in any number of other modes; the frame rate could be increased or decreased when appropriate to provide a desired effective frame resolution for any number of different repeat rates, and / or any number of additional objects can be encoded to represent the same portion of the media stream at any number of different frame rates.

Similar concepts could be used to provide reverse direction repetition, as in a backspace function. In the example shown in FIGURE 1, object 136 differs from objects 132 and 134 in that the various physical frames 102A-N are encoded in reverse time order. That is, frames representing content that appears later in time during normal repeat (for example, frame 102N) is provided within object 136 before frames that may appear previously in time during normal repeat · example, frame 102A). By providing subsequent frames previously in the

<img file="MX354192B_D0023.tif" />

<img file="MX354192B_D0024.tif" />

In object 136, the reverse repeat frames are displayed first during the first frames received by the decoder. The first frame received at object 136 (eg, frame 102N in FIGURE 1), for example, is the first frame displayed during by the reverse repeat. Since the decoder receives 102A-N frames in essentially the same order that they were rendered during reverse repeat, the need to decode and cache additional 102A-N frames before rendering reverse transmission to the viewer is substantially reduced , if not it is removed. Also, repetition will be much finer since frames are provided at regular intervals, compared to techniques that only render keyframes.

Different encoding of the frame rate and / or frame direction can be combined as desired. In the FIGURE 1 example, object 136 is shown to be encoded at a similar reduced frame rate as object 134 to facilitate faster repetition rates, albeit in an opposite direction as object 134. Other modes, however, may encode one or more reverse transmissions at higher or lower frame rates to provide effective reverse repeat at different rates. An additional transmission could

IMPI

<img file="MX354192B_D0025.tif" />

encode at the same frame rate as object 132, for example, but in reverse frame order to facilitate effective reverse repetition at the same rate as normal reverse repetition. Additional higher or lower frame resolution reverse repeat transmissions can be provided in any number of other modes.

In various embodiments, each media content object 132, 134, 136 is a tiny transmission, file, or similar data object representing a particular portion of the general transmission made available to the user. In such embodiments, each data object can be created to represent a particular portion of the original media stream that has a predetermined length of time, such as the two-second duration shown in FIGURE 1. In other embodiments, the predetermined length of time can be incorporated in the range of about 0.1 to 8.0 seconds, for example, although other predetermined lengths can be used equivalently. Furthermore, the media content in the object may have a unique time index with respect to the beginning of the media content contained in a transmission. The various objects can be arranged equivalently in a spatial way (for example, arranged and indexed according to a file size) or

IMPI

<img file="MX354192B_D0026.tif" />

in any other way.

Other modes may provide media objects that are not necessarily grouped or otherwise distributed as separate files, but in fact provide relatively continuous streams of media content along with a table or other metadata that identifies keyframe locations or similar that are used in non-standard reproduction. In such modalities, metadata can typically provide a common time or other index that enables switching between continuous streams while preserving the continuity of the viewer's experience. The various objects or portions of the media stream could therefore be identified through metadata processing even if separate files or tiny streams are not available.

In various embodiments, multiple sets of media objects are suitably generated using common space or time indices so that objects from different sets can be intermixed sequentially as the user requires different repetition rates or repetition directions. That is, an object in a first set of objects can be followed by an object to a different set that has different encoding parameters, but which nevertheless provide the portion

<img file="MX354192B_D0027.tif" />

<img file="MX354192B_D0028.tif" />

of the media stream in the form expected by the viewer for non-standard playback operation. Switching between sets of different objects allows responsible adaptation to network conditions, user instructions and / or the like while preserving the visual continuity of the programming transmission expected by the viewer. In the example presented in FIGURE 1, replacing object 132 with object 134 or object 136 preserves the viewer's visual continuity, since objects 132 and 134 in this example are time indexed according to a time index of common display, thereby ensuring that the content represented in objects 132, 134 and 136 represents the same portion of the general media content, albeit at a different frame rate and / or direction.

Referring now to FIGURE 2, an exemplary computing environment 200 for making available a media stream to one or more client devices 204 over a network 245 suitably includes a communication interface 237, a database 238 that stores two or more sets 232-236 of media objects, and a media server 210 that sequentially provides the various particular objects from various sets 232-236 to client devices 204 via network 245, as desired. The computing environment 200 may also include a

INSTITUTE · ν.

OF THE FXCLIEDAD

INDUSTRIAL

<img file="MX354192B_D0029.tif" />

media content source 205 and encoder 220 as desired, although other modes may perform the encoding function entirely separate from the content distribution function.

Content server 210 and client devices 204 are capable of communicating using one or more data communication networks 245, such as the Internet and / or one or more common local area networks (LANs), personal area networks ( PAN), campus area networks (CAN), metropolitan area networks (MAN), wide area networks (WAN), wireless local area networks, cellular networks, virtual local area networks, any combination of the above, and / or the like. Other modes may allow communications between content server 210 and client devices 204 in any other way.

Client devices 204 are any suitable device that can be configured to receive audio, video, and / or other media content from media server 210 over one or more streaming connections 241. Examples of client devices 204 could include (without limitation) client workstations, servers, personal computers, portable electronic devices, mobile phones, personal digital assistants, video game systems, entertainment systems, converter-decoder boxes,

<img file="MX354192B_D0030.tif" />

<img file="MX354192B_D0031.tif" />

digital receivers, digital televisions, time or location change devices, and / or other electronic devices as desired. In some implementations, the client device 204 may be implemented using a general-purpose computing system that runs software or firmware to provide a media player application 201, as appropriate. Media player 201 may be a piece of software that plays the media content (eg, displays video and displays audio), such as any kind of stand-alone software application, web browser add-on program, combination of browser add-on programs and support web search logic, or the like.

FIGURE 2 shows a content source 205 that provides a media stream 206 to an encoder 220, as appropriate. In the embodiment depicted in FIGURE 2, the media source 205 may be a publisher server, a publisher content repository, a creator or distributor of media content, and / or any other source of audio, video or media content. multimedia you want. For example, if the media content 206 to be broadcast continuously is a broadcast of a television program, the source 205 may be a server affiliated with a television or cable network channel, such as the ABC® channel, or the MTV® channel. The publisher can transfer the

IMPI

<img file="MX354192B_D0032.tif" />

media content 206 over the Internet or other network to encoder 220, which is suitably configured to receive and process media content 206 to create any encoded transmission numbers 232, 234.

Each encoded transmission 232, 234, 236 suitably represents a set of media objects (eg objects 132, 134, 136) each having different frame encoding parameters (eg, frame rate, frame address and / or the like). Each of these streams 232-236 can be stored in the database as a set of tiny streams or the like that collectively represent a copy of the original media content 206. Generally speaking, each of the different sets 232-236 of objects will share a common time or other index so that the objects of different sets 232-234 can intermingle with each other when the objects are made available to client devices 204, by allowing content streaming to be tailored to network conditions, user input, and any other appropriate factors.

The various objects can be stored as one or more separate files or sets of files on any one or more content servers, web servers, database servers, cache servers,

<img file="MX354192B_D0033.tif" />

xi proxy caches, or other devices on the network, such as is found on a conventional content distribution network (CDN) 240. In various embodiments, objects are stored within database 238, as desired, for subsequent retrieval by media server 210 so that objects can be made available to client devices 204.

Interface 237 is any kind of interface card, server, and / or other computing hardware that is capable of facilitating communications between media server 210 and one or more client devices 204. In various embodiments, the media server 210 can be implemented with a conventional computer server (which includes any conventional computing hardware, any kind of virtual cloud-based server, and / or the like), with interface 237 facilitating network communications between media server 210 and one or more client devices 204. Other embodiments may allow client devices 204 to retrieve media objects from more than one media server 210 within CDN 240, as desired. Interface 237, thereafter, may be a simple interface card that can be used by a particular server, or equivalently, an interface server that can provide load balancing, routing, authorization and / or authentication, firewall services, or others

<img file="MX354192B_D0034.tif" />

<img file="MX354192B_D0035.tif" />

desired characteristics.

Although a connection 241 to media server 210 and / or CDN 240 has been illustrated in FIGURE 2 for each client device 204, each connection 241 can logically represent multiple network connections to CDN 240. In one embodiment, each device 204 Client is capable of establishing multiple Transport Control Protocol (TCP) or other connection 241 to CDN 240 via network 245. In another mode, media content is stored on multiple CDNs. The content can be stored, for example, on the origin servers associated with each of the multiple CDNs. The CDN 240 can be used for the purpose of improving performance, scalability and cost efficiency for end users (eg viewers) by reducing bandwidth costs and increasing the overall availability of content. In other embodiments, other techniques may be used to make the media content available to the media players on the source servers, such as peer-to-peer networks, or the like. Also, although media server 210 has been illustrated as started within CDN 240 in FIGURE 2, server 210 may reside equivalently outside of CDN 240 and still associate with CDN 240.

As described above, each transmission

234, 236 non-standard reproduction represents a copy of

<img file="MX354192B_D0036.tif" />

MEXICAN INSTITUTE OF THE ero; ieua:&gt; industrial

<img file="MX354192B_D0037.tif" />

the original media stream at a different frame rate and / or direction than the regular repeat stream 232, as described above. Each of these representations is stored in media server 210, database 238 and / or another part of CDN 240, as appropriate. The various transmissions 232-246 can be stored as separate files and other objects that can be requested independently, can be distributed and / or can be reproduced by the client device 204. Each of the encoded objects can store on one or more content servers 210, on the web servers, proxies, CDN edge caches 240, and can be requested separately and made available to the client device 204.

The various concepts described herein can be implemented using client-driven, server-driven continuous transmission implementations, and / or any combination of client-driven and / or server-driven. In various embodiments, server 210 typically selects which content objects to send to client device 204 based on user input and / or other information provided by client device 204. In other embodiments, client device 204 determines which particular content objects to request from content server 210. Devices 204

<img file="MX354192B_D0038.tif" />

ITUT'J MU.laí 'U 1

OF THE fh-CPÍLC'AD * r

INDUSTRIAL client, for example, can request separate objects from media server 210 using conventional protocols, such as hypertext transport protocol (HTTP) or the like. One type of request that could be used in pull scenarios is an HTTP GET or similar request, although other modes can use any number of other mechanisms to request tiny streams or other objects from server 210.

Various modes are therefore capable of making media streaming available using a sequence of objects 132, 134, 136. The objects are selected by client 204 or server 210, and the selected objects are provided sequentially from server 210 up to client 204 via network 245. In many embodiments, where the client device 204 initiates requests for objects, a conventional web-like file server can be used to retrieve and serve the requested objects, thereby reducing the need for specialized servers to support specialized media transmissions. while retaining the ability to perform non-standard playback functions as streaming is provided.

Other modalities may use different techniques to provide media content over the network.

245. Some modalities, for example, can store the

<img file="MX354192B_D0039.tif" />

'AL contained in a single file or divided into chunks that can be cached on CDN 240 and / or requested using HTTP margin requests or the like. Other modes may provide adaptive content streaming using RTSP or other protocols, as desired. In some implementations, RTSP or other protocols may be encapsulated within or otherwise transmitted using TCP, UDP, RTP, HTTP, and / or other transport protocols to facilitate distribution through firewalls, or for any other purpose. Again, the use of standard protocols, such as HTTP or the like, frequently reduces or eliminates the need for network administrators to configure firewalls to recognize and pass network traffic for specialized protocols.

Any number of equivalent variations could be formulated.

Any number of transmissions 234,

236 Additional non-standard playback can be created by encoder 220 in a similar way as the pull-based configuration described above. The additional encoded content files may be stored as appropriate, such as in database 238. Objects can be selected on player 201 or another portion of client device 204, by logically executing within server 210, or at any other location such as

<img file="MX354192B_D0040.tif" />

'1

<img file="MX354192B_D0041.tif" />

desired. The selected objects can then be provided in any way from the server 210 to the client device 204 for repetition. The various non-standard reproduction concepts described herein could therefore be applied to insert or extract concepts, or other network distribution techniques that are based on client-side, server-side logic, or any logical combination client side and server side.

Many modes can be further enhanced with adaptive streaming capabilities to adjust the quality of regular or non-standard playback streaming in response to network conditions, player capabilities, or other factors as desired. To implement adaptive continuous transmission, the encoder repeat transmission 232

220 additionally encodes

<td>normal and / or</td><td>a</td><td>or more than</td><td colspan="2">the transmissions</td><td> 234,</td><td>236 of</td>

<td colspan="2">reproduction no</td><td>standard</td><td>in several</td><td>profiles</td><td>of</td><td>quality</td>

<td>different.</td><td>The</td><td>profiles</td><td>quality</td><td colspan="3">each one represents</td>

<td>different</td><td colspan="2">such parameters</td><td>as the</td><td>way in</td><td>the</td><td>which one</td>

<td>will encode</td><td colspan="2">the broadcast,</td><td>the width and</td><td>the height</td><td>of</td><td>the picture</td>

video of (i.e. the image size), the bitrate (say, the rate at which the video is encoded), the rate of the rate at which the audio is sampled when captured), the audio bits, the audio sampling rate (ie the «

or

IMPIf

MEXICAN INSTITUTE

OF THE PROPERTY (\._vINDUSTRIAL number of audio tracks (eg monophonic, stereophonic, or the like), frame rate (eg, frame per second), display size, or the like.

Various client devices 204 can process different levels of quality of the same media content 206, depending on the application, viewer preferences, device capabilities, network throughput, or any other factors. Some implementations may make different quality profiles available for client device 204, as desired. In such embodiments, different media players 201 may receive the same portion (eg, the same time index) of the media content, but at different levels of quality. For example, a media player 201 may request a tiny stream that has HD-quality video, since the requesting media player's computing device has sufficient computing power and sufficient network bandwidth, while another media player 201 may request objects that have lower quality, since your computing device may not have enough network bandwidth, for example. In one embodiment, media player 201 switches between quality levels at portion boundaries by requesting portions of different copies (eg, broadcasts of different quality) of the media content, as described

WMi ». minj-i

<img file="MX354192B_D0042.tif" />

MEXICAN INSTITUTE OF JA PROPlEJl- r INDUSTRIAL

<img file="MX354192B_D0043.tif" />

in US Patent Application Publication No. 2005/0262257, filed April 28, 2005. Alternatively, media player 201 requests portions that use other techniques that may be appreciated by those of ordinary skill in the art that have the benefit of this disclosure. The various quality parameters used in the encoding can be combined as desired, and used to complement the various types of frame encoding described herein. For example, at least one transmission 242 can be encoded having a relatively low frame rate to support non-standard playback that has a relatively high bit rate to maintain image quality even during non-standard playback operations. Any number of different transmissions that have any variety of parameters can be encoded and processed in some way in various ways.

To implement the non-standard playback features, then, media objects that have an appropriate frame rate and / or frame direction to support desired repetition are provided from server 210 to media player 201 or other device component. 204 customer. Particular tiny transmissions or other objects can be selected and requested by player 201 of

<img file="MX354192B_D0044.tif" />

means (eg, using an HTTP GET statement) in some implementations, while other implementations may respond to user input or other appropriate information to provide objects that are selected on server 210, in database 238, and / or or anywhere else in the 200 environment for the client device 204 as desired.

In various modes, the repetition of the various transmissions can be varied and controlled to support non-standard reproduction at any repetition rate, such as 3X, 0.5 x, lOx, 7-5, or any other multiple. The media player 201 adequately renders the frames at the appropriate intervals to obtain the desired reproduction rate. Because the repeat rate is variable, the player can calculate and change the rate to speed up or slow down continuously in many implementations. In other embodiments, the encoder encodes two or more special streams at different lower frame rates (eg, four frames / second and eight frames / second). Media player 201 (or server 210, when appropriate) can calculate which stream to use to generate the finest rendering of the desired multiple rate without increasing the load on the CPU or decoding hardware. Also, frames can be encoded in

<img file="MX354192B_D0045.tif" />

SX

<img file="MX354192B_D0046.tif" />

<img file="MX354192B_D0047.tif" />

direct or reverse order, as described herein,

<td rowspan="2">for</td><td colspan="3">endure reverse repeat like</td><td colspan="3">desired.</td>

<td>The</td><td>FIGURE 3 is</td><td>a diagram</td><td>of</td><td>flow of</td><td>a process</td>

<td> 300</td><td>copy</td><td>what could</td><td>be used</td><td>in</td><td>some</td><td>modalities</td>

to implement non-standard playback features such as fast forward, reverse and / or slow motion repeat (in either forward or reverse direction) of a media stream. The various functions shown in FIGURE 3 can be implemented in software or firmware that can be stored in any non-transient medium (for example, memory or mass storage within client device 204) and that can be executed by any kind of microprocessor, microcontroller, processor digital signal, or other programmable logic. Several implementations can implement almost, if not all of the process 300 within the client device 104, while other implementations can implement various functions (eg, functions that refer to the selection of a particular object or object transmission) with media server 210 or other portion of CDN 240. In the particular medium used to implement the various functions shown in FIGURE 3, therefore, it may vary from mode to mode.

Process 300 suitably includes broadcast functions to initiate a repeat rate and repeat address (function 302), obtaining a media object that corresponds to the repeat rate and direction (function 304), decode, and repeat the object obtained (function 306) the response to a user input 310 and directing a non-standard playback feature to adjust the repeat rate (functions

308,

312) or repeat address (functions

309, 314) as desired.

The basic functions shown in FIGURE can be modified, supplemented, or organized differently in any logical, temporal, or other way, as desired.

As noted above, non-standard playback characteristics can be implemented and / or improved through the use of tiny streams or other media objects 132, 134 that have different characteristics suitable for the particular repeat parameters desired by the viewer or another user. Note that tiny transmissions or similar objects 132, 134, 136 from various transmissions or sets 232, 234, 236 can be obtained sequentially and intermingled with each other based on a temporal or spatial index. Items can be obtained sequentially! in a direct or reverse direction to withstand repetition at any high level of user control.

speed and in any direction, so it allows a

<img file="MX354192B_D0048.tif" />

<img file="MX354192B_D0049.tif" />

Repetition can be performed initially at any rate, and in a direct or indirect direction (function 302). In some modes, repeat can initialize with a freeze frame or still image, as desired. Function 302 suitably involves setting initial parameters to obtain objects 132, 134 from suitable media, as desired.

Media objects 132, 134 can be obtained in any way (function 304). In various embodiments, client device 104 suitably obtains a suitable tiny stream or other media object from server 210 as appropriate. Such requests can be made using, for example, HTTP or similar protocols to obtain file-like objects from a conventional CDN or other web-like server accessible by the Internet or other network. Equivalently, objects can be provided to client device 204 using RTSP or other streaming protocols. In various embodiments, tiny transmissions or similar objects 132, 134, 136 can be identified by client device 204 and / or media server 210 using any kind of naming or file identification format. Objects 132, 134, 136 can be located by name or uniform resource locator (URL) within database 238, for example. In some modes, the name of each object

<img file="MX354192B_D0050.tif" />

<img file="MX354192B_D0051.tif" />

132, 134, 136 is determined at least in part from the relative time or spatial index value that corresponds to the object, and / or from the transmission or transmission set 232-236 that includes object 132, 134, 136 particular. Other modalities can identify objects through a data table or other structure, through metadata that identifies relative locations in one or more continuous data streams, or in any other way.

Still other modes can select and get the appropriate objects using server-based logic as described above, or the like. Particular media objects are selected by client 204 and / or by server 210 in any way. The selected objects are then provided from server 210 to client 204 using any kind of file-based distribution techniques (for example,

<td>distribution</td><td>of transmissions</td><td>tiny u</td><td>others</td><td>records</td><td>in</td>

<td>answer to</td><td>the requests</td><td>GET's</td><td>HTTP)</td><td>based</td><td>in</td>

<td>transmissions</td><td>(for example,</td><td>RTSP), and / or</td><td>others</td><td>techniques</td><td>of</td>

distribution.

The received media objects are decoded and rendered for repeating as desired (function 306).

Replay is typically performed by media player 201 or the like running on the device

204 client and uses conventional techniques in accordance with

<img file="MX354192B_D0052.tif" />

IMPI

INSTITUTE ΜΕΛΙΟ'- · O

Ι »ΙΛ PRoHEDAD

INDUSTRIAL current parameters that govern the speed and / or direction of repetition. Rendering the media content for replay could, in various embodiments, involve displaying the decoded content on a screen associated with the client device 204 itself (eg, a screen on a computer system, mobile phone, or the like). Alternatively, rendering the content for replay may involve providing signals that represent the content on a television or other external display (for example, a television receiver or converter box may render the content by providing suitable output signals and a television u other screen). Other ways to render content for replay may consider changing location or other remote viewing concepts, as desired.

If the user provides an input 310 to change the repeat of the media stream, then the tiny streams or other media objects 132, 134, 136 of media having different parameters can be obtained during requests for subsequent items or inserts and / or Repeat parameters can be adjusted to accommodate the set of available objects as desired.

If the viewer wants to change the repetition rate (function 308), for example, then the objects *

<img file="MX354192B_D0053.tif" />

Mexican INSTITUTE

OF THE PXOHFFuú, INDUSTRIAL

Media 132, 134 encoded at a frame rate more suitable for the new repetition rate (function 312) can be obtained during subsequent object requests. As the repeat rate increases, it may be desirable to obtain a tiny stream or other media object 134, 136 that has a lower frame rate for an equivalent period of time. Conversely, if the repeat rate is decreased (for example, to support a slow-motion feature), then objects with the same number or additional frames may be desirable to maintain the effective frame rate through the lowest repeat rate. . If a media object 132, 134, 136 that has the particularly requested optimal frame rate is not available, then subsequent requests can simply select an object with a frame rate that approximates much more than the desired rate, but nonetheless Provide enough data to maintain image consistency. If the viewer requests an 8x replay rate but only lx and 4x streams are available, for example, then the 4x stream can be selected, with subsequent replay discarding unused frames. Although this may not be efficient enough to receive a pre-encoded media object at the requested rate,

<img file="MX354192B_D0054.tif" />

<img file="MX354192B_D0055.tif" />

will conserve processing bandwidth compared to repeat

8x based only lx media. The rates are finely charged by the user when

If the alternatively (function 309), encoded can still according to network and processing resources in the transmission of the other, or other desired playback.

they can be changed in ways controlled by user input, change additionally or in the desired direction thereafter inversely recover from repetition tiny transmissions or other servers time, space or other media objects 136

210 in index sequence; the sequence direction is simply reversed (function 314). Backspace functions, for example, could be processed by retrieving objects from reverse transmission 236 in numerical sequence, but moving backward in time (for example, forward processing in null time, or at the start of programming). In embodiments where objects 136 are tiny streams or similar discrete files requested from a server 210, the process for receiving previous objects is relatively convenient since the files can simply be requested in numerical or other indexed order. This conventionally allows backspace functions to not typically be restricted to previously decoded and memory-locked content.

INSTITUTE, ΜΖΧΙ - .. ··. &gt;

SAY THE PROPERTY: JAÍ&gt;

INOUSTKiA !.

cache, as was typical in many conventional streaming media implementations. In some situations, reverse repeating for relatively short periods of time may be possible using only a single tiny transmission or other object, thereby reducing or eliminating the need to obtain multiple objects from server 210.

Also, in modes where objects 136 have reverse order encoded frames are available, frames 102 are received using essentially the same order in which they are decoded and rendered. Rather than decoding and caching the frames so that the last received frame can be played back first, then the frames 102 on each object 136 are simply played back in essentially the same order that they are received. This can substantially reduce memory consumption and processor load, thereby greatly improving performance (or allowing rollback features on devices that may not otherwise have such capacity).

The general process of obtaining media objects (function 304), rendering media objects obtained for repetition (function 306), and adjusting repetition in response to user inputs 310 can continue through any number of iterations as

<img file="MX354192B_D0056.tif" />

<img file="MX354192B_D0057.tif" />

<img file="MX354192B_D0058.tif" />

MEXICAN INSTITUTE

DE LA l'K &lt;TIEIMD INDUSTRIAL

<img file="MX354192B_D0059.tif" />

want. In modalities where common indexing is shared across separate streams having different encoding parameters, objects from any number of different streams can be intermixed in sequence to maintain image continuity to the viewer, as described above.

This could allow fine acceleration or slowdown of the repetition rate forward or backward, for example, thus providing a very pleasant user experience while conserving bandwidth and computing resources.

Also, because the received transmission is provided in a way that is selected based on the desired repeat mode (eg fast forward / slow forward / reverse), the processing to decode and render the received transmission is greatly simplified measure. The decoder simply decodes the various frames essentially in the order received, with no substantial regard to repetition rate or direction,

<td>since the object</td><td> 132, 134,</td><td>136 media</td><td colspan="2">received</td><td>I know</td>

<td colspan="2">encoded specifically for</td><td>provide</td><td>the</td><td>mode</td><td>of</td>

<td>repetition required by</td><td>the user.</td><td></td><td></td><td></td><td></td>

<td>The various</td><td>techniques</td><td>described in</td><td>the</td><td colspan="2">Present</td>

they can allow any number of convenient interfaces and other features for the viewer. Various modalities

<img file="MX354192B_D0060.tif" />

MEXICON INSTITUTE&gt;

OF THE ΡΚι '· ΊΕΓΆ »&gt;

INDUSTRIAL may respond to inputs provided on a virtual or real selector dial, rotary control, selector bar and / or other input to fine-tune the repeat rate in a way that simulates varying the speed of a videotape machine or similar device Similary.

In such modalities, continuously variable rate changes (or changes or a multiple rate can be made regardless of the initial repeat rate that was in use before non-standard playback. A user can start paused video repeat, for example, and then proceed to search forwards or backwards to locate the desired content.The user can then return to the zero speed state when the user finds what he wants.

Fast-forward and slow-motion effects can be similarly controlled by a disc in a hardware or software user interface. For example, the more the user rotates the disc to move forward or back, for example, the faster or slower the repeat rate produced on the screen. The repetition rate can be suitably varied continuously fine. In some implementations, the speed could return to the initial stable repeat state (for example, paused, regular repeat, or the like). In a modality, a track bar or

MEXICAN INSTITUTE.

FROM OWNER.

INDUSTRIAL rotary control could be implemented in a PC player interface to simulate spring-loaded mechanical controls that drift to a zero-effect position when the user releases the control. Various modes therefore provide a very enjoyable spectator experience that allows the user to control the replay at their own pace. These exemplary modalities provide better usability and appeal to replay experiences in the context of streaming, and provide replay experiences that are similar to traditional TV replay experiences. Other modes can provide different features, including other types of user interfaces when appropriate.

In the preceding description, numerous details are set forth. However, it will be apparent to someone with ordinary skill in the art that has the benefit of this description, that many different modalities can be practiced without these specific details. In some cases, well-known structures and devices are shown in block diagram form, rather than in detail, to avoid obscuring more relevant details.

Portions of the detailed description above are presented in terms of algorithms and symbolic representations of jf s bit operations.

data inside a computer memory. These algorithmic descriptions and representations are the means used by those experienced in the data processing technique to more effectively carry the substance of their work to others with experience in the

<img file="MX354192B_D0061.tif" />

I institute m ex ic PE The ERONEDaO INDUSTRIAL tecnica. An algorithm here is, and is generally intended to be a self-consistent sequence of steps leading to a desired result. The stages are those that require physical manipulations of physical quantities. Typically, although not necessarily, these quantities are in the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and manipulated in a certain way. It has been proven that it is sometimes convenient, mainly for reasons of common use, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

It should be noted, however, that all of these terms and the like will be associated with the appropriate physical quantities and only convenient labels applied to these quantities. Unless specifically stated otherwise as is apparent from the discussion herein, it is appreciated that during the description, discussions using terms such as receive, encode, generate, divide, process, compute, value,

<img file="MX354192B_D0062.tif" />

<img file="MX354192B_D0063.tif" />

determine, display, or the like, may refer to the actions and processes of a computer system, or similar electronic data processing system, that manipulates and transforms data presented as physical quantities (eg, electronic) quantities within records and computer system memories within other data similarly represented in physical quantities within the computer system memories or records or other information store, transmission or display devices.

Various modalities may also refer to an apparatus for performing the operations herein. This apparatus may be specially constructed for the stated purposes, or 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 as software or firmware in the form of source or object code on any non-transient computer-readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROM and magneto-optical discs, read-only memory (ROM), random access memory (RAM), flash memory, EPROM, EEPROM, magnetic or optical cards, or any type of suitable means to store electronic instructions.

<img file="MX354192B_D0064.tif" />

<img file="MX354192B_D0065.tif" />

The term exemplary is used herein to represent an example, case, or illustration that may have any number of alternatives. Any implementation described herein as exemplary should not necessarily be construed as preferred or advantageous over other implementations. Although various exemplary embodiments have been presented in the detailed description above, it should be appreciated that a vast number of alternative but equivalent variations exist, and the examples presented herein are not intended to limit the scope, applicability, or configuration of the invention in any way. shape. Rather, various changes may be made in the function and arrangement of the various features described herein without departing from the scope of the claims and their legal equivalents.

<img file="MX354192B_D0066.tif" />