Synchronization when streaming digital content

Abstract

Method for streaming digital content (112) in a digital medium environment (100), wherein the method is implemented by a computing device (702) and comprises: Receiving a response (214) to a request (212) for streaming the digital content (112) by a computing device (702), wherein the response (214) includes a time at which the digital content (112) was last modified and a time at which the response (214) was generated; Calculating an age by the computing device (702) by subtracting the time at which the digital content (112) was last modified from the time at which the answer (214) was generated; Determining a time by the computing device (702) by subtracting the age from a predefined reset time, the time being usable to define when a playback or rendering of the stream of digital content (112) is to take place; and Reproducing or rendering the stream of digital content (112) by the computing device (702) at least partially on the basis of the specified time.

Description

background

[0001] Synchronization in the playback of digital content is fundamental not only for client devices located in the same location but also for those located remotely. Consider, for example, a sports bar with multiple televisions, all of which can be viewed simultaneously. A person watching all these televisions at once can easily become confused about what is currently being shown if different parts of a sporting event are being broadcast, even with a delay of just a few seconds. Accordingly, a lack of synchronization between the televisions can be so confusing that the advantage of having multiple televisions is ultimately lost.

[0002] This consideration also applies to situations where client devices are geographically dispersed. Social media and other communication technologies, for example, allow users to communicate and comment on events in real time. When watching television from home, for instance, viewers share reactions via social media. Digital live content that is significantly out of sync can cause some viewers to miss exciting developments in a game or otherwise be pulled out of the program's context during shared viewing. Similarly, poor playback synchronization on geographically dispersed devices can lead to a lack of synchronization in communication, which quickly becomes frustrating for viewers.

[0003] Since viewers expect and are accustomed to good synchronization in traditional television broadcasts, they want a similar experience with media streamed over the internet. In traditional television broadcasts, multiple television receivers simultaneously receive the same transmission signal and display the transmitted video immediately. Accordingly, the presentations are inherently synchronized. However, conventional techniques for live-streamed HTTP media are typically synchronization-shifted by up to two or more segments, with segments usually lasting 6 to 10 seconds.

[0004] In a typical HTTP streaming example, live playback begins a number of segments behind the last segment served, as specified in a manifest file. The number of segments "behind" depends on when the manifest file is retrieved, when a new change and segment are served, and the time it takes to select, retrieve, and play the new segment. Consequently, client devices may be synchronized up to two segments out of sync, due to variations in this timing, for example, between 6 and 12 seconds. In another example, times from a local "wall clock" are specified in a manifest file to indicate when a segment should be played.However, this approach requires that the clocks on each client device are synchronized, which is not usually the case. Other proprietary techniques have also been developed to determine the time in order to display a relevant content segment. These proprietary techniques, however, typically require additional software and hardware resources (such as network synchronization) that are generally not available on every client device.

[0005] The publication EP 2 706 754 A2 describes systems and methods for synchronizing the display of a program across multiple devices. Program-related synchronization information can be exchanged via a bidirectional communication channel. The amounts by which each device can delay its program display can be calculated and / or exchanged. The time period by which a device can delay the display of program content can be calculated using this synchronization information.

[0006] Document US 2012 / 0042050A1 describes a device for receiving information for multimedia data, wherein the device comprises one or more processors configured to analyze at least a portion of a multimedia content manifest file, wherein the portion of the manifest file contains information indicating sets of representations of the multimedia content and information indicating common features for each of the sets of representations, selects one of the sets of representations based on the common features for one of the sets of representations, selects one of the representations of the selected set of representations based on one or more encoding features of one of the representations of one of the sets, and generates a request for data of one of the representations based on the selection.

[0007] Publication US 2012 / 0110138A1 describes a method for implementing a Hypertext Transfer Protocol (HTTP)-based streaming service. In the method, a server receives a request from a client and returns a response to the client, corresponding to a request for a media presentation description file, which contains the media presentation description file. The server establishes a time synchronization relationship with the client. The server receives a uniform resource localizer from the client, obtains a corresponding media fragment file, and returns the media fragment file to the client for playback. The uniform resource localizer is a uniform resource localizer of a media fragment determined by the client and required for playback, and is used by the client to request the media fragment file from the server. Summary

[0008] This document describes techniques for synchronizing digital content streaming. In a digital media environment for streaming digital content, content playback is synchronized by determining a playback time. This is achieved by receiving a response to a request to stream the digital content. The response includes the time the digital content was last modified (for example, a header related to the last modification) and the time the response was generated (for example, a date header).

