Low latency streaming

Abstract

Methods and systems for discovering or tuning to an upcoming live or current playlist for streaming media content, particularly for a live event during which media content is streamed. The method and system can reduce the time required to tune into such a live event. In one embodiment, a client device can receive duration data in a header of a message that returns a first playlist requested by a non-attributed playlist request from a client device. The duration data can be used to determine how many portions of media segments to skip in order to tune into the live event.

Description

[0001] This patent application claims the benefit of U.S. Provisional Patent Application No. 62 / 873,664, filed on July 12, 2019, which is incorporated herein by reference. Background Art

[0002] This patent application is related to U.S. Provisional Patent Application No. 62 / 807,329, filed on February 19, 2019, with inventor Roger N. Pantos and entitled “Low Latency Streaming Media,” and this provisional patent application is hereby incorporated herein by reference.

[0003] Many devices currently use streaming content delivery systems to present content, such as movies, television programs, recorded sports events, news programs, live events (such as live sports events, live news events, etc.). These streaming content delivery systems typically use one or more playlists that enumerate an ordered series of uniform resource identifiers (URIs) (such as uniform resource locators (URLs)) to identify media segments that can be retrieved from one or more servers using conventional HTTP-compliant requests. Once retrieved, the media segments can be presented on the client device that requested the media segments, and then erased on the client device after each media segment is presented. These streaming content delivery systems can display recorded content, such as movies or video-on-demand content, or live content, such as live sports events or live news events that occur while the user of the client device is watching. Existing streaming content delivery systems include systems based on DASH (dynamic adaptive streaming over HTTP), which are based on standards (e.g., ISO / IEC 23009-1:2014), and systems based on Apple's HTTP Live Streaming (HLS) from Apple Inc. Summary of the invention

[0004] The present disclosure describes various techniques, systems, non-transient machine-readable media and methods for reducing latency or otherwise improving the delivery or processing of streaming media content, particularly when tuning to a live event presented by streaming media. When a client device initially tunes to a live event when the event occurs, the client device will not have information about a specific media segment at the end of the current playlist at the source of the streaming content. Therefore, the client device can only request a general non-attributed playlist of content, which may be many seconds later than the current time in the live event. If the user of the client device wants to see the live event when it occurs, the client device must attempt to tune to the latest content represented by the latest playlist obtained from the source. The client device can discover the latest content by obtaining the playlist directly from the source. However, for many viewers, this direct method represents an unacceptably high burden on the source server. Therefore, the client device usually obtains the playlist from an intermediate cache server, which stores the playlists and the media segments identified in those playlists, so that many viewers can be distributed on multiple cache servers. In order to reduce the load on the source server, those cache servers continue to cache the playlist for a period of time after updating to the newer version from the source server. Therefore, the playlist delivered to the client by the cache server may not be the latest version. The various aspects described herein can improve the speed at which the client device can tune to the live event to obtain the latest playlist from the cache server. Those aspects can use the data in the playlist, such as one or more of the following: media sequence number, part number, part target duration, and duration data (age data) in other headers associated with the playlist response, to calculate the amount of the last part of the media fragment to be skipped forward or crossed at the end of the playlist (such as the playlist received as a response to a non-attributed playlist request). For example, the client device can use the duration indicated in the duration data to determine the number of partial media fragments to be skipped forward of the last part of the media fragment.

[0005] According to one aspect, a method for tuning to streaming content on a client device may include the following operations: requesting a first playlist for media content by a first request, the first request not including at least one attribute of a near live playlist for the media content; receiving the first playlist in a manner consistent with a transmission protocol, the first playlist including a plurality of uniform resource identifiers (URIs) indicating a playback order of a plurality of media segments that can be received in a manner consistent with the transmission protocol for recreating the media content, the first playlist including a last URI in the order, the last URI identifying a last available media segment (e.g., a last partial media segment) in the first playlist; if provided, receiving first duration data associated with the first playlist, the first duration data indicating a duration of the first playlist on a cache server; determining a first number of at least partial media segments after the last available partial media segment in the first playlist based on the first duration data and based on the last URI, the first number specifying a number of at least partial media segments to be skipped after the last available partial media segment to tune to the media content. In one aspect, the last URI includes a media sequence number and a portion number, and the first playlist specifies a target duration and a partial target duration. In one aspect, a first quantity of the at least partial media segments is determined based on: (1) the first duration data and (2) the last media sequence number and portion number in the last URI, and (3) the partial target duration. In one aspect, the partial target duration is compared to a predetermined minimum duration value, and the result of the comparison provides a base value based on which the first quantity is determined. In one aspect, the predetermined duration value may be equal to 1, and if the partial target duration is greater than a duration of one second, the base value may be the first duration data, and if the partial target duration is less than one second, the base value may be the first duration data plus a first additional value (such as 1).

