Method and system for providing a content stream based on a delivered content stream

Abstract

A method for providing a content stream based on capturing an initial delivery of the content stream. The method comprises the steps of: acquiring manifest data associated with the initial delivery of the content stream, acquiring the manifest data one or more times in sequence during the initial delivery of the content stream to generate one or more manifest files; associating a timestamp with each of the manifest files, the timestamp indicating the time when the associated manifest file was acquired; processing each of the manifest files to identify one or more addresses referenced in the manifest file that include one or more segments of a portion of the content stream in the initial delivery; accessing one or more of the segments identified via the one or more addresses referenced in the manifest file; modifying a last one of the manifest files to include at least a portion of an earlier one of the manifest files; and providing a client with access to the manifest files, including the modified last one, and the accessed one or more segments, thereby enabling the client to receive at least a portion of the content stream.

Description

Technical Field

[0001] The present disclosure relates to techniques (eg, systems, methods, or apparatuses) for capturing delivery of content streams and techniques for providing content streams based on previous delivery of the content streams. Background Art

[0002] Dynamic Adaptive Streaming over HTTP (DASH) has become more popular for streaming content over the Internet from traditional HTTP web servers. DASH is defined in the standard ISO / IEC 23009-1:2014, also known as Moving Picture Experts Group Dynamic Adaptive Streaming over HTTP or MPEG-DASH.

[0003] MPEG-DASH uses adaptive bitrate streaming technology to adapt streaming content to current network conditions. Media content is broken down into a sequence of small files called segments, each of which contains a short playback time interval. Each segment is encoded at a variety of different bit rates or spatial resolutions so that the alternative versions of the segment include the same content and cover the same aligned short intervals of playback time, but can be delivered at different bit rates. During playback, the MPEG-DASH client that plays the streaming content automatically selects the next segment to download from the alternative segment based on the current network conditions. This enables the client to select the segment with the highest bitrate segment, which can be downloaded in time for playback without causing pauses or rebuffering during playback.

[0004] The MPEG-DASH standard defines a manifest file called a Media Presentation Description (MPD) that provides information about the media segments that comprise the media content of a stream. This information includes timing information and media characteristics, such as the video resolution and bitrate used for the segment, as well as a Uniform Resource Identifier (URI) that can access each segment.

[0005] During delivery (e.g., transmission) of a content stream (e.g., live content), manifests and segments are dynamically generated by an MPEG-DASH server as the content becomes available. The resulting stream is typically available during a specified availability period, with each segment specified with an availability start time and an availability end time. Being able to capture and replay streams is useful for a variety of purposes. For example, debugging client playback problems encountered during live streaming may be difficult if the device setup originally used to generate the stream is not available to regenerate the live stream for debugging. As another example, monitoring the quality of stream delivery may be more easily achieved if the stream can be reproduced at a later time.

[0006] However, simply capturing the delivery of a stream may not enable the captured content to be re-streamed. When the stream is re-delivered, the content originally transmitted may no longer be accessible to the client to replay the stream. In addition, adaptive bitrate streaming techniques may not allow re-delivery of a stream unless the originally delivered content is captured at multiple bit rates or the content is re-encoded at multiple bit rates for re-streaming. In addition, in order to facilitate testing and debugging of devices and systems to support the delivery of content, it is useful to be able to deliver a previous delivery of the content within the time required to complete the test or debugging, even if this is longer than the length of the original delivery. Summary of the invention

[0007] The present disclosure proposes a system and method for providing a content stream based on capturing an initial delivery of the content stream. According to one aspect of the present disclosure, the method includes the following steps: obtaining manifest data related to the initial delivery of the content stream, obtaining the manifest data one or more times in sequence during the initial delivery of the content stream to generate one or more manifest files; associating a timestamp with each of the one or more manifest files, the timestamp indicating the time when the associated manifest file was obtained; processing each of the one or more manifest files to identify one or more addresses referenced in the manifest file of one or more segments that include a portion of the content stream in the initial delivery; accessing one or more of the segments identified via the one or more addresses referenced in the manifest file; modifying the last manifest file in the one or more manifest files to include at least a portion of an earlier manifest file in the one or more manifest files; and providing a client with access to the one or more manifest files including the modified last manifest file and the accessed one or more segments, so that the client can receive at least a portion of the content stream.

[0008] The method may also include storing each of the one or more manifest files to a location that enables a client to access the stream to render the content.

[0009] In one embodiment, the second manifest file or a later-obtained manifest file may be obtained after expiration of at least a predetermined time delay, wherein the predetermined time delay is a delay from the time when the last previously-obtained manifest file was obtained.

[0010] In one embodiment, access to the one or more segments is attempted for all of the one or more segments referenced by the address.In one embodiment, access to the one or more segments may be attempted for segments that meet a predetermined criterion, for example, such that it is determined whether the predetermined criterion is met before accessing a segment.