[0009] An age is calculated by subtracting the time at which the digital content was last modified (e.g., the header relating to the last modification) from the time at which the response was generated (e.g., the date header). Any time the response may have spent in one or more caches (e.g., an age header) is added as part of this age.

[0010] The time is determined by subtracting the age from a predefined reset time, and the stream of digital content is then at least partially reproduced based on this determined time. To improve synchronization accuracy between client devices, times can be specified using fractions of a second. To reduce latency, the reset time can be based at least partially on a specific time interval between changes to the digital content.

[0011] This summary presents a selection of concepts in simplified form, which are further described in detail below. The summary itself is not intended to identify essential features of the claimed invention, nor is it intended to be used as an aid in determining the scope of the claimed invention. Brief description of the drawing

[0012] The detailed description is based on the accompanying figures. In the figures, the leftmost digit of a reference symbol identifies the figure in which the reference symbol first appears. The use of the same reference symbol in different places in the description and the figures may denote similar or identical objects. Entities depicted in the figures may denote one or more entities; therefore, a reference to one or more forms of the entities in the discussion can be considered equivalent. Fig. Figure 1 is a representation of an environment in an exemplary implementation that is operable to use the techniques described here for synchronization when streaming digital content. Fig. Figure 2 shows a system in an exemplary implementation where digital content is distributed via a content distribution service over a network to a client device. Fig. 1 is being streamed. Fig. Figure 3 shows an exemplary implementation of setting a header relating to the last modification, a date header, and an age header for a response from Fig. 2. Fig. Figure 4 shows an exemplary implementation of using a last modification header, a date header, and an age header of a response from Fig. 3, to define when the digital content should be played back. Fig. Figure 5 is a flowchart to represent a procedure in an exemplary implementation, where a time is determined that is used as the basis for defining when the content should be played back. Fig. Figure 6 is a flowchart to represent a procedure in an exemplary implementation where a time interval between changes to the digital content is determined and which is used to reduce latency in the playback of the digital content. Fig. Figure 7 shows an exemplary system that includes various components of an exemplary device, which is described as a type of computing device and / or used in connection with Fig. 1 to 6 can be implemented to implement embodiments of the techniques described here. Detailed description Overview

[0013] Traditional techniques for streaming digital content that rely on segments and manifest files often fail to achieve synchronized playback across client devices. Manifest- and segment-based streaming techniques, such as those using a Hypertext Transfer Protocol (HTTP), employ a manifest file to map durations to segments of the digital content within a media presentation, with segments typically lasting a few seconds. Playback of the digital content therefore begins a number of segments behind the most recently provided segment, as defined by the manifest file. The number of segments "behind" depends on the timing of the manifest file's provisioning, when a new change and a new segment are provided, and other factors.Accordingly, this can vary from client device to client device, resulting in a lack of synchronization that can be frustrating during playback, as described above.

[0014] This document describes techniques and systems for streaming digital content to support synchronized playback of content by client devices. These techniques are applicable to streaming technologies that rely on manifest files and segments within a media file, for example, according to a hypertext transfer protocol (HTTP). A content distribution service can, for instance, generate a response to a request to stream digital content, such as a manifest file. The response specifies the time at which the requested resource (e.g., the manifest file) was last modified, as well as the time at which the response was generated.This can be accomplished using existing HTTP (Hypertext Transfer Protocol) headers, for example, a Last Modified header and a Date header, and therefore requires no additional resources and no special configuration of the client device receiving the response. Furthermore, an age can be specified for the period the response has spent in a cache (for example, an HTTP Age header) during its communication from the content delivery service to the client device. This can include a cache of the content delivery service itself or caches in intermediate areas used to communicate the response over a network between the content delivery service and the client device.

[0015] From this information in the response, the client device can determine a time to play back the digital content, which is synchronized with other client devices that are also scheduled to play back the same content. To do this, the client device first calculates an age by subtracting the time the digital content was last modified from the time the response was generated. In an HTTP example, this is done by subtracting the Last Modified header from the Date header. Additionally, an Age header can be used to optionally add to the age any time the response has spent in a cache.

[0016] Next, a time is determined to define when the digital content should be played back. This time is calculated by subtracting the age of the content from a reset time. The reset time can, for example, include a buffer period to support consistent playback. In live streaming, the reset time is set as the time after the end of the last available segment. This time is then used as the basis for the client device to play back segments of the digital content. Furthermore, the use of this technique by multiple client devices promotes synchronized playback of the content between these devices without the need for synchronizing local clocks or using proprietary communication techniques.