[0006] In one aspect, the method may further include the following operations: determining a first time period between the current time and one of the following items: (1) the time when the first request is requested, or (2) the time when the first playlist is received. In one aspect, the method may further include: adding a second additional value to the base value, the second additional value based on the first time period. In one embodiment, the first number can be the sum of the base value, the first additional value (when the partial target duration is less than one second), and the second additional value. According to one aspect, the method may further include the following operations: requesting a second playlist with a URI based on the first number; receiving the second playlist and second duration data; and updating the base value based on the second duration data. According to one aspect, the method may further include the following operations: comparing the second duration data with the partial target duration to determine whether to exit the tuning mode.

[0007] In another aspect described herein, a method performed by a client device to tune into streaming media may include the following operations: requesting a first playlist for streaming media content during a tuning mode by a non-attributed request, the non-attributed request lacking an attribute of a live adjacent playlist for the streaming media content; receiving the first playlist in a manner consistent with a transport protocol, the first playlist including a plurality of uniform resource identifiers (URIs) indicating a playback order of a plurality of media segments that can be received in a manner consistent with the transport protocol for recreating the media content, the first playlist including a last URI in the order, the last URI identifying a last available media segment (such as a last partial media segment) in the first playlist; determining whether first duration data is received with the first playlist; and exiting the tuning mode in response to determining that the first duration data is not received or that the first duration data has a minimum value if the first duration data is received. In one aspect, the minimum value may be zero. In one aspect, the method may further include the following operations: determining a first number of at least partial media segments after the last available media segment in the first playlist based on the difference, the first number specifying the number of at least partial media segments to be skipped after the last available media segment to tune to the streaming media content. In one aspect, the difference may include a difference between a first date header and a last modified header, wherein the first date header includes a timestamp of a time when the cache server responded to the request for the first playlist, and the last modified header includes a timestamp of a time when the first playlist was last modified. In one aspect, the method may further include the following operations: requesting a second playlist having a URI based on the first number; and receiving the second playlist.

[0008] According to another aspect, a set of rules used by the source server can also be implemented to improve the temporal tuning of the client device. In one specific implementation, these rules can include: always providing the last modified date data in one or more headers together with the playlist (the latest playlist at the source server). Therefore, when tuning into the live event, the source server can provide the last modified date data for the client device to use. In a specific implementation, the source server can also be configured to accept requests for playlists that exceed the current live playlist at the source server by up to two or three partial media segments. In one aspect, the source server can implement a restriction on the minimum partial target duration; according to one aspect, the minimum partial target duration can be, for example, 300ms, and therefore according to this specific implementation example, all partial target durations must be equal to or exceed 300ms. On the other hand, the cache server can comply with the rule that the duration data from the cache server is provided with millisecond accuracy. Currently, the duration data in the standard duration header represents the duration of the cache object in full (integer) seconds, without further time resolution of how long the cache object has been cached at the cache server. A non-standard duration header ("X-age-ms" header) will indicate the cached age (how long the cached object has been cached) with millisecond accuracy. This will allow client devices to more accurately view the duration of cached playlists (at the cache server), which in some cases can reduce the tuning time of client devices.

[0009] Aspects and embodiments described herein may include a non-transitory machine-readable medium storing executable computer program instructions that, when executed by one or more data processing systems, may cause one or more data processing systems (such as a client device and one or more server systems) to perform one or more methods described herein. The instructions may be stored in a non-volatile memory, such as a flash memory or a dynamic random access memory or other form of memory.

[0010] The above summary does not include an exhaustive list of all aspects and embodiments of the present disclosure.All systems and methods can be practiced according to all suitable combinations of the various aspects and embodiments of the above summary and those disclosed in the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The aspects described herein are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like reference numerals refer to similar elements.

[0012] Figure 1An example of a system for delivering content from one or more origin systems to one or more client devices via streaming media is shown with an origin server coupled to the client devices via one or more content delivery networks (CDNs).

[0013] Figure 2 An example of two media segments is shown, each divided into six parts, with part numbers displayed within each media segment identified by a media segment number (MSN).

[0014] Figure 3 is a flow chart that may be used by a client device to tune to streaming media content illustrating one aspect of the present disclosure.

[0015] Figure 4A is a flow chart that may be used by a client device to tune to streaming media content illustrating another aspect of the present disclosure.

[0016] Figure 4B is a flow chart that may be used by a client device to tune to streaming media content illustrating another aspect of the present disclosure.

[0017] Figure 5A and Figure 5B A flow chart representing a method that may be performed by a client device according to another aspect of the present disclosure is shown.