[0011] In one embodiment, the method further includes storing the accessed one or more segments and editing one or more of the manifest files to reference the one or more new addresses of the stored segments.

[0012] In one embodiment, the step of modifying the last manifest file includes copying a first period from an earlier manifest file and inserting the copied period as a second or later period of the last manifest file.

[0013] In one embodiment, the method further comprises processing each manifest file to identify an availability time for each identified segment, and attempting to access the identified segment before the availability time for the corresponding segment expires. In one embodiment, each of the one or more segments has an associated availability period, and processing of each manifest file is performed during the availability period for the corresponding segment. In one embodiment, the method further comprises editing the one or more manifest files to change one or more availability time indications in the manifest files.

[0014] According to another aspect, a system for providing a content stream based on capturing an earlier delivery of the content stream is proposed. The system comprises a manifest data access unit and a processing unit. The manifest data access unit is adapted to obtain manifest data related to the earlier delivery of the content stream, the manifest data being obtained one or more times in sequence during the earlier delivery of the content stream to generate one or more manifest files. The system is adapted to associate a timestamp with each of the one or more manifest files, the timestamp indicating the time when the associated manifest file was obtained; process each of the one or more manifest files to identify one or more addresses referenced in the manifest file containing one or more segments of a portion of the content stream in the earlier delivery; access one or more segments identified via the one or more addresses referenced in the manifest file; and modify a last manifest file of the one or more manifest files to include at least a portion of an earlier manifest file of the one or more manifest files. The system is adapted to provide a client with access to the one or more manifest files including the modified last manifest file and the accessed one or more segments, the access enabling the client to receive at least a portion of the content stream.

[0015] In one embodiment, the system is further adapted to save each of the one or more manifest files to a location for downloading to the client to enable the client to play the content stream. In one embodiment, any second or later manifest file is acquired after expiration of at least a predetermined time delay after acquiring a last previously acquired manifest file. In one embodiment, the step of modifying the last manifest file may include copying a first time period from an earlier manifest file and inserting the copied time period as a second or later time period of the last copy of the manifest file.

[0016] The system may also be adapted to process each manifest file to identify an availability time for each identified segment, and attempt to download the identified segments only during the availability time for the corresponding segment.

[0017] The present disclosure provides many advantages. It enables effective capture of manifest data edited live by a content stream server during stream delivery, and enables capture of a complete set or selected subset of the original encoded content segments delivered. This enables generation of cyclic stream retransmissions to avoid problems caused by discontinuities in the content stream, and facilitates applications such as testing or debugging of content streams that require continuous operation for extended periods. And by effectively reconstructing the same conditions as the original transmission, it enables retransmission of live stream transmissions, such as being able to more effectively test and debug problems encountered during the original transmission. These advantages are further explained below. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Embodiments will now be described, by way of example only, with reference to the accompanying drawings, in which corresponding reference numerals indicate corresponding parts, and in which:

[0019] Figure 1 shows a simplified block diagram of a system for providing a content stream based on previous delivery of the content stream according to an exemplary embodiment of the present disclosure;

[0020] Figure 2 shows a simplified block diagram of a computing device that can be used to implement components in any embodiment;

[0021] Figure 3 Shows Figure 1 An embodiment of a system showing more details of the system;

[0022] Figure 4 A flowchart of a method for capturing inventory information according to an exemplary embodiment of the present disclosure is shown;

[0023] Figure 5 An example of capturing inventory data in an embodiment of the present disclosure is shown;

[0024] Figure 6 A flowchart showing a method for capturing segments of content including content streaming according to an exemplary embodiment of the present disclosure; and

[0025] Figure 7 A flowchart of a method for re-streaming a captured manifest file and captured segments according to an exemplary embodiment of the present disclosure is shown.

[0026] The drawings are for illustration purposes only and are not intended to limit the scope or protection provided by the claims. DETAILED DESCRIPTION

[0027] The following is a description of certain embodiments. Note that the term "delivery" as used herein includes any means of communicating media or information content, such as through one or more network servers in a format that allows a client to access a content stream, including manifest information and media content segments related to the delivered content. Delivery of content may include transmission or broadcasting of content, and certain embodiments described herein involve transmission or broadcasting of content. However, the concepts and embodiments described herein are not limited to any particular means of delivery, and other forms of communication of content may also be used with any of the described embodiments.

[0028] The present disclosure provides techniques (eg, systems, methods, and apparatus) for capturing a streaming transmission of content and providing the content at a later time, such as re-streaming the transmission at a later time compared to an earlier transmission.

[0029] Figure 1 The embodiment shown in comprises a system 10 for providing a content stream based on an earlier transmission of the content. The system 10 is in communication with a computer system 40, which may comprise one or more servers, for example arranged to form a content delivery network, and the system 10 may receive a content stream 45 and access to manifest data 43 of the content stream from the computer system 40. The system 10 comprises a processing unit 11 for processing manifest data and the content stream, and a data storage unit 13 for storing data files related to the manifest data and the content stream. The system 10 is adapted to provide access to the processed manifest data and the content stream to a client 50, so that the client can receive the manifest data 15 and the content stream 19.