[0017] To further reduce latency in digital content playback, the reset time can be set based on a predicted time between changes to segments of the digital content. For example, latency can be reduced using this technique to predict how long it will be until the next change to the manifest file (and therefore a corresponding segment). A reset time is then set based on this predicted time to provide sufficient buffering while still allowing for the fastest possible content playback. Further reductions can be achieved by using headers that specify fractions of a second, thus promoting tighter synchronization between client devices.This approach facilitates the synchronized playback of streamed content by client devices—whether located in the same place or geographically dispersed—using a common technique that defines "when" this playback should occur. Further discussion of this and other examples is included in the following sections.

[0018] The following discussion will first describe an exemplary environment that can employ the techniques described here. Then, exemplary procedures will be described that can be used in this exemplary environment as well as in other environments. Consequently, the execution of the exemplary procedures is not limited to the exemplary environment, and the exemplary environment is not limited to the execution of the exemplary procedures. Exemplary environment

[0019] Fig. Figure 1 is a representation of an environment 100 of an exemplary implementation that can be operated to use the techniques described here for streaming digital content. The represented environment 100 includes a content distribution service 102, which is communicatively coupled to a plurality of client devices (examples of which are shown as first and second client devices 104 and 106) via a network 108. The content distribution service 102 can be configured in a variety of ways, for example, as one or more computing devices for implementing a website provider, a service provider, a web service, a satellite provider, a cable provider, or any other content distributor that uses a network 108. Similarly, the network 108 can also be configured in a variety of ways, for example, as the Internet or "World Wide Web," as a peer-to-peer network, and so on.

[0020] The first and second client devices 104, 106 are also using a variety of computing devices, which are further described by Fig. As described in section 7, a computing device is configurable. For example, a computing device can be configured as a desktop computer, laptop computer, mobile device (assuming manual configuration as with a tablet or mobile phone, as shown), and so on. The computing device can range from fully resourced devices with considerable memory and processor resources (e.g., PCs, game consoles) to resource-poor devices with limited memory and / or processing resources (e.g., mobile devices) configured to communicate over the network 108. Additionally, the first and second client devices 104, 106 can be implemented using a plurality of different devices, such as multiple servers.

[0021] The content distribution service 102 includes a content distribution module 110, which is at least partially implemented in hardware, to control or regulate the streaming of the digital content 112 over the network 108, which is represented as being stored in the memory 114. The digital content 112 can take a variety of forms, such as media, video, audio, and other forms of media suitable for digital storage, communication (e.g., streaming), and playback.

[0022] The first and second client devices 104, 106 are depicted as including respective communication modules 116, 118. The communication modules 116, 118 provide functionality, at least partially implemented in hardware, for communicating over the network 108, for example, to communicate with the content distribution service 102 for streaming the digital content 112. This includes dedicated applications or apps, plugin modules, network-enabled applications or apps, browsers, and the like. An example of the functionality used by the communication modules 116, 118 is provided by playback modules 120, 122, which are at least partially implemented in hardware to control the navigation and playback of the digital content 112.

[0023] As described above, users expect synchronization when playing streamed content. In traditional television broadcasts, client devices, such as receivers, are configured to simultaneously receive the same transmission signal and immediately display it. This results in the display being inherently synchronized in traditional television broadcasts. However, this is not the case with traditional live streaming techniques, which involve the use of a manifest file and segments (e.g., according to a hypertext transfer protocol). This is due to the time required to retrieve the manifest file, the time it takes for a new change and corresponding segment to be provided, the time it takes to make the request and receive the response containing the segment, and so on.As a result, a lack of synchronization in conventional live streaming techniques can run counter to user expectations.

[0024] Accordingly, the playback modules 120, 122 are configured to employ techniques for the time-based playback of a stream of the digital content 112 in such a way as to promote synchronized playback between the first and second client devices 104, 106. Furthermore, the synchronization as described here can be achieved without the use of a dedicated communication channel between the first and second client devices 104, 106, for example, to synchronize the local clocks of the client devices 104, 106, or without proprietary techniques. An example of the timing during the playback of digital content, where this synchronization is implemented, is described below and illustrated in the corresponding figures.