[0018] Figure 6 An example of a data processing system that can be used to implement one or more aspects described in this disclosure is shown. DETAILED DESCRIPTION

[0019] Various embodiments and aspects will be described with reference to the details discussed below, and the accompanying drawings will illustrate the various embodiments. The following description and drawings are illustrative and should not be construed as limiting. Many specific details are described to provide a comprehensive understanding of each embodiment. However, in some instances, well-known or conventional details are not described in order to provide a concise discussion of the embodiments.

[0020] References to "one embodiment" or "embodiment" in this specification mean that certain features, structures, or characteristics described in conjunction with the embodiment may be included in at least one embodiment. The phrase "in one embodiment" appearing in various locations in this specification does not necessarily refer to the same embodiment. The processes depicted in the subsequent figures are performed by processing logic components including hardware (e.g., circuits, dedicated logic components, etc.), software, or a combination of the two. Although the process is described below in terms of certain sequential operations, it should be understood that certain operations described may be performed in different orders. In addition, certain operations may also be performed in parallel rather than sequentially.

[0021] These existing systems may have difficulty delivering live event content in a manner with low latency relative to the live event. For example, for a live sports event that occurs while a user is watching the live sports event using a streaming media system, the action occurring in the live event may not be displayed until several seconds (e.g., 15 seconds or more) after the live event occurs. Many users may find this large latency frustrating, and thus there is a need to improve delivery latency in streaming media systems. The present disclosure provides various solutions for addressing this need.

[0022] Aspects, methods, and systems described herein provide techniques for discovering or tuning to streaming media content, which may be useful when tuning to a live event during which media content is streamed. These aspects may reduce the time required to tune into such a live event, such as a baseball game or a football game. Streaming media may be provided by a system including a content delivery network (CDN) that stores playlists in a cache on a server in the content delivery network. Figure 1 An example of a streaming media system 101 including multiple client devices, multiple content delivery networks, and multiple source systems is shown. The content delivery networks may each include multiple proxy cache servers that cache playlists and media segments that can be retrieved from the servers and provided to client devices. The caches used by these proxy cache servers may be conventional caching techniques used for streaming media content. Figure 1 As shown, source systems 103 and 105 can provide content to content distribution networks 107, 109, and 111 and be the source of content. Client devices such as client devices 115 and 117 can then request playlists and media segments from content distribution networks 107, 109, and 111. When a client device such as client device 115 attempts to retrieve streaming media for a live event, it will initially request a playlist for the live event that does not include attributes specifying the latest partial media segments or the media segments at the end of the latest playlist, which are obtained from the source server or source system. When the content distribution network receives such a non-attributed playlist request, the CDN returns a cached playlist, which is typically not the latest playlist obtained from the source server. The client device can then attempt to retrieve the latest playlist obtained from the source server by using the aspects described herein.

[0023] Figure 2 An example of a streaming media divided into parts as known in the art is shown. Each part is called a media segment, they can be identified by a media sequence number (MSN), and within each media sequence number, there can be multiple parts. Figure 2In the example shown, two media segments 151 and 153 are shown to have been segmented into six parts. Media segment 151 is followed by media segment 153, such as Figure 2 The media segment can be divided into multiple parts by allowing the client device to request the media segment to be divided into multiple parts by part number (such as Figure 2 The partial media segments indicated by the partial numbers P1 or P2) shown in the figure are used to improve the tuning operation of the client device.

[0024] Figure 3 A method is shown that can improve the time it takes a client device to tune into streaming media content, such as a live event, according to one aspect. The method can begin in operation 301. In operation 301, a client device can request an initial media playlist that does not have attributes for the latest available cached playlist. For example, the client device can issue a generic media playlist request for streaming content without including attributes indicating the media sequence number and the portion number of the latest playlist obtained from the cache server. Then in operation 303, the client device can receive the initial media playlist. According to one aspect, a header associated with the received media playlist can include duration data indicating the duration of the received cached playlist; according to one aspect, the duration data can indicate the length of time (in seconds) that the playlist has been cached (e.g., cached at a cache proxy server in a CDN). In one aspect, the duration data can have an integer value that only indicates the time (in seconds) that the playlist has been in the proxy cache. In operation 305, the client device can determine the duration based on the header and can also determine the last portion of the media fragments in the received playlist. Optionally, the client device may also determine partial target duration values ​​for the media segments in the playlist. For example, if the target duration value (which indicates the maximum media segment duration) is five seconds, as specified by parameters in the playlist, the playlist may also specify partial target duration values ​​that are all less than five seconds and represent a portion of the media segment. After operation 305, the client device may attempt to predict or determine an amount of at least a portion of the media segment to skip ahead in order to more quickly tune to the current time in the streaming media content. This may be Figure 3As shown in operation 307 in . According to one aspect, the client device can determine the number of at least some of the media segments to be skipped forward based on the duration data and the media sequence number of the last partial media segment in order to tune into the streaming media content. When determining the number of at least some of the media segments to be skipped, the partial target duration value can be optionally used in operation 307. For example, if the duration is three seconds, based on the partial target duration data, the client device can skip forward the number of the partial media segments that exceeds the last partial media segment in the initial media playlist received in operation 303 by about three seconds. Operation 307 can be repeated multiple times by requesting additional playlists and determining the duration of each playlist. Therefore, operations 303, 305 and 307 can be repeated by the client device in order to attempt to obtain the latest playlist obtained from the source server.