[0030] For the earlier transmission, computer system 40 operates as a provider of content streams in cooperation with system 10 operating as a client, requesting content and services from computer system 40, which services those requests. For the retransmission, system 10 operates as a provider of captured content in cooperation with client 50, which requests content and services from system 10, which services those requests. The client and server for both the earlier transmission and the retransmission may comprise separate units communicating over a computer network such as the Internet, or both the client and server may reside on the same system.

[0031] System 10 can be used for capturing the transmission of content stream 45 and retransmitting the captured content stream. In particular, system 10 can be suitable for capturing content stream. In addition, system 10 can be suitable for processing the captured content stream to allow the captured content to be re-streamed at a later time. In addition, system 10 can be suitable for re-streaming the captured content in a way that reproduces the captured content stream. Live stream (or content stream) as described herein is not limited to delivering (e.g., streaming) events live or "live" when events occur, but also includes any content stream that is progressively encoded so as to be transmitted during transmission. In addition, although these technologies are described herein in the context of live streams, the present disclosure is not limited thereto, and the system and method can also be applied to processing and transmitting content that is not derived from live streams.

[0032] System 10 is applicable to one or more different types of content delivery protocols or formats, such as streaming protocols. Examples of streaming protocols may include, but are not limited to, MPEG-DASH, Apple HTTP Live Streaming (HLS), Microsoft Smooth Streaming, and Adobe HTTP Dynamic Streaming (HDS). The manifest data of the streaming protocol (e.g., MPEG-DASH manifest file) has a hierarchical structure. The manifest data can be organized in one or more segments (e.g., time periods), wherein each segment includes information about a specific time interval of the stream. Each segment typically has a start time and duration, and may be composed of one or more adaptation sets. Each adaptation set may include information about various coded alternative segments for one (or more) of the segments or time periods of the media components of the stream, for example, an adaptation set may include information about video segments, and an adaptation set may include information about audio segments. Each adaptation set typically contains multiple representations, wherein each representation is a coding alternative for the same media component on the same time period, and is different from other representations by bit rate, resolution, number of channels, or some other characteristics. Each representation includes one or more segments, where each segment provides a start time and a Uniform Resource Identifier (URI), ie, an addressable location on a server from which a client can access (eg, download or retrieve) a corresponding segment of the media content.

[0033] System 10, computer system 40, and client 50, as well as components and elements of these systems, may be implemented as Figure 2 Computing device 500 is shown. Figure 2 A block diagram of one implementation of a computing device 500 is shown in which a set of instructions may be executed to cause the computing device to perform any one or more of the techniques or methods described herein. The computing device 500 may be used Figure 1 and Figure 3 Elements of the illustrated embodiment.

[0034] In alternative implementations, the computing device can be connected (e.g., networked) to other machines in a local area network (LAN), an intranet, an extranet, or the Internet. The computing device can operate in the capacity of a server or a client machine in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.

[0035] The computing device may be a personal computer (PC), a tablet computer, a set-top box (STB), a wearable computer system, a personal digital assistant (PDA), a cellular phone, a network appliance, a server, a network router, a switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specifies actions to be taken by the machine. Furthermore, while only a single computing device is shown, the term "computing device" should also be understood to include any collection of machines (e.g., computers) that individually or jointly execute an instruction set (or multiple instruction sets) to perform any one or more of the methods discussed herein.

[0036] The exemplary computing device 500 includes a processing device 502, a main memory 504 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM)), etc.), a static memory 506 (e.g., flash memory, static random access memory (SRAM), etc.), and an auxiliary memory (e.g., data storage device 518) that communicate with each other via a bus 530.

[0037] Processing device 502 represents one or more general-purpose processors, such as a microprocessor, a central processing unit, etc. More specifically, processing device 502 may be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a processor implementing other instruction sets, or a processor implementing a combination of instruction sets. Processing device 502 may also be one or more special-purpose processing devices, such as an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), a network processor, etc. Processing device 502 is configured to execute processing logic (instructions 522) for performing the operations and steps discussed herein.

[0038] The computing device 500 may also include a network interface device 508. The computing device 500 may also include a video display unit 510 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 512 (e.g., a keyboard or a touch screen), a cursor control device 514 (e.g., a mouse or a touch screen), and an audio device 516 (e.g., a speaker).

[0039] The data storage device 518 may include one or more machine-readable storage media (or more specifically, one or more non-transitory computer-readable storage media) 528 on which is stored one or more sets of instructions 522 embodying any one or more of the methodologies or functions described herein. During execution of the instructions 522 by the computing device 500, the instructions 522 may also be located, completely or at least partially, within the main memory 504 and / or within the processing device 502, which also constitute computer-readable storage media.