[0025] Fig. Figure 2 shows a System 200 of an exemplary implementation in which the digital content 112 is streamed by the content distribution service 102 over the network 108 to the first client device 104. In this example, the content distribution service 102 receives the digital content 112, which is "live," meaning it is captured, for example, in real time or linearly as pre-recorded content presented in a "live" style in real time. The content distribution module 110 then configures the digital content 112 for live streaming using manifest and segment techniques. For this purpose, the content distribution module 110 uses a manifest generation module 202 and a segment generation module 204.

[0026] The segment generation module 204 is at least partially implemented in hardware to create segments 206 in a media presentation 208. The segments 206 can be created, for example, by the segment generation module 204 in lengths of a few seconds each, from packets collected from the digital content 112. The manifest generation module 202 is at least partially implemented in hardware to create the manifest file 210, which maps the respective durations to the corresponding segments 206 of the media presentation 208.

[0027] The technique, comprising a request 212 and a response 214, is then used to stream the digital content over the network 108 between the content distribution service 102 and the first client device 104. For example, the playback module 120 of the first client device 104 can generate a request 212 for the manifest file 210 corresponding to the desired digital content 112 to be streamed. The content distribution module 110 receives this request 212 over the network 108 and generates a response 214 containing the manifest file 210. Using the manifest file 210, the playback module 120 can determine which segments 206 of the media presentation 208 should be mapped to the corresponding time durations whose playback (for example, as the last) is desired, and use similar techniques containing a request 212 and a response 214 to request communication of these segments 206 and their reception.

[0028] To define when the segments 206 should be played back, the content distribution module 110 can promote existing header fields and semantics present in the manifest and the segments based on streaming techniques, such as HTTP, and can do so without synchronizing the local clocks of the client devices 104 and 106. Examples of existing response header fields that can be used to define this "when" include a Last Modified header 216, a Date header 218, and an Age header 220. An example of setting the values ​​of these headers is described below and shown in the corresponding figure.

[0029] Fig. Figure 3 shows an exemplary implementation 300 for setting the header 216 relating to the last modification, the date header 218 and the age header 220 of the answer 214 from Fig. 2. This implementation 300 is shown using first, second, and third phases 320 and 302, 304, and 306, respectively. In the first phase 302, a request 212 is generated and communicated by the communication module 116 for reception by the content distribution module 110 of the content distribution service 102 via the network 108. The request 212 can, for example, request communication of a manifest file 210 for use in specifying the content segments to be streamed.

[0030] In the second phase 304, the content distribution module 110 uses a response generation module 308, which is at least partially implemented in hardware, to form the response 214. The response includes a last modification header 216, the date header 218, (optionally) the age header 220, and the manifest file 210. The last modification header 216 is set by the content distribution module 110 according to a time displayed by a clock 222 linked to the content distribution service 102, indicating when the media presentation 208 of the digital content 112 was last modified, for example, when a segment 206 was added in connection with a live stream.

[0031] The date header 218 is set by the content distribution module 112 according to a time displayed by clock 222 when the response 214 is generated by the response generation module 308. In one or more implementations, the clock 222 used to set the last modification header 216 is synchronized with, and / or the same as, the clock 222 used to set the date header 218.

[0032] The age header 220 is optionally used to indicate the amount of time that the response 214 has spent in a cache or in one or more intermediate locations (such as intermediate servers, routers, firewalls, and the like) since its creation by the response generation module 308, for example, at the content distribution service 102. These intermediate locations are used to communicate the response 214 over the network 108. The response 214 is communicated by the content distribution service 102 over the network 108 for receipt by the first client device 104 in this example. The first client device 104 can then use these headers to determine when to play back segments of the digital content in a manner synchronized with the other client devices, an example of which is described below.

[0033] Fig. Figure 4 shows an exemplary implementation 400 for using the last modification header 216, the date header 218, and the age header 220 of answer 214 from Fig. 3. To define when the digital content should be played back. Implementation 400 is represented such that it uses first and second phases 402 and 404. In the first phase, 402, the playback module 120 determines the age of the digital content, and in particular the age of the respective segments of the digital content to be played back. This is done by the playback module 120 by subtracting the last modification header 216 from the date header 218. In other words, it is done by subtracting the time at which the digital content was last modified—for example, when a segment was added to the digital content—from the time at which the response 214 was generated. The age header 220 is added to this result, if applicable.This was added to include the time the response spent in a cache during communication, such as in a cache of an intermediate server on network 108, in a cache of the content distribution service 102, and so on. In this way, the "true age" of the response is determined without using a clock at the first client device 104.