[0025] Figure 4A Another aspect that may be used by a client device is shown in FIG. In this aspect, the client device may use several parameters to calculate or determine an amount of advancement to skip at least one or more partial media segments after the last partial media segment at the end of the initial playlist. For example, if the last partial media segment at the end of the initial playlist has a media sequence number of 56 and a portion number of 2, and Figure 4A The method shown determines that the amount to advance is one complete media segment (having 6 parts) and another 2 additional parts (the total amount to be advanced or skipped is 8 parts), then the client device will request a playlist with attributes indicating msn=57, parts=5. In this case, the client device will also typically indicate that it does not want any segments pushed to it by setting the push parameter to zero (push=0). Additional information about push parameters can be found in the provisional application mentioned in the first paragraph of this disclosure. Typically, when the client device is in tuning mode, the push parameter is set to zero, and after leaving tuning mode, the client device sets the push parameter to 1 or 2 (e.g., push=1) in order to reduce the latency of the content stream used to receive the media content of the live event.

[0026] Figure 4AThe method shown in begins in operation 351. In operation 351, a client device may request an initial playlist; the playlist request does not have an attribute that specifies a live playlist. Then in operation 353, the client device receives the initial playlist and receives other data, such as duration data in the header. The playlist may include a partial target duration value and may also include media sequence numbers and partial numbers of various media segments in the playlist. The last partial media segment in the playlist includes the media sequence number and partial number of the last partial media segment. The client device may then use the received data to calculate the amount to advance. These calculations may begin in operation 355, where the client device compares the partial target duration to a predetermined duration value. In one aspect, the predetermined duration value may be a minimum non-zero duration. In a specific implementation, the predetermined duration value may be a value of one second. After the comparison in operation 355, in operation 357, the client device may set a target value. The target value may be the amount of time (in seconds) to skip forward from the last partial media segment in the playlist received in operation 353. In one implementation, the target is set based on the comparison in operation 355. In one implementation, if the partial target duration value is greater than or equal to the predetermined duration value, the target is set to the value of the duration data, and if the partial target duration value is less than the predetermined duration value, the target is set to the value of the duration data plus a constant value (N). Then, in operation 359, the duration data is compared to the partial target duration specified in the last received playlist. If the duration data is greater than or equal to the partial target duration, processing proceeds to operation 363, as shown in FIG. Figure 4A As shown; on the other hand, if the duration data is not greater than or equal to the partial target duration determined in operation 359, the process proceeds to operation 361.

[0027] In operation 361, the client device exits tuning mode. Exiting tuning mode generally means that the client device will stop skipping media segments and will begin processing media segments by requesting media segments in the order in the playlist. In one aspect, the client device can use a non-zero push value to cause the push of future media segments, as described in the provisional patent application mentioned in the first paragraph of this disclosure. Once the client device has exited tuning mode, the client device begins to process the media segments in a normal manner by requesting media segments and receiving them and presenting them, rather than skipping and not requesting media segments as occurs in some aspects of the tuning mode described herein. In operation 363, the client device compares the last advance amount (advanced from the previous) with the target value, as shown in operation 363. When the initial playlist is being processed, the last advance amount is zero, and therefore processing will proceed to operation 365. However, if the last advance amount is non-zero, it may exceed or equal the target, in which case processing will return to operation 361 described above.