[0040] Various methods described herein can be implemented by computer programs. A computer program may include a computer code that is arranged to instruct a computer to perform the functions of one or more methods in the various methods described herein. A computer program and / or code for performing such a method may be provided to a device such as a computer on one or more computer-readable media, or more generally, on a computer program product. A computer-readable medium may be temporary or non-temporary. One or more computer-readable media may be, for example, electronic, magnetic, optical, electromagnetic, infrared or semiconductor systems, or a propagation medium for data transmission (e.g., for downloading code via the Internet). Alternatively, one or more computer-readable media may take the form of one or more physical computer-readable media, such as semiconductor or solid-state memory, magnetic tape, removable computer disk, random access memory (RAM), read-only memory (ROM), rigid disk and optical disk, such as CD-ROM, CD-R / W or DVD.

[0041] In one implementation, the modules, components, and other features described herein (e.g. Figure 1 The processing unit 11 and / or Figure 3 The manifest capture unit 12, segment capture unit 16 and / or manifest data editing unit 20) may be implemented as discrete components or integrated in the functionality of hardware components (e.g., ASICS, FPGA, DSP or similar devices) as part of a personalization server.

[0042] A “hardware component” is a tangible (e.g., non-transitory) physical component (e.g., a collection of one or more processors) that is capable of performing specific operations and may be configured or arranged in a particular physical manner. A hardware component may include dedicated circuitry or logic that is permanently configured to perform certain operations. A hardware component may be or include a dedicated processor, such as a field programmable gate array (FPGA) or an ASIC. A hardware component may also include programmable logic or circuitry that is temporarily configured by software to perform certain operations. Thus, the phrase “hardware component” should be understood to include a tangible entity that may be physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a particular manner or to perform specific operations described herein.

[0043] In addition, modules and components can be implemented as firmware or functional circuits within hardware devices. In addition, modules and components can be implemented in any combination of hardware devices and software components, or only in software (e.g., code stored in or otherwise embodied in a machine-readable medium or transmission medium).

[0044] Figure 3 The embodiment shown in FIG. 1 includes a system 10 for providing a content stream based on an earlier transmission of the content stream, wherein: Figure 1 The processing unit 11 comprises a list capturing unit 12, a segment capturing unit 16 and a list data editing unit 20, and wherein, Figure 1 The data storage unit 13 includes a capture list data storage unit 14, a capture segment storage unit 18 and a reflow list data storage unit 22.

[0045] The system 10 and the units of the system are generally implemented as programmable computer devices, which include one or more processors connected via one or more communication buses, memory, data storage such as disk or flash memory, input / output circuits, programmable hardware and / or hardware logic, together with computer program codes and / or instructions executed from the memory on the processor for performing the functions described herein. Each system and unit described herein can be implemented as one or more separate devices or combined into one or more integrated devices, and each function performed by the system and unit can be implemented as one or more separate functions or two or more functions can be combined. For example, the content streaming server 40, the system 10 and the client 50 can be separate devices, or one or all of them can be integrated together, and it can be implemented in a content delivery network or other network-based or cloud-based implementations. The system 10 or a part of the system 10 can be implemented in various devices such as mobile phones, tablet computers, set-top boxes, televisions, personal computers, network servers or other suitable devices.

[0046] The system 10 operates to capture a content stream sent from a content stream server 40 , and manipulate the captured content stream to allow the captured content to be later re-streamed to a client 50 .

[0047] The computer system 40 can generate and store manifest data 42 and content stream segments 44 for presentation during delivery of the stream. The computer system 40 can be configured to provide live content streams, such as live content streams using adaptive bitrate streaming technologies such as Moving Picture Experts Group Dynamic Adaptive Streaming over HTTP (MPEG-DASH), Apple HTTP Live Streaming (HLS), Microsoft Smooth Streaming, and Adobe HTTP Dynamic Streaming (HDS), among others.

[0048] The content stream segments 44 contain the content of the stream, such as video and audio information, encoded in segments, each segment containing the content for a short playback interval. The content for each playback interval is preferably encoded in segments containing alternative versions of the same content, but encoded at one or more bit rates, one or more resolutions, one or more channel numbers, or some other characteristics or attributes, which allows the content for the playback interval to be delivered to the client 50 according to those characteristics or attributes (e.g., different bit rates). The manifest data 42 contains information to be used by the client 50 to select from the content stream segments 44 to play the content streaming.

[0049] The client 50 may be of conventional design, which operates to receive content streams. The client 50 may include software executed on a computer processor, or may include a dedicated client server device, and may be implemented in a suitable end-user device such as a mobile phone, a computer, a set-top box, a television, etc., or may be implemented as a network or cloud-based client that receives content streams from the system 10 and communicates with the end-user's device. In some embodiments, the client 50 may be integrated into the system 10. In some embodiments, the client 50 may be a live streaming client, such as a Google Shaka player, a VLC media player, or other live streaming clients, and the client 50 may support MPEG-DASH live streaming media, or may be a web browser or media player that supports MPEG-DASH or other streaming services.