[0034] In the second phase, 404, a time is calculated to serve as the basis for defining when the content will be played back. This time is calculated by subtracting the age calculated in the first phase, 402, from a reset time. The reset time includes a buffer period to promote consistent playback. The reset time can be predefined as a static time period that is consistent between the first and second clients (104, 106). Alternatively, the reset time can be defined dynamically to address latency, as described below in the context of... Fig. As described in section 6, to reduce.

[0035] This time is then used as the basis for defining "when" the segments of the digital content should be played back. By being able to determine the "age" of response 214 using the headers and reset times, synchronization between the first and second client devices 104 and 106 can be achieved. For example, the first client device 104 can determine an age that differs from the age determined by the second client device 106. Using the reset times and the respective ages, the "when" of playback is synchronized by taking these differences into account.In one or more implementations, times requiring higher precision (such as fractions of a second) are used in additional headers to improve accuracy compared to traditional HTTP headers, which are limited to specifying times using whole seconds and larger. This enables sub-second synchronization. Further examples are described using the procedures below. Exemplary procedures

[0036] The following discussion describes techniques for synchronizing digital content streaming that can be implemented using the systems and devices described above. Aspects of each procedure can be implemented in hardware, firmware, or software, or a combination thereof. The procedures are shown as a set of blocks that specify operations that can be performed by one or more devices and are not necessarily restricted to the sequences shown for performing the operations by the respective blocks. Parts of the following discussion refer to Fig. 1 to 4 referred.

[0037] Fig. Figure 5 shows an example implementation (Block 500) where a time is determined as the basis for defining when the content should be played back. A request to stream the content is communicated (Block 502). For example, request 212 can request a manifest file 210 for use when streaming the digital content 112.

[0038] A response to the request is received. The response includes the time the digital content was last modified and the time the response was generated (Block 504). The last modification time can be specified, for example, as the Last Modification header 216 (e.g., the HTTP response header "Last Modified"), which specifies the time when a segment 206 was added to a media presentation. The response generation time is generated using a Date header 218, such as the HTTP response header "Date". The response can also include an Age header, indicating the time the response has spent in at least one cache, using an Age header 220, such as the HTTP header "Age".

[0039] The logical consistency of the response is now checked (Block 506). For example, the playback module 120 can check and determine that the date header 218 specifies a time that is not earlier than a time specified by the header 216 relating to the last modification. If logical consistency is lacking, subsequent processing is not carried out, thus protecting against errors and saving computer resources.

[0040] An age is calculated by subtracting the time the digital content was last modified from the time the response was generated (Block 508). For example, the playback module 120 can subtract the last modification header 216 from the date header 218. The age header 220 can also be added to this value, if specified. In this way, the age describes a time span that has elapsed between the availability of a newly added segment (as indicated by the last modification header 216) and the generation of the response 214, to which the time spent in the cache is added, if specified.

[0041] A time is determined by subtracting the age from a reset time, the time being used to define when the playback of the digital content stream should occur (Block 510). The reset time may, for example, include a buffer time to ensure smooth playback of the digital content 112. In live streaming, the reset time is set as the time after the end of the last available segment. The reset time can be defined statically (i.e., as a set time interval) or dynamically to control latency, as illustrated below. Fig. As described in section 6, the stream of digital content is at least partially reproduced based on the specified time (block 512). By using this technique for both the first client device 104 and the second client device 106, synchronization of the reproduction of the digital content 112 can be achieved.

[0042] Fig. Figure 6 shows a procedure 600 in an exemplary implementation where a time interval between changes to the digital content is determined, which is then used to reduce the latency in the playback of the digital content. A time interval between changes to the digital content (block 602) is determined. The manifest file can, for example, specify a maximum allowable segment duration for the media presentation 208. Based on this, an interval can be determined to describe when "new" segments 206 of the digital content 112 are made available, which is then used to reduce the latency in the playback of the content, as described below.

[0043] As before, the age is calculated as the difference between a header relating to the last modification and a date header in a response to a request to stream the digital content (Block 604). A time is then determined at which the stream of digital content should be played back. This time is determined by subtracting the age from a reset time, as previously described. In this case, however, the reset time is based at least partially on the determined time interval between changes (Block 606). The reset time can be calculated, for example, by adding a set buffer time (e.g., to ensure smooth playback) to the determined time interval.In this way, the playback of the digital content stream is performed, at least partially, based on a specific time (block 608) with minimal latency, based on when the segments are made available for playback. When executed by multiple client devices, this can also be used to achieve synchronization between the devices and reduce latency. Exemplary system and exemplary device