[0028] In operation 365, according to one aspect, the client device determines an amount to advance by calculating the number of portions to advance to skip the media segment after the last partial media segment in the current playlist. In one specific implementation, the amount to advance is calculated based on a target value, which can be a duration data value or a duration plus a constant value (N). The target value can be divided by the value of the portion target duration, and the result of the division produces a number that can be rounded down to the nearest integer to provide a number representing the number of portions to skip after the last partial media segment in the current playlist. For example, if the last partial media segment at the end of the initial playlist has a media sequence number of 56 and a portion number of 2, and Figure 4A The method shown determines that the amount to advance is one complete media segment (having 6 parts) and another 2 additional parts (the total amount to be advanced or skipped is 8 parts), then the client device will request a playlist with attributes indicating msn=57, parts=5. After determining the amount to advance, the client device requests the next updated playlist in operation 367, which has the amount of advancement as specified by the attributes in the playlist request. Then in operation 369, the client device receives the requested playlist and determines the updated duration value based on the duration header. After operation 369, the client device returns to operation 359 to repeat. Figure 4AThe process shown in FIG. 360 continues until the client device leaves tuning mode. In one specific implementation, after operation 369, the client device may check the playlist received in operation 369 to determine how much media duration it has compared to the initial playlist. If the partial segment is less than the partial target duration, the playlist received in operation 369 may not advance by the expected amount. If this occurs, the target may be increased based on the difference between the expected amount of advancement and the actual amount of advancement. In one aspect, the client device may remain in tuning mode until the process indicates that it should exit tuning mode; in another aspect, the client device may also use a timer (e.g., a watchdog timer) to Figure 4A In another aspect, the client device may leave the tuning mode after a predetermined number (e.g., a maximum number) of tuning attempts (even if the client device exits the tuning mode). Figure 4A The process shown in does not cause the device to exit tuning mode); for example, after 6 tuning attempts, the client device can exit tuning mode.

[0029] Figure 4B The method shown in is similar to Figure 4A The method shown in Figure 4BThe method shown in uses an additional parameter value to calculate the amount to advance in order to skip the last partial media segment in the last received playlist. In operation 401, the client device may request an initial playlist, the request not having an attribute specifying an adjacent live playlist; the client device stores the time of this request, which is later used in the calculation to determine the amount to advance. The stored time may be referred to as TimeOfFirstLoad. Then in operation 403, the client device receives the requested playlist and determines the duration data (from the header) and the partial target duration value from the playlist, and also determines the media sequence number and the partial number of the last partial media segment in the playlist. Then in operation 405, the client device compares the partial target duration with a value of 1; in one specific implementation, the comparison may be "PTD<1?". The result of the comparison may be used to set a target value in operation 407. In operation 407, if the partial target duration is greater than or equal to 1, the target value may be set to the duration data value, and if the partial target duration is less than 1, the target value may be set to the duration data value+1. Then, in operation 409, the client device may perform a comparison operation. If the duration data value is greater than or equal to the partial target duration, the client device proceeds to operation 413; on the other hand, if the duration data is less than the PTD, the client device proceeds to operation 411, in which the client device exits the tuning mode, as described above. In operation 413, the client device compares the last advance amount to the target value. If the last advance amount exceeds or equals the target value, the process proceeds to operation 411, in which the client device exits the tuning mode. On the other hand, if the target value is greater than the last advance amount, the process proceeds to operation 415.

[0030] In operation 415, the client device determines the amount to advance; for example, the client device may calculate the media sequence number and portion number of the last portion number (in the last received playlist) to skip the last portion of the media segment by at least the target plus the time that has elapsed since the last received playlist was first loaded. In one aspect, this may be calculated based on the current time and the stored time (TimeOfFirstLoad) stored in operation 401; for example, the amount to advance may be equal to: target + (current time - TimeOfFirstLoad). Then, in operation 417, the client device may request the next updated playlist, with the playlist request having an advance amount attribute. In operation 419, the client device may then receive the requested playlist and update the duration value based on the duration data in the header associated with the received playlist. Processing may then return to operation 409 in a loop, which may continue until the client device exits tuning mode. Exiting tuning mode may be due to Figure 4B The processing logic shown in or occurs due to a watchdog timer, which forces an exit from the tuning mode based on the expiration of the watchdog timer. In one aspect, Figure 4B The use of the stored time (TimeOfFirstLoad) in the method may be optional, and when the difference between the stored time and the current time exceeds a threshold, the stored time is used (and when the difference does not exceed the threshold, the stored time is not used).