[0050] The client 50 may include one or more facilities for retrieving content streaming from the system 10. In the illustrated embodiment, the client 50 includes a manifest data parser 52, a segment parser 54, and a media player 56.

[0051] In this embodiment, the client 50 accesses manifest data from the re-stream manifest data storage unit 22. The manifest data parser 52 parses the accessed (e.g., downloaded or retrieved) manifest data and selects a set of segments that it can use based on the information in the manifest data, the capabilities of the client, the selections of its user, and the current network conditions. The client 50 then begins accessing (e.g., downloading) the selected segments, and the segment parser 54 parses these segments to extract video and audio information, which is passed to the media player 56 to play the content stream.

[0052] Figures 4 to 7 The flowchart shown in shows steps that may be implemented in system 10 in some embodiments of the present disclosure.

[0053] Figure 4 The steps of a process 200 performed by the system 10 in one embodiment to capture inventory data are shown. The process is explained in the context of live streaming of multimedia content such as video of a live concert, but is equally applicable to other contexts, such as re-streaming or retransmitting or otherwise providing access to any type of information content obtained from an earlier live or non-live stream or transmission or by other means.

[0054] The system first acquires and stores manifest data during an initial stream (e.g., a live stream). The manifest data 42 typically includes one or more addresses, such as uniform resource identifiers (URIs), where each address indicates a location where one or more stream segments 44 can be accessed. Each address can provide a location for an alternative encoding of some or a portion of a segment (e.g., a segment comprising the same media content encoded according to one or more attributes or characteristics of a short interval of the content stream (e.g., a different bit rate or resolution)).

[0055] For the initial stream, the manifest data 42 generated by the computer system 40 will change as the content stream proceeds. When the media content becomes available, such as when a live video feed from an event is received, the media content is encoded into the content stream segments 44 by the computer system 40 and stored as ready for streaming. The manifest data 42 is constructed live by the computer system 40 (e.g., when the media content becomes available), such as stored in a manifest file, which is updated by appending new segment information to the newly created segments as the content stream proceeds. After a delay sufficient to ensure that any client that plays the content stream has accessed (e.g., downloaded) the segments to be removed from the manifest file, the manifest data 42 can also be updated by removing the segment information of the older segments that have been streamed from the manifest file.

[0056] To capture the content stream, new versions of the manifest data are periodically accessed, for example by accessing updated manifest files from system 10 as the transmission proceeds. At step 210, system 10 accesses (e.g., downloads or retrieves) currently existing manifest data 42 from content stream server 40, and associates a timestamp with the retrieved manifest data file in step 220, the timestamp indicating the time when the associated manifest data was retrieved. Each accessed (e.g., downloaded) copy of manifest data 42 is referred to herein as a capture manifest file, each capture manifest file relating to a time slice of the content stream transmission.

[0057] The system 10 stores the captured inventory data and associated timestamps in step 230 as a Figure 5 If the content stream capture period has not ended (step 240), the system 10 may optionally wait for a certain period of time (e.g., a predetermined delay period of time) as shown in step 250, and then repeat the process by again accessing a copy of the manifest data 42 from the content stream server 40, timestamping the next manifest file, and storing the next manifest file and the associated timestamp as a subsequent manifest file 60b (e.g., a second capture manifest file) with timestamp 62b in step 230, see Figure 5This process is repeated until the content streaming ends, or the stream capture period ends, or the available storage in system 10 is full, or some other event occurs. The attributes (e.g., name) of each captured manifest file are preferably modified or associated with sequence information to indicate the position in the sequence at which the manifest data was captured. This enables system 10 to facilitate later redistribution (e.g., re-streaming) of each manifest file according to the sequence (e.g., manifest 1, manifest 2, etc.).

[0058] Figure 5 An example of system 10 capturing manifest data 42 is shown. During transmission of a content stream, manifest data 42 is accessed at times t0, t1, t2, etc. In this example, manifest files 60a, 60b, 60c, etc. are obtained from computer system 40 at each time t0, t1, t2, etc., respectively. In this example, the captured manifest files 60a, 60b, 60c, etc. are renamed as manifest 1, manifest 2, manifest 3, etc. to indicate the order in which the manifest data in each file was obtained, and are saved with associated timestamps 62a, 62b, 62c, etc., respectively. In this way, each copy or instance of manifest data 42 in a sequence can be accessed from computer system 40 and time-stamped to enable system 10 to gradually obtain all of the manifest information for retransmitting all or part of the stream during the capture period, thereby enabling the stream to be recreated later from the manifest files and reference segments of the original transmission.