[0044] Fig.Figure 7 shows, generally, an exemplary system at 700 that includes an exemplary computing device 702, which represents one or more computing systems and / or devices that can implement the various techniques described herein. This is illustrated by the inclusion of the playback module 120. The computing device 702 can be, for example, a server of a service provider, a device associated with a client (e.g., a client device), an on-chip system, and / or any other suitable computing device or such computing system.

[0045] The exemplary computing device 702 is depicted as including a processing system 704, one or more computer-readable media 706, and one or more I / O interfaces 708, which are communicatively coupled to one another. Although not shown, the computing device 702 may further include a system bus or other data and instruction transmission system that couples the various components. A system bus may include any bus structure or a combination of different bus structures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and / or a processor or local bus that utilizes a variety of bus architectures. A variety of other examples are also included, such as control and data lines.

[0046] The 704 processing system provides functionality for performing one or more operations using hardware. Accordingly, the 704 processing system is represented as including a hardware element 710, which can be configured as a processor, functional block, and the like. This may involve a hardware implementation as an application-specific integrated circuit or other logic circuit formed using one or more semiconductors. The 710 hardware elements are not limited by the materials from which they are formed or by the processing mechanisms employed. For example, the processors may be formed from a semiconductor(s) and / or transistors (e.g., electronic integrated circuits (ICs)). In this context, processor-executable instructions may also be electronically executable instructions.

[0047] The computer-readable storage media 706 are represented as including a memory / storage component 712. The memory / storage component 712 provides storage / storage capacity in conjunction with one or more computer-readable media. The memory / storage component 712 may include volatile media (such as random access memory (RAM)) and / or non-volatile media (such as read-only memory (ROM), flash memory, optical disks, magnetic disks, and the like). The memory / storage component 712 may also include fixed media (such as RAM, ROM, a fixed hard disk drive, and the like) as well as removable media (such as flash memory, a removable hard disk drive, an optical disk, and the like). The computer-readable media 706 may be configured in a variety of other ways, as described below.

[0048] The input / output interface(s) 708 provides functionality that enables a user to input commands and information into the computing device 702, and also enables information to be presented to the user and / or other components or devices using various input / output devices. Examples of input devices include a keyboard, a cursor control device (for example, a mouse), a microphone, a scanner, touch functionality (for example, capacitive or other sensors configured to detect physical touch), a camera (which, for example, can detect visible or invisible wavelengths, such as infrared frequencies, to detect movement as gestures that do not imply touch), and the like.Examples of output devices include a display device (such as a monitor or projector), speakers, a printer, a network card, a tactile response device, and the like. Therefore, the Computing Device 702 can be configured in a variety of ways, as described below, to support user interaction.

[0049] Various techniques have been described in the general context of software, hardware elements, or program modules. Generally, such modules comprise routines, programs, objects, elements, components, data structures, and the like, which perform specific tasks or implement certain abstract data types. For the purposes of this document, the terms "module," "functionality," and "component" generally refer to software, firmware, hardware, or a combination thereof. The characteristics of the techniques described here are platform-independent, meaning that the techniques can be implemented on a wide variety of commercially available computing platforms with a wide range of processors.

[0050] An implementation of the described modules and techniques can be stored on or transmitted via some form of computer-readable medium. The computer-readable media can include a variety of media accessible to the Computing Device 702. For example, and not as a limitation, computer-readable media can include "computer-readable storage media" and "computer-readable signal media."

[0051] "Computer-readable storage media" refers to media and / or devices that enable the permanent and / or non-temporary storage of information, as opposed to mere signal transmission, carrier waves, or signals as such. Therefore, computer-readable storage media do not include signal-carrying media. Computer-readable storage media include hardware, such as volatile and non-volatile, removable and non-removable media, and / or storage devices implemented in a process or technology suitable for storing information, such as computer-readable instructions, data structures, program modules, logic elements / circuits, or other data.Examples of computer-readable storage media may include, but are not limited to, RAM, ROM, EEPROM, flash memory or other storage technology, CD-ROM, DVD or other optical storage, hard disks, magnetic cartridges, magnetic tape, magnetic storage disk or other magnetic storage devices, or any other storage device, physical media or manufactured product suitable for storing the desired information and being accessible to a computer.