[0031] Figure 5A Another example of utilizing additional data in a header obtained from a source server according to one aspect is shown. In this regard, certain rules relative to the source server may be used to require the source server to provide last modified date data in one or more headers accompanying the playlist. The client device may use this data to calculate the amount to advance to speed up the tuning mode. In one specific implementation, the source server may be required to provide last modified date data in one or more headers of each playlist requested; in another specific implementation, when the client device remains in the tuning mode, the source server may be required to provide the last modified data upon request from the client device. The client device may also use date data, which may be a timestamp indicating the time when the cache server responded to the request for the playlist. The last modified date data may be a timestamp indicating the time when the playlist was last modified at the source server. Figure 5AThe method shown in begins in operation 501, in which the client device requests an initial non-attributed playlist. Then in operation 503, the client device receives the initial playlist and also receives duration data and last modified data in one or more headers. The client device may also determine date data based on the header in the response containing the playlist. In operation 503, the client device may also determine a partial target duration value based on the playlist. Next, in operation 505, the client device determines whether the duration data is equal to zero. If so, then in operation 507, the client device exits the tuning mode. On the other hand, if the duration data is not equal to zero, then operation 509 is performed, in which the client device determines whether the date value minus the last modified time value is equal to zero. Since the two values ​​are integer values, if the subtraction shown in operation 509 produces a zero value, the client device is within one second of the latest playlist at the source server, in which case the process proceeds to operation 517, which will be further described below. On the other hand, if operation 509 determines that the date minus the last modified value is not equal to zero, processing proceeds to operation 511, which calculates the amount to advance. In operation 511, the calculation can be based on the partial target duration, the date data, and the last modified date. The calculation can determine the partial number of the last partial media segment in the playlist last received in operation 503 to be skipped forward. In one specific implementation, the calculation can be: N = [date-last modified value+PTD-c] / PTD, where c is a small value (e.g., 0.01) designed to ensure that N is rounded down. The calculation of N from operation 511 is then used in the request for the next playlist in operation 513. The next playlist is received, and the duration data is updated along with the last modified date value received from the source server. The client device then performs a comparison operation of 515; specifically, the client device determines whether the duration data is equal to zero. If not, processing returns to operation 511, as shown in FIG. Figure 5A If the duration data is equal to zero, processing proceeds to operation 517. In one aspect, since the duration data value is only an integer value, if operation 515 determines that the duration is equal to zero, the client device may be within one second of the live event or within one second of the latest playlist on the origin server.

[0032] Figure 5A and Figure 5BThe remaining operations shown in are intended to bring the client device closer to the current live edge of the current playlist. In operation 517, the client device determines whether the partial target duration is greater than or equal to one second. If so, then in operation 519, the client device exits the tuning mode, because each partial target duration is greater than one second, so the client device is unlikely to improve the delay at this time. If operation 517 determines that the partial target duration is less than one second, then in operation 521, the client device determines whether the partial target duration is greater than or equal to 600ms. If so, then the processing proceeds to operation 523, in which the client device requests the next playlist with an N value of +1 to skip a playlist, and then exits the tuning mode under the assumption that the next playlist is up to date enough for the client device. If in operation 521, the client device determines that the partial target duration is less than 600ms, then the processing proceeds to operation 525, in which the client device determines whether the partial target duration is greater than or equal to 400ms. If so, processing proceeds to operation 527, in which the client device requests the next playlist of the advance value or advance amount equal to two parts, and then exits the tuning mode. If in operation 525, the client device determines that the part target duration is less than 400ms, then processing proceeds to Figure 5B Operation 533 shown in . In operation 533, the client device requests the next playlist plus an advance amount of N = two portions, and looks for obvious blocking behavior at the content distribution network. This obvious blocking behavior is described in the previous provisional patent application mentioned in the first paragraph of this disclosure. This behavior comes from the fact that if the playlist returns quickly after the request, it may be cached, and if the playlist takes more time to return, it may be due to blocking behavior at the content distribution network, which is described in the previous provisional patent application. In one aspect, this can be achieved by measuring the time between the request and the receipt of the playlist. For example, if the measured time exceeds the round-trip time (RTT) plus the partial target duration, it can be assumed that obvious blocking behavior has occurred, which means that the client device can exit the tuning mode. In particular, referring back to Figure 5B , decision block 535 can detect that significant blocking has occurred by measuring a time that exceeds the round trip time plus a portion of the target duration, and can then cause the client device to exit tuning mode. On the other hand, if operation 535 indicates that no significant blocking has occurred, the client device can request the next playlist plus an advance amount of N=1, and can then exit tuning mode.

[0033] It should be appreciated that variations of the methods described herein may use fewer parameters or fewer decision blocks; for example, in these variations, one or more of decision blocks 517 , 521 , and 525 may be eliminated.

[0034] Figure 6 An example of a data processing system 800 that can be used with one embodiment is shown. For example, system 800 can be implemented to provide Figure 1 client device or other system as shown. Note that although Figure 6 Various components of the device are shown, but it is not intended to represent any particular architecture or manner of interconnecting these components, and such details are not germane to the present disclosure. It should also be understood that network computers and other data processing systems or other consumer electronic devices with fewer or possibly more components may also be used in embodiments of the present disclosure.