[0059] Figure 6 The steps of a process 300 performed by the system 10 for processing captured segments containing transmission content in one embodiment are shown.

[0060] When periodically accessing (e.g., downloading or retrieving) manifest data 42, system 10 accesses each newly captured manifest file (step 310) and parses the manifest file (step 320) to extract segment addresses from the manifest data, thereby enabling system 10 to download the referenced live stream segments from content stream server 40.

[0061] The system 10 may apply selection criteria to select which segments to access (e.g., download or retrieve) from the computer system 40 (step 330). In one embodiment, the system 10 accesses (e.g., downloads or retrieves) all candidate segments for each playback time interval (step 340). This results in the system acquiring a complete set of segments generated by the content stream server 40 for all bit rates or resolutions for the capture period. However, it may be desirable to limit the set of segments downloaded to limit the amount of storage required in the system to store the captured segments. For example, limited downloading may be achieved by selecting the candidate segments to download according to predetermined selection criteria (step 350). Various selection criteria may be used, such as not accessing (e.g., downloading) candidate segments encoded at the highest bit rate or resolution or at a bit rate or resolution above a certain predetermined threshold, accessing (e.g., downloading) selected portions or elements of the content stream, etc.

[0062] The segments are accessed (eg, downloaded) and stored in the system 10 (step 360), or the segments may be stored in a separate storage system from which they may be accessed later when needed.

[0063] The system 10 updates the captured manifest file to modify the segment addresses to reference the new storage location of the captured segments (step 370), i.e., the addresses of the captured segments can be downloaded. Where the segment addresses in the manifest file 42 are relative addresses, this can be effectively achieved by modifying the base addresses to point to the new storage location of the captured segments while retaining separate relative addresses for each captured segment. If absolute addresses are used, these absolute addresses can be modified to point to the new storage location of the captured segments, or preferably can be modified to relative addresses to enable the storage location to be changed as needed at any future time.

[0064] Reference Figure 6 The process 300 described may be used with reference to Figure 4 The manifest file capture process 200 described runs in parallel. The downloading and storing of stream segments and the editing of segment addresses in the captured manifest file may be performed as each new copy of the manifest data 42 is accessed (e.g., downloaded), or may be performed after a certain delay by accessing a stored capture manifest file. However, the system 10 may attempt to access the content stream segments 44 referenced in each captured manifest file during the availability period of the relevant segments to avoid the system 10 attempting to access the segments before the content stream segments 44 are accessible from the content stream server 40 or after the content stream segments 44 become unavailable on the content stream server 40.

[0065] For live streaming, segments usually have different availability times, which indicate the earliest time and the latest time that a segment can be downloaded without receiving an error response. As live streaming proceeds, the live edge (the latest edge of the live stream) moves forward in time with the current wall clock time. Since the server is still recording these segments, the segments at the live edge cannot be downloaded and played. The latest segment that can be reliably obtained can be determined by backing up a segment size (e.g., by the maximum segment size) from the live edge, and also by considering the time required for the server to update the manifest file to include a reference to the latest segment and the network delay when accessing the segment. When a streaming event occurs, the content stream server 40 will record and store (e.g., save) the segment 44, but the segment can be available in a limited time window. This can occur, for example, because after a predetermined amount of time (e.g., after 10 minutes) the segment is deleted to release the storage space on the content stream server 40 for new segments.

[0066] The manifest data 42 may include an availability attribute that defines which segments are available for download from the server, and the system 10 may use this attribute to select segments for download. For example, the manifest file may specify a moving window of availability around the live edge by specifying, for example, a range of segment presentation times between the live edge and 10 minutes before that. However, the manifest file may list more or fewer segments than the availability window. If the manifest file lists more segments, the additional segments may not have been available when the manifest was downloaded; if the manifest lists fewer segments, the segments may not fill the entire availability window, but if the segments fall within the availability window, the client may still be able to download the segments even if the segments are no longer listed in the manifest file.

[0067] The system 10 is also configured to recreate the captured live streaming using the captured manifest file and its associated timestamps and the captured segments. Figure 7 The steps of a process 400 performed by the system 10 in one embodiment for distributing a new stream (eg, a retransmission) based on a captured manifest file and captured segments are shown.

[0068] The captured manifest files may be sorted into a sequential set of manifest files according to their associated timestamps in the order in which they were downloaded during the live stream. In step 410, the first captured manifest file is identified. Note that although Figure 7 The process 400 is shown starting from the first capture manifest file, but the process 400 may also start from any other of the captured manifest files to enable the system 10 to retransmit the captured live stream from any point within the capture period.