[0052] "Computer-readable signal media" refers to a signal-carrying medium configured to transmit instructions to the hardware of the Computing Device 702, for example, over a network. Signal media can typically embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as carrier waves, data signals, or another transport mechanism. Signal media also include any information distribution medium. The term "modulated data signal" refers to a signal in which one or more of its properties are set or modified such that information is encoded in the signal.For the purposes of example, and not as a limitation, communication media includes wired media, such as a wired network or a direct wired connection, as well as wireless media, such as acoustic, radio frequency-based, infrared and other wireless media.

[0053] As described above, the hardware elements 710 and the computer-readable media 706 modules represent programmable device logic and / or fixed device logic implemented in hardware, which in some embodiments can be used to implement at least some aspects of the techniques described herein, such as executing one or more instructions. Hardware may include components of an integrated circuit or on-chip system, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), and other implementations made of silicon or other hardware.In this context, hardware can act as a processing device that executes program tasks defined by instructions, and / or as logic embodied by the hardware, as well as hardware used to store instructions for execution, such as computer-readable storage media as described above.

[0054] Combinations of the foregoing can also be used and implement various techniques described herein. Accordingly, software, hardware, or executable modules can be implemented as one or more instructions and / or logic embodied in any form by computer-readable storage media and / or one or more hardware elements 710. The computing device 702 can be configured to implement certain instructions and / or functions according to software and / or hardware modules. Similarly, a software implementation of a module executable by the computing device 702 can also be at least partially implemented in hardware, for example, using computer-readable storage media and / or hardware elements 710 of the processing system 704.The instructions and / or functions can be executed / operated by one or more manufactured products (for example, one or more computing devices 702 and / or processing systems 704) to implement techniques, modules and examples as described herein.

[0055] The techniques described here can be supported by various configurations of the 702 computing device, and one is not limited to the specific examples of techniques described here. Furthermore, the functionality can be implemented wholly or partially through a distributed system, for example, via a 714 "cloud" using a 716 platform, as described below.

[0056] Cloud 714 includes and / or represents a platform 716 for resources 718. Platform 716 abstracts the underlying functionality of the hardware (e.g., servers) and software resources of Cloud 714. The resources 718 can include applications or apps and / or data that can be used while computing is performed on servers remote from the computing device 702. The resources 718 can also include services provided over the internet and / or a subscriber network, such as a cellular or Wi-Fi network.

[0057] Platform 716 can abstract resources and functions for connecting the computing device 702 to other computing devices. Platform 716 can also serve to abstract resource scaling in order to provide an appropriate level of scaling for an expected demand for resources 718 implemented via Platform 716. Accordingly, in an embodiment with a networked device, an implementation of the functionality described herein can be distributed across System 700. For example, the functionality can be implemented partly on the computing device 702 and partly via Platform 716, which abstracts the functionality of Cloud 714. Concluding remarks

[0058] Although techniques have been described in a language specific to structural features and / or methodological procedures, it should be clear that the invention defined by the appended claims is not necessarily limited to the specific features or procedures described. Rather, the specific features and procedures are disclosed as exemplary forms of implementation of the claimed invention.

Claims