[0035] like Figure 6 As shown, the device 800 in the form of a data processing system includes a bus 803 coupled to a microprocessor 805, a ROM (read only memory) 807, a volatile RAM 809, and a non-volatile memory 811. The one or more microprocessors 805 can retrieve instructions from the memory 807, 809, 811 and execute the instructions to perform the above-mentioned operations. The one or more microprocessors 805 may include one or more processing cores. The bus 803 interconnects these various components together, and also interconnects these components 805, 807, 809 and 811 to a display controller and a display device 813, as well as to peripheral devices such as input / output (I / O) devices 815, which can be touch screens, mice, keyboards, modems, network interfaces, printers, and other devices well known in the art. Typically, the input / output device 815 is coupled to the system through an input / output controller 810. The volatile RAM (random access memory) 809 is typically implemented as a dynamic RAM (DRAM) that requires continuous power to refresh or maintain data in the memory.

[0036] The non-volatile memory 811 is typically a magnetic hard drive, or a magneto-optical drive, or an optical drive, or a DVD RAM, or a flash memory, or other type of memory system that retains data (e.g., a large amount of data) even after the system is powered off. Typically, the non-volatile memory 811 may also be a random access memory, although this is not required. Although Figure 6The non-volatile memory 811 is shown as a local device directly coupled to the rest of the components in the data processing system, but it should be understood that embodiments of the present disclosure may utilize non-volatile memory that is remote from the system, such as a network storage device coupled to the data processing system through a network interface such as a modem, an Ethernet interface, or a wireless network. The bus 803 may include one or more buses interconnected by various bridges, controllers, and / or adapters well known in the art.

[0037] Part of the above content can be realized by utilizing logic circuits such as special logic circuits or by utilizing the processing core of microcontroller or other forms of execution program code instructions. Thus, program code such as machine executable instructions can be utilized to perform the process taught by the above discussion, and the machine executable instructions make the machine execute these instructions to perform certain functions. In this context, "machine" can be a machine that converts intermediate form (or "abstract") instructions into processor-specific instructions (for example, abstract execution environment such as "virtual machine" (for example, Java virtual machine), interpreter, common language runtime, high-level language virtual machine, etc.), and / or is arranged on a semiconductor chip designed to execute instructions (for example, "logic circuit" implemented by transistors) such as a general-purpose processor and / or an electronic circuit on a special-purpose processor. The process taught by the above discussion can also be performed by (as a substitute of a machine or in combination with a machine) an electronic circuit, which is designed to perform a process (or a part thereof) without executing program code.

[0038] The present disclosure also relates to an apparatus for performing the operations described herein. The apparatus may be specially constructed for the desired purpose, or may include a general purpose device selectively activated or reconfigured by a computer program stored in the device. Such a computer program may be stored in a computer-readable storage medium, such as, but not limited to, any type of disk, including a floppy disk, an optical disk, a CD-ROM and a magneto-optical disk, a DRAM (volatile), a flash memory, a read-only memory (ROM), a RAM, an EPROM, an EEPROM, a magnetic card or an optical card, or any type of medium suitable for storing electronic instructions, and each is coupled to a device bus.

[0039] Machine-readable media include any mechanism for storing information in a form readable by a machine (e.g., a computer). For example, machine-readable media include read-only memory ("ROM"); random access memory ("RAM"); magnetic disk storage media; optical storage media; flash memory devices; etc.