[0069] If it is determined in step 420 that the manifest file being processed (i.e., the first captured manifest file or one of the next subsequently captured manifest files) is not the last, then in step 450, the manifest file is associated with new attributes (e.g., renamed to a re-streamed manifest file to provide the manifest file name expected by the client) and stored (e.g., copied or saved) to a storage location in system 10 (or to a separate storage location in another server), such as Figure 3 As shown in the re-stream manifest file storage unit 22 in FIG. 1 , the client 50 can access and download the manifest file from the re-stream manifest file storage unit 22 .

[0070] Optionally, the system 10 may be configured to then wait for a particular time period, such as a predetermined delay time period (step 460), which may be determined based on the availability time period of the manifest data, and then identify the next captured manifest file based on the sequence indicated by the associated timestamps, and repeat the process in steps 450 to 470 until the last captured manifest file is processed.

[0071] If it is determined in step 420 that the manifest file being processed is the last manifest file, the system 10 modifies the manifest file to enable a "loop" of re-streaming. As shown in step 430, this can be achieved by copying the first portion of the first captured manifest file (or any manifest file captured earlier than the last) and inserting it as the end of the last captured manifest file (note that if there is one captured manifest file, the first captured manifest file will also be the last). For example, in the case of encoding the content stream using MPEG-DASH, the first period of the first capture manifest file can be copied and inserted into the last captured manifest file as the last period. In the case where the manifest file includes a single period, the period can be copied to create an identical second period in the manifest file. The period ID of the copied period is also changed to make it different from the first period, and can indicate that the copied period is the second, third, or fourth period, etc., as appropriate, or indicates the next upcoming period period. This is in the Figure 5 As shown in Figure 5 An example of the capture of manifest data 42 by the system 10 is shown. In this example, a period "period.1" in a first capture manifest file 60a is copied and saved as a renamed second period "period.y" into a final capture manifest file 60x.

[0072] As an alternative to storing the first or earlier time period, the captured manifest file and the time period (e.g., timestamp) in the segment can be modified so that the first (or earlier) manifest file follows the last captured manifest file in time to achieve a "loop" of re-streaming. This alternative would require additional processing to re-stream, for example, additional processing to recreate each segment with a new timestamp. If the stream is encrypted, this would also require access to the encryption key used to encrypt the content stream so that each segment can be decrypted, modified, and re-encrypted.

[0073] The above process enables the client 50 to play the last segment of the captured content stream during the re-streaming of the captured content stream, and then seamlessly loop to start playing the earlier segment of the captured stream. This looping facility may be useful for some content streams (such as MPEG-DASH live streams with a single period) that are not designed to handle discontinuities in live streaming. For some applications, such as testing or debugging, it is necessary to continuously run a live stream for an extended period of time, and it may also be ideal to generate a stream that can represent a live content loop.

[0074] The modified manifest file is then associated with new attributes (e.g., a new name) as a re-stream manifest file (e.g., associated with the manifest file name expected by the live streaming client) and saved to a storage location in the system 10 (or to a separate storage location in another server), such as Figure 3 As shown in the re-stream manifest file storage unit 22 in the live streaming client, the live streaming client can access and download the manifest file from the re-stream manifest file storage unit 22.

[0075] The above described and Figure 7 The process shown in recreates the content streaming by sequentially presenting the captured manifest files to the client 50 by sequentially storing (saving) each captured manifest file to a location for download by the client, wherein the storage is timed to replicate the captured live streaming so that the client 50 can re-stream the captured content stream. Thus, as the retransmission of the content stream proceeds, the re-stream manifest file downloaded by the client 50 is dynamically edited, effectively recreating the same conditions as the original content streaming.

[0076] Alternatively, the captured manifest files may be combined into one or more larger manifest files, for example by copying manifest information from all captured manifests into a single manifest file, renaming the combined manifest file, and storing it in a storage location where a live streaming client can access and download the manifest file to re-stream the captured live broadcast.

[0077] The system 10 may optionally create new representations that were not in the original capture, for example, by dynamically transcoding the media content in the captured segments at a different bitrate or resolution than in the captured segments before or during retransmission. This can be used to enable testing of different bitrates or resolutions, or to test various types of codecs, for example, transcoding multiple H.264 content streams at the same quality but at a lower bitrate to test an H.265 or VP9 codec.

[0078] One or more embodiments of the present disclosure may be implemented as a computer program product for use with a computer system. The program of the program product may define the functions of the embodiments (including the methods described herein) and may be contained on various computer-readable storage media. Computer-readable storage media may be non-temporary storage media. Illustrative computer-readable storage media include, but are not limited to: (i) non-writable storage media (e.g., a read-only memory device within a computer, such as a CD-ROM disk 10 that can be read by a CD-ROM drive, a ROM chip, or any type of solid-state non-volatile semiconductor memory), on which information may be permanently stored; and (ii) a writable storage medium that can store variable information (e.g., a hard drive or any type of solid-state random access semiconductor memory, flash memory).

Claims