[1] Method for streaming digital content (112) in a digital media environment (100), wherein the method is implemented by a computing device (702) and comprises: Receiving a response (214) to a request (212) for streaming the digital content (112) by a computing device (702), wherein the response (214) includes a time at which the digital content (112) was last modified and a time at which the response (214) was generated; Calculating an age by the computing device (702) by subtracting the time at which the digital content (112) was last modified from the time at which the answer (214) was generated; Determining a time by the computing device (702) by subtracting the age from a predefined reset time, the time being usable to define when a playback or rendering of the stream of digital content (112) is to take place; and Reproducing or rendering the stream of digital content (112) by the computing device (702) at least partially on the basis of the specified time. [2] Method according to claim 1, wherein the time at which the digital content (112) was last modified is set using a clock (222) of a content distribution service (102) to generate the response (214) as part of a header (216) relating to the last modification. [3] Method according to claim 1 or 2, wherein the time at which the response (214) has been generated is set using a clock (222) of the content distribution service (102) to generate the response (214) as part of a date header (218). [4] Method according to any one of the preceding claims, wherein: The answer (214) further includes an age header (220) that indicates a time period that the answer (214) has spent in at least one cache; and Calculating the age involves adding the age header (220). [5] Method according to claim 4, wherein the cache is included as part of a content distribution service (102) that streams the digital content (112) or an intermediate area through which the response (214) is communicated between the content distribution service (102) and the computing device (702). [6] Method according to one of the preceding claims, wherein the response (214) includes a manifest file (210) that maps time durations to respective segments (206) from a plurality of segments (206) within a media presentation (208) of the digital content (112). [7] Method according to any of the preceding claims, wherein the request (212), the response (214) and the playback or rendering are configured according to a hypertext transfer protocol. [8] Method according to any of the preceding claims, wherein the header (216) relating to the last modification or the date header (218) specifies fractions of a second. [9] Method according to one of the preceding claims, further comprising a determination by the computing device (702) of a time interval between changes to the digital content (112) and a setting of the reset time at least partially on the basis of the determined time interval. [10] Method according to claim 9, wherein the determination is based on respective time intervals to which respective segments (206) are added or added to a media presentation (208) of the digital content (112). [11] Method for streaming digital content (112) in a digital media environment (100), wherein the method is implemented by a computing device (702) and comprises: Communication of an HTTP request (212) (Hypertext Transfer Protocol HTTP) for a manifest file (210) for streaming the digital content (112) by the computing device (702); Receiving an HTTP response (214) to the request (212) by the computing device (702), wherein the response (214) includes a last modification header (216), a date header (218) and the manifest file (210); Calculating an age by the calculating device (702) by subtracting the header (216) relating to the last modification from the date header (218); Determining a time by the computing device (702) by subtracting the age from a predefined reset time, the time being usable to define when a playback or rendering of the stream of digital content (112) should take place; the retrieval by the computing device (702) of at least one segment (206) of the digital content (112) from a media presentation (208) on the basis of the manifest file (210) and the specified time according to the hypertext transfer protocol; and Reproducing or rendering at least one segment (206) of the digital content (112) at least partially on the basis of the specified time by the computing device (702). [12] Method according to claim 11, wherein: the last modification header (216) is set by a content distribution service (102) that created the response (214), wherein the last modification header (216) indicates a time at which the digital content (112) was last modified, as indicated by a clock (222) of the content distribution service (102); and the date header (218) is set by the content distribution service (102) that created the response (214), where the date header (218) specifies a time at which the response (214) is generated as specified by a clock (222) of the content distribution service (102). [13] Method according to claim 11 or 12, wherein: The answer (214) further includes an age header (220) that indicates a time period that the answer (214) has spent in at least one cache; and Calculating the age involves adding the age header (220). [14] Method according to any one of claims 11 to 13, wherein the header (216) relating to the last modification or the date header (218) specifies fractions of a second. [15] Method according to any one of claims 11 to 14, further comprising: Determining a time interval between changes to the digital content (112) by means of the computing device (702); and setting the predefined reset time by the calculating device (702) at least partially on the basis of the determined time span. [16] Method according to any one of claims 11 to 15, further comprising a check by the computing device (702) for a logical consistency of the header (216) relating to the last modification with respect to the date header (218), wherein the computation, determination and reproduction or rendering are not carried out in response to a check that the header (216) relating to the last modification and the date header (218) are not logically consistent. [17] System (200) comprising a playback module (120, 122) implemented at least partially in the hardware of a client device (104, 106) for streaming digital content (112) in a digital media environment (100), wherein the playback module (120, 122) is configured to perform operations that include: Determining a time interval between changes to the digital content (112); calculating an age as the difference between a last modification header (216) and a date header (218) in a response (214) to a request (212) to stream the digital content (112); Determining a time by subtracting the age from a reset time, wherein the reset time is based at least partially on the determined time interval between changes and the time is usable to define when a playback of the stream of digital content (112) is to take place; and Replaying the stream of the digital content (112) at least partially on the basis of the specified time. [18] System (200) according to claim 17, wherein: the last modification header (216) is set by a content distribution service (102) that created the response (214), wherein the last modification header (216) indicates a time at which the digital content (112) was last modified, as indicated by a clock (222) of the content distribution service (102); and the date header (218) is set by the content distribution service (102) that created the response (214), where the date header (218) specifies a time at which the response (214) is generated as specified by a clock (222) of the content distribution service (102). [19] System (200) according to claim 17 or 18, wherein: The answer (214) further includes an age header (220) that indicates a time period that the answer (214) has spent in at least one cache; and Calculating the age involves adding the age header (220). [20] System (200) according to any one of claims 17 to 19, wherein the header (216) relating to the last modification or the date header (218) defines fractions of a second.

Images