[0040] Articles of manufacture can be used to store program code. Articles of manufacture storing program code can be implemented as, but not limited to, one or more memories (e.g., one or more flash memories, random access memories (static, dynamic or other)), optical disks, CD-ROMs, DVD ROMs, EPROMs, EEPROMs, magnetic or optical cards, or other types of machine-readable media suitable for storing electronic instructions. Program code can also be downloaded from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by means of a data signal contained in a propagation medium (e.g., via a communication link (e.g., a network connection).

[0041] The foregoing detailed description has been presented in terms of algorithms and symbolic representations of operations on data bits within device memories. These algorithmic descriptions and representations are tools used by those skilled in the art of data processing, and these tools can also most effectively convey the substance of their work to other technicians in the field. An algorithm here and generally refers to a self-consistent sequence of operations that lead to a desired result. Operations are those operations that require physical manipulation of physical quantities. Typically, although not necessarily, these quantities take the form of electrical or magnetic signals that can be stored, transmitted, combined, compared, and in other words manipulated. It has proven to be convenient to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc., primarily for general reasons.

[0042] It should be borne in mind, however, that all of these and similar terms are associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless otherwise specifically stated, it will be apparent from the above discussion that discussions throughout this specification using terms such as "receive," "determine," "send," "terminate," "wait," "change," etc., will be understood to refer to actions and processes on a device or similar electronic computing device that manipulates data represented as physical (electronic) quantities within the device's registers and memories and converts them into other data similarly represented as physical quantities in the device's memories or registers or other such information storage, transmission, or display devices.

[0043] The process and display presented herein are not inherently related to any particular device or other apparatus. According to the teachings herein, various general purpose systems can be used together with programs, or it can be proved that it is convenient to construct a more special device for performing the operation. According to the description below, the required structure for various these systems will be apparent. In addition, the present disclosure is not described with reference to any specific programming language. It should be understood that a variety of programming languages ​​can be used to implement the teachings of the present disclosure as described herein.

[0044] In the foregoing specification, specific exemplary embodiments have been described. It will be apparent that various modifications may be made to those embodiments without departing from the broader spirit and scope as set forth in the following claims. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

Claims

1. A non-transitory machine-readable medium storing executable program instructions, which when executed by a data processing system causes the data processing system to perform a method, the method comprising: Requesting a first playlist for media content by a first request, the first request not including at least one attribute of a near-live playlist for the media content; receiving the first playlist in a manner consistent with a transport protocol, the first playlist comprising a plurality of uniform resource identifiers (URIs) indicating a playback order of a plurality of media segments that can be received in the manner consistent with the transport protocol for recreating the media content, the first playlist comprising a last URI in the order, the last URI identifying a last available media segment in the first playlist; receiving first duration data associated with the first playlist, the first duration data indicating a duration of the first playlist on a cache server; Based on the first duration data and based on the last URI, a first number of at least partial media segments after the last available media segment in the first playlist is determined, the first number specifying a number of at least partial media segments to be skipped after the last available media segment to tune to the media content.

2. The medium of claim 1 , wherein the last URI includes a media sequence number and a portion number, and the first playlist specifies a target duration and a portion target duration, and wherein the first number of at least a portion of the media segments is determined based on: (1) the first duration data and (2) the last media sequence number and the portion number in the last URI, and (3) the portion target duration.

3. The medium of claim 2, wherein the partial target duration is compared to a predetermined minimum duration value, and a result of the comparison provides a base value from which the first quantity is determined.

4. A medium according to claim 3, wherein the predetermined minimum duration value is 1, and wherein if the partial target duration is greater than 1 second, the base value is the first duration data, and wherein if the partial target duration is less than 1 second, the base value is the first duration data plus a first additional value. The medium according to claim 4 , wherein the first additional value is 1 or a fraction less than 1.

6. The medium of claim 4, wherein the method further comprises: A first time period is determined between a current time and one of: (1) a time when the first request is requested, or (2) a time when the first playlist is received.

7. The medium of claim 6, wherein the method further comprises: A second additional value is added to the base value, the second additional value being based on the first time period.

8. The medium of claim 7, wherein the first amount is a sum of the base value, the first additional value if the partial target duration is less than one second, and the second additional value.

9. The medium of claim 7, wherein the method further comprises: requesting a second playlist having a URI based on the first number; Receive the second playlist and second duration data; as well as The base value is updated based on the second duration data.

10. The medium of claim 9, wherein the method further comprises: The second duration data is compared with the partial target duration to determine whether to exit the tuning mode.

11. The medium of claim 10, wherein the method further comprises: If the second duration data is less than the minimum partial target duration, the tuning mode is exited.

12. The medium of claim 11, wherein the method further comprises: Determining whether the first number is greater than the second duration data, and exiting the tuning mode if the first number is greater than the second duration data.

13. The medium of claim 1, wherein the method further comprises: In response to detecting that the first duration data is not received, exiting the tuning mode.

14. A non-transitory machine-readable medium storing executable program instructions which, when executed by a data processing system, cause the data processing system to perform a method comprising: requesting a first playlist for streaming media content during a tuning mode by a non-attributed request, the non-attributed request lacking an attribute of an adjacent live playlist for the streaming media content; receiving the first playlist in a manner consistent with a transport protocol, the first playlist comprising a plurality of uniform resource identifiers (URIs), the plurality of URIs indicating a playback order of a plurality of media segments that can be received in the manner consistent with the transport protocol for recreating the streaming media content, the first playlist comprising a last URI in the order, the last URI identifying a last available media segment in the first playlist; determining whether first duration data is received together with the first playlist, the first duration data indicating a duration of the first playlist on the cache server; In response to determining that the first duration data is not received or the first duration data has a minimum value if the first duration data is received, the tuning mode is exited. The medium of claim 14 , wherein the minimum value is zero.

16. The medium of claim 14, wherein the method further comprises: A first number of at least partial media segments after the last available media segment in the first playlist is determined based on the difference, the first number specifying a number of at least partial media segments to be skipped after the last available media segment to tune to the streaming media content.

17. The medium of claim 16, wherein the difference comprises a difference between a first date header and a last modified date header, and wherein the first date header comprises a timestamp of a time when a cache server responded to the request for the first playlist, and the last modified date header comprises a timestamp of a time when the first playlist was last modified.

18. The medium of claim 17, wherein the method further comprises: requesting a second playlist having a URI based on the first number; The second playlist is received.

Images