1. A method for providing a content stream based on capturing an initial delivery of the content stream, the method comprising the steps of: Acquiring manifest data associated with an initial delivery of a content stream, the manifest data being acquired one or more times in sequence during the initial delivery of the content stream to generate one or more manifest files; associating a corresponding timestamp with each of the one or more manifest files, each of the corresponding timestamps indicating a time when a corresponding manifest file of the one or more manifest files was obtained; processing each of the one or more manifest files to identify one or more addresses referenced in the one or more manifest files, wherein the one or more addresses reference one or more segments, each of the one or more segments comprising a portion of the content stream in the initial delivery; accessing the one or more segments referenced by the one or more addresses identified in the one or more manifest files; modifying a last manifest file of the one or more manifest files to include at least a portion of an earlier manifest file of the one or more manifest files; and Access to the one or more manifest files, including the modified last manifest file, and the accessed one or more segments is provided to a client, thereby enabling the client to receive at least a portion of the content stream.

2. The method according to claim 1, further comprising the steps of: Each of the one or more manifest files is stored at a location that enables the client to access the stream to render the content.

3. The method according to claim 1 or claim 2, wherein: Any second or later acquired manifest file is acquired after expiration of at least a predetermined time delay, wherein the predetermined time delay is a delay from the time when the last previously acquired manifest file was acquired.

4. The method according to claim 1 or claim 2, further comprising: An attempt is made to access all of the one or more segments referenced by the one or more addresses.

5. The method of claim 1 or claim 2, further comprising attempting to access all of the one or more segments that meet a predetermined criterion.

6. The method according to claim 1 or claim 2, further comprising the following steps: storing the accessed segment or segments; as well as One or more of the one or more manifest files are edited to reference the one or more new addresses of the stored one or more segments.

7. The method according to claim 1 or claim 2, wherein: The step of modifying the last manifest file includes copying a first period from a first manifest file, and inserting the copied period as a second or later period of the last manifest file.

8. The method according to claim 1 or claim 2, further comprising the following steps: processing each of the one or more manifest files to identify an availability time for each of the one or more segments; as well as Access to the one or more segments is attempted before an availability time of the corresponding segment expires.

9. The method according to claim 1 or claim 2, wherein: Each segment of the one or more segments has an associated availability period, and wherein processing of each manifest file is performed during the availability period of the corresponding segment.

10. The method according to claim 1 or claim 2, further comprising the following steps: The one or more manifest files are edited to change one or more availability time indications in the one or more manifest files.

11. The method according to claim 1 or claim 2, further comprising the following steps: Each manifest file of the one or more manifest files is stored including a corresponding associated timestamp.

12. The method according to claim 1 or claim 2, further comprising the following steps: The content stream is recreated using the one or more manifest files, the associated timestamps, and the one or more segments.

13. The method according to claim 1 or claim 2, further comprising the following steps: The one or more manifest files are sorted into a sequential set of manifest files according to their associated timestamps.

14. The method according to claim 1 or claim 2, further comprising the following steps: at capture time, progressively acquiring all of the one or more manifest files for retransmitting a portion of the content stream; as well as The content stream is recreated later.

15. A system for providing a content stream based on capturing an earlier transmission of the content stream, the system comprising: one or more processors; as well as A memory accessible by the one or more processors, the memory storing instructions that, when executed, cause the processor to: Acquiring manifest data associated with an initial delivery of a content stream, the manifest data being acquired one or more times in sequence during the initial delivery of the content stream to generate one or more manifest files; associating a corresponding timestamp with each of the one or more manifest files, each of the corresponding timestamps indicating a time when a corresponding manifest file of the one or more manifest files was obtained; processing each of the one or more manifest files to identify one or more addresses referenced in the one or more manifest files, wherein the one or more addresses reference one or more segments, each of the one or more segments comprising a portion of the content stream in the initial delivery; accessing the one or more segments referenced by the one or more addresses identified in the one or more manifest files; and modifying a last manifest file of the one or more manifest files to include at least a portion of an earlier manifest file of the one or more manifest files; The system is adapted to provide a client with access to the one or more manifest files including the modified last manifest file and the accessed one or more segments, thereby enabling the client to receive at least a portion of the content stream.

16. The system of claim 15, wherein: The system is further adapted to store each of the one or more manifest files in a corresponding location for access by a client, so that the client can play the content stream.

17. A system according to claim 15 or claim 16, wherein: Any second or later acquired manifest file is acquired after expiration of at least a predetermined time delay, wherein the predetermined time delay is a delay from the time when the last previously acquired manifest file was acquired.

18. A system according to claim 15 or claim 16, wherein: The step of modifying the last manifest file comprises copying a first period from an earlier manifest file and inserting the copied period as a second or later period of the last copy of the manifest file.

19. A system according to claim 15 or claim 16, the system further comprising processing each of the one or more manifest files to identify an availability time of each of the one or more segments, and attempting to access the one or more segments before the availability time of the corresponding segment expires.

Images